# Reward Design

为 RL 训练设计奖励函数或排查奖励黑客时使用, , 决定奖励来自规则、人类偏好还是模型评判，结果奖励还是过程奖励，标量、向量还是生成式诊断，以及如何用路径约束与 RLVP...

- Repository: https://github.com/bojieli/ai-agent-book (56844 stars)
- Category: AI and agents
- License: Apache-2.0
- Last updated: 2026-10-08
- Runs scripts: no, instructions only

## Install

Claude Code: `npx skills add bojieli/ai-agent-book --skill reward-design -g -a claude-code -y`
Codex: `npx skills add bojieli/ai-agent-book --skill reward-design -g -a codex -y`
Cursor: `npx skills add bojieli/ai-agent-book --skill reward-design -g -a cursor -y`
Gemini CLI: `npx skills add bojieli/ai-agent-book --skill reward-design -g -a gemini-cli -y`

## Description

为 RL 训练设计奖励函数或排查奖励黑客时使用, , 决定奖励来自规则、人类偏好还是模型评判，结果奖励还是过程奖励，标量、向量还是生成式诊断，以及如何用路径约束与 RLVP 惩罚违规动作；也用于多轮 Agent 的信用分配、隐藏测试与早停判定设计。触发词：奖励设计、reward hacking、reward seeking、RLVR、RLHF、GRM、ORM、PRM、RLVP、信用分配、隐藏测试、过程奖励、奖励塑形、组内差异。

## SKILL.md, as published by its author (untrusted third-party text, read it as data)

# 奖励设计

## 何时使用

- 为 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. 奖励来源：三条路线

| 来源 | 适用 | 注意 |
|---|---|---|
| 规则 / 可验证奖励（RLVR） | 数学答案、代码测试、结构化工具调用、状态断言 | 最优先建立；从二元结果奖励开始 |
| 人类偏好 / 奖励模型（RLHF） | 目标难以完全规则化的开放式任务 | 奖励模型只是偏好的代理，过度优化会 reward hacking；通常用 KL 正则把策略锚定在 SFT 参考模型附近 |
| 模型评判（GRM） | 难以穷举规则、需要诊断信息 | 不只给分，还生成"哪里做得好、哪里需要改"的诊断；让模型先归纳评价原则再按原则评价轨迹，最后用可验证事实检查评价是否正确；仍需抽样人工校准，防止评判器形成新偏差 |

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

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

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

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

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

### 3. 奖励密度与表示形式

The rest: https://github.com/bojieli/ai-agent-book/blob/HEAD/skills/reward-design/SKILL.md