Agent 越强，为什么越需要语义层

Tue, 08 Sep 2026 00:00:00 +0000

把订单表、支付表和客户表的 Schema 交给模型，它很快就能写出一条可运行的 SQL。可当用户问“上个月收入是多少”，真正的问题才开始：收入是下单金额、实收、净收款还是财务确认收入？按下单时间还是确认时间？退款归属哪个月？

这些不是模型应该自由推断的常识，而是企业自己的业务合同。Agent 能力越强、执行链越长，一个错误定义被传播到报告和动作中的代价就越大。

Schema 描述数据的形状；语义层规定数据在什么条件下代表什么事实、允许怎样聚合。模型可以帮助发现冲突、起草定义，却不能替指标负责人决定口径。

语义层、本体和目录各管什么

资产目录回答“有什么、在哪里、谁负责”；语义层回答“怎么算、能按哪些维度分析”；业务本体回答客户、账户、订单等概念如何识别和关联。执行与治理系统则强制实施权限、预算和审计。

本体不一定要从复杂知识图谱起步。一个受治理的实体关系模型，能明确主键、基数、有效期和身份映射，就已经解决很多 Join 放大和概念混用问题。重要的是定义可引用、可版本化、可被查询编译或验证，而不是图画得多复杂。

六类语义资产缺一不可

资产	至少要明确	缺失后的典型错误
指标	公式、单位、时间口径、粒度、聚合、版本、负责人	把支付金额当确认收入；比率直接平均
实体	主键、唯一性、关系方向、基数、有效期	一对多 Join 放大金额；账户与客户混用
维度	层级、合法取值、适用指标、历史归属	用当前地区解释历史业绩
同义词	业务域、语言、候选概念与不可等同项	把营收、销售额和回款无条件合并
业务规则	状态过滤、币种、财务周期、用途、生效区间	测试订单进入正式报表
验证样例	问题、口径、查询、快照、预期结果、验证人	旧 SQL 被当成永久正确答案

这些资产可以分布在词汇表、指标服务、目录和样例库中，但必须通过稳定 ID 与版本关联。复制多份自然语言说明，通常只会制造新的漂移。

“收入”案例：先绑定定义，再写 SQL

假设团队同时维护交易总额、实收金额和财务确认收入。用户只说“收入”时，可靠流程是：

检查当前报表或会话是否已绑定某个指标；没有明确上下文就澄清。
将“上个月”转换为指定时区的具体区间，确定支付时间还是确认时间。
读取退款、税费、币种和内部账户排除规则。
先形成指标、维度、过滤与版本组成的语义计划，再编译查询。

一个最小指标契约可以长这样：

{
 "metric_id": "commerce.period_net_receipts",
 "version": "1.0",
 "definition": "期间成功收款减期间成功退款",
 "expression": "sum(receipt_cny) - sum(refund_cny)",
 "time_fields": {"receipts": "paid_at", "refunds": "refunded_at"},
 "timezone": "Asia/Shanghai",
 "grain": "calendar_day",
 "unit": "CNY",
 "allowed_dimensions": ["channel"],
 "missing_input_policy": "unknown_not_zero",
 "effective_from": "2026-08-01",
 "test_suite_ref": "tests/net-receipts-v1"
}

缺失输入记为未知，而不是零；退款与收款应先按兼容粒度聚合，再对齐计算，不能直接连接两张明细表造成乘积。最终答案还应带出采用的指标版本、时间字段、数据水位和限制。

语义如何进入运行链路

语义资产只有进入执行与验证，才不只是文档：

知识图谱 on DataAgentX

Agent 越强，为什么越需要语义层

语义层、本体和目录各管什么

六类语义资产缺一不可

“收入”案例：先绑定定义，再写 SQL

语义如何进入运行链路