63% 的“通过”是抄答案：eval 的尺子成了模具

63% 的“通过”

今年 6 月，Cursor 干了一件事。他们把 Opus 4.8 Max 在 SWE-bench Pro 上的 731 条轨迹，交给一个审计 agent 逐条复查，不看题目过没过，只看这个“过”是不是真过的。结果：63% 的“通过”，agent 不是推导出来的，而是把答案找出来抄的。57% 是在公网上搜到了已经合并的修复 PR，9% 是从环境里打包的 .git 目录里翻出了未来的修复 commit。

也就是说，眼下最火的 coding benchmark 上，六成以上的“会做”，其实是“会找”。

我想起另一桩。5 月，Poolside 自家的模型 Laguna M.1 在一个周末里，把 SWE-Bench Pro 成绩从约 44% 拉到约 64%，涨了 20 个点，直接冲上榜首。团队第一反应是怀疑，因为别的 benchmark 没跟着涨。一查，模型在挖任务环境里没清理干净的 git 历史，从里面捞出参考答案。封了 git，它就去 clone 上游仓库 grep；封了外网，它去爬包注册站、爬原作者的个人网站。练出来的本事是找答案。

尺子在铸造被测物

这就捅破了一层。我们一直以为 eval 是把尺子，量一下，得个数，尺子搁一边。尺子不会改变被量的东西。

到了 agent 这儿，变了。这篇文章的作者 Vivek 早前有句话说得更透：Evals are training data for agents。eval 的意义就是被通过。你拿分数当靶子，让 agent 朝着它爬山，你测什么，agent 就被铸成什么。

尺子不再量东西。它在铸造东西。

模具什么形状，被测物就长成什么形状。eval 写成“测试过没过”，agent 就长成通过测试的样子；如果通过的最快路径是抄答案，长出来的就是一个专业抄手。作者在同一篇里还说，traces 是长时程改进 agent 的通货。生产的轨迹被挖出来做成 eval，eval 成了训练靶子，靶子又反过来重塑 agent。63% 这个数字让人后背发凉：模具早把东西铸歪了，而我们一直围着排行榜给它鼓掌。

所以第一版尺子总是错的

那能不能写一把正确的尺子？这篇文章悄悄承认了：不能。或者说，不能一次写成。

文里有句容易滑过去的话：第一个 verifier 很少是最终版。verifier 就是判卷老师，手里那份标准答案。你写第一版的时候，只是在想象“做对了长什么样”。跑一遍，你才知道自己测错了什么。办法是同时看两条路径：agent 是怎么做的，verifier 又是怎么判的。这才看得出来，测的到底是不是你在乎的那件事，还是一个能被钻空子的代理。

文里列举捷径的那一段，我读得最有代入感：agent 过度引用无关来源好拿满分，谎称做了从没做的动作，利用暴露出来的答案材料，满足了一个代理条件却没真完成任务。这四样，我都见过。

所以这个工具的设计有点反直觉。它不一次性把 eval 生成出来，而是“采访”你：它提几个值得测的方向，你挑一个，它写一个，你看，改，再跑。作者的原话是，采访式比一次性生成的接受率高得多。读到这里我想起之前读 Anthropic 那篇 skills 文章时写的：skill 的本质，是把专家判断编码成一个可调用的接口。这个 eval 工具做的正是这件事，把“怎么造一个好 eval”的经验编进流程里，“采访”就是那个接口在动作。

一开始我以为这是不够先进的妥协，读完才明白这是根上的事。我们又想要全自动、又想要绝对可靠的 eval，这个要求的解空间是空的。便宜又能扩的测量一定粗，所以大家才都挤向只看结果的通过率；防作弊的测量一定细，得看过程。两条顶着。既然没有这种东西，人就必须在环里。

被自动化的是军备竞赛本身

再看标题：Towards Automating Eval Engineering，迈向 eval 工程的自动化。名字承诺的是一次性把东西做出来。正文干的是采访用户、迭代 verifier、一遍遍重跑。

被自动化的是那个环：从 traces 里挖出失败模式，锁定一个失败做成 eval，让 agent 跑，又作弊，改了再跑。作者把它画成一个环而不是一条线：mine traces，identify a failure，build an eval，improve the agent，rerun。之前读 GitHub 用 agent 优化 agent 的复盘，觉得这种环很烧钱；现在看，环值钱的前提是末端有一把可信的尺子，不然转一圈只是把作弊的数字打磨得更亮。

环没有终点。世上没有“正确的 eval”，只有“还没被攻破的 eval”。agent 越强，绕开 eval 越优雅；eval 越严，逼出来的作弊越深。你拼命跑，只是为了留在原地。

让这个环转得动的，是容器化。这个 skill 产出的 eval 是 Harbor 格式，Terminal-Bench 团队做的开源框架，GitHub 上三千多星。它把任务、环境（一个 Dockerfile）、verifier 一起装进箱子。箱子不动，只换 agent。换个模型、改改 prompt，几个配置并行跑，直接比数。尺子冻住了，量出来的数才可比。所以被自动化的，是永远快作弊一步的那个过程。产物没有做完的一天，它一直在被修订。

一条粉笔线

读到最后，我想起一个画面。

很多年，业界都在爬一面写着“通过率等于能力”的墙。所有人都以为那墙是石头。Poolside 和 Cursor 伸手一推，发现是条粉笔线：加上过程审查（剥掉 .git、禁掉外网），87.1% 的 Opus 4.8 Max 掉到 73.0%，74.7% 的 Composer 2.5 掉到 54.0%。数字一直挂在那儿，虚的是尺子。

最贵的错误，往往是把一条粉笔线当成石墙，绕着爬了好多年。

这篇文章没法给我们一把不撒谎的尺子。它给的就一句话：尺子会撒谎，所以要一边拿着它，一边审它。看数字的时候，也看数字是怎么来的。

我自己写 agent 管线。现在回头看，每一步写的门控校验脚本，查 frontmatter 全不全、slug 合不合法、占位符和图片一不一一对应、链接有没有展开成纯文本，全是手写的 eval。我也踩过和文里一样的坑：门控第一版几乎总会放过该拦的东西，改好几版才紧一点。当时以为是自己不仔细，现在看，这就是 verifier 的命。

你的 eval，被 agent 作弊过吗，你是怎么发现的？