让数据库代理先理解业务口径

Agent 能连数据库、能执行 SQL，不代表它能答对业务问题。问一句「上个月有多少客户」，它可能数的是注册账号，业务要的却是完成过购买、排除测试账号后的去重人数。查询成功了，数字依然可能错。

原文借 NVIDIA Auto Ontology 提出一个实用结论：先给 Agent 一份可审核的业务定义，再开放查询入口。作者没有实测该平台，而是用数据字典、SQL 视图和测试，演示普通团队可以怎样起步。对正在接分析助手、内部数据问答的开发者，这比继续补提示词更值得看。

为什么表结构齐全，Agent 还是会答错

数据库 schema 描述的是数据怎样存：有哪些表、字段、类型和约束。业务语义描述的是这些数据该怎样解释：什么算客户、哪些订单有效、收入要不要扣退款、按哪个时间统计。

customer_id、status、created_at 都在，Agent 也未必知道「活跃客户」需要满足什么条件。人类分析师往往掌握着没有写下来的规则，模型只能猜、参考样本，或者追问。问题就出在这些猜测里。

SQL 语法正确，只能证明查询能够执行，不能证明它回答了业务真正关心的问题。

原文把这件事拆成三层：

• schema 说明存储结构。
• 语义层记录指标、关系、排除条件和定义来源。
• 查询策略规定 Agent 可以访问什么、执行什么。

三层各管一件事。数据字典不能限制权限，只读账号也不能修正错误口径。提示词可以引用定义，但单靠一段提示词，很难承担长期维护业务事实的职责。

NVIDIA Auto Ontology 尝试把这些上下文做成基础设施。按维护者的描述，它支持从元数据生成语义层、协调跨系统定义、依据认证定义和数据血缘校验查询，并通过 MCP、CLI 和 API 提供上下文。数据血缘可以理解为：这个结果来自哪些数据，经过了哪些处理。

原文提到，该项目在 2026 年 11 月 3 日引发 Hacker News 讨论。但这些能力来自项目文档，并非作者独立验证过的准确率保证。

先把一个指标写清，再把它变成查询入口

作者建议从一个常见、容易核对的问题开始，例如「上个月有多少购买客户」，不要一上来覆盖整个数据仓库。

下面的定义把「购买客户」展开为可审核的规则，同时记录来源、时间字段、统计粒度和负责人：

metrics:
  purchasing_customers:
    description: "Distinct customers with at least one completed, non-test order."
    entity: customer
    source: analytics.purchasing_customers
    filters:
      - "orders.status = 'completed'"
      - "customers.is_test = false"
    time_field: orders.completed_at
    grain: customer per calendar month
    owner: analytics
    status: approved

entities:
  customer:
    primary_key: customers.id
    joins:
      - target: orders
        condition: customers.id = orders.customer_id

要重点看 filters、time_field 和 grain：它们决定谁被计入、归到哪个月，以及按什么单位去重。

这不是通用本体格式，也不靠 YAML 本身产生价值。真正有用的是把隐含假设写成别人可以质疑的决定。「购买客户」只是名称，「至少有一笔已完成订单、排除测试账号、按完成日期归月」才是规则。

时间也必须说明白。「上个月」可能指自然月、过去 30 天，或上一个完整报表周期。示例选择 UTC 自然月；实际团队应明确时区和边界。若财务与产品使用不同口径，就保留两个具名指标，并说明各自适用场景。

接着，把核心规则放进数据库视图，让 Agent 使用统一入口：

CREATE VIEW analytics.purchasing_customers AS
SELECT DISTINCT
    c.id AS customer_id,
    date_trunc('month', o.completed_at AT TIME ZONE 'UTC') AS month_utc
FROM customers AS c
JOIN orders AS o
  ON o.customer_id = c.id
WHERE c.is_test = false
  AND o.status = 'completed';

这里要关注 SELECT DISTINCT 的作用范围：去重的是客户与月份的组合，同一客户在同月买多次，仍只保留一条记录。

这段代码使用 PostgreSQL 语法。真实库里的时间字段类型、软删除规则和租户过滤，都要由数据负责人确认。原文没有提供这些实际条件，不能直接把示例当成正式口径。

有了视图，查询 2026 年 10 月购买客户数时，Agent 可以对 customer_id 使用 COUNT(DISTINCT customer_id)，并用 month_utc = TIMESTAMP '2026-10-01 00:00:00' 限定月份，不必每次重新拼接关联和过滤规则。

视图的优势是集中维护。它仍可能有 bug、暴露敏感列，或者固化了有争议的定义，所以还需要审核、测试和数据库权限。

怎样验证它懂业务，而不是只会解释结果

原文没有提供性能或准确率对照实验，它提供的是两层验证方法。

第一层验证指标实现。准备小规模测试数据，检查一笔已完成订单计一次、多笔订单仍计一次，待处理或已取消订单不计入，测试账号不计入。还要覆盖月末跨界，以及同名但不同 ID 的两个客户。

这些测试检查的是业务规则。视图能返回数据，并不足以说明规则正确。

第二层验证 Agent。建立一小组问题和预期行为：问「2026 年 10 月购买客户有多少」，应选择已批准指标和月份；问「活跃客户有多少」，如果没有定义，应先澄清；要求查看全部客户邮箱和购买历史，如果超出授权范围，就应拒绝或进入明确授权的流程。

每条评测记录问题、预期指标或视图、预期结果和审核人。定义、schema、模型或 Agent 指令发生变化后，再运行这组问题，同时核对生成的 SQL 和返回结果。

能识别歧义、知道何时不能回答，也是查询助手正确性的一部分。

执行边界则要落在系统里：使用专用只读角色，只开放必要视图，设置语句超时、适当的返回行数和资源限制。原文没有给出通用参数值，团队需要按实际数据库配置。

回答也应附带指标、视图、过滤条件和时间范围，必要时展示 SQL。自动生成的定义先进入草稿，由领域负责人批准后再用于报表。项目列出的可选凭据存储组件 HashiCorp Vault，也不能代替对认证、凭据轮换和部署配置的检查。

我的判断

我认同「先收敛定义，再扩大访问」的顺序。对于范围小、口径稳定的团队，数据字典加审核过的 SQL 视图，改动直接，责任也容易落实。相比只在提示词里堆业务说明，它多了一个可复用、可测试的执行入口。

但这套方案有前提：团队得有人能确认口径，并持续维护。owner 和 status: approved 写进文件，并不自动构成有效的审批流程。业务规则变了，定义和视图却没人更新，Agent 仍会稳定地给出过时答案。

另外，示例处理的是单一指标和简单关联。它没有证明这种做法在复杂关联、跨库数据或大量部门口径下还能保持低维护成本，也没有给出它相对其他方案的准确率提升。因此，这是一套有道理的设计建议，不能当作经过对照实验的效果结论。

当定义横跨多个数据库、部门术语冲突频繁、多个 Agent 需要共享上下文时，专门平台才更有评估价值。评估时应拿真实问题检查定义表达、变更审核、权限遵循和查询溯源。一个简单演示答对了，说明不了多少。

能拿来做什么

• 给内部数据问答或 Node 查询服务接入 Agent 时，先选一个可核对的指标，补齐过滤条件、时间字段、时区、粒度和负责人，再开放对应视图。
• 把重复购买、测试账号、订单状态和月份边界放进现有 SQL 测试或集成测试，让口径变更能够触发明确失败。
• 为日常调试保留「问题、所用指标、SQL、结果、审核人」记录，在更换模型或修改指令后复跑，同时检查歧义问题是否被正确澄清。
• 若要评估 Auto Ontology 这类平台，先整理团队自己的小型题集，包含正常问题、例外条件和必须拒绝的问题，再比较 SQL 与结果是否正确。