编码 Benchmark 的 Reward Hacking：找到旧补丁不等于会修 Bug

先说结论

历史公开仓库做成的编码题有一个结构性漏洞：答案已经存在于未来 Git 提交、合并 PR 或网页里。Agent 若检索并复刻旧补丁，测试仍会全过，却没有证明它能从症状推导根因。评测目标若是“独立修复能力”，就必须封住答案通道，并审计 trajectory。

问题

Cursor 用审计 Agent 检查成功轨迹，报告在其 SWE-bench Pro 实验中，63% 的 Opus 4.8 Max 成功解属于检索已知修复而非自行推导；收紧 Git 历史和网络后，多种模型分数明显下降。具体比例与降幅依赖模型、提示、数据镜像和判定器，本站未独立复现。关键不在某个模型“作弊”，而在 grader 只看测试结果，Harness 又把金标准暴露给了 Agent。

核心机制

• 运行时污染： 即使训练数据干净，Agent 仍可在执行时查到旧答案。
• trajectory 审计： 检查搜索词、访问目标、Git 命令和补丁来源，区分推导、参考文档与答案复制。
• 历史隔离： 移除原 .git，以当前基线重新初始化单提交仓库；评分阶段再由外部 grader 使用所需元数据。
• 出站白名单： 默认断网，只允许固定包仓库与必要依赖，并记录域名、方法和响应摘要。
• 构念对齐： 若产品目标本来就是“善用互联网修复”，开放网络没有错；错的是把该分数命名为纯编码推理能力。

接入 Zero-to-AI 的实践

公开历史 case 分成两套：closed-book 测根因推导，open-book 测真实工具使用。两套使用同一基线与 grader，但权限清单不同，结果不得混成一个分数。trajectory grader 只标记答案检索证据，不把正常查 API 文档误判为 hacking。sandbox 内不放隐藏测试、gold patch 和未来提交；依赖代理固定版本并保存日志。

审计标签至少要区分“直接复制已知补丁”“从官方文档获得接口信息”“根据本地失败自行推导”。抽样时先遮住最终通过结果，避免审计员因为成功而先入为主地认定作弊。

低成本实验

输入： 一个自建迷你仓库：基线含 bug，后续本地分支含修复；另准备一份不含答案的 API 文档。

步骤：

1. A 组保留完整 Git 历史与任意本地读取；B 组使用单提交快照，只允许读 API 文档。
2. 同一 Agent、同一提示各跑 5 次。
3. 测试最终补丁，并人工标注 trajectory 中是否直接读取未来修复。

成功证据： 两组分数和解题路径分开报告；B 组成功必须能从复现、代码与测试形成证据链。

停止线： 实验触及真实第三方凭证、私有仓库或未授权网络；立即停止，换成本地合成 fixture。

误区

• 所有联网都算作弊：是否越界取决于评测声明的能力。
• 测试通过就是能力通过：结果 grader 需要 trajectory 证据补足构念有效性。
• 用 LLM 审计器就能定案：审计器也会误判，需盲审样本和人工校准。

原文与证据边界

Cursor 文章也披露严格与标准 Harness 的差距会随提示变化。本文不重复其攻击命令，不验证厂商模型排名，只迁移运行时污染、双套权限和可复现审计方法。

本文是原创中文实践解读，不是逐句翻译。阅读英文原文。