最近做 Agent 评测时，我遇到一个很具体的问题。

同一个 skill，同一个模型，分别跑在公司里两套 agent 架构上。任务一样，提示词一字没改。反复跑了很多轮，一套稳定，另一套时好时坏。

问题集能告诉你哪道题答错了，但很难告诉你为什么错。要继续往下追，就必须回到 Trace：看 agent 中间走过哪些步、做过哪些判断、调了哪些工具、用哪份中间结果支撑了结论。

这也是我最近越来越觉得 Agent Observability 的量化至关重要。

在公司内部做这种归因，天然是小样本。你看的只是自己的问题集、自己的 skill、自己的架构。它能解释一个具体问题，但很难支撑一个更大的判断。

凑巧的是，Anthropic 的经济研究团队 在 2026 年 6 月 16 日发了一篇 Claude Code 研究。样本是大约 40 万次 session、约 23.5 万名用户，时间从 2025 年 10 月一直铺到 2026 年 4 月。

《Agentic coding and persistent returns to expertise》

它不是专门讲 Agent Observability 的文章，但它提供了一个难得的大样本视角：如果把会话拆成轨迹看，很多只看最终输出看不到的差异，会浮出来。

Anthropic 看了 40 万次 session，过程差异是什么？

大多数人读这篇文章，可能会关注一个结论：不同专业度的用户，和 Claude Code 协作的方式不一样。专家用户更能让 Claude 做更多工作，也更能把任务推进到成功。

但我自己读下来，最吸引我的不是这个结论本身，而是它的测量方式。

他们没有只看最后交出来的代码，也没有简单问一句“这个 session 成功了吗”。他们真正做的，是把一次次 Claude Code 会话拆成了可分析的轨迹指标。

Anthropic 做的第一步，是把这些会话变成一行行结构化数据。

他们不只看最后有没有交付代码，而是拆出了几类问题：用户在做什么任务，用户在这个任务上有多专业，Claude 触发了多少动作，谁在做规划决策，谁在做执行决策，最后有没有成功，以及成功有没有留下硬证据。

这才是我觉得这篇研究真正值得看的地方。

它不是在多存日志，而是在把 agent 的运行过程变成可分析的指标。

第一层：先把 Trace 变成变量

Trace 如果只是一大段过程记录，本质上还是原材料。真正能进入评测的，是被结构化之后的变量。

Anthropic 的做法，可以理解成先把一段会话拆成三类问题。

第一类，人在什么位置上。

比如用户的职业是什么，用户在这个具体任务上的专业度是什么。这里有一个非常关键的设计：不能因为用户在写代码，就把他判成软件工程师。

一个市场同学让 Claude 写脚本分析投放数据，他的工作任务可能涉及代码，但他的职业语境并不是软件工程。这个区分很重要。否则最后得出的结论就会被污染：你以为是在比较“软件工程师和非软件工程师”，其实只是把“写了代码的人”都塞进了软件工程师那一栏。

第二类，活本身是什么。

这个 session 是在写代码、修 bug、测试、部署，还是在分析数据、写文档、规划改造？任务类型不一样，难度和成功标准都不一样。如果不拆清楚，后面比较专家和新手的成功率，很容易把任务差异误认为人的差异。

第三类，结果怎么样。

会话最后看起来是否成功？有没有失败信号？有没有硬证据证明它真的成功？这些不是一个问题，而是几组不同的问题。

这就是测量层的价值。

它把一段不可统计的 transcript，变成了一组可以继续分析的变量。

如果没有这一步，后面所有“成功率”“专家差异”“agent 质量”的讨论，都会很虚。

第二层：不是问“成功了吗”，而要问“能证明成功吗”

这篇研究里，我最喜欢的指标，是 verified success。

因为它非常适合拿来解释 Agent Observability 到底在观测什么。

Anthropic 没有简单问一句：这个 session 成功了吗？

因为 agent 的成功本来就很滑。

代码写完了，不一定能跑。用户没有继续追问，不等于满意。最终输出看起来完整，也不代表中间没有走偏。更麻烦的是，有些任务可能真的成功了，但没有留下足够硬的证据。

所以他们把“成功”拆成两个问题。

第一个问题是：这次会话看起来是否达成了用户目标。

第二个问题是：有没有足够硬的成功证据。

只有同时满足这两个条件，才算 verified success。

换句话说：

看起来成功，只是第一道门。

留下可验证证据，才过第二道门。

这个设计很克制。

它宁可漏掉一部分“可能真的成功了，但证据不足”的会话，也不轻易把“看起来没问题”当成真实成功。

所以 verified success 不是普通意义上的成功率，而是一个更保守的下界。它回答的不是“Claude Code 到底成功了多少”，而是“有多少 session 既被判定成功，又留下了可以被验证的硬痕迹”。

这件事很重要。

因为它把 Agent Evaluation 从“看起来对不对”，推向了“有没有证据支撑它是对的”。这也是我理解的 Agent Observability：不是相信最终答案，而是要求 agent 在过程中留下可以追溯、可以验证、可以归因的证据。

第三层：过程差异，才是最终答案装不下的信息

有了前面这些变量，Anthropic 才能继续往下看：不同专业度的人，到底是怎么使用 Claude Code 的。

第一组是动作链长度。专家用户每发一条 prompt，平均会触发约 12 个 Claude 动作；新手大约 5 个。同样一句话扔进去，专家手里的 agent 链条要长出一倍多。

第二组是决策归属。规划层面的决策，大约七成由人做出；执行层面的决策，大约八成交给 Claude。

同一个 Claude、同一类任务，新手和专家最后交出来的东西，可能都“能用”。但他们走到答案的路，长度不一样，决策分工不一样，动作结构也不一样。

如果只看最后代码能不能跑、最后答案像不像样，你很难知道专家到底强在哪，新手到底弱在哪。

专家并不是简单地“多写提示词”，也不是单纯地“让 Claude 多干活”。更准确地说，他们把更多执行动作交给 Claude，但把更关键的规划判断留在自己手里。

问题集能告诉你“错了”。

Trace 才可能告诉你“为什么错”。

Metrics 则让这些 Trace 变成可以比较、可以统计、可以复盘的对象。

第四层：

真正要看的，是控制之后还剩下什么

但光有 metrics matrix，还不能马上下结论。

看到专家用户的 verified success 更高，并不等于可以直接说：专家更会用 agent。还有一个更朴素的解释：专家做的任务，本来就更容易成功。

所以 Anthropic 后面真正要做的事，是控混杂。

它不是只比较“专家 vs 新手”，而是逐步把任务类型、任务价值、月份、任务职业、用户职业这些因素加进去，看专业度和 verified success 之间的关系还在不在。

如果一加控制，专业度系数就塌了，那说明原来的差异很可能不是专业度带来的，而是任务不同带来的。比如专家只是挑了更容易、更适合 Claude Code 的活。

但结果不是这样。

不加控制时，专业度每升一级，verified success 大约增加 4 个百分点。把任务类型、任务价值、时间、职业这些因素逐步加进去后，这个数仍然稳定在接近 4 个百分点。

这说明，专业度差异不是被任务差异完全解释掉的。

也就是说，matrix 的价值不只是“记录得更细”，而是让研究者有能力问一个更严肃的问题：

这个差异到底来自人，还是来自活？

没有这张 matrix，你只能看到专家更成功。

有了这张 matrix，你才能继续追问：专家更成功，是因为他更懂任务，还是因为他做的任务更容易？

这才是 metrics matrix 真正有用的地方。

它让 Agent 评测从“看结果”走向“做归因”。

最后：

Trace 不是评测，Metrics Matrix 才是评测的起点

原始 transcript 只是过程记录。

Trace 只是让你能回放过程。

Metrics Matrix 才让这些过程变成可以比较、可以统计、可以归因的数据。

每一行，是一次 session。

每一列，是一个经过设计的变量。

哪些列描述人。

哪些列描述任务。

哪些列描述过程。

哪些列描述证据。

哪些列描述结果。

这张矩阵设计得越好，agent 的质量问题就越容易被看见。

这张矩阵设计得越粗，评测就越容易退回到“感觉它好像更准”。

这可能才是Agent Observability的起点。