原文：Inside our in-house data agent — OpenAI · 2026-01-29 · Bonnie Xu, Aravind Suresh, Emma Tang
一句话导读：当数据规模达到 600PB 和 7 万张表，“找对表格"本身就是一份全职工作。OpenAI 的解法不是更聪明的模型，而是一套以 六层上下文 + Codex 代码语义 + 透传权限 为核心的内部数据 Agent —— 这套设计的真正价值，在于它把"上下文工程"从一句口号变成了可工程化的产品形态。
一、引言：当一条 SQL 长到 180 行
先看几个让人头皮发麻的数字。
OpenAI 内部数据平台支撑着 3,500 名员工（工程、产品、研究三条战线全在内），仓库里趴着 7 万张表，总量 600PB。在这样的体量下，分析师真正花时间的地方，往往不是写 SQL，而是 找对那张表：
“我们有很多非常相似的表格，我曾耗费大量时间去厘清它们的不同之处，以及具体应选择哪一个表格。有的表格包括已注销用户，有的则不包括这些用户。有的表格存在重叠字段，很难分辨具体内容。” —— OpenAI 内部用户原话
即便选对了表，分析师还要在多对多 JOIN、谓词下推错误、未处理的 NULL 之间挣扎，单条查询动辄 180 行以上。OpenAI 团队把这个状态总结得很直接：分析师本应专注于"定义指标、验证假设、做数据驱动决策”，结果一半时间都在调试 SQL 语义。
于是他们做了一件值得行业借鉴的事——不是采购更贵的 BI，不是给员工开 SQL 培训，而是自建一个数据 Agent，由 GPT-5.2 驱动，目标是把"分析要花一天"压到"分钟级回答"。
下面拆开看，这套系统真正稳的地方在哪。
二、设计动机：传统 BI 为什么撑不住 OpenAI 的规模
传统 BI 的隐含假设是"表格数量可控、语义稳定、用户懂 SQL"。在 600PB / 7 万张表的体量下，这三条假设全部破产：
- 可控？——表格沿袭复杂到分析师自己都说不清"用户活跃数"该走哪一张事实表。
- 稳定？——每天有新表上线、字段语义随产品迭代漂移。
- 懂 SQL？——研究员、PM、GTM 都要看数据，但他们不该被迫成为 DBA。
更糟的是，传统 Text-to-SQL 工具的失败模式高度集中在"上下文不够"：模型看不到字段是不是包含已注销用户、看不到这张表是不是只来自第一方 ChatGPT 流量、看不到上周事故让某指标定义临时改过——这些信息都不在 schema 里，但分析师每天靠它做判断。
OpenAI 团队由此得出一个并不性感、却极其重要的判断：
数据 Agent 的核心不是更聪明的模型，而是更准确、更新鲜、更可信的上下文。
落到产品上，这个 Agent 由 GPT-5.2 驱动，并通过 OpenAI 自家的工具栈（Codex、GPT‑5 旗舰模型、Evals API、Embeddings API）构建。多端接入：Slack 智能体、Web 界面、IDE 嵌入、通过 MCP 接入 Codex CLI、再经 MCP connector 接入内部 ChatGPT。
它能回答的提问长这样：
“For NYC taxi trips, which pickup-to-dropoff ZIP pairs are the most unreliable, with the largest gap between typical and worst-case travel times, and when does that variability occur?”
不是单步 SQL，而是 理解问题 → 探索数据 → 运行查询 → 汇总结果 的端到端分析；如果中间结果异常，它会自我调试并重试——已经接近"和一位资深分析师协作"的体验。
三、架构深拆：六层上下文体系
OpenAI 把这套上下文做成了一个分层栈，从最稳定的底座，一路叠到最易变的运行时校准。理解了这张图，就理解了为什么"加 description"远远不够。
第 1 层 · 表格使用情况
最朴素的一层：模式元数据（列名、类型）、表格沿袭（上下游关系）、历史查询采集。这是行业标配，但在 7 万张表的规模下，仅靠这层，模型甚至选不对表。
第 2 层 · 人工注释
领域专家撰写的表格 / 列描述：意图、语义、业务含义、注意事项。信噪比最高——但成本也最高、最容易过期，注定无法穷举。
第 3 层 · Codex 增强（关键创新）
这是整个体系里最反常识、也最值得学的一层。
OpenAI 让 Codex 去爬整个代码库，从生成数据的代码本身去推导：
- 这一列是否唯一？
- 这张表多久更新一次？
- 数据范围 / 粒度是什么？
- 它在 SQL 之外还被怎么用？（Spark、Python、notebook ……）
举一个原文里的例子：通过读代码，Agent 可以判断某张表是否仅包含第一方 ChatGPT 流量——这个事实在 schema 和 description 里都不会写明，但写代码的人显然知道。
“Meaning lives in code.”
这句话是整篇官方博客最值钱的一句。它意味着：
- schema 只描述形状（shape）；
- 查询历史只描述用法（usage）；
- 真正的语义（meaning）藏在生成数据的代码里。
如果你正在自建数据 Agent，把代码仓库当作一等公民——这是从 OpenAI 这套设计能学到的最反直觉、也最有迁移价值的判断。
第 4 层 · 机构知识
接入 Slack、Google Docs、Notion，把"产品发布、可靠性事件、内部代号、关键指标定义"全部喂进来。每条文档被采集后会嵌入并和元数据 / 权限一起存储，检索时 runtime 处理访问控制——非常重要，下一节会再回到这里。
第 5 层 · Memory 记忆
保存更正信息、过滤约束。范围分全局（整个团队共享）和个人（针对个人偏好）。用户可以手动创建 / 编辑记忆——这点在产品哲学上很关键：它把数据 Agent 的可靠性，从"开发团队单方面打磨"转变为"和用户共建"。
原文给了一个例子：Agent 最初不知道如何筛选某个分析实验（要匹配实验门里的特定字符串），通过用户加入一条记忆解决了——这是个非常具体的"用户教 Agent 学业务"场景。
第 6 层 · 运行时上下文
最后一层是兜底校准：直接对数据仓库发实时查询，验证 schema 没漂；可以与元数据服务、Airflow、Spark 对话拿当下的真实状态。前 5 层是"知识"，第 6 层是"事实"。
底座 ① ② 提供"形状"，③ Codex 揭示"含义"，④ ⑤ 沉淀团队知识，⑥ 兜底校准——这是这套上下文体系最完整的一句话总结。
它们怎么进 RAG —— 离线管道 + 运行时检索
注意一个工程细节：这些上下文不会全部塞进 prompt 常驻。
OpenAI 跑了一条每日离线管道：聚合表格使用情况、人工注释、Codex 增强 → 经 OpenAI Embeddings API 向量化 → 入向量库。运行时通过 RAG 仅拉取最相关的那一小段上下文，保证延迟。
这套设计有两个非常容易被忽略的工程价值：
- token 预算可控：上下文虽然有 6 层，但每次只"按需取"，不会因为知识库变大而拖慢任何一次问答。
- 权限可被严格执行：检索服务自带访问控制层，用户检索不到的内容，模型也读不到——这是数据 Agent 真正能在企业落地的前提。
四、像团队成员一样工作：与传统 BI 的差异
光有上下文还不够，产品形态本身决定了 Agent 是"工具"还是"同事"。OpenAI 在这一层做了几个关键选择：
- 多轮对话：跨轮次保留完整上下文，可以追问、改方向。
- 可中断（interruptible）：用户可以在分析中途打断并重新指定方向——和真人协作一样。
- 主动澄清：指令不明确时会主动反问；如果用户没回应，则采用合理默认值（例如"业务增长"默认最近 7 或 30 天）。
- 双模式胜任：既能干"已知问法"（“Tell me about this table”），也能陪你做开放探索（“I’m seeing a dip here, can we break this down by customer type and timeframe?"）。
- Workflows（工作流）：把"周报、表格校验"这种重复性分析打包成可复用指令集——本质上是把团队 SOP 数字化进 Agent。
这套交互的关键不在"模型能力”，而在产品愿不愿意承认 Agent 是个会犯错的同事，而不是一个永远正确的查询接口。多轮、可中断、主动澄清，全是这个判断的衍生物。
五、质量与安全：把 Agent 当作持续部署的服务
数据 Agent 在企业落地，最大的风险有两个：胡说八道（hallucinated SQL） 和 越权读数（permission leak）。OpenAI 在这两条上都做了硬约束。
Evals 闭环：防止能力漂移
Agent 不是上线一次就完事。模型升级、prompt 调整、工具变化，任何一个改动都可能让它在某些问题上悄悄退步。OpenAI 用 Evals API 做了一套类似单元测试的回归体系：
- 维护一份精选的问题—答案对；
- 每个问题配一条手工编写的 golden SQL；
- 跑流程：自然语言 → Agent 生成 SQL → 执行 → 与期望结果比较；
- 不依赖朴素字符串匹配——同一问题往往有多种正确写法，所以 grader 同时看 SQL 文本和实际结果，再由模型给出最终评分 + 可读理由。
这套体系开发期当作单元测试用，生产期当作 canaries 持续抽样跑——指标一掉就告警，提早发现回归。
把数据 Agent 当成持续部署的服务来对待——这是非常工程化的态度。绝大多数团队上线 Text-to-SQL 后就停止了 evaluation，只是因为它"看上去能用"。OpenAI 的做法提供了一份可复制的纪律。
严格透传的权限模型
“All access is strictly pass-through.”
这一句话是这套系统能在企业落地的根本保证：用户只能查询自己已经有权限的表格。Agent 不绕权、不缓存权限、不走自己的服务账号——它就是用户身份的延伸。
如果某次分析需要的某张表用户无权访问，Agent 会标记或回退到用户授权范围内的替代数据集，而不是默默失败或越权读取。
加上"公开推理过程、汇总假设与执行步骤、查询结果直链原始数据"的透明性约束，整个系统的信任锚点不在"模型有多准"，而在"过程可核验、权限可追溯"。
六、Lessons Learned：写给自建数据 Agent 团队的三条经验
这一节是整篇博客最具迁移价值的部分——不论你用不用 GPT-5.2，下面三条都成立。
#1 Less is More — 工具集越大，Agent 越糊涂
早期 OpenAI 团队把"完整工具集"暴露给模型，结果功能重叠让 Agent 频繁选错。精简和合并工具调用之后，可靠性反而提升。
我们能学什么：不要"以防万一"加工具。每加一个工具，模型每次推理的搜索空间都会变大、决策成本都会上升。先砍到最小工具集再扩——这条原则同样适用于通用 AI Agent。
#2 Guide the Goal, Not the Path — prompt 是目标书，不是流程图
OpenAI 团队发现：高度规定性的 prompt 反而降低效果。改为"高层级指引 + 让 GPT-5 自己决定路径"之后，结果更稳健。
我们能学什么：写 prompt 时区分"What"和"How"——你应该清晰描述什么样算成功，但不该规定先做 A 再做 B。前者让模型发挥推理能力，后者把它降级成一个执行器。这条经验和 OpenAI 在 GPT-5 上的整体设计取向是一致的：模型在"目标对齐"下表现最佳，而不是在"步骤受控"下。
#3 Meaning Lives in Code — 意义存在于代码中
这是最反常识、也是最值得搬到任何企业的一条。
我们能学什么：当你在做数据 Agent / 数据 Copilot / 内部 Text-to-SQL 时——
- 不要只接元数据服务和查询历史；
- 要把代码仓库（ETL / dbt / Spark / Airflow / 业务后端）也作为上下文源头；
- 用代码静态分析或 Codex 类工具去推导列含义、表的真实粒度、字段是否经过业务过滤。
如果你的数据 Agent 现在只看 schema 和 description，你看到的只是"形状"，真正的语义你还没看到。
三条经验共同指向同一件事：把"上下文工程"做扎实，比换更大的模型重要。
七、总结：给自建数据 Agent 团队的可执行清单
OpenAI 这篇博客在工程层面给了非常具体的可迁移信号。如果你正在或即将做一套企业数据 Agent，下面是一份基于这篇文章压出来的执行清单——按重要性排序：
- 先建上下文体系，再选模型。模型是变量，上下文是常量；你今天选 GPT-5.2，半年后可能换 Claude，但上下文体系一旦做好就持续吃复利。
- 强制把代码仓库纳入上下文源头。ETL / dbt / Spark / Airflow 任务的代码，比 schema 更接近字段真正的含义。Codex / 代码静态分析在这里是杠杆。
- 离线管道 + RAG，不要 prompt 常驻知识。前者保证 token 预算与权限边界，后者注定崩塌在大库上。
- 权限严格透传。Agent 是用户身份的延伸，不是新的服务账号。这是企业落地的不可妥协项。
- 维护一份 golden SQL 评测集，开发期当单元测试，生产期当 canaries——双信号 grader（SQL + 结果）比朴素字符串匹配可靠得多。
- 承认 Agent 是个会犯错的同事。多轮、可中断、主动澄清、Workflow 化——这些产品决策远比"再训一版模型"更影响落地体验。
- 共建式 Memory。让用户能写记忆、改记忆、管理记忆，不要把可靠性绑在你自己一个团队身上。
- 从最小工具集起步。功能重叠是 Agent 失败的主要来源之一，每加一个工具都要给出删除候选。
OpenAI 团队为这套系统设定的使命非常朴素：
“在 OpenAI 数据生态中无缝交付快速、可信的数据分析。”
这背后真正的判断是：在企业内部，数据分析的瓶颈早已不是 SQL 能力，而是上下文获取效率。谁能把上下文工程做扎实——把人、表、代码、文档、权限、记忆一层层组织好——谁就能让自家的数据生产力跨上一个量级。
模型会一代代变，但这个判断，在可见的未来都不会过时。
延伸阅读
- 原文：Inside our in-house data agent — OpenAI Engineering, 2026-01-29
- 关联：本仓库已有的 Hermes Agent 源码深潜 也展示了一套"运行时内核 + 工具系统 + 状态库"的 Agent OS 思路，可对照阅读。
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
