本文整理自 OpenAI 工程博客原文：深入了解 OpenAI 的内部数据智能体。

数据为系统如何学习、产品如何演进以及企业如何做出选择提供动力。但要快速、准确地获取答案，并结合相关上下文，往往比想象中更为困难。随着 OpenAI 业务范围的扩展，为了简化这项工作，我们建立了专属定制内部 AI 数据智能体，通过 OpenAI 的平台进行探索和推理。

我们的智能体是一款定制内部专用工具（非外部产品），围绕 OpenAI 的数据、权限和工作流而构建。我们将展示 OpenAI 如何构建和使用这一工具，以帮助大家了解 AI 如何以切实可行的方式，支持团队完成日常工作。我们用于构建和运行这一智能体的 OpenAI 工具（Codex、我们的 GPT‑5 旗舰模型、Evals API 和 Embeddings API）与我们面向全球各地开发人员提供的工具相同。

我们的数据智能体可支持员工在几分钟（而非几天）内从问题中提取洞察数据。这降低了所有职能部门（而不仅仅是我们的数据团队）提取数据和进行细致分析的门槛。如今，OpenAI 的工程、数据科学、市场进入、财务和研究团队都依赖智能体来解答高价值数据问题。例如，它可以通过直观的自然语言格式，回答如何评估发布流程和理解业务运行状况等问题。该智能体结合了 Codex 驱动的表格级知识，以及产品和组织的背景信息。其持续学习记忆系统意味着它能够不断优化。

屏幕截图显示用户在 2025 年 10 月 6 日询问 ChatGPT 周活跃用户 (WAU) 数据，并与 DevDay 2023 期间的数据进行比较。智能体报告称，2025 年的 WAU 约为 8 亿，2023 年的 WAU 约为 1 亿，备注信息表明变化幅度超过 7 亿，增长约 8 倍，随后还附上说明背景信息。

在这篇文章中，我们将深入分析为什么我们需要定制 AI 数据智能体，代码增强型数据上下文和自学习功能为何如此重要，以及我们在此过程中汲取的经验教训。

为什么我们需要定制工具

OpenAI 的数据平台为工程、产品和研究部门的3,500 多名内部用户提供服务，涵盖70,000 个数据集中超过600 PB 的数据。在此规模下，寻找合适的表格可能是分析过程中最耗时的环节之一。

正如一位内部用户所解释的：

"我们有很多非常相似的表格，我曾耗费大量时间去厘清它们的不同之处，以及具体应选择哪一个表格。有的表格包括已注销用户，有的则不包括这些用户。有的表格存在重叠字段，很难分辨具体内容。"

即使选择了正确的表格，生成正确的结果也并非易事。分析师必须对表格数据和表格关系进行推理，以确保正确应用转换和筛选功能。常见的故障模式 — 多对多连接、筛选条件下推错误和未处理的空值，都可能会在不知不觉中输出无效结果。鉴于 OpenAI 庞大的组织架构，分析师不应将时间浪费在调试 SQL 语义或查询性能上：他们的重点应放在定义指标、验证假设和制定数据驱动的决策。

这条 SQL 语句长达 180 多行。要确认我们是否连接正确的表格并查询相关列，并非易事。

工作原理

让我们逐步了解 OpenAI 的智能体及其如何整理上下文并不断自我完善。

我们的智能体由 GPT‑5.2 驱动，旨在通过 OpenAI 的数据平台进行推理。无论员工在何处办公，都可以使用这一工具：它能够充当 Slack 智能体、通过 Web 界面、嵌入集成开发环境 (IDE)、经由 MCP 连接的 Codex CLI 以及直接通过 MCP 连接器在 OpenAI 的内部 ChatGPT 应用中调用。

标题为"数据智能体运作原理"的图表。Agent-UI、Local Agent-MCP、Remote Agent-MCP 和 Slack Agent 等入口点均已输入到 Agent-API。API 可连接内部数据知识和企业背景信息，与数据仓库和平台源同步，并通过 Agent-MCP 与 GPT-5.2 模型交换请求。

用户可以提出复杂的开放式问题，这通常需要多轮人工探索。以使用测试数据集的提示为例：

"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 的数据和机构知识为基础。

标题为"数据智能体上下文层级"的图表，展示了六个堆叠层级：1) 表格使用情况，2) 人工注释，3) Codex 增强，4) 机构知识，5) 记忆和 6) 运行时上下文。每一层都以金字塔形状的条形图显示。

第 1 层：表格使用情况

• 元数据基础： 智能体依赖模式元数据（列名和数据类型）来指导 SQL 编写，并使用表格沿袭（例如，上游和下游表格关系）来理解不同表格之间的上下文。
• 查询推理： 采集历史查询有助于智能体理解如何编写查询，以及哪些表格通常相互关联。

第 2 层：人工注释

• 精选描述： 由领域专家精心整理的表格和列相关描述，用于记录意图、语义、业务含义，以及无法从模式或过往查询中轻易推断的已知注意事项。

仅靠元数据是不够的。要真正区分表格，你需要了解其创建方式及来源。

第 3 层：Codex 增强

• 通过推导表格的代码级定义，智能体能够更深入地理解数据的实际内容。
  • 关于表格中存储的内容以及如何根据分析事件中得出的细微差别提供额外的信息。例如，它可以提供关于值的唯一性、表格数据更新频率、数据范围（例如，如果表格排除某些字段，即标识其具备相应的粒度级别）等上下文。
• 通过展示如何在 Spark、Python 和其他数据系统中使用 SQL 以外的表格，提供更丰富的使用情况上下文。
• 这意味着，智能体可以区分内容相似但存在关键差异的表格。例如，它可以判断某个表格是否仅包含第一方 ChatGPT 流量。该上下文还会自动刷新，因此无需手动维护即可保持更新。

标题为"Codex 增强知识管道"的图表。主流表格已应用于多个 Codex 任务，这些任务从 OpenAI 代码库中提取细节，包括表格的用途、粒度和主键、下游使用模式、替代表格选项以及数据新鲜度。

第 4 层：机构知识

• 智能体可以访问 Slack、Google Docs 和 Notion，这些平台可记录关键的企业背景信息，例如产品发布、可靠性事件、内部代号和工具，以及关键指标的规范定义和计算逻辑。
• 这些文档会被采集、嵌入，并与元数据和权限一起存储。检索服务可在运行时处理访问控制和缓存，支持智能体高效且安全地获取这些信息。

用户询问连接器的使用量为何在 12 月呈现下滑趋势的屏幕截图。智能体解释称，使用量下降的原因是 2025 年 11 月 13 日出现的日志问题，导致 ChatGPT 5.1 发布后的使用量被低估。传统的遥测技术一直处于空白状态，直到更新的事件成为可信数据源。

第 5 层：记忆

• 当智能体收到更正信息或发现某些数据问题存在细微差别时，它能够保存这些学习结果以供后续使用，从而在与用户交互的过程中持续改进。
  • 因此，未来的答案将以更准确的基线为切入点，而非反复处理相同的问题。
  • 记忆的目标是保留并复用那些不易察觉的更正信息、过滤条件和约束限制，这些内容对于维持数据的正确性至关重要，但仅凭其他层级难以有效推断。
  • 例如，在某个案例中，智能体不知道如何筛选特定的分析实验（它需要依赖与实验门中定义的特定字符串进行匹配）。在此过程中，记忆至关重要，因为这一能力可确保智能体正确筛选相关信息，而非盲目尝试进行字符串匹配。
• 当你向智能体提出更正意见，或者当其从对话中查找学习内容时，它会提示你保存记忆，以备后续使用。
  • 用户也可以手动创建和编辑记忆。
  • 记忆的范围涵盖全局和个人层面，而智能体所配备的工具将简化编辑流程。

通知横幅显示"数据智能体希望将 2 条学习内容保存到其记忆中"，其中一个标注项为"ChatGPT 顶级指标"，右侧的确认消息显示"已保存到全局记忆"字样，且包含绿色复选标记。

第 6 层：运行时上下文

• 如果表格缺乏先前的上下文或现有信息过时，智能体可以向数据仓库发起实时查询，以直接检查和查询该表格。这使其能够验证模式、实时理解数据，并做出相应的回复。
• 该智能体还能根据需要与其他数据平台系统（元数据服务、Airflow、Spark）进行对话，以获取数据仓库之外更广泛的数据上下文。

我们运行每日离线管道，将表格使用情况、人工注释和 Codex 衍生的增强内容聚合成单一、规范化的表示形式。然后，使用 OpenAI embeddings API 将这些丰富的上下文转换为嵌入并存储以供检索。在查询时，智能体通过 检索增强生成 (RAG) 仅提取最相关的嵌入上下文，而不是扫描原始元数据或日志。这使得表格理解快速且可扩展，即使跨越数万个表格，也能保持运行时延迟的可预测性和低水平。运行时查询会根据需要实时发送到我们的数据仓库。

标题为"数据智能体中的上下文检索"的图表。离线预处理层包括表格使用情况、人工注释、Codex 增强、机构知识和记忆，这些信息均已输入到 RAG 嵌入中。实时检索表明智能体可通过语义搜索或精确文本检索功能来查询数据库，以生成运行时上下文。

这些层共同确保智能体的推理基于 OpenAI 的数据、代码和机构知识，大幅减少错误并提高答案质量。

像团队成员一样思考和协作

当问题清晰时，一次性答案有效，但大多数问题并非如此。通常，要得出正确结果需要反复推敲和某些方向调整。

智能体被设计为像一个可以与你交流的团队成员。它是对话式的、始终在线的，可以处理快速答案和迭代探索。

它在多轮之间保留完整的上下文，因此用户可以提出后续问题、调整意图或更改方向，而无需重复所有内容。如果智能体开始朝错误的方向发展，用户可以在分析过程中中断并重定向它，就像与一个倾听而非继续推进的人类合作者一样工作。

当指令不清晰或不完整时，智能体会主动提出澄清问题。如果没有提供回复，它会应用合理的默认值以继续进行。例如，如果用户询问业务增长但未指定日期范围，它可能会假设最近七天或30天。这些先验知识使其能够保持响应和非阻塞，同时仍能收敛到正确的结果。

因此，该智能体在当你确切知道自己想要什么（例如，"告诉我关于这个表的信息"）和同样强大当你正在探索（例如，"我在这里看到下降，我们可以按客户类型和时间范围分解吗？"）时都能很好地工作。

在推出后，我们观察到用户经常为常规重复工作运行相同的分析。为了加快这一过程，智能体的工作流程将重复分析打包成可重用的指令集。示例包括每周业务报告和表格验证的工作流程。通过一次编码上下文和最佳实践，工作流程简化了重复分析，并确保用户之间的结果一致。

包含"提出数据问题"字样占位符的用户界面 (UI) 输入栏。输入栏下方是标注"使用工作流"字样的按钮，右侧为麦克风和发送图标。该条形图采用圆角设计，且置于深色背景之上。

在快速迭代的同时保持信任

构建一个始终在线、不断发展的智能体意味着质量可能像改进一样容易漂移。如果没有紧密的反馈循环，回归是不可避免的且不可见的。在不破坏信任的情况下扩展能力的唯一途径是通过系统性评估。

在本节中，我们将讨论如何利用 OpenAI 的 Evals API 来衡量和保护智能体的响应质量。

其评估基于精心挑选的问答对集。每个问题针对我们在正确性方面非常关心的重要指标或分析模式，配有手动编写的"黄金"SQL 查询，该查询产生预期结果。对于每次评估，我们将自然语言问题发送到其查询生成端点，执行生成的 SQL，并将输出与预期 SQL 的结果进行比较。

标题为"数据智能体评估管道"的图表。问答评估与预期的 SQL 同步输入到生成步骤，用于生成 SQL 和结果。OpenAI Evals 使用 dataframe 和 SQL 比较功能，比对生成的结果与预期结果，并输出评分和推理。

评估不依赖于简单的字符串匹配。生成的 SQL 在语法上可能不同但仍然是正确的，并且结果集可能包含不会实质性影响答案的额外列。为了考虑到这一点，我们比较 SQL 和结果数据，并将这些信号输入到 OpenAI 的 Evals 评分器中。评分器产生最终分数和解释，捕获正确性和可接受的变化。

这些评估就像单元测试，在开发期间持续运行以识别回归，就像生产环境中的金丝雀一样；这使我们能够及早发现问题，并在智能体能力扩展时自信地进行迭代。

智能体安全

我们的智能体直接接入 OpenAI 现有的安全和访问控制模型。它纯粹作为接口层运行，继承和执行管理 OpenAI 数据的相同权限和护栏。

智能体的所有访问都是严格的透传，这意味着用户只能查询他们已经有权访问的表格。当访问缺失时，它会标记这一点或回退到用户被授权使用的替代数据集。

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

经验教训

从零开始构建我们的智能体揭示了一些关于智能体如何行为、它们在哪些方面挣扎以及什么实际上使它们在规模上可靠的实用经验教训。

经验教训 #1：少即是多

早期，我们将完整的工具集暴露给智能体，很快遇到了功能重叠的问题。虽然这种冗余对于特定自定义情况可能很有帮助，并且在手动调用时对人类来说更明显，但它对智能体来说很困惑。为了减少歧义并提高可靠性，我们限制和合并了某些工具调用。

经验教训 #2：指导目标而非路径

我们还发现，高度规定性的提示会降低结果质量。虽然许多问题具有通用分析形状，但细节差异足以使刚性指令经常将智能体推向错误的路径。通过转向更高级别的指导并依靠 GPT‑5 的推理来选择适当的执行路径，智能体变得更加稳健并产生更好的结果。

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

模式和查询历史描述了表格的形状和用法，但其真正的意义存在于产生它的代码中。管道逻辑捕获了假设、新鲜度保证和业务意图，这些永远不会在 SQL 或元数据中体现。通过使用 Codex 爬取代码库，我们的智能体理解了数据集的实际构建方式，并能够更好地推理每个表格实际包含的内容。它可以比仅从仓库信号更准确地回答"这里有什么"和"什么时候可以使用它"。

愿景不变，工具更新

我们不断努力改进我们的智能体，通过提高其处理歧义问题的能力，通过更强的验证提高其可靠性和准确性，并将其更深入地集成到工作流程中。我们相信它应该自然地融合到人们已经工作的方式中，而不是像一个单独的工具一样运作。

虽然我们的工具将继续受益于智能体推理、验证和自纠错的底层改进，但我们团队的使命保持不变：在 OpenAI 的数据生态系统中无缝交付快速、值得信赖的数据分析。

作者

Bonnie Xu、Aravind Suresh、Emma Tang

致谢

特别鸣谢数据生产力和数据科学团队，以及众多跨职能用户的实验和反馈。

继续阅读

• 从模型到智能体：为 Responses API 配备计算机环境 - 工程 - 2026年3月11日
• 超越速率限制：扩大 Codex 和 Sora 的访问规模 - 工程 - 2026年2月13日
• 工程技术：在智能体优先的世界中利用 Codex - 工程 - 2026年2月11日

1. 如何编写博客

这个仓库的博客文件需要放在 src/content/blog 目录下，可以是 markdown 文件，也可以是 mdx 文件。

有以下这些元数据需要用户自行根据需要进行配置：

• title: 博客标题
• date: 博客发布日期
• updated: 博客更新日期
• keywords: 博客关键词，优化 SEO
• featured: 是否放在首页
• summary: 博客摘要

2. 博客配置

博客的所有配置都集中在 src/lib/config.ts 文件中，这样做的好处是：

1. 集中管理：所有配置都在一个文件中，方便维护和修改
2. 类型安全：使用 TypeScript 可以获得类型检查和自动补全
3. 复用性：避免重复的配置散落在各个文件中
4. 一致性：确保所有地方使用相同的配置值

2.1 站点基本配置

site: {
  title: "你的博客标题",
  name: "你的博客名称",
  description: "博客描述",
  keywords: ["关键词1", "关键词2"],
  url: "https://你的域名.com",
  baseUrl: "https://你的域名.com",
  image: "https://你的域名.com/og-image.png",
  favicon: {
    ico: "/favicon.ico",
    png: "/favicon.png",
    svg: "/favicon.svg",
    appleTouchIcon: "/favicon.png",
  },
  manifest: "/site.webmanifest",
}

这些配置用于：

• 网站的基本信息展示
• SEO 优化
• 浏览器标签页图标
• 社交媒体分享预览

2.2 作者信息配置

author: {
  name: "你的名字",
  email: "你的邮箱",
  bio: "个人简介",
}

作者信息会用于：

• 首页展示
• RSS 订阅源信息
• 博客文章的作者信息

2.3 社交媒体配置

social: {
  github: "https://github.com/你的用户名",
  x: "https://x.com/你的用户名",
  xiaohongshu: "https://www.xiaohongshu.com/user/profile/你的ID",
  wechat: "你的微信二维码图片链接",
  buyMeACoffee: "https://www.buymeacoffee.com/你的用户名",
}

这些链接会显示在：

• 首页的社交媒体链接区域
• 导航栏的社交媒体图标

2.4 评论系统配置

giscus: {
  repo: "你的GitHub仓库名",
  repoId: "仓库ID",
  categoryId: "分类ID",
}

使用 Giscus 作为评论系统，需要：

1. 在 GitHub 上安装 Giscus 应用
2. 在你的仓库中启用 Discussions
3. 获取配置信息并填入这里

2.5 导航菜单配置

navigation: {
  main: [
    { 
      title: "文章", 
      href: "/blog",
    },
    // 可以添加更多导航项
  ],
}

这里配置网站的导航菜单，支持：

• 普通链接
• 带子菜单的下拉菜单

2.6 SEO 配置

seo: {
  metadataBase: new URL("https://你的域名.com"),
  alternates: {
    canonical: './',
  },
  openGraph: {
    type: "website" as const,
    locale: "zh_CN",
  },
  twitter: {
    card: "summary_large_image" as const,
    creator: "@你的推特用户名",
  },
}

这些配置用于：

• 搜索引擎优化
• 社交媒体分享卡片
• 网站元数据

2.7 RSS 订阅配置

rss: {
  title: "你的博客标题",
  description: "博客描述",
  feedLinks: {
    rss2: "/rss.xml",
    json: "/feed.json",
    atom: "/atom.xml",
  },
}

这些配置用于生成：

• RSS 2.0 订阅源
• JSON Feed
• Atom 订阅源

3. 如何修改配置

1. 打开 src/lib/config.ts 文件
2. 根据你的需求修改相应的配置项
3. 保存文件后，Next.js 会自动重新构建并应用新的配置

注意事项：

• 确保所有 URL 都是有效的
• 图片链接应该是可访问的
• 社交媒体链接要填写完整的 URL
• 配置修改后，建议检查网站的：
  • 首页展示
  • 导航菜单
  • SEO 信息
  • 社交媒体分享效果
  • RSS 订阅源

4. 如何生成 RSS 订阅源

修改 scripts/generate-rss.js 文件中的配置，然后运行：

npm run generate-rss

5. 如何生成 Sitemap

修改 scripts/generate-sitemap.js 文件中的配置，然后运行：

npm run generate-sitemap

在markdown里可以使用 \ 对特殊符号进行转义。

1. 标题

语法

# This is an <h1> tag
## This is an <h2> tag
### This is an <h3> tag
#### This is an <h4> tag

实例

This is an h1 tag

This is an h2 tag

This is an h3 tag

This is an h4 tag

2. 强调和斜体

语法

*This text will be italic*
_This will also be italic_

**This text will be bold**
__This will also be bold__

实例

This text will be italic This will also be italic

This text will be bold This will also be bold

3. 有序列表和无序列表

语法

* Item 1
* Item 2
* Item 3

1. Item 1
2. Item 2
3. Item 3

实例

• Item 1
• Item 2
• Item 3

1. Item 1
2. Item 2
3. Item 3

4. 图片

语法

![img-name](img-url)

实例

5. 超链接

语法

[link-name](link-url)

实例

微信公众号链接

6. 引用

语法

> 引用本意是引用别人的话之类  

实例

If you please draw me a sheep!
不想当将军的士兵, 不是好士兵.

7. 单行代码

语法

`This is an inline code.`

实例

同样的单行代码, 我经常用来显示特殊名词

8. 多行代码

语法

​```js
for (var i=0; i<100; i++) {
    console.log("hello world" + i);
}
​```

实例

for (var i=0; i<100; i++) {
    console.log("hello world" + i);
}

也可以通过缩进来显示代码, 下面是示例:

console.loe("Hello_World");

9. 表格

Table

参考链接

• https://guides.github.com/features/mastering-markdown/
• https://help.github.com/articles/basic-writing-and-formatting-syntax/