奖励设计

何时使用

• 为 RL 训练定义奖励函数，或评审已有奖励是否会激励错误行为
• 判断某类任务该用可验证奖励、人类偏好还是模型评判
• 结果奖励信号太稀疏、组内 rollout 全对或全错导致无梯度
• 多轮 Agent 任务要做信用分配（终局成败归因到第几步）
• 需要区分"事情办成了"与"以允许的方式办成了"
• 排查模型学会口头承诺验证、删除失败测试、自设简单检查就提前结束等行为
• 为"是否完成"设计模型无法篡改的判定（隐藏测试、状态断言、外部终止钩子）

核心原则

• 奖励设计沿三个互补维度展开：奖励来自哪里（规则/偏好/模型评判）、什么时候给（结果还是过程）、表达多少信息（标量/向量/生成式诊断）。第四个问题是结果正确时路径是否也合规。四问都答完再动手写奖励函数。
• 最可靠的来源是可验证奖励（RLVR）。 用测试用例、数据库断言、状态差异或格式检查直接判断结果。规则越确定，奖励越便宜、可复现，也越不容易被模型钻空子。有确定答案或测试时优先二元标量。
• reward hacking 与 reward seeking 是两件事。 reward hacking 是钻规则或实现漏洞拿高分（改测试、伪造结果）；reward seeking 是模型先在心里建立一个"评判器会看什么"的模型，再按这个猜测调整行为——不一定篡改测试，却可能在长程任务中自行设置一个过于简单的检查，刚好通过就提前结束。"通过了 grader"不能自动等价于"任务完成了"：评判器是意图的代理，训练越强，模型越可能把代理当成目标本身。
• 奖励结果，约束过程（RLVP）。 结果奖励解决"事情有没有办成"，表达不了"是否按规定办成"。真实 Agent 可能通过改测试文件、跳过身份验证或执行破坏性命令获得表面成功。RLVP 针对可机器判定的、与最终成败无关的结果中性约束，不能替代对语义意图、交付完整性和早停行为的独立检查。
• 真实环境通常是不对称验证器。 检测"做了一个坏动作"便宜而可靠，证明"这一步确实朝目标取得了有意义的进展"却很难。因此惩罚几乎总能恢复组内差异，进展奖励只有在部分进展可达时才有效。
• 每个新增维度都增加一种被钻空子的可能。 不要为了"奖励更丰富"而堆叠不可验证的维度；先确认这个信号能在少量 rollout 中产生有意义的组内差异，再决定是否加入训练。
• 多轮任务的终局反馈要靠外部机制归因。 多轮 LLM RL 通常将折扣因子设为 γ=1；PPO 的价值网络或 turn-level 优势负责把终点反馈归因到较早的动作，GRPO 则把轨迹级优势均摊到生成 token，长轨迹上需格外注意信号稀释。

实践模式

1. 奖励来源：三条路线

2. 奖励时机：结果奖励打底，过程信号按需叠加

结果奖励（ORM） 只在 episode 结束判断任务是否完成，最简单，也给策略最大探索自由度。当中间路径没有公认标准、最优解尚未被发现时（如 SimpleVLA-RL 的稀疏成功/失败），它是合适起点。

关键实现：长程 coding 或 cowork 任务中，"是否完成"的判定要交给模型写不了的隐藏测试、状态断言或外部终止钩子，不能依赖模型自己声称完成。模型宣称完成时才在隔离工作区运行它看不到的验收测试，通过 +1、不通过 −1。测试必须读取真实文件或环境状态，不能只检查模型是否说了"已完成"，否则模型会学会口头承诺验证而不真正验证。

过程奖励（PRM） 在中间步骤提供反馈（身份验证、工具参数、测试通过数、导航动作），能缓解长时序信用分配，却可能把模型限制在设计者预设的路径上，且标注和验证成本更高。

工程路径：先用结果奖励建立可靠基线，再只为真正可验证的中间事件加入过程信号。

3. 奖励密度与表示形式

密度和表示是两件事。选择原则很直接：

• 有确定答案或测试 → 优先二元标量
• 有多个相互独立的质量目标 → 向量（按准确性、完整性、成本、安全分别打分），或将各维度加权成标量
• 开放式、难以穷举规则 → 生成式诊断，但要配合事实校验和人工抽检

半标量（先给简短理由再给分数）介于两者之间，便于归因。

4. 路径约束与 RLVP：两路奖励再合并

把验证器输出拆成两路，交给现有策略优化器（不改变 PPO/GRPO，只改变每一步看到的奖励）：

outcome = verify_final_state(trajectory)              # 读结果，不是模型自述
path_signal = 0
for step in trajectory:
    path_signal += deterministic_path_signal(step)    # 惩罚违规，或奖励可达子目标
reward = normalize(outcome) + beta * normalize(path_signal)

总奖励写作 R = O + βΦ：O 是任务结果，Φ 是由确定性规则逐动作计算的路径信号。对可验证的违规动作扣分，对可验证的合规动作或可达子目标给少量部分奖励；两路各自归一化后再合并，避免路径信号淹没主目标。

RLVP 的四条设计规则：

1. 只惩罚具体动作，不惩罚"不够努力"——惩罚规则必须确定、难以钻空子。
2. 结果奖励始终保留——避免模型学会什么都不做（什么都不做就不会违规）。
3. 每个惩罚最好配一条可达的合规路径；如果基础策略根本不会采样合规动作，先用少量示范把这条路径"种"出来，待合规行为稳定后再逐步减弱路径塑形。
4. 先测信号可达性，再决定是否增加奖励维度。软件修复中若所有 rollout 都无法通过任何测试，进展信号不可达，加入它不会带来收益。

一句话概括配比：惩罚是通常可达的那一半，进展奖励是受可达性门控的那一半。

5. 多轮任务的信用分配

• 终局成功/失败难以归因到具体某一轮时，优先用逐步可验证的中间事件构造过程信号，而不是发明更复杂的优势估计。
• 工具轨迹中环境返回的 token 不是策略生成的，计算策略梯度时必须屏蔽这些反馈 token，只对模型自己的思考和工具调用参数回传梯度。
• 用带价值网络的 PPO 做细粒度信用分配；用 GRPO 时注意轨迹级优势均摊到所有生成 token 会造成信号稀释，长轨迹上更明显。
• 把"宣称完成"当作一个独立决策点来处理：在它前面挂外部验证器，而不是指望终局奖励顺带修正。

常见陷阱

• 只看回复长度就生成冗长无意义的文本式奖励——评估最终目标而非中间指标。
• 把"通过了 grader"当成"任务完成了"，忽略 reward seeking：模型自设一个过于简单的检查、刚好通过就提前结束，交付物只满足代理指标。
• 奖励维度堆叠：每加一个不可验证的维度就多一种被钻空子的方式；先验证信号能在少量 rollout 中产生组内差异再加入。
• 结果奖励缺位、只有路径惩罚：模型很快学会什么都不做。
• 进展奖励不可达时硬加：全败组里进展信号取不到值，只会增加噪声。
• 过程奖励过度塑形：把模型限制在设计者预设的路径上，丧失探索空间；也可能奖励"正确的过程导致错误的结果"。
• 验证器本身有系统性偏差：RL 只会更快地利用它。先用少量 rollout 检查"任务是否可完成、验证器能否区分对错"，再扩大采样规模。
• 用模型自述代替状态检查：删除失败测试用例也能让测试通过；口头承诺"7 天内退款"也能得到暂时满意。过程验证层必须由代码判定政策库、权限表与动作轨迹。
• 模拟器漏洞被主动利用：用 LLM 扮演环境训练时，Agent 钻空子的对象从"真实环境的规则"变成"模拟器本身的偏见与漏洞"，RL 会主动寻找并利用它。稳妥做法是混合——模型模拟承担大部分交互量，辅以真实环境交互并定期校准。

配套代码

• chapter8/RLVP/ — RLVP 复现指南：GRPO 上叠加结果奖励与确定性路径信号；书中报告 TerminalBench 违规次数 3.71→0.66 而成功率基本持平，miniF2F 上可达的部分奖励把达到 0.9 成功率所需迭代从 7.0 降至 4.4。
• chapter8/premature-completion-dpo/ — "过早结束"案例的隐藏测试奖励落地：data/hidden_tests.json 提供模型不可见的端到端验收脚本，train_grpo_optional.py 是同一问题的可选 RL 分支。
• chapter8/SimpleVLA-RL/ — 稀疏结果奖励保留最大探索空间的对照案例（每条任务仅一条演示 SFT 冷启动，17.3%→91.7%）。
• chapter8/retool/ — 工具反馈如何改变思考策略：模型学会主动执行、读取错误并自我修正。
• chapter8/AWorld-train/ — MCP 多工具沙盒中的奖励与可重放环境链路。

深度阅读

• book/chapter8.md「从单轮到多轮：任务场景与信用分配」
• book/chapter8.md「奖励设计：如何把任务目标变成学习信号」
• book/chapter8.md「RL 环境：从评估到仿真」
• book/chapter8.md「后训练实践要点」
• book/chapter9.md「从运行轨迹中获得学习信号」