夜雨聆风AI Data 内参｜实践解读
来源：OpenAI Engineering Blog
类型：内部实践 / 数据分析 Agent
时间：2026-01-29
不是给数据库套一层聊天框
OpenAI 这篇文章讲的是他们内部自研的数据 Agent。这里的数据 Agent，可以简单理解成一个能帮员工找表、写查询、跑分析、解释结果的 AI 数据分析助手。
先把边界说清楚：这不是一个对外发布的新产品，而是 OpenAI 内部使用的分析工具。它围绕 OpenAI 自己的数据、权限和工作流搭建，用来帮助员工通过自然语言做数据探索和分析。
为什么这篇值得看？
因为 OpenAI 的问题足够典型，也足够大。原文提到，OpenAI 的数据平台服务超过 3500 名内部用户，覆盖工程、产品、研究等团队；数据规模超过 600PB，分布在 7 万个数据集里。
在这个规模下，数据分析的第一难题往往不是“SQL 怎么写”，而是：
到底该用哪张表？
原文里有个内部用户的反馈很具体：很多表看起来相似，但含义不同。有的包含未登录用户，有的不包含；有的字段重叠，但不容易判断每个字段到底代表什么。
这也是很多公司做 AI 问数时容易低估的地方。
给模型一份数据库结构说明，也就是表名、字段名和字段类型，只能告诉它“有哪些数据”。但分析真正要回答的是“这些数据能不能用、该怎么用、哪里不能乱用”。
这中间差了很长一段路。
一条可信分析链路长什么样
如果把 OpenAI 这篇文章压成一张 P0 链路，我会这样看：
这里真正重要的不是入口多，也不是模型强。
真正重要的是：OpenAI 把数据 Agent 当成一个会持续运行、会犯错、需要被验证和运营的系统，而不是一次性的“把问题翻译成 SQL”功能。
为什么只看表结构不够
很多 AI 数据分析方案默认从表结构开始。
表结构说明主要包括表名、字段名、字段类型。它很重要，但它只是最低门槛。
OpenAI 文章里讲了几个常见失败模式：
• 多对多关联：两张表一连，结果行数被放大，指标被算高； • 过滤条件下推错误：过滤条件被放在错误环节，结果口径被带偏； • 空值没处理：字段为空时没有特殊处理，结论被悄悄带偏。
这些问题的共同点是：SQL 能跑，结果也会返回，但答案可能已经错了。
这就是数据分析助手和普通问答助手最大的区别。普通问答错了，用户可能能看出来；数据分析错了，错误往往藏在表关联、过滤条件、指标口径和汇总方式里面。
所以 OpenAI 的核心做法，不是继续往提示词里塞更多说明，而是给数据 Agent 补足“它该怎么理解这些数据”的背景信息。
OpenAI 给它补了六层信息
这篇文章最有价值的部分，是 OpenAI 明确拆出了六层信息来源。
第一层是表使用模式。
数据 Agent 不只看表结构，还会看历史查询。也就是说，它会学习人过去怎么用这些表、哪些表经常连在一起、哪些表更可能是正确入口。
这对分析很关键。因为在真实企业里，表的“正确用法”经常藏在历史 SQL 里，而不是字段名里。
第二层是人工注释。
领域专家会给表和字段补说明，包括业务含义、使用意图、已知限制和注意事项。比如某张表是否包含某类用户，某个字段是否只适合特定场景。
这类信息通常很难从表结构里自动推出来，但它决定了分析结果能不能被信任。
第三层是代码语义。
这是 OpenAI 这篇文章里很有启发的一点：表的真正含义，往往在生成它的代码里。
OpenAI 用 Codex 去理解代码库，提取一张表的用途、粒度、主键、下游使用方式、可替代表、数据新鲜度等信息。这里的 Codex，可以理解为 OpenAI 用来理解和处理代码的 AI 工具。
这件事很关键。因为表名和字段名只能描述结果，代码能告诉你这个结果是怎么来的。
第四层是组织知识。
数据 Agent 可以访问 Slack、Google Docs、Notion 等内部知识源，用来理解发布事件、可靠性事故、内部代号、工具名称，以及核心指标的标准定义和计算逻辑。
这类知识不是传统数据仓库的一部分，但它经常解释“为什么数据突然变了”。比如某个使用量下降，可能不是业务真的下滑，而是某次日志口径或事件采集出现变化。
第五层是记忆。
当用户纠正它，或者它在分析中发现某个不容易看出来的规则，可以提示用户保存为记忆。以后再遇到类似问题，就不用重新从零摸索。
这里的记忆不是随便记聊天记录，而是记那些会影响数据正确性的过滤条件、限制和修正。
第六层是现场校验信息。
如果没有现成信息，或者已有信息可能过期，数据 Agent 可以实时查询数据仓库，也可以访问元数据服务、Airflow、Spark 等数据平台系统。
也就是说，它不是只拿一份静态说明书回答问题，而是必要时现场检查。
代码语义为什么重要
这篇文章里有一句判断很值得单独拎出来：表的意义活在代码里。
这对数据团队很有启发。
很多公司做数据治理时，会优先补字段描述、指标口径和数据目录。这些当然重要，但 OpenAI 的实践提醒我们：如果只看数据仓库里的表，很容易漏掉生产这张表的真实逻辑。
比如：
• 这张表是不是只包含一部分流量； • 这张表多久更新一次； • 主键到底是什么； • 哪些字段是从事件日志里派生出来的； • 下游哪些分析或任务依赖它； • 有没有更适合当前问题的替代表。
这些问题，很多时候不是表结构能回答的，也不是让业务同学补一段描述就够了。
它们在 ETL、Spark、Python、事件处理和指标计算代码里。
所以可信的数据 Agent，不能只连数据仓库。它还要理解“数据是怎么被生产出来的”。
复杂分析要能自己纠偏
OpenAI 文章里用了一个测试数据集问题来展示 Agent 的工作方式：分析纽约出租车行程中，哪些上车到下车 ZIP 区域组合最不稳定，也就是典型耗时和最坏情况耗时差距最大，并判断这种波动在什么时候出现。
这个问题不是查一个数。
它至少要做几件事：
• 找到合适的数据集； • 理解 pickup 和 dropoff ZIP 的含义； • 定义什么叫“典型耗时”和“最坏情况耗时”； • 计算不同 ZIP 组合的差距； • 找出波动最大的组合； • 再解释这种波动什么时候出现。
OpenAI 的数据 Agent 不是固定按一套脚本跑完。原文强调，它会检查自己的中间结果。如果发现结果不对，比如因为表关联或过滤错误导致返回 0 行，它会回头排查问题、调整方法，然后继续尝试。
这就是“可信分析助手”和“SQL 生成器”的区别。
SQL 生成器的目标是把问题翻译成一条查询。分析助手的目标是把问题推进到一个可以被验证的结论。
真正上线后，最怕质量悄悄变差
OpenAI 这篇文章还有一个很重要的部分：持续评测。
这里的评测，指的是用一组标准问题和标准答案，反复检查数据 Agent 的回答有没有变差。OpenAI 原文里提到的 Evals API，可以理解为一套自动化评测工具。
具体做法是：准备一组人工整理的问题和答案。每个问题对应一条人工写好的标准 SQL，也就是他们认为正确的查询逻辑。评测时，先让数据 Agent 根据自然语言问题生成 SQL 并执行，再把结果和标准 SQL 的结果进行比较。
这里还有一个细节很重要：不是简单比较 SQL 字符串是否一模一样。
因为两条 SQL 写法可能不同，但结果一样；结果集也可能多了某些不影响答案的列。OpenAI 的做法是同时比较 SQL 和结果数据，再交给评估器给出最终分数和解释。
这很像给数据 Agent 加一套固定的质检题。
产品继续迭代、模型继续升级、工具继续调整时，这套质检题可以帮助团队及时发现问题。否则你很难知道：这次改动到底让它更强了，还是让某些关键问题悄悄变差了。
权限不是后补项
企业数据 Agent 最容易被忽略的一点，是权限。
OpenAI 的做法很清楚：数据 Agent 只是一个入口层，继承并执行 OpenAI 已有的数据权限和安全规则。
也就是说，用户只能查询自己本来就有权限访问的表。如果没有权限，Agent 要么提示权限不足，要么改用用户有权限的其他数据集。
这点不能妥协。
如果一个数据 Agent 因为“智能”而绕过了原有权限，那它不是提高分析效率，而是在放大数据风险。
OpenAI 还强调透明度：数据 Agent 会说明假设和执行步骤；查询执行后，会链接到底层结果，方便用户检查原始数据和验证过程。
这也是可信分析的基本条件。最终答案不能是一个黑盒。
三个实践教训
OpenAI 最后总结了三个教训，对做企业数据 Agent 很有参考价值。
第一，工具不是越多越好。
他们早期把完整工具集都开放给数据 Agent，结果遇到了功能重叠和选择混乱。后来做法是收窄和合并工具调用，减少歧义，提高可靠性。
这对很多团队是个提醒：给数据 Agent 更多工具，不等于更智能。工具边界不清楚，反而会让它更容易选错路。
第二，指导目标，不要规定死路径。
OpenAI 发现，过于细的提示词会让结果变差。很多分析问题看起来类似，但细节差异很大。如果提示词把路径规定得太死，数据 Agent 反而会被推向错误方向。
更好的做法，是给清楚的目标和约束，让模型自己选择合适的执行路径。
第三，数据意义在代码里。
这是这篇文章最值得反复记住的判断。表结构和历史查询只能描述表的外观和常见用法，代码才记录了数据如何生成、有哪些假设、什么时候更新、适合什么场景。
所以，未来企业级数据 Agent 的底座，可能不是单独的数据目录，而是数据目录、代码库、指标定义、组织知识和现场校验共同组成的分析信息层。
如果你也想做 AI 分析助手，先补这几块地基
1. 先整理高频问题和核心表，不要一开始让数据 Agent 面对全量数据。 2. 给核心表补业务注释，尤其是数据范围、统计口径、已知限制和不能乱用的字段。 3. 把历史 SQL 和表关联模式纳入信息来源，让数据 Agent 学会团队真实的表使用方式。 4. 不只看表结构，还要把生成表的代码、任务依赖和数据新鲜度纳入语义来源。 5. 建一套持续评测题，用标准 SQL 和结果对比，及时发现“越改越差”的问题。 6. 权限必须继承现有数据权限体系，不能让 Agent 成为越权访问的捷径。
最后
OpenAI 这篇文章给出的信号很明确：
可信的 AI 数据分析，不能只靠表结构和提示词，而要靠数据理解、执行校验、权限控制和持续评测一起托底。
模型能力会继续变强，但企业分析场景里，真正决定数据 Agent 能不能落地的，往往不是它会不会写 SQL，而是它能不能知道自己该查什么、为什么这么查、哪里可能错，以及错了以后怎么被发现。
这才是 AI 数据 Agent 从演示走向生产的分水岭。
如果你也在关注 AI 问数、语义层、数据 Agent 和企业级数据分析工作流，可以关注「AI Data 内参」。
我会持续拆解一手论文、产品文档和真实工程实践，不追热点，重点看三件事：
1. 这件事对数据分析和数据工程有什么实际影响； 2. 它离生产落地还有多远； 3. DA 和 DE 可以从里面借鉴什么。
下一篇会继续看：为什么复杂问数不能只生成一条 SQL，而要拆成一套能检查、能复用的分析步骤。
参考资料
• Bonnie Xu, Aravind Suresh, Emma Tang. Inside OpenAI's in-house data agent. OpenAI Engineering Blog. 2026-01-29. https://openai.com/index/inside-our-in-house-data-agent/
