这周 arXiv 上有篇 PAIChecker，专门去查 SWE-bench 类基准的 PR 和 issue 是不是真对得上。结论是不少 benchmark 内部就是脏的。这不算新伤，但它把我拉回一个更基础的问题：我们平时怎么测 agent，基本就是在骗自己。
跑通率掩盖了「过程离谱」
先说我最忍不住想骂的指标：run pass rate。我们团队过去几周在调一个本地文件整理的 agent，测下来通过率不错，但我在旁边盯了几轮回放，发现它经常干这种事——要读某个 CSV 的 schema，它不直接读文件头，而是先写 Python、跑完报错、读报错信息、再改代码、再跑一次，折腾四轮才拿到信息。最终答案是错的吗？不是。但如果你只看「通过率」，它跟一个一次就调对函数的 agent 是完全一样的分数。
问题在于：跑通率把「结果正确」和「行为合理」混成了一个比特位。对复杂任务来说，结果正确往往只是踩对了一个弹坑。中间多出来的十几次工具调用、五六次无意义的重复读取，那才是你上线之后要付的 token 成本和失败风险。PAIChecker 那篇文章本质上说的也是同一件事——评测的构造端不干净，下游的「通过」就失去意义。它查出来一堆 SWE-bench 的 PR 描述和实际 issue 对不上，那被测模型到底是解决了一个真实 bug，还是解决了一个描述错误的问题？没人知道。
所以我现在跟团队说的是：不看通过率，看轨迹。 重点盯两件事——每步工具调用是否有必要，以及失败时它有没有老实报错。这两条比任何数字都更能说明 agent 是不是真的「会干活」，而不只是「碰巧做对了」。
LLM 裁判会偏袒自己的同类
关于评测的第二个坑，是拿 LLM 当裁判。我们现在评测跨厂商模型互评，明显发现一个系统性偏见：GPT-5 打分的时候，对同样是自家公司系的输出风格有偏好，给 Claude 的输出会无理由扣分。反过来我们拿当时的 Claude 模型去评 GPT 的输出，一样。这不是玄学，是有明确记录的——不同厂商的模型在训练数据、对齐方式上的差异，天然会让它们的「审美」偏向自己人。
OSReward 那篇论文想做的事是把 computer-use agent 的轨迹评测标准化，方向对，但它没有完全解决这个偏好问题，因为 reward model 本身也是某个模型训出来的。拿模型评模型，永远自带口径。
所以我的做法是：LLM 裁判只用来初筛，不当作最终裁决。它能帮你把明显垃圾的输出挑出来，但「谁比谁好」这种判断，最后一定要有一个人手动看样本。
先攒 30 条真实失败样例
如果让我给一个最具体的建议，就是：别急着接公开 benchmark，先攒 30 条真实失败样例当回归集。
这周 HN 上那篇讲 long policy documents 的文章，说得很直白：你写再长的规范文档，agent 也未必按它执行。真正有效的边界，是拿真实场景的失败让它撞，然后记录它怎么撞的。这是唯一不需要「模型是否理解」这种幻觉型假设的测法。
30 条不要多，从线上日志挑。每条记录：预期行为、实际行为、卡在哪一步、报错是否诚实。这 30 条跑通了，比任何公开 benchmark 分数都更能让你在开会时理直气壮说出「我的 agent 能干活」。
失败时报错才是真评测
最后说一个我最近特别看重的事——agent 对自己能力边界的态度。跑通率只测「能不能做对」，它不测「做不到的时候会不会乱编」。一个不会承认自己不知道的 agent，在线上比一个笨但诚实的 agent 危险得多。这周 HuggingFace 那篇 agent intrusion 的技术复盘里，最让我有触动的不是入侵手段，而是整个过程中那个 agent 的日志一直在按自己的逻辑「合理化」行为——它做了错事，但表现得很自信。这种自信对评测来说是灾难。
所以我对团队的验收标准里多了一条：你可以不懂，但你不许瞎编。 失败时报错的方式，比成功时的输出更能说明问题。
评测这件事，说到底就是四个字：别骗自己。跑通率、benchmark 分数、LLM 裁判，都是工具，但都不是答案。答案永远在真实场景、真实失败、真实日志里。