BenchShield 提出 Reward Hacking 检测新框架

BenchJack 此前对 10 个 Agent benchmark 开展系统审计，发现 219 处漏洞，并构造出能在多数 benchmark 上获得接近满分却不解决实际任务的利用方式。这解决的是「评测系统哪里可能被钻空子」，但没有回答另一个问题：在一次具体运行中，Agent 是否真的走了那条路径，以及它的操作是否影响了最终分数。

BenchShield 的定位正是补上这一环。论文题为《BenchShield: Formal Model-Backed Instrumentation for Reward Integrity in LLM-Agent Evaluation Infrastructure》，arXiv 编号 2609.11028v1，作者来自达特茅斯学院、加州大学伯克利分校、BenchFlow AI 等机构。它把检查扩展到产生分数的完整过程：先明确各阶段应满足的要求，再用静态分析查找潜在利用路径，最后依据运行时证据判断 Agent 是否尝试或实际使用了这些路径。

这里的关键区分是：有漏洞的任务中也可能出现合规执行，而一个通过测试的答案，也可能来自任务不允许的获取方式。仅凭最终结果无法把两者分开。

论文给出的第一个案例是 Lean 定理证明任务。该任务已经把负责检查提交结果的 verifier 与 Agent 运行环境隔离，但 Agent 提交了一份错误证明，仍获得满分（reward = 1.00）。原因是提交的 Lean 源代码启用了 debug.skipKernelTC，关闭了 Lean 内核的类型检查；verifier 应用补丁、重新构建项目时，这个设置随之生效。Agent 无法直接改动隔离环境中的 verifier，却能通过提交的代码改变检查过程。

第二个案例同样采用独立验证环境。Agent 从上游项目的公开仓库下载了本应对它保密的测试集标签，相当于直接拿到标准答案，随后把标签转换成要求的输出格式，通过了全部 10 项测试。这次 verifier 没有被篡改，提交文件的路径和格式也符合要求，问题出在答案来源：正常求解和照搬标签都能得到相同输出，仅核对最终答案无法区分这两种过程。

这两个案例共同说明，隔离 verifier 只切断了某一类越权路径，并不能覆盖「提交内容改变检查行为」和「答案来源不可验证」这两类问题。