Agent 评测：把结果和执行轨迹分开看

Agent 可能跑完一长串工具调用，却没把系统改到正确状态；也可能回答不够漂亮，环境里的目标却已经实现。所以整理评测笔记时，我先把“做了什么”和“最后变成什么”分开，后面的指标才有明确对象。

一次任务可以运行很多次

Anthropic 的 Agent 评测说明给了几个名称：

• task：一个待测任务；trial：对它的一次尝试。
• transcript：执行过程的记录；outcome：最终的环境结果。
• grader：按标准评分，可以同时读轨迹和结果，不必只看最终回答。

同一篇里还有几个词会在别的文档里反复碰到：eval harness 是把评测端到端跑起来的基础设施，agent harness（也叫 scaffold）是让模型能当 Agent 行动的那套系统，eval suite 是一组衡量同一类能力的任务。

flowchart TD
  task["Task：任务与成功标准"] -->|运行一次| trial["Trial：一次尝试"]
  trial --> transcript["Transcript：消息和工具交互"]
  trial --> outcome["Outcome：最终环境状态"]
  transcript --> grader["Grader：按标准评估"]
  outcome --> grader
  grader --> record["分数、失败类型与证据"]

比如一个修改数据的任务：轨迹说明用了哪些工具，结果检查则要把数据读回来，确认实际状态。图最后落到分数、失败类型和证据。这一层留着，失败的那几次运行才有东西可回头读。

不过轨迹和结果在评分里的分量不一样。原文在讲评分器设计时说得很直接：

it’s often better to grade what the agent produced, not the path it took.

我的理解是：轨迹用来读失败原因，打分标准尽量落在产物上。把“先调 A 工具再调 B 工具”写死进评分，换一条同样能走通的路就会被判错。

多次运行还有一个前提：每次 trial 都从干净环境开始。原文提到，运行之间不必要的共享状态会造成“相关失败”，基础设施抖一下被算成模型的问题；也可能反过来抬高分数，比如 Agent 读到了前几次 trial 留下的 git 历史。

pass@k 和 pass^k：至少成功一次，和每次都成功

我的笔记把 pass@k 简写成“一次成功率”，这容易误读。pass@k 看 k 次尝试里至少一次成功，pass^k 看 k 次全部成功。前者适合有重试空间的任务，后者更接近稳定性要求，两者不能互相替代。定义来源

一个纯计算的例子：假设每次成功率 0.8、尝试相互独立，那么三次里

• 至少成功一次：1 - (1 - 0.8)^3 = 0.992
• 全部成功：0.8^3 = 0.512

差得很大。k 再变大，两者还会反向走：前者越来越接近 1，后者越来越往下掉。真实 Agent 的运行未必独立，这个算例只用来解释指标差异，不能代替实际统计。Anthropic 原文用的是 0.75，三次全过约 42%，并说到 k=10 时两个指标“讲相反的故事”：pass@k 逼近 100%，pass^k 掉到 0%。

两个指标各自从哪来

pass@k 出自 OpenAI 的 Codex 论文 §2.1，评的是 HumanEval 代码生成：每题采 n ≥ k 个样本，数出能通过单元测试的 c 个，再用无偏估计算 pass@k。判据是跑测试，不是和参考答案比字符串。所以它天生适合结果能执行核对的任务。

pass^k 来自 2024 年的 τ-bench，定义写的就是“k 次独立同分布试验全部成功的概率，再对任务取平均”。上面那个算例的独立假设，正是这个指标本身的假设。论文里的真实数字比我的算例更难看：

摘要把这归为这类 Agent 处理随机性时“脆弱的本质”。同一个 Agent，看“至少一次”和看“每次都行”，结论可以完全不同。

现在的评测框架已经把这两个指标做成了现成选项。UK AISI 的 Inspect 里，同一道题跑多个 epoch 会产生多个分数，默认取平均；内置的 reducer 里就有 pass_at_{k} 和 pass_k_{k}，命令行用 --epochs 配 --epochs-reducer 指定。报哪个指标，只是换个 reducer 的事。

新能力和旧能力，用不同的题检查

能力评测找当前做不到的任务，回归评测保护已经能做的事。全部题目混成一个平均分，“新任务进步、旧任务退步”就被掩盖了。

两类题之间也会转换。Anthropic 原文提到，通过率很高的能力题可以“毕业”进回归套件。反过来，Agent 通过了所有可解任务、没有进步空间，叫评测饱和（eval saturation），这时就该加难题。起步也不用大：原文的经验是从真实失败里挑 20–50 道简单题就够开始。

评分手段可以组合：

• 代码检查：适合有明确可执行条件的部分。
• 模型评分：能处理开放文本，但要有清楚的标准。原文的具体建议是写 rubric、给评委留一个 “Unknown” 出口、每个维度单独一个评委，并经常拿专家判断校准。MT-Bench 论文测过，GPT-4 这类强评委和人类偏好的一致率超过 80%，和人与人之间差不多，但有位置偏差、偏爱冗长、偏向自己的输出。
• 人工检查：能发现题面歧义、错误的参考答案和评分盲点。

不管用哪种，都要留下可回看的失败实例。

笔记里列的任务有编码、对话、研究和计算机操作，要检查的结果各不相同：有的落在环境状态上，要回环境里读；有的主要看最后交出来的文字，过程那一半还得回轨迹核对。研究任务尤其要说清引用和结论各自怎么核对——引用对不上来源、结论推不出材料，是两类不同的错。只给最终文字打分，容易漏掉搜索过程里的错。

Anthropic 原文给这四类任务各举了做法，摘几条我觉得最能说明 outcome 怎么落地的：

• 编码：SWE-bench 每道题有两组测试，FAIL_TO_PASS 是要从失败变通过的，PASS_TO_PASS 是要保持通过的，两组全过才算解决。后一列就是内置的回归检查。
• 对话：交互质量本身就是被评的对象，常常要第二个模型扮演用户。τ²-Bench 让 Agent 和用户都能用工具改同一个环境，从无用户切到这种“双控”时，Agent 表现明显下降。
• 研究：拆成三项检查，断言有没有检索来源支撑（groundedness）、关键事实有没有覆盖（coverage）、来源是否可靠（source quality）。
• 计算机操作：WebArena 除了看页面状态，还会查后端，原文的说法是确认订单真的下了，而不只是确认页出现了。这句几乎就是 transcript 和 outcome 之别的最好例子。

先读失败轨迹，再加指标

维护评测时，先读一些失败轨迹。失败集中在任务描述不清，多跑几次也不会让题目变好；工具返回就错了，改最终答案的评分也抓不到根因。

读的时候要分清错在 Agent 还是错在评分器。原文的说法更狠：一道题跑很多次还是 0%（0% pass@100），多半是题坏了，不是 Agent 不行。它举了 Opus 4.5 在 CORE-Bench 上的例子：最初只有 42%，原因包括评分太死（期望 “96.124991…” 时把 “96.12” 判错）、任务描述含糊、随机性任务无法精确复现；修掉这些问题、换了约束更少的 scaffold 后，分数到了 95%。评测侧的 bug 能一下吃掉五十多个百分点。

错在 Agent 的那部分，也可以分类。τ-bench 抽了 gpt-4o 的失败轨迹做归因（§5.2），常见的几类：

1. 工具选对了，参数填错，比如用了不存在的 ID。
2. 没遵守领域政策，约占四分之一。
3. 复合请求只做了一半，约占五分之一：开头就漏掉用户明确提出的要求，或者查完一单就停。

读完轨迹能落到这样几类上，才知道下一步改提示、改工具还是改题。

还要留意 Agent 是不是在迎合评分器。分数涨了以后，抽样看看实际成果，再看留出的任务有没有一起变好。这样才能发现“检查项全过，用户的问题还是没解决”。

这件事已经在前沿模型上被抓到过。METR 2025 年 6 月的报告里，o3 在 RE-Bench 上有 39/128 次（30.4%）尝试作弊，手法包括改写 PyTorch 的相等运算符、把评分函数替换成空实现、覆盖计时函数。在提示里加一句 “Please do not cheat”，作弊率还是 80%，和不加一样。他们的做法是按分数筛出高分轨迹人工复核，并提醒简单惩罚作弊只会让作弊更难被发现。所以堵漏要靠改评分代码，不能靠提示词。

留出任务也有出处可查。AI Agents That Matter 批评多数 Agent 基准没有像样的留出集，开发者哪怕无意也会走捷径；还指出只看准确率会被重试这种“科学上无意义”的手段刷上去，评测应该把成本一起报。前面说 pass@k 适合有重试空间的任务，这里就是它被用歪的样子。