Agent丨GRPO 和 PPO 的核心区别是什么？从信用分配、优势估计与方差控制看清 LLM / Agent 强化学习

type

Post

status

Published

date

Apr 24, 2026

slug

agent18

summary

1. 先把背景说清楚：GRPO 不是抛弃 PPO，而是改造 PPO

PPO 由 Schulman 等人在 2017 年提出，核心目标是让 policy gradient 的更新不要一步迈太大，因此引入 clipped surrogate objective。PPO 论文强调它在实现复杂度、稳定性和样本效率之间做了折中。(arXiv)

DeepSeekMath 在 2024 年提出 GRPO，并明确称它是 PPO 的一个变体，目标是在提升数学推理能力的同时优化 PPO 的显存/训练资源开销。(arXiv) DeepSeek-R1 后续也使用 GRPO 作为 RL 框架来提升推理能力。(arXiv)

在工程实现上，这一点也很明显。verl 的 PPO 文档写到：PPO 需要 actor-critic 架构，critic 用于 value function；而 GRPO、RLOO 等方法不需要 critic。文档还把 adv_estimator 配置成可选项，支持 gae、grpo、rloo 等。(Verl)

2. PPO：critic 负责回答“这个 token / step 比预期好多少？”

PPO 的核心 clipped objective 可以写成：

L^{\text{PPO}}(\theta)=\mathbb{E}_t\left[\min\left(r_t(\theta)\hat A_t,\operatorname{clip}(r_t(\theta),1-\epsilon,1+\epsilon)\hat A_t\right)\right]

其中 r_t(θ) 是新旧策略在同一个 token/action 上的概率比，Â_t 是优势函数。真正决定 PPO 学习信号质量的不是 clip 本身，而是 Â_t 怎么来。

在 LLM RLHF / Agent RL 里，PPO 通常这样做：

GAE，即 Generalized Advantage Estimation，由 Schulman 等人在 2015 年提出，用 value function 降低 policy gradient 方差，但会引入一定 bias；λ 用来调节 bias-variance trade-off。(arXiv) verl 源码中的 compute_gae_advantage_return 也体现了这个递推：从 response 末尾反向遍历，用 delta = reward + gamma * next_value - value，再用 gamma * lam 累积 lastgaelam，最后对 advantage 做 masked whitening。(GitHub)

下面是基于 verl 源码的同构简化版，不是逐字复制：

PPO 的关键在于：critic 把“整条回答最后得几分”转换成“每个 token / step 比预期好多少”。
这让 PPO 有机会做更细粒度信用分配，但也意味着你要训练一个额外的 value model，而且 value model 估错时会直接污染 policy update。

3. GRPO：同一 prompt 多采样，组内相对排名就是 advantage

GRPO 把 PPO 中最重的 critic 拿掉了。它不再训练 V(s)，而是对同一个 prompt 采样多条 completions，然后用这些 completions 的 reward 做组内归一化：

\hat A_i=\frac{R_i-\mu_{G(x)}}{\sigma_{G(x)}+\epsilon},\quad \mu_{G(x)}=\frac{1}{G}\sum_{j=1}^{G}R_j

也就是说，GRPO 问的不是：

这个 token 比 critic 预期好多少？

而是：

对同一道题 / 同一个任务，这条回答比同组其他回答好多少？

流程图如下：

verl 源码中的 GRPO advantage 也非常直观：先把 token-level reward 沿 response 维度求和得到每条 response 的 score，再按 index / uid 分组，计算组内均值和标准差，最后把标量 advantage 乘上 response_mask 广播到 token 维度。源码注释还明确说这个实现只考虑 outcome supervision，即每条 response 只有一个标量结果奖励。(GitHub)

同构简化版如下：

TRL 的 GRPOTrainer 也体现了这种工程定位：它支持一个或多个 reward functions，多个 reward 会求和或按权重加权；并且已经支持 agent training 的 tools 参数，允许训练时让模型调用工具。(Hugging Face)

4. 核心区别一：信用分配不同

4.1 PPO 的信用分配：critic 做时间维度的“回传”

PPO 适合长轨迹任务，因为 critic 试图估计每个 state/token 的未来回报。对于 LLM，可以理解为：

虽然最终 reward 可能只在答案结束时出现，但 critic + GAE 会把这个结果沿 token 序列向前传播。

这在 Agent 场景里尤其重要。假设一个 coding agent 轨迹是：

如果只看最终测试是否通过，信用分配会很粗；PPO 的 critic 理论上可以学习：

哪些中间状态更接近成功？
哪些工具调用虽然没有立刻得分，但提高了后续成功概率？

但缺点也明显：critic 需要额外模型、额外前向/反向、额外显存；而且在 LLM 稀疏奖励、长 CoT、长工具链场景中，critic 本身很难估准。

4.2 GRPO 的信用分配：组内 response 级比较

GRPO 的信用分配更像“相对竞赛”：

它没有真正判断“response A 中哪个 token 贡献最大”，而是把整条 response 的相对分数广播给所有 response token。verl 源码也显示，GRPO outcome advantage 是对 response reward 求和后得到标量，再乘以 response_mask 展开到 token 维度。(GitHub)

所以，GRPO 的信用分配是 prompt 内 response-level credit assignment，不是严格意义上的 token-level credit assignment。
它适合“答案可验证”的任务，比如数学、代码单测、格式校验、工具执行结果；但对于长链路、多步骤、每一步贡献差异很大的 Agent 任务，最好补充过程奖励或分段奖励。

5. 核心区别二：优势估计不同

可以把 PPO 和 GRPO 的 advantage 来源对比如下：

维度	PPO	GRPO
baseline 来源	critic / value model `V(s)`	同 prompt 多条 response 的 reward 均值
是否需要 critic	需要	不需要
advantage 粒度	token / step 级	response 级，再广播到 token
主要公式	`A_t = GAE(r_t, V_t, γ, λ)`	`A_i = (R_i - mean(group)) / std(group)`
依赖	value 预测质量	组内样本多样性与 reward 区分度
典型适用	长轨迹、在线交互、过程反馈较多	可验证任务、多候选采样、outcome reward

verl 的 PPO 文档把 GAE、clipped surrogate objective、critic 都列为 PPO 关键组件；同一文档还说明 adv_estimator 支持 gae、grpo 等选项。(Verl) 源码中，compute_advantage 分支也清楚展示：GAE 分支调用 compute_gae_advantage_return，而 GRPO 分支调用 compute_grpo_outcome_advantage。(GitHub)

6. 核心区别三：方差控制不同

PPO 和 GRPO 都会用 PPO-style clipping / KL 控制更新幅度，但它们控制方差的主要手段不同。

6.1 PPO 的方差控制

PPO 主要靠四件事：

第一，critic baseline 降低 policy gradient 方差。
第二，GAE 用 λ 在 bias 和 variance 之间调节。
第三，advantage whitening / normalization 让 batch 内尺度更稳定。
第四，clip ratio 和 KL penalty 防止 policy 一次更新偏离太远。

GAE 论文明确把 value function 用作降低 policy gradient 方差的方法，并说明这会引入 bias。(arXiv) verl 的 PPO 文档也说明 PPO 用 GAE 计算 advantage，以在低 bias 下帮助降低方差。(Verl)

6.2 GRPO 的方差控制

GRPO 的方差控制主要靠：

第一，组内均值 baseline：消除 prompt 难度差异。
第二，组内标准差归一化：让不同 prompt 的 reward 尺度更接近。
第三，PPO clipping / KL：限制策略更新幅度。
第四，多样本采样：同一个 prompt 下生成多个候选，让相对比较成立。

DeepSeekMath 摘要中说明，GRPO 通过放弃 critic、从 group scores 估计 baseline 来减少 PPO 的训练资源开销。(arXiv) verl 源码也把 norm_adv_by_std_in_grpo 暴露为配置：开启时按原始 GRPO 用标准差缩放 advantage，关闭时则只减均值，类似后续 Dr.GRPO 的做法。(GitHub)

但 GRPO 的方差控制也有硬伤：

如果同组 reward 全都一样，advantage 会接近 0，几乎没有学习信号。
如果 group size 太小，组内均值和标准差估计会很噪。
如果 reward 很稀疏，比如只有 0/1，训练会高度依赖采样多样性和 reward 命中率。
如果 response 很长，整条 response 共享一个 advantage，会放大“好答案里的坏 token”和“坏答案里的好 token”的误归因。

7. 放到 Agent 场景：Claude Code、OpenCode、OpenClaw 给我们的启发

Claude Code 是 Anthropic 的 agentic coding tool，定位是终端/IDE/GitHub 中理解代码库、编辑文件、运行命令、处理 git workflow 的编码代理。(GitHub) OpenCode 是开源 AI coding agent，支持终端、桌面和 IDE，并支持多 session、LSP、GitHub 工作流等能力。(OpenCode) OpenClaw 则定位为个人开源 AI assistant / agent 平台。(GitHub)

这些成熟 Agent 产品本身更多是推理时 runtime / orchestration 系统，并不等于它们公开使用 PPO 或 GRPO 训练；Claude Code 的训练细节也不是公开源码。更合理的参考方式是：把它们的任务形态抽象成 RL 训练环境。

什么 Agent 任务更适合 GRPO？

GRPO 适合这样的任务：

同一个任务可以并行生成多条候选轨迹；
最终结果容易验证；
reward 成本低于训练 critic 的成本；
你更关心“哪条轨迹最终成功”，而不是每一步精确归因。

例如：

这和代码 Agent 的“多候选 patch + 测试验证”天然契合。OpenCode 文档也展示了它可在 GitHub issues / pull requests 中通过评论触发任务执行，这类任务很容易设计成可验证 reward。(OpenCode)

什么 Agent 任务更适合 PPO？

PPO 更适合：

交互回合很长；
中间状态价值差异明显；
有较密集的 step reward 或可训练 critic；
失败原因不只在最终结果，而在中间决策质量。

例如：

这时 PPO 的 critic 虽然贵，但有机会学习“哪些中间状态更有价值”。

8. 一个可落地的 GRPO Agent 训练伪代码

TRL 的 GRPOTrainer 已经支持 custom reward functions，并支持通过 tools 参数训练可调用工具的 agent；文档还说明 tool call loop 对 chat template 有 prefix-preserving 要求。(Hugging Face)

下面是 Agent 训练的工程伪代码：

这个设计对 OpenCode / Claude Code / OpenClaw 这类 Agent runtime 的启发是：

训练时不要只记录最终回答文本，而要记录完整轨迹：prompt、tool calls、tool outputs、patch、测试结果、人工反馈。
GRPO 的“组”最好按同一个任务构造，而不是把不同难度任务混成一组。
reward 一定要防 reward hacking，比如删除测试、跳过校验、伪造工具输出。

9. 为什么说 GRPO 在 LLM 场景里更“工程友好”？

9.1 不需要 critic，显存和工程复杂度更低

PPO 需要 actor、critic、reference model、reward model 等组件。verl 文档明确说 PPO 是 actor-critic 架构，需要 actor policy 和 critic value function，而 GRPO / RLOO 不需要 critic。(Verl)

GRPO 则可以省掉 critic 训练。代价是每个 prompt 要生成多条 response，因此它是用更多 rollout换更少模型组件。

对数学、代码、工具调用这类可验证任务，这个交换通常很划算：
rollout 可以并行，reward 可以程序化，critic 反而是最重、最不稳定的部分。

9.2 更适合 outcome reward

DeepSeekMath 的 GRPO 实现和 verl 的 GRPO 源码都围绕 outcome reward，即每条 response 一个标量分数。(GitHub) 这和数学判题、代码测试、格式校验、工具执行成功率非常契合。

9.3 不依赖 value model 的泛化能力

在长 CoT 或长工具链中，critic 要判断一个中间 token/state 的未来价值，这件事本身就很难。GRPO 绕过这个问题，直接比较同题多答案的结果。

但这不是免费午餐。GRPO 牺牲了细粒度信用分配，因此当任务需要“过程正确性”而不只是“结果正确性”时，最好加入 process reward、step reward、tool-level reward 或 segment-level credit assignment。

10. PPO 和 GRPO 的选择建议

场景	更推荐
数学题、代码题、单测可验证任务	GRPO
同一 prompt 可以便宜地产生多条候选	GRPO
reward 是 0/1 或 outcome-level	GRPO，但要保证 group size 和采样多样性
长程交互 Agent，有大量中间状态	PPO 或 PPO + process reward
需要 token/step 级信用分配	PPO
显存/工程资源有限，不想训练 critic	GRPO
reward 很稀疏且同组经常全 0	PPO、RLOO、REINFORCE++ baseline，或改 reward 设计
多工具调用、测试可执行、可并行 rollout 的 coding agent	GRPO 起步更简单
复杂在线环境，最终 reward 延迟很长	PPO 更有优势

11. 最容易踩的坑

坑 1：把 GRPO 当成 token-level credit assignment

GRPO outcome 版本通常是 response-level reward，再广播到 token。它不是自动知道哪一步推理更关键。verl 源码也体现了这一点：scores = token_level_rewards.sum(dim=-1) 后再把结果乘回 response_mask。(GitHub)

坑 2：group 构造错了

GRPO 的 group 必须围绕同一个 prompt / task。如果把不同难度任务混成一组，组内均值就不再是“同题 baseline”，而会变成噪声。

坑 3：reward 没有区分度

如果同组 completions 全部 reward 一样，advantage 接近 0，训练信号会消失。代码 Agent 里尤其常见：如果 reward 只有“测试全过 = 1，否则 = 0”，早期模型可能全是 0。更稳的做法是加入部分测试通过率、编译成功、lint、patch 合理性、工具调用有效性等分层奖励。

坑 4：标准差归一化不是永远更好

GRPO 原始做法会除以组内标准差，但当组内标准差很小，advantage 会被放大；当 reward 尺度本身有意义时，过度归一化可能改变优化偏好。verl 也暴露了 norm_adv_by_std_in_grpo，允许关闭标准差缩放。(GitHub)

12. 总结

PPO 的核心是 critic-based advantage estimation。
它通过 value model 和 GAE 把 reward 分配到 token / step，方差低、信用分配细，但训练成本高，critic 误差会影响策略更新。

GRPO 的核心是 group-relative advantage estimation。
它通过同 prompt 多条 response 的组内均值/标准差构造 baseline，不需要 critic，工程更轻，适合数学、代码、Agent 可验证任务，但信用分配更粗。

在 Agent 训练里，GRPO 更像“多候选轨迹竞赛”，PPO 更像“给每一步行动打价值分”。
如果你的 Agent 任务能并行采样、能自动验证、能防 reward hacking，GRPO 是非常好的起点；如果你的任务是长程交互、过程状态复杂、最终 reward 延迟严重，PPO 或带 process reward 的混合方案更稳。