深入解析来自Anthropic的数据分析最佳实践：代理回答错误的根本原因与应对策略

在 Anthropic 内部，大约 95% 的业务分析请求已由 Claude 自动处理，整体准确率稳定在 95% 上下。

从结果看，他们的数据分析 Agent 初步跑通了。但在落地过程中，Anthropic 发现一个反直觉的结论：数据分析 Agent 的真正挑战，不是模型能否写出正确的 SQL，而是——Agent 到底能不能准确识别自己所查的数据表？它是否理解了正确的业务定义？以及，它能否判断计算出的答案是否可信？

Claude 做数据分析，SQL 不是最大难点

坦白讲，过去很多团队都尝试过推动“自助式数据分析”。

要么拉平数据模型，让业务同事自己查表；要么提前封装好指标和 Dashboard，把分析范围锁死在预设框架里。结果呢？前者导致数据定义越来越混乱，后者则难以覆盖业务中那些五花八门的长尾问题。

大语言模型的出现提供了第三条路径：直接将 Agent 接入数据仓库，让业务方提问，Agent 自动查询并生成分析结果。

但问题很快暴露：

Agent 确实能查到数据，可原本由数据团队、文档体系和业务专家共同提供的上下文信息，在这个过程中消失了。

于是，你看到一个看似合理的结果，背后引用的可能是一张早已废弃的数据表，或者一个过时的指标定义。

结合自身实践，以及与大量 Claude Code 用户的交流，Anthropic 总结出一套关于数据分析 Agent 的最佳实践。这也回答了核心问题：为什么数据分析 Agent 频繁答错？

一句话总结

数据分析 Agent 的核心瓶颈从来不是 SQL 生成能力，而是业务上下文。不要指望 Agent 能在混乱的数据体系中自动找到标准答案。你需要做的，是先将数据环境整理成 Agent 能导航、能理解、能验证的结构。

数据分析不是软件工程

很多人会下意识地把数据分析 Agent 当作 Coding Agent 的另一种形态。但 Anthropic 认为，两者面对的根本不是同一个问题。

写代码属于“开放问题”。同一个需求有无数种实现方式，只要代码能跑通、单元测试通过，方向通常不会错。

数据分析则完全不同。许多业务问题只有一个正确答案，甚至正确的数据源也只有一个。

举个例子，人类分析师经常被问：“当前活跃用户是多少？”但对 Agent 来说，在写 SQL 之前，它必须跨越几道关卡：活跃如何定义？要不要剔除作弊账号？看的是 7 天还是 30 天？用哪个产品线的表？

这些问题不搞清楚，SQL 写得再优雅也无意义。数据分析 Agent 最重要的能力不是生成查询语句，而是将模糊的业务概念精准映射到具体的数据实体上。

Anthropic 的一个“失败实验”

很多人在构建数据分析 Agent 时，第一反应是给模型提供更多信息，以为知识库足够庞大，Agent 自然会变聪明。

Anthropic 曾把内部数千份真实的查询文件（包括 Dashboard SQL、分析师的 Notebook SQL）全开放给 Agent。按理说，Agent 应该能从历史经验中学到正确的分析套路。

结果却令人意外：这么做几乎没有带来任何提升，准确率的波动甚至不到 1%。

更有意思的是，他们翻查了大量错误案例后发现，正确答案其实就躺在那些历史 SQL 里，Agent 看到了，但并未正确使用。大约 80% 的错误案例都出现了类似的失误。

这让 Anthropic 意识到：Agent 缺的根本不是更多信息。数据分析 Agent 的瓶颈不是知识量，而是知识导航。问题不在于系统里有没有答案，而在于 Agent 能否找到那个正确答案。这也是他们后续构建专属数据架构的出发点。

数据分析 Agent 最容易犯的三个错误

基于上述发现，Anthropic 将数据分析错误归结为三种典型的失败模式：

概念与实体的歧义： 这是 Agent 最高频的错误。用户口中的“收入”，在数仓里可能有几十种相似的表格：财务收入、产品收入、实时流水、历史快照。每个数字算出来都合理，但只有一个是当前问题真正需要的。实体映射错了，后续分析全盘皆输。

数据过时： 代码没变，但业务变了。上游改了表结构，或者业务换了统计口径，而 Agent 还在依赖过时的文档查数。这种错误最危险，因为它不会报错，SQL 照样运行，结果看似合理，实则完全不准确。

检索失败： 文档写了，指标定义了，标准模型也在。但答案就藏在数百万个字段里，Agent 却没能找到它。

解法：构建 Agent 专属的数据栈

搞懂了这些痛点，Anthropic 也就找到了解决方案：不要死磕模型能力，而是把数据环境改造成 Agent 容易理解的样子。他们搭建了一套“Agent 专属数据栈”（Agentic Analytics Stack），本质上只做一件事：让 Claude 少猜。

这套数据栈的核心，是把数据体系分成几个层次来处理，从基础到规范，再到验证和纠错。

Data Foundations：打好基础

很多 Agent 出错，是因为数据体系本身就充满歧义。因此，必须建立标准数据集（Canonical Dataset）。对于关键业务概念，只保留少量、受管理、被认可的单一事实来源。当 Agent 搜索“Revenue”时，不应该面对几十个候选项，而应直接被路由到那个唯一受治理的标准逻辑模型上。底座的干净程度，直接决定了准确率的上限。

Sources of Truth：建立可信来源字典

Agent 还需要知道，遇到问题时该优先信任谁。为此，Anthropic 建立了明确的查询优先级：

优先查语义层： 如果指标已经标准化，Agent 就不该再去手写 Join 和过滤条件。通过 Skill 强制规定：先调取语义层，查不到，才允许退回写原始 SQL。

补充业务上下文： 很多分析问题本质上其实是业务问题。问“Q2 发布效果怎么样”，Agent 得先知道 Q2 发布了什么产品。把产品路线图、企业知识库提供给 Agent，这极大地提升了它追问“澄清问题”的能力。

从 21% 到 95%：Anthropic 找到的不是更强模型，而是 SOP

这是整个系统提升最大的一环。Anthropic 内部的评测数据对比相当惊人：

• 没有 Skills：准确率不到 21%。
• 加入 Skills 后：准确率超过 95%。

这里的 Skill 并不是简单的提示词，而是把资深分析师的“脑回路”沉淀为流程规范。Anthropic 主要将 Skill 分为两类：

Knowledge Skill： 直接缩小搜索空间。它告诉 Agent 先查哪个领域、看哪些业务文档，而不是在混乱的数据仓库里盲目搜索。

Unbook Skill： 强制执行标准步骤。它要求 Agent 必须按照“先澄清问题 -> 找数据源 -> 写查询 -> 调用审查 -> 输出分析”这个闭环来工作，并内置了留存分析、漏斗分析等常见分析套路。

Validation：发现错误，防止系统长期退化

搭完系统只是开始，还需要验证机制来兜底那些漏网之鱼。

对抗式审查： 在给出最终答案前，唤起另一个 Claude 专门“挑错”，质疑是否有漏加过滤条件。代价是多花 32% 的 Token 和增加 72% 的耗时，但能提升 6% 的准确率。这笔交易显然是划算的。

离线评测： 把业务常见问题做成测试集。Anthropic 不把评测当单纯的测试日志，而是当成监控数据写入数仓。每次评测都会记录模型版本、Git SHA、Token 消耗和通过率，用来观察系统是否在持续退化。

说明来源： 强制要求 Agent 在回答末尾说明来源，例如：数据来源：语义层 | 新鲜度：昨天 | 责任团队：增长组。

Anthropic 坦言，目前最难防的是“静默错误”——结果是错的，但看起来完全合理，并且被直接使用。说明来源，就是为了提醒业务方：如果看到“数据来源：原始表，新鲜度未知”，那就必须保持警惕。

如果从零开始，先做三件事

如果你准备在团队落地数据分析 Agent，Anthropic 的建议是，不需要一上来就复制全套架构。只要先做好这三件事，就能拿到大部分收益：

• 整理 Canonical Dataset： 让每一个关键业务概念都拥有唯一的标准表。
• 建立 Offline Eval： 知道你的系统到底会在哪里出错。
• 编写轻量级的 Knowledge Skill： 给 Agent 划定搜索范围，帮助它快速找到正确的数据和文档。

至于自动文档同步、对抗式审查、在线纠错闭环，等系统跑起来遇到瓶颈了再加也不迟。

小结

Anthropic 上述实践带来的启发在于：当 Agent 已经掌握了写 SQL 的技能后，真正决定数据分析成败的，是上下文、数据定义和验证体系。

过去 BI 的核心痛点是“业务不懂怎么查”；未来数据分析 Agent 的挑战，则变成了“AI 不知道哪个才是标准答案”。

当查询生成越来越便宜，真正昂贵的其实是：Agent 沿着错误的上下文，快速跑出一个看似正确的答案。