Agent 语义层的 2W1H：为什么需要、是什么、怎么做

Fri, 23 Oct 2026 00:00:00 +0000

接上数据库、写出 SQL，Agent 就能答对业务问题了吗？

同样问“上季度收入是多少”，不同工具会给出不同答案：BI 可能把税费、运费算进去了，Notebook 可能没扣折扣和退货，财务按发货日确认，Agent 还在重新猜表之间怎么关联。

问题藏在“收入”两个字背后。本文基于堵俊平在 DACon 2026 的分享《开放语义、Ontology 与元数据：Agent Context 的三重支柱》整理。

Why：为什么需要语义层

Agent 需要知道三件事：收入怎么算、时间按哪一天、该连哪些表。

当它进一步参与决策和执行，还要知道当前用户有没有权限、操作需要满足什么条件。

把这些业务知识整理成能共享、可维护的上下文，才能减少每次从头猜测。这就是语义层的起点：不是给模型更多资料，而是给模型一个稳定的解释框架。

让 Agent 找到真实资产：数据在哪里、结构是什么、如何访问。

关键点是“不必把所有数据搬到一处”。元数据提供的是地图和通行证，而不是把地图上的东西都搬进一个房间。

把指标、维度、时间口径和关联定义统一起来，让 BI、应用与 Agent 使用经过确认的业务定义。

这是解决“收入口径不一致”的核心一层。它约束的不是数据形态，而是计算含义：分子分母是什么、时间按哪个字段、哪些 Join 合法。

表达业务实体、关系和约束。比如“个人数据”包括邮箱和电话，再把这些概念连接到真实字段，检查权限与脱敏策略。

这一层的作用在权限和合规场景里最明显：当问题从“收入多少”变成“这个人的信息能不能给这个角色看”，需要的不是指标定义，而是概念之间的关系。

三者合起来，才构成较完整的 Agent Context。做收入分析和查个人数据，调用的上下文路径并不相同——这一点很重要：上下文不是一份静态文档，而是按任务组合的路径。

同样一套底座，支撑两种完全不同的路径。这正是“共享”与“统一”的区别：共享底座，不意味着所有问题走同一条链。

分享给出的路径很务实：

场景帮助我们验证价值，共享底座让这些知识被下一个应用复用。