看到 Anthropic 发的一篇文章，讲他们内部怎么用 Claude 做自助数据分析。文中给了两个数字：95% 的业务分析查询由 Claude 自动完成，整体准确率约 95%。

过去一年我们在做同一件事。这篇先讲清楚他们怎么做的，再和我们的实现做比较：哪些想到了一起，哪些是该抄的作业。最后给正要做这件事的团队一些建议。

Anthropic 怎么做的

起点是一个判断：分析 Agent 的准确性是 context 和验证的问题，不是 SQL 生成的问题。他们专门对比了 coding 和分析两类任务：coding 是开放解空间，文档和测试天然给幻觉兜底；分析往往只有一个正确答案、一个正确数据源，而且没有确定性的办法证明对错。

在这个判断下，他们把绝大多数错误归因为三个失败模式。

一是概念到实体的映射歧义：数据模型里有几百个都说得通的候选，agent 选不中正确的那个。比如算活跃用户数，什么行为算「活跃」？作弊用户算不算？回看窗口用多长？

二是过时：数据源、口径、schema 天天在变，agent 的知识悄悄失效，开始返回看起来正常的错误答案。

三是检索失败：正确的信息就在数据模型里，也标注好了，但搜索空间太大，agent 找不到。

下图是 Anthropic 的四层技术栈，每层都针对着一个或多个失败模式。

┌───────────────────────────────────────────────────────────────────┐
│  04 Validation        评测 / 在线验证             歧义 过时 检索  │
├───────────────────────────────────────────────────────────────────┤
│  03 Skills            薄路由 + runbook                 过时 检索  │
├───────────────────────────────────────────────────────────────────┤
│  02 Sources of truth  语义层 > 血缘 > 业务上下文            歧义  │
├───────────────────────────────────────────────────────────────────┤
│  01 Data foundations  单一事实源 + 元数据              歧义 过时  │
└───────────────────────────────────────────────────────────────────┘

从下往上说。

数据基建层是数仓本身：模型、转换、测试、表，加上描述它们的元数据。这层的思路是让歧义在 agent 开始搜索之前就消失：「收入」如果只解析到一个治理过的数据集，而不是四十个都说得通的候选，就没有歧义可言。核心动作是收敛，把近似重复的表收敛成少量单一事实源，激进下线其余的，再用工具、CI 和制度三重强制，保证所有人真的在用。防过时的第一道闸也在这层：所有数据代码放同一个仓库，改模型会弄坏下游看板的，CI 当场拦下。最后，元数据当一等公民来维护：表描述、粒度、血缘写到 agent 能读懂的程度，让数仓和代码库一样可读。

如果基建层是数仓本身，Sources of truth 层就是 agent 查数时翻的参考资料，作用是把问题里的「周活」对应到数据模型里一个明确的实体。四个参考面按信任度降序：语义层最高，问题能映射到已定义指标的，agent 直接调函数拿数，全公司同一个口径，skill 指令强制 agent 先走这条路；血缘次之，语义层没覆盖的问题，靠血缘推理该从哪张上游表聚合；再往下是历史查询语料，直觉上很值钱，实验结果反直觉，负面结果里细说；最低是业务上下文：agent 不懂业务，就只能回答用户问的，回答不了用户想问的，所以他们把公司文档、roadmap、组织架构接了进来，让 agent 听得懂「Q2 那次发布」指的是哪个产品。

Skills 层。如果说 sources of truth 是知识（一个指标是什么意思），skill 就是干活的流程（按什么顺序查、查到之后怎么办）。skill 本身就是一个 markdown 文件夹，agent 按需读取，但这是杠杆最大的一层：没有 skills 时，Claude 在他们评测集上的准确率不超过 21%；加上后稳定在 95% 以上。skill 成对出现：knowledge skill 管路由，内容大意是「先试语义层，没覆盖的话，这个域有三十份参考文档，表、字段、join、坑都在里面」，把百万字段的搜索空间收敛到几十份文档，检索失败就是这么解的；runbook skill 管流程，把资深分析师的干活顺序写下来，澄清问题、找数据源、跑查询、交给对抗审查。

最后是 Validation 层。前面三层建得再好，错误还是会有漏网之鱼，这层负责发现。手段按阶段分三种。上线前，每个域几十条问答对做离线评测，通过率不达标（初期门槛 90%）不允许向业务方开放。改动时，固定评测集、每次只动一个变量做回归，每个重要的 skill 改动，PR 里要带上前后通过率的变化。上线后，对抗审查加来源标注，再加一个定时 agent 扫业务群里的纠错，起草文档修复 PR，纠错同时沉淀到评测集。

比正面经验更有价值的是三个负面结果：

一，用 LLM 从原始表和查询日志自动生成语义层定义，产出看起来很合理，评测上净负向，因为生成的定义把他们想消灭的歧义又编码了回去。结论：文档可以让 Claude 起草，定义必须人来拍板。

二，给 agent 开放全部历史 SQL 的检索权限（几千份 dashboard、notebook 查询），准确率变化不到一个点。他们追查过原因：80% 的错题，答案其实就在语料里，agent 也确实读了，但还是不会用。问题到实体的映射没建立，给再多先例也没用。这一个实验改写了他们几个月的 roadmap。

三，维护松懈的代价：离线准确率一个月内从 95% 掉到 65%。修复的办法是把 skill 文档和数据模型放在同一个仓库，改模型的 PR 必须同时改对应文档，hook 强制检查。现在他们 90% 的数据模型 PR 里带着 skill 变更。

想到了一起的

两套系统在完全独立的条件下，长出来的骨架几乎一样。

瓶颈的判断一致。我在「让 Data Agent 懂业务的六层 Context」里写的是「企业数据问答的瓶颈是 context 质量，不是模型能力」，他们的表述是「准确性是 context 和验证问题，不是代码生成问题」。

传统数据工程没有过时。他们把这句话单独放在架构图下面：

Standard data engineering practices like dimensional modeling are just as important as they ever were.

维度建模、数据质量检查，这些标准实践和以前一样重要。我在「Agent 时代的数据架构」里的说法是「数仓没死，是下沉了」：湖仓、元数据、调度这些老基建，从数据团队的交付物变成了 Agent 消费的地基。

语义层人工把关。我们的语义层从第一天就是专家标注，指标的来源表、过滤条件、跨日口径全部结构化写死。他们替所有人验证了另一条路走不通：LLM 自动生成的定义是净负向。

路由结构。他们的 knowledge skill 是薄路由，把搜索空间收敛到每个域几十份文档；我们是 Manifest 加详情的两级结构，轻量索引全量加载，命中后按需拉取。名字不同，解决的是同一个问题：检索失败。与其让 agent 在百万字段里搜，不如先把空间收敛到几十个候选。

ETL 代码是最权威的语义。他们把血缘列为语义层之外信任度最高的参考面；我们的 L3 直接从调度系统拉每张表的产出 SQL，反推字段的真实含义。人工标注会过时，生产数据的代码不会说谎。

业务上下文。他们说这是「被低估最久的一层」，我们的 L4 域知识层放的就是这个：分析框架、已知波动（周末推送量下降属正常）、口径陷阱（两个 DAU 有重叠不可相加）。

评测的思路也一致：LLM judge 判语义等价而非 SQL 逐字比对，「知道自己答不了」也算一种正确，用户的纠错自动变成评测候选。

该抄的作业

四点值得学习。

第一，维护没有被当成工程问题。一个月 95 掉到 65，这是我读全文记得最牢的数字。我们的知识更新链路是变更通知、人工确认、agent 改文档，闭环靠人推。他们是把文档和数据模型绑在同一个 PR 里，hook 强制。前者是提醒，后者是纪律。我们的 context 也在腐烂，只是还没量化过腐烂的速度。

第二，回归验证的纪律。我们的评测系统有 diff 能力，改一版 context 跑一遍对比，但没有制度化到「每个 skill 改动的 PR 必须带评测 delta」。他们靠这个挡住了一类很隐蔽的退化：好心的文档补充让效果变差。他们连续三轮文档精修都是净负向，文档在变长，不在变好。没有这条纪律，这种退化根本发现不了。

第三，对抗审查。用 32% 的 token 和 72% 的延迟买 6 个点的准确率，这笔账在自助分析场景是划算的：错误答案被业务方拿去做决策，成本远高于此。他们还试过换个便宜模型做审查者，准确率收益丢了大半，延迟没省多少。我们没有这个环节，至少高风险问题上值得加强。

第四，来源标注。每条回答末尾标明数据来源的层级（语义层、治理过的表、还是现场探查）、数据新鲜度和责任人。它不让答案变得更对，但让使用者知道该信几分。最危险的失败模式是静默失败：答案错了，但看起来合理。Anthropic 也承认对此没有完整解法，来源标注是少数可用的缓解手段。这一条我们已经做了：每次问答末尾的口径说明会给出指标定义、来源表、过滤条件、数据分区，甚至会主动声明哪些维度拆不了、为什么。对照下来差的是最后一步：一是来源没有分信任层级，治理过的指标和现场探查拼出来的结果，在使用者眼里应该长得不一样；二是缺一个责任人字段，让使用者在答案可疑时知道该找谁。这不是从零建，是把已有的口径说明升级成分级的信任标注。

也有几处是路线不同，无关高下。他们的文章只覆盖分析问答这一段，数据到执行的链路、企业内的权限管控、多引擎适配都没有涉及，这些在前面提到的「Agent 时代的数据架构」里写过。记忆机制也不同：他们的纠错直接修源头文档，我们的 memory 在运行时召回、高频条目再沉淀到源文件，前者干净，后者响应快，各有取舍。

给要做这件事的团队

一定要做的，两边用不同的路径得到了几乎相同的清单。

收敛口径。把「收入」从四十个候选变成一个治理过的答案，这一步做完，歧义问题消失大半。我之前叫它熵减，他们叫 canonical datasets，同一件事。

语义层定义人来写。模型可以起草文档、提示遗漏，口径的 owner 必须是人。

先有评测再铺场景。每个域几十条问答对，按域设通过率门槛，不达标不对业务方开放。很多团队搭好了华丽的分析环境，却没有任何手段知道自己的 agent 准确率是多少。

维护机制和系统同一天设计。上线那天 95%，放着不管一个月后就是 65%。文档跟数据模型同仓库、同 PR，是目前看到最有效的做法。

容易踩的坑，他们踩过或绕过的：把历史 SQL 一股脑喂给 agent 指望它自己学会（准确率变化不到一个点）；用 LLM 自动生成指标定义（净负向）；无限堆文档（越堆越差）；为当前模型的缺陷过度建设基础设施（模型一升级这些投入就作废，先想清楚自己等不等得起）。

数据从业者的工作会变成什么样

那篇文章里有一句容易漏过的话：数据模型的最终用户不再是数据专家，而是替各种水平的人干活的 agent。这意味着结果的正确性不能再指望用户把关：以前分析师看到一个不对劲的数字会去查，现在业务方拿到一个看起来合理的数字，直接就用了。把关没有消失，是从消费端挪到了生产端，挪到了数据团队手里。

这解释了他们文章里人的位置。通读全文，人出现的地方全是把关环节：拍板语义层的定义，审 agent 起草的文档 PR，给评测标注真值，按域为上线质量负责，在给管理层的结论上签字。写 SQL、找表、跑查询这些执行环节，人几乎不再出现。翻译类的工作（把业务问题翻成 SQL）被自动化了，把关类的工作（口径、真值、责任）在增值。

Anthropic 的数据科学团队把省下来的时间投到了因果建模、预测和机器学习。这是这篇官方博客给出的版本。它没有回答的问题是，把关岗位比翻译岗位少得多，多出来的人去哪里。