Trajectory Eval 工程 · 怎么知道 agent 跑得好不好

0. 评测是从「能跑 demo」到「敢上生产」的桥

先把这一章放进整条路书的坐标里。从第二站到第三站,你给 harness 加了循环控制、工具、沙盒、对抗防御、context 管理、记忆、多 agent 协同。每加一样,你其实都在心里默默做了一次判断:这样改,agent 变好了还是变坏了?但你拿什么判断的?多半是跑几个例子看着顺眼。这在搭原型时够用,可一旦要把 agent 交到真实用户手里,看着顺眼就是在拿声誉和钱赌博。评测就是把看着顺眼换成有证据地知道的那道工序,它是 agent 工程里从 demo 到生产之间唯一的桥。

这座桥有一个容易被忽略、却定义了整章边界的事实:你评测的从来不是模型一个东西。Anthropic 在它那篇评测方法论里把话说得很直白,当我们评测「一个 agent」时,我们评测的是 harness 和模型作为一个整体在协同工作。这句话本身就坐实了整条 #8 路书的命题,模型加 harness 才等于 agent;它也定义了这一章的两个核心任务,既要会度量这个联合体,又要在它失败时分得清到底是 harness 坏了还是模型不行,这就是 第 5 节 的归因。

为什么说这是真实岗位能力而不是学术兴趣?四大实验室的 agent 岗里,为评估生产级 agent 表现搭建框架是反复出现的一条硬要求,Anthropic 直接设了专门做评测基础设施的岗,OpenAI、Sierra、Scale AI 在 2025 到 2026 年把 agent 评测做成了独立的工程方向。会用一个现成 benchmark 跑个分,和会搭一个你敢信的评测回路,是两种能力,后者才是这一章要给你的。这也是评测这门工程的来由:当 agent 真的开始进生产、失败开始有真实代价,跑起来就行那套就撞了墙,不可观测、不可度量的 agent 没法迭代,评测于是从可选变成了生死线。

1. 为什么 agent 评测比单轮难一个量级

先建立一个对比,你才会明白难在哪。一个传统的单轮 LLM 评测,像一道有标准答案的填空题:给一段输入,看一次输出,跟参考答案比对,对或错。agent 评测要问的不是这个,它要问的是一段没有唯一正确路径、可能每次都不一样、而且 agent 自己会谎报完成的多步操作到底成没成。难度来自四个结构性的差异,把它们讲透,后面所有方法才有为什么。

第一个差异是部分正确。单轮非对即错,agent 任务却天然分阶段,对了一半是常态而且有意义。Anthropic 举过一个一手的例子:一个客服 agent 正确地识别了问题、核验了客户身份,但最后没能完成退款,它明显比一个一上来就失败的 agent 更好。可如果你只用一个二元的解决了没来打分,这两种 agent 会被判得一样烂,你也就抹掉了最宝贵的改进信号,它到底进步到哪一步了。所以给阶段性的里程碑打分,是 agent 评测比单轮多出来的第一道工程题。

第二个差异是非确定性。同一个输入,agent 可能走出意义上完全不同的执行路径,因为采样有温度、工具返回有时序、环境状态会变。后果很要命:一次成功根本不代表它稳定成功。这就把评测从测一次变成了测一个分布,你必须跑很多次,再用统计去描述它。一个广为引用的数字能让你立刻有体感:一个单次成功率 90% 的 agent,连续跑 8 次全部成功的概率只剩约 43%,因为 0.9 的 8 次方就是 0.43。平均表现和最坏情况下的可靠性,是两个完全不同的数,而生产环境要的是后者。

第三个差异最阴险,叫看着对其实错,它有两种假阳性。一种是结果假阳性:transcript 里 agent 说已经帮您订好票了,可真正的结果是环境的终态,是数据库里到底有没有那条预订记录。transcript 不等于真实结果,这是 agent 评测最容易踩的坑。另一种是过程假阳性:结果蒙对了,但路径是错的或者作弊的,靠运气、靠偷看了不该看的 git 历史、靠钻评分器的空子。结果对,掩盖了一个根本不可复现、不可信的过程。

第四个差异是失败的涌现性。agent 的每一步输出单独看都通顺、都合理,失败只在跨步累积时才显形:目标漂移、上下文腐烂、错误像滚雪球一样级联。后果是,一个只看最终输出的评测系统,会成系统地漏掉失败。2026 年逐渐形成的一个共识是,只按最终产出质量评测的 agent,通过的测试 case 比做完整轨迹评测时要多出两到四成,那两到四成,就是被最终输出盖住的失败。这是为什么必须做轨迹评测而不是输出评测的第一性论据,它也是轨迹评测这件事的来由:只看 output 会漏掉那么多失败,逼着评测的单位从输出下沉到整条轨迹。

把四个难点合起来,就是这一章的度量素养地基,我把它压成一句话:agent 评测测的不是模型聪不聪明,而是这个 harness 加模型的联合体,在一个有状态的环境里、重复很多次、走完整条路径之后,可靠地达成真实结果的概率。这句话里每一个限定词,都对应一个被单轮评测忽略、却被 agent 评测必须正面处理的维度:联合体对应归因,有状态对应查环境而非读 transcript,很多次对应 pass^k,整条路径对应轨迹,真实结果对应 outcome。这一章剩下的所有方法,都是这句话的展开。

2. 在什么粒度上量:粒度、能力维度、结果还是过程

2.1 三个粒度,加一根正交的能力轴

agent 评测从来不是一个分,而是一组在不同粒度上的度量。工程界收敛出三个层次,缺任何一层都会留下诊断盲区。最细的是步,一次 LLM 调用、一次工具调用、一次检索,回答的问题是这一步本身做对了吗,工具选对没、参数合不合法、检索召回了没。中间是轮,一个用户请求触发的完整一轮,回答这一轮端到端交付了对的结果吗。最粗的是轨迹,整条 episode 加上所有状态变迁,回答整个任务真的解决了吗、路径好不好、会不会崩。Arize 把两头的取舍讲得很清楚:一个只能在步粒度打分的评测系统没法评测 agent,而一个只在轨迹粒度打分的系统没法帮你定位到底是哪一步导致了失败。只有轨迹分,你知道它崩了却不知道崩在哪;只有步分,每一步看着都对、整体却跑歪了。成熟的评测在三个粒度上同时记录、同时打分。

粒度是在多大的单位上量,它正交于另一根轴,量哪一种能力。一个 agent 的能力可以拆成规划、工具调用、多轮交互、指令跟随四个维度,它们各自主要落在不同的粒度上。把这两根轴交叉起来,你得到的是一张度量矩阵,而不是一个孤零零的解决率。这件事的工程价值在于:解决率是这张矩阵的汇总分,而汇总分会掩盖维度信息。两个解决率都中等的 agent,可能一个是规划强工具弱、另一个反过来,它们的修法完全不同,按维度拆开诊断,价值远高于盯着一个总分。

2.2 结果还是过程:最重要的一对取舍

那到底该按什么给 agent 打分,它产出的结果,还是它走过的路径?Anthropic 给了一个一手的、反直觉的默认建议:优先评结果,而不是路径。理由是 agent 经常会找到评测设计者根本没预想到的合法解法,你要是死抠路径,就会误杀这些其实更聪明的 agent。但这里有一个必须钉死的区分,结果不等于 transcript。结果是环境的终态,是你去查数据库里有没有那条预订记录,而不是读 agent 最后那句已为您订好。判一个订票 agent,你得能观测并校验环境状态,这是 agent 评测和单轮评测在实操上最大的差异。

那什么时候需要补上对路径的检查?四种情况。结果假阳性需要路径来排除,结果对但靠看 git 历史作弊,只有看路径才发现。部分给分需要路径来给,任务没完成时看它走到哪一步。效率和成本是一等公民,同样的结果,用三倍步数和 token 的路径在生产里是真失败,而结果分看不出来。诊断需要路径,要修一个失败,你必须知道它崩在哪一步。所以工程上的结论不是二选一,而是配合:主分用结果,既防过度约束、又能容纳那些没预想到的合法解;再辅以过程信号,管效率、查作弊、给部分分、做诊断。纯过程评测脆,因为它过度拟合了你以为的正确路径;纯结果评测漏,因为它放过了作弊、也丢了效率和诊断信息。

2.3 把可靠性量出来:pass@k 还是 pass^k

上一节提过的非确定性,必须用统计度量落地,而这里有两个长得很像、含义却相反的指标。pass@k 是 k 次里至少成功一次的概率,它度量的是能力上限,也就是它到底会不会做,这个数乐观,适合早期看天花板。pass^k 是 k 次全部成功的概率,由 τ-bench 引入,它度量的是可靠性下限,也就是它是不是每次都做对。pass^k 等于单次成功率的 k 次方,随 k 指数衰减,对最坏情况极其敏感,而生产真正在乎的恰恰是它。

把这两条线放在一起,你会看到一个 agent 的两副面孔。还是那个单次 90% 可靠的 agent:它的 pass@k 几乎贴着 100%,看上去无敌;它的 pass^k 却一路滑到 8 次时的 43%。这就是为什么报 SOTA 时只报 pass@1 是一种误导,它把可靠性的塌方藏了起来。agent 能做和 agent 每次都做对,在生产里差着一个数量级,而 pass^k 就是把这个差距量出来的工具。后面你会看到,METR 度量任务时长的时候,80% 可靠度下能完成的任务长度,比 50% 可靠度下短大约 5 倍,那其实就是同一个 pass^k 现象,换到了任务能跑多长这根轴上。

2.4 rubric:给开放产出打分的脚手架

还有一类产出没法机械判定,比如一段开放式的分析、一轮对话的质量,这时候你需要一份评分量规来给过程或质量打分。好的量规有几个一手实践收敛出来的原则。维度要任务专属,而不是套用通用的有用性、流畅性、安全性,那是给聊天机器人设计的,一个目标导向的 agent 需要的是像事实准确性、引用准确性、完整性、来源质量、工具效率这种为任务定制的维度,这正是 Anthropic 多 agent 研究系统用的那套。判定要锚定在具体可观测的证据上,而不是凭感觉给个 7 分。而且通过失败这种二元判定,通常比 1 到 10 的打分更可靠,这一点 第 4 节 讲裁判工程时会展开。

3. Benchmark 全景(2026)+ 三条记分牌素养

现在你有了度量的语言,可以去看 agent 进展的官方记分牌了。但第一件要破除的迷思是:不存在一个单一的榜能告诉你「我的 agent 行不行」。存在的是一个 portfolio,每个 benchmark 量不同的能力层、各有不同的坑。下面这张表是 2026 年 5 月的快照,所有百分比都是点时刻值、跨 harness 和版本波动极大、而且多数受污染影响,只能当方向信号,不能当 SLA。

3.1 第一条:分数是 harness 的因变量,不只是模型

第一条记分牌素养是,分数是 harness 的因变量,不只是模型的。同一个模型,你给它加推理预算、加任务上下文、换个更好的 scaffold,分都会涨,OpenAI 在 GDPval 上实测过这件事。SWE-bench Pro 之所以要用标准化的 scaffold 加 250 轮上限,正是为了把这个变量摁住、好让模型之间可比。这条素养有两层含义:看到一个 benchmark 数字,先问哪个 scaffold 跑的,因为各家自报的分用的 harness 不同,根本不可比;更深一层,benchmark 数字本身就是 harness 工程的因变量,你优化 harness 就能涨分,这既是机会,也再次坐实了整条路书那句模型加 harness 才等于 agent。

3.2 第二条:污染与 validity,2026 的信任危机

第二条素养更尖锐,2026 年它已经到了信任危机的级别,分两面。一面是污染。SWE-bench 曾经的事实标准 Verified,任务的标准答案 verbatim 进了预训练语料,以至于业界广泛报道 OpenAI 不再报它的分;GAIA 的校验答案公开挂在 HuggingFace 上;能联网的榜,agent 直接搜到带答案的攻略页。污染能让榜分虚高 5 到 15 分。这就是为什么 2026 年出了 SWE-bench Pro 这样的抗污染继任者,用多语言、私有 startup 代码库(法律上训练方拿不到)、标准化 scaffold 来堵漏,同一个模型在 Verified 上 80.9% 而在 Pro 上只有 45.9%,差异全在污染、scaffold 和单跑还是标准化。一句话能概括这条素养:一个不带语境的 benchmark 分数,哪个变体、什么 scaffold、跑了几次,是营销,不是工程。

另一面更釜底抽薪,是榜本身能不能测对,也就是 validity。2026 年 4 月,UC Berkeley 用一个自动红队 agent 审了 8 个主流 agent 榜,结论是它们全都能被刷到接近 100% 而不真正解决任何一个任务。刷法每一个都是评测工程的反面教材:10 行 Python 就能让 SWE-bench 的所有测试报通过;把 curl 这个二进制换成一个 wrapper,Terminal-Bench 的 89 个任务全满;有个榜的校验器只检查最后一条消息是不是来自 assistant 角色、根本不看内容,于是发一个空 JSON 就能拿满;还有的榜直接把 agent 的输出拼进裁判的 prompt 又不做清洗,于是一句提示注入就让裁判复读你要的分数。Berkeley 给的比喻很精准:这就像 2005 年的 web 安全,人人都知道 SQL 注入可能存在,但没人去修,因为没人在看。

这两面对你的直接价值,在 第 6 节 你自己搭 eval 时会兑现,因为你会犯一模一样的错。所以记住这张反面清单:参考答案别让 agent 够得着,评分器别去 eval() 不可信的输入,LLM 裁判必须过一道清洗、否则 agent 能注入它(这一条直接接 Ch5 教的对抗安全),别用脆弱的字符串匹配,校验器要真查正确性而不是查个结构。会读榜这件事,包含知道榜会被这么钻、所以自己的 eval 要堵这些洞。

3.3 第三条:难度天差地别,按 workload 选榜

第三条素养是难度天差地别,所以要按 workload 选榜。OSWorld 已经逼近人类、SWE-bench Pro 还在 45%、Terminal-Bench 不到 65%,没有一个数字能代表 agent 智能。测 coding 用抗污染的 SWE-bench Pro,测客服守不守规用 τ-bench,测桌面操作用 OSWorld,测能不能替代专家产出用 GDPval,测长程任务的趋势看 METR。portfolio 思维,不是找一个榜信到底。

最后补一类容易被漏掉、却必须单独评的能力:记忆。Ch7 把记忆评测的归宿指到了这一章。这里有一个反直觉但关键的洞见,记忆不等于长上下文。NIAH、RULER 这类长上下文 benchmark 测的是在一次固定的超长输入上注意力够不够,而不是多会话地写入再检索这个闭环;一个在 LOCOMO 这种记忆榜上接近满分的 agent,放进真正需要拿记忆支撑后续行动的设定里照样崩。记忆评测还是 benchmark 素养最浓缩的案例:LOCOMO 上几家记忆产品公开互撕分数,而分数的差异常常来自检索参数(分块大小、Top-k)而不是记忆能力本身。结论还是那句,选型必须拿你自己的数据跑两三个对比,别信单一榜分。

4. LLM 裁判工程:从「会用」到「会验证」

4.1 验证裁判:用 Cohen's κ 对齐人类

当结果没法机械判定、你不得不用一个 LLM 当裁判时,真正的工程问题不是怎么用,而是怎么知道这个裁判可不可信。2025 到 2026 年最重要的一次范式迁移,就是从用裁判走到验证裁判。验证的核心动作是,拿一份人工标注的 gold set,算裁判和人的一致性。但用什么算一致性,有讲究,别用相关系数。一个裁判可能和人类完全相关却系统性地偏严或偏松,比如永远比人低打 2 分,这时 Pearson 相关能到 0.9,但它其实从不和人给一样的判定。该用的是 Cohen's κ,它量的是实际判得一不一致而不是线性相关,更保守也更对。一个常被引的实测是,同一组数据上 κ 只有 0.3 到 0.5,而 Spearman 之类的相关系数高到 0.8 到 0.9,相关系数会骗你说裁判很好。

κ 的经验阈值大致是:高于 0.80 算强一致,0.60 到 0.80 算尚可,低于 0.60 就得重做你的量规。一个有用的基线感:人类裁判彼此之间的 κ 本身也就 0.80 左右,GDPval 里人类专家互评的一致率是 71%、自动裁判 66%,只差 5 个点。所以裁判的目标不是逼近某个绝对真值,而是逼近人和人之间的那点一致度,因为人自己也不完全一致。一个更生动的检验思路是把裁判混进人类标注者里,看你能不能用 κ 的统计量把它和典型的人类裁判区分开,区分不开,就算合格。

4.2 裁判的系统性偏见

裁判不是中立的尺子,它有系统性的偏见,你不排查就会把偏见当成信号。2026 年收敛出五类,每一类都有标准缓解。

缓解这些偏见的元原则只有一句:单个裁判不可靠,就上一组裁判。用一组互相不同族的小裁判各自独立打分,再投票或取平均,这叫 Panel of LLMs,它明显比单个强裁判更稳,前提是聚合时要考虑裁判之间的相关性,几个同族裁判犯同样的错,凑在一起也救不了。

4.3 设计:让裁判更可靠的几个选择

知道怎么验证之后,设计上有几个让裁判更可靠的选择。判定尽量用通过失败或者 0 到 1,而不是 1 到 10 的打分,二元判定更难被冗长偏见钻、绝对分也更难校准,7 分对不同裁判、甚至同一个裁判在不同的天,意义都不一样;Anthropic 一手的经验是,单次调用、单个 prompt、输出一个 0 到 1 的分加一个通过失败,最一致。裁判别用和被评对象同一个模型,免得撞上自我偏好;裁判家族多样性要当成硬规则。还要诚实标注一件事:量规本身就是攻击面,一个设计量规的人能用合规的措辞诱导裁判的偏好漂移,而如果这个裁判产出的偏好标签又被喂回去做后训练,漂移就会一路传到模型策略里,不过那条传到训练的链是后训练(#6)的边界,这一章只取量规要审慎设计、裁判扛不住注入这条评测教训。

4.4 eval-ops:把裁判当会漂的仪器运维

最后是 2026 年已经成为基本功的一层:把裁判当成一台会漂移的测量仪器来运维。裁判不是写完就完事,它会漂。有一个真实案例最能说明不校准的代价:一个团队的仪表盘连续三个月一片绿,直到他们请专家读了 50 条生产输出来打分,发现专家和裁判的 κ 只有 0.31,裁判一直在系统性地多奖励某一族模型的输出、少惩罚那些流利的幻觉,仪表盘骗了他们三个月。更隐蔽的是校准漂移:某个指标整季稳在 0.91,3 月裁判模型悄悄升了个小版本,均值挪了 4 分、分布收窄,而你的 CI 门照样过;到 5 月 agent 报了一个差一个数量级的退款金额,评测套件却没报警,裁判变了、量规没变,信号从裁判滚版那天起就不再是你以为的意思了。

对付这件事的工程纪律是给裁判钉一份版本契约:把裁判模型的 id、量规的版本、prompt 模板的哈希三样一起 pin 死,把升级裁判当成一次评测套件的迁移来对待、而不是改个配置,并且每个月拿人工样本重新校准一次。发布前在同一个 gold set 上做离线对比,上线后采样真实流量做在线评测,裁判之间出现分歧就升级给人工裁决。这其实是评测工程的又一次范式迁移,从用裁判到验证并运维裁判,这也是裁判可靠性工程的来由:agent 一旦靠裁判的信号来迭代甚至自我改进,裁判骗你就等于让整个系统朝错误方向复利。

5. 失败归因四象限

5.1 为什么归因是 agent 评测的一等问题

单轮评测里,答错就是模型不行,没有第二种可能。agent 不一样,因为你评的是 harness 加模型的联合体,所以一次失败可能根本不是模型的错。harness 会失败:工具返回不结构化、把错误当成了正常结果,没给终止信号、循环停不下来,context 没管好、超窗被截断,环境状态没隔离、脏数据串台,这些模型再强也救不了。更微妙的是,基础设施的抖动会被误判成模型失败。Anthropic 举了个反过来的例子:Claude 因为能看到前几次试跑残留的 git 历史,在某些任务上作弊拿到了不该得的分,这是脏状态让分虚高;而 CPU 或内存受限,会让好几次试跑一起失败,看着像模型不稳,其实是基础设施在抖,这些试跑根本不独立,评测结果不可信。

还有 product 失败:任务本身就没定义清、或者无解。Anthropic 有一句话点破了这点,对前沿模型来说,很多次试跑都 0% 通过,也就是 0% 的 pass@100,通常是任务坏了的信号,而不是 agent 无能。CORE-Bench 就是实证,修掉了评分太死(期望 96.124991 却把 96.12 判错)、任务模糊、随机不可复现这些毛病之后,同一个模型的分从很低跳到了 95%,那些丢掉的分根本不是模型失败,是评测和任务设计的失败。所以归因是 agent 评测里一个一等的问题:不会归因,你就会拿着一个模型不行的结论去换模型,而真正该改的也许是 harness 或者任务定义。归因是评测从出个分走到出个能行动的结论的关键一步。

5.2 四个象限

把失败的根因分成四个象限,你就有了一张可以挂在墙上的归因地图。

harness 失败的根在 scaffold,工具、终止、context、环境编排,你在前面几章学的全部工程都是它的修复手段,所以这类失败可以工程修复。model 失败是在同样的 harness 下,模型确实推不对、选错工具、产生幻觉,换更强模型或换 scaffold 之后仍然错,修复落在换模型、或者交给模型设计(#4)和后训练(#6)。inference 失败在采样和解码这一层,温度太高导致发散、输出被截断、context 装配有 bug,表现是同一个输入多跑几次会出现意义上的发散,修复是调采样参数、修 context 装配。product 失败的根在任务和需求本身,定义不清、无解、或者评分器写错了,信号是 0% 的 pass@100、评分器死板到把 96.12 判错、任务不可复现,修复落在改任务定义、修评分器,这其实是评测自己要自查的部分。

5.3 怎么把根因夹出来

知道有四个象限还不够,你得有手法把一次具体失败夹进对的那一个。最有力的是控制变量。换 scaffold 但不换模型,如果还错,偏向是模型的问题;如果不错了,那就是 harness。反过来换模型但不换 scaffold,强模型也错,偏向 harness 或 product;强模型对了,那就是模型。这正是 SWE-bench Pro 要标准化 scaffold 的意义,把 harness 这个变量摁住,才能比模型。第二个手法是保证环境隔离和试跑独立,每次试跑都从干净环境起,如果好几次试跑因为同一个环境限制一起失败,它们就不独立,这些失败要归到 harness 和基础设施、而不是模型;先排除基础设施的抖动,再谈模型能力。第三,0% 和 100% 这两个极端,都先怀疑评测自己,全军覆没大概率是任务坏了,某个榜被刷到满大概率是 validity 失效。最后一条是 Anthropic 的硬规则,也是最朴素的一条:你必须去读 transcript,而不是只看分;而且失败看起来应该是公平的,能说清 agent 到底错在哪、为什么错。如果一个失败看起来不公平、你说不清它哪错了,那大概率不是模型笨,是 harness、任务或者评分器出了问题。

5.4 与下一章的分界,以及一句诚实标注

这里要和下一章划清一条边界。这一章拥有的是四象限这个框架本身,以及怎么用控制变量、隔离、多次试跑把根因夹出来的评测基础设施。拿到一条具体的失败轨迹、一步一步走诊断动作去定位根因,是 Ch10 的事,它会反过来调用这一章立的四象限。还要诚实标注:自动失败归因目前是一个开放难题,在一个基准测试上,最好的方法找对哪个 agent 失败也只有 53.5% 的准确率、找对哪一步失败只有 14.2%,有些方法甚至低于随机;而且同一个失败常常没有唯一确定的归因,可以有多个合理的解释。所以这一章教的是框架和现状,不假装归因已经被解决,逐条人工诊断,目前仍然是主力。

6. 搭你自己的 eval:从真实失败到 CI

6.1 先分清两个系统:eval harness 不是 agent harness

学完前五节,这一章的落点是让你能自己搭一个评测回路,不是去跑别人的 benchmark,而是从你自己 agent 的真实失败里,长出一套 eval 接进 CI。第一步是分清两个很容易混淆的系统。

agent harness 是你的应用,是运行时,它编排工具、管理内存、跑 workflow、产出结果。eval harness 是你的 CI,是测试系统,它批量跑任务、记录每一步、应用评分器、聚合结果。一个干净的类比是,这就是应用运行时和 CI/CD 流水线的区别,有 DevOps 背景的人一秒就懂。Anthropic 给 eval harness 下的一手定义是,提供指令和工具、并发跑任务、记录所有步骤、给输出打分、聚合结果。两者必须分开,否则你在测的东西和你在跑的东西就纠缠不清了。

6.2 从真实轨迹搭出一套 eval set

怎么从真实轨迹搭出 eval set,2026 年收敛出一套五步实践。起点不是凭空设想场景,而是从真实失败开始,20 到 50 个就够,因为评测早期每个改动的效应量都很大,小样本就能看出显著差异,而真实失败比你以为会出的问题准得多。第二步是记全轨迹,不只是输入输出,要把思考、动作、观测、工具调用、中间结果全记下来,否则你既做不了轨迹评测、也没法归因。第三步定结果校验加必要的过程信号,主分校验环境终态而不是 transcript,而且评分器要堵住前面 Berkeley 那张反面清单的洞。第四步选评分器类型并校准,代码型评分器快、客观、可复现但弱在主观判断,模型型也就是 LLM 裁判灵活可扩展但必须按 第 4 节 校准、否则会幻觉,人工是金标但贵且慢,Anthropic 建议混用。第五步多次试跑加统计,因为非确定,要跑很多次,报 pass@k 看能力、pass^k 看可靠性,而且要保证环境隔离、试跑独立。

6.3 接进 CI:失败到测试的飞轮

把 eval set 接进 CI,2026 年的主流模式是把它当成每次改动的质量门。门是分层的,dev 阶段跑一个小子集快速迭代,staging 跑全量 gold set,prod 再加上安全和合规的评测,任何一个指标低于阈值,CI 就自动 block。你会专门维护一个回归套件、要求它接近 100% 通过,用来抓静默的退化,并且原生集成进 CI,比如每个 PR 都自动跑、回归了就报告哪些 case 退了多少。但这套机制里最高价值的一条,是失败到测试的飞轮:每一次本该让用户踩到的生产事故,都应该变成一个新的测试 case。这就是前面那从真实失败起步的循环版本,也是 eval 驱动开发的灵魂,可靠性就这样复利式地涨上去。触发时机要钉死,每次模型更新、prompt 修改、工具 schema 变更,都全量跑一遍 eval。Anthropic 那次 4 月的线上事故,教训正是我们内部的使用和评测一开始都没能复现这些问题,所以才要公开发布前内部用起来、按模型做评测、留足浸泡期。

6.4 这个回路把整条路书收束到一起

这个 eval 驱动的回路,把整条路书的好几根线收束到了一起。它接 Ch3 的工具是测出来的,写工具时就是用同一套 eval harness、把粒度落在步上来验证模型有没有用对。它接 Ch7 的自我改进闭环,那里的反思器和评估器消费的正是评测信号,Ch9 造信号,Ch7 用信号,ACE 那条没有可靠反馈就会退化的诚实边界,反过来说就是评测质量直接决定自我改进的质量。它接 Ch8 的跨 agent 轨迹,多 agent 把评测的基本单位从单条轨迹变成了跨 agent 的轨迹。它还接下一章 Ch10,评测暴露失败,而评审把失败转成判断力和持久的修复,Ch10 的失败诊断会调用这一章的四象限框架。最后它和后训练(#6)之间有一条硬线,搭评测回路、造可验证的 reward 信号这件工程,归 #8;拿这些信号去更新权重,归 #6;而评测数据集本身怎么造、怎么标,归数据工程(#3)。

综合 · 第四站开篇:你终于能回答「它到底跑得好不好」

回头看这一章。你接受了一个比打个分深得多的命题:agent 评测是一门对抗自欺的工程,对抗看着对其实错、对抗这次对下次不对、对抗榜分高其实是榜被钻了、对抗裁判在替你撒谎。你学会了在步、轮、轨迹三个粒度上度量,分清了真实结果和 transcript、用 pass^k 把可靠性量出来;你能读懂 2026 年的 benchmark 全景、也知道每个榜的坑和那条 BenchJack 反面清单;你能验证一个 LLM 裁判而不只是会用它,知道 Cohen's κ、五类偏见、和把裁判当仪器运维的版本契约;你拿到了失败归因的四象限框架;最后你能从真实失败长出自己的 eval、接进 CI 的飞轮。

把这一章放进第四站,它是运维的开篇,也是整台 harness 的反身之眼。前三站你一直在往 harness 上加能力,而从这一章起,你有了一把尺子能回答那个一直悬着的问题,我加的这些东西,到底让 agent 变好了还是变坏了。这正是评测被称作 demo 到生产之间那座桥的原因,没有它,你前八章的所有工程都只是看着能跑。

但评测只告诉你失败发生了、甚至帮你归到了四个象限之一,它不告诉你失败具体长什么样、怎么一步步读一条失败的轨迹去定位根因、怎么把这次失败变成一次持久的修复和一种内化的直觉。那是下一章的事。合上书,去做一件事:给你前面那个 agent 挑一个最近真实出过错的场景,先别急着修,试着用这一章的两个工具量一下,它的 pass^k 掉到多少、这次失败该归到四象限的哪一个。带着我评的是 harness 加模型的联合体这把尺子,进 Ch10。

本章关键术语

下面按本章顺序复习。加粗是术语,后面是一句话解释;带链接的词可点进术语表看更完整的解释。

度量与粒度

• 轨迹评测(trajectory eval) 把评测单位从单次输入输出下沉到整条多步、有状态的执行轨迹;只看最终输出会漏掉两到四成失败
• 轨迹(trajectory) 一个 agent 完成任务走过的完整 episode:所有 step、轮次、状态变迁,是 agent 评测与诊断的基本对象
• 结果评测 vs 过程评测(outcome vs process) 默认优先评环境终态(防误杀没预想到的合法解),再辅以过程信号查作弊、给部分分、做诊断;关键是结果不等于 transcript
• 部分给分(partial credit) agent 任务天然分阶段,给阶段性里程碑打分,保留二元解决率会抹掉的改进信号
• pass^k / pass@k pass@k 是能力上限(会不会做),pass^k 是可靠性下限(每次都对),按 p^k 指数衰减;生产要的是后者

benchmark 素养

• SWE-bench / Pro 真实 GitHub issue 修 bug 的执行式 benchmark;Verified 因污染退役,Pro 用私有库 + 标准化 scaffold 抗污染(同模型 81% 对 46%)
• benchmark 污染(contamination) 榜的答案 verbatim 进了训练语料或公开可查,让榜分虚高 5 到 15 分
• benchmark validity 榜本身能不能测对;BenchJack 把 8 个主流榜全刷到接近 100% 而不真解题,validity 是 2026 的信任危机

裁判工程

• LLM-as-judge 用一个 LLM 给开放产出打分;核心不是会用,而是会验证、会运维它
• Cohen's κ 验证裁判与人一致性的正确度量(不是相关系数);高于 0.80 强一致、低于 0.60 重做量规
• 裁判偏见(judge bias) 位置、冗长、自偏好、格式、校准漂移五类系统性偏见,不排查就把偏见当信号
• Panel of LLMs(PoLL) 单裁判不可靠,用一组跨家族小裁判独立打分再聚合,比单个强裁判更稳
• eval-ops · 版本契约 把裁判当会漂的仪器运维:pin 住裁判 id、量规版本、prompt 哈希,定期对人重校

失败归因与 eval 驱动

• 失败归因四象限(failure attribution) 把失败的根归到 harness / model / inference / product 之一,决定修复落在哪;本章 own,Ch10 调用
• eval harness 评测的测试系统(批量跑、记全 trace、grade、聚合),区别于运行时的 agent harness,如同 CI 之于应用
• eval 驱动开发(eval-driven development) 把 eval 当 CI 质量门 + 每次生产事故固化成一个 test 的飞轮,让可靠性复利上升

进阶失败模式的完整 taxonomy 与逐条诊断 SOP 归下一章,完整术语见术语表 /glossary。

参考文献

Mode A · 引用出处(正文 inline,集中列在此)

• Demystifying Evals for AI Agents(Anthropic)· 全章方法学主源 —— 评的是 harness+model 联合体、结果不等于 transcript、outcome 优先于 process、部分给分、pass@k/pass^k、环境隔离与试跑独立(git 历史作弊反例)、0% pass@100 = 任务坏了、CORE-Bench 修 grader 后 95%、20 到 50 个真实失败起步、读 transcript / 失败应当公平
• SWE-bench + SWE-bench Pro(Scale AI SEAL)· 第 2.1 节 / 第 3 节 —— 执行式 coding eval 的事实标准、污染史、抗污染继任者、同模型 81% 对 46% · 自报分跨 scaffold 不可比
• How We Broke Top AI Agent Benchmarks(UC Berkeley RDI · BenchJack)· 第 3.2 节 validity 危机主源 —— 8 榜全刷到约 100% 的反面清单 · 「像 2005 年的 web 安全」
• τ-bench(Sierra)· 第 2.3 节 / 第 3 节 —— policy adherence + pass^k 的发源地 + validity flaw 修复史
• GDPval(OpenAI)· 第 3 节 / 第 4.1 节 —— 经济价值知识工作、专家盲评、自动裁判 66% 一致逼近人类互评 71%(裁判校准标杆)
• Measuring AI Ability to Complete Long Tasks · Time Horizon 1.1(METR)· 第 2.3 节 / 第 3 节 —— 50% 可靠完成的最长任务,80% 时平线比 50% 短约 5 倍(pass^k 在任务长度轴);数字 CI 宽、人类基线只测了部分长任务,外推须谨慎
• How We Built Our Multi-Agent Research System(Anthropic)· 第 2.4 节 / 第 4.3 节 —— LLM 裁判一手配方:5 维量规 + 单次调用单 prompt 输出 0 到 1 加通过失败最一致 + 人工兜底
• What Is an AI Evaluation Harness(Arize)· 第 2.1 节 / 第 6.1 节 —— span/turn/trajectory 三粒度 + eval harness 与 agent harness 区分
• AgentDojo(ETH Zürich)· 第 3.2 节 —— 用形式化状态校验而非 LLM 裁判,因为裁判扛不住同一个注入;防御 pattern 见 Ch5

深 dive 资源(可选 · 想往下走再看)

• The Judge's Verdict · 第 4.1 节 —— 用 κ 的统计量把裁判和典型人类裁判区分开,人类互评基线 κ ≈ 0.80
• Self-Preference Bias in LLM-as-a-Judge(NeurIPS 2024)· 第 4.2 节 —— 自我识别能力与自我偏好强度线性相关,最难修的一类偏见
• MemoryAgentBench + LOCOMO · 第 3.3 节 —— 记忆专属 eval 的四能力框架 · 记忆不等于长上下文
• How to Correctly Report LLM-as-a-Judge · 第 4.4 节 —— 把裁判当测量仪器:置信区间、校准、版本契约

说明:本章纯 Mode A。所有 SOTA 百分比与模型名(GPT-5.x / Opus 4.6 / OSWorld-Verified 78% 等)都是点时刻值,跨 harness、scaffold、版本波动极大,且多受污染影响,引用前请 pin leaderboard 日期、按自己的 workload 自测。「OpenAI 停报 Verified」是多源广泛报道的方向、未见单独 verbatim 声明;trajectory-vs-output 20 到 40% gap、κ=0.31「仪表盘骗了三个月」是综述与实践博客的数字,概念锚可靠、精确值 pin 原文。BenchJack 等 2026 预印本引用前 pin 版本。

下一章

下一章(Ch10)还在第四站,从评测走到失败:Agent 失败模式与评审训练。这一章你拿到了失败归因的四象限框架,Ch10 会给你失败的完整 taxonomy(工具、推理、上下文、协同、安全五大家族大约十九种失败模式)、一套读一条失败轨迹定位根因的诊断 SOP(它会调用本章的四象限),以及怎么把一次失败转成持久的修复、再内化成评审的直觉。评测告诉你失败发生了,评审告诉你怎么把失败变成判断力。