接上数据库、写出 SQL，Agent 就能答对业务问题了吗？
同样问“上季度收入是多少”，不同工具会给出不同答案：BI 可能把税费、运费算进去了，Notebook 可能没扣折扣和退货，财务按发货日确认，Agent 还在重新猜表之间怎么关联。
问题藏在“收入”两个字背后。本文基于堵俊平在 DACon 2026 的分享《开放语义、Ontology 与元数据：Agent Context 的三重支柱》整理。
Why：为什么需要语义层
Agent 需要知道三件事：收入怎么算、时间按哪一天、该连哪些表。
当它进一步参与决策和执行，还要知道当前用户有没有权限、操作需要满足什么条件。
把这些业务知识整理成能共享、可维护的上下文，才能减少每次从头猜测。这就是语义层的起点：不是给模型更多资料，而是给模型一个稳定的解释框架。
What：三重支柱分别解决什么
统一元数据
让 Agent 找到真实资产：数据在哪里、结构是什么、如何访问。
关键点是“不必把所有数据搬到一处”。元数据提供的是地图和通行证，而不是把地图上的东西都搬进一个房间。
开放语义层
把指标、维度、时间口径和关联定义统一起来，让 BI、应用与 Agent 使用经过确认的业务定义。
这是解决“收入口径不一致”的核心一层。它约束的不是数据形态，而是计算含义：分子分母是什么、时间按哪个字段、哪些 Join 合法。
Ontology
表达业务实体、关系和约束。比如“个人数据”包括邮箱和电话，再把这些概念连接到真实字段，检查权限与脱敏策略。
这一层的作用在权限和合规场景里最明显：当问题从“收入多少”变成“这个人的信息能不能给这个角色看”，需要的不是指标定义，而是概念之间的关系。
三者合起来，才构成较完整的 Agent Context。做收入分析和查个人数据，调用的上下文路径并不相同——这一点很重要：上下文不是一份静态文档，而是按任务组合的路径。
两条路径的对比
| 维度 | 收入分析 | 个人数据保护 |
|---|---|---|
| 起点 | 业务术语解释 | 业务域 |
| 主要依据 | 指标与维度定义 | 本体关系 |
| 落点 | 指标 → 资产 → 查询执行 | 概念 → 字段 → 权限与脱敏 |
| 关键约束 | 口径一致、时间口径 | 最小必要、可审计 |
同样一套底座，支撑两种完全不同的路径。这正是“共享”与“统一”的区别：共享底座，不意味着所有问题走同一条链。
How：怎么开始构建
分享给出的路径很务实：
- 先选一个高价值问题，比如收入分析。
- 业务与工程一起确认定义。
- 绑定真实资产。
- 用参考问题和不同角色验证。
- 确认可用后，发布成共享对象。
- 根据使用反馈修订。
场景帮助我们验证价值，共享底座让这些知识被下一个应用复用。
第 4 步最容易被简化成“问几个问题试试”。更严格的做法是设计参考问题集，并且用不同角色去跑：同一个问题，分析师、业务负责人和受限角色看到的答案和字段范围应当不同，且这些差异是有意设计的。
容易忽略的一点：上下文会过期
字段改了、权限变了、收入规则调整了，都需要重新校验。
这引出一个常见误解：把语义层当成一次性建设项目。实际上它更接近持续维护的资产，和代码、文档一样需要版本和回归。
分享还提到一个有意思的处理方式：Agent 从使用中学到的内容，可以先作为候选保留来源，经过审核后再更新正式定义。
这个设计把“学习”和“生效”分开了。没有审核环节的自学习语义层，会很快积累一批没人确认过的定义，最终比没有语义层更危险。
从一个真实问题开始，问清四件事
基于分享内容，我整理了以下四个问题作为评估清单。这是编辑建议，并非演讲原文给出的结论：
- 定义谁负责？ 如果一个指标没有明确的负责人，它迟早会出现两个版本。
- 概念能否找到对应资产？ 定义再准确，落不到字段上也执行不了。
- 换个角色权限还有效吗？ 同一个概念在不同角色下应当有不同的可见范围。
- 定义变更后能否追溯和复验？ 不能追溯的变更，等于把历史数据变成不可比。
这四个问题覆盖了责任、落地、权限和版本四个方面，正好对应三重支柱加上贯穿其中的治理。
我的判断
语义层建设的难点不在技术，而在归属。统一元数据、开放语义层和 Ontology 都可以用工程手段搭起来，但如果没有明确的定义负责人和变更流程，它们会各自演化成一套孤岛。
因此，与其先比较工具，不如先确认：谁有权定义这个指标，谁在变更时需要被通知，变更后谁来复验。这些答案清楚了，技术选型才有意义。
资料来源：堵俊平《开放语义、Ontology 与元数据：Agent Context 的三重支柱》，DACon 2026。