OpenAI 数据智能体构建解析

OpenAI 的数据平台汇聚了 1.5 EB 的海量数据，涵盖 90,000 个数据集，预计在 2026 年 5 月服务于约 4,000 名内部员工。过去两年，团队在巨大的增长压力下成功实现了平台的规模化。在这个规模下，数据分析的最大难点并非编写 SQL，而是首先找到正确的表，并从语义层面理解数据用法。许多表外观相似，但含义迥异。每张表的粒度是什么？如何与其他数据关联？分析师在编写第一行代码之前，可能要耗费数小时来弄清该使用哪些表以及如何使用。

去年，OpenAI 数据平台团队内部研发了一个智能体来解决这一问题。用他们的话来说，这个智能体“相当普通”，但它在整个生态系统中表现可靠。驱动该智能体的 Codex 投入也让团队实现了大多数公司认为不可能的任务，例如在两个月内将数千个 DAG、90,000 张表和 600 PB 数据在云端之间迁移。

我们采访了 OpenAI 数据平台工程负责人 Emma Tang，深入探讨了智能体的工作原理、为何在如此规模下简单的架构便已足够——因为底层拥有强大的数据基础设施，其他团队能从中获得哪些启示，以及平台的下一步发展方向。感谢 Emma 详细分享团队的工作。

在本文中，你将了解到：

要理解这个智能体，我们需关注三个维度：用户提问时的体验、支撑这一体验的架构，以及一个请求如何穿过智能体直至返回经过验证的答案。

试想一下，OpenAI 的一位工程师或市场人员需要快速获取答案。他们打开 Slack，用日常英语提出疑问。片刻之后，智能体回复了答案、执行的 SQL 以及使用的表。这就是 OpenAI 的数据智能体。

该智能体覆盖了整个数据平台，用自然语言回答问题。用户可以在 Slack 中提问，也可以在 Web 门户、IDE 中，或通过 MCP 在 Codex CLI 里提问。智能体会识别相关表，编写 SQL，执行查询，检查结果，并返回附带推理过程的答案。

在 90,000 张表上可靠地完成所有这些操作，听起来需要一个复杂的系统。然而，团队的做法与大多数人的预期背道而驰。智能体本身很简单。可靠性源于围绕它的工程工作——在智能体看到问题之前就精心准备正确的上下文。接下来的部分将探讨智能体是如何构建以正确获取这一上下文的。

OpenAI 的架构设计刻意保持简约。在深入架构之前，理解智能体系统背后的基本模式至关重要。

数据智能体的基础模式是一个 LLM 加上一个 Harness。LLM 提供推理能力，Harness 提供工具并将推理转化为行动的智能体循环。

引入 Harness 的原因是，LLM 本身只能预测下一个 token。它虽然知识渊博，但无法执行 SQL 查询，也无法根据结果采取行动。Harness 弥补了这一缺陷：它为模型提供可调用的工具，如数据库查询接口；它组装相关上下文；它将模型置于循环中，使其能够推理、行动、观察结果、再次行动，直至任务完成。

许多智能体系统在此阶段变得复杂，如下图所示。团队可能会增加路由器，将简单问题交给小而便宜的模型，将难题交给大模型；可能会混用多个 LLM，在内部数据上微调模型，或者为不同内容类型搭建不同的嵌入模型和复杂的检索管道。每个选择都有帮助，但每个选择也增加了成本、延迟和更多的故障点。

OpenAI 数据团队另辟蹊径。他们发现，在强大且统一的数据平台基础之上，简单的架构在自身规模下运转良好。他们开发的数据智能体由四个主要组件构成：一个 LLM、一个上下文组装层、一套精心筛选的工具，以及一个智能体运行时。

LLM。数据智能体使用 GPT-5.5 作为每个请求的基础模型。团队依赖该模型来生成正确的 SQL 查询、检查结果、修正查询，并一路推理到经过验证的答案。

运行时。运行时是驱动每个请求的编排器。LLM 单靠自己只会输出文本，因此需要某种东西对其产生的内容采取行动。运行时解析模型的输出，将请求的调用分派给工具，将结果反馈给模型，并重复这个循环——使模型可以推理、行动、观察、再次行动，直到任务完成。

上下文组装。这是真正的工程工作所在。一个强大的模型，如果没有正确的上下文，仍然会给出错误答案。仅凭模式无法区分两张表。例如，两张表可能都有 user_id 列，外观几乎一模一样，但一张包含未登录用户，另一张不包含。仅从模式来看，模型无法判断哪张表回答了问题，于是选错了。

为了构建更丰富的上下文，团队识别了真正能帮助模型决定使用哪些表以及生成什么查询的信号：表的模式以及人们如何查询它、表负责人提供的注释，以及管道代码揭示的表的构建方式。

基于这些信号，智能体依赖六层上下文在用户查询到达时组装正确的上下文：

表使用元数据。表的模式、血缘关系，以及人们历史上如何查询它的记录。并非所有查询都同样有用。来自数据科学家编写的热门仪表盘中的查询排名最高，因为它们往往正确且可复用。一次性的探索性查询排名较低。

人工注释。表负责人编写的精心描述，涵盖业务含义、归属、关键程度，以及无法从模式或历史查询中推断出来的已知注意事项。

Codex 增强。一个每晚运行的 Codex 任务会爬取为每张表生产数据的管道代码。它以 100 到 200 张表为一批运行，每张表耗时 5 到 10 分钟。通过阅读代码，它能捕获表的实际内容、如何派生、数据的新鲜度，以及什么时候应该使用它而不是另一张相似的表。

机构知识。大量关于公司数据的上下文并不在数仓中，而是在 Slack 讨论串、Google Docs 和 Notion 页面里。这些文档被单独摄入和嵌入，并通过一个带权限控制的检索服务提供，因此智能体永远不会展示用户无权查看的文档。

记忆。智能体从之前的对话中保存下来的修正和经验，范围可是全局的或个人的。

运行时上下文。当离线上下文缺失或过时时，智能体直接查询数仓，还可以与 Airflow 和 Spark 等其他平台系统对话来填补空白。

前三个层级——表使用元数据、人工注释和 Codex 增强——用于描述表。一个每日运行的离线管道将它们合并为每张表的一段描述，嵌入模型将该描述嵌入为一个向量，存储起来用于检索。在运行时，当问题到来时，描述与问题最匹配的表被检索出来，纳入上下文。

记忆是上下文的另一个