OpenAI 最近公开介绍了一个内部使用的数据智能体。它不是面向外部销售的产品，而是 OpenAI 为自身数据、权限和工作流定制的内部工具。

这篇文章的核心不是“用自然语言写 SQL”这么简单，而是展示了一套企业级数据智能体如何真正进入日常工作：它要理解业务问题，找到正确数据源，生成查询，执行分析，解释结果，还要在权限、安全、评估和记忆系统的约束下持续改进。

OpenAI 提到，用来构建和运行这个系统的能力，包括 Codex、GPT-5 系列模型、Evals API 和 Embeddings API。这些并不是内部特供能力，而是开发者也能使用的同类平台组件。

图源：OpenAI 原文。示例中，用户用自然语言询问 ChatGPT 周活跃用户数据，并让智能体和 DevDay 2023 时的数据做比较。

为什么需要一个内部数据智能体

数据驱动着产品迭代、系统学习和业务决策。但在组织变大之后，想快速得到可靠答案会越来越难。

一个看似简单的问题，背后往往有几层隐性成本：

传统流程通常需要业务同事找数据团队，数据团队再理解问题、找表、写 SQL、跑分析、解释结果。这个流程可靠，但对探索性问题来说很慢。

OpenAI 的目标是让员工在几分钟内从问题走到洞察，而不是等待几天。这个能力不只服务数据团队，也服务工程、数据科学、市场、财务和研究等团队。

它不是简单的 Text-to-SQL

很多数据问答系统会停在“自然语言转 SQL”。OpenAI 的内部数据智能体显然走得更远。

它需要做的事情包括：

图源：OpenAI 原文。示例展示智能体生成 SQL，并通过 CTE、字段派生和聚合来完成分析。

这意味着，数据智能体必须同时具备“数据目录”“分析助理”“查询执行器”“结果解释器”和“知识沉淀系统”的能力。

系统如何工作

OpenAI 把这个数据智能体放在多个入口后面：可以通过 Agent UI 使用，也可以通过本地 Agent-MCP、远程 Agent-MCP、Slack Agent 等方式接入。

这些入口最终连接到 Agent API。Agent API 再把请求发给模型，并连接内部数据知识、企业背景、数据仓库和平台数据源。

图源：OpenAI 原文。图中展示了 Agent UI、MCP、Slack 等入口如何连接 Agent API、数据知识和模型。

这个架构的重点在于：模型并不是孤立回答。它需要通过工具访问数据，需要通过知识系统理解表和业务上下文，也需要在组织权限边界内执行。

一个出租车数据分析例子

原文用了纽约出租车数据作为例子：用户想知道哪些上车和下车 ZIP 组合最“不可靠”。

这个问题并不是简单求平均值。智能体需要先定义“不可靠”是什么意思。示例里，它用典型情况和较差情况之间的差距来衡量，例如比较 p50 和 p95 行程时长，从而找出波动特别大的路线组合。

图源：OpenAI 原文。示例中，智能体解释了如何定义“典型情况”和“最坏情况”，并基于样本进行分析。

从这个例子可以看到，数据智能体不仅要会查数，还要会把模糊业务问题转成可计算的问题。

它会先规划分析目标，再检查可用表结构，生成 SQL，计算指标，并解释筛选条件。也就是说，分析过程本身是可追踪的。

图源：OpenAI 原文。图中展示了智能体在分析纽约出租车数据时的计划、表检查、代码片段和推理过程。

为什么“上下文”是核心

OpenAI 认为，定制数据智能体最关键的能力之一，是让模型拿到足够好的数据上下文。

单靠表名和字段名通常不够。企业数据里有太多历史包袱：

如果智能体不知道这些背景，就很容易查错表、误解字段，或者给出看起来合理但其实不可靠的答案。

OpenAI 把数据上下文分成多个层级：表使用情况、人工注释、Codex 增强、组织知识、记忆，以及运行时上下文。

图源：OpenAI 原文。图中展示数据智能体的上下文层级。

Codex 如何补充表级知识

原文中一个很重要的设计，是用 Codex 去增强表级知识。

Codex 可以检查代码库中表的真实使用方式，从代码中提取信息，例如：

图源：OpenAI 原文。Codex 会围绕核心表运行任务，从代码库中提取用途、粒度、主键、替代表和新鲜度等信息。

这个设计很关键。很多企业数据知识并不在数据仓库本身，而藏在应用代码、数据管道、指标实现和历史分析里。让 Codex 读取这些线索，可以帮助智能体更接近真实工作语境。

更快的查询：从 22 分钟到 1 分钟

原文还展示了一个查询性能例子。

用户询问过去 30 天 ChatGPT Image Gen 登录用户 DAU。没有足够上下文时，智能体可能会写出很慢的查询，长时间等待。

图源：OpenAI 原文。慢查询示例中，智能体运行了 22 分钟以上。

当系统有了更好的表知识、查询模式和上下文后，智能体可以选择更合适的数据源和查询方式。

图源：OpenAI 原文。优化后的查询示例中，运行时间降到约 1 分钟。

这说明上下文不仅影响答案正确性，也直接影响分析效率和成本。

为什么需要组织知识和记忆

有些问题无法只靠数据库回答。用户可能会问：某个指标为什么在某个时间点下降？这类问题往往涉及发布、日志变化、产品事件或组织内部约定。

原文举了连接器使用量下滑的例子。智能体需要知道某个时间点发生过日志问题，知道旧事件和新事件的可信度变化，才能解释趋势变化。

图源：OpenAI 原文。示例中，智能体解释连接器使用量下滑与日志问题、事件口径变化有关。

这种知识很难只靠数据库 schema 表达，所以 OpenAI 引入了组织背景和记忆机制。

记忆不是无条件写入。原文展示的交互里，智能体会提示用户是否将学习内容保存为记忆。被保存的记忆可以在未来类似问题中帮助智能体更快定位背景。

图源：OpenAI 原文。智能体提示保存学习内容到记忆中。

上下文如何被检索出来

OpenAI 的方案不是把所有背景一次性塞进提示词，而是使用检索机制。

离线阶段，系统会把表使用情况、人工注释、Codex 增强知识、组织知识和记忆处理成可检索内容。

实时阶段，当用户提出问题时，智能体会通过语义搜索或精确文本检索查找相关上下文，再把必要信息放入当前任务。

图源：OpenAI 原文。图中展示离线预处理、RAG 嵌入、语义搜索和运行时上下文生成。

这套设计的好处是：智能体可以按需拿上下文，而不是依赖一个巨大、混乱、不可控的全局提示词。

像队友一样协作，而不是只回答问题

OpenAI 强调，这个智能体不只是回答单个问题，而是逐渐成为团队工作流的一部分。

它支持在界面里发起数据问题，也支持工作流入口。员工可以把反复出现的数据任务沉淀成更稳定的流程。

图源：OpenAI 原文。界面中可以直接提出数据问题，也可以使用工作流。

这意味着它不是一个“一次性问答框”，而是一个可以被组织持续使用和改进的分析界面。

评估体系：不能只看回答像不像

数据智能体最危险的问题，是“看起来很合理，但其实错了”。

因此，OpenAI 使用 Evals API 建立评估流程。评估对象不只是最终文本，还包括 SQL、数据结果和预期答案之间的比较。

图源：OpenAI 原文。评估流程会比较生成 SQL、运行结果和预期结果，并输出评分与推理。

这种评估方式比只让人工读回答更可靠。因为数据任务的关键在于：

权限和安全边界

内部数据智能体不能绕过权限。OpenAI 的设计前提是，智能体只能在用户已有权限范围内工作。

这条边界非常重要。否则自然语言入口会变成数据泄露入口。

企业级数据智能体至少要处理几类风险：

OpenAI 的经验教训

从原文看，这个系统的建设经验可以概括成几条：

第一，模型能力重要，但模型本身不够。真正决定效果的是数据上下文、工具链和组织知识。

第二，数据智能体不能只优化“能回答”，还要优化“答得对、查得快、可追踪”。

第三，记忆和反馈机制很关键。一个内部工具如果不能从真实使用中学习，就很难适应组织不断变化的数据口径。

第四，评估必须进入开发闭环。否则系统很容易在演示里好看，在真实场景里失控。

第五，安全和权限不是上线前补丁，而是架构设计的一部分。

对企业落地的启发

这篇文章的价值，不只是 OpenAI 做了一个内部数据工具，而是展示了一个可迁移的企业 Agent 落地范式。

一个真正有用的数据智能体，至少需要五个组件：

对多数企业来说，难点不是“接入一个大模型”，而是把模型接入真实数据工作流。

也就是说，数据智能体不是一个聊天窗口，而是一套围绕数据、权限、知识和评估重构的工作系统。

更现实的判断

数据智能体不会马上替代数据团队。更可能发生的是：数据团队从大量重复性问答中解放出来，把更多时间投入到指标治理、复杂建模、数据质量、关键业务判断和平台建设上。

业务团队也不会因为有了智能体就天然更懂数据。相反，他们需要学会更清楚地提出问题，理解指标假设，并识别哪些答案需要进一步人工确认。

OpenAI 的案例说明，Agent 最先改变的不是“谁被替代”，而是“一个问题从提出到验证的路径”。

过去，一个数据问题可能要先变成工单、需求文档或 SQL。现在，它可以先变成一句自然语言，再由智能体推进到查询、验证和解释。

这就是内部数据智能体最有现实意义的地方。

更多AI最新消息，请关注《派派AI学院》
https://www.pypyai.com/