企业数据 Agent：先建设语义上下文，再让模型写 SQL

先说结论

数据 Agent 的主要难点不是 SQL 语法，而是把“活跃用户”“收入”“实验曝光”等业务词稳定映射到正确表、时间口径、过滤条件和权限范围。让模型直接浏览全部 schema，只会把组织里的歧义原样放大。更可靠的路线是先把语义上下文离线整理，再用真实问题与结果集评测闭环。

原文解决什么

企业数仓通常有重复表、历史字段、隐含 join 规则和只存在于分析师经验里的指标定义。用户问一句自然语言，Agent 即使生成可执行 SQL，也可能查错数据域、混用时间粒度，最终得到“看起来合理”的错误数字。原文介绍 OpenAI 如何为内部数据 Agent 提供分层上下文，并持续判断答案是否真的正确。

核心机制

原文的上下文不是单份数据字典，而是六层语义信息共同约束查询，可概括为业务术语、指标定义、表与字段、关联关系、历史查询经验以及用户或团队语境。关键做法有两点：

• 离线归一化： 预先清理名称、补充描述、识别重复资产并建立可检索关联，避免每次提问都让模型从原始元数据重新猜。
• Golden SQL 评测： 保存代表性问题、参考查询与预期结果集。评分优先比较结果集语义，而不是要求生成文本与参考 SQL 字符串完全一致，因为不同写法可能得到同一正确答案。

因此，线上回答与离线治理是同一系统：线上暴露的新歧义，应回流到语义层或评测集，而不是只改提示词。

和 Zero-to-AI 现有实践如何接上

本站的 Memory 系统设计 强调分层与按需取用，Agent Evals 强调 outcome 证据。数据 Agent 可以直接复用这两点：把稳定指标定义放在可版本化语义层，把当前用户请求留在会话层；评测时检查结果集与权限，不用“回答很像分析师”代替正确性。

一个低成本实验

选 10 个公开 SQLite 问题，先为 3 张表建立迷你语义包：业务名、字段解释、主键、join 规则、时间口径和两个已知陷阱。为每题保存参考 SQL 与排序归一化后的结果集。让 Agent 分别在“只有 schema”和“schema 加语义包”两种条件下各跑一次。

成功证据： 语义包版本在同一题集上的结果集通过数更高；每个失败能归因到口径、检索、SQL 或执行，而不是只记一句“模型答错”。

停止线： 参考 SQL 自身结果不稳定、数据快照无法固定，或敏感字段权限未定义；先修数据与 grader，不接入真实内部库。

常见误区

• schema 越多越好：无关表会增加检索噪声和误 join。
• SQL 文本不同就是错：应先规范化并比较结果集，再检查性能与治理要求。
• 把分析师经验全塞进 prompt：不可版本化、不可复用，也无法知道哪条知识已过期。

原文与证据边界

本文使用 OpenAI 官方页面公开的方法描述，没有 TraceFetch 验签包，因此不声称 verification.valid=true。六层结构是对原文工程思路的实践化概括；本站未访问其内部数据、指标、权限系统或生产评测结果，也未独立复现其效果。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。