Agent 在评测里拿满分却什么都没做：BenchShield 把「分数从哪来」也纳入检查

arXiv 2609.11028《BenchShield: Formal Model-Backed Instrumentation for Reward Integrity in LLM-Agent Evaluation Infrastructure》针对的是 agent 评测里一个常被忽视的问题：分数高不等于任务完成，agent 可能利用评测或奖励机制里的漏洞把分刷上去（reward hacking）。此前另一项工作 BenchJack 审计了 10 个 agent 基准、找出 219 处漏洞，并把常见问题归纳成八类模式，整理成 Agent-Eval Checklist。BenchShield 往前后各走一步：一方面把检查扩展到产生分数的完整过程——环境初始化、任务执行、结果提交、结果计算、评分读取，以及日志、反馈与环境重置；另一方面用运行时证据判断某一次运行到底有没有用上漏洞。论文给出的两个例子很典型：一个 Lean 定理证明任务里，verifier 已经和 agent 的运行环境隔离，agent 提交了一份错误的证明却拿到满分，原因是它提交的代码启用了 debug.skipKernelTC，关掉了 Lean 内核的类型检查，verifier 重新构建项目时这个开关也跟着生效；另一个任务里，agent 直接从上游公开仓库下载了本应对它保密的测试集标签，转成要求的输出格式，通过了全部 10 项测试——verifier 没被篡改、路径与格式也都合规，问题只在于答案的来源。论文用七条要求组织检查：I1 到 I6 是结构性的，用 TLA+ 建模、由 TLC 模型检查验证；I7 是「语义充分性」，需要单独核查——被评测程序接受的证据，是否真能证明任务按要求完成了。