2026 年，OpenAI 和 Anthropic 分别发布了两篇关于企业 Data Agent 的文章：OpenAI 的 Inside OpenAI’s in-house data agent 和 Anthropic 的 How Anthropic enables self-service data analytics with Claude。两篇文章都在讨论同一个问题：如何让普通员工通过自然语言完成数据发现、查询和分析。但它们给出的答案并不相同。
一句话概括：
OpenAI 关注的是：如何让 Agent 更懂企业数据。
Claude 关注的是：如何让 Agent 更稳定地沿着可信路径使用数据。
前者偏向“上下文增强”，后者偏向“治理闭环”。这正是两种 Data Agent 方法论的核心分野。
目录
- 问题定位与核心关注点
- 架构分层设计
- 数据处理策略
- 流程控制与技能使用
- 评测与验证方法
- 权限与安全管理
- 产品形态与落地策略
- 为什么会产生两种不同方案？
- 核心差异总结
1. 问题定位与核心关注点
OpenAI 的出发点是内部数据规模过大之后，传统分析方式难以支撑业务效率。文章提到，OpenAI 内部数据平台服务超过 3,500 名用户，覆盖 70,000 个数据集和 600PB 以上数据。在这种规模下，难点不只是写 SQL，而是找到正确的表、理解表之间的区别、知道字段真实含义，并在复杂 join、过滤、空值、粒度差异中避免错误。
因此，OpenAI 对问题的定义是：Data Agent 缺少足够上下文，导致它无法真正理解企业数据。
Claude 的问题定位更偏治理。Anthropic 认为，把 Claude 接到数仓并允许它执行 SQL，会制造一种“看起来很精确”的假象。真正的难点不是 SQL 生成，而是用户问题能否被映射到正确、最新、可信的数据实体上。
Claude 总结了三类主要失败模式：概念与实体的歧义、数据过时、检索失败。比如“活跃用户”到底指什么行为、什么时间窗口、是否排除作弊用户，这不是 SQL 技巧问题，而是业务定义问题。
所以 Claude 对问题的定义是：Agent 即使有能力执行查询，也可能走错数据路径。
2. 架构分层设计
OpenAI 的架构核心是多层上下文系统。它把 Data Agent 的上下文分为六层：
- Table Usage：表结构、字段类型、血缘关系、历史查询、常见 join 模式。
- Human Annotations：人工维护的表说明、字段说明、业务语义和使用注意事项。
- Codex Enrichment：通过 Codex 阅读代码、数据管道和转换逻辑，理解数据如何生成。
- Institutional Knowledge：Slack、Google Docs、Notion 等内部知识中的业务背景、事件、指标定义。
- Memory：用户纠错、非显性规则、历史经验和个人偏好。
- Runtime Context：运行时 schema 检查、实时查询、权限检查和数据状态确认。
这套架构的本质，是为 Agent 构建一个“企业数据认知层”。Agent 不只是知道表名和字段名，还要知道数据从哪里来、怎么被生产、什么时候更新、哪些指标有什么特殊口径。
Claude 的架构则是 agentic analytics stack，主要分为四层：
- Data Foundations：规范的数据模型、转换逻辑、测试、数据质量、canonical datasets。
- Sources of Truth：语义层、血缘图、转换图、结构化参考文档、业务上下文。
- Skills：定义 Agent 在不同业务域中的操作顺序、查询路径、回退策略和验证流程。
- Validation：离线评测、ablation、CI、在线验证、provenance 和纠错闭环。
这套架构不是让 Agent 尽可能多地看信息，而是把数据世界治理成 Agent 可以稳定导航的结构。
3. 数据处理策略
OpenAI 的数据处理策略是“补齐上下文”。它认为，企业数据的真实含义往往散落在 schema、历史 SQL、代码、文档、业务事件、用户纠错和运行时状态中。尤其值得注意的是 Codex Enrichment：OpenAI 明确指出，表的真正含义常常存在于生产这张表的代码里，而不是只存在于仓库元数据里。
因此，OpenAI 会通过离线管道把表使用情况、人工注释、代码理解、组织知识和记忆整合成统一的上下文表示，再通过 embeddings 和 RAG 在查询时检索相关信息。
Claude 对“堆上下文”更加谨慎。Anthropic 认为，历史 SQL、旧 dashboard、过期文档和相似表名都可能污染 Agent 的判断。它们不是不能用，但不能直接作为事实来源。Claude 特别强调 canonical datasets 和 semantic layer：当用户问一个指标时，系统应该优先把问题路由到受治理的指标定义，而不是让 Agent 在原始表和历史查询中自由搜索。
这两种策略的区别可以概括为：
| 维度 | OpenAI | Claude |
|---|---|---|
| 数据策略 | 丰富上下文，让 Agent 理解更多 | 治理上下文，让 Agent 使用更准 |
| 历史 SQL | 重要学习材料 | 原材料，需要被蒸馏成结构化参考 |
| 代码作用 | 理解数据生成逻辑 | 与文档、Skill、模型定义共仓库维护 |
| 关键目标 | 提升 Agent 的数据理解能力 | 降低 Agent 选错来源的概率 |
4. 流程控制与技能使用
OpenAI 更强调 Agent 的自主推理能力。文章提到，它不是让 Agent 按固定脚本运行，而是让 Agent 能够评估自己的中间结果。如果某次查询因为 join 或过滤条件导致结果异常，Agent 会检查问题、调整路径并再次尝试。用户也可以在过程中打断、修正或继续追问。
OpenAI 的经验是：不要过度规定路径，而要指导目标。它们发现，过于细致的 prompt 反而会让 Agent 在不同问题中走向错误路径。更有效的做法是给出高层目标，让模型根据上下文和推理能力选择具体执行方式。
Claude 则把流程控制显式化为 Skills。Skill 在 Claude 的方法论里不是普通提示词，而是 Agent 的程序性知识：面对某类分析问题，先查什么、后查什么、什么时候必须使用语义层、什么时候进入参考文档、什么时候回退到原始 SQL、什么时候需要 adversarial review。
Anthropic 提到，没有 Skills 时，Claude 在其内部评测上的准确率不超过 21%；加入 Skills 后，整体准确率稳定超过 95%，某些领域接近 99%。这个数字说明，在企业数据分析场景里，模型能力本身并不等于生产可靠性。流程、路径和领域知识的组织方式，会显著影响最终效果。
5. 评测与验证方法
OpenAI 的评测方式更像查询级单元测试。它使用人工编写的 question-answer eval：给定自然语言问题，Agent 生成 SQL，系统执行 SQL，然后与 golden SQL 及其结果进行比较。它不会简单做字符串匹配，而是同时比较 SQL 语义和查询结果，并用 grader 给出评分和解释。
这种评测适合回答一个问题：Agent 是否能把自然语言问题转成正确查询？
Claude 的评测体系更像生产治理闭环。它包括离线 eval、ablation、线上验证、provenance footer、被动监控和主动纠错采集。Claude 不只关心结果是否正确，还关心答案来自哪一层事实来源、数据是否新鲜、Skill 版本变化是否造成回归、业务域是否达到上线门槛。
尤其值得注意的是 Claude 的 ablation 思路。Anthropic 曾让 Agent 直接访问大量历史 SQL、dashboard 和 notebook，结果准确率提升不到 1 个点。这个实验让他们意识到，瓶颈不在于“信息是否存在”，而在于“问题能否被结构化地路由到正确实体”。
所以两者的评测重点不同：
| 维度 | OpenAI | Claude |
|---|---|---|
| 评测对象 | 单次查询与结果 | 完整分析路径与生产稳定性 |
| 核心问题 | SQL 和结果是否正确 | 来源、路径、版本、验证是否可信 |
| 方法 | Golden SQL、结果比对、Evals API | Offline eval、ablation、CI、online validation |
| 目标 | 提升查询正确率 | 降低生产环境中的系统性错误 |
6. 权限与安全管理
OpenAI 的权限策略是 pass-through permission。Agent 继承现有权限模型，用户只能查询自己本来有权限访问的数据。如果用户没有权限，Agent 会提示权限不足，或者选择用户有权限的替代数据集。
此外，OpenAI 强调透明性。Agent 会总结假设、执行步骤，并链接到底层查询结果，让用户可以检查原始数据和分析过程。
Claude 则在访问控制之外，更强调分析过程中的安全边界。Skill 可以规定高风险问题、敏感数据、PII、受限业务域的处理方式。例如，某些场景下 Agent 不能直接返回结果，只能返回 SQL 让用户自行执行；某些决策类问题只能呈现数据，不能替业务团队下结论。
可以理解为：
OpenAI 解决“用户能不能访问这些数据”。
Claude 解决“Agent 应该如何使用这些数据”。
这两者并不冲突。生产级 Data Agent 应该同时具备底层权限继承和上层流程约束。
7. 产品形态与落地策略
OpenAI 的 Data Agent 更像一个统一的内部数据分析平台。它可以通过 Slack、Web、IDE、Codex CLI、内部 ChatGPT app 等入口使用，覆盖数据发现、SQL 查询、Notebook、报告生成等完整流程。它强调的是让 Agent 融入员工已有工作流，而不是成为一个孤立工具。
Claude 的产品形态更像 Claude Code + Skills + MCP + 语义层 + 数据仓库的组合。它没有把重点放在单一平台，而是强调 Skills 作为可复用、可版本管理、可评测的领域能力载体。一个 Skill 可以被 IDE、Slack、dashboard 工具或独立 Agent 会话共同使用，从而保证不同入口下的分析路径一致。
从落地策略看，OpenAI 更适合先建设一个强大的统一 Data Agent，再逐步增强上下文和记忆；Claude 更适合从重点业务域切入，先治理 canonical datasets、语义层和 Skill，再逐步扩大覆盖面。
8. 为什么会产生两种不同方案？
两种方案的差异，根本上来自它们对失败原因的不同归因。
OpenAI 认为，Data Agent 失败主要是因为“不够懂”。企业数据太复杂，表太多，语义太隐蔽，用户问题又经常带有业务背景。如果 Agent 缺少上下文，就很容易选错表、误解字段、漏掉过滤条件。因此，OpenAI 的自然解法是补上下文、读代码、加记忆、做运行时校验。
Claude 认为，Data Agent 失败主要是因为“走错路”。在企业数据环境中，错误信息和正确信息常常同时存在：旧表、旧指标、旧 dashboard、临时分析、过期 SQL、部门口径差异。Agent 如果自由搜索，很容易找到一个看起来合理但实际错误的路径。因此，Claude 的自然解法是治理数据、建立事实来源、用 Skill 限定路径、用 Validation 持续检查。
这也反映了两家公司产品路线的差异。OpenAI 的文章更像内部系统架构复盘，展示 GPT、Codex、Embeddings、Evals、Memory 如何组合成一个强大的数据智能体。Claude 的文章更像企业落地方法论，展示如何用 Claude Code、Skills、MCP 和验证闭环把自助分析做可靠。
更抽象地说：
OpenAI 把企业数据世界看成一个复杂但可以被理解的知识空间。
Claude 把企业数据世界看成一个容易污染、必须被治理的决策环境。
9. 核心差异总结
| 维度 | OpenAI | Claude |
|---|---|---|
| 核心问题 | Agent 缺少上下文 | Agent 可能走错路径 |
| 基本假设 | 理解充分才能可靠 | 路径可信才能可靠 |
| 架构重点 | 上下文、代码理解、记忆、运行时校验 | 数据治理、语义层、Skills、Validation |
| 数据策略 | 汇聚更多上下文，让 Agent 自主推理 | 建立事实来源，让 Agent 优先走可信路径 |
| 流程控制 | 高层目标引导，减少过度规定 | Skill 明确规定操作顺序和回退策略 |
| 评测方法 | Golden SQL 与结果比对 | Domain eval、ablation、online validation |
| 权限安全 | Pass-through 权限继承 | 权限约束 + Skill 流程边界 |
| 产品形态 | 多入口统一 Data Agent 平台 | Claude Code + Skills + MCP 的工程体系 |
| 方案气质 | 认知增强型 | 治理约束型 |
最终来看，OpenAI 和 Claude 的方案不是互斥关系，而是生产级 Data Agent 的两个必要侧面。
OpenAI 提醒我们：没有足够上下文，Agent 不可能真正理解企业数据。
Claude 提醒我们：只有上下文还不够，Agent 必须沿着可信、可验证、可维护的路径行动。
真正可落地的企业 Data Agent，应该同时吸收两者的方法：
用 OpenAI 的思路增强 Agent 的数据理解能力；用 Claude 的思路约束 Agent 的分析路径和验证闭环。
也就是说，企业不应该只问“模型能不能写 SQL”，而应该问：
它是否知道该用什么数据？是否知道为什么用这些数据？是否能说明来源？是否能被评测？是否能在数据变化后持续保持正确？
只有这些问题都被系统性解决，Data Agent 才能从演示工具走向真正的企业生产系统。
