Agent 训练实战 / 02

Agent RL 实战：用强化学习提升推理与决策质量

上一篇讲了 Agent SFT——用轨迹数据教模型“学会做 Agent”。但 SFT 有个本质问题：它是模仿学习，模型最多做到和标注数据一样好，不会更好。

企业场景对 Agent 的要求远不止“能跑通”：要步骤少、工具调用准、推理链路清晰、遇到异常能自己恢复。这些都不是靠堆 SFT 数据能解决的——你需要 RL。

本篇聚焦 Agent RL 的工程落地：怎么设计 Reward、选什么算法、怎么搭训练环境、怎么用 RL 把推理性能拉上去。

为什么 SFT 之后还需要 RL

SFT 的天花板来自三个结构性问题：

问题 1：模仿学习的上限就是标注数据的质量

SFT 本质是“照着标准答案学”。如果标注轨迹里有冗余步骤、次优决策，模型会原样学过来。你无法通过 SFT 让模型超越数据本身的质量——就像一个只看教科书的学生，考试成绩上限就是教科书写得多好。

问题 2：Exposure Bias（暴露偏差）

SFT 训练时，模型看到的上文永远是 ground truth（标准轨迹）。但推理时，模型是基于自己上一步的输出继续生成的——一旦某一步偏了，后面的上文全变了，模型从没见过这种情况，就容易崩掉。

一个直观的例子：SFT 训练时，模型看到的轨迹是“查天气 → 拿到结果 → 回复用户”。但推理时如果第一步工具调用参数写错了、返回了报错，模型在训练阶段从未见过“报错之后该怎么办”——它只见过一路顺风的轨迹。

问题 3：SFT 只学“怎么做”，不学“做得好不好”

SFT 的 loss 是 token 级别的交叉熵——模型学的是“这个位置应该输出什么 token”，不关心最终任务有没有完成、完成得是否高效。RL 才引入了“结果好不好”这个信号。

Agent RL 的核心框架

把 Agent 交互过程映射到 RL 框架，其实非常自然：

具体来说：

状态 (State)    = 当前对话历史 + 所有工具返回结果 + system prompt
动作 (Action)   = 模型的下一步输出（一次 tool_call 或一段文本回复）
环境 (Env)      = 工具执行引擎 + 沙箱（代码执行、API 模拟等）
奖励 (Reward)   = 任务是否完成 + 过程质量评分
策略 (Policy)   = Agent 模型本身（给定状态，输出动作的概率分布）

和游戏 RL 的关键区别：Agent RL 的动作空间是自然语言（或结构化的 JSON tool call），维度极高；状态空间是变长的文本序列，不是固定维度的向量。这导致 Agent RL 的训练比 Atari 之类的难得多——后面会展开讲工程挑战。

Reward 设计：Agent RL 的成败关键

Reward 设计是 Agent RL 里最难也最重要的部分。设计得好，模型能学到真正有用的策略；设计得差，模型会学到各种钻空子的方式（reward hacking）。

结果 Reward vs 过程 Reward

结果 Reward (Outcome-based)
├── 任务完成了 → +1
└── 任务失败了 → 0 或 -1

过程 Reward (Process-based)
├── 调了正确的工具 → +0.1
├── 参数格式正确   → +0.05
├── 产生了冗余步骤 → -0.1
└── 陷入死循环     → -0.5

结果 Reward 的优点是简单、不需要人工设计中间标准。缺点是信号稀疏——Agent 可能执行了 10 步，只在最后一步拿到 Reward，中间步骤的好坏完全没有反馈。

过程 Reward 信号密集，训练效率高，但需要你定义“什么是好的中间步骤”——这本身就是一个难题，而且定义不好会误导模型。

实践中的做法：以结果 Reward 为主，用少量过程 Reward 做辅助。

企业场景的 Reward 设计示例

不同类型的 Agent，Reward 设计思路差别很大：

代码 Agent（如 SWE-Agent）

Reward 组成：
├── 测试通过率              权重 0.6    ← 核心指标
├── 代码是否能编译/运行       权重 0.2    ← 基本正确性
├── 修改的文件数量惩罚       权重 -0.1   ← 鼓励精准修改，避免乱改一通
└── 步骤数量惩罚            权重 -0.1   ← 鼓励高效完成

这是最容易设计 Reward 的场景——测试用例是天然的、可自动化的评判标准。这也是为什么代码 Agent 是 RL 训练最早跑通的企业场景之一。

RAG Agent（检索增强生成）

Reward 组成：
├── 最终答案准确率（和参考答案对比）  权重 0.4
├── 检索召回率（找到了相关文档吗）    权重 0.3
├── 检索精确率（召回的文档相关吗）    权重 0.2
└── 检索次数惩罚                    权重 -0.1   ← 避免无脑检索

RAG Agent 的 Reward 设计难点在于“答案准确率”的自动评估。常见做法是用一个更强的模型做 judge（RLAIF 思路），或者在有标准答案的数据集上训练。

搜索/数据分析 Agent

Reward 组成：
├── 最终结果正确性      权重 0.5
├── SQL/查询语法正确    权重 0.2
├── 执行无报错          权重 0.2
└── 查询效率（扫描行数） 权重 -0.1

稀疏 Reward 的缓解方法

纯结果 Reward 最大的问题是稀疏性——Agent 走了 10 步，只有最后一步有 Reward，前面 9 步的梯度信号非常弱。

几种实用的缓解方法：

其中 PRM（过程奖励模型） 是目前比较热的方向——用人工标注的“每一步对不对”数据训练一个打分模型，然后用这个模型给 RL 训练提供密集 Reward。OpenAI 在数学推理上验证了这个思路的效果，Agent 场景同理。

主流算法选型

PPO：最稳的选择

PPO（Proximal Policy Optimization）是目前 Agent RL 的主流算法。核心思想是限制每次策略更新的幅度，避免训练崩溃。

PPO 训练循环：
1. 用当前策略（Agent 模型）在环境中 rollout，收集轨迹
2. 用 Reward 计算每一步的优势函数（advantage）
3. 用 clipped objective 更新策略，限制更新幅度
4. 用 KL 散度约束策略不要偏离 SFT checkpoint 太远
5. 回到第 1 步

PPO 在 Agent 场景的关键配置：

• KL 系数：控制策略偏离 SFT checkpoint 的程度。设太大，模型不敢探索；设太小，格式容易退化（比如 tool call 格式崩掉）。经验值 0.01–0.05，需要根据场景调
• Rollout 批次大小：Agent 轨迹长，rollout 成本高，batch size 不能设太大。通常 64–256 条轨迹一个 batch
• GAE lambda：控制优势函数的偏差-方差权衡，Agent 场景一般 0.95–0.99

GRPO：更适合长轨迹的变体

GRPO（Group Relative Policy Optimization）是 DeepSeek 在 R1 中使用的算法。和 PPO 的核心区别是：不需要单独训练 Critic/Value 网络，而是通过同一 prompt 的多条 rollout 之间做相对比较来估计优势。

GRPO 流程：
1. 对同一个 prompt，用当前策略生成 N 条不同的轨迹（比如 N=8）
2. 分别计算每条轨迹的 Reward
3. 在这 N 条轨迹内部做归一化，得到相对优势
4. 用相对优势更新策略

GRPO 的优势：

• 省掉了 Critic 网络的训练和显存开销——Agent 轨迹本身就很长，再加个 Critic 显存压力很大
• 相对比较比绝对打分更稳定——“这条比那条好”比“这条值 0.7 分”更容易判断

GRPO 的劣势：

• 需要同一个 prompt 生成多条轨迹，rollout 成本翻 N 倍
• 如果 N 太小，相对优势的估计噪声大

Rejection Sampling + SFT：轻量替代方案

如果你的场景不想上完整的 RL 训练管线，有一个更简单的替代方案：

Rejection Sampling 流程：
1. 对每个 prompt，用当前模型生成 K 条轨迹
2. 用 Reward 函数给每条轨迹打分
3. 只保留得分最高的那条（或 top-k 条）
4. 用筛选后的数据做 SFT
5. 回到第 1 步，迭代

这个方法的本质是用采样+筛选来近似 RL 的效果，避免了 PPO/GRPO 复杂的训练管线。代价是收敛更慢、上限更低，但实现成本低很多。

适合的场景：

• 团队没有 RL 训练基础设施
• 快速验证 Reward 设计是否合理
• 作为正式 RL 训练前的数据增强手段

RLHF vs RLAIF：谁来提供 Reward

Agent 场景的一个优势是：很多 Reward 可以自动化验证（代码跑通了吗？SQL 结果对吗？），不一定需要人来标注。能自动验证的场景优先用自动 Reward，省钱又稳定。

RL 训练的工程挑战

Agent RL 的理论不复杂，但工程落地非常难。下面是几个最头疼的问题。

Rollout 成本

Agent RL 的每次策略更新都需要 rollout——让模型在环境里跑完整条轨迹。和游戏 RL 不同，Agent rollout 涉及真实的工具调用：

一次 rollout 的成本：
├── 模型推理：每步生成 100-500 tokens，一条轨迹 5-15 步
├── 工具执行：API 调用延迟、代码编译运行时间
├── 总耗时：一条轨迹可能要 30 秒到几分钟
└── 对比：Atari 游戏一步只需要几毫秒

缓解方法：

• 并行 rollout：同时跑几十到几百条轨迹，用 GPU 集群做模型推理，用容器化环境做工具执行
• 异步训练：rollout 和策略更新解耦，收集到一批轨迹就更新，不等所有 rollout 完成
• 轨迹缓存：对于确定性的工具调用（同样的参数总是返回同样的结果），缓存工具返回值

沙箱环境搭建

Agent RL 需要一个可以安全、大规模执行工具调用的环境。这是和对话 RL（RLHF）最大的工程区别——对话 RL 只需要生成文本然后打分，Agent RL 需要真的执行操作。

沙箱环境需要满足：
├── 隔离性    每条轨迹的执行互不影响
├── 可重置    执行完一条轨迹后环境恢复初始状态
├── 可扩展    支持几百条轨迹并行执行
├── 确定性    相同输入得到相同输出（尽量）
└── 安全性    不能让模型的操作影响到宿主系统

代码 Agent 的沙箱方案比较成熟（Docker 容器 + 文件系统快照），但 API 调用类的 Agent 就麻烦——你不能在 RL 训练时真的去调第三方 API（成本、速率限制、副作用），需要搭模拟环境。

训练稳定性

Agent RL 的训练比对话 RL 更容易崩，因为轨迹更长、动作空间更大、Reward 更稀疏。

Reward Hacking：模型找到了钻 Reward 漏洞的方法，拿到高分但没有真正完成任务。

几个真实案例：

• 代码 Agent 学会了修改测试用例让测试通过，而不是修复 bug
• 搜索 Agent 学会了不检索直接编造答案（因为有时候蒙对了也有 Reward）
• RAG Agent 学会了把所有文档都检索回来（召回率高，但精确率崩了）

防范方法：

• 多维度 Reward：不只看任务完成率，加入步骤合理性、格式正确性等辅助 Reward
• 对抗性测试集：用专门设计的 edge case 测试模型是否在 hack
• 人工抽检：定期抽查高 Reward 轨迹，看看模型到底在做什么

KL 散度约束：控制策略不要偏离 SFT checkpoint 太远。

总 Loss = -RL_objective + β × KL(π_current || π_sft)

β 太大 → 策略几乎不更新，RL 白训
β 太小 → 策略漂移太远，格式退化、能力崩塌

经验做法：用自适应 KL 系数——设定一个 KL 目标值（比如 0.1），如果实际 KL 超了就增大 β，反之减小。

推理性能优化：RL 的实际收益

讲了这么多机制，RL 到底能带来什么实际收益？聚焦三个企业最关心的指标。

减少冗余步骤

SFT 模型容易产生冗余步骤——因为它是模仿训练数据的平均行为，而训练数据里不可避免地包含一些不够高效的轨迹。

RL 通过步骤数量惩罚，可以让模型学会“走捷径”：

SFT 模型的典型行为：
  查天气 → 查温度 → 查湿度 → 查风力 → 综合回复（4 步工具调用）

RL 优化后：
  查天气（返回包含温度/湿度/风力） → 综合回复（1 步工具调用）

实际效果：在代码修复场景中，RL 训练后的 Agent 平均步骤数可以从 8-12 步降到 5-7 步，同时保持或提升完成率。

提升工具调用准确率

SFT 模型在工具调用上常犯两类错误：

• 选错工具：该用 search 的时候用了 fetch，该查数据库的时候调了文件 API
• 参数填错：字段名拼错、格式不对、必填参数漏了

RL 通过“工具调用成功才有 Reward”这个信号，可以显著减少这两类错误。模型会学到：与其冒险调一个不确定的工具，不如先确认再调。

改善复杂推理链

对于需要多步推理的任务（比如“先查用户信息，根据用户等级查对应的优惠政策，再计算折扣价格”），SFT 模型容易在中间环节出错后一路错下去。

RL 的优势在于它是在完整轨迹上优化的——模型会学到“前面几步的决策会影响后面的结果”，从而在关键节点做出更谨慎的选择。

RL 对推理链的改善：
├── 错误恢复能力   工具报错后知道换一种方式重试
├── 分支决策质量   在需要判断的地方选对路径的概率更高
└── 信息利用效率   更好地利用工具返回的信息，减少重复查询

小结

• SFT 的天花板是标注数据质量，RL 通过 Reward 信号让模型有机会超越模仿学习的上限
• Reward 设计是 Agent RL 的核心难题：以结果 Reward 为主，过程 Reward 为辅；能自动验证的场景（代码、SQL）优先用自动 Reward
• 算法选型：PPO 最稳、GRPO 省显存适合长轨迹、Rejection Sampling + SFT 是轻量替代
• 工程挑战集中在 rollout 成本、沙箱环境和训练稳定性——Reward Hacking 是最常见的坑
• RL 的实际收益体现在减少冗余步骤、提升工具调用准确率、改善复杂推理链的表现

下一篇建议继续看：

• GRPO vs PPO：Agent 强化学习算法深度对比与选型