我最怕的不是 AI 答不出来，而是它答得飞快，数字却是错的。以前让 agent 查营收，它就靠列名猜：哪个字段像 revenue 就 sum 哪个，口径对不上、关联表接错，最后给出的数字看起来很自信，查账时根本对不上。auto-ontology 吸引我的地方就在这里：它不先急着回答，而是先给数据建一层“意思”——什么叫营收、这个指标由哪些字段算出来、表和表之间怎么连，都先写清楚、让人审过，agent 再按这层意思去查。
它的做法分三步，这个顺序比功能列表更重要。第一步是生成：从数据库元数据里抽出业务术语、表间关系和 SQL 表达式，存进 Postgres 加 pgvector，变成一张可以检索的语义图。第二步是认证：人在界面里改术语、改口径，确认无误后再打上认证标记，没认证过的东西不值得信任。第三步才是回答：agent 先查术语、再写 SQL、再校验过滤值和查询，跑完把答案、SQL 和推导步骤一起交出来；答不出来就直说数据里没有，别硬编。
上手门槛我先说明白，这不是 pip install 就能跑的小库，而是一整套服务：前端、后端、摄取服务、Postgres，还有可选的 Vault，本地用 Docker Compose 起，线上用 Helm 上 Kubernetes。还要准备 NVIDIA 的 API 密钥，默认走 NIM 的模型，推理、抽取、向量、重排各有分工，环境变量按三元组配，漏配就回落默认值，配错了排查起来有点绕。官方快速上手用的是微软的示例销售库，先起数据库、导数据，再开语义编译，等到提示就绪后才能在聊天里提问。这一圈跑下来不算短，但对数据类项目来说，这个前置成本花得值。
真正让我觉得它值得试的，是两个细节。第一，答案带出处：不光给数字，还给 SQL 和步骤，错了能定位到是术语错了、关联错了还是过滤值错了。第二，它懂得说“不知道”：问一个数据里根本没有的概念，它会先做可回答性检查，而不是现编一个数字。这两点加起来，才是做数据分析的 agent 该有的样子——慢一点没关系，错了还自信才要命。
坑我也列清楚。MCP 服务器本身只是只读客户端，不存数据库连接、不存密钥，别把它当成产品本体；后端和摄取服务的端口要放在内网，因为摄取接口自己没有鉴权、还信任前端传来的用户标识，暴露到公网就是隐患。向量模型在摄取和查询时必须一致，换模型要重建。预测问答走外部服务时会把表上传出去，开之前先过一遍数据合规。另外这个项目目前不接受外部贡献，想参与只能提 issue 或集成需求，别指望提 PR 能合进去。
适合谁？我觉得是三类：同一指标在不同系统里有不同口径、经常为数字打架的数据团队；已经在用 Postgres、Snowflake、Databricks 这些源、想让 agent 稳定查数的人；还有在给 Cursor、Claude 这类工具接企业数据、但不想让 agent 直接猜表结构的人。反过来，如果你只是偶尔查一两次表、数据量很小、口径从来没乱过，那这套东西就是大材小用，先把 SQL 写清楚更划算。
上手建议：先别接自己的生产库，就用示例库走通一圈——起服务、等语义编译就绪、问一个能算出数的业务问题、再故意问一个数据里没有的概念，看它是不是真的会说不知道。这两问都对了，你再决定要不要把自己的库接进来。
