走进 OpenAI 内部的数据 agent

作者：Bonnie Xu、Aravind Suresh、Emma Tang

数据驱动着系统如何学习、产品如何演进，以及公司如何做决策。但快速、正确、并带着恰当上下文拿到答案，往往比应有的难度更高。为了让这件事在 OpenAI 规模化的过程中变得更容易，我们构建了属于自己的、定制的内部 AI 数据 agent，用来探索和推理我们自己的数据平台。

我们的 agent 是一个定制的纯内部工具（并非对外产品），专门围绕 OpenAI 的数据、权限和工作流构建。我们之所以展示我们如何构建和使用它，是为了呈现 AI 支持各团队日常工作的真实且有影响力的方式。我们用来构建和运行它的 OpenAI 工具（Codex、我们的 GPT‑5 旗舰模型、Evals API 和 Embeddings API），与我们对所有开发者开放的工具完全一致。

我们的数据 agent 让员工从提出问题到获得洞察只需要几分钟，而不是几天。这降低了获取数据和做细致分析的门槛，不再局限于数据团队。今天，OpenAI 的 Engineering、Data Science、Go-To-Market、Finance 和 Research 等团队都在依靠这个 agent 回答高影响力的数据问题。例如，它可以帮助回答如何评估发布效果、如何理解业务健康状况，而这一切都通过自然语言这种直观的方式完成。这个 agent 把 Codex 驱动的表级知识与产品和组织上下文结合起来。它持续学习的记忆系统意味着它还会随着每一轮交互而不断改进。

图 1

在这篇文章中，我们会拆解为什么我们需要一个定制的 AI 数据 agent、它的代码富化数据上下文和自我学习为何如此有用，以及我们一路走来的经验教训。

为什么我们需要一个定制工具

OpenAI 的数据平台服务着超过 3.5k 名内部用户，覆盖 Engineering、Product 和 Research，横跨 70k 个数据集、超过 600 PB 的数据。在这个体量下，光是找到正确的表，就可能成为分析工作中最耗时的部分之一。

正如一位内部用户所说：

「我们有很多非常相似的表，我花大量时间试图弄清它们有什么区别、该用哪一个。有些包含登出用户，有些不包含。有些字段相互重叠；很难分清哪个是哪个。」

即便选对了表，产出正确的结果也并非易事。分析人员必须对表数据和表间关系进行推理，以确保转换和过滤条件被正确应用。常见的失效模式——多对多连接、过滤条件下推错误、未处理的空值——会在无声中让结果失效。在 OpenAI 的规模下，分析人员不应该把时间耗在调试 SQL 语义或查询性能上：他们的精力应该放在定义指标、验证假设和做出数据驱动的决策上。

图 2

这条 SQL 语句长达 180 多行。很难判断我们连接的表是否正确、查询的列是否正确。

它是如何工作的

让我们走一遍：我们的 agent 是什么、它如何组织上下文，以及它如何持续自我改进。

我们的 agent 由 GPT‑5.2 驱动，专为在 OpenAI 数据平台上做推理而设计。它出现在员工已有的工作场所中：作为 Slack agent、通过 Web 界面、在 IDE 内部、通过 MCP 接入 Codex CLI，以及通过 MCP 连接器直接进入 OpenAI 内部的 ChatGPT 应用。

用户可以提出通常需要多轮人工探索才能回答的复杂、开放式问题。以下面这个使用测试数据集的提示为例：「对于纽约市出租车行程，哪些上车点到下车点的 ZIP 组合最不可靠，也就是典型行程时间与最坏情况之间的差距最大？这种波动又发生在什么时候？」

这个 agent 端到端地处理整个分析过程，从理解问题、探索数据、运行查询，再到综合出结论。

图 4

agent 对该问题的回答。

这个 agent 的超能力之一，在于它推理问题的方式。它不是照着固定脚本执行，而是会评估自己的进展。如果某个中间结果看起来不对（例如，由于错误的连接或过滤导致结果为零行），agent 会去调查出了什么问题，调整自己的方法，然后再试一次。在整个过程中，它保留完整的上下文，并在各个步骤之间把学到的东西带下去。这种闭环的自我学习过程，把迭代工作从用户身上转移到了 agent 自身，从而带来比人工流程更快的速度和持续更高的分析质量。

图 5

agent 为找出最不可靠的纽约市出租车上下车点组合所做的推理。

这个 agent 覆盖了完整的分析工作流：发现数据、运行 SQL、发布 notebook 和报告。它理解公司内部知识，能够联网搜索外部信息，并通过学习使用方式和记忆不断进步。

上下文就是一切

高质量的答案依赖于丰富而准确的上下文。没有上下文，即便很强的模型也可能给出错误的结果，比如大幅误估用户数量，或误解内部术语。

图 6

没有记忆的 agent，无法有效查询。

图 7

agent 的记忆通过定位正确的表来实现更快的查询。

为了避免这些失效模式，agent 围绕多层上下文构建，让它牢牢扎根于 OpenAI 的数据和机构知识之中。

图 8

第 1 层：表的使用情况

元数据锚定： agent 依赖 schema 元数据（列名和数据类型）来指导 SQL 编写，并使用表血缘（例如上下游表关系）来提供不同表之间如何关联的上下文。
查询推断： 摄取历史查询，帮助 agent 理解该如何编写自己的查询，以及哪些表通常会被连接在一起。

第 2 层：人工标注

由领域专家提供的经整理的表与列描述，捕捉那些难以从 schema 或过往查询中推断出来的意图、语义、业务含义和已知注意事项。

光有元数据还不够。要真正区分开这些表，你需要理解它们是如何被创建的、源自何处。

第 3 层：Codex 富化

通过推导出一张表的代码级定义，agent 对数据的真实内容建立起更深入的理解。关于表里存了什么、它是如何从某个分析事件派生出来的细节，提供了额外的信息。例如，它可以给出关于取值唯一性、表数据更新频率、数据范围（比如该表是否排除了某些字段，因而具有何种粒度）等方面的上下文。
它还能通过展示该表在 SQL 之外如何被 Spark、Python 和其他数据系统使用，提供更丰富的使用上下文。
这意味着 agent 能够区分那些看起来相似但在关键之处不同的表。例如，它能判断某张表是否只包含第一方 ChatGPT 流量。这层上下文还会自动刷新，因此无需人工维护就能保持最新。

图 9

第 4 层：机构知识

agent 可以访问 Slack、Google Docs 和 Notion，这些地方沉淀着关键的公司上下文，例如发布活动、可靠性事故、内部代号与工具，以及关键指标的权威定义和计算逻辑。
这些文档被摄取、向量化，并连同元数据与权限一起存储。一个检索服务在运行时处理访问控制和缓存，使 agent 能够高效且安全地拉取这些信息。

图 10

第 5 层：记忆

当 agent 得到纠正，或发现了关于某些数据问题的细微之处时，它能够把这些经验保存下来供下次使用，从而持续与用户一起进步。结果是，未来的回答会从一个更准确的基线出发，而不是反复撞上同样的问题。记忆的目标是保留并复用那些对数据正确性至关重要、却难以仅凭其他层次推断出来的非显而易见的纠正、过滤条件和约束。例如，在某个案例中，agent 不知道该如何针对某个特定的分析实验做过滤（它依赖于匹配一个在实验开关中定义的特定字符串）。在这里，记忆起到了关键作用，确保它能正确过滤，而不是靠模糊的字符串匹配去碰运气。
当你给 agent 一个纠正，或者它从你们的对话中得到一个经验时，它会提示你把这个记忆保存下来供下次使用。记忆也可以由用户手动创建和编辑。记忆分为全局级和个人级两个作用域，agent 的工具让编辑它们变得很容易。

图 11

第 6 层：运行时上下文

当某张表没有既有上下文，或者已有信息已过期时，agent 可以向数据仓库发起实时查询，直接检查和查询这张表。这使它能够验证 schema、实时理解数据，并据此作出回应。
agent 还能根据需要与其他 Data Platform 系统（元数据服务、Airflow、Spark）对话，获取存在于仓库之外的更广泛的数据上下文。

我们运行一条每日离线流水线，把表使用情况、人工标注和 Codex 派生出的富化信息聚合为单一的规范化表示。这些富化后的上下文随后通过 OpenAI Embeddings API 转换为嵌入向量并存储起来以供检索。在查询时，agent 只通过检索增强生成（RAG）拉取最相关的嵌入上下文，而不是扫描原始元数据或日志。这让表的理解即使在数万张表的规模下也快速且可扩展，同时保持运行时延迟可预测且很低。运行时查询会在需要时实时下发到我们的数据仓库。

这些层次合在一起，确保 agent 的推理牢牢扎根于 OpenAI 的数据、代码和机构知识之中，大幅减少错误并提升答案质量。

像队友一样思考和协作

一次性回答在问题清晰时是有效的，但大多数问题并不清晰。更常见的情况是，要得到正确的结果需要反复打磨和若干次方向修正。

这个 agent 被设计成像一个你可以与之推理的队友。它是对话式的、始终在线的，既能处理快速问答，也能支撑迭代式探索。

它跨轮次保留完整的上下文，因此用户可以追问、调整意图或改变方向，而不必把一切重述一遍。如果 agent 开始走上错误的路径，用户可以在分析进行到一半时打断并把它引导回来，就像与一位会倾听而不是埋头往前冲的人类协作者共事一样。

当指令不清楚或不完整时，agent 会主动提出澄清性问题。如果没有得到回应，它会采用合理的默认值继续推进。例如，如果用户询问业务增长却没有指定日期范围，它可能会默认取最近 7 天或 30 天。这些先验让它在保持响应迅速、不阻塞的同时，仍然能收敛到正确的结果。

最终得到的是一个这样的 agent：当你明确知道自己想要什么时（例如「给我讲讲这张表」），它表现出色；当你在探索时（例如「我看到这里有个下滑，能按客户类型和时间段拆解一下吗？」），它也同样强大。

上线之后，我们观察到用户经常为日常重复性工作跑同一批分析。为了加速这一点，agent 的工作流（workflows）把重复出现的分析打包成可复用的指令集。例如每周业务报告和表校验的工作流。通过把上下文和最佳实践一次性编码进去，workflows 简化了重复分析，并确保跨用户的结果保持一致。

图 13

快速迭代而不破坏信任

构建一个始终在线、不断演进的 agent，意味着质量既可能提升，也同样容易漂移。没有紧密的反馈回路，能力回退就不可避免，而且是隐形的。要在不破坏信任的前提下扩展能力，唯一的办法就是系统化的评估。

在这一节中，我们会讨论我们如何利用 OpenAI 的 Evals API 来衡量和保护 agent 的回答质量。

它的 Evals 建立在经过整理的问题-答案对集合之上。每个问题都针对一个我们极度在意其正确性的重要指标或分析模式，并配有一条人工撰写的、能产出预期结果的「golden」SQL 查询。对于每一条 eval，我们把自然语言问题发送到它的查询生成端点，执行生成的 SQL，并把输出与预期 SQL 的结果进行比较。

评估并不依赖朴素的字符串匹配。生成的 SQL 可能在语法上不同却依然正确，结果集也可能包含对答案没有实质影响的多余列。为此，我们同时比较 SQL 和结果数据，并把这些信号输入 OpenAI 的 Evals 打分器（grader）。打分器会产出一个最终分数以及相应的解释，同时兼顾正确性与可接受的差异。

这些 evals 就像是单元测试，在开发过程中持续运行以识别回退，在生产中则充当金丝雀；这让我们能在 agent 能力不断扩展的过程中及早发现问题并自信地迭代。

Agent 的安全

我们的 agent 直接接入 OpenAI 既有的安全和访问控制模型。它纯粹作为一个接口层运行，继承并强制执行治理 OpenAI 数据的同一套权限与护栏。

agent 的所有访问都是严格的透传（pass-through），这意味着用户只能查询他们本就有权限访问的表。当缺少访问权限时，它会明确提示，或回退到用户被授权可用的替代数据集。

最后，它为透明度而构建。像任何系统一样，它也会犯错。它在每个答案旁边通过总结假设和执行步骤来暴露自己的推理过程。当查询被执行时，它会直接链接到底层结果，允许用户检查原始数据并验证分析的每一步。

经验教训

从零开始构建我们的 agent，让我们收获了一些关于 agent 如何表现、在哪里吃力，以及究竟是什么让它们在规模化下可靠的实践教训。

经验 #1：少即是多

早期，我们把完整的工具集都暴露给 agent，很快就遇到了功能重叠的问题。虽然这种冗余在特定定制场景下有帮助，且人类手动调用时更容易分辨，但对 agent 来说却很困惑。为了减少歧义并提升可靠性，我们收窄并合并了某些工具调用。

经验 #2：引导目标，而非路径

我们还发现，过于指令化的提示会降低效果。虽然许多问题共享一个大致的分析形态，但细节差异足够大，以至于僵硬的指令常常把 agent 推向错误的路径。转向更高层的指引，并依靠 GPT‑5 的推理能力去选择合适的执行路径后，agent 变得更稳健，产出的结果也更好。

经验 #3：意义存在于代码之中

Schema 和查询历史描述了一张表的形状与用法，但它真正的意义存在于产出它的代码里。流水线逻辑捕捉了那些永远不会出现在 SQL 或元数据中的假设、新鲜度保证和业务意图。通过用 Codex 爬取代码库，我们的 agent 能理解数据集实际上是如何被构建出来的，并更好地推理每张表究竟包含什么。它在回答「这里面有什么」和「我什么时候可以用它」时，比单靠数据仓库信号要准确得多。

同一个愿景，新的工具

我们正在持续改进我们的 agent：提升它处理模糊问题的能力，用更强的校验提升可靠性和准确性，并把它更深入地集成进工作流。我们相信它应该自然地融入人们本来的工作方式，而不是像一个独立的工具那样存在。

虽然我们的工具会持续受益于 agent 推理、校验和自我纠错等底层能力的进步，但我们团队的使命始终不变：在 OpenAI 的数据生态中，无缝地交付快速、可信的数据分析。