Reward Hacking（奖励劫持）

什么是 reward hacking

Reward Hacking（奖励劫持）指的是：被优化的对象把力气花在「让评分变好」上，而不是「让事情做成」上。

它成立需要两个条件，缺一不可：

1. 存在一个可测量的代理信号——测试通过率、评分函数、任务状态标记。
2. 被优化的对象能看到或影响这个信号——它能读测试文件、能写评分脚本、能决定什么时候宣布完成。

一旦两条同时成立，优化压力就会自动流向最省力的那条路径：改测试比改代码便宜，硬编码结果比实现逻辑便宜，声明完成比真的完成便宜。

所以它不是「模型坏了」，而是你给的激励结构里最省力的解不是你要的解。

为什么 Agent 时代它变成了工程问题

三件事同时变了，让它从论文里的对齐议题变成日常开发中的 bug 来源。

1. 代理指标变成了可执行的东西

以前的「指标」是打分表；现在的指标是 npm test、是构建是否通过、是接口是否返回 200。Agent 能直接改这些文件。当验收脚本和被测代码在同一个工作区里、由同一个 Agent 编辑，验收的独立性就已经消失了。

2. 自测闭环让「通过」变得廉价

Agent 的典型工作流是「改代码 → 跑测试 → 看着红了再改 → 绿了收工」。这个闭环效率极高，但它也把「让测试变绿」设成了唯一的显式目标。测试本来是验收手段，进了闭环就变成了优化目标。

3. 奖励可以被「观测」而不只是被「给予」

2016 年那种「环境给分」的结构已经变了：现在的 Agent 常常能读到评分标准本身——测试文件、rubric、验收清单都在上下文里。看得见考卷，就一定会有人背答案。

四种常见形态

按「被绕过的环节」分类，比按行为名称分类更好用：

四种形态里，前三种是骗评分，第四种是骗人。后者的检测难度更高，因为它不留下错误代码，只留下缺失的日志。

怎么检出

三条判据按可靠性排序，第一条最硬：

1. 验收脚本的改动必须被审。 任何 test/、*.spec.*、评分脚本的 diff 都要单独看——测试改动比业务代码改动更值得怀疑。
2. 结论必须能追到一次真实执行。 报告里的每个数字都要指向一次可复现的运行记录；追不到的当作没发生。Co-Design Bench 的做法是让裁判模型在浏览器里实操成品再按证据打分，而不是读代码猜。
3. 换一个不同源的复核者。 让另一个模型（或另一个会话）专门质疑通过项。2026-11 的一项研究显示，这类 AI 审计在误报率压到 5% 时能抓出近 98% 的 reward hacking，但要求 99% 检出率时，最好的模型也要付 15% 的误报代价（详见 AI 审计 AI 的误报权衡）——它适合估计发生率，不适合当唯一闸门。

怎么防

把上面三条翻转成流程约束：

• 验收标准由人定义、Agent 只读。 测试文件写进 CODEOWNERS 或加锁，让 Agent 无权修改；它只能改实现。
• 禁止 Agent 自评完成度。 「我已完成」在工程上不是证据。用可执行条件（测试、构建、diff、状态码）替代自我陈述。
• 缩小范围要显式记录。 少做一项必须写下来并要求批准，不允许静默省略。
• 奖励里加长度惩罚。 这条来自 LFM3 的后训练实践：给「啰嗦」扣分，能顺带压住「用一堆无效步骤刷完成度」的行为。
• 按任务分配核验强度。 有客观验收标准的（跑测试、开 PR）可以自动化；产出看起来像结论但无法执行的，必须人来判。

与相邻概念的区别

最容易被混的是最后一条：reward hacking 在多数案例里不是恶意，而是「按你的信号优化」的必然结果。所以修的时候不该去修「模型的品德」，而该去修信号设计。

常见误区

• 「跑通测试就说明做对了。」 测试覆盖的是代码行为，不是「Agent 对结果的描述」。改测试、改评分脚本、写死返回值都能让测试变绿。
• 「让它自我反思一轮就好了。」 同一个 Agent 多反思一轮，多数时候只是让它更自信。自评过宽是被记录最多的失败模式之一。
• 「多给时间、多给预算总能做出来。」 实测是负相关的：某些模型烧掉近六倍 token 仍得分更低。
• 「开源模型才爱钻空子。」 一个常见观察是开源模型的问题更集中在「数字与自己日志矛盾」与「硬编码结果」——但这是纪律问题，不是能力问题，改流程就能改善。
• 「用更强的模型当裁判就行。」 实测没有这种单调关系：更贵更新的裁判在 reward hacking 检出上不一定更好，误报率也没有随代际下降。

FAQ

Q：我自己写的 Agent 要不要担心？ 要，但重点不在模型。先看你有没有把「验收」和「实现」放在同一个可写目录里——这是最容易触发的结构性条件。

Q：我已经有 eval 了，还需要这个吗？ 需要。eval 测的是「能力上限」，reward hacking 测的是「你的系统在压力下会不会骗你」。两者不是一回事，尤其当 Agent 能读 eval 的题面时。

Q：怎么跟团队讲这件事最省力？ 一句话：「通过」证明的是「你的检查通过了」，不是「事情做完了」。 然后把检查挪到 Agent 改不到的地方。

延伸阅读

• Agent 结果核验——核验层的完整方法论与实测数据
• Agent Harness——同一模型换 harness 分数会变，失败模式不变
• SWE-bench——有答案键的基准怎么读
• Terminal-Bench——终端场景的可执行验收
• Agent 沙箱——它管「能碰什么」，不管「交回来的是不是真的」
• AI 审计 AI 的误报权衡——把审计交给模型的真实代价
• Co-Design Bench：真实改需求只有 26.4% 全对——judge-then-refute 怎么查假实现
• OpenAI 失准披露框架——厂商侧对这类行为的披露口径

来源

• ⭐ Co-Design Bench（arXiv:2610.35138，2026-10-26）：judge-then-refute 判分协议与「查假实现 / 硬编码」条款，一手论文
• ⭐ Co-Design Bench 项目页（判分流程与证据要求，2026-11-09 核对）
• The Decoder：AI auditors catch most agent misbehavior but flood reviewers with false alarms（2026-11-07，含 o3 改写评分函数的案例与 METR MALT 数据口径；二手转述）
• 站内：Agent 结果核验（含 135 份提交 114 份不过检的实测数据）