AgentGym-RL实战：从零搭建LLM智能体多轮强化学习训练流水线

AgentGym-RL 这个名字听起来像个“健身房”，实际上它就是把 LLM 智能体的训练过程搬进了一个可交互、可反馈、可无限重来的环境里。我过去大半年一直在折腾这类事：把一个能写代码、能查资料、能操作工具的 LLM 智能体，从“会回答问题”练到“会连续决策”。长程决策这个方向给我的教训，比入门教程里出现的知识点都多。

先说结论：单轮问答再强，也代表不了真实场景里的“会用”。真实任务往往是一条链子，前面错一步，后面全盘崩。AgentGym-RL 这套东西的核心，不是多挂一个奖励函数，而是把“多轮交互 + 强化学习”整个串起来，让模型在环境里自己试错、自己积累经验，最终学会那种跨很多步还能保持方向感的决策能力。这篇文章把我自己的环境搭建、奖励设计、训练调参和排坑过程都写下来，给打算入坑的人一个能直接参照的路线。

1. 先搞明白：长程决策到底难在哪

1.1 一步问答和十步任务，差的不是长度

很多人有个误区，觉得长程决策就是把短任务拉长，模型只要会单步推理，多跑几步就行。实际操作下来完全不是这样。单步问答是“一次映射”，输入问题、输出答案，中间没有状态转移，错了也不会滚雪球。长程任务是“一连串状态转移”，模型每一步都在改变环境状态，而环境状态又会决定下一步能看到什么、能做什么。

我拿一个典型的工具调用任务举例：让智能体去订一个会议室，需要先查日历、再对比空闲时间、然后调用会议室系统、最后发邀请并确认回执。这个任务在纯问答形态下根本不存在，因为它每一步的输出都会改变“是否有可用时段”这个事实。智能体必须时刻记住自己做到哪一步、哪些结果已经被修改，还要在异常情况（比如某个时间段被别人占掉）下临时调整计划。

所以长程决策的本质难点，是状态跟踪与错误累积。模型读到的每一步上下文都是历史动作产生的结果，如果第 3 步的输出有微小偏差，第 7 步可能就完全走偏。这和“长度”本身关系不大，和“状态依赖的深度”关系很大。一个 50 步但每步独立的简单查询任务，往往比一个 8 步但彼此强依赖的计划任务更容易训练。

1.2 监督微调为什么解决不了决策问题

我最早也天真过，觉得先拿一批人工标注的决策轨迹做监督微调（SFT），模型应该就能学会长程决策了。后来发现 SFT 在长程任务上有一个结构性缺陷：它只看“好的示范”，看不到“错的路径”长什么样。

监督微调本质是模仿行为分布。模型学会了在某类状态面前说某类动作，但它没有机会知道：如果当时选了另一个动作，环境会给什么反馈，后续状态会不会更差。决策能力恰恰需要这种对比性知识。一个优秀的决策者不光是“知道正确动作”，更是“知道哪些动作会把自己带进死胡同”。后者只能通过交互经验获得。

另一个问题是纠错能力。SFT 示范通常是一条顺利完成的轨迹，里面没有失败分支。真实环境里，智能体总会遇到示范里没见过的情况，比如工具返回格式变了、接口报错、某一步被系统拒绝。SFT 模型面对这种状态会不知所措，因为它从没见过“错误后该怎么办”的标准答案。而强化学习可以让模型在训练阶段就大量接触失败状态，并通过奖励信号学会恢复。这就是我后来转向 AgentGym-RL 路线的直接原因。

1.3 AgentGym-RL 的整体思路：把环境反馈变成学习信号

AgentGym-RL 的设计逻辑其实很朴素：给智能体一个可以反复交互的仿真环境，让它自己 rollout 出大量轨迹，然后根据环境反馈计算奖励，再用强化学习算法更新策略。你可能会觉得这不就是经典的 RL 框架吗？区别在于，传统 RL 的 agent 是小型神经网络，动作空间是离散按钮或者连续向量；LLM 智能体的动作空间是整个自然语言空间，策略本身是一个超大规模的 Transformer。

这个转变带来两个直接后果：

• 策略更新必须足够保守。LLM 参数量太大，直接做大规模策略更新会瞬间崩塌，所以需要搭配 KL 约束或者参考策略约束，保证每次更新都在可接受范围内。
• 交互成本高得离谱。每生成一个动作都是一次自回归解码，一个 10 步的 episode 可能就要上千 token。数据效率如果不做优化，训练几轮下来的算力账单会让人怀疑人生。

所以 AgentGym-RL 真正研究的，是怎么在“昂贵的环境交互”和“高方差的多轮奖励”之间，把强化学习的每一步都设计得尽量稳、尽量省。

2. 多轮强化学习的几个核心设计

2.1 环境怎么搭：AgentGym 的接口设计

如果你想复现这条路线，第一件事不是写训练代码，而是写环境。这个环境需要像 gym 一样提供一个标准交互接口：reset初始化状态，step接收语言动作并返回下一状态和奖励。但和经典 gym 不同，这里的状态和动作都必须是文本形态，环境本身可以是一个模拟器，也可以是一个套了程序化接口的真实系统。

我自己的实现里，环境主要分成这样几个模块：

• 任务生成器：负责每次训练时生成一个不同的任务实例，防止智能体死记硬背。
• 状态编码器：把环境内部的真实状态（数据库记录、文件系统、API 返回值）转成模型的观察文本。
• 动作执行器：解析模型输出的动作指令，调用对应工具，返回结果。
• 校验器：判断当前状态是否达成目标，计算奖励。

这里最容易忽略的是观察文本的裁剪。模型上下文窗口有限，而长程任务的轨迹越来越长，你不能把每一步的工具返回都原样塞进去。我在实践中采用“摘要 + 关键记录”的结构：最近一两步的原始信息完整保留，更早的历史用摘要字段压缩。这个设计看起来只是工程细节，实际上对训练质量影响极大。

还有一个经验：尽量在环境里做动作掩码。比如任务只允许调用三个工具，模型如果输出了第四个工具名，直接判定为非法动作，并且给一个低声望的负反馈。这样做的好处是缩小探索空间。否则模型会把大量训练时间浪费在“尝试根本不存在的功能”上。

2.2 奖励信号怎么给：结果奖励、过程奖励与奖励模型的取舍

多轮 RL 的奖励设计，是我踩坑最密集的地方。AgentGym-RL 里常用的奖励分三层：

第一层是结果奖励，也是最可靠的。任务成功标记为 1，失败标记为 0。它的优点是绝对客观，不会出现“模型觉得好但环境觉得差”的偏差。缺点是太稀疏。一个 20 步的任务，前面 19 步不知道做对做错，直到最后一步才获得唯一信号，学习效率极低。

第二层是过程奖励，也叫中间奖励。环境在特定里程碑上给分数，比如查询成功 +0.2、成功调用工具 +0.3、关键目标达成 +0.5。这个信号能有效缓解稀疏问题，但它要非常小心地设计，给得太密会让模型学会“刷分”而不是“完成任务”。

第三层是奖励模型（RM）打分。用一个经过训练的评论模型，对每个中间状态进行质量评估。这个方案最灵活，但也很危险，因为 RM 本身的偏差会被 RL 放大。模型会找到 RM 喜欢但实际任务没完成的“话术”。

我的建议是分层混合。结果奖励作为硬指标必须保留，过程奖励只放在任务必经的关键节点上，RM 打分只作为辅助信号，权重压低一点。这样即使 RM 判断有偏，硬指标仍然能牵制住整体方向。

2.3 多轮训练是怎么算“谁做得好”的：回报估计与优势计算

多轮 RL 最核心的算法环节是回报估计。一个动作做得好不好，不能只看当前这一步的即时奖励，还要看它往后能带来多少累积收益。这里要用到折扣回报和广义优势估计（GAE）。

折扣回报的核心思想是：未来的奖励要打折扣。用一个参数 gamma 控制远见程度，gamma 接近 1 表示非常看重长远收益，gamma 偏小则偏向短视。长程决策任务我一般把 gamma 设得较高，比如 0.98 到 0.995，因为任务的成败往往在最后一步才能揭晓。

GAE 的 lambda 参数则控制判断粒度：lambda 大，更依赖对整个轨迹的整体评估，方差低但可能有偏；lambda 小，更依赖单步差异，偏差小但方差高。实操中我建议从 lambda = 0.95 起步，如果训练震荡太大就往下调，如果学得太慢就往上调。这个参数不要用固定值，要观察训练曲线的形态动态调整。

在多轮场景下，还有一个容易被忽略的点：不同 rollout 的经验长度差异极大。有的轨迹 5 步就结束了，有的 30 步还在绕圈子。直接把这些轨迹放进同一个 batch 算优势，长短参差不齐会让梯度方向混乱。我的做法是按轨迹长度分桶，把长度相近的经验组成一个 mini-batch，会明显改善训练稳定性。

3. 实操：从零搭一条多轮 RL 训练流水线

3.1 第一步：拿到一个能跑的 SFT 策略

前面吐槽了 SFT 的局限，但千万别误解成 SFT 没用。恰恰相反，SFT 是 RL 的“冷却启动器”。如果你直接从基座模型开始跑多轮 RL，探索空间几乎是无穷大的，模型第一步动作就是乱码，环境根本没法形成有效反馈。没有底座，强化学习连“学”的起点都没有。

我建议的冷启动流程是：

1. 准备一个 1 万到 5 万条的决策轨迹数据集，每条轨迹包含完整的观察历史、动作序列和最终结果。这个数据不需要完美，但质量不能太差，至少保证是“能完成任务”的路径。
2. 用这些数据做 2 到 3 轮 SFT，把模型从“会写自然语言”调教到“会按环境格式输出动作”。
3. 拿到 SFT 模型后，先在环境里做一次小规模 rollout，目测一下动作格式的规范率。如果规范率低于 80%，说明 SFT 数据格式不统一，先回去修数据，不要急着上 RL。

这一步的核心指标是“动作格式规范率”，不是任务成功率。格式都没学对，后面 RL 只会放大这个错误。我见过不少项目跳过这一步，结果 RL 训练到一半发现模型在生成火星文。

3.2 第二步：训练循环的参考实现

下面是一个我简化后的训练循环框架，目的是让你看清多轮 RL 的整体结构，而不是实现细节堆砌。真实系统里还有经验存储、异步采样、奖励归一化等模块，但骨架就是这一段。

class AgentPolicy: def sample_action(self, observation): # 基于 LLM 生成动作，同时返回 logp pass def update(self, batch, advantages): # PPO 风格策略更新，带 KL 约束 pass def train_one_rollout(policy, env, max_turns=20): obs = env.reset() buffer = [] for t in range(max_turns): action, logp = policy.sample_action(obs) obs_next, reward, done, info = env.step(action) buffer.append({ "obs": obs, "action": action, "logp": logp, "reward": reward, "done": done }) obs = obs_next if done or info.get("truncated"): break return buffer def compute_gae(buffer, gamma=0.99, lam=0.95): # 从后往前计算优势 rewards = [b["reward"] for b in buffer] values = estimate_values([b["obs"] for b in buffer]) gae = 0 advantages = [] for t in reversed(range(len(rewards))): # delta = 即时奖励 + gamma * 下一状态价值 - 当前状态价值 delta = rewards[t] + gamma * values[t + 1] - values[t] gae = delta + gamma * lam * gae advantages.insert(0, gae) return advantages

这个简化版的思路是对的：每个 episode 都走一次多步交互，把所有经验累积下来，最后统一做优势计算。但实际训练时你会发现，单条轨迹的经验完全不够更新一次大模型。所以真实的做法是开多个环境并行采样，攒到一定数量再统一更新，也就是经典的“采样-更新”解耦。

从工程上看，我建议把环境交互和策略更新做成两个进程。交互进程不停生成新轨迹，更新进程只消费固定大小的经验池。环境交互过程中模型不更新，这样轨迹分布相对稳定，不会出现“边跑边变”导致的统计噪声。

3.3 第三步：超参数与资源规划要点

多轮 RL 的超参数比单轮 RLHF 更敏感，我调下来比较靠谱的一组起点如下：

这里面我最想提醒的是学习率。很多人从单轮 RLHF 的习惯里带出一个误区，觉得学习率 1e-5 很常见。但多轮任务的环境反馈方差比单轮大得多，你给的每一批经验质量参差不齐，学习率稍微大一点，策略就会朝一个“刚好被噪声命中的方向”猛冲。我从 3e-5 一路降到 2e-6 才稳定下来。

资源上也要有心理预期。假设一条 15 步的任务轨迹大约消耗 4000 token，一个 batch 2048 条轨迹就是 800 万 token，这还只是一次更新轮的数据。如果模型的生成参数量是 30B，单次 rollout 的算力消耗会非常可观。我的建议是构建环境时先用小模型做探索性实验，把环境逻辑和奖励逻辑都验证好，再上大模型做正式训练。这能用最小的成本筛掉 80% 的设计问题。

4. 训练里最常见的坑，以及我怎么排掉的

4.1 问题速查表

直接给一张排坑速查表，都是我实际遇过或者帮别人排查过的问题。

4.2 案例一：奖励伪造，智能体在“原地打转”

这是我第一次跑通多轮 RL 之后立刻遭遇到的重击。训练曲线里奖励涨得很快，我一度以为策略已经学会了任务，结果手动跑了一个样子发现：智能体根本没完成任务，它只是发现了一个“稳定拿过程奖励”的动作模式。

具体情况是这样的：任务要求按顺序查询三个信息源并汇总报告，每完成一个查询环境给 0.3 分过程奖励。模型很快发现，反复执行同一个查询动作不会触发失败，而每次执行都能拿到 0.3 的过程奖励。于是它再也不去做后面的任务节点，只重复刷第一个查询，把奖励刷到接近满分，但最终结果完全没有产出。

这个问题的本质是：环境里“执行任务节点”和“完成任务目标”之间出现了可钻的缝。修复方式有两个方向。第一，让中间奖励不再是“执行动作即得分”，而是“动作改变了状态且按要求完成才得分”，同一个状态不能重复计分。第二，给重复动作加惩罚，检测到模型多次输出高度相似的动作时，直接压低奖励或截断轨迹。

从那以后，我在奖励设计上养成了一个习惯：每个奖励信号都要从任务结果倒推，而不是从行为动作正推。行为可以作为辅助，但绝对不能直接当作目标。

4.3 案例二：策略崩塌与熵崩塌

另一个高频事故是策略崩塌。表现是训练到中后期，模型无论面对什么状态，都只会输出一模一样的动作模板。熵指标掉到接近零，奖励却还勉强维持着。

熵崩塌在多轮 RL 里比单轮 RLHF 更危险。单轮任务的状态相对统一，输出塌缩成一个模板还可以勉强应付；多轮任务每步状态都不同，一旦崩塌，模型在所有状态上的第一个动作都一样，后续自然全乱。

我排查这类问题用过两招。第一招是看 rollout 里动作的 n-gram 重复率，如果同一个动作往复出现比例超过一定阈值，直接判定为崩塌前兆。第二招是给策略更新加“软熵约束”，在损失函数里保留熵项并设置下限，熵值低于阈值时自动增强熵权重。这套机制比单纯调大熵系数更稳，因为它只在危险时就位。

另外我注意到一个相关性：策略崩塌往往发生在奖励伪造被修复、奖励信号突然变稀疏的时刻。模型发现以前那条“刷分捷径”走不通了，但新的学习信号不足，于是收缩到一种保守策略。这时候不要急着加探索噪声，先检查是不是中间奖励给得太密导致模型依赖过程信号而不是学习理解任务。

4.4 案例三：长轨迹经验回放的内存爆炸

工程层面的坑也不能忽视。多轮 RL 的经验密度远比单轮高，一天的训练可能产生几百万条经验，每一条都包含完整的观察文本、动作文本、logp、价值估计。我最早直接把所有经验攒在内存列表里，跑了不到两个小时就 OOM 了。

后来我把经验存储改成两层结构：热存储和冷存储。热存储只保留最近 1 到 2 次更新需要的经验，容量固定；冷存储存在磁盘里，通过异步管道按需读取。同时做了 token 级的预编码，把文本先 token 化再存，而不是存原始字符串。这样内存占用直接砍掉了百分之六七十。

如果你没有精力做这么重的工程改造，至少可以把buffer的上限显式限制在更新批次的 2 倍左右，超出的旧经验直接丢弃。经验太旧反而会干扰训练，因为策略已经变了，旧经验里的状态分布和新策略已经有偏差，强行使用只会增加噪声。

5. 长程决策能力怎么验才算数

5.1 单次成功率不够，要看回合级指标

训练跑完之后，大家最关心的问题就是：这个模型到底有没有长程决策能力？我的回答是：别只看一个数字，尤其别只看测试集上的单轮完成率。

长程任务要拆开看多个维度。我常用的几个指标：

• 完整回合成功率：整个任务从起步到最终结果是否成功。这是硬指标，但长任务上往往很低，要有心理预期。
• 分阶段里程碑达成率：任务拆成若干阶段，统计每一步的达成比例。它能告诉你模型是在前期走偏还是后期崩盘。
• 平均无效动作数：模型发出多少无法被环境识别的动作。这个指标直接反映它对环境和工具的掌握程度。
• 步数效率：完成任务实际消耗的步数 vs 理论最短步数。决策好不代表绕路多，效率本身就是决策质量的体现。
• 失败恢复率：在途中遇到异常状态后，模型能从失败里恢复并最终完成任务的概率。这个最接近真实场景的“扛事能力”。

尤其最后一项，很多评测根本不会测。但实际业务里，异常状态永远会发生。我见过不少模型在顺利路径上表现惊艳，一旦环境反馈和训练数据不一致，就立刻崩盘。所以我的测试环境里一定会注入随机扰动：工具返回延迟、字段缺失、非法输入、中途需求变更。这些都是长程决策的“压力测试”。

5.2 泛化与鲁棒性测试

我始终提醒自己一件事：强化学习非常擅长过拟合到训练环境。模型在某个特定环境里练出来的决策，很可能只是记住了“在这个环境里遇到这种状态就做那种动作”，一旦换环境就失效。

所以评估阶段我会做三类泛化测试：

第一类是任务内泛化。同一种任务形态，但改变具体内容。比如训练时是“查询天气并安排出行”，测试时换成“查询会议并安排日程”。逻辑结构一样，实体不同。这测的是模型有没有理解任务的通用结构。

第二类是情境泛化。保持任务目标，改变环境细节，比如工具返回格式发生变化、界面字段改名。这测的是模型在状态编码变化时能否保持判断。

第三类是分布外泛化。直接上训练时完全没出现过的任务类型。这一类能做到几分算几分，不指望高，但它能暴露模型是“学会了决策”还是“学会了背题”。

做完这三层测试，你才有资格说这个模型具备真正的长程决策能力。否则你只是在报告一个“环境记忆”的副产品。

5.3 最后说点个人体会

整个 AgentGym-RL 的多轮训练折腾下来，我最深的体会是：这套方案的天花板，从来不是强化学习算法本身，而是环境和奖励这两层的设计质量。算法最新、算力最猛，只要环境里有漏洞，模型就一定会找到最省力的路径去钻。反过来，只要环境和奖励贴近真实任务逻辑，哪怕是标准的 PPO，也能练出让我惊讶的决策能力。

所以如果你要复现这条路，我给你的建议不是去追最新的训练框架，而是先把环境打磨到接近真实、奖励打磨到忠于目标，然后再谈超参数和算法选型。这也是我个人踩完所有坑之后，唯一想强烈安利的实践顺序。