Data Agent 核心目标就是给 AI 提供 Self-learning 环境
仅仅有元数据还不够，要拿到更源头的信息（这个过程中权限逻辑至关重要），Code 是整个过程的通用语言 实时的，真实的，有机的 Context 直接决定 Agent 效果
翻译，整理，微调 by 付子豪（SioFU，AI PM）
数据是系统学习、产品迭代和公司决策的底层动力，但真正把“数据”转化为及时、准确、且具备业务语境的答案，往往是组织中的高摩擦环节。为了解决这一问题，并支撑 OpenAI 的规模化快速发展，我们内部打造了一个专用的 AI Data Agent，用于直接在自有平台上进行推理和探索。
这个 Agent 并不是对外产品，而是一个深度贴合 OpenAI 内部数据结构、权限模型和工作流的定制化工具。我们之所以分享它的构建与使用方式，是为了展示 AI 如何在真实业务环境中，切实提升团队的日常工作效率。我们用来构建和运行该 Agent 的工具（Codex、我们的 GPT-5 旗舰模型、Evals API 以及 Embeddings API）与我们向全球开发者提供的工具完全一致。
通过这个 Data Agent，员工可以在几分钟内从海量数据中获得洞察，而不再依赖漫长的数据需求和分析周期。这种能力被“民主化”到了整个组织，而不只局限于数据团队。如今，OpenAI 内部的 Engineering、Data Science、Go-To-Market、Finance 和 Research 团队都在用它来回答关键业务问题。例如，它可以通过自然语言这种直观的形式，帮助回答如何评估产品发布、以及如何理解业务健康状况等问题。在技术上，该 Agent 将 Codex 驱动的表级理解能力，与产品与组织层面的上下文深度融合；再加上持续学习的记忆系统，使它在每一次使用中都会变得更聪明。
在这篇文章中，我们将分享：为什么我们需要一个定制化的 AI Data Agent，它所具备的代码增强的数据上下文能力(code-enriched data context)和自我学习能力(self-learning)，以及我们在这一过程中学到的经验教训。
OpenAI 的数据平台为超过 3500 名内部用户提供服务，这些用户分布在 Engineering、Product 和 Research 团队中，管理着超过 600 PB 的数据，横跨 7 万个数据集。在这样的规模下，仅仅定位到正确的表，都可能成为分析流程中最耗时的瓶颈。
正如一位内部用户所说：
“我们有很多彼此非常相似的表，我花了大量时间去搞清楚它们之间的差异，以及到底该用哪一个。有些包含已登出用户的数据，有些不包含；有些字段是重叠的，很难判断每个字段具体代表什么。”
即使已经选对了表，想要得到正确的结果依然挑战重重。分析人员需要对表中的数据以及表与表之间的关系进行推理，才能确保转换和过滤被正确地应用。常见的失败模式：例如，多对多 join、过滤条件下推错误、以及未处理的 null 值可能会在不被察觉的情况下让结果失效。在如此规模化的组织中，让高价值人才把时间浪费在 SQL 语义调试和性能问题上，本身就不合理。分析工作的重心，应该回到更高层次的认知活动：指标定义是否合理、假设是否成立、结论是否真正支持决策。
这条 SQL 语句有 180 多行那么长。要判断我们是否在 join 正确的表、以及是否在查询正确的列，并不容易。
接下来我们将系统性地介绍三件事：这个 Data Agent 的定位与能力边界、它如何构建高质量的上下文基础，以及它如何在实际使用中不断自我进化。
这个 AI Data Agent 基于 GPT-5.2 构建，目标不是简单“查数据”，而是在 OpenAI 的数据平台之上进行推理。它被无缝嵌入到员工已有的工作环境中：Slack、Web、IDE、Codex CLI，甚至内部 ChatGPT的应用中——几乎消除了工具切换的成本。
用户可以直接提出高度复杂、探索式的问题，这类问题在传统流程中往往需要多轮 SQL 编写、结果检查和假设修正。举例来说，下面这个 prompt 使用了一个测试数据集：“针对纽约市出租车行程，哪些从上车到下车的 ZIP 编码组合最不可靠，即典型行程时间与最坏情况下行程时间之间的差距最大？这种波动通常发生在什么时候？”
这个 Agent 能够端到端地处理整个分析流程：从理解问题、探索数据、运行查询，到综合分析结论。
可能今天很多 Data Agent 也可以做这样的任务，但是真正拉开差距的是 Data Agent 基于结果反馈的推理和自我校正能力。
它不会机械地按预设流程执行，而是持续校验中间结果的合理性：如果某个中间结果看起来不对（例如，由于错误的 join 或 filter 导致结果为 0 行），Agent 会主动调查根因，调整策略并重新尝试。与此同时在整个过程中，它会保留完整上下文，并将学到的经验在不同步骤之间延续。
在这一过程中，上下文和中间认知被完整保留，并在后续步骤中复用。这种闭环的自学习机制，把原本由人来完成的“反复试错”，内化成 Agent 自身的能力，从而在速度和分析质量上都显著优于人工工作流。
从系统层面看，这个 Agent 覆盖了完整的数据分析生命周期：理解问题 → 发现数据 → 编写并执行 SQL → 综合洞察 → 产出 notebook 与报告。它不仅掌握内部知识，还能调用外部信息源，并通过长期记忆与使用反馈持续进化。
高质量的答案依赖于丰富且准确的上下文。如果缺乏上下文，即便是能力很强的模型，也可能产生错误结果，例如严重高估或低估用户数量，或误解内部术语的含义。
The agent without memory, unable to query effectively.
The agent’s memory enables faster queries by locating the correct tables.
正因如此，这个 Data Agent 的设计核心不是单点智能，而是一套多层上下文体系——通过将模型的推理过程锚定在 OpenAI 的数据事实与组织知识之上，从系统层面规避这些高风险错误。
Layer #1：表的使用(Table Usage)
元数据锚定(MetaData grounding)：该 Agent 依赖 schema 元数据（列名与数据类型）来指导 SQL 编写，并使用表血缘信息（例如上游和下游表关系）来理解不同表之间的关联方式。
查询推断(Query inference)：通过摄入历史查询，Agent 能理解应如何编写查询，以及哪些表通常会被一起 join。
Layer #2：人工标注(Human Annotations)
由领域专家提供的、经过整理的表和列描述，捕捉了这些数据的意图、语义、业务含义，以及那些无法仅从 schema 或历史查询中轻易推断出的已知注意事项。
仅有元数据是不够的，理解数据如何被创建及其来源，才是区分表差异的关键。
Layer #3：Codex 增强(Codex Enrichment)⭐️
通过推导出表的代码级定义，Agent 能建立对表中数据实际内容的更深层理解。
关于表中存储了什么、以及这些数据是如何从分析事件(analytics event)中派生出来的细节，会提供额外信息。例如： 值的唯一性特征 表更新的频率 数据的覆盖范围（例如是否排除了某些字段、粒度到什么级别）
这种增强不仅体现为“能写对 SQL”，还体现为“理解这张表在系统里的真实用途”：它能看到表在 SQL 之外，如何在 Spark、Python 等数据链路中被消费与加工，从而形成更完整的使用语境。
因此，Agent 才能可靠地区分那些表面结构很像、但口径关键差异巨大的表。举例来说，它可以判断某张表是否仅包含第一方的 ChatGPT 流量。并且这层上下文会自动刷新，确保信息实时有效、无需人工维护。
Layer #4：组织知识(Institutional Knowledge)
这一层的目标，是让 Agent 具备“组织语境感知能力”。它可以访问 Slack、Google Docs 和 Notion 等内部知识载体，从中获取那些只存在于组织内部、却对数据理解至关重要的信息——例如产品发布背景、稳定性与可靠性事件、内部代号与工具体系，以及关键业务指标的权威定义与计算口径。
这些文档会被统一提取、转化为 embeddings，并与相应的元数据和权限策略一同存储。在查询时，由专门的检索服务负责访问控制与结果缓存，确保 Agent 在不越权的前提下，高效地调用最相关的组织知识。
Layer #5：记忆(Memory)
当用户纠正了某个结论，或 Agent 在分析过程中发现了关键但隐蔽的约束条件，这些经验不会随着对话结束而丢失，而是被保存下来，成为下一次推理的默认前提。因此，未来的回答将从一个更加准确的起点出发，而不是反复遇到同样的问题。
记忆的目标，是保留并复用那些不直观的修正、过滤条件和约束——这些因素对数据正确性至关重要，但又难以仅从其他上下文层中推断出来。
例如，在某个案例中，Agent 并不知道该如何为某个特定的分析实验做过滤（它依赖于在实验 gate 中定义的某个特定字符串）。在这种情况下，记忆机制至关重要，它确保 Agent 能够正确过滤，而不是模糊地尝试做字符串匹配。
在交互设计上，当用户给出修正，或 Agent 在对话中识别出新的学习点时，它会主动提示是否将该信息保存为记忆；这些记忆也可以由用户手动创建和编辑。
记忆支持全局作用域与个人作用域两种层级，使 Agent 既能积累组织层面的共识，也能适配个人的分析习惯。
Layer #6：运行时上下文(Runtime Context)⭐️
这一层是整个上下文体系的“兜底与校验层”。当某张表缺乏历史上下文，或已有信息已经不再可靠时，Agent 不会依赖猜测，而是直接向数据仓库发起实时查询，对表进行检查与采样。这让它能够即时验证 schema、理解当前数据形态，并据此调整分析策略。
此外，Agent 还可以按需与数据平台中的其他系统协作——例如元数据服务、Airflow 和 Spark——以补齐那些并不直接存在于数据仓库中的运行与生产语境。
在系统实现上，采用了“离线压缩 + 在线检索”的架构：
每天通过离线管道，将表使用情况、专家标注以及 Codex 推导的代码级增强信息整合为统一、规范化的上下文表示；随后使用 Embeddings API 将其转化为向量并存储。
在实际查询时，Agent 通过 RAG 机制只检索最相关的上下文片段，而不是扫描原始元数据或日志，从而在面对数万张表时，仍能保持快速、可扩展且延迟可预测的响应性能。真正需要时，才会触发对数据仓库的实时查询。
通过这套多层上下文体系，Agent 的推理不再依赖猜测或隐式假设，而是始终锚定在 OpenAI 的数据事实、代码语义与组织共识之上，从系统层面大幅降低出错概率，并持续提升输出结果的可靠性与质量。
当问题清晰时，一次提问（one-shot）的答案就能奏效，但大多数问题并不是这样。更常见的情况是：要得到正确结果，需要来回的细化、以及一些过程中的纠偏。
这个 Agent 被构建成一个可以和你一起推理的队友，它是对话式的、始终在线（always-on），既能处理快速回答，也能进行迭代式探索。
最关键的是，它能跨轮保留完整上下文，让用户可以直接追问、改意图、换方向，而不必重复交代背景；并且当它走偏时，用户可以随时打断、重定向——它会像一个真正听得进去的协作者那样调整，而不是机械执行到最后。
为了避免“卡在澄清问题上”，它还具备主动推进机制：当需求不完整时会先问清楚；若用户暂时不回复，它会采用合理默认值继续跑下去（比如默认看近 7 天或 30 天的增长）。这套 priors 的作用是：在不牺牲正确性的前提下，让交互保持顺滑，分析持续收敛。
最终效果是：无论你是明确型需求（“解释这张表”），还是探索型需求（“这里下滑了，能按客户类型×时间拆开吗？”），它都能稳定工作。
上线后，我们又发现一个很真实的现象：大量分析是“重复劳动”。于是引入 workflow，把高频分析固化成可复用的指令集（例如周报、表验证）。把上下文与最佳实践一次性编码进去后，重复分析会更快、更一致，也更不依赖个人经验
一个 always-on、不断学习的 Agent，并不会天然只朝“更好”的方向演进——在缺乏反馈约束时，能力同样可能悄然退化。如果没有一套严格、持续的反馈闭环，质量回退几乎是必然发生、却又最难被发现的问题。想要在规模化能力的同时维持用户信任，系统化评估是唯一可行的路径。
在这一节中，我们将讨论如何利用 OpenAI 的 Evals API 来衡量并保护该 Agent 的响应质量。
评估体系建立在一组精心设计的问题–答案对之上。每个问题都对应一个关键指标或高风险分析模式，并配套一条人工编写的“golden SQL”，作为正确结果的权威参照。评估流程是：将自然语言问题交给 Agent 生成 SQL，执行该 SQL，然后将结果与 golden SQL 的输出进行对比。
这里的关键在于：评估并不等价于简单的字符串比对。SQL 可以在形式上不同但语义正确，结果中也可能包含对结论无影响的冗余列。因此，系统会同时比较生成的 SQL 与最终数据结果，并将这些多维信号交由 Evals grader 进行综合判断。最终输出的不只是一个分数，还有对正确性与“可接受差异”的解释。
这些 eval 的角色，类似于持续运行的单元测试：在开发阶段及时暴露回退（regression），在生产环境中作为金丝雀监控。这让团队能够在 Agent 能力不断扩展的过程中，既跑得快，又不牺牲可靠性。
数据安全依然是 Data Agent 的重中之重，这个 Agent 并没有引入新的权限体系，而是无缝接入 OpenAI 既有的安全与访问控制模型。在系统架构上，它只充当接口层，完整继承并严格执行原有的数据权限与安全护栏。
所有数据访问都是严格的 pass-through：Agent 不会扩大任何权限边界，用户只能查询自己本来就被授权访问的数据表。如果某个请求超出了权限范围，Agent 会明确指出权限不足，或者在可能的情况下自动切换到用户具备访问权限的替代数据源。
在此之上，它在设计上强调透明性。和任何系统一样，它也可能犯错。它会通过在每个答案旁总结假设条件和执行步骤，来暴露自身的推理过程。当查询被执行时，它会直接链接到底层结果，使用户能够检查原始数据，并验证分析中的每一步。
从 0 到 1 构建这个 Agent 的过程，让团队获得了一些洞察：Agent 在真实系统中是如何行动的，它们最容易出错的地方在哪里，以及要让 Agent 在规模化环境中“长期可靠”，真正需要做对的是什么。
Lesson #1: 少即是多(Less is More)
Lesson #2: 告知目标，而非路径(Guide the Goal, Not the Path)
Lesson #3: 意义深藏于代码之中(Meaning Lives in Code)
