系列第一次按领域拆「评测该往哪使劲」。两个全新机制值得收藏：MAST 多智能体失败分类（14 种失败、3 大类，最大来源竟是规范不清而非协作能力）补上藏书在多 Agent 评测的空白；AgentRewardBench 把「评测器本身也要被评测」从口号变成可操作的基准。编码 / Web 两节约半数为系列内回扣，速读即可。
先修：a21（实战 05 评测全景图——本篇的「往哪压兵力」就是那张地图的领域版）；无其他硬先修。做编码 Agent 的重点读第一节并回查实战 07/08（a23/a32）；做 Web Agent 的配 a29（实战 17 工具调用）读；准备上多智能体架构的，第三节是必读——尤其「能单别多」那句劝退。
先合上原文在心里作答，再点开对照。全对 = 本篇真正通关。
多智能体失败的最大来源（约 42%）不是协作能力差，而是规范 / 角色 / 任务定义不清。所以评多 Agent 系统的第一件事不是测协作，而是先查「谁负责什么、怎么交接」定义得够不够清楚。
Web Agent 会改变环境状态（点击、提交、下单）。只验「该做的做了没」会漏掉误删、误发、多下一单这类多余或有害操作——AgentRewardBench 专门把 side effects 列为检查项。这和工具调用的「冗余操作」、安全评测的「越权动作」是同一类担忧。
① 没有一个 LLM 裁判在所有基准上通吃——别默认强模型当裁判就一定准，要在自己的数据上验证；② 规则判定会系统性低报 web agent 成功率——多路径领域里纯规则过严，需要更灵活但经过校准的判定。
上方为本站原创导读，下方为原文完整收录，便于对照阅读。
前面讲的都是通用方法——不管什么 Agent 都适用的评什么、怎么打分、怎么落地。但不同形态的 Agent，评测的侧重点其实很不一样。这一讲挑三类最主流的——编码、Web、多智能体——讲各自的评测要点。
先说清楚定位：不是重新发明方法，而是把前面那套方法（outcome、轨迹、代码型评分器、裁判、harness……）按每个领域的特点调好侧重。方法是通用的，「往哪使劲」是领域特有的。
编码 Agent（改代码、修 bug、写功能）有个天赐之礼：产出天然带可执行的验收标准——跑测试（第 7 讲 SWE-bench）。outcome = 测试通过，几乎零主观。这是所有领域里最容易客观评的一类。
评测要点：
两个坑：测试太弱会放过错误补丁（第 8 讲 SWE-bench 靠 Verified 版人工清洗弱测试）；作弊——Agent 可能直接改测试让它通过，而不是修 bug（第 8 讲的「作弊体检」）。编码 Agent 好评，但「测试通过」这个信号本身也可能被污染或被绕过，别盲信。
再补两点。指标选择：编码 Agent 通常能自检、能重试，所以看 pass@k 而非 pass^k（第 7、16 讲）——只要 k 次里有一次通过、且系统能识别出那一次，任务就算成。基准选择：SWE-bench 早已不是一个基准，而是一整个家族——Verified（人工清洗）、Multimodal（带图）、Pro（更难的工程任务）等，选贴近你场景的那个；此外还有 OpenAI 的 SWE-Lancer（评「能不能挣到真实的自由职业报酬」，是独立基准）也值得一看。
Web Agent 在真实或仿真网页上操作——点击、填表、提交。它的核心特点是会改变环境状态。
评测要点：
一个 web agent 特有的、容易漏的维度——副作用（side effects）：它会点、会提交，那它有没有做多余或有害的操作？（误删、误发、多下了一单）AgentRewardBench 就专门把 side effects 列为一个要查的项。评 web agent，不只看「该做的做了没」，还要看「不该做的有没有乱做」——这和第 17 讲工具调用里的「冗余/多余操作」、第 25 讲安全里的「越权动作」，是同一类担忧在 web 场景的体现。
顺带认识几个 web 领域的基准：WebArena / VisualWebArena（自托管站点）、WebVoyager（真实网站 + 多模态）、OSWorld（扩到整个桌面）、Online-Mind2Web（真实网站上的浏览操作任务）。其中 Online-Mind2Web 有个警示性发现——之前不少 web agent 的成绩被高报了（论文直接叫它「进步的幻觉」），一旦放到更真实、判定更严的环境里，成功率大幅缩水。这再次印证第 6 讲：基准的判定方式，直接决定了分数可不可信。
这里还引出一个更深的问题——你怎么知道你评 web agent 的评测器本身准不准？这是第五节要讲的「评测器的元评测」，AgentRewardBench 正是干这个的。
多智能体系统（多个 Agent 协作——集中式 manager，或去中心化，第 8 讲 τ²）的评测难度陡增：你不只要评单个 Agent，还要评它们的协作。
这里有一份现成的、极有价值的清单——MAST（多智能体系统失败分类）。它分析了大量真实失败轨迹（专家标注、κ=0.88 高一致），总结出 14 种失败模式、归为 3 大类，而且给出了触目惊心的分布：
这个分布藏着一个反直觉的洞察：多智能体失败的最大来源（42%），不是「某个 Agent 不够聪明」，而是「规范 / 任务与角色定义不清」。所以评多智能体，第一件事不是测协作能力，而是先查你的规范清不清楚。
评测要点（在评单个 Agent 之外，专门加）：
MAST 还配了一个 LLM-as-a-Judge 流水线来自动识别这些失败（94% 准确率、0.77 kappa）——但记住第 13/15 讲：这类裁判用之前要校准。
举个交接失败的具体样子：查单 Agent 查到「订单 #1234 已发货、不可退」，但交接给审批 Agent 时，只传了「订单 #1234」、漏了「已发货」这个关键状态；审批 Agent 拿着残缺信息、误批了退款——三个 Agent 单看每个都没错，错在交接处那次信息丢失。这正是 MAST 说的那 37% 协调 breakdown 的典型，也是单 Agent 评测永远照不到、必须专门评交接的原因。
一个务实建议：多智能体极难评，能用单 Agent 解决就别上多 Agent。你每多引入一个 Agent，就多引入一整套交接 / 协调 / 规范的失败面。先把单 Agent 评明白，再谈多 Agent。
| 领域 | 评测侧重 | 主力手段 | 最典型的坑 |
|---|---|---|---|
| 编码 | 测试通过 + 回归 | 跑测试（代码型，execution-based） | 弱测试放过错补丁、改测试作弊 |
| Web | 功能正确 + 副作用 | 验最终状态 + 多模态 + 允许多路径 | 环境易碎、乱点副作用 |
| 多智能体 | 协作（交接 / 编排 / 协调） | 单 Agent 评测 + MAST 失败分类 | 规范不清（42%）、协调 breakdown |
有一个通用动作，无论哪个领域都适用：先问「这个领域最典型的失败长什么样」（编码：测试没过 / 作弊；Web：副作用 / 易碎；多智能体：协调 / 规范不清），再针对性地设计评测。领域知识，决定了你该往哪几个格子（第 5 讲全景图）重点投入。
你的评测器，在你的领域里到底准不准？
AgentRewardBench 就是专门回答这个的：它是第一个评估「LLM 裁判评 web agent 轨迹」效果的基准，用 1302 条专家审过的轨迹（含成功、副作用、重复性）去考 12 个 LLM 裁判。两个结论，直接影响你怎么做评测：
这就是「评测器的元评测」——评的不是 Agent，是评测器本身。它是第 8、14 讲那个「套娃：评测组件也要被评测」的正式化。
怎么在你的领域做元评测？照 AgentRewardBench 的思路：抽一批你领域的真实轨迹，请专家逐条标注（成功没、有无副作用、有无重复），作为金标准；再让你的评测器评同一批，算它和专家的一致率（第 15 讲）。一致率低，就说明你的评测器在这个领域不可信——先修评测器、再谈评 Agent。你评 Agent 的那把尺子，本身也需要被校准。
领域还有很多，评测的「侧重」逻辑是一样的——先看它最典型的失败：
不管哪个领域，套路不变：认出它最典型的失败，把评测的兵力压在那里。
回到退款 Agent，它其实是个「工具型 + 对话型」的混合——最该借鉴的是 τ-bench（第 7 讲：多轮交互 + 守 policy + 用户模拟）。
而如果你把它做成多智能体——一个 Agent 查订单、一个审批、一个执行退款——那 MAST 的清单立刻用得上：查这三个 Agent 之间交接有没有丢信息、规范清不清楚（谁有权批、谁有权退——别栽在那 42% 上）、以及协调（会不会两个 Agent 同时对一单操作、造成重复退款）。同一个退款业务，做成单 Agent 还是多 Agent，评测的重点完全不同：单 Agent 你重点评它自己的工具调用和 outcome，多 Agent 你还得额外背上一整套交接 / 协调 / 规范的评测负担——这也正是「能单别多」的理由。