在 Anthropic 内部，大约 95% 的业务分析请求已经由 Claude 自动完成，且整体准确率高达 95% 左右。
从结果看，他们似乎已经把数据分析 Agent （Analytics Agent）跑通了。但在实践过程中，Anthropic 发现了一个反常识的结论：数据分析 Agent 最大的挑战是 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 出错，是因为数据体系本身就充满歧义。因此，必须建立标准数据集。对于关键业务概念，只保留少量受管理、被认可的单一事实来源。当 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 沿着错误上下文，快速跑出一个看似正确的答案。
