数据不是软件：Anthropic 如何用 Claude 实现自助式数据分析
最近 Anthropic 发布了一篇很值得数据团队和 Agent 团队阅读的文章：《How Anthropic enables self-service data analytics with Claude》。文章讨论的不是“Claude 会不会写 SQL”，而是一个更现实的问题：当企业希望让业务人员直接通过自然语言查询数据时，如何保证 Agent 给出的答案是准确、可治理、可追溯的。
Anthropic 在文中披露，他们内部约 95% 的业务分析查询已经由 Claude 自动化完成，整体准确率约 95%。这让数据科学团队可以从大量重复的临时分析请求中解放出来，把更多精力放在因果建模、预测、机器学习等更高价值工作上。(Claude)
这篇文章最有价值的一点，是它没有把自助式数据分析简单归结为“让大模型生成 SQL”。Anthropic 的核心判断是：分析型 Agent 的准确性，本质上是上下文、数据治理和验证问题，而不是代码生成问题。(Claude)
一、为什么说“数据不是软件”
Anthropic 在文章中提出了一个非常关键的判断：Data is not software，数据不是软件。
这句话的含义并不是说数据系统不需要工程化，而是说，数据分析 Agent 面临的问题和 Coding Agent 不一样。
在软件开发场景中，模型可以有较大的创造空间。代码有编译器、测试、类型检查、运行报错等反馈机制。模型写错了，很多时候系统会立刻暴露问题。软件开发本身也是开放式解空间，同一个需求可能有多种实现方式。
但业务数据分析不同。很多分析问题只有一个正确答案，或者至少只有一个被组织认可的正确口径。比如“本月活跃用户数”“某产品收入”“某区域故障率”，看起来只是一个简单查询，实际背后涉及数据源、指标定义、过滤条件、时间窗口、实体粒度、去重逻辑、异常数据排除等一系列业务约定。文章指出，分析场景往往没有确定性机制可以证明最终答案一定正确。(Claude)
这就带来了一个更危险的问题： Agent 查错表、选错字段、漏掉过滤条件时，SQL 可能仍然能正常执行，结果也可能看起来很合理，但答案是错的。
这类错误比代码报错更隐蔽，因为它不会以异常栈的形式出现，而是以“看起来专业的错误结论”出现。
因此，业务数据 Agent 的核心挑战不是“能不能生成 SQL”，而是：
1 | 用户问题 |
如果这条链路没有治理好，大模型越强，反而越可能把错误答案包装得更可信。
二、业务数据 Agent 最常见的三类错误
Anthropic 把自助式数据分析中的主要错误归纳为三类：概念到实体的歧义、数据陈旧、检索失败。(Claude)
第一类是 概念到实体的歧义。
用户说“活跃用户”，数据系统里可能有多个字段、多个表、多个看板都能回答这个问题。但“活跃”到底是什么意思？是登录过、发起过会话、完成过关键操作，还是付费使用过？是否排除欺诈用户？时间窗口是 7 天、30 天，还是自然月？使用哪个用户 ID 去重？
如果这些定义没有被治理，Agent 只能在一堆看似合理的字段中猜测。猜对了是智能，猜错了就是事故。
第二类是 数据陈旧。
企业数据系统不是静态的。表结构会变，字段含义会变，业务定义会变，指标口径会变，数据链路也会变。如果 Agent 依赖的文档、Skill、查询样例或指标说明没有及时更新，它仍然可能返回一个“符合旧世界”的答案。
这种错误尤其危险，因为它通常不是完全离谱，而是“轻微但关键地错误”。
第三类是 检索失败。
有时候正确答案其实存在：正确的数据表存在，字段描述存在，历史分析也存在。但由于搜索空间太大，Agent 没有找到它。Anthropic 的一个重要发现是，单纯给 Agent 更多历史 SQL、更多文档、更多数据资产，并不会自然解决问题。信息“存在”不等于 Agent 能“正确使用”。
这三类错误可以概括为一句话：
1 | 业务数据 Agent 的问题，不是缺少数据， |
三、Anthropic 的解法：用治理缩小答案空间
Anthropic 的核心方案不是把整个数据仓库开放给 Agent，让它自己探索，而是建立一套 agentic analytics stack，也就是面向 Agent 的分析栈。这个栈的目标，是分别解决实体歧义、数据陈旧和检索失败。(Claude)
第一层是 Data Foundations，数据基础设施层。
这一层包括数据模型、数据转换、测试、数据仓库表，以及描述这些资产的元数据。Anthropic 明确强调，传统数据工程实践仍然重要，比如维度建模、shift-left testing、关键链路的新鲜度检查、完整性检查等。换句话说，LLM 并不会替代数据治理，反而会放大数据治理的价值。(Claude)
在这一层，最重要的实践是建立 canonical datasets，也就是权威数据集。
很多 Agent 错误来自一个常见现象：同一个业务概念在数据仓库中有多个近似实现。比如收入有多个表，用户有多个表，订单有多个表，每个表都“差不多能用”，但口径略有不同。对人类资深分析师来说，这些差异可能是经验常识；对 Agent 来说，这就是错误来源。
Anthropic 的做法是减少候选项，建立少量经过强治理的逻辑模型。这些模型要有明确 owner、可消费、可发现，并且要主动废弃近似重复表。目标是当 Agent 搜索某个概念时，能找到一个被治理的标准答案，而不是一堆候选答案。(Claude)
这对企业数据 Agent 的启发很直接：
1 | 不要让 Agent 在整个数据仓库里自由搜索。 |
四、治理不能只靠文档，必须靠工程机制强制执行
很多团队的问题不是没有指标文档，而是文档没有约束力。写在 Confluence、README 或 Wiki 里的规范，如果没有工具、CI 和流程约束，很快就会过期。
Anthropic 特别强调，数据治理必须被执行。它们通过三类机制保证治理不退化：工具层路由、CI 检查、组织规范。Agent 会被结构化地优先路由到 canonical models 和 semantic layer；绕过治理层的变更会在 review 中失败；下游团队默认基于治理层建设，除非能说明原因。(Claude)
这说明 Anthropic 并不是靠一句 prompt 告诉模型“请使用正确表”，而是把“正确路径”做成默认路径和强制路径。
文章还提到一个重要做法：把数据建模代码、语义层、参考文档、权威 dashboard 定义放在同一个 repo 里，并通过 CI 保护跨层一致性。如果某个数据模型变更会破坏下游 dashboard，或者使文档中的指标定义失效，CI 应该能发现，并要求在同一个 PR 中修复。(Claude)
这个思想非常关键：
1 | 指标口径变更 |
否则就会出现一个典型问题：底层字段变了，查询还能跑，Agent 仍然按照旧文档解释，最终生成一个错误但看似合理的业务结论。
五、元数据要成为一等产品
Anthropic 认为，Coding Agent 之所以能在代码库中表现较好，是因为代码库通常有 README、类型签名、docstring、测试、目录结构等可读信息。数据仓库也可以变得“可读”，但前提是表描述、列描述、指标定义、粒度、合法值范围、血缘关系、owner、模型分层等元数据被像数据转换逻辑一样认真维护。(Claude)
这意味着，面向 Agent 的数据治理不能只停留在“表能查”。一个合格的数据资产至少需要回答以下问题：
1 | 这张表表示什么业务对象？ |
对 Agent 来说，这些元数据不是附加说明，而是准确性的基础设施。
六、Source of Truth：不要把历史 SQL 当真理
在 Anthropic 的方案中，sources of truth 是 Agent 查询数据时参考的可信表面。它们大致按可信度排序：语义层、血缘和 transformation graph、查询语料、业务上下文。(Claude)
优先级最高的是 semantic layer，语义层。如果用户问题能映射到一个已定义指标，Agent 就应该直接调用语义层函数，得到和公司其他系统一致的结果。Anthropic 还提到，他们会通过 Skill instruction 结构性要求 Agent 优先使用语义层。(Claude)
这里有一个很重要的反直觉结论：Anthropic 曾尝试让 LLM 基于原始表和查询日志自动生成指标定义，但效果不好。因为模型生成的定义看起来合理，却可能把原本要消除的歧义固化进去。Anthropic 的建议是：Claude 可以帮助生成文档，但指标定义必须由人负责。(Claude)
换句话说：
1 | LLM 可以辅助治理， |
第二个重要参考面是 lineage 和 transformation graph。当语义层无法覆盖某个问题时，Agent 可以通过血缘关系、表引用频率、模型上下游关系判断哪个表更接近权威答案，哪些模型已经废弃，哪些表粒度一致。(Claude)
第三个参考面是历史查询语料，也就是 dashboard、notebook、历史分析中的 SQL。但 Anthropic 的实验发现，直接让 Agent 检索成千上万条历史 SQL，准确率提升不到 1 个百分点。真正有效的做法，是把历史查询沉淀为结构化领域文档和可复用分析模式，再写入 Skill。(Claude)
这点对很多企业尤其重要。历史 SQL 很有价值，但它不是 source of truth。它更像原材料，需要被整理、抽象、审查和治理。
七、Skill：把资深分析师的流程写下来
Anthropic 对 Skill 的定义很清晰：如果 source of truth 是声明式知识，说明“指标是什么意思”；那么 Skill 就是过程性知识，说明“应该按什么顺序查哪些来源、如何处理歧义、一个完成的分析应该长什么样”。(Claude)
这也是文章中最值得关注的数据之一：在 Anthropic 的评测中，如果没有 Skills，Claude 回答分析问题的准确率不超过 21%；加入 Skills 后，整体准确率稳定超过 95%，某些领域接近 99%。(Claude)
这说明 Skill 不是简单的提示词模板，而是业务分析流程的工程化载体。
一个好的数据分析 Skill 应该包含：
1 | 1. 什么时候触发这个 Skill |
Anthropic 还强调，Skill 文档要面向 LLM 检索来写，而不是面向人类随便读一读。比如要明确写出表的 grain、scope、exclusion、usage、gotchas、cross references。(Claude)
更重要的是，Skill 必须持续维护。Anthropic 观察到，如果 Skill 不主动维护，离线准确率会从上线时约 95% 在一个月内漂移到约 65%。后来他们把 Skill markdown 和 transformation models 放到同一个 repo，并用 code-review hook 检查 reporting-model 变更是否同步修改 Skill 文件。之后，约 90% 的数据模型 PR 都会同时包含 Skill 变更。(Claude)
这给我们的启发是：
1 | Skill 不是一次性 prompt。 |
八、Validation：让准确性可测量、可回归、可追踪
Anthropic 的验证体系包括 offline evaluations、ablation techniques 和 online validation。(Claude)
离线评测使用 question / answer pairs。Anthropic 使用两类评测：一类是基于 dashboard 的常见问题，由 Claude 自动生成后再人工验证；另一类是 long-tail eval，也就是把业务上下文、roadmap、表文档喂给 Claude，让它生成领域内可能出现的长尾问题。同时，业务人员在对话中纠正 Agent 的内容，也会被持续收集为候选 eval。(Claude)
为了避免 ground truth 漂移，Anthropic 建议把评测绑定到 snapshot date、稳定 fact table，或者让 grader 判断查询逻辑而不是动态数字。同时，评测要接入 CI，当 PR 影响相关依赖时自动重新运行。(Claude)
他们还把评测结果当作 telemetry，而不是普通测试日志。每次运行都会记录 skill version、git SHA、model ID、每条断言的通过失败、token count、耗时等信息。这样，“某个改动是否真的提升准确率”就可以通过查询回答，而不是靠感觉判断。(Claude)
这套机制非常适合企业内部 Agent：
1 | 每一次 Skill 修改 |
九、线上准确性：不仅要答对，还要让可信度可见
在线上系统中，Anthropic 使用了几类机制保证准确性。
第一是 adversarial review。他们会用一个 Claude Skill 激进质疑最终答案背后的假设。这个机制在 eval 中带来约 6% 的准确率提升，但代价是 token 增加 32%、延迟增加 72%。(Claude)
第二是 provenance footer，也就是每个回答都带上来源层级、数据新鲜度和模型 owner。比如答案来自 semantic layer、curated reference 还是 raw table；数据更新到什么时候；所属 owner 是谁。Anthropic 也承认，这不会让答案本身更正确，但能帮助使用者判断可信度。(Claude)
第三是 data quality checks。即使 Agent 使用了正确字段，如果数据本身不完整、不新鲜或异常，答案仍然会错。因此，需要检查字段是否最新、完整，是否存在异常。(Claude)
第四是 passive monitoring。Anthropic 会持续跟踪两个生产信号：Agent 查询中有多少比例通过语义层解决，以及回答中出现多少纠错语言，比如“表错了”“漏掉了某个过滤条件”。这些信号会和离线准确率一起定期查看。(Claude)
第五是 active correction harvesting。Anthropic 会定时扫描 stakeholder channel 中的纠错语言，自动给相关 reference doc 起草修复，并开 PR 给 domain owner。这些纠错也会回流到离线 eval。(Claude)
这形成了一个闭环：
1 | 线上出错 |
十、仍然没有完全解决的问题：silent failure
Anthropic 很坦诚地承认，还有一种错误无法完全捕获：silent failure。
也就是答案是错的，但看起来合理，并且没有人提出异议。当前的缓解手段包括 provenance footer、面向领导层材料的人类确认、以及对每个领域 top KPI 每天和权威 dashboard 做 sanity check。但他们也明确表示，目前还没有鲁棒解决方案。(Claude)
这恰恰是业务数据 Agent 最现实的风险。因为业务分析的错误不一定会立刻报错，它可能进入周报、汇报、决策会议，甚至影响业务判断。
所以，企业构建数据 Agent 时，目标不应该是幻想“永远不出错”，而是建立一套机制：
1 | 让错误更难发生； |
十一、对企业数据 Agent 的落地启发
如果把 Anthropic 的实践抽象成一套可落地方案，可以总结为以下几点。
第一，先建立 canonical datasets，不要让 Agent 直接面对混乱的数据仓库。
第二，语义层应该成为默认入口。能通过 semantic layer 解决的问题，不应该 fallback 到手写 SQL。
第三，每个指标都需要 owner、grain、unit、freshness、required filters、valid range、lineage 等元数据。
第四，历史 SQL 只能作为治理素材，不能直接作为 source of truth。
第五，Skill 要写成过程规范，而不是提示词片段。它应该描述如何澄清问题、如何选数据源、如何执行查询、如何审查结果、如何输出来源。
第六，Skill 和数据模型要放在同一个工程生命周期中。模型变更、指标变更、字段变更，必须同步更新 Skill 和评测。
第七，评测要进入 CI。不能只在上线前测一次，而要在每次改动后持续回归。
第八，最终回答必须带 provenance。用户至少要知道答案来自哪里、数据是否新鲜、口径是什么、owner 是谁、置信等级如何。
第九，对高风险问题引入 adversarial review 和人工确认。
第十，把用户纠错变成文档、Skill 和 eval 的更新，而不是只在当前会话里修正一次。
结语：数据 Agent 的关键不是“会查”，而是“查得对”
这篇文章最大的价值，在于它把自助式数据分析从“自然语言生成 SQL”的狭窄视角中拉了出来。
真正的业务数据 Agent，不是一个 SQL 生成器，而是一个运行在数据治理体系之上的分析执行系统。它需要理解业务语义，知道哪些数据可信，知道什么时候必须澄清，知道如何验证结果，也知道如何把错误反馈回治理流程。
Anthropic 的实践说明，想让 Agent 大规模处理业务数据，不能只堆模型能力。更重要的是建设四类基础设施：
1 | 被治理的数据入口； |
一句话总结：
数据 Agent 的准确性，不主要来自更强的 SQL 生成能力，而来自更好的数据治理、语义约束、流程化 Skill 和持续验证闭环。
这也是“数据不是软件”这句话真正值得重视的地方。
