一篇"不太 Anthropic"的文章
Anthropic 的博客通常是产品发布或安全研究。这篇不太一样——纯工程实践分享，讲他们内部如何让非技术人员通过 Claude 直接查数据，而不需要写 SQL。不是" Claude 能做什么"，而是"我们踩了哪些坑、怎么解决的"。
这背后有一个判断：给 Claude 接上数据仓库然后说"去回答问题"，准确率不到 21%。这篇文章讲的是他们如何把这个数字拉到 95% 以上。
三种失败模式
他们把分析型 agent 的失败归纳为三类：实体歧义——用户问"产品 X 的营收"，agent 把"营收"映射到了错误的表或列；陈旧性——skill 或 reference doc 写的时候是正确的，但数据模型在不断演进，一个月不维护准确率从 95% 漂移到 65%；检索失败——正确答案存在于某个地方，但 agent 找不到它。
四层解法
第一层：Data Foundations——从源头消除歧义
核心动作只有一个：收敛。把 40 个可能回答"营收"的表缩减成一个 canonical 数据集，一个概念对应一个权威答案。这看似简单，但执行难度极大——需要强制治理：工具链必须把 agent 路由到 canonical 数据集、CI 必须拦截绕过权威层的变更、下游团队必须在权威层上构建否则要解释为什么。
他们还有一个关键实践：所有数据代码同 repo。建模、语义层、参考文档、仪表盘定义都放在同一个仓库里，一个 PR 改了模型，必须同步改下游文档，否则 CI 直接拦住。
第二层：Sources of Truth——agent 的参考书目
按可信度排序：语义层排第一，如果问题能映射到已定义的指标，agent 直接调函数拿一个数字。一个有趣的失败：他们试过让 LLM 自动从原始表和查询日志生成指标定义，结果产出了"看起来合理但编码了你想消除的歧义"的定义——净效果是负的。结论：文档可以让 Claude 起草，但定义必须人 owns。
血缘图谱排第二。语义层覆盖不了时，agent 通过血缘关系推理出该从哪个上游模型聚合。查询历史排第三——直接给 agent 做非结构化检索，准确率提升不到 1 个百分点。正确做法是蒸馏成结构化的 per-domain reference doc。
业务上下文被他们称为"最被低估的层"。不理解"Q2 launch"指的是哪个产品、两个部门对同一个词有不同定义——agent 能回答字面意思，但不是真正想问的。
第三层：Skills——从 21% 到 95% 的关键跳板
如果 Sources of Truth 是"知识"（什么指标是什么意思），那 Skill 就是"方法"（先查什么再查什么、遇到歧义怎么处理、一个完整的分析长什么样）。
没有 skill，准确率不超过 21%。加上 skill，稳定 95% 以上，部分领域接近 99%。
他们设计了成对的 skill：一个知识 skill 做薄路由（"先查语义层，没有覆盖的话这里有 30 个参考文件"），一个 unbook skill 编码资深分析师的流程（澄清问题→找数据源→跑查询→对抗性审查子 agent 审查结果）。
维护是生死问题。Skill 描述的数据模型每天都在变，不维护几周就错。他们的解法：skill markdown 文件和数据模型放同一个 repo，改模型的 PR 必须包含 skill 变更（code review hook 强制），90% 的数据模型 PR 现在会带上 skill 变更。
第四层：Validation——怎么知道还在出错
离线 eval 套件。每个 domain 有几十道 QA 对，锚定快照日期防止数字漂移。每次跑结果存到仓库表里——skill 版本、git SHA、model ID、通过率全部记录。"那个改动有用吗"变成一个查询，可以看到准确率的时间序列。
每个 domain 必须达到 ~90% 的离线准确率才能面向 stakeholder 上线。消融实验方法论值得一提：固定 eval set，每次只改一个变量，一小时跑完——用数据替代争论。
几个值得带回自己团队的洞察
查询历史作为直接检索源几乎无用，但蒸馏后的参考文档价值巨大。这跟 RAG 领域"原始文档 vs 精加工知识"的争论完全一致。Raw retrieval 太嘈杂，structured reference 才是 agent 能用的知识形态。
让 LLM 自动生成元数据定义是危险的。它会把歧义编码成看起来合理的定义，让你以为问题解决了，实际上在系统里固化了错误。人类 ownership 不可替代。
Skill 和数据模型必须同 repo 同 PR。这个实践的成本极低（code review hook 一次搞定），但对防止陈旧性至关重要。一个月不维护准确率掉 30 个百分点。
Business context 是 agent 准确性的隐藏变量。纯技术方案把数据模型做到极致，但 agent 不理解"为什么问这个问题"和"这个指标在业务语境中意味着什么"，准确率天花板很低。
这篇文章的定位不是" Claude 多厉害"，而是"我们花了多少工程力气才让 Claude 在数据分析场景里真正可靠"。对正在构建企业级 agent 系统的团队来说，这是目前公开的最完整的一套实战方法论。