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 KnowledgeSlack、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 EnrichmentOpenAI 明确指出表的真正含义常常存在于生产这张表的代码里而不是只存在于仓库元数据里。因此OpenAI 会通过离线管道把表使用情况、人工注释、代码理解、组织知识和记忆整合成统一的上下文表示再通过 embeddings 和 RAG 在查询时检索相关信息。Claude 对“堆上下文”更加谨慎。Anthropic 认为历史 SQL、旧 dashboard、过期文档和相似表名都可能污染 Agent 的判断。它们不是不能用但不能直接作为事实来源。Claude 特别强调 canonical datasets 和 semantic layer当用户问一个指标时系统应该优先把问题路由到受治理的指标定义而不是让 Agent 在原始表和历史查询中自由搜索。这两种策略的区别可以概括为维度OpenAIClaude数据策略丰富上下文让 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 个点。这个实验让他们意识到瓶颈不在于“信息是否存在”而在于“问题能否被结构化地路由到正确实体”。所以两者的评测重点不同维度OpenAIClaude评测对象单次查询与结果完整分析路径与生产稳定性核心问题SQL 和结果是否正确来源、路径、版本、验证是否可信方法Golden SQL、结果比对、Evals APIOffline 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. 核心差异总结维度OpenAIClaude核心问题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 才能从演示工具走向真正的企业生产系统。