智能体强化学习：框架与最佳实践

最近关于大型语言模型（LLM）的研究一直高度关注推理和强化学习（RL）。该领域的大部分早期工作考虑的是静态任务，即 LLM 针对一个提示生成单个响应。

然而，这种单轮任务现在已不太具有代表性，因为 AI 系统已变得越来越具代理性（agentic）。这些系统需要在长时间跨度上进行推理、调用工具、与用户交互，并能灵活适应反馈。这种向自主功能的转变使 RL 训练变得更加复杂，需要多轮轨迹、可扩展的 rollout 基础设施、模块化环境，以及在多轮任务上稳定学习的技术。

在这篇综述中，我们将研究近期关于 LLM 代理 RL 训练的工作，并为构建功能完善、性能优越的智能体强化学习系统总结实用的设计原则。

1、智能体与强化学习基础

本综述的大部分内容将研究近期关于使用 RL 训练代理的实用技术和框架的工作。然而，为了理解这些研究，我们首先需要建立对智能体和 RL 的基础理解。代理不仅仅是 LLM，但我们不必过度复杂化代理的定义。在最简单层面上，代理只是一个在智能体循环中运行的 LLM，利用工具和自身的推理能力来解决复杂问题。在本节中，我们将详细介绍代理的关键组件，并提供一个结构化框架来理解智能体强化学习。

1.1 代理的关键组件

智能体循环

上图提供了代理系统的高层示意。如图所示，代理有许多组件，例如：

LLM 主干。
指令。
工具。
环境。

给定初始指令和规范，这些组件在智能体循环中运行。LLM 主干生成输出、执行工具调用、从环境摄取反馈，然后重复。在每一步，都会检查终止条件以确定循环是否应该继续，或者问题是否已解决。这些组件构成一个代理框架（agent harness），控制 LLM 的编排和集成细节。我们现在将详细介绍每个组件。

代理系统中的LLM 主干只是一个标准 LLM，它经过训练以在代理上下文中运行。具体来说，LLM 必须能够在所提供的框架内良好工作，这需要高级的指令跟随、工具调用和推理能力。虽然任何 LLM 都可以用作代理主干，但我们通常从使用推理模型中受益；见下文。

推理模型在最终输出之前产生思考轨迹

为了解决多步任务，代理必须能够将困难的问题分解为更小、更简单的部分，并解决每个部分——可能借助工具——以得出最终解决方案。此外，模型必须能够在解决问题时自我反思并从自身错误中恢复。以这种方式处理长时程问题需要高水平的推理能力和可靠性。

"代理往往试图一次性做太多——本质上是试图一次性完成整个应用……[为了解决这个问题]，我们……让代理一步一步、一个功能一个功能地工作……[然后]我们提示每个代理朝着目标取得渐进式进展，同时在会话结束时将环境保持在干净状态。" - 来自 [9]

指令为代理提供解决问题所需的信息，以及帮助代理正确处理问题的上下文。我们应该向代理提供相关的领域信息——通常取自现有指南或政策文档。此外，我们可以提供关于任务或解决问题策略的指导，例如要求代理将问题分解为更小的步骤、维护已完成子任务的待办事项列表、在解决方案中遵循特定风格，甚至在解决问题过程中仔细检查每个步骤。代理指令应在简洁性和具体性之间取得平衡。我们希望指令足够详细以可靠地指导代理行为，但又不能过于详细以至于变得脆弱且难以维护。

工具和环境。 为了与外部环境交互，LLM 需要能够使用 API、CLI 或 MCP 服务器等工具。例如，如果我们希望代理为我们预订当地餐厅的餐桌，我们可以简单地教模型如何构造对 OpenTable API 的调用。工具调用可以直接在 LLM 的 token 流中表示，通过创建一组特殊的工具调用 token 并教 LLM 如何使用这些 token；见下文。

例如，Qwen3 模型通过 XML 风格的分隔符处理工具调用：

<tools> 和 </tools> 用于封装工具定义。
<tool_call> 和 </tool_call> 用于封装特定的工具调用，包括要调用的工具和相关参数。
</tool_response> 和 </tool_response> 用于封装被调用工具的结果或响应。

在代理指令中，我们在 <tools> 标签之间提供所有工具的规范，让 LLM 了解有哪些工具可用以及如何调用它们。当 LLM 生成输出时，可以通过输出带有适当参数的 <tool_call> 序列来调用工具。</tool_call> token 将触发生成过程停止，以便工具调用可以被解析和执行。工具调用的结果是来自环境的观察或反馈，封装在 </tool_call> 标签中。

使用工具与环境交互

工具介导代理对环境的访问。环境是有状态的，工具调用可能导致环境状态变化。环境动态通常编码在工具调用逻辑中。可以通过工具定义创建任意环境规则，为代理提供对环境状态或从环境返回的反馈的控制；见上文。

在智能体循环的每一步，代理执行两个关键操作：

生成输出 token。
执行工具调用（如果生成了工具调用）。

鉴于工具是代理与环境的接口，这个循环中的一步通常称为环境交互步骤。在每一步之后，我们通过检查预定义的终止条件来确定智能体循环是否应该退出，这些条件因应用而异。例如，我们可以定义最大交互步数、运行一系列测试来确定问题是否已解决，或者让 LLM 提供输出表明其解决方案已完成。

（来自 [10]）

其他细节。 虽然我们已经介绍了代理系统的主要组件，但代理框架是一个快速发展的研究领域——新的想法和组件每天都在出现。其他重要但未包含在上述讨论中的框架组件包括：

上下文管理控制如何向代理呈现信息。例如，长时间运行的任务可能使用压缩来总结先前的步骤，或截断来自环境的反馈（如错误消息），以避免用过多上下文使 LLM 过载；见上文。
记忆可以让代理在长时间运行的任务中甚至在不同会话和任务之间持久化有用的上下文。在概念上，这个记忆系统成为环境的另一个方面——它是有状态的，代理可以通过工具调用访问它。

1.2 智能体强化学习的形式化

RL 训练的组件

最近的工作已经开始将代理轨迹纳入预训练或中期训练过程。然而，大多数关于训练代理的文献都集中在后训练，特别是强化学习（RL）1。在 RL 训练期间，我们在两个关键操作之间交替（如上所示）：

Rollout：给定一组提示，使用当前 LLM 为每个提示采样多个补全（并计算每个补全的奖励）。
策略更新：使用采样的 rollout 和给定的目标函数计算 LLM 的权重更新。

策略更新的细节取决于所使用的 RL 优化器。常见选择包括 GRPO、PPO 和 REINFORCE。虽然 GRPO 最常用，但最近的工作已开始使用 PPO 来提高训练稳定性并更好地处理长时程任务（例如编码代理）。例如，GLM-5.2 [12] 出于这个原因使用了 PPO 而不是 GRPO；见下文。

"长时程任务会产生明显更长的执行轨迹，一旦超长轨迹被压缩分解为多个子轨迹，相同提示下的不同 rollout 会产生数量不同且长度高度可变的可训练轨迹。因此，我们从基于组的优化转向基于 critic 的 PPO 公式化，从单个 rollout 中学习，依赖 critic 来估计 token 级别的优势，而不是基于组的相对比较。" - 来自 [12]

智能体 Rollout。 RL 优化器可能不同，但策略更新的核心输入通常是相同的：token 级别的对数概率和奖励。此外，RL 训练的机制对于代理和标准 LLM 是相似的。主要区别在于 rollout 阶段：

标准 LLM 通常使用单轮设置，给定提示作为输入采样一个文本 rollout。
代理使用多轮设置，其中在单个 rollout 中跨多个环境步骤从 LLM 生成多个输出。

智能体 rollout 比标准 LLM 的 rollout 更复杂。这些 rollout 不仅在长时间跨度上运行，而且智能体 rollout 中的每个步骤还通过工具调用与环境交互。因此，采样智能体 rollout 是一个困难的基础设施问题。某些 rollout 可能由于大量的交互轮次或环境中的减速而需要更长时间才能完成。因此，大多数代理使用具有分离式——相对于同址（colocated）——架构的异步 RL 进行训练；见下文。关于这个主题的更多细节可以在这篇关于 RL 训练基础设施的综述中找到。

（来自 [11]）

MDP 公式化。 为了严格捕捉传统 RL 和智能体 RL 之间的差异，我们将推导单轮 LLM 和代理的马尔可夫决策过程（MDP）公式化。简单地说，MDP 是一个用于决策的概率框架，包括一系列状态、动作、转移动态和奖励——这正是 RL 训练的结构。

传统的单轮 RL 设置具有相对简单的公式化。LLM 使用下一 token 预测生成 rollout，自回归地采样每个输出 token；见上文。在此设置中，MDP 的组件定义如下：

状态：LLM 的当前 token 上下文（即提示 token 和到目前为止已生成的所有 token）。
动作：在下一 token 预测期间选择的 token。
转移函数：将选定的下一个 token 确定性地附加到 LLM 的 token 上下文。
奖励：通常是终端（或结果）奖励，由环境分配给完整的、已完成的 rollout。
轨迹：完整的 rollout 或生成的 token 序列。

在生成期间，通过从 LLM 的下一 token 分布中选择 token 来执行动作——每个 token 就是一个动作。选择一个 token 后，它被添加到当前状态并被 LLM 用于预测下一个 token。这个过程重复，直到 LLM 预测一个停止 token（例如 <|end_of_text|> 或 <eos>），这会终止生成并产生完整的轨迹。

单轮 MDP 公式化

上图描绘了单轮 RL 的 MDP 公式化。此公式化描述了生成单个 rollout 的步骤。在 RL 期间，我们在计算策略更新之前生成一批 rollout。

多轮（智能体）RL 设置将 token 级别的 MDP 公式化扩展到代理可以对外部环境采取行动——并接收反馈——的交互设置。代理不是生成单个文本序列，而是在多个回合中生成动作。每个代理动作可能包括普通文本以及与工具调用对应的格式化序列。当生成工具调用时，它会从环境产生相应的观察。这个观察被添加到运行状态中，类似于生成的输出 token。

智能体 RL 和单轮 RL 之间的另一个关键区别是，状态不再只是 LLM 的 token 上下文。相反，状态现在包括：

文本上下文，包括提示、生成的 token、工具调用以及工具调用产生的任何观察。
环境的外部状态，代理可以通过其动作（即工具调用）修改。

因此，MDP 状态是一个联合状态，包含 LLM 可见的上下文和环境状态。当代理生成 token 时，转移函数将这些 token 确定性地附加到状态中，就像单轮 MDP 公式化一样。然而，转移函数还处理环境状态的更新以及从环境返回的观察。因此，转移函数——与单轮设置不同——可以根据工具或环境的行为是非确定性的。

多轮 MDP 公式化

上图描绘了多轮智能体 RL 的 MDP 公式化。总结一下，我们将此多轮 MDP 的组件定义如下：

状态：代理和环境的联合状态，包括 LLM 可见的上下文——指令、生成的 token、工具调用和观察——以及任何相关的外部环境状态。
动作：给定步骤中代理生成的输出。在最低级别，动作是从 LLM 的下一 token 分布中采样的 token，但 token 序列可以形成更高级别的动作（例如工具调用）。
转移函数**：**在代理采取行动后更新联合状态。纯文本动作将 token 附加到 LLM 可见的上下文，就像单轮 RL 一样。工具调用还会更新环境状态并返回观察，这些观察可能是随机的。
奖励：分配给代理在轨迹上行为的反馈，包括终端（或结果）奖励和通常在步骤级别授予的中间奖励。
轨迹：完整的多轮交互痕迹，包括指令、代理动作、工具调用、观察、奖励和相关环境状态。

与单轮公式化类似，我们在每个 RL 训练迭代中生成一批轨迹。每个轨迹可以包含多轮代理动作和环境交互，这些轨迹用于计算策略更新。虽然最近关于 RL 的工作大量使用基于结果的奖励，但智能体 RL 经常同时使用结果奖励和中间过程奖励，以在更长的轨迹上提供细粒度的监督。

环境执行和扩展。 每个智能体 rollout 需要一个隔离的环境实例，代理可以与之交互。环境可能包含其自身的状态（例如文件系统、代码库、数据库等），代理通过工具（例如 shell、浏览器、API 等）访问和修改这些状态。隔离很重要，因为代理的动作可以修改状态——代理可能会编辑文件或更改数据库条目。在 RL 训练中，我们通常为每个任务生成多个 rollout（例如 GRPO 的组）。如果没有隔离，这些 rollout 可能会修改相同环境的共享状态，一个 rollout 中的错误可能会干扰其他 rollout。可以通过为每个 rollout 创建单独的隔离环境实例来避免这些问题——代理始终拥有其专用环境。

编码代理的环境和工具（来自 [13]）

这种隔离通常通过 Docker 容器或类似的沙箱机制来处理——每个 rollout 接收一个干净的环境实例以防止轨迹间干扰。扩展环境是一个系统挑战。RL 训练每次更新可能需要数千个并发 rollout，每个都有隔离的环境。环境启动、执行或拆除中的任何减速都会成为 rollout 生成和 RL 训练过程的瓶颈。

"我们遇到的一个挑战是扩展 SWE-Bench 环境……每次 RL 迭代并行生成 512 个 Docker 容器……使 Docker 的 API 服务器过载并最终导致 Docker 守护进程崩溃……为了消除这个瓶颈，我们将 Kubernetes 支持集成到 R2E-Gym，让编排器跨节点池调度容器。" - 来自 [13]

朴素的实现可能会通过每个 rollout 工作节点上的本地 Docker 守护进程启动容器，但当许多工作者并发创建和销毁容器时，这可能成为瓶颈。更大规模的系统通常使用集群编排层（例如 Kubernetes）在资源池上调度环境实例、管理环境生命周期并避免单点故障。有关 RL 环境的实际示例以及如何大规模管理它们，请参阅下面来自 Prime Intellect 的文章。

Environments Hub

2、智能体强化学习框架和技术

既然我们对代理以及如何使用 RL 训练它们有了基本的了解，我们将研究一系列从实用角度研究智能体 RL 的近期论文。这些论文涵盖了代理训练的所有方面，例如：

正确表示轨迹。
扩展环境。
处理多任务训练。
创建合成环境。
使训练稳定。

从这项工作中，我们将识别出反复用于训练更有能力代理的常见模式和实用技术。正如我们将看到的，训练过程的许多部分可以模块化，使得更容易对新环境、奖励设计、rollout 策略和 RL 优化器进行实验。

2.1 ToRL：扩展工具集成强化学习 [1]

（来自 [2]）

虽然 LLM 往往难以执行精确的数值计算或解决复杂的方程，但这些任务可以轻松委托给外部工具。例如，教 LLM 如何使用外部代码解释器生成和执行代码，可以实现复杂的数学和符号推理能力。这个概念通常被称为工具集成推理（TIR），以这种方式被教授推理的 LLM 代理已被证明相当强大 [2]。如上图所示，TIR 在问题解决过程中交替进行基于文本和基于代码的推理。

"尽管取得了这些进展，现有的工具集成推理方法面临关键限制。大多数研究从更强的模型中提取轨迹并执行 SFT，将模型限制在预定的工具使用模式中，并限制了对最优策略的探索。" - 来自 [1]

代理通常通过监督学习被教授执行工具集成推理（例如通过在强大的教师 LLM 生成的轨迹上训练）。[1] 中的作者通过使用他们提出的工具集成强化学习（ToRL）方法使用 RL 训练工具集成推理代理来扩展这种方法。这个训练框架相对简单——它使用标准的基于结果奖励的 RL 设置——但 [1] 中的分析为实现工具集成推理代理的稳定有效的 RL 训练提供了有用的实用见解。

ToRL 框架使用 RL-Zero 设置，这意味着我们直接从尚未经过任何后训练的预训练基础模型开始 RL 训练过程。为了实现工具集成推理，代码解释器作为工具被添加到 RL 训练环境中，模型通过奖励驱动的探索学习使用工具。重要的是，LLM 被给予一个提示，鼓励模型使用自然语言和基于代码的推理的融合来回答问题；见下文。这个提示提供了一个有用的种子，通过鼓励 TIR 风格的解决方案来帮助缩小模型的探索空间。这种行为随后在 RL 训练期间得到完善，因为模型被更新以最大化奖励。

（来自 [1]）

当模型生成文本时，它有交织的代码块，包裹在 ```python <code here>``` 指示符中。生成代码块后，模型然后产生一个 ```output 标签。当生成此标签时，我们：

暂停生成。
执行代码块2。
将代码输出附加到上下文。
继续生成。

下图提供了这种交织代码结构的示例。

（来自 [1]）

模型可以将多个代码块交织到问题解决过程中。然而，执行每个代码块的代价是停止推理过程，因此可能会减慢 RL 训练期间的 rollout 生成。为了确保代理不会过度使用代码块并导致训练效率下降，我们对模型施加每个问题最多 C 个工具调用的限制。[1] 中的大多数实验设置 C = 1。设置 C = 2 会产生适度的性能提升，但这是以显著的效率成本为代价的。

"我们在代码执行失败时故意向 LLM 返回错误消息……这些错误诊断增强了模型在后续迭代中生成语法和语义正确代码的能力。" - 来自 [1]

代码执行期间的任何错误都作为观察返回给 LLM。然而，[1] 中的作者将错误消息截断为只包含最后一行，这样 LLM 的上下文就不会被冗长的回溯信息过载。代码输出也会从 RL 损失函数中屏蔽，确保非生成的文本被视为外部上下文，并且模型不会被训练来预测这些结果。所有代码都在与主训练过程隔离的沙箱环境3中执行。创建沙箱环境会增加额外的执行延迟，但隔离对于确保代码中的问题（例如段错误）不会损害实际的 RL 训练过程是必要的。

[1] 中用于训练工具集成推理代理的奖励机制相对简单。奖励函数分配：

正确响应的正奖励（+1）。
错误响应的负奖励（-1）。
不可执行代码的轻微负奖励（-0.5）。

我们在 [1] 中了解到，惩罚代理的不可执行代码不利于性能；见下文。使用纯结果奖励——通过将模型的输出与提示的 ground truth 答案进行比较计算——产生的结果与或超过使用额外错误惩罚实现的结果。[1] 中的作者假设这种惩罚可能会鼓励模型在生成代码时变得过于保守，从而导致整体性能下降。

有和没有代码错误惩罚的结果（来自 [1]）

实用发现。 [1] 中的实验使用 GRPO 在从公开基准（例如 MATH 和 Numina-MATH）整理的约 29K 数学竞赛问题集上执行。难以验证的问题（例如证明风格的问题）从数据中移除，最终的训练示例集使用 LIMR 技术选择；见下文。在高层次上，LIMR 跟踪每个训练样本在训练轮次中的奖励，并根据与学习轨迹的对齐程度对问题进行评分。与模型学习过程匹配的示例获得高分并被选择。LIMR 不是选择困难或随机的数据，而是优先考虑模型在正确时间可学习的问题。

（来源）

使用 ToRL 训练被发现可以显著提高数学推理能力。例如，对于 Qwen2.5-Math-7B 模型，相对于 SFT 训练的基线观察到 14.7% 的绝对准确率提升；见下文。

（来自 [1]）

除了 ToRL 的性能优势之外，[1] 中观察到代理行为有几个有趣的趋势：

模型通过生成代码解决问题的比例在整个训练过程中稳步增加（即从 40% 增加到 80%，在 100 步之后）。
成功执行的代码比例在整个训练过程中增加。

这些发现表明，有意义的工具使用策略可以通过 RL 学习。作者甚至提供了在使用 ToRL 训练的模型中观察到的复杂代理行为的具体示例。例如，代理被发现使用错误消息中的信息来反思和纠正自己的代码，甚至使用代码和自然语言的混合来验证生成的解决方案。

2.2 AgentGym-RL：通过多轮强化学习训练 LLM 代理进行长时程决策 [3]

（来自 [3]）

随着 LLM 从对话代理发展为推理和行动的自主系统，训练这些代理的基础设施也必须发展。在 [3] 中，作者提出了一个开源框架，用于使用 RL 训练 LLM 代理，以更好地处理需要跨多个对话轮次进行复杂交互的决策任务；见上文。[3] 中提出的框架使用结果奖励训练 LLM 代理——与大多数智能体 RL 训练工作类似——但遵循模块化和可扩展的设计以简化代理实验。值得注意的是，代理在 [3] 中纯粹使用基于结果的 RL 进行训练，通常从现有的 instruct 模型检查点（例如 Qwen2.5-3B-Instruct）开始。

AgentGym-RL 框架是先前 AgentGym 框架的通用扩展，具有改进的效率和更模块化的支持，可在各种现实任务上进行训练。该框架有三个关键组件：

环境：代理要解决的现实任务或场景。
代理：由在智能体循环中运行的 LLM 驱动的核心智能层，用于处理观察、推理和生成动作。
训练：模块化 RL 训练管道，允许我们在环境内优化代理行为。

[3] 中的环境涵盖各种领域（例如网页导航、具身任务或科学实验），但遵循标准设计。即，环境是实现共享 API 集的独立服务；见下文。

（来自 [3]）

这种标准化结构允许我们在 RL 训练期间独立并行运行许多环境。具体来说，[3] 中的每个环境作为独立服务运行，暴露统一的 HTTP 接口，允许许多不同的环境无缝"插入"到 RL 训练过程中。

更新代理。 执行训练更新时，我们有一批用户查询和每个查询的初始环境状态集。环境并行初始化，每个代理与自己的环境实例交互以避免任务之间的干扰。通常，这些代理是运行在每个独立环境中的当前策略的副本。在智能体循环内，每个代理与环境经历几个顺序交互轮次，其中在每轮中执行以下操作：

response = actor.generate(prompt)：给定当前状态和交互历史，从代理采样响应。
state, reward = env.step(response)：将此响应发送到环境客户端以更新环境、提供环境观察并产生奖励。
add_assistant_message(response)：更新轨迹以包含从代理采样的新响应。
add_user_message(state)：更新轨迹以包含代理最新动作后环境的新状态。

最后，框架记录每个交互轮次期间产生的任何分数或奖励。当代理解决任务或达到其固定的交互轮次预算时，智能体循环终止。每个完成的 rollout 产生一个完整的轨迹，包含代理的所有动作、观察和奖励。通过跨环境并发运行多个代理，框架收集一批轨迹，然后传递给训练管道以更新代理的行为。此过程在整个训练过程中重复。

工程优化。 除了 [3] 中使用的代理-环境交互统一接口之外，AgentGym-RL 还包括几个特定于环境的工程优化，使长时间运行任务的 RL 实验更加高效。例如，verl 库已扩展到单轮用例之外，以更好地支持多轮智能体 RL。用于 AgentGym-RL 的 RolloutHandler 跟踪所有轨迹细节（即每个 rollout 的完整交互历史和奖励），并构建注意力和损失掩码以帮助区分轨迹中的代理和环境生成的 token。

"一个框架必须能够在并行性和交互持续时间上进行扩展。我们实施了一系列优化来实现这一点……我们将 WebArena 默认的每进程单浏览器设计替换为基于子进程的架构，允许单个服务器并发管理多个 Chromium 实例……在 SciWorld 环境中，我们重新设计了环境的初始化和重置例程，以支持多个实例的健壮并行创建和重置……我们通过 WebArena 中的完全重置接口支持更长的训练时程，该接口在每个 episode 之后将每个 Web 服务器恢复到初始状态，并缓解随时间推移的状态不一致。" - 来自 [3]

环境还配置为支持并行初始化并独立运行以收集许多并发 rollout。例如，WebArena 环境最初使用每进程单浏览器设计，在 [3] 中被基于子进程的架构所取代，允许单个服务器管理多个并发浏览器实例。SciWorld 环境也被修改以简化在每个 rollout 开始和结束时启动和重置多个环境实例。进行了许多这样的修改，以便在 [3] 中更有效地管理和扩展智能体 RL 的环境。

ScalingInter-RL。 我们在 [3] 中看到，训练 LLM 代理执行长时程任务是困难的。在训练的早期阶段，代理难以产生有意义的长交互，通常塌缩为冗余的推理模式或采取不必要的行动。我们可以通过限制代理训练的环境集来解决这个问题——如果我们只考虑较短时程的任务，训练可能是稳定的——但这种方法会阻止代理学习多样化的、非平凡的推理模式。

（来自 [3]）

作为解决方案，[3] 中的作者提出了一种称为 ScalingInter-RL 的课程学习策略，该策略在代理训练过程中单调增加任务时程；见上文。我们从初始探索阶段开始，通过首先在简单任务上发展熟练程度来建立代理的基础技能。随着时间的推移，我们逐渐增加代理可以执行的交互量，允许逐渐引入长时程规划。这种方法通过确保代理在尝试更长时程决策之前建立基本技能来稳定训练过程。

"随着时程的增加，代理被激励探索更长的决策路径，促进更高阶认知行为的出现，如规划、反思和战略回溯……这种分阶段的扩展使 ScalingInter-RL 能够将交互深度与代理不断发展的策略能力对齐，弥合高效的早期利用和长时程泛化之间的差距。" - 来自 [3]

具体来说，这个课程通过将 RL 训练过程分为 N 个阶段来实现。假设我们执行总共 T 次训练更新，每个阶段包含 ∆ = T / N 步，并分配单调递增的交互预算 h_1 < h_2 < … < h_N。此交互预算每 ∆ 次迭代增加一次，交互被定义为代理与环境的交互轮次数。具体来说，代理在 [3] 中使用 N = 3 个阶段、∆ = 80 次训练迭代进行训练，预算分别为 8、12 和 15 个交互轮次。 ScalingInter-RL 使用标准的 RL 训练目标：*我们希望最大化代理收到的预期累积奖励。*然而，这个目标是在逐步增加的环境交互轮次约束下优化的。为了实现这个约束，一旦达到最大交互轮次，框架就会终止交互，并提示代理提供最终答案。

（来自 [3]）

使用 RL 训练代理。 我们在 [3] 中看到，RL 训练允许较小的开源模型（最大 7B 参数）在各种环境中表现与大型闭源模型相当。换句话说，RL 训练对于在较小模型中注入代理智能是有效的。例如，[3] 中最好的模型在网络搜索和深度研究任务上分别达到 26% 和 38.25% 的成功率，超过了 GPT-4o 甚至参数量是其 10 倍的开源 LLM（例如 Llama-3.1-70B）的性能。

"训练早期阶段的过度探索不一定是好的选择。在建立坚实基础之前，代理可能会进行无生产力和低效率的探索，导致训练不稳定性风险。相比之下，较短的轮次限制了早期探索，但提供更稳定的学习信号，从而带来更可靠的长期性能。" - 来自 [3]

当我们更细粒度地评估跨领域性能时，我们看到 RL 在具有明确环境规则的结构化任务上最有益——高复杂度的开放式环境受益不那么显著。例如，RL 训练在 TextCraft（基于文本的游戏环境）和 SciWorld（科学实验的基于文本的模拟器）等领域提供最显著的性能提升。这两个任务都有简单的模拟环境，遵循明确的基于规则的动态。虽然 RL 训练在所有领域仍然有益，但在基于更真实和嘈杂的 Web 环境的 WebArena 上，性能提升不那么明显。

ScalingInter-RL 方法也被发现比固定时程方法更一致地稳定训练。如下所示，大的交互预算（即 10 个轮次）往往会最初提高性能，但 RL 训练过程很快崩溃。相反，在训练早期阶段限制交互预算会提供清晰而稳定的学习信号。通过随着时间的推移逐渐增加交互预算，我们允许模型通过重新利用在更简单任务上掌握的推理模式来解决更困难的问题。因此，我们能够在保持 RL 优化过程稳定性和效率的同时，有意义地提高代理的能力。

（来自 [3]）

有趣的是，[3] 中发现 RL 训练的代理自然具有强大的测试时扩展能力。我们看到增加以下方面会带来明显的性能收益：

顺序交互（即允许每个任务有更多的环境轮次）。
并行采样（即为每个任务生成多个轨迹）。

事实上，用 RL 训练的代理被发现在这方面优于基线模型，表明 RL 训练的代理表现出更强的测试时扩展行为。[3] 中还测试了各种 RL 优化器。RL 优化器的选择会对性能产生有意义的影响。例如，用 GRPO 训练的 3B 参数模型实际上优于用 REINFORCE 训练的更大的 7B 模型。

2.3 Agent-R1：智能体强化学习的统一模块化框架 [4]

（来自 [4]）

当作为代理行事时，LLM 预期不仅进行静态推理或问答。代理需要在长时间跨度上自主决策和行动，并快速适应环境状态的变化——它们存在于一个动态和交互的世界中，必须可靠地遍历这个世界来解决困难问题。由于代理必须解决的任务的动态性质，我们为 RL 训练采取的方法需要特别考虑。

"代理进行顺序决策，跨轮次维护记忆，并适应随机的环境反馈，呈现出与更静态任务不同的独特挑战。这导致在应用 RL 时出现特定困难；特别是在多轮交互场景中，代理训练可能遇到不稳定、复杂的奖励信号设计和有限的泛化" - 来自 [4]

在单轮 RL 中，rollout 可以表示为 token 的扁平序列，但智能体 RL 更复杂：模型经历多轮观察上下文、采取行动和接收反馈。我们的 RL 训练框架必须保留代理在多轮轨迹中获得的观察、行动、反馈和奖励的因果结构，直到终止。框架还必须有效地编排通常以不同时间粒度运行的多个相关组件，例如：

LLM 推理。
工具执行和环境模拟。
轨迹存储和回放。
使用 RL 的模型更新。

Agent-R1 提供了一个以标准化方式统一这些组件的框架。特别是，大部分设计集中在正确集成 rollout 和训练步骤上，使其最适合多轮 RL。该框架支持各种环境设置，可以与任意 RL 优化算法以及终端和过程奖励集成。

（来自 [4]）

步骤级轨迹。 Agent-R1 的一个关键设计选择是将每个代理-环境交互步骤——而不是每个 token——视为代理轨迹的主要单元。这意味着 RL 训练期间产生的每个轨迹都表示为一系列结构化的步骤级跟踪。对于每个步骤，我们存储：

当前和下一个状态。
代理的动作。
环境反馈或观察（例如工具输出）。
奖励（步骤级和终端级）。

这种结构维护了明确的步骤边界，使框架不仅能够捕获终端奖励，还能够捕获定位到代理轨迹中特定步骤的过程奖励。具体来说，每个步骤都存储奖励，以及标识轨迹中最后一步的终止信号——具有正终止信号的步骤中的奖励是结果奖励。

轨迹通常表示为 i) 扁平 token 序列或 ii) 消息跟踪（即带有相关角色和内容的聊天式消息列表）。然而，这两种表示在用于智能体 RL 时都有局限性。

"在[智能体 RL]中，将轨迹视为不断增长的 token 序列的通常观点变得越来越不充分：它使上下文演化变得僵化，并在 rollout 和训练之间造成表示不匹配。" - 来自 [4]

使用消息格式时，我们将轨迹存储为消息列表，然后在执行策略更新时将它们重新构建为文本提示（例如使用提示模板）。这种方法可能导致不匹配——在 [4] 中称为 retokenization drift（重标记漂移）——因为 rollout 发生在 token 空间中，但这些 token 被解析为文本消息并稍后重新标记。由于 tokenization 是不可逆的，此管道可能导致生成的轨迹与实际用于训练的数据之间存在不一致；见下文。

（来自 [4]）

Agent-R1 中的 rollout 作为结构化的步骤级记录存储，保留原始动作 token 和明确的交互边界；见上文。这种格式通过显式存储每个步骤生成的 token 并在训练期间直接使用这些 token，显著降低了 retokenization drift 的风险。

另一方面，将轨迹表示为扁平序列很简单并保留确切的 token，但这种方法使步骤边界隐含，并假设上下文管理采用仅追加策略。步骤级轨迹表示支持灵活的上下文管理策略；见下文。我们可以选择如何从这些步骤级跟踪构建上下文。

（来自 [4]）

代理实现可能仍采用简单的仅追加策略，将新信息直接添加到代理的上下文中。然而，这种方法在工具输出冗长或无关推理步骤的场景中是有问题的——用太多信息使代理上下文过载可能导致上下文腐烂。

为了避免这个问题，Agent-R1 定义了特定于环境的上下文规则，允许任意内存管理策略集成到 RL 训练中。代理可见的上下文通过将原始步骤级跟踪传递通过此规则来构建。在此规则内，我们可以选择保留、总结、删除或转换轨迹中的任何步骤。通过这种方式，Agent-R1 为每个 rollout 存储完整的结构化轨迹，但模型并不总是看到这个完整轨迹。相反，特定于环境的上下文规则决定了成为代理下一个观察的（可能经过转换的）上下文。

环境结构4。 [4] 中介绍的 RL 框架的目标是扩展现有的单轮 RL 框架以支持多轮和交互式任务。这两种范式之间最显著的差异存在于 rollout 阶段：单轮 rollout 要求策略生成一次响应，而多轮 rollout 包含多个环境交互轮次，其中每一步都可能发生工具调用。这些步骤涉及根据代理生成的工具调用，从 LLM 代理生成输出以及与环境交互。在 Agent-R1 中，所有与环境的外部交互通过两个主要接口进行标准化：

Tool 接口执行原子操作或工具调用（例如调用 API、执行代码、检索数据等）。
ToolEnv 接口通过解析工具调用、调用工具、更新环境状态、计算奖励并返回下一个观察来实现每个交互步骤的环境转换。

Tool 作为描述 LLM 代理可以采取的原子操作以与环境交互的统一接口。代理可以在环境中采取的所有操作都被封装成一组明确定义的工具，可以由代理调用。[4] 中使用的特定工具格式基于 OpenAI function calling schema。每个工具有两个模块：

执行逻辑：处理工具输入参数、执行操作并返回结果的核心执行方法。
元数据规范：工具的名称、描述和参数（以结构化 JSON schema 指定）。

为了让代理有效地与每个工具交互，元数据规范必须清晰全面，让代理了解每个工具的用途并在需要时正确调用工具。在 LLM 代理调用工具后，它执行请求的操作并返回原始结果。

ToolEnv 编排代理与其环境之间的交互。ToolEnv 的操作通过 step() 函数标准化，该函数驱动代理-环境交互。此函数摄取代理的原始输出，识别并执行任何工具调用，更新环境状态，计算当前奖励（如果有），并向代理返回观察。步骤机制因领域而异，但某些辅助方法必须为任何任务实现：

从代理输出中解析结构化工具调用。
在将工具输出添加回代理上下文之前对其进行格式化。
检查给定轨迹的终止条件（即代理是否已完成任务）。
轨迹终止后计算最终结果奖励。

ToolEnv 管理状态转换，为代理打包状态信息，计算奖励信号，并编排创建多轮轨迹或 rollout 的整个过程。ToolEnv 可以处理将代理输出纳入下一个状态的生成式转换，以及可能修改外部环境或状态的工具调用触发的任何转换。

"这种设计以 step 方法在推动环境动态中的关键作用为中心，并由管理工具调用和轨迹生命周期的清晰机制支持，使 Agent-R1 框架能够有效地模拟复杂的交互场景。它仔细区分了确定性文本生成与工具使用引入的非确定性、改变环境的状态变化，这对于代理学习至关重要。" - 来自 [4]

Agent-R1 框架的多轮 rollout 过程如下图所示。如图所示，每个 rollout 在代理循环运行时跨多个步骤组合两个关键接口。随着在每个步骤生成输出，ToolEnv 解析工具调用并通过相应的 Tool 接口执行它们。每一步之后，相关上下文（例如工具输出或生成的 token）由 ToolEnv 处理并添加到代理的上下文中，然后进入下一个生成步骤。奖励可以在中间步骤计算，一旦达到终止条件，计算最终奖励并结束 rollout。每个 rollout 包含代理的状态、动作和奖励的步骤级历史。

（来自 [4]）

既然我们已经定义了处理代理与其环境之间动态交互的模块化结构，我们可以开发学习策略来优化代理的行为。尽管智能体 RL 具有独特的性质，Agent-R1 并未规定特定的 RL 算法。相反，该框架标准化了多轮轨迹的表示方式及其传递给优化层的方式，允许各种 RL 优化器（例如 PPO、GRPO 和 REINFORCE）在相同的交互数据上运行。无论使用哪个优化器，两个实现细节尤其重要：

将结果奖励和中间过程奖励都纳入 RL 目标。
从策略目标中屏蔽非生成的 token，包括初始指令和任何工具或环境输出。

在 [4] 中，用于标识 LLM 生成的 token 的掩码称为 Action Mask（动作掩码）。这个二进制掩码对代理生成的 token 为 1，否则为 0。token 级损失乘以这个掩码，使得只有代理生成的 token 对策略梯度有贡献，而非生成的内容和提示被视为外部上下文。因为 Agent-R1 将轨迹存储为结构化的交互步骤，它可以将每个动作与相应的反馈和奖励相关联，并识别该动作中的各个 token。

（来自 [4]）

这种结构还支持灵活的信用分配。更具体地说，我们可以为每个 token 计算单独的奖励，或者将相同的奖励广播到特定交互步骤中的所有 token。中间过程奖励可以直接附加到获得它们的步骤，而结果奖励可以在整个轨迹上提供信用。Agent-R1 将多轮轨迹的表示与 RL 优化器的选择分离，为不同的优化策略提供通用格式。

经验验证。 Agent-R1 框架用于在四个不同环境中训练 Qwen3-4B 模型：GSM8K、HotpotQA、ALFWorld 和 WebShop。RL 训练明显提高了所有环境中的性能，但结果因训练设置而异。例如，GRPO 在大多数任务上产生最佳结果，但 PPO 在 WebShop 环境中表现最好；见下文。不同 RL 算法之间的性能没有剧烈差异——两种 REINFORCE 变体也表现良好——但性能差异确实存在。

（来自 [4]）

有趣的是，上下文管理策略的选择也被发现对代理性能有很大影响。[4] 中测试了几种不同的策略：

仅追加：只是继续将所有上下文追加到轨迹中。
滑动窗口：只在轨迹中维护最近的上下文。
LLM 总结：使用 LLM 总结上下文，以避免耗尽代理的最大上下文长度。

在 GSM8K 环境上测试时，滑动窗口策略实现了最佳性能；见下文。虽然这些结果可能特定于被测试的环境，但我们看到保留所有上下文并不总是最优的。通过采用更有效利用上下文窗口的上下文管理策略，可以提高代理性能——在某些情况下少即是多。

（来自 [4]）

2.4 AgentRL：使用多轮多任务框架扩展智能体强化学习 [5]

（来自 [5]）

大多数关于 LLM RL 训练的早期工作考虑单轮设置，通常专注于一个领域或任务。虽然这种方法对对话和推理领域效果很好，但我们必须扩展 RL 训练策略以处理多轮多任务设置，以训练自主 LLM 代理。在 [5] 中，作者提出了一个开源框架 AgentRL，用于扩展通用 LLM 代理的 RL 训练过程。正如我们将看到的，AgentRL 框架结合了基础设施和算法改进，使 RL 训练高效且易于扩展到各种任务领域。

"从单轮到多轮的转变定义了智能体 RL 问题，其中 LLM 作为自主代理执行多轮推理、与工具或环境交互，并在扩展的轨迹上调整其行为。" - 来自 [5]

智能体 RL 的复杂性。 智能体 RL 的多轮设置是与标准单轮 RL 训练设置的关键区别因素。在多轮代理环境中生成 rollout 很复杂：

生成过程是长时间运行的，包含多个轮次。
代理能够在任何给定轮次与其环境交互，这可能会减慢生成过程。
每个轨迹的长度——以及相应的实际生成时间——高度可变。
相关代理环境的数量庞大，每个环境都有独特的特征。

鉴于代理轨迹在长度和完成时间上差异很大，交错训练和生成的同步 RL 方法——虽然在单轮设置中常用——将不起作用。即使在单个训练批次内，我们可能也需要采样几个需要截然不同时间才能完成的 rollout。在同步设置中，当较长的轨迹仍在完成时，我们会让处理较短轨迹的 GPU 空闲，导致硬件利用率差且不平衡。

代理在交互环境中运行的事实加剧了这种可变的 rollout 时间。在采样每个轨迹时，代理必须在其频繁交互的隔离环境中运行。环境交互的减速会导致 rollout 长度和完成时间的可变性，从而降低效率。为了避免这个问题，智能体 RL 框架必须能够并发部署和管理大量环境。

（来自 [5]）

根据要解决的问题，代理可能需要在具有独特接口和计算需求的各种环境中运行。为了简化将新任务集成到 RL 训练过程中，我们可以设计一个标准接口，让我们统一各种代理环境的设计和执行。此外，必须进行算法改进，以确保 RL 训练过程在训练过程中的许多环境和领域中保持高效和稳定。

AgentRL 框架有三个关键组件，用于解决上述智能体 RL 的每个挑战：

异步 RL 训练管道。
可扩展的环境部署基础设施。
算法更改（即任务优势归一化和跨策略采样），用于更好的智能体（即多轮和多任务）训练。

（来自 [5]）

如前所述，由于 rollout 长度或时间的可变性会产生大量空闲时间，同步设置对智能体 RL 效果不佳。为了更好地处理长的交互轨迹，[5] 中的作者采用了完全异步训练管道，将 rollout 生成与模型训练解耦。为训练和推理创建了单独的引擎，每个都有专用的资源池5。两个引擎并发运行：

推理引擎持续在可用硬件上调度异步 rollout 作业，其中每个作业在给定任务上运行智能体循环并生成完整的 rollout 或轨迹。
训练引擎在每次更新后拉取所有已完成的轨迹——而不是像同步设置中那样等待固定批次的 rollout 完成——以执行下一次更新。

在此设置中，批大小在训练更新之间变化，但 [5] 中的作者为每个批次设置了最小和最大 rollout 数，以确保批大小在可接受范围内波动。通过这种方法，我们可以通过确保一旦有足够数据可用就立即继续训练来提高硬件利用率。此外，rollout 生成时间的可变性通过推理引擎持续运行作业的事实来处理。未能及时完成以供给定更新使用的 rollout 将简单地继续运行，我们在现有作业完成时立即调度新的 rollout 作业。

"为了避免 rollout 引擎的 off-policy 偏差，我们设置数据队列的最大大小，并强制在每一步将所有轨迹移动到训练引擎。通过这样做，所有轨迹都尽可能与最新策略保持同步，后续实验表明这是可接受的。" - 来自 [5]

保持在策略上。 有了这样的异步管道，我们面临在训练更新中包含陈旧或 off-policy 数据的风险。为了使训练方法完全在策略上（on-policy），用于生成 rollout 的模型应该与被更新的模型相同，但这在异步设置中并不总是成立——当轨迹用于训练时，模型可能已经经历了一次或多次策略更新。我们可以通过以下方式限制数据的陈旧性来防止训练过程变得过于 off-policy：

将完成的异步 rollout 存储在数据队列中。
限制此队列的最大大小，使 rollout 工作者无法生成无限数量的轨迹。
如果队列已满，请等到训练者消耗现有数据后再将新轨迹添加到队列。
在每次更新期间从队列拉取所有数据到训练引擎（即清空队列），以确保数据不会闲置太久。

AgentRL 还为代理环境设计了统一的环境部署基础设施。在多任务智能体 RL 中，我们需要能够同时运行大量异构环境，并轻松扩展训练以包含新环境。为了处理环境的可变性，创建了一个统一的基于函数调用的 API 接口，代理可以使用它与任何环境交互。此接口用代理可以调用的标准化函数调用替换每个环境的自定义动作格式；见下文。

（来自 [5]）

[5] 中的每个环境工作者都被容器化为隔离的执行单元，与其他环境分开。容器化隔离了在许多并发环境中运行时发生的错误，并简化了跨各种硬件的环境部署，从而提高利用率和效率。如上图所示，AgentRL 中的环境由中央控制器管理，该控制器编排训练管道和 rollout 工作者。此控制器管理数千个并发环境实例，并允许 rollout 引擎通过统一接口与这些环境交互。

"为了在同一基础设施下托管、调度和监控异构环境而无需额外的集成成本，我们在工作者和控制器级别暴露一致的接口。在环境方面，我们跨所有任务统一工作者 API，使得每个任务可以使用相同的一组生命周期操作进行实例化和管理。在训练方面，控制器为 RL 引擎提供单个网关 API，抽象任务异构性，并将多任务执行暴露为单任务情况的透明扩展。" - 来自 [5]

最后，[5] 中采用了一些算法更改来处理智能体 RL 中常见的两个关键困难：

由于多轮智能体设置中的大动作空间，模型随时间推移探索能力严重下降。
当训练过程中包含多个不同任务时，RL 训练倾向于变得不稳定。

为了鼓励探索，提出了一种跨策略采样技术，使用多个 LLM 在单个轨迹中生成动作；见下文。轨迹中的动作通常从单个模型采样，但这种方法从模型池中随机抽取以在每个步骤生成动作，从而通过创建任何单个模型都不会探索的轨迹来帮助探索。

在 rollout 引擎中管理多个模型很复杂。相反，作者创建了一个模型池，其中包含训练过程早期步骤的几个较早版本的模型。具体来说，这个模型池通过一组专用的 rollout 引擎构建，这些引擎通过在 RL 训练过程中以不同频率更新模型参数来有意保持陈旧。

（来自 [5]）

值得注意的是，[5] 中的作者测试了跨策略采样（从轨迹内的不同模型采样动作）和混合策略（用单个模型生成每个轨迹，但在更新中组合来自多个模型的轨迹）。跨策略采样与混合不同，因为策略在每个轨迹内混合。这种方法允许后续动作来自不同的策略，并创建与任何单个策略生成的轨迹不同的轨迹。有趣的是，[5] 中提出的跨策略采样方法在经验上优于更简单的混合策略。

还引入了修改后的任务级优势归一化方法，以提高多任务训练的稳定性。AgentRL 首先使用基础 RL 算法计算优势。在训练使用的 GRPO 设置中，结果奖励相对于为相同输入采样的其他 rollout 进行归一化，为每个轨迹产生组相对优势。然后使用动作掩码将此轨迹级优势分配给该轨迹内所有代理生成的 token，与标准 GRPO 中使用的方法匹配。

import torch

eps = 1e-8

# terminal reward for each sampled trajectory
rewards = torch.tensor([1.0, 0.0, 0.5, 1.0, 0.0, 1.0])

# trajectories with same prompt ID were sampled for the same input
# we have three trajectory groups for GRPO here
prompt_ids = torch.tensor([0, 0, 1, 1, 2, 2])

# first four trajectories belong to task / domain 0
# final two trajectories belong to task / domain 1
task_ids = torch.tensor([0, 0, 0, 0, 1, 1])

# 1 marks tokens generated by the agent
# 0 marks prompt, padding, or environment tokens.
action_mask = torch.tensor([
    [0, 1, 1, 1],
    [0, 1, 1, 0],
    [0, 1, 1, 1],
    [0, 1, 0, 0],
    [0, 1, 1, 1],
    [0, 1, 1, 0],
], dtype=torch.float32)

# -------------------------------------------------
# compute GRPO-style advantage for each trajectory
# -------------------------------------------------
trajectory_advantages = torch.zeros_like(rewards)

for prompt_id in prompt_ids.unique():
    group_mask = prompt_ids == prompt_id
    group_rewards = rewards[group_mask]

    group_mean = group_rewards.mean()
    group_std = group_rewards.std(unbiased=False)

    trajectory_advantages[group_mask] = (
        group_rewards - group_mean
    ) / (group_std + eps)

# ----------------------------------------------------
# assign trajectory advantage to each generated token
# ----------------------------------------------------
token_advantages = trajectory_advantages[:, None] * action_mask

# --------------------------------------------
# normalize token advantages within each task
# --------------------------------------------
task_normalized_advantages = torch.zeros_like(token_advantages)

for task_id in task_ids.unique():
    task_rows = task_ids == task_id
    task_action_mask = action_mask[task_rows].bool()

    # gather all agent-token advantages for the entire task
    task_values = token_advantages[task_rows][task_action_mask]

    task_mean = task_values.mean()
    task_std = task_values.std(unbiased=False)

    normalized_values = (
        token_advantages[task_rows] - task_mean
    ) / (task_std + eps)

    # zero out non-agent-generated token positions
    task_normalized_advantages[task_rows] = (
        normalized_values * action_mask[task_rows]
    )

print("Trajectory advantages:")
print(trajectory_advantages)

print("\nToken-level advantages:")
print(token_advantages)

print("\nTask-normalized token advantages:")
print(task_normalized_advantages)

然后 AgentRL 将当前批次中每个领域（如 WebShop）的所有 token 级优势分组，并使用该领域的均值和标准差进行归一化；见上文。因此，每个领域的 token 级优势分布具有大约零均值和单位方差。这个额外的归一化步骤减少了任务领域之间优化规模的差异，并防止单个领域主导策略更新。当一起使用时，任务级优势归一化和跨策略采样使多任务多轮 RL 更加稳定和高效；见下文。

（来自 [5]）

性能影响。 五个任务被集成到 AgentRL 中，用于 [5] 中执行的实验，包括 ALFWorld、WebShop 和三个为与 SQL 数据库、操作系统和知识图谱交互而创建的新任务。任务在多任务 RL 训练期间均匀采样，使用 RL-Zero 设置（即智能体 RL 训练之前没有热身 SFT 阶段）。

（来自 [5]）

AgentRL 在智能体任务上取得了令人印象深刻的结果，并且在几个基础模型上保持一致，包括 GLM-4-9B 和不同大小的 Qwen2.5-Instruct 模型。AgentRL 实现的平均任务通过率超过了 GPT-5 和 Claude-Sonnet-4 等多个专有模型。这些性能指标对于较小的模型尤其令人印象深刻；例如，即使 Qwen-2.5-3B-Instruct 在使用 AgentRL 进行 RL 训练后也优于大多数专有模型。*RL 训练显然有益于所有任务上的代理性能。*我们可以通过在上表中比较 Qwen-2.5-32B 基础模型（绿色）和 AgentRL 模型变体（红色）来观察每个任务的性能差异6。

（来自 [5]）

有人可能会认为 AgentRL 取得的令人印象深刻的结果是由于代理直接在用于评估的领域上训练。虽然这一点是正确的并且确实影响评估结果，但我们在 [5] 中也看到 AgentRL 模型对某些保留基准的泛化相对较好。例如，我们在未包含在训练中的 BFCL-v3 基准上看到 AgentRL 的适度增益；见上文。此外，用多任务 RL 训练的代理往往与在每个领域单独训练的代理的性能相匹配，表明 AgentRL 能够训练通用的多任务代理。

2.5 AutoForge：智能体强化学习的自动化环境合成 [6]

代理可能难以解决需要大量环境或用户交互的现实世界任务，但我们可以通过 RL 来完善解决此类任务的能力。这种智能体 RL 方法的主要瓶颈是，为 RL 训练策划具有准确 ground truth 的现实环境往往成本高昂，因此不可扩展。我们可以通过为智能体 RL 合成模拟环境来缓解这个问题，但之前关于这个主题的大多数工作都局限于半自动化方法，这些方法往往产生缺乏难度和多样性的任务。在 [6] 中，作者提出了一个 LLM-in-the-loop 框架来合成高质量的 RL 环境，并概述了对 RL 训练过程的几项修改，可以提高智能体领域的性能和稳定性。

"我们认为，能够自动生成模拟环境和复杂任务的统一管道更适合同时扩展代理训练的范围并加深其复杂性。" - 来自 [6]

任务合成管道是 [6] 的关键贡献，因为它能够合成真实、困难且可验证的 RL 环境；见下文。如果生成的任务质量足够高，那么在模拟环境上进行 RL 训练是提高 LLM 代理的经济高效且可扩展的方法。然而，只有当我们能够最小化代理在训练期间遇到的模拟任务与它必须在现实世界中解决的任务之间的差距时，这种方法才有效。为了确保合成环境足够真实和困难，提出了一种自下而上的方法，从基本工具定义开始迭代构建最终任务。

（来自 [6]）

如上图所示，任务合成管道有三个高级步骤：

环境生成：通过从提供的工具文档开始，自动生成环境的状态空间和函数集。
任务构建：通过采样工具调用序列来构建任务，然后组合和后处理以创建复杂的工具调用序列。
任务实例化：使用最终的工具调用集通过将抽象结构转换为具体值并执行工具序列来生成实际任务，以获得任务的可验证 ground truth 结果。

要执行环境生成，我们从为可用工具提供的文档开始。从这个文档中，我们可以提示 LLM 构建键值对列表 S = [(K_1, V_1), …, (K_n, V_n)] 作为任务的状态空间，以及每个工具的 Python 实现。将工具实现为 Python 函数允许通过标准字典操作轻松与环境状态交互，并支持并发高效的工具执行，这对于 RL 训练是必要的。此过程产生形式为 E = (S, F) 的环境，其中 S 是键值状态，F 是可用函数集；见下文获取具体示例。

S (State):

  projects:
   - project_id: P0001
       project_name: Auro
       owner: Alice
       status: active
   ...

  users:
   - user_id: U001
       email: alice@example.com
   ...

F (Functions):
  get_project_id_by_name(name)
  delete_project(project_id)
  create_project(name)
  assign_user_to_project(project_id, user_id)
  ...

此时仅生成每个状态条目的键——具体值在稍后阶段实例化。从这个初始环境，我们使用自下而上的任务构建方法，首先为任务创建工具调用序列。用工具描述提示的 LLM 将可用工具组织成有向图，其中有向边表示一个工具的输出构成另一个工具的输入。下面显示了一个可能边的示例。

get_project_id_by_name(name) → delete_project(project_id)

可以使用随机游走从这个有向工具图中采样工具序列。然后可以将得到的序列合并在一起——通过连接序列并要求 LLM 删除重复的工具调用——以增加它们的复杂性。

"我们的合成管道从工具描述文档开始，实现自动构建数据库来存储环境状态以及在 Python 中生成工具实现。然后构建工具的依赖图，随机游走由此产生多样化的工具序列。这些序列被合并并用推理节点和边增强，形成复杂的有向无环图（DAG），进而作为生成任务的蓝图。" - 来自 [6]

解决任务时，代理执行的不仅仅是工具调用。它还使用其文本生成能力在解决问题过程中进行推理。我们可以提示 LLM 在工具调用序列中插入推理节点——表示代理应对工具调用结果进行中间推理的点——以捕获这种行为。使用这个工具和推理节点的序列，我们可以然后提示 LLM 预测节点之间的有向边，以形成有向无环图（DAG），捕获任务的解决方案轨迹。我们可以通过提示 LLM 执行以下操作来实例化最终任务：

为每个状态空间变量分配具体值。
基于工具调用序列生成任务意图和问题。
用具体有效的参数增强所有工具调用。
在初始环境上执行工具调用以产生黄金最终状态。
迭代地完善任务以删除不必要的步骤并提高一致性。

任务意图更明确，而任务问题是用户将向代理提出的任务的不太明确的措辞。例如，任务问题 "Hi, I no longer need the Auro project. Could you please delete it? Also, please create a new project named Lumina." 可能有意图 "delete project Auro, create project Lumina"。最终状态用于在 RL 训练期间为每个任务计算可验证的奖励。我们也可以根据 ground truth 工具序列验证代理的轨迹，但 [6] 中的作者选择明确专注于结果验证，因为多个工具序列可能产生相同的有效输出。

"为了更好地模拟用户不断发出请求且代理与用户和环境交互的现实场景，我们在 RL 阶段的合成环境中引入了模拟用户代理。" - 来自 [6]

模拟用户交互。 在构建了模拟任务和环境集之后，我们可以在这些合成环境上使用 RL 训练我们的代理。然而，为使问题解决过程真实，代理必须与环境以外的东西交互——代理在现实世界中通常与用户和环境交互。因此，[6] 中的作者在 RL 训练过程中引入了模拟用户代理。模拟用户代理通过直接向代理提供任务问题来启动任务。然后代理迭代地解决任务，在智能体循环的每一步有两个选项：

进行工具调用。
向用户请求信息。

这两个动作都会向代理返回观察，无论是工具调用的结果还是用户代理的文本回复。当用户代理确定所有需求都已满足时，rollout 终止。此时，将环境状态与 ground truth 状态进行比较以计算最终奖励。具体来说，如果代理产生的环境状态与黄金最终状态完全匹配，则最终奖励为 1，否则为 0。值得注意的是，AutoForge 仅使用基于结果的奖励进行 RL 训练。

（来自 [6]）

**环境相对策略优化（ERPO）**是 [6] 中为智能体 RL 提出的 GRPO 变体，除了上述基于模拟用户的 rollout 过程外，还进行了以下三个额外更改：

交错思考（Interleaved Thinking）：保留代理在任务每一步的思考轨迹，而不是在生成每个新输出时丢弃先前的思考轨迹（即大多数 LLM 使用的标准设置）。保留先前的思考 token 对于保持先前步骤中有用的任务分析和规划信息不被丢弃是必要的。
屏蔽错误用户行为：模拟用户代理可能会犯错。为解决这个问题，用户响应由 LLM 判断以识别模拟用户导致任务失败的错误。检测到此类错误时，该轨迹被排除在优势和损失计算之外7。
环境级优势估计：训练批次由多个环境组成，每个环境有一组问题。问题 q_i 有相应的采样轨迹集 M_i。在 GRPO 中，我们计算每个问题的轨迹集上的组级优势。ERPO 通过计算共享相同环境的问题的所有有效轨迹上的奖励标准差来修改这种方法；见下文。

ERPO 中的优势估计（来自 [6]）

ERPO 使用的修改后的归一化在更广泛的奖励组上计算标准差，进而提高对异常值的稳健性。如上图所示，ERPO 在分子中保留了 GRPO 使用的相同问题级奖励均值。然而，标准差项在同一环境中所有问题的所有有效轨迹上计算，产生环境级优势缩放。换句话说，ERPO 在分子中保持 GRPO 风格的均值，而分母在整个环境中汇集奖励。

经验分析。 [6] 中使用 Qwen3-235B-A22B-Thinking 模型合成了 10 个环境，总共包含 1,078 个任务。当用于微调 Qwen3-30B-A3B-Thinking 时，AutoForge 提高了 τ-Bench 系列和 VitaBench 等域内基准的性能。RL 训练之前，使用基础模型与合成环境交互收集的有效轨迹执行冷启动 SFT 阶段。然后使用 ERPO 进一步优化生成的 SFT 模型。AutoForge 代理性能超过了较大的开放基础模型（例如 Qwen3-235B-A22B-Thinking），在某些情况下接近专有模型（例如 Gemini-2.5-Pro）的性能；见下文。

（来自 [6]）

在域外数据集上评估时，用 AutoForge 训练的代理继续表现良好；见下文。值得注意的是，这个域外泛化测试特别苛刻。AceBench-zh 使用 i) 与训练不同的提示和工具调用格式，ii) 训练期间未见过的新工具集，以及 iii) 完全不同的语言——模型用英语训练，用中文评估。然而，代理在 RL 训练后仍然看到性能提升。

（来自 [6]）

毫不奇怪，我们看到用 RL 训练代理相对于仅用 SFT 的收益明显更大。消融实验也在 AutoForge 的每个组件上执行，发现：

交错思考尽管增加了代理消耗的上下文量，但仍能明显提升代理能力；见上文。
在评估期间使用更强的模拟用户代理（例如使用 GPT-5 模拟用户而不是 GPT-4.1）有利于性能。
错误用户屏蔽是有帮助的，当允许不正确的用户行为时观察到性能下降。
使用环境级优势估计对于保持智能体 RL 训练稳定至关重要。

2.6 RAGEN：通过多轮强化学习理解 LLM 代理中的自我进化 [7]

（来自 [7]）

同样，[7] 中的作者专注于使用基于规则的 RL（即可验证奖励）来训练可以解决困难多步任务的交互代理。代理的这个学习过程在 [7] 中被称为"自我进化"，因为代理在 RL 期间从其自己的输出和相应的环境奖励中学习。正如我们已经了解到的，执行多轮 RL 时会出现几个困难，例如跨环境泛化不足或一般训练不稳定。在 [7] 中，作者提出了 RAGEN，这是一个支持新环境模块化的智能体 RL 训练框架。他们还引入了状态-思考-动作-奖励策略优化（StarPO），这是一种专门为训练交互代理设计的轨迹级学习算法。

"与将每个动作独立对待的先前静态任务方法不同，StarPO 将整个轨迹——包括观察、推理轨迹、动作和反馈——视为用于 rollout 和模型优化的一致单元。" - 来自 [7]

StarPO 通过将代理的整个轨迹视为一致的单元进行优化，超越了单轮 RL 技术。生成 rollout 时，代理在智能体循环中运行。在每一步，代理生成结构化输出，包含文本推理轨迹和一个或多个环境可执行动作（即工具调用）。在 [7] 中，我们特别考虑训练基于推理的代理，生成如下所示的推理引导的结构化输出。

推理代理的动作包括思考和输出（来自 [7]）

每一步之后，环境更新，代理接收可选的中间奖励。例如，[7] 中的代理因格式错误的输出而接收负奖励。代理最终达到终止状态，由于停止条件或达到最大允许轮次，此时 rollout 终止，我们计算最终的可验证奖励。此过程的结果是代理产生的状态和动作轨迹，以及在整个 rollout 中获得的累积奖励。

（来自 [7]）

按照标准实践，[7] 中的目标是最大化累积奖励，但此目标是在整个多轮轨迹上优化的；见上文。与 [6] 类似，StarPO 也在轨迹中保留中间推理轨迹，但作者没有从目标中屏蔽环境 token，这与我们见过的其他方法有显著区别。然而，在附录中，测试了响应掩码并发现是有益的。在 [7] 中，StarPO 被框定为高级优化方法，而不是特定算法——训练过程可以用任何 RL 优化器（例如 PPO 或 GRPO）实现。

实验结果。 StarPO 在 [7] 中通过在 RAGEN 框架内实现进行实际分析，RAGEN 是一个 LLM 代理训练系统，在具有任意奖励函数的多轮随机环境中提供模块化和可扩展支持以生成结构化 rollout。基于 Qwen-2.5 模型的代理在各种环境中训练，包括三个允许针对性分析的受控符号环境和一个真实环境——WebShop 基准，测试网页导航能力。向 StarPO 目标添加了熵奖励，所有领域都采用可验证的结果奖励，并使用 PPO 和 GRPO 执行实验。

（来自 [7]）

从 [7] 的实验中，作者发现了一种新颖的不稳定模式，称为回声陷阱（echo trap），在智能体 RL 中经常观察到；见上文。当代理在 RL 训练期间过度拟合其自己生成的推理模式时，会出现此问题，导致行为塌缩，破坏训练稳定性。回声陷阱的常见迹象（如下图所示）包括：

训练奖励的平台期或下降。
组内奖励可变性和 token 级输出熵的急剧减少，表明代理中的行为塌缩。
与严重——且通常不可逆的——训练不稳定的梯度范数激增。

"早期阶段的轨迹展示了关于符号含义和预期奖励的多样化推理，而后期阶段的响应变得重复和确定性。这表明 RL 训练可能过度放大了固有的推理捷径，在抑制探索的同时强化了局部奖励的模板。我们将这种失败模式称为 Echo Trap……其中模型在自生成轨迹上训练时重复重用记忆的推理路径，导致多样性塌缩和长期性能下降。" - 来自 [7]

（来自 [7]）

[7] 中提出了几种干预措施来鼓励行为多样性和探索，从而避免回声陷阱并提高稳定性。这些更改形成了 StarPO-S，StarPO 的稳定变体。首先，通过从 RL 目标中移除 KL 散度正则化项来鼓励探索。还使用了 DAPO 中的 Clip-Higher 方法来防止熵塌缩。

更进一步，提出了一种离线数据过滤方法，选择结果不确定性最高的训练任务——[7] 中的作者认为这些任务提供最有信息量的训练信号。具体来说，我们测量所有训练任务的奖励标准差，并按标准差降序选择任务用于训练。此选择过程允许代理从高方差任务中学习，而不是强化确定性行为。如下所示，这些更改延迟了塌缩并提升了代理性能。

（来自 [7]）

[7] 中训练的代理行为被深入分析，得出以下发现：

增加每个训练批次中的多样性（即采样更多任务并为每个任务使用略少的 rollout）有利于泛化。
更大的交互预算允许代理在解决任务时使用更多步骤，并被证明有利于整体代理性能，特别是在需要规划的复杂环境中。然而，如果预算增加太多，性能会下降——适度的交互预算最好。
在线 RL 产生最佳性能，而在陈旧 rollout 上训练（即通过 5 或 10 个训练步骤）会持续降低性能。
显式推理在某些设置中改进了泛化，但在其他设置中收益好坏参半。有趣的是，推理轨迹往往在整个训练过程中缩短，表明仅轨迹级结果奖励不足以鼓励代理在长交互中保留有用的推理。

"我们发现即使熵稳定，模型也可能依赖于看似多样但与输入无关的固定模板。我们称之为模板塌缩……为了诊断这种失败，我们将推理质量分解为输入内多样性（熵）和跨输入可区分性（互信息），并引入一系列互信息代理用于在线诊断。" - 来自 [8]

RAGEN-2。 扩展 [7] 中的分析，作者在 [8] 中发现了另一种形式的 RL 不稳定，称为模板塌缩；见下文。我们可以持续监控 RL 中的多样性指标，但大多数捕获多样性的常见指标（例如 token 级熵）仅测量相同输入内的多样性。模型可能在每个输入内保持高熵，同时仍然产生与输入无关的输出。为了超越输入内多样性，我们必须跨输入计算互信息以捕获代理推理的深度。

（来自 [8]）

在 [8] 中，作者认为我们应该将总多样性分解为熵——特定提示的推理有多多样——和互信息——推理根据提示变化多少——的组合。大多数现有方法（例如 RL 的熵奖励）仅针对熵，因此导致模板塌缩。[8] 中提出了几种不同的互信息代理，发现它们与最终性能的相关性比熵更强；见下文。

（来自 [8]）

有趣的是，[8] 中用于在训练期间改进多样性指标的方法与 [7] 中提出的主动学习方法有些相似。作者分析了 RL 更新中的信噪比（SNR），表明更新中的信号与每个任务的奖励方差相关。因此，我们可以通过以下方式选择具有最大信号的任务：

为批次中的每个任务采样多个轨迹。
计算每个任务组的奖励方差。
按方差对任务排名，仅保留方差质量最高的任务（即根据预定义的保留率 p = 0.9）。

下图描绘了 [8] 中用于 RL 的这种动态 SNR 过滤方法。通过删除低信号提示对策略梯度的贡献，我们可以避免模板塌缩，从而提高智能体 RL 训练过程的整体性能、泛化性、效率和稳定性。

（来自 [8]）

3、关键要点

我们研究了大量关于使用 RL 训练代理的论文。虽然这些论文在环境、优化器和实验设置方面有所不同，但一些共同的想法和模式贯穿其中。通过研究这些趋势，我们可以得出一套实用的设计原则，用于构建模块化、可扩展、稳定且能够改进代理行为的智能体 RL 系统。

模块化接口。 我们见过的大多数框架都建立在工具和环境的模块化抽象之上：

AgentGym-RL [3] 使用统一的 HTTP 接口。
Agent-R1 [4] 定义了 Tool 和 ToolEnv 抽象。
AgentRL [5] 暴露基于函数调用的环境 API。

通过使用模块化设计，我们可以轻松添加新任务、交换环境或测试不同的优化器。通过这种方式，我们的智能体 RL 基础设施可以扩展到手动定义的任务之外，以捕获任意训练环境。

轨迹结构。 智能体 RL 要求我们处理包含指令、生成的 token、工具调用、观察、奖励和环境状态的多轮轨迹。与单轮 RL 设置相比，表示如此复杂的轨迹更复杂。因此，智能体 RL 框架超越了将 rollout 表示为扁平 token 序列的方式。例如，Agent-R1 [4] 存储结构化的步骤级轨迹，保留步骤边界并存储确切的 token 以避免重标记漂移。轨迹的格式很重要，因为它决定了上下文的构建方式和奖励的分配方式。

动作掩码。 大多数智能体 RL 论文修改 RL 目标，使得只有代理生成的 token 对策略梯度有贡献。这种动作掩码是我们见过的论文中最一致的共享实现细节之一，并被证明可以提高代理性能。然而，最近的工作发现，完全将非代理生成的 token 排除在目标之外可能不是最优的。具体来说，我们可以通过以下方式进一步提高性能：

对代理生成的 token 应用 RL 目标。
对环境生成的 token 应用 SFT 目标。

直观上，这种方法可以看作通过 RL 学习行动，同时通过 SFT 从提供的环境反馈中学习世界模型。更多细节，请参阅最近发表在该主题上的论文，如 Echo 和 PaW。

过程奖励。 大多数关于 LLM RL 训练的近期工作严重依赖结果奖励，智能体 RL 也是如此——特别是当任务具有可验证的成功标准时。然而，长时程任务通常受益于更丰富的信用分配机制。因此，一些智能体 RL 论文在训练中支持中间过程奖励 [3, 4, 7]。然而，包含过程奖励并不总是产生明确的收益；例如，ToRL [1] 在添加不可执行代码的惩罚时观察到性能下降。

优势归一化。 在 vanilla GRPO 中，通过将补全的奖励相对于为相同提示采样的其他补全进行归一化来估计优势。一些智能体 RL 论文使用修改后优势估计技术，在更广泛的组上归一化——特别是批次中来自相同领域或环境的所有轨迹。AgentRL [5] 使用任务级优势归一化，跨整个任务或领域归一化 token 级优势。类似地，AutoForge [6] 提出 ERPO，它在环境中所有有效轨迹上计算 GRPO 中的优势缩放项。这些方法以略有不同的方式归一化，但基于相同的原理：我们跨整个任务或环境归一化优势，以确保多任务训练稳定，并且没有单个任务主导策略更新。

可扩展的 Rollout。 智能体 RL 既是算法问题也是系统问题。Rollout 的长度和完成时间可能具有高方差，这取决于代理运行的环境。因此，大多数智能体 RL 框架使用异步 rollout 生成和分离式架构，为训练和推理提供专用资源。此外，环境被容器化并以可扩展的方式托管（例如使用 Kubernetes），以便环境执行不会成为瓶颈。

稳定性和探索。 在长时间跨度上训练代理引入了在单轮 RL 中不太突出的新失败模式：

由于代理的大动作空间导致的熵塌缩。
多任务训练设置中的不稳定。
异步训练引入的陈旧或 off-policy 数据。
回声陷阱和模板塌缩。

我们见过的论文提出了各种方法来解决这些问题。例如，AgentRL [5] 探索了跨策略采样、任务级优势归一化和异步 RL 的陈旧性控制等技术来解决这些问题。类似地，AutoForge [6] 使用修改后的优势归一化，而 RAGEN [7] 和 RAGEN-2 [8] 通过更好的数据过滤解决不稳定问题。

任务选择和课程。 当数据分布受到仔细控制，向代理暴露多样化且当前可学习的任务时，训练过程效果最好。数据可以选择、合成、过滤，甚至通过课程随时间安排。ScalingInter-RL [3] 在整个训练过程中增加交互预算，以便代理可以逐步学习如何解决长时程任务，而 RAGEN [7, 8] 优先考虑高方差或高信号的任务，以避免强化代理内的确定性行为。为了缓解数据收集瓶颈，AutoForge [6] 从工具文档为智能体 RL 训练合成真实且可验证的环境。

原文链接: Agentic RL: Frameworks and Best Practices

汇智网翻译整理，转载请标明出处