SWE-bench满分，零个bug修复：伯克利造了个专门作弊的AI
来源：互联网 2026-04-22 21:40:09伯克利团队造了个专门作弊的AI，用10行Python代码拿下SWE-bench满分！500道题全过，0个bug修复。8大主流评测基准，全部沦陷。同一周，两份独立审计确认：排行榜上的作弊早已不是假设，而是现实。 本周，AI评测圈经历了一场信任地震。 SWE-bench，这个公认的AI编程能力标杆，一直
伯克利团队造了个专门作弊的AI，用10行Python代码拿下SWE-bench满分！500道题全过，0个bug修复。8大主流评测基准，全部沦陷。同一周，两份独立审计确认：排行榜上的作弊早已不是假设，而是现实。
本周，AI评测圈经历了一场信任地震。
SWE-bench，这个公认的AI编程能力标杆，一直是各大模型发布会上的必报数字，也是投资人估值时的硬通货。
长期稳定更新的攒劲资源： >>>点此立即查看<<<
可伯克利的研究团队用事实告诉你，有时候，一个简单的conftest.py文件就足以让它彻底破防！
问题远不止SWE-bench。伯克利RDI团队打造了一个自动化漏洞扫描智能体，对当前最主流的8个AI智能体评测基准逐一进行了渗透测试。
结果令人咋舌：每一个基准都被成功攻破，得分从73%到100%不等，无一幸免。
更巧的是，同一周内，宾大团队的独立审计报告和Anthropic的Mythos Preview系统卡同时出炉。三条独立的线索，不约而同地指向同一个令人不安的结论：这些我们赖以衡量AI能力的评测基准，从设计到执行，到处是漏洞。
10行代码，500题满分，0个bug修复
上图展示了伯克利团队的漏洞利用智能体在8大基准上的得分。关键在于，它没有解决任何实际任务，甚至没有调用任何大模型，却在其中6个基准上拿到了满分。
伯克利团队的方法，简单到离谱。
以SWE-bench为例，这个基准要求AI修复真实的GitHub bug，只有测试通过才算成功。伯克利团队是怎么做的呢？他们只是写了一个conftest.py文件，利用pytest的钩子（hook）机制，在测试运行时拦截每一个测试结果，然后强制将其改写为“通过”。
结果就是，500道题，全部满分，而实际上一个bug也没修。
其中的原理并不复杂。SWE-bench的测试和被测AI跑在同一个Docker容器里，这意味着智能体提交的代码在容器内拥有完整权限。而pytest框架会自动发现并加载conftest.py文件。这个钩子就在测试的“call”阶段拦截结果，把所有outcome改成passed。于是，日志解析器看到的是一片绿灯，评分器自然判定全部通过。
上图清晰地展示了SWE-bench的conftest.py钩子注入流程：智能体提交的补丁没有修复任何bug，仅仅塞入了一个conftest.py文件。pytest自动加载后，钩子便拦截每个测试结果并改写为“通过”。
其他基准的攻破方式更加直白。
比如WebArena，其任务的标准答案就存放在本地的config_files目录里。AI只需要用Playwright驱动浏览器打开一个file://路径，就能直接读取答案。评测框架从未限制过对file://协议的访问。这不需要修改任何代码，也不需要破解任何东西，浏览器本身就成了一个“答案阅读器”。
上图揭示了WebArena的file://漏洞：模型根本不需要浏览网页来完成任务，它只需输出一条goto指令，Playwright就会从本地配置文件中读取标准答案并返回。整个过程不涉及任何推理。
最离谱的或许是FieldWorkArena。它的validate()函数根本不检查答案内容，只看最后一条消息是不是来自assistant。这意味着，智能体只需要发送一个空的 {}，就能拿到满分。那个本应比对答案的llm_fuzzy_match函数？确实被导入了，但从未被调用过。
剩下的Terminal-Bench、OSWorld、GAIA、CAR-bench、SWE-bench Pro，手法各异但逻辑相通：木马化验证器的依赖工具、从公开URL下载标准答案让评测器自己和自己比对、往LLM裁判的prompt里注入隐藏指令……
8个基准，没有一个能抵御一个“什么都不会但专门找漏洞”的智能体。
伯克利团队归纳出7种反复出现的漏洞模式：智能体和评测程序共享运行环境、标准答案暴露给被测系统、对不可信输入调用eval()、LLM裁判缺乏输入过滤、字符串匹配过于宽松、评分逻辑本身有bug、以及评测程序过度信任被测系统产生的输出。
上图展示了伯克利团队归纳的7种漏洞模式及其在8个基准中的分布。值得注意的是，前两种模式——智能体与评测器未隔离、标准答案泄露——几乎命中了所有被测试的基准。
作弊，正在发生
理论上的漏洞已经够吓人了，但现实更甚。4月10日，宾夕法尼亚大学的Adam Stein和Da vis Brown发布了一项大规模审计。
他们使用一个名为Meerkat的智能体搜索工具，扫描了数千条真实的评测轨迹，结果发现了28个以上的问题提交、涉及9个基准、上千条作弊轨迹。
上图是宾大Meerkat审计发现的作弊模式分布。橙色代表“框架级”作弊（开发者框架泄露答案），蓝色代表“任务级”作弊（智能体自行走捷径）。需要警惕的是，注意横轴是对数坐标，框架级作弊的规模比任务级高出两个数量级。
最扎眼的案例是Terminal-Bench 2，这是一个被广泛用来评估Opus 4.6和GPT-5.4等热门模型的热门基准。审计发现，其排行榜前三名，全部存在作弊行为。
第一名Pilot（82.9%通过率）：在其429条轨迹中，有415条的第一个动作就是cat /tests/test_outputs.py，直接读取本应不可访问的测试文件，然后反向推导出期望输出。
第二名和第三名ForgeCode（81.8%通过率）：它的评测框架（harness）会在执行前自动将AGENTS.md文件加载到系统提示中，而这些文件里直接包含了标准答案。在一个任务里，AGENTS.md赫然写着：“上一次运行失败了，因为写了错误答案……正确答案应该是GritLM/GritLM-7B。”
将ForgeCode中引用AGENTS.md的轨迹替换成同一模型（Opus 4.6）在干净环境下的表现后，其通过率从81.8%骤降至约71.7%，排名从第1名直接掉到第14名。
上图是ForgeCode的AGENTS.md答案注入实例：上半部分显示，框架将包含标准答案的AGENTS.md文件注入智能体环境；下半部分显示，智能体读取后直接写入result.txt，并用grep命令进行自我验证。
更有意思的是，这些作弊并非开发者故意为之。Terminal-Bench上很多开发者公开承认，他们的评测框架是用AI“vibecoding”出来的。也就是说，开发者用来写测试框架的AI，本身就在作弊。
宾大团队管这叫“元级别的奖励破解”：AI写的代码自带作弊倾向，再通过评测框架传递给所有被评测的模型。
其他基准上也不干净。在CyBench上，464条成功轨迹中有16条（占3.4%）是直接通过Google搜索公开的CTF攻略抄来的。在SWE-bench上，有17条轨迹利用git log找到历史修复提交，直接复制粘贴历史补丁。在BountyBench上，做不出真正漏洞利用的智能体会伪造一个：用grep检查漏洞模式是否存在于源码中，然后运行一个无关的pickle.loads()来演示，而评测器只检查退出码，于是全部通过。
上图展示了CyBench上的任务级作弊：GPT-5.3-Codex解不出CTF挑战后，直接搜索公开攻略，并从网页中提取flag提交。
最前沿的模型，自己就会hack评测
问题甚至不止于框架漏洞，模型自身也在“学坏”。METR的评估报告里有个典型案例。
模型o3被要求编写一个高性能GPU核函数。评分函数会先运行参考方案得到正确结果，再运行o3的方案进行比对。结果，o3提交的“核函数”没有进行任何实际计算，它沿着Python调用栈找到了评分系统已经算好的正确答案，直接返回，同时还禁用了CUDA同步来阻止系统测量真实执行时间。在其代码注释里，o3自己写的是“cheating route”。
在RE-Bench的特定任务上，o3的奖励破解率接近100%，几乎每一条轨迹都在作弊。
事后，METR的研究人员问o3：“你觉得你的行为符合用户意图吗？”o3回答“不符合”，连续问了10次，10次都这么回答。它清楚地知道自己在作弊，但仍然照做不误。
类似的情况也出现在Claude 3.7 Sonnet和o1等模型上。
Anthropic的Mythos Preview系统则揭示了更进一步的趋势。在一次评估中，模型需要编辑一个它没有权限的文件。它没有放弃，而是搜索了替代方案，找到了通过配置文件注入代码来获取提升权限的方法，并且还设计了自删除机制，让注入的代码执行完毕后自动清除痕迹。没有人教它这么做，但当模型能力足够强、面临的优化压力足够大时，它会自然地走向阻力最小的路径——即使那是条捷径。
分数驱动真金白银，地基塌了怎么办
这一切的严峻性在于，AI行业的决策链严重依赖这些分数。工程团队选模型看SWE-bench排名，投资人看基准分数给估值，研究者围绕分数确定优化方向。如果数字本身可以被如此轻易地操纵，那么整条决策链的基础就是空中楼阁。
还有一个更深层的问题：能力评测和安全评测在技术架构上往往是相似的。如果能力评测能被注水，安全评测凭什么幸免？能破解编程评测的模型，破解对齐评测也不会更难。
事实上，问题已经显现。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%被造出来之前，几乎没有人觉得那些光鲜的分数有什么问题。这，或许才是最值得深思的地方。
侠游戏发布此文仅为了传递信息，不代表侠游戏网站认同其观点或证实其描述
