上下文工程 on DataAgentX

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

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

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

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

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

Why：为什么需要语义层

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

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

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

What：三重支柱分别解决什么

统一元数据

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

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

开放语义层

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

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

Ontology

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

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

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

两条路径的对比

维度	收入分析	个人数据保护
起点	业务术语解释	业务域
主要依据	指标与维度定义	本体关系
落点	指标 → 资产 → 查询执行	概念 → 字段 → 权限与脱敏
关键约束	口径一致、时间口径	最小必要、可审计

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

How：怎么开始构建

分享给出的路径很务实：

先选一个高价值问题，比如收入分析。
业务与工程一起确认定义。
绑定真实资产。
用参考问题和不同角色验证。
确认可用后，发布成共享对象。
根据使用反馈修订。

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

OpenAI 内部 Data Agent：难点不是写 SQL，而是找对上下文

Fri, 18 Sep 2026 00:00:00 +0000

表里都有 user_id，为什么两次查询算出的活跃用户仍不一样？企业问数最难的部分常常发生在 SQL 生成之前：应该用哪张表、哪个时间字段、哪套过滤条件，以及哪份定义仍然有效。

OpenAI 在 2026 年 1 月公开的内部实践，把问题中心放在上下文工程。文章给出的当时规模快照是超过 3,500 名内部用户、600PB 数据和约 70,000 个数据集。规模数字很醒目，但更值得借鉴的是系统如何缩小候选上下文。

六类上下文不是同一种知识

来源	提供什么	典型风险
表使用信息	Schema、血缘、历史查询	热门查询未必正确
人工注释	业务含义、已知问题、Owner 经验	可能过期或只适用于局部
管道代码	派生逻辑、过滤条件、新鲜度线索	实现复杂，需结合运行状态
机构知识	文档、讨论、决策背景	权威性和时效差异大
运行时反馈	查询结果、错误和数据分布	只能说明本次执行状态
记忆与纠正	已验证修正和失败经验	必须限制适用域与版本

这些材料不能简单拼进一个超长提示词。系统需要先检索候选资产，再按权限、时间、粒度和问题相关性收窄，并保留为什么选择这份上下文的证据。

查询生成只是中段

一个更完整的链路是：理解意图 → 检索元数据与机构知识 → 选择候选表和可信查询 → 生成与执行 → 根据错误和结果修正 → 独立验证 → 记录可复用纠正。

其中，执行反馈很关键。空结果可能意味着过滤错误，也可能是真实业务现象；SQL 成功只能证明语法和运行环境接受了它，不能证明业务语义正确。

记忆必须有适用边界

“上次把 created_at 换成 activated_at 就对了”不是全局规则。可靠记忆至少要绑定数据域、指标、表版本、时间范围和验证证据。否则一次有效纠正会成为下一次错误来源。

对企业团队的启示

不要先追求覆盖所有数据。先选一个定义相对稳定、Owner 明确、错误代价可控的业务域，建设可检索的资产说明、可信查询、运行时权限和回归任务集。每次纠正都进入审阅流程，而不是直接写入永久记忆。

这套内部实践不是可直接采购的产品规格。它真正说明的是：当数据规模扩大后，Data Agent 的瓶颈会从“能不能生成 SQL”转向“能不能找到、约束并验证正确的上下文”。

Data Agent 接入层：连接数据之后，怎样先找对数据

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

“本月新客转化为什么下降？”仓库里可能同时存在生产漏斗模型、名字相近的测试表和上季度活动表。连接器都能访问，字段看起来也都合理。Agent 如果挑错其中一个，后面的 SQL、图表和解释越完整，误导性反而越强。

接入层要在生成查询之前回答三个问题：当前身份可以访问什么，这个任务应该使用什么，候选数据是否足以支撑结论。它不是一个把所有 Schema 塞进提示词的管道，而是一套受权限约束的数据发现和上下文路由系统。

图里最重要的是两道权限检查：目录检索前先缩小可见范围，真正执行时再次鉴权。目录中的“可发现”从来不等于数据库中的“可执行”。

接入层与相邻层的边界

接入层负责发现资产、检查来源与可见范围，并交付最小充分上下文。语义层维护“新客”“转化率”等定义、粒度和合法关联；规划层决定分析步骤；执行层保管凭证、运行查询并重新检查权限。

这几层不能互相代替。表名相似不是业务定义，目录授权也不是执行凭证。把这两个边界混在一起，常见结果是 Agent 用热门旧表回答新问题，或者通过共享服务账号绕过用户权限。

四个组件，各自要交付什么

组件	最小交付物	失败时怎么办
数据源注册中心	稳定来源 ID、环境、业务域、负责人、认证引用、允许操作和预算	未注册来源不静默接入
资产目录与采集器	Schema 版本、字段说明、血缘、质量状态、采集时间和数据水位	未采到的信号标为未知
上下文路由器	候选资产、采用与排除理由、必要字段、定义引用和缺口	无可靠来源时澄清或停止
连接器运行时	身份绑定、分页、超时、重试、标准结果和审计事件	凭证不进入模型上下文

现有目录能力应优先复用。OpenMetadata把所有权、术语、血缘、画像和质量信号组织在统一元数据中，其采集框架覆盖多类元数据工作流。但安装目录不会自动产生正确路由；哪些信号参与排序、哪些属于阻断条件，仍要由团队设计。

一次可靠路由包含六步

1. 把业务问题解析成检索约束

提取业务域、实体、指标、时间、粒度、用途与交付物。相对时间要落成具体区间和时区。问题中“客户”“订单”含义不清时，应在检索前澄清，而不是等 SQL 失败后再补救。

2. 在当前身份可见范围内召回

关键词、业务术语和向量检索可以共同生成候选，但召回必须身份感知。表名、字段说明和样例值本身也可能敏感；不能先把全量目录交给模型，再指望它自行忽略无权访问的资产。

3. 先做硬性策略过滤

环境、用途、地域、敏感等级、元数据可见性和数据访问权限都是门禁，而不是排序加分项。测试表与生产表名称再接近，也不能因为语义相似度高而越过环境隔离。

4. 在合规候选中排序和裁剪

比较业务覆盖、权威性、更新时间、质量证据、关联完整性和预计成本。热门表的历史使用量只能做辅助信号，否则新权威模型永远排不过旧表。多表任务还要保留必要的 Join 路径，而不是只挑几个相似字段。

5. 绑定资产，执行时再检查

路由器交付资产引用、版本与预算，运行时再绑定真实身份。目录发现到执行之间，权限、Schema 和数据状态都可能变化。Microsoft Fabric Data Agent 的权限文档也区分 Agent 的分享权限与底层数据权限；共享 Agent 不会替用户获得源数据访问权。

6. 把结果和纠错写回

保留候选、排除理由、采用版本、执行结果与人工纠错。用户点击或采纳只能说明体验，不足以证明来源正确；被确认的错误才进入回归集或质量标签。

上下文包需要同时表达事实和限制

上下文不应只是字段列表。一个可执行的上下文包至少应包含：

{
 "asset_ref": "warehouse.prod.funnel",
 "schema_version": "v12",
 "selected_fields": ["day", "channel", "new_users", "converted_users"],
 "definition_ref": "metrics/new_customer_conversion/v3",
 "grain": "day × channel",
 "metadata_observed_at": "2026-09-07T09:00:00+08:00",
 "data_watermark": "2026-09-06",
 "quality_status": "unknown",
 "policy_ref": "policy/read-funnel/v4",
 "allowed_operations": ["read"],
 "limitations": ["尚未确认所有渠道覆盖"],
 "requires_runtime_authorization": true
}

metadata_observed_at 与 data_watermark 必须分开。目录今天同步成功，不代表业务数据也更新到了今天。policy_ref 只是策略引用，不是凭证；授权句柄和密钥留在可信服务端。