为什么你的数据Agent总答错？OpenAI内部数据Agent给了4个工程答案

摘要

很多团队做数据 Agent 的第一反应，是让大模型直接连数据仓库、自动写 SQL、自动生成图表。Demo 看起来很快，但一进真实业务就容易翻车：表选错、字段含义理解错、join 条件错、口径不一致、权限边界不清，最后用户还是得找数据同学兜底。

OpenAI 在《Inside OpenAI’s in-house data agent》中披露了他们内部数据 Agent 的设计。这个系统服务 3.5k+ 内部用户，面对 600PB 数据和 70k 数据集，目标是让员工用自然语言在几分钟内得到高质量分析结果。重点不是“模型会不会写 SQL”，而是如何给 Agent 足够准确的上下文、权限和自我纠错机制。

本文用更工程化的方式拆解这篇文章：如果你正在做企业内部数据 Agent，最该关注的不是炫酷对话界面，而是下面四个问题。

痛点一：数据 Agent 最大的问题不是不会查，而是不知道该查什么

在企业数据平台里，表名和字段名通常只描述了形状，不描述业务含义。一个字段叫 user_id，不代表它一定是最终用户；一个 active_users 指标，也可能因为产品线、时间窗口、去重规则不同而含义完全不同。

OpenAI 文章里提到，没有足够上下文时，即使强模型也会误估用户数、误解内部术语，甚至找不到正确表。这个问题在企业里非常普遍。数据 Agent 如果只拿 schema、字段类型和用户问题，就像让新同事第一天进公司直接写核心经营分析。

OpenAI 的方案不是让模型“猜得更聪明”，而是构建多层数据上下文。第一层是 table usage：表的 schema、上下游 lineage、历史查询、常见 join 方式。第二层是 human annotations：由领域专家提供表和字段解释、业务语义、已知 caveat。第三层是 Codex 代码理解：通过代码库理解数据集到底是怎么生产出来的。

这里有一个关键判断：数据含义很多时候不在数据仓库里，而在生产数据的代码里。pipeline 逻辑、刷新保证、过滤条件、实验 gate、业务假设，往往不会完整出现在表注释里。OpenAI 把 Codex 用来丰富数据上下文，本质上是在让 Agent 读懂数据生成链路。

痛点二：RAG 不是简单搜文档，而是要搜“可执行的数据语义”

很多团队做数据 Agent，会把数据字典、指标口径、SQL 示例丢进向量库，然后让模型检索。但如果检索材料质量低，Agent 只是更快地拿到错误上下文。

OpenAI 的做法更系统。他们运行每日离线 pipeline，把 table usage、人类标注和 Codex-derived enrichment 聚合成标准化表示，再通过 Embeddings API 转成可检索向量。运行时，Agent 只拉取和当前问题最相关的上下文，而不是扫描原始元数据和日志。

这个设计解决了两个问题。第一，规模问题：70k 数据集不能靠 prompt 全塞，也不能靠模型逐个扫描。第二，延迟问题：上下文检索必须快而稳定，否则自然语言分析体验会退化成慢查询系统。

对研发团队来说，RAG 在这里不是“知识库问答”的附属功能，而是数据 Agent 的核心路由层。它决定 Agent 能否找到正确表、理解正确口径、避免低级 SQL 错误。

痛点三：真正可用的数据 Agent 必须会自我纠错

数据分析不是一次性问答。真实问题经常是开放式的：用户问“最近增长怎么样”，并没有说时间范围、分群、指标口径和异常处理。Agent 需要先提出假设，再查询，再检查结果是否合理，然后修正路径。

OpenAI 的内部数据 Agent 不是固定脚本。文章中描述，它会评估自己的中间结果。如果发现结果明显不对，比如 join 或 filter 导致 0 行，会调查原因、调整方法、重试。它还支持用户中途打断和重定向，像和人类数据同事协作一样逐步收敛。

这对企业落地很重要。一个只会“用户问一句、模型跑一条 SQL”的系统，本质上只是 SQL 生成器。数据 Agent 要真正可用，必须能闭环：理解问题、探索数据、运行查询、检查异常、修正假设、输出结论，并暴露关键假设和执行步骤。

痛点四：权限不是外挂，必须是 Agent 架构的一部分

数据 Agent 一旦接入企业数据，权限就是第一优先级。OpenAI 的设计是 pass-through access：Agent 继承并执行用户已有的数据权限。用户只能查询自己本来有权限访问的表；缺权限时，Agent 会提示或寻找用户可访问的替代数据集。

这比“给 Agent 一个超级权限账号”安全得多。很多内部工具为了图省事，会让 Agent 使用统一服务账号访问数据，再在应用层做一些粗粒度限制。这种设计短期快，长期风险很大：越权查询、审计困难、责任边界不清。

OpenAI 还强调透明性。Agent 会总结假设和执行步骤，查询结果可以追溯到底层数据，用户能检查原始结果。这点同样关键。数据分析结果天然可能出错，可靠系统不是假装不会错，而是让错误可发现、可复查、可纠正。

研发落地清单：做企业数据 Agent 先检查这6件事

第一，先建表级知识，不要先做聊天界面。至少要有 schema、血缘、历史查询、常见 join、字段解释、口径 caveat。

第二，把人类标注纳入闭环。数据专家对表和字段的解释，比模型自己猜更可靠。Agent 每次被纠正后，应允许用户保存 memory，并支持人工编辑。

第三，读代码，不只读表。数据 pipeline 代码里有大量业务语义：过滤条件、实验命名、刷新周期、去重逻辑。没有代码上下文，Agent 很难理解表的真实含义。

第四，限制工具数量和重叠能力。OpenAI 的经验之一是 Less is More。早期暴露完整工具集会让 Agent 被重叠功能干扰，应合并和收敛工具边界。

第五，提示词要指导目标，不要硬编码路径。OpenAI 提到过度规定步骤会降低效果。数据问题变化大，平台应给模型高层分析目标和验证原则，而不是把每类问题写成死流程。

第六，权限和审计从第一天就接入。不要等 demo 成功后再补权限。数据 Agent 的每次查询、假设、结果链接和用户可见解释，都应该能审计。

风险与限制

OpenAI 这套系统是内部工具，不是外部产品。它依赖 OpenAI 自身的数据平台、权限模型、Codex、Evals API、Embeddings API 和内部工作流。其他团队不能直接复制，但可以复用设计原则。

另一个限制是，数据 Agent 的价值来自上下文积累。刚上线时，如果表注释差、历史查询乱、权限体系不清，Agent 的质量不会因为接入大模型就自动变好。企业真正要投入的是数据治理、元数据系统和反馈闭环。

结尾：数据 Agent 不是 SQL 生成器

如果你的数据 Agent 总答错，先不要急着换模型。更可能的问题是：它没有足够准确的数据语义，没有稳定的检索层，没有自我纠错机制，也没有和企业权限模型打通。

OpenAI 这篇文章给出的核心答案很直接：可靠的数据 Agent = 模型推理 + 数据上下文 + 代码语义 + 权限透传 + 可审计闭环。

如果你们团队也在做内部数据 Agent，可以先评论区交流一个问题：你们现在最头疼的是“找表难”、SQL 质量差，还是权限和审计难？

参考来源

• OpenAI Engineering - Inside OpenAI’s in-house data agent: https://openai.com/index/inside-our-in-house-data-agent/