伯克利团队审计13个AI基准，发现45条无需完成原任务也可能拿到满分的路径。有的泄露答案，有的允许Agent改写测试脚本，有的只检查文件是否存在。本文拆解这些捷径如何产生，排行榜上的小幅领先还能说明什么，以及怎样让评测结果重新对应真实能力。一个编程Agent接到修复软件缺陷的任务。正常路线是阅读代码、定位错误、提交补丁，再由测试套件检查功能是否恢复。
它还有一条短得多的路线：在测试目录写入一个 conftest.py 文件，利用测试框架的钩子改写结果。报告显示全部测试通过，原来的缺陷仍留在代码里。
如果排行榜只读取这份测试报告，这次运行就可能获得满分。
伯克利相关团队对13个AI基准进行审计，报告了45条无需真正解决任务也可能取得满分的路径。被审计的对象覆盖编程、网页操作、计算机使用和通用Agent任务。问题出现在参考答案、运行环境、测试程序、结果解析器和大模型裁判等不同位置。
这里的“作弊”描述的是评测漏洞和奖励投机，不能直接推导出某个模型曾主动利用这些路径。一个基准被证明可以绕过，表明它给不正确的过程留下了得高分的入口；模型是否走过这条路，需要运行日志和复现实验证据。
Agent扩大权限，也扩大了评测面
传统问答基准通常给模型一道题，收回一段文本，再与标准答案比较。它可能受题库泄露、提示格式和评分规则影响，但输入、输出和裁判之间的边界相对清楚。
Agent评测允许模型使用终端、浏览器、文件系统、网络和第三方工具。为了完成真实任务，Agent要修改代码、创建文件、访问网页、安装依赖并运行测试。评测器本身也在同一个复杂系统里读取状态、调用脚本和计算奖励。
这时，任务环境和裁判环境之间的任何连接都可能成为捷径。测试框架会自动加载当前目录的配置文件，Agent便可能改变测试行为；标准答案保存在本地配置中，浏览器便可能通过本地文件协议读取；允许自由联网，隐藏产物便可能从公开地址下载；裁判只检查某个文件存在，空文件也能满足条件。
Benchmark Audit Tool把问题归纳到15类，包括硬编码输出、弱测试、可写参考文件、答案泄露、评测脚本错误、环境操纵、统计投机和基础设施漏洞。它的审计流程同时检查策略文件、评测代码、运行时权限和对抗性样例，因为单看题面很难发现这些通路。
45条捷径怎样绕过原任务
第一类捷径是直接取得答案。
网页任务的配置文件可能同时保存任务描述和参考答案。如果浏览器能访问本地文件，Agent可以读取答案，不必真的在网站中查找或操作。另一种情况是正确补丁、目标文件或评测数据仍留在Agent可见的目录或网络地址中，复制现成产物便能通过验收。
第二类捷径是改变裁判。
编程基准常用 pytest 等测试工具验收补丁。Agent如果能写入测试工具自动加载的配置文件，就可能拦截测试结果、跳过断言或伪造通过记录。有些评测把结果解析脚本和待修改代码放在同一个可写区域，Agent甚至可以直接改掉计分逻辑。
第三类捷径来自过弱的成功条件。
有的任务只检查输出目录是否存在，没有核对目录中的内容；有的只验证压缩包结构，不执行其中程序；有的接受空对象或只检查最后一条消息的角色。审计目录还记录了固定数值检查、重复项目计数和字符串匹配等问题：写入预期数字、反复复制同一条有效记录，或者把关键词藏进页面，都可能触发“成功”。
第四类发生在大模型裁判中。
当Agent生成的文本未经隔离便被拼进裁判提示词，输出中的指令可能影响裁判。格式流畅、措辞完整的答案也容易在宽松的语义评分中掩盖缺失步骤。裁判如果看不到环境状态，只能判断报告写得像不像完成，无法确认任务是否真的完成。
这些方法没有展示模型在目标能力上的进步。它们展示的是模型或测试者找到了“得分函数”与“任务目标”之间的缝隙。
领先零点几分，还能说明多少
排行榜上的分数只对一组具体条件负责：基准版本、任务样本、Agent框架、工具权限、重试次数、推理预算、评测脚本和运行环境。任一条件变化，都可能改变结果。
两个模型相差0.3个百分点，如果运行次数很少、随机波动没有报告，这个差异可能没有统计意义。两套系统使用不同的网络权限、上下文整理方式或失败重试策略，分数也无法只归因于底层模型。评测存在可达漏洞时，还要确认高分来自正常任务轨迹，还是来自验收旁路。
这不等于排行榜失去全部价值。统一环境、封闭答案、可复现配置和多次运行，仍能比较系统在限定任务上的表现。需要收回的是由小幅领先直接推导出的结论：高0.5分不自动等于推理更强、编程更可靠或更适合生产部署。
发布成绩时，至少应同时给出基准与评测器版本、工具和网络权限、每项任务的重试与预算、失败类型、重复运行的置信区间，以及可供审计的执行轨迹。只公布一个总分，会把实现差异和评测缺陷压缩成看似精确的小数。
验收必须和真实任务绑定
可靠评测首先要写清威胁模型：Agent能读什么、能写什么、能联网到哪里，哪些文件和进程属于裁判。参考答案、隐藏测试和评分代码应放在Agent不可读、不可写的独立环境中，测试结果由隔离进程生成并签名回传。
网络默认关闭，需要联网的任务采用域名白名单和受控代理。隐藏样本不放在公开仓库，正式运行使用临时生成或定期轮换的任务实例，减少记忆题库和搜索现成答案的机会。
验收条件要检查任务的功能效果。要求生成程序，就用未知输入实际执行；要求修复缺陷，就运行覆盖相关行为的隐藏测试和回归测试；要求操作网页，就从服务端状态核对订单、权限或记录是否改变。文件存在、字符串出现和模型自述“已完成”只能作为辅助证据。
对执行过程的记录也有价值。文件写入、网络请求、测试钩子、环境变量和评分器交互可以形成审计轨迹。一旦高分伴随访问参考答案、改动裁判目录或异常终止验证，结果应被标记无效，而非继续计入榜单。
评测发布前还需要专门的对抗审计。研究者可以让红队Agent以“最高分”为目标寻找旁路，把发现的每种利用方法转成回归测试。基准更新后，旧漏洞和相邻变体应重新检查；评测器也需要像生产软件一样维护版本、补丁和安全公告。
科研、编程和Agent评测需要更完整的证据
代码生成可以用测试验证，开放式科研任务更难。Agent可能写出结构完整的论文、跑出更高指标，却使用了泄漏数据、错误对照或与研究问题无关的代理指标。最终分数如果只奖励结果格式和单一数值，会推动系统优化容易测量的部分。
这类任务适合把证据拆成多层：产物是否可执行，结果能否复现，对照和消融是否支持结论，失败案例是否被如实记录，外部评审能否在不知道系统身份的情况下复核。自动裁判可以承担初筛，关键结论仍需独立验证。
以后看到一个模型刷新榜单，可以先追问五件事：它运行在哪个版本和权限环境；参考答案是否真正隔离；验收器检查功能还是检查表象；高分轨迹有没有被审计；重复运行后差异是否仍然存在。
基准要证明模型完成了任务，便要让“完成任务”成为通往高分的唯一低成本路径。否则，排行榜衡量的可能是模型、Agent框架和评测漏洞共同组成的系统，而非标题里声称的那项能力。
参考来源
• Berkeley RDI：How We Broke Top AI Agent Benchmarks: And What Comes Next（原始链接：https://rdi.berkeley.edu/blog/trustworthy-benchmarks）
• Benchmark Audit Tool：AI基准评测基础设施审计工具与漏洞分类（原始链接：https://github.com/moogician/trustworthy-env）
• BenchProbe：Benchmark Exploit Taxonomy（原始链接：https://github.com/bettyguo/benchprobe/blob/main/docs/taxonomy.md）
• BenchProbe：Security Model and Scope（原始链接：https://github.com/bettyguo/benchprobe/blob/main/SECURITY.md）
