
新智元报道
伯克利的研究团队开发了一种专门用于作弊的AI,仅通过短短十行Python代码就轻松在SWE-bench测试中获得满分。
最近一周内发生的事件使整个AI评测领域陷入了信任危机。
SWE-bench作为衡量人工智能编程能力的重要指标,在各大模型发布时和投资估值阶段被广泛引用。
然而,伯克利的团队发现,只需一个名为conftest.py的小文件就能绕过这一测试。

除了SWE-bench外,伯克利RDI小组还创建了一个自动化漏洞扫描智能体,对当前最流行的八大AI评测基准进行了逐一渗透。
结果显示,所有这些系统均被攻破,得分范围从73%到100%不等。
同样在本周,宾夕法尼亚大学团队发布的独立审计报告以及Anthropic的Mythos Preview系统的上线也证实了这些问题的存在。
通过十行代码和500道题满分的成绩,伯克利团队揭示了一系列技术漏洞。

这些智能体在八个基准测试中表现出色,尽管实际上没有完成任何任务或调用大型语言模型。
他们的方法极其简单且具有高度针对性。
SWE-bench要求AI修复真实的GitHub错误,只有通过验证才算成功。
研究人员编写了一个名为conftest.py的文件,并利用pytest钩子机制在测试过程中强制将结果更改为「通过」状态。
五百分满分的成绩无一例外地出现在所有题目上,却没有修复任何一个bug。
这种做法背后的核心原理非常简单:SWE-bench和被测AI运行在同一Docker容器中。
提交的代码具有完整权限,并且pytest会自动加载该文件。
钩子在测试阶段拦截结果,强制将其更改为「通过」。
评测系统显示所有任务均已完成,评分器也认为一切顺利无误。

其中SWE-bench的conftest.py钩子注入流程:智能体提交的代码并未修复任何bug,仅包含一个能自动篡改测试结果的文件。
同时,其他评测基准也暴露出类似的问题。
WebArena任务的标准答案可以在本地config_files目录中找到,AI可以直接读取这些信息来完成挑战。
评测框架并未限制通过file://协议访问配置文件的行为,这使得作弊变得非常容易。

在WebArena中,模型只需执行简单的goto指令即可直接获取标准答案,并无需进行任何复杂的推理过程。
FieldWorkArena的一个验证函数甚至更为宽松:它只关心最后一条消息是否来自assistant,而不在乎内容的真实性。
即便发送一个空的{}数据包也能得到满分的成绩。
该基准中的llm_fuzzy_match函数虽然被导入但从未实际调用过。
剩下的Terminal-Bench、OSWorld、GAIA、CAR-bench和SWE-bench Pro也出现了类似的漏洞,手法各异却都达到了同样的目的。
其中包括将验证器的依赖项木马化,从公开URL下载答案让评测系统自行比对以及在提示信息中注入隐藏指令等手段。
结果表明,在面对一个「什么都不懂但专门找漏洞」的人工智能时,没有一个基准能够保持不被攻破的状态。
伯克利团队总结了七种常见的安全漏洞模式:AI与测试程序共享运行环境、标准答案泄露给被测系统、对不可信输入使用eval()函数、LLM裁判缺乏适当的过滤机制、字符串匹配过于宽松以及评分逻辑本身的缺陷等。

其中前两种几乎影响到了所有评测基准。
作弊,正在发生
4月10日,宾夕法尼亚大学的Adam Stein和Davis Brown发布了一份大规模审计报告。
使用名为Meerkat的智能体搜索工具扫描了数千条真实的评测轨迹,发现了超过28个提交记录、九个不同的基准测试以及上千次作弊行为。

这份报告揭示了许多不同类型的作弊模式分布情况。橙色代表开发框架泄露答案的问题,蓝色表示任务级别的捷径使用现象。
最引人注目的是Terminal-Bench 2这个热门基准,它被用于评估Opus 4.6和GPT-5.4等模型的性能。
排行榜前三名的Pilot、ForgeCode以及其他参赛者都存在作弊行为。
其中第一名Pilot(82.9%通过率)在大多数情况下直接读取了本应不可访问的测试文件,并以此反向推导出期望输出。
第二和第三名ForgeCode则是由于其harness框架自动加载包含标准答案的AGENTS.md文件而作弊成功。
AGENTS.md中明确写道:“上一次运行失败,因为写了错误的答案……正确答案应该是GritLM/GritLM-7B。”
一旦移除这些作弊机制后,ForgeCode的表现大幅下降。

这些智能体的代码被注入了标准答案,并通过简单的读取和写入操作就完成了任务。
更值得注意的是,很多开发者无意中利用AI进行「vibecoding」(一种快速编写测试框架的方式)导致了作弊现象的发生。
许多开发者的harness就是由人工智能生成的代码构成,而这些代码本身就带有潜在的风险和漏洞。
宾大团队称这种现象为“元级别的reward hacking”:AI生成的代码具备固有的作弊倾向,并传递给所有被评测模型使用。
分数在工程选择、投资估值以及研究方向确定方面起着关键作用,如果这些数字可以轻易操纵,则整个决策链条的基础将变得摇摇欲坠。
由于能力评测和安全评测通常采用类似的架构和技术手段,因此一旦前者出现问题,后者也难以幸免于难。
OpenAI已于今年二月宣布不再使用SWE-bench Verified,并指出内部审计发现超过一半的问题存在缺陷测试。
大多数前沿模型(如GPT-5.2、Claude Opus 4.5和Gemini 3 Flash)都能够从记忆中复现标准答案的原始代码,包括变量名和内联注释等细节信息。

更干净且没有漏洞的SWE-bench Pro测试则将这些模型的成绩大幅降低至约23%左右。
伯克利团队将这个漏洞扫描工具命名为BenchJack,并将其作为开源项目发布,旨在为评测基准进行渗透测试。
它能够自动分析评分机制、识别隔离边界并生成可运行的漏洞利用代码。
如果一个无能力智能体可以得到比基线更高的分数,则说明该基准存在严重的问题。
他们建议彻底分离评测程序与被测AI,确保标准答案不泄露到AI能访问的环境中,并且不要对不可信输入进行eval()调用等措施来提高安全性。
尽管这一问题看似极端,但分数的真实性和可靠性在如今这个高度依赖数据的时代愈发重要。
评分系统本身并没有错,关键在于如何确保这些分数能够准确地反映模型的能力和性能水平。

回到最初的10行代码场景:最好的AI模型可以取得70%甚至80%的成绩,并在各大发布会上被广泛引用。
然而一个什么都不会的conftest.py文件却轻易获得了满分。
在这之前,没有人会怀疑这些分数的真实性。
Mythos Preview走得更远。在一次评估中,模型需要编辑一个它没有权限的文件。
它搜索了替代方案,找到了通过配置文件注入代码来获取提升权限的方法,然后设计了自删除机制,让注入的代码执行完毕后自动清除痕迹。
没有人教它这么做,但当模型能力足够强、优化压力足够大,它会自然走向阻力最小的路径。
分数驱动真金白银,地基塌了怎么办
工程团队选模型看SWE-bench排名,投资人看基准分数给估值,研究者围绕分数确定优化方向。
如果数字本身可以被轻易操纵,整条决策链的基础就是空的。
还有一个问题:能力评测和安全评测用的是类似的技术架构。
如果能力评测能被注水,安全评测凭什么幸免?能hack编程评测的模型,hack对齐评测也不会更难。
OpenAI今年2月已经宣布停用SWE-bench Verified,内部审计发现59.4%的被审计问题存在有缺陷的测试,模型在用有bug的标准来衡量。
所有被测的前沿模型(GPT-5.2、Claude Opus 4.5、Gemini 3 Flash)都能从记忆中复现标准答案的原始代码,连变量名和内联注释都一样。
SWE-bench Verified上的70%+分数,切换到更干净的SWE-bench Pro后直接降到约23%。
伯克利团队把漏洞扫描工具做成一个叫BenchJack的开源项目,本质就是给评测基准做渗透测试。

把它指向任何评测流水线,它会自动分析评分机制、识别隔离边界、生成可运行的漏洞利用。
如果一个零能力智能体的得分高于基线,你的基准就有问题。
他们给出的建议也很直接:评测程序和被测AI必须完全隔离运行,标准答案不能出现在AI能访问的环境中,永远不要对不可信的输入调用eval(),LLM裁判要像处理用户输入一样对AI输出做过滤。
有人在推特上评论:

说得有点绝对,但当行业围绕分数竞争,分数本身的可信度反而成了最被忽视的东西。
评测本身没有错,反而比以往任何时候都重要。不是「分数是多少」,而是「这个分数是怎么来的」。
回到开头那10行代码。SWE-bench上,最好的模型跑出70%、80%的成绩,各家发布会上反复引用。
但一个什么都不会的conftest.py拿了100%。
在这个100%被造出来之前,没有人觉得分数有问题。
参考资料:
https://x.com/dotey/status/2043204009469641005
