Anthropic 最近公开了基于 Claude 的分析智能体实践，它接管了公司内部 95% 的商业分析查询，整体准确率也稳定在约 95%。这看似是数据分析的质变时刻。

但我盯着这篇博客看了很久，真正有趣的，是另一个几乎没动的数字。他们把几千条历史 SQL、旧 Dashboard、数据转换代码全开放给模型，日志显示模型逐个都读了，准确率的正负波动不到 1%。

历史 SQL 留下了答案，却没留下“为什么这么算”

先把那个反直觉的实验说清楚。Anthropic给Agent 直接开放了整个 dashboard、transformation 和 analyst-notebook SQL 的检索访问，涉及数千个文件；日志显示模型每次回答前确实读到了这些内容。但准确率在正负方向上只波动了不到 1 个百分点。

更耐人寻味的是，他们扒开那些答错的问题——约 80% 的情况下，答案确实已经在语料库里，但“answer present”并没有让模型更容易答对。

原因藏在一个区别里。历史 SQL 只留下了答案的痕迹，没留下当时那个人为什么这么算的理由。模型能看见结果，看不见判断。它知道“以前有人这么算过”，却不知道“这一次为什么也该这么算”。

这跟很多人对 Data Agent 的期待正好拧着。大家以为把库连上、把历史查询喂够，模型自己就能学会取数。可业务群里最常见的抱怨恰恰是：工具连上了库，却连最基础的活跃客户都算错。它不缺答案，缺的是“按谁的算法才算对”。

Skills 之所以有用，是它把“该听谁的”写了下来

Anthropic 的解法叫 Skills——一份份 Markdown。但它真正管的，远不止“有哪张表、哪些字段”。它写下来的是判断：什么样的回答才算对，哪些对象必须排除，哪些例外必须保留。问“上个月的活跃客户有多少”，它会回：按规范，排除已知的免费邮箱注册用户，但保留像 anthropic.com 这样的自定义企业域名。这等于把一条原本只在老分析师脑子里的判断，写成了模型能照着守的规矩。

如果放到模型评测里，这套“什么才算对”的判断，就叫 Rubric——评分标准。做模型训练和评估的人，几乎都认一条朴素的经验：决定一道题答得好不好的，从来都是评分标准写没写清楚，答案本身说了不算。Anthropic 的 Skills，本质上就是一份写给 Agent 的评分标准。没有它，Claude 在他们评测里的准确率不超过 21%；写清楚之后，整体稳定在 95% 以上，某些领域接近 99%。

但这份评分标准是活的。Skills 一个月不维护，离线准确率就从约 95% 滑到约 65%。他们也试过让大模型自己生成定义，结果是净负面——模型只会把原始表里本就模糊的口径，原封不动再编码一遍。所以他们认下一条很朴素的原则：文档可以让 Claude 写，但定义得由人来拥有。

倒过来读，这篇博客其实是一套评测工程

一旦拿到这个视角，再回头读 Anthropic 这篇博客，你会发现它几乎是一本评测工程手册——Data Agent 只是接进这套工程的考生，反复打磨的，是考卷和评分流程。

他们给每个业务域建了离线评测集，把标准答案锚死在快照日期上，免得底层数字一变、答案跟着漂；哪个域过不了大约 90% 这条线，就不许把 Agent 放给业务方。答案出门前要过一道对抗式审查，一个专门唱反调的评卷人把假设逐条挑战一遍——按他们披露的数字，这道审查多挣 6% 的准确率，代价是多花 32% 的 token、多等 72% 的时间，他们认了。答案落地时还带着出处：数来自语义层还是原始表、底层数据多新鲜、归谁管，等于把“按哪张评分表打的分”亮给提问的人。甚至业务同事在群里的类似纠正——“表用错了”“漏了过滤”——也会被一个定时跑的 agent 扫出来，变成新的评测样本和文档修订 PR。

所以 21% 到 95% 的跳变，与其读成 Claude 变聪明了，不如读成：这家公司第一次把“什么算对”写成了可执行、可回归、连不合规变更都拦得住的东西。模型没换，换的是考场。

但是，数据工作的评分标准，本来就没有标准版

到这儿，方法论好像很顺：把评分标准写清楚，模型就能答对。可任何做过数据的人都知道，最难的恰恰是这半句——写清楚。

写代码的评分标准是现成的，测试跑过就算数；数学题更干脆，答案唯一。数据分析的评分标准，从一开始就长在争议里。就说“活跃用户”：产品按打开 App 算，增长按完成关键行为算，商业化只认有付费动作的，风控还要先剔掉异常账号；到了管理层，要的又是能解释趋势的口径，不是最严格的那个。这时候模型没算错什么，它只是撞上一个事实——公司内部本来就没有一个说得清的标准答案。

“活跃用户”“流失率”“有效客户”，这些词背后全是业务判断。它们是公司内部一点点吵出来、又不断在变的共识，散在口径文档、SQL、权限系统、会议纪要和几个关键人的脑子里，还经常自相矛盾。这套判断从没被真正统一、写下、认账过。模型不缺答案，公司缺一张大家都认的评分表。

管口径的人，管不清基建，也碰不到权限

我经历过最无力的时刻，是拿着全公司确认过的标准口径，看着业务部门自己搭起一套逻辑相悖的报表。数据产品经理花三周梳理出统一的流失指标，业务侧转头用两行临时代码就绕过了官方底表。

这也是很多数据团队最尴尬的地方：管口径的人，管不清基建，也碰不到权限。

你可以把“流失率怎么算”写进规范，却未必能清楚地决定底层表怎么建；你可以要求大家用官方底表，却未必拦得住业务去查原始日志；你可以解释哪套口径更可信，却未必控制得了谁能导出、谁能二次加工、谁能拿着一份临时报表去开会。

口径从来不是一张中立的评分表。它背后站着人。业务希望指标能解释自己的动作，平台希望模型稳定好维护，安全希望权限边界清楚，数据团队希望口径统一，管理层希望答案够快、够能支撑决策。每一方都在说“这才是正确算法”，但他们嘴里的“正确”，根本不是同一个。

所以决定“什么算对”的权力，在大多数公司里通常是断开的：有人能定义指标，但管不住数据生产；有人能改模型，但未必承担业务口径；有人能管访问，但不一定知道用户是不是在错用。拆开看，每个人手里都攥着那张评分表的一截：一截管算什么，一截管怎么算，一截管谁能用。问题是，没有人真正拿着完整的一张。

Data Agent 一上线，这个断裂会被放大。过去业务自己绕口径，最多是几张报表对不上；现在 Agent 如果没有一套被承认、被执行的标准，就会把这种混乱批量生产出来。到最后，答案看起来更快了，背后的失控也更快了。

Anthropic 难复制的，是让某一张评分表真的生效

所以 Anthropic 真正强的地方，不在写了多少 Markdown，在它有能力让这些判断进入发布流程，变成所有人绕不过去的东西。

在他们的工作流里，绝大多数数据模型变更，都被要求同步更新对应的 Skills；只改了底层 SQL、没更新教 AI 算数的文档，这段代码在审查环节就会被打回。打个比方，有人改了一段算支付指标的代码却没动文档，提交会被一个 hook 拦下来，大意是：模型变了，规则没跟上，先补再合。这靠的是把数据代码、语义层、参考文档、关键看板定义尽量收进同一套工程流程——模型一动，文档、评估、下游影响一起被检查。换成大多数公司，这相当于把口径治理嵌进发布流程本身，让它不再只是飞书文档里的一句话。

大多数公司缺的，其实从来不是 Markdown——是让某一张评分表真的生效的那纸组织授权。所以我对“AI 帮数据民主化”这种话始终谨慎：业务方一旦能随意绕开标准口径取数，没有执行权的数据团队，只能眼睁睁看着 Agent 把混乱的口径再放大一遍——原本手工才会犯的错，现在以更快的速度批量产出。

先看它分不分得清“官方口径”和“探索口径”

回到落地。真要评估一个 Data Agent，比 SQL 生成成功率更该看的，是它分不分得清“官方口径”和“探索口径”。业务探索没有错，错的是让探索口径冒充正式指标。所以官方指标得默认走标准算法，临时口径可以支持，但要被明确标记成不能拿去汇报的结果。

比如有人说“按我的办法算一下华东区上月流失率”，一个成熟的 Agent 不该闷头生成一段没人背书的 SQL。它大致会先回这样一句：华东区流失率已有官方口径，默认按它算；你要的临时算法我也能单独跑，但结果会标记成非正式分析，不能用于经营汇报。前者执行规则，后者只是有求必应——这正是 Data Agent 和普通 SQL 生成器的分野。说穿了，它每次回答都在向你交代：这个数，按的是公司认账的那张评分表，还是你临时画的那张。

真要推 Data Agent，先别急着接全公司的盘子。先看清自己缺的是哪一权——说了算、改得动、还是拦得住——要么把缺的那块补上，要么把战场先缩到自己有全权的那一小块，跑通了再往外扩。

所以今天再看 Anthropic 这个 95%，比起它怎么做到，我更在意它照出了什么。当 AI 开始替公司回答数据问题，它执行的，是一套关于“什么才算公司事实”的判断——而这套判断，在大多数组织里并没有一个干净、统一、有人认账的版本。

它从来不是帮你绕过数据治理的捷径，而是把你过去没定清楚的东西，提前摊开的一次压力测试。公司从来不缺评分表，每个部门脑子里都揣着一张；缺的是把其中一张摆上桌、让所有人认账、再让它进入流程的那个动作。

DataAgent 没有创造这个难题，它只是让它没法再拖。