面向 Agent 的强化学习：从 GRPO 到 Agentic RL

Agent 的 RL 不是”把 RLHF 用在多轮对话上”。它的奖励稀疏、horizon 长、环境不可微且非平稳、rollout 成本高一个量级——这五点差异，把算法和基础设施都改了。

导语

2024 年的 RL 后训练主线是 RLHF：偏好对 → 奖励模型 → PPO。2025 年的主线换成 RLVR：可验证奖励 → GRPO → 数学/代码能力跃升。2026 年的主线正在变成 Agentic RL：让模型在环境里跑几十步，用最终结果做奖励。

三次迭代不是同一件事的版本升级，而是问题结构在变：

	RLHF（2023–2024）	RLVR（2025）	Agentic RL（2025–2026）
决策步数	1（整段回复）	1（整段 CoT）	10–200（多轮工具调用）
奖励来源	人类偏好 → RM	程序验证（答案/单测）	环境终态 + 中间验证
奖励密度	稠密（一句话一个分）	稀疏（整条一个 0/1）	极稀疏（几十步一个 0/1）
环境	无（离线数据）	无（静态题库）	有状态、不可微、非平稳
rollout 成本	低	中	高（含真实工具调用与沙箱）
主要瓶颈	奖励模型偏差	奖励黑客 / 熵坍缩	信用分配 + 系统工程

本文按这个演进顺序展开：先讲清 Agent 的架构（因为”什么是策略、什么是环境”决定了 RL 怎么建模），再讲为什么 PPO 系在长任务上失效，然后是 GRPO / RLVR / Agentic RL 三层的技术要点，最后是 Slime 这类异步基础设施解决的工程问题。

0. 前置：把 Agent 形式化成 POMDP

0.1 一句话定义

Agent 的强化学习，优化的是这个目标：

1	max_θ E_{τ ~ π_θ} [ R(τ) ], τ = (s_0, a_0, o_1, s_1, a_1, ..., s_T)

其中 a_t 是一段 token 序列（不是单个动作），s_t 由环境转移 s_{t+1} ~ P(·|s_t, a_t) 决定，o_t 是部分观测，R(τ) 通常只在终态给一次。

四个关键性质，每一个都和传统 RL 不同：

性质	Agent 的具体形态	后果
动作是文本	`a_t = (tool_name, args)` 或自然语言	动作空间是离散但组合爆炸的；不可枚举、不可连续化
环境不可微	工具返回、HTTP 响应、文件系统	不能反传；只能靠 REINFORCE 类的 score function 估计
非平稳	网页会变、API 会限流、依赖会升级	同一个动作在不同 episode 得到不同奖励 → 方差天然很大
部分可观测	只看得到工具返回，看不到世界真实状态	必须靠上下文（history）当 belief state；POMDP 而非 MDP

0.2 学术界常做的简化（以及它带来的失真）

为了让训练跑得动，几乎所有工程实现都做了三个简化：

把 belief state 简化为完整 history（不做显式状态估计）；
把环境当作确定性（同参数同输入 → 同输出，实测不成立）；
只用终态奖励（R(τ) = r_T），放弃中间信号。

这三个简化的代价，正好是 Agentic RL 当前最主要的三类失败：上下文爆炸、训练方差大、信用分配不准。后面会逐一对应。

1. Agent 通用架构：哪些是策略，哪些是环境

1.1 五个组件

                 ┌─────────────────────────────┐
                 │  ① 规划 Planner              │
                 │  任务分解 / 子目标选择         │
                 └──────────┬──────────────────┘
                            ↓ 子目标
┌──────────────┐   ┌────────▼────────┐   ┌──────────────┐
│ ② 记忆 Memory │←→│ ⑤ 执行器 Executor │→│ ③ 工具 Tools  │
│ 短期/长期      │   │ 生成动作 + 解析    │   │ 检索/代码/API │
└──────────────┘   └────────┬────────┘   └──────┬───────┘
                            ↓ 动作                │ 观测
                 ┌──────────▼──────────────────┐ │
                 │  ④ 反思 Reflector            │←┘
                 │  失败归因 / 策略修正           │
                 └─────────────────────────────┘

组件	作用	在 RL 里的角色
① 规划	把任务拆成子目标序列	策略的一部分（可训练）
② 记忆	保存跨步/跨会话的信息	环境的一部分（通常是固定规则或外部检索）
③ 工具	与外部世界交互	环境（绝对不可微，且非平稳）
④ 反思	从失败中提取修正信号	策略的一部分，但也可以当奖励塑形器
⑤ 执行器	把子目标变成具体的 token/调用	策略（训练的实体）

1.2 这个划分为什么决定 RL 方案

关键洞察：只有 ①④⑤ 是可训练的，②③ 是环境。

这带来三个直接结论：

结论一：工具的质量决定 RL 的上限，且训练改变不了它。
如果某个工具本身不稳定（超时率 10%），RL 会学到”少用它”——这不是模型的进步，是模型的妥协。做 Agentic RL 之前，先把工具的成功率稳定在 95% 以上，否则你在训练模型去规避工程缺陷。

结论二：记忆模块的设计会污染信用分配。
如果记忆是”自动摘要”（每 N 步压缩一次历史），那么某一个动作的后果可能被摘要抹掉，模型无法把结果归因到那个动作。记忆的压缩是不可逆的信息损失，而 RL 需要的信息恰好是被压缩掉的那些细节。

结论三：反思模块是一个”免费的奖励信号源”，但也是奖励黑客的入口。
用 LLM 自评作奖励（self-reward），在短任务上有效；在长任务上会导致”模型学会说服自己成功了”——这是 Agentic RL 最隐蔽的失败模式。

1.3 一个被忽视的问题：动作粒度的选择

Agent 的动作可以是：

粒度	例子	优缺点
Token 级	每个 token 一个动作	最细，但 horizon 变成几万步，信用分配几乎不可能
工具调用级	一次 `search(q)` 一个动作	horizon = 调用次数（10–100），最常用
子任务级	“完成登录流程”	horizon 短（3–10），但需要分层策略

这个选择直接决定了 RL 算法怎么用：

工具调用级 → 可以把”一次调用内部的所有 token 共享同一个 advantage”（这也是 GRPO 在 Agent 场景的默认做法）；
Token 级 → 需要 token 级奖励，否则几万步共享一个标量，梯度全是噪声。

工程上 99% 的实现选工具调用级，然后在调用内部做 token 级 loss（同一个 advantage 广播到该调用的所有 token）。这个细节在论文里常被省略，但它决定了 loss mask 怎么写。

2. 为什么 PPO / Critic 方案在长任务上失效

2.1 回顾 PPO 的结构

PPO 的目标：

1 2	L = E_t [ min( r_t(θ) Â_t, clip(r_t(θ), 1-ε, 1+ε) Â_t ) ] r_t(θ) = π_θ(a_t\|s_t) / π_θold(a_t\|s_t)

其中 Â_t 是优势估计，标准做法是 GAE：

1	Â_t = Σ_{l=0}^{T-t} (γλ)^l δ_{t+l}, δ_t = r_t + γ V(s_{t+1}) - V(s_t)

这要求一个 value network（critic）V(s)。 对 LLM，就是再训一个同规模的模型，输出”当前状态的价值”。

2.2 五个失效点

失效点一：critic 本身训不出来

V(s) 要预测”从当前上下文出发的期望回报”。对 Agent 任务：

状态是几十轮工具调用的完整 history，长度几万 token；
同一个状态，不同环境随机性下回报差异极大（非平稳）；
早期训练时策略很差，回报分布全是 0 或 1，critic 学到的几乎是常数。

结果是 critic 的 MSE loss 长期居高不下，Â_t 接近噪声。用噪声当优势，PPO 的 clip 机制反而会放大偏差。

失效点二：显存与算力翻倍

7B 策略 + 7B critic + 7B reference（KL 约束用）= 21B 的显存占用。而 Agent 的 rollout 本身已经很长（几万 token 的 context），KV cache 会成为第一个 OOM 的地方。

失效点三：GAE 的 horizon 问题

GAE 用 λ 在”偏差”和”方差”之间折中。但 Agent 任务的 T 是 50–200 步，且奖励只在终点：

λ 小 → 优势几乎完全依赖 critic（而 critic 不准）；
λ 大 → 优势退化为 Monte Carlo（方差爆炸）；
没有中间地带，因为中间根本没有奖励。

失效点四：奖励尺度不一致

Agent 任务常有多种奖励：格式正确（+0.1）、工具调用成功（+0.2）、最终答案正确（+1.0）。critic 要拟合这种多尺度混合信号，比单纯的 0/1 更难。

失效点五：训练-推理不一致被放大

PPO 的 importance ratio r_t 假设 rollout 和 training 用的是同一个策略。但实际：

rollout 用 SGLang/vLLM（推理优化过的 kernel，bf16/fp8）；
training 用 Megatron（不同的 kernel、不同的并行切分）；
两者的 logprob 有系统性差异（1e-3 到 1e-2 量级）。

短序列上这个差异可忽略；长序列上，r_t 会随步数漂移，clip 频繁触发，有效样本被丢弃。这就是为什么大规模 RL 必须做 权重同步 + logprob 校正（后面第 5 节）。

2.3 RLHF 的另外两个 Agent 特有问题

问题一：偏好模型不适用于轨迹

RLHF 的 RM 是 r(x, y)——输入 prompt + 整段回复。对 Agent 轨迹，y 是 50 轮交错的 动作/观测，长度几十万 token。RM 在这种长度上：

注意力稀释，几乎只看得到开头和结尾；
无法判断”中间第 23 步的那个工具调用是否合理”。

问题二：人类标注不可行

给一条 50 步的 Agent 轨迹打偏好分，需要标注者理解每一步的工具语义、判断中间状态。成本是普通对话的 50–100 倍，且一致性极差（不同标注者给的分可能完全相反）。

这两点是 RLVR 出现的直接原因：不是”RLVR 更好”，而是”RLHF 在 Agent 上根本做不了”。

3. GRPO：去掉 critic 的极简方案

3.1 核心想法

GRPO（Group Relative Policy Optimization, Shao et al., DeepSeekMath 2024）的洞察非常朴素：

如果同一个问题的多个回答之间有可比性，那么”组内相对排名”就可以替代”绝对价值估计”。

于是：不用 critic，用同一 prompt 的 G 个采样结果互相比较。

3.2 公式

对每个问题 q，从旧策略采样 G 个输出 {o_1, ..., o_G}，每个得到奖励 {r_1, ..., r_G}。

优势（组内标准化）：

1	Â_{i,t} = (r_i - mean(r_1..r_G)) / std(r_1..r_G)

注意：**同一个 o_i 内所有 token 共享同一个 Â_i**（因为奖励是序列级的）。

目标函数：

1
2
3

J_GRPO(θ) = E[ (1/G) Σ_i (1/|o_i|) Σ_t ( min( ρ_{i,t} Â_i, clip(ρ_{i,t}, 1-ε, 1+ε) Â_i ) - β·D_KL(π_θ || π_ref) ) ]

ρ_{i,t} = π_θ(o_{i,t} | q, o_{i,<t}) / π_θold(o_{i,t} | q, o_{i,<t})

三个细节值得注意：

1/|o_i| 是长度归一化——它让长短回答的 loss 量级可比，但引入了长度偏置（见 3.4）；
KL 是加性惩罚而非合入奖励（DeepSeekMath 用无偏 KL 估计量），可以逐 token 算；
Â_i 不依赖 critic，完全由组内统计量决定。

3.3 为什么它能工作（三个解释）

解释一：组内标准化是一种”自适应基线”

REINFORCE 的方差来自 R 的绝对尺度。减去 baseline 不减方差是有条件的：Var(R - b) = Var(R) - 2Cov(R,b) + Var(b)，最优 b = E[R]。

GRPO 用 mean(r_1..r_G) 估计 E[R]，用 std 归一化尺度。这相当于一个不需要训练的、无参数的 value baseline——代价是只能用组内信息，不能跨状态泛化。

解释二：它天然适配”0/1 奖励”

对可验证奖励，r_i ∈ {0,1}。组内标准化的结果极其直观：

G=8 里 3 对 5 错 → 对的 Â = +0.65，错的 Â = -0.39；
全对或全错 → std = 0 → Â = 0，没有梯度。

后者是 GRPO 最大的工程问题（3.4 详述），但也是它的”诚实”之处：它不假装能从全对的样本里学到东西。

解释三：它把”比较”变成了学习信号

这是与 RLHF 的深层联系：RLHF 用人类比较 (y_w, y_l) 训练奖励模型；GRPO 用程序比较（奖励高低）直接在策略上做更新。跳过奖励模型，直接用可验证信号做相对排序——这是 RLVR 能用 GRPO 的根本原因。

3.4 五个必须知道的缺陷

缺陷一：全对/全错组产生零梯度（zero-variance group）

1	如果 std(r) = 0 → Â_i = 0 → loss 梯度 = 0 → 这个 batch 白跑

早期训练时，简单题（全对）和难题（全错）各占一半，**有效样本只有 10–30%**。这是 RL 训练”看起来在跑但指标不动”的最常见原因。

解法（DAPO，字节 2025）：动态采样——过滤掉全对和全错的组，只用”部分正确”的组做梯度。代价是要额外采样补足 batch size，rollout 成本上升。

缺陷二：长度偏置

1/|o_i| 归一化让长度不同的回答 loss 可比，但也意味着：

长回答的每个 token 权重小 → 模型倾向生成更长的回答（因为长回答”分摊”了同样的 loss）；
另一面：如果错误回答更长，惩罚被稀释。

Dr. GRPO（Liu et al., 2025） 的修法：去掉 1/|o_i|，改成”按 token 总数归一化（全局常数）”，同时去掉 std 归一化（因为 std 也会引入难度偏置——简单题的 std 小，梯度被放大）。

缺陷三：熵坍缩（entropy collapse）

clip(ρ, 1-ε, 1+ε) 是对称的。但实际分布是偏斜的：

高概率 token 的 ρ 上升空间有限（已经接近 1）；
低概率 token 的 ρ 下降空间大。

结果：采样分布越来越尖，熵单调下降，探索能力丧失。典型表现是训练后期 pass@1 涨但 pass@k 跌。

DAPO 的 clip-higher：把上界放宽（1+ε_high, 如 0.28）、下界保持（1-ε_low, 如 0.2）。给低概率 token 留出上升空间。

缺陷四：KL 惩罚对 Agent 任务的副作用

GRPO 保留 KL 约束（不偏离 reference 太远）。但 Agent 任务需要探索新的工具使用方式，而新方式在 reference 模型里概率极低 → KL 惩罚会把它们压回去。

DAPO 直接去掉了 KL（”long CoT 本来就要大幅偏离原模型”）。Agentic RL 里这个取舍更激进：很多实现只用 reference 做软约束，或者只在早期开 KL 后期关掉。

缺陷五：组内样本不独立（环境随机性）

如果环境有随机性（同一个动作可能成功也可能失败），G 个样本的奖励差异部分来自环境噪声而非策略差异。这时组内标准化会：

把”运气好”当成”策略好”，强化错误动作；
需要 G 足够大（8–32）才能把信号从噪声里分出来。

这就是 Agentic RL 需要比 RLVR 更大的 G 的原因——不是因为策略更难，是因为环境更吵。

4. RLVR：把”对不对”交给程序判断

4.1 定义与奖励构造

RLVR（Reinforcement Learning with Verifiable Rewards）的核心是：奖励来自一个确定性的、程序化的验证器（verifier），而不是学习出来的奖励模型。

1	r(τ) = verifier(answer(τ), ground_truth)

四类常见的 verifier：

类型	例子	可靠性	覆盖
答案精确匹配	数学题最终数值、选择题选项	极高	窄（需要答案唯一）
单元测试 / 执行	代码跑通测试、SQL 返回正确结果	高	中（需要可执行环境）
规则/格式校验	JSON schema、正则、长度约束	极高	只覆盖形式
环境终态检查	任务完成后文件状态、数据库状态	高	需要状态快照

Agent 场景最常用的是后两类 + 执行类，因为**Agent 的输出很少是”一个答案”，而是”环境的一个状态”**。

4.2 为什么 RLVR 在 Agent 上几乎是必然选择

对比 RLHF：

	RLHF	RLVR
奖励来源	人类偏好 → RM	程序验证
单条标注成本	高（人要读完整轨迹）	零（可无限次重跑）
一致性	低（标注者分歧）	完美（同一输入同一输出）
可被 hack	严重（reward model 过优化）	可控（除非 verifier 有漏洞）
适用长度	短（RM 看不了长轨迹）	长（verifier 只看终态）
覆盖范围	广（任何主观质量）	窄（必须有客观判据）

第 5 行是关键：verifier 只需要看终态，所以轨迹多长都无所谓。这一条让 RLVR 天然适配长程 Agent。

4.3 一个必须知道的清醒结论：Spurious Rewards

2025 年有一篇影响很大的论文（Spurious Rewards: Rethinking Training Signals in RLVR, arXiv:2506.10947）做了个反直觉实验：

在 Qwen2.5-Math-7B 上，把奖励换成随机奖励（完全不看答案对错，随机给 0/1），RLVR 训练后 MATH 上的表现仍然大幅提升。

这个结果的含义非常重：

**RLVR 的收益有一部分不是”学到了新能力”，而是”激发了已有能力”**——RL 的作用是让模型更倾向于输出它已经会的高概率路径，而不是学会新知识；
**”奖励涨了”不等于”能力涨了”**：如果奖励设计有偏，模型会优化那个偏的奖励；
不同模型家族对这个效应的敏感度差异极大（论文里 Qwen 敏感，Llama 几乎无收益）——这意味着”XX 模型用 RLVR 涨了 20 点”这类结论不能跨模型迁移。

工程含义：

做 RLVR 必须同时监控 pass@1 和 pass@k（前者涨后者跌 = 熵坍缩，能力没涨只是在收窄分布）；
必须有 held-out 的、分布外的评测集，防止在训练分布上过拟合；
**别把”奖励曲线”当”能力曲线”**。

4.4 奖励设计的五个坑

坑一：奖励黑客（reward hacking）

verifier 有漏洞时，模型会找到漏洞而不是解决问题。典型例子：

漏洞	模型学到的	修法
答案匹配用 `in` 判断	输出包含正确答案的所有可能形式	用严格解析 + 集合比较
单测只测 happy path	硬编码测试用例的返回值	隐藏测试 + 随机化输入
格式分权重过高	只输出格式不求正确	格式分设为必要条件而非加分项
环境终态检查不完整	只完成最简单的子任务就终止	全量状态断言

坑二：奖励尺度失衡

如果 r = 0.1·format + 0.2·tool_ok + 1.0·correct，模型会优先学”容易拿的分”（格式、调用成功），而”正确”的梯度被稀释。在训练早期，模型会先学会输出漂亮的格式，然后卡在那里。

修法：用必要条件而非加权和。r = 1.0 if (format_ok and correct) else 0.0。这会让奖励更稀疏（回到全 0 的问题），但避免了”局部最优陷阱”。

坑三：验证器与生产环境不一致

训练时用 mock 的工具（返回预置 JSON），上线用真实 API（返回格式略有不同）。**模型在训练里 90% 成功，上线 40%**。

这不是模型的错。verifier 必须跑在和线上一致的环境里，包括工具的超时行为、错误码、返回格式。

坑四：过度稀疏

终态奖励在 50 步任务上，成功率的初始值可能只有 3%。这意味着 G=8 的组里几乎全是 0，std=0，没有梯度。

三条缓解路径：

课程学习：从简单任务开始（成功率 30–50% 的难度带），逐步加难；
中间验证点：把一个长任务拆成几个可验证的子目标，每个给部分奖励（但这又引入了”部分完成”的 hack 空间）；
过程奖励模型（PRM）：训一个模型给每一步打分（成本高、本身也有偏差）。

坑五：验证器本身的成本

代码类任务的验证要跑测试，一次几秒到几十秒。G=8 × batch=256 = 2048 次执行，验证时间可能超过生成时间。这是 Slime 这类框架必须做异步的原因之一。

4.5 RLVR 的能力边界

能做的：数学、代码、结构化输出、有明确终态的任务（表单填写、文件操作、游戏通关）。

做不了的：

开放式写作（没有 verifier）；
需要”风格、语气、有用性”判断的任务；
多解且都合理的任务（verifier 只认一个答案，会把模型训练成”只走一条路”）；
长尾的专业领域（写 verifier 的成本高于标注成本）。

一个实用判断：如果一个任务你写不出 verifier，就不要用 RLVR。 强行用 LLM-as-judge 当 verifier，是把”奖励模型偏差”的问题换了个壳。

5. 基础设施：Slime 与异步 RL 的工程问题

5.1 为什么 RL 的工程比 SFT 难一个量级

SFT 是纯计算：读 batch → 前向 → 反向 → 更新。RL 多了一个闭环：

1	rollout（生成） → reward（验证） → train（更新） → 同步权重 → rollout ...

这个闭环引入四类工程问题：

问题	表现	影响
训推异构	rollout 用 SGLang/vLLM，train 用 Megatron	logprob 不一致 → importance ratio 有偏
长尾生成	agent 任务里 90% 在 10s 结束，10% 要 5 分钟	GPU 空转等待（利用率可能只有 30–50%）
权重同步开销	每步把几百 GB 权重从训练集群传到推理集群	通信时间可能超过计算时间
环境与沙箱	工具调用、代码执行、浏览器	状态管理、隔离、故障恢复

5.2 Slime 的设计

Slime（THUDM/智谱，github.com/THUDM/slime）的定位是”RL Scaling 的训练框架“，核心是两个能力：

高性能训练：把 Megatron（训练）与 SGLang（rollout）对接；
灵活数据生成：通过自定义生成接口 + server-based 引擎，支持任意 rollout 工作流。

架构是三段式：

┌────────────────┐      ┌──────────────┐      ┌─────────────────┐
│ training       │←────→│ data buffer  │←────→│ rollout         │
│ (Megatron)     │      │ (桥接模块)    │      │ (SGLang+router) │
└────────────────┘      └──────────────┘      └─────────────────┘
        │                                              │
        │ 训练后同步权重                                  │ 生成样本 + 奖励/verifier
        └──────────────────────────────────────────────┘

设计目标（官方表述）：让 Megatron 训练、SGLang rollout、自定义数据生成、奖励计算、verifier 反馈、环境交互，都走同一条 training / rollout / Data Buffer 路径，而不是堆叠成一堆互不相连的 trainer、rollout 服务和 agent 框架。

5.3 它解决的四个具体问题

问题一：训推一致的权重同步

三个层级的方案：

方案	机制	开销
全量同步	每步传完整权重	最高
Delta Weight Sync	只传变化的字节（走共享存储）	中
PD 分离 + 异步	prefill / decode 资源分开，权重异步流式更新	低，但有 staleness

“Delta Weight Sync”是关键优化：RL 每步的权重变化通常只有 0.1%–1% 的数值发生实质变化，传 delta 比传全量省一个数量级。

问题二：长尾 rollout（这是 Agentic RL 最大的效率杀手）

Agent 任务的生成长度分布极度不均。同步等待的结果是：

1 2	step 1: [====任务A 10s====][==任务B 12s==][=======任务C 95s=======] ↑ 前两个 GPU 空转 83s

Slime 的 examples/fully_async 提供完全异步 rollout——不等待整批完成，谁先结束谁先进 buffer。代价是引入 staleness（训练用的策略比当前策略旧了 N 步），需要：

重要性采样校正（用旧的 logprob 做 ratio）；
staleness 上限（超过 N 步的样本丢弃）；
更保守的 clip。

这是”吞吐 vs 偏差”的显式权衡。没有免费的异步。

问题三：Agent 工作流的接口解耦

Slime 用 --custom-generate-function-path 把 agent 逻辑注入标准 rollout 循环。官方给了几个例子：

examples/multi_agent：多 agent 生成；
examples/search-r1：搜索/RAG 式多轮；
examples/coding_agent_rl：coding agent + 沙箱 + 官方测试作奖励。

这个设计的意义：训练框架不需要理解”什么是 agent”，只需要知道”给我一个 prompt，我调你的函数，你返回 trajectory + reward”。Agent 的复杂性被封在 user function 里。

问题四：TITO（Token-In-Token-Out）与 token 级 logprob 保真

这是最容易被忽略、但会直接破坏训练的问题。

Agent 框架的典型流程：

1 2	prompt → 模型生成 a_1 → 环境中执行 → 得到 o_1 → 拼成新 prompt: [prompt, a_1, o_1] → 再生成 a_2 → ...

问题在于：拼接后重新 tokenize，a_1 的 token 边界可能改变（因为 BPE 是上下文相关的）。后果是：

训练时算出的 log π(a_1 | prompt) 与 rollout 时的不一致；
importance ratio 偏离 1，clip 频繁触发；
模型在优化一个它实际上没有生成过的 token 序列。

解法：TITO —— 全程保留 token id 而不重新编码，只对新生成的部分做 tokenize，并用 loss mask 标记”哪些 token 是模型生成的”（工具返回的部分 mask 掉，不参与 loss）。

Slime 生态里的 Miles、Dressage 都明确实现了 TITO 和 segment-aware training。这是 Agentic RL 必须做对的一件事，做错了训练会莫名其妙不收敛。

5.4 生态：Slime 作为”RL 底座”

Slime 的 README 列出了一批基于它的独立系统，这个分布本身说明了它的定位（一个可复用的 RL 内核，而不是一个端到端产品）：

项目	侧重
vime	vLLM 原生（rollout 后端换成 vLLM + vllm-router，其余保持）
Miles	企业级（LoRA、TITO、低精度训练、运维工具）
Relax	全模态（text/vision/audio）+ 完全异步，TransferQueue 解耦 Actor/Rollout/Reference
Dressage	黑盒 agent（OpenCode、OpenClaw）+ 任意沙箱（E2B、K8s）
ART	AWS Bedrock AgentCore 上的生产 agent RL
APRIL	部分 rollout 加速（over-provisioning 请求、管理部分完成）
RLVE	400 个可验证环境联合训练，难度自适应

README 自述 Slime 是 GLM-5.x / GLM-4.5–4.7 系列的 RL 框架（截至 2026-11 抓取）。这类”官方背书”是可信度信号，但具体版本迭代请以仓库为准。

5.5 选型建议

你的情况	建议
只有单机 8 卡，做算法验证	TRL / OpenRLHF（生态成熟、上手快）
多机，需要 Megatron 的并行能力	Slime / verl
rollout 想用 vLLM 生态	vime（Slime 系）或 verl
大量黑盒 agent（不改内部逻辑）	Dressage（Slime 系）
需要完全异步 + 长尾	Slime 的 fully_async / Relax
要接企业级 K8s 与多租户	Miles / OCE 类方案

一条经验：先测”rollout 时间 / 训练时间”的比值。如果 < 1，说明瓶颈在训练，异步收益有限；如果 > 3（Agent 任务常见），必须上异步，否则 GPU 利用率会惨不忍睹。

6. Agentic RL：和单步偏好 RL 的本质区别

6.1 六个结构性差异

维度	单步偏好 RL（RLHF/RLVR on CoT）	Agentic RL
决策单元	1（整段回复）	10–200（工具调用轮次）
状态	静态 prompt	动态环境状态（部分可观测）
奖励	1 个标量	通常 1 个标量（终态），但跨几十步
转移	无	`s_{t+1} ~ P(· \| s_t, a_t)`，不可微、非平稳
方差来源	采样随机性	采样 + 环境随机性（双重）
rollout 成本	1 次生成	N 次生成 + N 次工具调用 + 沙箱
信用分配	不需要（整段共享）	核心难题

6.2 信用分配：Agentic RL 的核心难题

一条 50 步的轨迹，终态奖励 r=1。哪一步的贡献最大？

四个主流思路：

思路	机制	优点	缺点
轨迹级广播（GRPO 默认）	整条轨迹所有 token 共享同一个 `Â`	简单、无偏	方差极大；把”运气”当”能力”
轮次级奖励（turn-level）	每轮给一个分（PRM 或启发式）	信号密	PRM 本身有偏；成本高
Token 级奖励	每个 token 一个分	信号最密	极难获得可靠信号
反事实/留一法	去掉某一步重跑，看奖励变化	理论上最准	成本 × 步数，不可行

**当前最务实的是”轨迹级广播 + 关键步掩码”**：

整条轨迹一个优势（避免引入 PRM 偏差）；
但用 loss mask 只对”关键决策点”回传梯度（比如只对工具调用参数、不对格式 token）；
这样既保持了无偏，又降低了噪声。

6.3 一个残酷的现实：Agentic RL 的有效信号很少

设一条轨迹 50 步，每步平均 200 token，就是 1 万 token。如果用一个终态标量做优势，那么每个 token 得到的信号量是 1/10000。

对比 RLVR 的数学题（一条 CoT 2000 token）：信号密度高 5 倍。

这解释了两个现象：

Agentic RL 需要更多的 rollout（同样信息量，样本数要 ×5）；
Agentic RL 的提升更慢、更不稳——这不是实现问题，是信息论层面的限制。

6.4 环境非平稳带来的方差

设某个工具的成功率 95%。一条 20 次调用的轨迹，全部成功的概率是 0.95^20 ≈ 36%。

也就是说：即使策略完美，64% 的轨迹会因为工具随机失败而拿不到奖励。

后果：

G=8 的组里，全是”失败”，std=0，零梯度；
模型可能学到”失败的轨迹不好”——但它学不到是”哪一步的错”，因为错的可能是工具而不是策略。

三条应对：

环境确定性化：mock 掉不稳定工具，或用重试+缓存让工具行为可复现；
**区分”策略失败”和”环境失败”**：在 verifier 里加标记，环境失败的样本只做负样本（降低权重）或直接丢弃；
增大 G：用统计手段把信号从噪声里分出来，代价是成本。

6.5 六个落地难点（按踩坑频率排序）

难点一：训练-推理一致性
Agent 框架（自己写的 loop）与训练框架（Megatron）对同一段文本的 tokenization 不一致 → logprob 不匹配。必须 TITO + 显式记录 token 级 logprob 与 mask。

难点二：上下文长度爆炸
50 轮 × 每轮 500 token（含工具返回）= 2.5 万 token。加上 KV cache，batch=64 时显存会先于计算成为瓶颈。应对：截断策略（丢最早的轮次）、工具返回摘要、prefix caching。

难点三：奖励稀疏 + 全 0 组
成功率 < 10% 的任务，GRPO 基本训不动。必须先做 SFT 冷启动（把成功率拉到 20–30%），再上 RL。跳过 SFT 直接 RL 是新手最常犯的错。

难点四：环境不可复现
同一个 seed 跑两次，工具返回不同 → 训练不可复现 → 无法 debug。应对：录制-回放（record & replay）、确定性 mock。

难点五：多轮 rollout 的中间状态丢失
Agent 在第 30 步崩了，你想知道是第几步开始错的。如果没有完整的 trace（每步的 prompt、action、observation、logprob），只能重跑。

难点六：评测集污染
Agent 任务的”测试集”往往是真实网站/API。跑几次之后：

网站记住了你的 IP，返回不同内容；
任务的初始状态被前一次运行改变了（比如文件已被创建）。

必须有”环境重置”机制（容器快照、数据库回滚），否则评测不可比。

6.6 一个参考训练配方

阶段 0：环境准备
  - 工具成功率 > 95%，加超时和重试
  - 容器化 + 快照回滚，保证可复现

阶段 1：SFT 冷启动（1–3k 条专家轨迹）
  - 目标：把单次成功率拉到 20–40%
  - 数据：人工 / 强模型 / 规则生成，覆盖主要失败模式

阶段 2：RLVR + GRPO（G=8–16）
  - 奖励：终态 verifier（0/1）+ 必要格式检查（作为闸门而非加分）
  - 动态采样：过滤全对/全错组
  - clip-higher（上界 0.28）+ 无 KL 或弱 KL
  - 完全异步 rollout（若 rollout/train > 3）

阶段 3：课程学习 + 难度自适应
  - 按当前成功率动态选任务（0.2–0.8 成功率带）
  - 对长尾任务单独加采样权重

阶段 4：稳定性收尾
  - 监控 pass@1 / pass@k / 熵，防熵坍缩
  - 分布外评测集验证泛化

7. 对比：PPO / GRPO / RLVR / Agentic RL

7.1 算法层对比

维度	PPO（带 critic）	GRPO	RLVR（可叠加任意算法）	Agentic RL（范式）
算法本质	Actor-Critic + clip	无 critic，组内基线 + clip	奖励定义（不是算法）	问题设定（不是算法）
是否需要 value net	是（同规模）	否	取决于底层算法	通常否（critic 训不动）
显存（7B 为例）	~21B（policy+critic+ref）	~14B（policy+ref）	同底层算法	~14B + 环境
优势估计	GAE + `V(s)`	组内标准化	同底层算法	组内 + 轮次掩码
奖励要求	稠密/连续最佳	0/1 即可	必须可程序验证	终态可验证
典型 G / batch	—	G=8–64	G=8–16	G=8–32（需更大）
训练步数	1	1	1	10–200
主要失效	critic 不准、显存翻倍	零方差组、熵坍缩	奖励黑客、假性提升	信用分配、方差爆炸
成熟度	高（但 Agent 上不好用）	高	高	中（工程未标准化）

7.2 场景选择

场景	推荐方案	理由
数学/代码推理	RLVR + GRPO（DAPO 变体）	答案可验证；单步；已有大量成功案例
格式化输出 / 工具调用规范	RLVR + GRPO，奖励=格式闸门	规则可验证；不需要长 horizon
多轮工具调用 Agent	RLVR + GRPO + 异步 + SFT 冷启动	终态可验证；但必须解决稀疏与长尾
开放式对话（有用性/风格）	RLHF + PPO/DPO	没有 verifier，只能靠偏好（但 Agent 长轨迹上不可行）
主观质量 + 可验证混合	两阶段：先 RLVR 训能力，再 RLHF 调风格	分开做，避免奖励尺度打架
超长任务（>100 步）	分层 RL / 子目标分解 + 轮次级奖励	轨迹级广播信号密度太低
没有 verifier 的任务	不要用 RL，用 SFT / DPO / best-of-N	强行用 LLM-judge 是换个壳的 RM

7.3 一个容易混淆的点：RLVR 是”奖励”，不是”算法”

RLVR 和 GRPO 不是并列关系：

1 2	RLVR 定义奖励 → GRPO/PPO 优化策略（what）（how）

所以”用 RLVR 还是用 GRPO”这个问法本身不成立。正确的问题是：

奖励怎么定义（RLVR / RM / 混合）；
用什么算法优化（GRPO / PPO / DAPO / 其他）；
用什么基础设施跑（Slime / verl / TRL）；
问题怎么建模（单步 / 多轮 / 分层）。

这四层是独立的，可以自由组合。 混为一谈是当前讨论里最常见的概念混乱。

8. 瓶颈与前沿

8.1 五个真瓶颈

瓶颈一：信用分配没有好解法

轨迹级广播是”无偏但高方差”，PRM 是”低方差但有偏”，反事实是”准确但不可行”。目前没有既准又便宜的方法。 这是 Agentic RL 最根本的理论缺口。

瓶颈二：环境是最大成本项，不是模型

做 Agentic RL，80% 的工程量在环境：沙箱、快照、工具 mock、故障注入、状态重置。模型和数据反而简单。 这也是为什么只有少数团队能做大规摸 Agentic RL——不是算力问题，是环境工程问题。

瓶颈三：评测不可比

Agent 评测的方差极大（同一策略两次评测差 10–20 个点很常见）。原因：环境非平稳、任务难度分布不均、样本量小。没有可靠的评测，就无法判断”改进”是不是噪声。

瓶颈四：能力天花板来自基座，不是 RL

Spurious Rewards 已经说明：RLVR 的收益很大一部分是”激发”而非”学习”。Agentic RL 更甚——RL 能让模型更稳定地用已有能力，但很难教会它全新的能力。这与”RL 能突破能力上限”的叙事不符。

瓶颈五：多模态与长上下文

真 Agent 要看屏幕、读文档、操作 GUI。视觉 token 让上下文爆炸更快（一张图 1000+ token），而长上下文的 RL 训练成本是超线性的。

8.2 五个值得关注的方向

方向一：更细粒度的奖励信号

Turn-level credit（如 TRACE：用信用估计做轮次级奖励分配）；
Token 级奖励（如 ADRS：宣称在 3B 模型上做到 94.5% 成功率，据 2026-09 报道）；
Hindsight 重标注：从后验的成功/失败反推中间步骤的对错（类似 HER）。

方向二：无环境的 RL（offline / sim-based）

用世界模型或历史轨迹做”虚拟环境”，避免真实工具调用。风险是 sim2real gap。

方向三：异步 + 容错的极致化

部分 rollout（APRIL）：不等整条轨迹完成就开始训练；
staleness-aware 优化：显式建模”样本有多旧”，用加权而非丢弃；
断点续训：Agent 任务跑几小时，故障是常态。

方向四：多智能体 RL 与自博弈

单 agent 的能力受限于其探索能力。多 agent（自博弈、竞争、协作）可以提供更丰富的学习信号，尤其在无 verifier 的任务上（用对手/队友当 verifier）。Slime 的 README 提到 qqr 用 ArenaRL（锦标赛式相对排名）解决”判别性坍缩”，这是一个值得关注的方向。

方向五：从”训练策略”转向”训练 harness”

一个正在浮现的观点：Agent 的能力瓶颈不在模型参数，而在 harness（工具设计、上下文组织、错误恢复）。所以 RL 的对象可能从”模型权重”扩展到”harness 的可学习部分”（提示、工具选择策略、检索策略）。

这个方向的工程含义很大：如果 harness 的改进比模型微调收益更高，那 RL 的 ROI 就该重新算。

9. 小结

Agent 的 RL 是 POMDP，不是 bandit。 动作是文本、环境不可微且非平稳、奖励极稀疏、horizon 长——四个性质共同决定了”直接套 RLHF 会失败”。
先分清”策略”和”环境”。 规划、执行器、反思是可训练的；记忆和工具是环境。工具成功率不达标时做 RL，是在训练模型规避你的工程缺陷。
PPO 在长 Agent 任务上有五个失效点：critic 训不出来（状态太长、回报太吵）、显存翻倍、GAE 没有中间奖励可用、奖励尺度混叠、训练-推理 logprob 漂移被长序列放大。
GRPO 的核心是”用组内相对排名替代价值估计”。 它把 RLHF 的”人类比较”换成了”程序比较”，这是它和 RLVR 天然契合的原因。省掉 critic 是结果，不是目的。
GRPO 的五个坑：全对/全错组零梯度（→ DAPO 动态采样）、长度偏置（→ Dr. GRPO 去掉 1/|o| 和 std）、熵坍缩（→ clip-higher）、KL 阻碍探索（→ 去掉或弱化）、组内样本受环境噪声污染（→ 增大 G）。
RLVR 是”奖励定义”，不是算法。 它可以和 GRPO/PPO/DAPO 任意组合。”用 RLVR 还是 GRPO”是个错误的问法。
RLVR 的收益有一部分是”激发”而非”学习”。 Spurious Rewards 的实验（随机奖励也能涨点）要求我们必须同时看 pass@1 和 pass@k，并有分布外评测。别把奖励曲线当能力曲线。
奖励设计的核心原则是”必要条件而非加权和”。 r = 1 if (format_ok and correct) else 0 比 0.1·format + 1.0·correct 更难训，但不会陷入”先学格式后卡住”的局部最优。
Slime 这类框架解决的是四件事：训推一致（delta weight sync）、长尾 rollout（fully async + staleness 控制）、工作流解耦（custom-generate-function-path）、token 保真（TITO）。其中 TITO 最容易被忽略，做错了训练会莫名不收敛。
Agentic RL 的有效信号密度比 RLVR 低约一个量级。 1 万 token 共享一个标量，这是信息论层面的限制，不是实现问题。所以它需要更多 rollout、更慢的收敛、更强的工程。
必须 SFT 冷启动。 成功率 < 10% 的任务上直接 RL，组内全是 0，没有梯度。先把成功率拉到 20–40%，再上 RL。
Agentic RL 的瓶颈主要在环境工程和评测，不在算法。 80% 的工程量在沙箱、快照、工具 mock、状态重置。这也是为什么大团队和小团队在这个方向上差距拉得特别开。

如果只留一句：Agent 的 RL，算法已经足够（GRPO + RLVR 就是当前的最优组合），真正的护城河是环境工程——能不能低成本、可复现、大规模地让 Agent 在真实世界里失败。

参考来源

算法

Shao et al., DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models, 2024（GRPO 原始提出；组内标准化 + KL 惩罚）
DeepSeek-AI, DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning, 2025（GRPO + 规则奖励的大规模实践）
Yu et al., DAPO: An Open-Source LLM Reinforcement Learning System at Scale, 2025（clip-higher、动态采样、token 级 loss、去掉 KL）
Liu et al., Understanding R1-Zero-Like Training: A Critical Perspective, 2025（Dr. GRPO：去掉长度与 std 归一化）
Zheng et al., GSPO: Group Sequence Policy Optimization, 2025（序列级重要性比）
Schulman et al., Proximal Policy Optimization Algorithms, 2017（PPO 原始）
Rafailov et al., DPO: Direct Preference Optimization, 2023
Lambert et al., Tülu 3: Pushing Frontiers in Open Language Model Post-Training, 2024（RLVR 的系统化实践）

RLVR 与奖励

Spurious Rewards: Rethinking Training Signals in RLVR, arXiv:2506.10947（随机奖励也能提升的实证）
RLBFF: Binary Flexible Feedback to bridge between Human Feedback & Verifiable Rewards, arXiv:2509.21319
Lightman et al., Let’s Verify Step by Step, 2023（PRM）

Agentic RL

Jin et al., AgentGym-RL: Training LLM Agents for Long-Horizon Decision Making through Multi-Turn Reinforcement Learning, 2025
SkyRL-Agent: Efficient RL Training for Multi-turn LLM Agent, arXiv:2511.16108
TRACE: Turn-level Reward Assignment via Credit Estimation for Long-Horizon Agents, 2026
RAGEN / Agent-R1 系列（多轮 agent RL 的开源实践）

基础设施

Slime 官方仓库与 README：https://github.com/THUDM/slime（Megatron + SGLang + Data Buffer 架构、fully_async、delta weight sync、TITO 相关生态；抓取时间 2026-11-11）
slime: An SGLang-Native Post-Training Framework for RL Scaling（官方博客）
Agent-Oriented Design: An Asynchronous and Decoupled Framework for Agentic RL（官方博客）
APRIL: Accelerating RL Training with Active Partial Rollouts（部分 rollout 加速）
Laminar: A Scalable Asynchronous RL Post-Training Framework, arXiv:2510.12633
OpenRLHF / verl / TRL 开源框架文档

说明：文中引用 Slime README 的”GLM-5.x 系列 RL 框架”为官方自述（抓取于 2026-11-11），具体版本迭代请以仓库最新状态为准。所有具体数值（如 94.5% 成功率、随机奖励实验结论）均标注了来源性质（论文自报 / 二手报道），不同模型与复现条件下会显著偏差。