摘要
1) 一句话总结 OpenAI 构建了一套专用的内部 AI 数据智能体，结合多层上下文架构与自学习机制，使员工能够在庞大且复杂的数据生态中快速、安全地完成端到端的数据分析与推理。
2) 核心要点
- 应用规模与成效：该智能体服务于内部 3,500 多名用户，覆盖 600 PB 数据和 70,000 个数据集，将数据提取与分析的耗时从数天缩短至数分钟。
- 底层技术栈：使用 OpenAI 标准工具构建，包括 Codex、GPT-5 旗舰模型、Evals API 以及 Embeddings API。
- 自主闭环推理：智能体能端到端完成分析，若中间结果异常（如 join 导致结果为 0 行），它会主动调查原因、调整策略并重试，无需人类手动干预。
- 六层上下文架构：为确保准确性，系统构建了 6 层上下文：元数据锚定、历史查询推断、人工语义描述、代码推导定义、公司知识库与记忆（通过 RAG 接入 Slack/Docs/Notion）、以及运行时实时查询。
- 代码级上下文：通过 Codex 抓取代码库（如 Spark、Python 流水线逻辑），智能体能理解数据的真实构建方式、更新频率和业务意图，这比仅依赖 SQL 或元数据更准确。
- 自学习记忆系统：具备全局与个人记忆功能，能够保存用户的纠正记录、特定过滤条件和业务约束，确保在后续对话中避免重复踩坑。
- 系统化评估（Evals）：通过将生成的 SQL 和数据结果与人工编写的“黄金 SQL”进行对比打分，作为持续运行的单元测试，防止系统在迭代中出现能力退化。
- 安全与权限透传：严格遵循透传（pass-through）访问控制，用户只能查询其原有权限内的表；同时智能体会透明展示推理步骤并链接原始数据以供验证。
3) 风险与不足
- 上下文缺失风险：在缺乏准确上下文的情况下，即使是强大的模型也会给出错误结果（如严重误估用户数量或误解内部术语）。
- 工具冗余导致困惑：早期向智能体暴露完整的工具集时，功能重叠会造成智能体困惑并降低可靠性（后续通过限制和整合工具调用解决）。
- 提示词僵硬风险：过度“规定动作”的提示词容易将智能体引导至错误路径，提供高层指导并依赖模型自身推理的效果更好。
- 能力退化（回归）风险：作为一个持续演化的系统，如果没有紧密的反馈回路和系统化评估，不可避免会发生难以察觉的质量漂移或回归问题。
- 系统出错可能性：智能体仍有犯错的可能，因此必须在回答旁暴露其假设与执行步骤，依赖用户进行最终的检查与验证。
正文
数据驱动着系统如何学习、产品如何演进，以及公司如何做出决策。但要快速、正确、且在充分上下文下拿到答案，往往比它应有的难得多。为了让这一切在 OpenAI 规模增长时变得更容易，我们构建了一套自研、专用的内部 AI 数据智能体，用于在我们自己的平台数据之上进行探索与推理。
我们的智能体是一个只在内部使用的定制工具（并非对外提供的产品），围绕 OpenAI 的数据、权限与工作流专门打造。我们在这篇文章中分享它如何被构建与使用，借此展示 AI 在团队日常工作中能以真实且有影响力的方式提供支持。我们用来构建和运行它的 OpenAI 工具（Codex、GPT‑5 旗舰模型、Evals API 以及 Embeddings API）与我们提供给全球开发者的工具是同一套。
这套数据智能体让员工能在几分钟内从问题走到洞见，而不是花上几天。这把数据提取与细致分析的门槛降低到了几乎所有职能部门，而不再仅限于数据团队。如今，在 OpenAI 的工程、数据科学、市场（Go‑To‑Market）、财务与研究团队中，很多人都依赖它来回答高影响力的数据问题。例如，它能用自然语言的直观形式，帮助评估发布效果、理解业务健康状况。智能体将 Codex 提供的“表级知识”与产品与组织上下文结合起来；并且借助持续学习的记忆系统，它会在每一次对话中变得更好。
在本文中，我们将拆解：为什么我们需要一套专用的 AI 数据智能体；它“带代码的上下文”和自学习机制为什么如此有用；以及我们一路走来的经验教训。
为什么需要定制工具
OpenAI 的数据平台服务于超过 3,500 名内部用户，这些人分布在工程、产品与研究等团队；平台横跨 600 PB 数据、覆盖 70,000 个数据集。在这样的规模下，光是找到正确的表，就可能是分析中最耗时的部分之一。
正如一位内部用户所说：
“我们有很多表长得非常像，我要花大量时间去搞清它们到底有什么不同、该用哪一张。有的包含未登录用户，有的不包含。有的字段重叠；很难判断哪些是什么。”
即使选对了表，得到正确结果依然不容易。分析师需要理解表内数据与表间关系，确保转换与过滤应用正确。很多常见故障模式——多对多 join、过滤下推错误、对 null 处理不当——都可能在无声无息中让结果失真。在 OpenAI 这样的规模下，分析师不应把时间消耗在调试 SQL 语义或查询性能上；他们的注意力应当放在定义指标、验证假设，以及做出数据驱动的决策上。
它是如何工作的
下面我们逐步介绍：这个智能体是什么、它如何组织上下文，以及它如何持续自我改进。
用户可以提出复杂、开放式的问题，这类问题通常需要多轮手工探索才能回答。比如下面这个示例提示词（使用一个测试数据集）：“针对纽约市出租车行程，哪些起点 ZIP 到终点 ZIP 的组合最不可靠——也就是典型行程时间与最差行程时间之间的差距最大——并且这种波动通常发生在什么时候？”
智能体端到端完成分析：从理解问题，到探索数据、运行查询，再到综合并输出结论。
它的一项“超能力”在于如何推理与推进问题。它不会机械地按固定脚本执行，而会评估自己的中间结果。如果某个中间结果看起来不对（例如因为 join 或过滤写错导致结果为 0 行），它会主动调查原因、调整策略并重试。整个过程中它保留完整上下文，并把每一步的学习带到下一步。这种闭环、自学习的过程把迭代负担从用户转移到智能体本身，让结果更快产出，也比纯手工流程更稳定地产出高质量分析。
智能体覆盖了完整的分析工作流：发现数据、运行 SQL、发布笔记本与报告。它理解公司内部知识，能通过网页搜索补充外部信息，并会通过使用与记忆在时间中不断进化。
上下文是一切
高质量的答案依赖于丰富且准确的上下文。缺乏上下文时，即使是很强的模型也会给出错误结果，例如严重误估用户数量，或误解内部术语。
没有记忆的智能体无法有效查询。
智能体的记忆能更快定位正确的表，从而加速查询。
为了避免这些故障模式，智能体围绕多层上下文构建，用来把推理“锚定”在 OpenAI 的数据与组织知识之上。
上下文层（概览）
第 1 层：元数据锚定（Metadata grounding）
- 智能体依赖 schema 元数据（列名与数据类型）来辅助编写 SQL，并利用表血缘（例如上游与下游表之间的关系）来理解不同表之间的关联。
第 2 层：查询推断（Query inference）
- 通过摄入历史查询，智能体能学习如何写出自己的查询，以及哪些表通常会被 join 在一起。
第 3 层：人工整理的语义描述（Curated descriptions）
- 领域专家会为表与列提供整理后的描述，涵盖意图、语义、业务含义以及已知注意事项——这些信息很难仅从 schema 或历史查询中可靠推断出来。
仅靠元数据还不够。要真正区分相似的表，你还需要理解它们是如何被创建、源自何处。
第 4 层：从代码推导的数据定义（Code‑derived context）
- 通过推导表的“代码级定义”，智能体会更深入地理解数据到底包含什么。
- 例如，了解表里存储了什么、它如何从某个分析事件推导出来，可以提供额外信息：值的唯一性、更新频率、数据覆盖范围（例如是否排除某些字段、粒度到什么层级）等。
- 这也能提供更强的使用上下文：不仅看 SQL，还能看到表在 Spark、Python 与其他数据系统中的使用方式。
- 这意味着智能体能够区分“看起来很像但关键差异巨大”的表。比如，它能判断某张表是否只包含第一方的 ChatGPT 流量。这类上下文还会自动刷新，因此无需手工维护也能保持最新。
第 5 层：公司知识库与记忆（Institutional knowledge + Memory）
- 智能体可以访问 Slack、Google Docs 与 Notion，这些载体保存了关键的公司上下文，例如发布信息、可靠性事件、内部代号与工具，以及关键指标的权威定义与计算逻辑。
- 这些文档会被摄入、向量化，并连同元数据与权限一起存储。检索服务会在运行时处理访问控制与缓存，让智能体能高效且安全地拉取相关信息。
- 当智能体收到纠正，或在某些数据问题上发现关键细节时，它会把这些学习保存下来，便于下次复用，并随着用户使用不断提升。
- 因此，后续回答可以从更准确的基线开始，而不是反复踩同样的坑。
- 记忆的目标，是保留并复用那些“不显而易见但对正确性至关重要”的修正、过滤条件与约束——而这些很难仅从其他上下文层推断出来。
- 例如在一个案例里，智能体不知道某个分析实验应该如何过滤（它需要匹配一个在实验 gate 里定义的特定字符串）。这时记忆至关重要：它能让智能体正确过滤，而不是模糊地做字符串匹配。
- 当你给智能体纠正，或它从对话中学到东西时，它会提示你把这条记忆保存起来，供下次使用。
- 用户也可以手动创建与编辑记忆。
- 记忆分为全局与个人两个范围；智能体的工具让编辑非常便捷。
第 6 层：运行时上下文（Runtime context）
- 当某张表缺少先验上下文，或现有信息已过期时，智能体可以对数据仓库发起实时查询，直接检查并查询该表，以验证 schema、实时理解数据并据此响应。
- 必要时，智能体还可以与其他数据平台系统（元数据服务、Airflow、Spark）交互，以获取仓库之外的更广泛数据上下文。
我们每天运行一条离线流水线，把表使用情况、人工注释与 Codex 推导的增强信息聚合为统一的标准化表示。随后，这些增强上下文会通过 OpenAI embeddings API 转换为向量并存储，以便检索。在查询时，智能体不会去扫描原始元数据或日志，而是通过 RAG（检索增强生成） 只拉取最相关的向量化上下文，从而让“理解表”这件事既快又可扩展——即使面对数以万计的表，也能保持可预测且较低的运行时延迟。必要时，运行时查询会直接对数据仓库实时发起。
这些层共同确保智能体的推理扎根于 OpenAI 的数据、代码与组织知识之上，显著减少错误并提升答案质量。
像队友一样思考与工作
当问题足够清晰时，一次性回答当然有效；但大多数问题并非如此。更多情况下，得到正确结果需要来回打磨、不断细化，并在过程中做一些方向修正。
这个智能体的目标是表现得像一个你可以与之共同推理的队友：它是对话式的、随时在线，既能处理快速问答，也能支持迭代式探索。
它会在多轮之间保留完整上下文，因此用户可以追问、调整意图或改变方向，而无需把前置内容重复一遍。如果智能体开始走偏，用户也可以在分析过程中打断并重定向，就像与一个会倾听、而不是只顾向前冲的人类协作者一起工作。
当指令不清晰或不完整时，智能体会主动提出澄清问题；如果没有得到回复，它会用合理的默认值继续推进。例如，用户询问业务增长但没给日期范围时，它可能默认使用最近 7 天或 30 天。这些先验让它既能保持响应与不中断，又能逐步收敛到正确结论。
最终的效果是：当你非常清楚自己要什么时（例如“给我讲讲这张表”），它能做得很好；当你还在探索时（例如“我看到这里在下滑，能按客户类型和时间范围拆一下吗？”），它同样强。
在推行之后，我们观察到用户会反复执行同样的分析来完成例行、重复性工作。为了加速这类任务，智能体的工作流会把重复分析封装成可复用的指令集，例如每周业务报告与表验证等工作流。通过一次性编码上下文与最佳实践，工作流能让重复分析更快、更一致，并在不同用户间保持稳定质量。
快速迭代但不破坏信任
构建一个“始终在线且持续演化”的智能体，意味着质量既可能提升，也同样可能发生漂移。没有紧密的反馈回路，回归问题将不可避免且难以察觉。想在不破坏信任的前提下扩展能力，唯一方式是系统化评估。
它的 Evals 基于一组精心整理的问答对。每个问题都针对我们非常在意的某个关键指标或分析模式，并配套一条人工撰写的“黄金 SQL”，用于产出期望结果。每次 eval，我们会把自然语言问题发送给它的“生成查询”端点，执行生成的 SQL，再把输出与黄金 SQL 的输出进行对比。
评估不依赖简单的字符串匹配。生成 SQL 在语法上可能不同但依然正确；结果集也可能包含额外列而不影响最终答案。为了解决这些情况，我们同时对比 SQL 与最终数据，并将这些信号送入 OpenAI 的 Evals 评分器。评分器会给出最终分数及解释，涵盖正确性与可接受的差异范围。
这些 eval 就像持续运行的单元测试：在开发过程中不断运行，像生产环境里的金丝雀一样尽早发现回归，让我们能在智能体能力扩展时更有信心地迭代。
智能体安全
这套智能体直接接入 OpenAI 既有的安全与访问控制模型。它纯粹作为接口层运行，继承并强制执行同样的权限与护栏来管理 OpenAI 的数据。
智能体的访问严格遵循 pass‑through：用户只能查询自己原本就有权限访问的表。当缺少访问权限时，智能体会提示这一点，或回退到用户有权限访问的替代数据集。
最后，它也以透明为设计目标。像任何系统一样，它可能犯错；因此它会通过在每次回答旁边总结假设与执行步骤来暴露其推理过程。当查询被执行时，它会直接链接到对应结果，方便用户检查原始数据并逐步验证分析过程。
经验教训
从零构建这套智能体让我们得到了一些务实的经验：智能体会如何表现、会卡在哪些地方，以及什么才是真正让它在规模化场景下变得可靠的关键。
早期我们把完整工具集暴露给智能体，很快就碰到了功能重叠带来的问题。对人类而言，这种冗余在手动调用时更直观，也可能对某些特例有帮助；但对智能体来说，它会造成困惑。为了降低歧义并提升可靠性，我们限制并整合了某些工具调用。
我们也发现，过度“规定动作”的提示词会让结果变差。很多问题在分析形态上相似，但细节差异足以让僵硬的指令把智能体带到错误路径。我们转而提供更高层的指导，并让 GPT‑5 的推理来选择合适的执行路径；这让智能体更稳健，也能产出更好的结果。
Schema 与查询历史能描述一张表的形状与使用方式，但它的真实含义存在于生成它的代码里。流水线逻辑承载着假设、时效性保障与业务意图——这些信息不会出现在 SQL 或元数据中。通过用 Codex 爬取代码库，我们的智能体能理解数据集实际如何构建，从而更好地推理每张表真正包含什么。它对“这里有什么”与“我什么时候能用它”的回答，会比仅依赖数仓信号准确得多。
愿景不变，工具迭代
我们会持续改进这套智能体：增强它处理模糊问题的能力，用更强的验证提升可靠性与准确性，并把它更深地融入工作流。我们相信，它应该自然地融入人们已有的工作方式，而不是像一个割裂的独立工具。
尽管我们的工具会持续受益于智能体推理、验证与自我纠错的底层进步，我们团队的使命始终不变：在 OpenAI 的数据生态中，无缝交付快速、可信的数据分析。
相关文档
- GPT-5.1 如何助力 Tolan 构建语音交互 AI；关联理由：延伸思考；说明：两文都强调“分层上下文 + 长期记忆”对 Agent 稳定性的作用，只是应用场景分别是语音交互与企业数据分析。
- 用 Evals 系统化测试 Agent Skills；关联理由：解说；说明：本文将 Evals 作为防回归机制，该文详细展开了 Agent Skills 的评测方法、评分结构与持续回归实践。