面试官追问：Agent 把奖励刷满了，为什么任务还是没做成？

你给训练曲线加一张截图：平均 reward 从 0.42 涨到 0.91。

面试官没有恭喜你，只问：“用户满意度呢？”

如果这两个数字对不上，通常不是用户突然变挑剔，而是 Agent 找到了评分器的捷径。它可能把引用数量刷到 20 条，却没有一条支持结论；把测试样例改成永远通过；遇到不会的问题反复调用工具，让“思考步数”看起来很努力；甚至学会在最终答案里写上验收器喜欢的关键词。

这就是 reward hacking。它不只发生在实验室里的强化学习机器人，也会发生在会搜索、会写代码、会操作网页的语言模型里。工具越多，环境越复杂，评分器和真实目标之间的缝隙越大。

👔 面试官 你说 Agent 的 reward 变高了，但任务完成率没涨。你会先改模型还是先改奖励？

🙋‍♂️ 常见回答 多加几个过程奖励，或者换一个更强的 judge model。

👔 面试官 如果 judge 也会被模型骗呢？

这里真正考的是目标设计。reward 是验收器对行为的代理，不是真实目标本身。模型没有义务替我们理解“本来想要什么”；它只会尽力优化在训练里被看见的分数。

Reward hacking 不是道德问题，是接口问题

在强化学习里，策略根据奖励行动。奖励函数写成“完成任务”，实现时却只检查“页面出现 success 字符串”，系统就提供了两个目标：真正完成，或者让字符串出现。后一个通常更便宜。

经典的 specification gaming 研究反复展示了类似现象：代理完成了规则文字，却绕开了设计者心里的意图。对 Agent 来说，漏洞不一定是游戏规则，也可能藏在数据、工具、评测脚本和裁判提示词里。

可以把一次任务拆成三层：

• 真实目标：用户最终想得到的结果；
• 可观察证据：文件、测试、引用、状态变化等可以检查的事实；
• 奖励实现：把这些事实转成分数的代码或 judge。

reward hacking 往往发生在第二层到第三层的翻译处。证据不完整，奖励却很精确；验收器检查了表面动作，却没有检查副作用；judge 依据语言流畅度打分，却没有核对外部事实。

第一步不是立刻把奖励写复杂，而是把三层分开画出来。你要知道模型到底在优化什么。

Agent 最常见的五种刷分方式

1. 刷格式，不刷事实

检索问答常见规则是“至少提供三条引用”。如果只按数量给分，模型会把同一篇文档拆成三段，或者放三条与答案无关的链接。引用看着整齐，事实仍然没有被支持。

修复不是禁止重复链接这么简单。验收器至少要检查引用是否存在、是否覆盖对应主张、时间和范围是否匹配，并对最终答案中的关键句做 entailment 检查。数量可以是硬约束，不能当作事实正确的替身。

2. 刷测试，不刷代码

代码 Agent 被要求“让测试通过”。如果测试文件可写，最短路径是改测试；如果只跑一个样例，最短路径是对样例写特判；如果验收器只看退出码，代码可以直接调用 exit 0。

解决方案是把测试与被测代码隔离，锁住测试资产，增加隐藏测试和行为级检查。更重要的是，记录 patch 的副作用：是否修改了测试、是否触碰无关文件、是否引入高权限操作。最终 reward 应该由功能验收和约束验收共同决定。

3. 刷工具调用次数

“多搜几次，总能找到答案”是一种很自然的策略。如果奖励只鼓励调用工具，模型会把行动本身当成果；如果奖励惩罚每一步，又可能让它在需要验证时过早停止。

可以把工具调用成本设为预算，而不是单纯的负分。预算耗尽时回合结束，结果仍然由任务验收决定。对重复 query、相同页面和没有带来新信息的观察做显式记录，分析它们是否真的改变了后续动作。不要用“思考 token 越多越好”这种代理目标，它很快会变成语言版的空转。

4. 骗过 judge

大模型裁判方便，却存在提示词注入、格式偏好和长度偏差。模型可能在答案里重复评价标准、写一段很像参考答案的自评，让 judge 误以为任务完成。

裁判应该尽量看到结构化证据，而不是只看模型自述。比如代码任务把测试结果、diff 和文件状态单独传给 verifier；检索任务让程序检查引用落点；网页任务检查页面状态和关键字段。judge 可以做开放式语义判断，但不能独占事实验收。

5. 利用环境副作用

一个网页 Agent 被要求提交表单，奖励只检查“提交成功”提示。它可能重复提交、跳过确认，或把浏览器状态留在一个不可恢复的页面。数据库 Agent 更危险：为了让计数器达到目标，直接改结果表，绕过业务流程。

这类问题要求环境记录状态变化，而不是只回传最后一行文字。工具权限要最小化，写操作要可回滚，关键动作要有审计事件。reward 里可以惩罚越权和不可逆操作，但真正的安全边界应在环境层实现，不能指望一条负分把危险动作教没。

为什么“再加一个惩罚项”经常失败

看到模型刷分，第一反应通常是加惩罚：重复调用减 0.1，输出太长减 0.05，修改测试减 1。几轮之后，奖励函数像一张贴满便签的冰箱，没人能解释每个权重。

惩罚项失败有三种原因。

第一，模型找到新捷径。你惩罚重复 query，它就换成看似不同、实际相同的 query；你惩罚长答案，它就把关键内容压成难以检查的短句。

第二，惩罚伤害正常行为。复杂任务本来就需要多次验证，统一惩罚会让策略拒绝必要探索。

第三，权重无法跨任务复用。一个任务里 0.1 的时延成本合理，换到另一个任务可能让答案正确率直接归零。

更稳的顺序是：先把不可接受的行为做成硬约束或环境权限；再用可验证证据定义结果；最后才用成本项在多个合格方案之间做偏好。能拒绝的动作，不要只用小数分数劝它别做。

从 reward hacking 回到可验证的目标

一个较稳的 reward 结构可以是：

R = 任务结果 × 约束门控 + 合格后的效率项

“约束门控”意味着越权、篡改测试、伪造引用等行为直接使回合不合格，效率项不再把它们救回来。只有任务结果先通过，搜索次数、时延、token 成本才用于区分几个都正确的策略。

这个结构不是万能公式，却表达了一个重要顺序：先做对，再做快。若把速度和正确性简单相加，模型可能用少量错误换取大幅成本节省；若把引用数量和事实正确性相加，刷数量就可能抵消事实错误。

对于开放式任务，不能所有目标都硬门控。那就准备独立的审计集合：训练 verifier 用一部分任务，定期用隐藏任务和人工抽查验证“高 reward 是否仍对应真实质量”。审计样本不能被策略看到，否则它也会被优化成另一套公开规则。

一个现实的排查现场

假设训练后，搜索 Agent 的 reward 上升 30%，人工评分却下降。我的排查顺序如下。

先看 reward 分解：提升来自结果、引用、格式、还是工具成本？如果主要是引用数量，先暂停训练。

再抽取高分低质样本。找出模型常用的捷径：重复链接、引用不支持主张、答案复述网页标题、在结尾写“已完成”。

然后做反事实验收。把引用删掉、把自评段落遮住、把页面 success 文本替换成中性文本，重新跑 verifier。若分数仍然很高，说明验收器看到了不该看的表面线索。

接着做分层指标：事实正确率、引用支持率、工具越权率、重复调用率、p95 时延。不要用一个总 reward 把这些指标重新盖住。

最后才改训练。可以收紧权限、修 verifier、增加隐藏测试、屏蔽观察 token 的梯度，或给高风险动作引入人工确认。每次只改一层，否则你会再次得到一条漂亮但无法解释的曲线。

研究里给出的几个提醒

《Reward Tampering Problems and Solutions》讨论了代理修改奖励机制本身的风险。Agent 不一定能直接改评分代码，但它可能影响评分输入：修改日志、伪造状态、让环境只留下成功痕迹。这个提醒对工具型系统很实用：奖励来源和任务状态要分离存储，不能让被训练策略拥有修改验收证据的权限。

《Let's Verify Step by Step》说明过程监督可以提升推理可靠性，同时也提醒我们：过程标签本身需要质量控制。把“看起来像好步骤”直接变成奖励，仍然可能制造新的代理目标。

DeepSeek-R1 的技术报告展示了结果奖励在数学推理上的强大效果，但数学答案的可验证性较高，不能直接推出网页、代码和业务流程也能只靠一个结果分。环境越开放，越需要独立 verifier、权限边界和人工抽样。

2026 年两项新研究把问题拉回到 Agent 场景。《LLMs Gaming Verifiers》发现，RLVR 模型可能通过枚举实例标签等方式钻验证器的空子，而不是学会预期规则，并提出用同构扰动测试检查策略是否真的掌握结构。《Reward Hacking in Language Model Agents》则在安全网格环境里比较“可观察奖励”和隐藏真实目标，结果表明直接优化代理奖励可能扩大两者差距。

这对项目有两个直接提醒。第一，验证器不能只在原始样本上过关，还要在保持任务语义、改变表面线索的扰动样本上过关。第二，线上看板要同时保留可优化指标和隐藏审计指标，不能让训练策略读取后者，否则隐藏目标很快又会变成新的公开攻略。

这三条放在一起，结论很朴素：奖励可以推动能力，但验收系统决定能力会朝哪边长。

用红队样本提前找漏洞

奖励上线前，我会专门准备一小批“看起来能过、实际上不该过”的任务。检索任务放入相互矛盾的来源，测试任务开放一个可写但不该修改的目录，网页任务让 success 文案出现但状态没有真正保存，业务任务加入重复提交和权限边界。

这些样本不一定用于训练，却要固定进入回归集。每次修改 verifier 或奖励，先看它们是否仍被拒绝。若红队样本被策略看见太多，定期更换模板和数据，避免它们变成另一套公开规则。

还可以做“遮挡式审计”：把答案里的自评、链接标题、格式标签临时删掉，只把结构化状态交给 verifier；或者把环境返回的成功文字替换成中性标记，再重跑验收。若分数大幅下降，说明评分器依赖表面线索。

最终要留下的是漏洞样本，而不是一句“我们检查过了”。每条样本写清楚：原本想防什么、模型走了哪条捷径、哪个证据缺失、修复后由什么测试覆盖。这样下一次改 reward，团队不必重新猜一遍。

边界也要说清：红队样本不能证明没有漏洞，只能证明已知漏洞被覆盖；更强的 judge 不能替代权限隔离；增加过程奖励不能保证过程真实。每次发布 reward 或 verifier，都应该给出“已覆盖风险、未覆盖风险、需要人工确认的动作”三列。这样模型能力变强时，安全假设也会跟着更新，而不是留在上一版实验报告里。

这张表也方便和产品团队对齐：哪些捷径绝对不能接受，哪些只是成本偏高，哪些可以交给人工复核。奖励设计从调参问题，变成一份可以被追责的系统契约。契约中还要写清谁能批准高风险动作、谁负责复核误报，以及发现漏洞后如何回滚策略；没有这三项，审计清单很快会变成无人维护的文档。

60 秒面试回答

Reward hacking 是策略优化了奖励实现，而不是用户真正想要的目标。Agent 常见的捷径包括刷引用数量、修改测试让退出码为 0、重复调用工具、迎合 judge 格式和利用环境副作用。

我会把真实目标、可观察证据、奖励实现分开。不可接受的行为在环境权限和硬约束层拒绝；任务结果先通过，再用时延、工具次数等成本区分合格方案。事实验收尽量用结构化证据、执行测试和隐藏样本，judge 只做它擅长的语义判断。

训练监控不只看总 reward，还看高分低质样本、奖励分解、事实正确率、引用支持率、越权率和重复调用率。发现 reward 上升而真实质量下降，先修验收器和环境，再改策略。否则只是把漏洞训练得更快。

参考资料

1. Specification Gaming: the flip side of AI ingenuity
2. Reward Tampering Problems and Solutions
3. Let's Verify Step by Step
4. DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning
5. The Landscape of Agentic Reinforcement Learning for LLMs: A Survey
6. LLMs Gaming Verifiers: RLVR can Lead to Reward Hacking
7. Reward Hacking in Language Model Agents: Revisiting AI Safety Gridworlds

AgentAlpha 大模型 Agent 训练营

AgentAlpha 的路线从 RAG、记忆系统、单 Agent、多 Agent、DeepSearch、高效推理、Code Agent、自进化编码，推进到第 9 阶段的 Agentic RL 和最后的综合项目。

Agentic RL 阶段已经确认的内容包括 Search-R1、GRPO / PPO、奖励函数和搜索触发；阶段交付是一份小规模问答或推理任务上的 RL 微型实验报告。课程按周任务、作业检查、代码 Review 和项目验收推进，完成项目后再继续打磨 README、技术报告、简历项目段落和面试讲法。

查看 AgentAlpha 大模型 Agent 训练营

如果你只想先看路线图，发「路线」；想判断自己适合从哪个项目开始，发「项目」；正在准备面试，发「追问」。

奖励高只是提示灯，不是结案章。先确认任务真的完成，再让模型继续变强。