夜雨聆风这半年OpenAI和Claude都发表了一篇文章去讲自己是如何做智能问数的，某种程度上意味着一件事：智能问数在模型层面逐渐地成熟起来了，学习这两篇文章，不仅可以去了解目前最强的两家大模型公司如何去做智能问数，也可以针对我们选用的模型对harness进行相应的改造，从而发挥出模型最大的能力。
一句话总结
OpenAI 把 Data Agent 的关键瓶颈看成“上下文不足”，所以方案是补齐上下文；Claude 把关键瓶颈看成“路径不可信”，所以方案是治理数据、约束流程、持续验证。
OpenAI 与 Claude Data Agent 的设计差异与方法论比较
在企业自助式数据分析场景中，OpenAI 和 Claude 分别提出了两种不同的 Data Agent 设计方案。虽然两篇文章都在解决同一个问题——让普通员工通过自然语言完成数据发现、查询和分析——但它们对失败原因的归因、架构设计和落地方法存在显著差异。
OpenAI 的《Inside OpenAI’s in-house data agent》更像一篇内部系统架构复盘，重点解释如何通过上下文、代码理解、记忆和评测机制，让 Agent 理解复杂企业数据。Claude 的《How Anthropic enables self-service data analytics with Claude》则更像一篇企业落地方法论，重点说明如何通过数据治理、语义层、Skills 和 Validation，让 Agent 按可信路径稳定工作。
本文从问题定位、架构分层、数据处理策略、流程控制、评测方法、权限安全和产品形态几个方面对两者进行比较，并进一步分析为什么会产生这两种不同方案。
1. 问题定位与核心关注点
OpenAI 在《Inside OpenAI’s in-house data agent》中，将企业数据分析的主要瓶颈归因于 Agent 缺少足够上下文。在企业内部，数据集数量庞大、表结构复杂、指标口径多样，用户很难快速找到正确的数据表、字段和 SQL。即使 Agent 能生成 SQL，如果它不了解表的业务含义、生成逻辑、使用习惯和历史约束，也很容易得到错误结果。
因此，OpenAI 的关注点是：Agent 理解企业数据需要哪些上下文？
Claude 在《How Anthropic enables self-service data analytics with Claude》中，则将问题归因于另一种情况：Agent 即使拿到了大量信息，也可能走错路径。企业内部往往存在重复表、相似字段、旧指标、过期 dashboard、历史 SQL 和不同部门的口径差异。Agent 如果在这些信息中自由搜索，可能会选中一个看似相关但实际错误的数据实体，最后给出一个“很像正确答案”的错误结论。
因此，Claude 的关注点是：如何让 Agent 在复杂信息空间里沿着可信路径使用数据？
总结来说：
• OpenAI 关注点：Agent 要理解企业数据，需要哪些上下文。 • Claude 关注点：Agent 要稳定完成分析，需要怎样的治理路径。
这也是两种方案分化的起点。
2. 架构分层设计
两者的架构设计反映了不同的问题假设。
2.1 OpenAI：上下文增强型架构
OpenAI 将 Data Agent 的上下文分为六层：
1. Table Usage：表结构、字段类型、血缘关系、历史 SQL 和常见 join 模式。 2. Human Annotations：人工标注的表说明、字段说明、指标含义和使用注意事项。 3. Codex Enrichment：从代码、数据管道、存储过程和作业逻辑中理解数据生成方式。 4. Institutional Knowledge：业务文档、会议纪要、制度说明、内部术语和组织知识。 5. Memory：用户纠错、非显性规则、历史经验和个性化偏好。 6. Runtime Context：实时数据校验、schema 检查、权限检查和运行状态确认。
这套架构的目标，是让 Agent 获得一个更完整的“企业数据认知层”。它不仅知道表叫什么、字段叫什么，还要知道数据从哪里来、什么时候更新、哪些表常被一起使用、哪些指标有特殊过滤条件、历史上用户如何纠正过类似问题。
因此，OpenAI 的方案可以概括为：
通过补齐上下文，让 Agent 更懂数据。
它更像一种认知型架构，重点在于增强 Agent 对复杂数据世界的理解能力。
2.2 Claude：治理闭环型架构
Claude 将 Data Agent 架构分为四层：
1. Data Foundations：canonical datasets、指标口径、数据质量、转换逻辑和负责人管理。 2. Sources of Truth：语义层、血缘图、转换图、结构化文档和权威业务定义。 3. Skills：定义 Agent 的操作顺序、查询路径、回退策略和业务域分析流程。 4. Validation：离线评测、ablation、domain gating、在线验证和 provenance 标注。
这套架构强调的不是“让 Agent 尽可能读取所有信息”，而是先把数据世界治理成可导航、可验证、可复用的结构，再让 Agent 沿着确定路径完成分析。
Claude 特别强调：语义层和权威指标应该优先于自由 SQL；canonical datasets 应该优先于临时表和历史查询；Skills 应该规定 Agent 在不同业务场景中先查什么、后查什么、什么时候需要验证、什么时候应该降级或拒答。
因此，Claude 的方案可以概括为：
通过治理路径，让 Agent 更稳定地使用数据。
它更像一种治理型架构，重点在于降低 Agent 自由探索带来的不确定性。
3. 数据处理策略
OpenAI 依赖上下文理解能力。它认为，历史 SQL、代码、文档、人工标注、运行时状态和用户纠错都可以成为 Agent 理解数据的重要材料。上下文越丰富，Agent 越有可能生成正确 SQL，并对结果做出合理解释。
Claude 则对“堆上下文”更加谨慎。它认为，企业数据环境中很多信息本身就存在歧义和污染。历史 SQL 可能包含过期口径，旧 dashboard 可能已经不再维护，文档可能与真实数据不一致，临时分析表可能不适合复用。把这些信息直接交给 Agent，并不等于 Agent 会正确使用。
因此，Claude 更强调：
• 哪些数据集是权威的； • 哪些指标可以作为事实来源； • 哪些历史 SQL 只能作为参考； • 哪些场景必须优先走语义层； • 哪些问题必须进入验证或人工升级流程。
换句话说：
OpenAI 更关注“让 Agent 看得更多、懂得更深”；Claude 更关注“让 Agent 看得有顺序、用得有约束”。
4. 流程控制与技能使用
OpenAI 强调 Memory + Runtime Context + Codex Enrichment，偏向智能自适应。Agent 可以根据上下文和历史经验自主生成 SQL、执行查询、分析结果，并在用户纠错后沉淀新的经验。
这种方式更像是给 Agent 一个不断扩展的认知系统：它通过上下文理解当前任务，通过 Memory 记住过去的纠错，通过 Runtime Context 验证当前数据状态，通过 Codex Enrichment 理解数据生成逻辑。
Claude 强调 Skills + Validation，偏向规则驱动和流程控制。Skills 不只是提示词，而是一种程序性知识：它定义 Agent 在某类业务问题中应该如何行动。例如，先查询语义层，再查询权威文档；如果语义层无法覆盖，再进入原始表探索；如果涉及敏感数据或高风险结论，则需要降级、拒答或升级处理。
因此，两者对流程控制的理解不同：
OpenAI 更像是增强 Agent 的“判断力”，Claude 更像是给 Agent 铺设“轨道”。
5. 评测与验证方法
OpenAI 使用 Golden SQL + 结果比对。它更像单元测试：给定一个自然语言问题，Agent 生成 SQL，系统执行 SQL，再将结果与 golden SQL 或预期结果进行比较。这种方法适合验证 Agent 是否能把用户问题转成正确查询。
Claude 使用 Offline eval + Ablation + Online validation + Domain gating + Provenance。它更像生产治理闭环，不仅验证某次 SQL 是否正确，还验证 Agent 是否使用了正确事实来源、Skill 版本变化是否造成回归、某个业务域准确率是否达标、回答是否带有来源说明、高风险请求是否被正确处理。
两者的差异不在于谁更重视评测，而在于评测对象不同：
OpenAI 的评测更像“查询单元测试”，Claude 的评测更像“业务域上线门禁”。
6. 权限与安全管理
OpenAI 使用 Pass-through permission，即 Agent 继承现有权限模型。用户只能访问自己原本有权限的数据，Agent 不额外扩大权限。如果用户没有权限，Agent 需要提示或选择用户有权限的替代数据。
Claude 则更强调通过 Skill 流程约束 和规则限制敏感或高风险查询。对于涉及敏感信息、受限数据、高风险业务结论的问题，Skill 可以规定 Agent 降级处理、拒绝回答、返回 SQL 让用户自行执行，或者升级给人工判断。
可以理解为：
• OpenAI 更强调底层权限继承。 • Claude 更强调执行过程中的流程约束。
这两种方式并不冲突。一个负责“能不能访问”，一个负责“应该怎么使用”。
7. 产品形态与落地策略
OpenAI 的形态更像一个统一的内部 Data Agent 平台。它可以通过 Slack、Web、IDE、CLI、ChatGPT app 等入口服务不同用户，覆盖数据发现、SQL 查询、Notebook、分析报告等端到端流程。
Claude 的形态更像 Claude Code + Skills + MCP + Dashboard 的组合。Skill 是核心载体，用于把某个业务域的分析流程、事实来源、判断规则和验证方式固化下来。不同入口可以复用同一套 Skill，从而保证回答路径一致。
两者的产品形态可以这样概括：
8. 为什么会产生两种不同方案？
两种方案的差异不是偶然的，也不是简单的“OpenAI 更重技术、Claude 更重治理”。更准确地说，它们来自不同的问题定义、系统假设和产品路线。
8.1 失败归因不同
这是最根本的原因。
OpenAI 认为，Data Agent 失败的主要原因是 上下文不足。Agent 不知道该用哪张表，不知道字段真实含义，不知道表是怎么生成的，也不知道历史上有哪些业务约束和用户纠错。因此，它容易生成错误 SQL 或错误解释。
所以 OpenAI 的解法是：
错误来自“不够懂”→ 补上下文→ 增强理解→ 提升自主推理能力Claude 认为，Data Agent 失败的主要原因是 路径不可信。Agent 可能找到很多相关信息，但这些信息里有旧口径、旧报表、重复表、相似字段、临时分析结果和过期 SQL。Agent 最终可能选择了一个看似合理但实际错误的路径。
所以 Claude 的解法是：
错误来自“走错路”→ 建事实来源→ 设计 Skill 路径→ 做 Validation 闭环这就是两种方案最核心的分叉。
8.2 对上下文的信任程度不同
OpenAI 更相信，只要上下文足够丰富，Agent 就可以更好地自主推理。它将表使用历史、人工标注、代码理解、机构知识、记忆和运行时状态都纳入上下文层，试图让 Agent 尽可能完整地理解企业数据世界。
Claude 对这种方式更谨慎。它认为，上下文不是越多越好，关键是上下文有没有优先级、可信度和使用路径。大量历史 SQL 和旧 dashboard 并不一定能提升准确率，反而可能让 Agent 在错误路径上越走越远。
因此，两者对上下文的态度不同：
OpenAI 的关键词是“丰富上下文”，Claude 的关键词是“治理上下文”。
8.3 对企业数据世界的抽象不同
OpenAI 更像是在处理一个 超大规模、复杂但可通过上下文理解的数据世界。在这种视角下，企业数据世界是一个巨大的知识空间：有海量数据集、表、SQL、代码、文档和历史经验。问题不是这些东西不能用，而是 Agent 不理解它们之间的关系。
Claude 则更像是在处理一个 容易污染、容易歧义、需要治理的数据分析环境。在这种视角下，企业数据世界不是天然可信的。里面有重复表、旧指标、废弃 dashboard、错误历史 SQL、部门口径冲突和文档数据不一致。
所以两者的系统抽象不同：
OpenAI：把复杂数据世界建模给 Agent 理解Claude：把混乱数据世界治理成 Agent 可走的路径这会自然导向不同架构。
8.4 产品和技术路线不同
方案差异也来自两家公司正在强调的产品能力不同。
OpenAI 的文章天然会突出 GPT、Codex、Embeddings、Evals、Memory、MCP 等能力。因此它的 Data Agent 更像一个完整的智能体系统：能发现数据、理解代码、生成 SQL、执行查询、生成 notebook 或报告，并通过 memory 和 evals 持续改进。
Claude 的文章则延续了 Anthropic 近期主推的 Claude Code、Skills、MCP 和 agentic workflow。它自然会强调 Skills：把某类专业任务的执行方式固化为可复用、可版本管理、可评测的程序性知识。
因此，技术资产也会塑造方案形态：
这不是单纯的技术差异，而是产品叙事差异。OpenAI 展示“我们如何用模型和上下文做出一个强大的内部 Data Agent”；Claude 展示“企业如何用 Claude Code 和 Skills 把自助分析做可靠”。
8.5 对 Agent 自主性的风险判断不同
OpenAI 的方案更接近：
给 Agent 足够上下文让它自主探索、自主推理、自主纠错它不是无约束，但整体上更相信 Agent 的推理能力。它通过上下文、Memory、Runtime Context 和 Evals 来增强 Agent 的自主能力。
Claude 的方案更接近：
不要让 Agent 在数据世界里自由游荡要给它轨道、路标、红线和复核机制也就是说，Claude 更关注自主性带来的风险。它更愿意通过 Skill、语义层、事实来源和验证机制来约束 Agent 的行为。
这种差异可以理解为：
OpenAI 更像是增强 Agent 的大脑，Claude 更像是给 Agent 建立操作规程。
8.6 评测对象不同
OpenAI 的评测对象更偏向单次查询任务：
自然语言问题→ 生成 SQL→ 执行 SQL→ 与 golden SQL / 预期结果对比这种评测适合衡量 Agent 是否能把用户问题转成正确查询。
Claude 的评测对象更偏向完整业务分析工作流：
是否选对了语义层指标是否使用了正确事实来源Skill 版本变化是否造成回归某个业务域准确率是否达标线上回答是否有来源说明高风险请求是否被正确处理因此，OpenAI 更自然地建设 Query Eval，Claude 更自然地建设 Domain Eval、Skill Eval、Ablation 和 Online Validation。
8.7 文章写作目的不同
OpenAI 这篇更像内部系统架构复盘。它的叙述方式是：内部数据规模很大，传统分析很难，因此构建一个 in-house Data Agent，并解释它由哪些上下文和能力组成。
Claude 这篇更像企业落地方法论。它的叙述方式是：企业做自助式数据分析会遇到哪些失败模式，应该如何建设数据基础、事实来源、Skills 和 Validation。
所以表达重点天然不同：
OpenAI：我建了什么系统Claude：你应该怎么建设可靠系统这也会导致两篇文章呈现出不同的方案风格。
9. 核心差异总结
一句话概括：
OpenAI 解决“Agent 要懂什么”，Claude 解决“Agent 如何可靠地做”。
更进一步说：
OpenAI 把可靠性的前提定义为“理解充分”，Claude 把可靠性的前提定义为“路径可信”。
因此，两种方案可以分别概括为：
OpenAI：理解充分 → 推理正确 → 查询正确 → 分析可信Claude：路径可信 → 来源正确 → 验证通过 → 分析可信10. 结语
OpenAI 和 Claude 的 Data Agent 方案各有侧重。OpenAI 偏向认知型架构，强调上下文、理解、记忆和自主推理；Claude 偏向治理型架构，强调数据治理、语义层、Skill、验证和工程闭环。
这两种方案不是互斥关系，而是从不同角度解决 Data Agent 的可靠性问题。OpenAI 更关注“让 Agent 懂起来”，Claude 更关注“让 Agent 稳起来”。
如果用一句话总结两篇文章的关系：
OpenAI 给出了 Data Agent 的上下文大脑，Claude 给出了 Agentic Analytics 的工程轨道。
真正可落地的企业 Data Agent，通常需要同时具备这两种能力：既要有足够丰富的上下文，让 Agent 理解数据；也要有清晰的事实来源、Skill 路径和验证机制，让 Agent 不会在复杂数据环境中走偏。只有将“理解能力”和“治理约束”结合起来，Data Agent 才能从演示走向生产。
参考文章:
• https://openai.com/index/inside-our-in-house-data-agent/?utm_source=chatgpt.com "Inside OpenAI's in-house data agent" • https://claude.com/blog/how-anthropic-enables-self-service-data-analytics-with-claude?utm_source=chatgpt.com "How Anthropic enables self-service data analytics with Claude"
