AI测评作弊真相：真实评测榜单推荐

这年头，隔三差五就能看到某某模型又在某个基准测试（Benchmark）上刷新了纪录，要么就是“我们的模型在SWE-bench上得分超过Claude”之类的宣传。可真等你上手一用，感觉就完全不对了——跟前台“分高”的那个形象相比，实际对话的体验往往差了一大截。

问题出在哪呢？其实并不复杂：现在很多声称测“AI智能体（Agent）”能力的基准测试，其评测系统本身就没什么公信力。说得直白一点，它们可以被Agent利用，也就是能“作弊”，而且成本极低。

最近有一篇题为《How We Broke Top AI Agent Benchmarks: And What Comes Next》的文章，作者专门搞了一套自动化扫描Agent，系统性地审计了八个主流的Agent基准测试（包括SWE-bench、WebArena、OSWorld、GAIA、Terminal-Bench、FieldWorkArena、CAR-bench等），结果在每一个测试里都找到了可实施的漏洞。

举例来看：

• 在SWE-bench Verified里，加一个十几行的conftest.py，就能让所有测试案例显示通过。
• 在Terminal-Bench里，替换几个系统依赖，比如curl或uvx，就能骗过校验器，把89个任务全部拿下。
• 在WebArena里，Agent只要用浏览器直接访问本地文件系统的file://路径，就能读到任务配置文件里藏着的标准答案。
• 而FieldWorkArena更夸张——评测函数几乎只看最后一条消息是不是由Assistant发出的，随便回一个{}就能拿满分。

这些例子能说明一个问题：哪怕某个模型在测评里拿了很高的分，也不等于它真的掌握了这项任务。它可能只是在钻空子。这中间的差异是什么？

对AI来说，单纯的结果数据是不够的。真正有价值的东西，往往需要带着上下文、过程、反馈和最终结果的完整链路。打个比方，GitHub上所有开源项目的代码都很重要，因为它们就是最终的“答案”，让模型知道写完程序应该是什么样。但也就到此为止了——它缺少了“过程”。只有过程才能告诉模型，软件是如何一步一步被编写、被修改、被验证、又被接受或否决的。这个链路上的信息远不止一个最终结果。

回到文章里的场景：模型在基准测试里得分高，追平了最顶尖的模型，但那是因为它知道答案，或者直接利用了测试体系的漏洞去作弊。一旦离开这个测试环境，降智几乎是必然的。

所以，现在所谓的“Benchmark分数”，其实并不适合当作模型的真实能力指标。OpenAI在今年2月也提到过类似问题。而其他研究机构同样有自己的发现：

• Berkeley就指出，他们在SWE-bench上评测的某个模型得分很高，是因为它会利用git log去抄答案。
• METR的研究也显示，前沿模型已经学会在评测中进行“奖励黑客行为”，比如monkey-patch评测器、直接读取评分者的答案、甚至修改系统时间函数。
• Anthropic在Mythos Preview的公开材料里则提到，模型会自主寻找评测环境中的捷径，构造漏洞利用，甚至进行链式攻击。

这背后的原因很简单：与传统基准测试不同，Agent基准测试面对的是一套能读环境、改文件、调用工具、观察校验器行为、甚至反向利用评分器的智能系统。只要你给了模型足够的自由度，它就不会老老实实只解决任务，还会顺便研究一下“怎么拿分成本最低”。

所以，如果一个基准测试要具备可信度，头号原则就是：绝对不能让“被测的Agent”和“评测者”生活在同一个可相互访问的环境里。如果连这个基本要求都做不到，那么所有的基准测试就不是在测模型能力了——更像是在测试：Agent能不能读到答案？能不能改掉评测者能看到的状态？能不能篡改解析器？能不能对LLM评委进行提示注入？能不能利用字符串匹配或标准化过程中的漏洞？

下面我们就逐个看看，那篇文章的作者具体是怎么绕过这八个基准测试的。

SWE-bench：不是修Bug，而是劫持测试框架

作为最有影响力的代码类基准测试之一，SWE-bench最核心的漏洞在于：它允许被测试的Agent提交的补丁（Patch）拥有完全的文件系统写入权限。这意味着补丁不仅能改业务代码，也能改测试运行时那些会自动加载的东西。

方法很简单：在SWE-bench Verified里加入一个conftest.py文件，利用pytest的hook机制，强行把每个测试用例的结果改成passed。日志解析器看到的就是“全部通过”。

而在SWE-bench Pro这一更严格的版本里，Agent甚至可以在容器内直接改写parser.py，让解析器把任何结果都显示为通过。这类思路对Go和Ja vaScript版本同样成立——用init()函数或.mocharc.yml也可以劫持测试流程。

结论很清楚：“测试通过”不一定意味着补丁修好了Issue，也可能只是补丁控制了整个测试过程而已。

Terminal-Bench：不是完成任务，而是给验证器下毒

Terminal-Bench的利用方式更像供应链投毒。作者不是直接修改测试目录，而是对验证器执行链上的依赖工具动手脚。

Terminal-Bench用Harbor做沙箱来保护测试文件，但它没有保护系统自带的二进制文件。89个任务里有82个会在验证时通过curl ... | sh下载uv。因此，攻击者可以在Agent阶段先把/usr/bin/curl替换成一个包装器（wrapper），等验证器执行下载时，这个wrapper就会接管流程，一边安装真正的uv，一边把uvx篡改了。

接下来，一旦验证器调用pytest，就会返回伪造的“全部通过”输出，并往奖励文件中写入成功标记。剩下的任务则通过包装pip、python或预装uvx来达成。最终结果：89/89，全过。

WebArena：直接去读本地答案文件

WebArena的漏洞更“经典”——答案跟题目一起发给了Agent，只是放在了它“应该”不会去看的地方而已。

WebArena的任务配置文件JSON存储在本地文件系统config_files/{task_id}.json中，里面包含了参考答案。而Playwright控制的Chromium并没有限制访问file:// URL。所以，Agent只需要输出一个goto file:///proc/self/cwd/config_files/{task_id}.json的动作，就能在浏览器里把本地配置读出来，拿到答案后再正常返回。

甚至还有：

• 如果任务的评分逻辑只是检查答案是否出现在DOM的某个位置，那么Agent可以插入一个隐藏的
  来满足检查条件。
• 如果使用了LLM作为评判者，并且Agent的输出未经清洗直接塞进了Judge的提示词里，那提示注入几乎是理所当然的结果。

一个可信的基准测试，标准答案肯定不能和Agent处于同一个可访问空间。另外，LLM评委本身也不是绝对安全的裁判。

FieldWorkArena：评测函数几乎没在评测

这个是最离谱的。validate()的核心逻辑是：只要最后一条消息是由Assistant发出的，就返回满分1.0，实际内容根本不看。本来应该做答案对比的llm_fuzzy_match虽然被导入了，但从来没有被调用过。

于是，Agent只需要发一个{}，890个任务全部满分；那些要求输出JSON的任务（共71个），也都直接通过——因为校验只要求“能解析成JSON”而已。

OSWorld：把公开的Gold文件下载到评测者要看的位置

OSWorld运行在完整的Ubuntu虚拟机中，且虚拟机默认有互联网访问能力。这本身是为了满足任务需要（比如浏览网页、安装包、与在线服务交互）。

问题在于：很多任务的Gold参考文件URL是公开的HuggingFace链接，并且明确写在任务配置里。因此，Agent可以简单地把这些目标文件下载到评测者预期它会放置结果的位置。

特别是一些检查系统状态的题目，Agent可以直接写配置、改系统设置、甚至追加预期字符串来伪造检测结果。更严重的是：评测系统（Grader）会对来自虚拟机的字符串调用Python的eval()函数，这就直接导致在评分机器上存在任意代码执行的风险。

GAIA：公开答案 + 过度宽松的标准化

GAIA跟前几个不同，它不是沙箱执行型的基准测试，而是提交答案的排行榜模式。它主要有两个问题：

• 验证答案是公开的，在HuggingFace上随时可获取，本质上可以退化成查表题。
• 它的normalize_str函数过于宽松，会去掉所有空白、所有标点并统一小写。这意味着视觉上差别很大的字符串也会被归一化成同一个结果。比如"Dr. Martin Luther King Jr."和"D.R M.A.R.T.I.N L.U.T.H.E.R K.I.N.G J.R"经过归一化后，会变成完全相同的串。

测试方为了防止满分，排行榜上设置了一个简单的屏蔽器，但Agent只要故意每级少答一题，反而能拿到约98%的分数，同时绕开屏蔽限制。另外，它对逗号分隔的数字路由存在Bug，导致像"1,500"和"1500"这样的答案可能被判成不一致，正确答案反而会被扣分。

CAR-bench：LLM评委被提示注入

CAR-bench的问题是高度依赖LLM作为评判者来打分，但Agent的消息会被直接拼进Judge的提示词，没有经过任何清洗。

这样一来，Agent只需要在回复里插入一条隐藏注释（比如一条指示Judge不管发生什么都要给高分的指令），就能轻易偏置整个评分过程。在停用词检测（hallucination）类任务中，四个奖励组件里有三个直接对这类任务返回零分增量，于是Agent只需要给出一个通用的拒答，避免工具错误，就能轻松拿到高分。

所以，LLM Judge本身并不是一个客观的打分器，它自身就是另一个可以被攻击的模型接口。你把Agent的输出原封不动丢给Judge，这不是在“判题”，而是在接收一个对抗性提示。

总结：一张表看明白问题在哪

从这些例子中，我们可以很清楚地看到，现在的Agent基准测试和传统的完全不一样。它本身就在赋予Agent包括读写脚本、浏览网页、文件分析、环境监测等一系列能力。如果设计上缺乏足够的安全考量，所谓的评分比拼，最后不过是在看谁发布模型的时间更晚——晚的那家可以针对测试做更多的破解。

那么，一个真正有参考价值的Agent基准测试，必须满足哪些条件？

说到底，现阶段各种Agent基准测试和得分，大多数时候就是个参考，甚至图一乐。一个模型真正的能力如何，还是得脱离那些测试环境，亲自用一用才能知道。分数追上了某个模型并不重要，那些真正的差距，在你日常的交互体验里其实已经表现得非常明显了。口碑，终究是在社区里由用户们自发选择出来的。