📊 今日飙升榜（数据截至 11-05）：上榜 16 个仓库 · 最快 +2470 star/日 · 完整榜单与各仓库 star 趋势见 open-repo.com

把仓库拉到本地，一条 uvx 命令就把 MCP server 拉了起来，本机 3003 端口开始监听——主服务根本不在，它也照样启动，因为它只是一个只读的 HTTP 客户端。这个细节把 NVIDIA 这波刷屏的 auto-ontology 的性格摆得很清楚：门面做得极轻，重活全部押在数据这一层。它要治的病更直白——agent 查库，三秒出数、图表漂亮，但用错了"营收"那一列，没人看得出来。

auto-ontology 在 open-repo.com 的详情页：star 趋势与统计卡（数据截至 11-05）

## 它给 agent 的不是更强的模型，是一本对过口径的字典

auto-ontology 管的是 text-to-SQL 里很脆的一段：口径。官方文档把它的本体拆成三类对象——业务术语（"客户""订单"指什么、映射到哪些列）、SQL 属性（毛利、滚动汇总这类经过评审的计算式）、关系（表之间怎么连、桥表在哪）。生成阶段吃元数据自动起草，人认证过了才准 agent 用；回答时附上 SQL 和数据出处，语义层盖不住的问题，它会直接说答不了。

接入面也铺得开。文档列出的数据源有十种，从 Postgres、MySQL、Snowflake、Databricks 到 DuckDB、SQLite；对 agent 只开九个 MCP 工具，全部只读——刻意不给浏览原始库表的入口，agent 只能从语义层走。谁登录、谁有什么权限，沿用部署侧的 RBAC。

open-repo.com 首页：当日飙升榜快照（数据截至 11-05）

## 我拉起来转了一圈：轻的是门面，重的是全家桶

先说轻的那半。MCP 子包的打包注释写得很坦白：故意不做成主服务的 extra，因为装主服务要拖约 450 个依赖、超过 1GB；MCP 只当 HTTP 客户端，四个依赖几秒装完——这也是它能一条 uvx 命令起服务的原因。

重的在后头。跑全套要 Docker Compose 拉起七个服务：Postgres、pgAdmin、后端、ingestion、两个 migrate、前端；.env 里要填 nvapi- 开头的 API key 和 AUTH_SECRET，密码有五处要换，默认模型挂在 NVIDIA NIM 的 nemotron 系列上。样例库用微软的 Wide World Importers，官方文档称一次编译产出 31 个术语。另外 README 明说：暂不接受外部贡献。

## 热度这周才压过来，证据还在路上

时间线能对上。10 月 21 日它随 NVIDIA 的 Agent Knowledge Foundation 亮相；上周末到本周，marktechpost、AI Affairs 相继撰文，X 上有数据工程博主把矛盾点戳穿——三秒出数、数字干净，但用错了营收列，没人发现。转发把这波热度压到 GitHub：单日 +2050 star、累计 5203（截至 11 月 5 日）。

仓库主页 README：定位一句话讲清——reliability gates agentic analytics（数据截至 11-05）

但有一个缺口值得盯住：官方发布的是评测 harness（BIRD 等基准的对比脚手架），准确率结果还没公布；Hacker News 讨论里尖锐的一条质疑也打在这里——用 LLM 生成的本体去修 LLM 的 SQL，会不会只是拿一层不可靠去补另一层。这个问题的答案，得等数据。

一个判断：agent 查数缺的从来不是速度，是口径——语义层这个方向押对了；但准确率数据公布之前，auto-ontology 更像企业试点的一张门票，不是现成的答案。

你司报表里的"营收"，和业务系统里的"营收"，是同一个数吗？评论区聊聊你对口径打架印象最深的一次。