ProRL Agent：用于多轮 LLM Agent 强化学习训练的 Rollout-as-a-Service 框架 ProRL Agent: Rollout-as-a-Service for RL Training of Multi-Turn LLM Agents
将多轮 Agent rollout 解耦为独立 HTTP 服务，提升 RL 训练的可扩展性和可维护性
前置知识
Rollout
Rollout 指智能体在环境中按策略执行动作并收集轨迹的过程。对于多轮 LLM Agent，Rollout 涉及几十轮对话和工具调用，可能产生数万个 token 的长轨迹。每次 Rollout 需创建沙箱环境、执行代码、运行测试。
本文核心围绕 Rollout 生成和管理展开，理解其复杂性和资源需求是把握 ProRL Agent 设计理念的基础。
PPO 和 DAPO
PPO 通过限制策略更新幅度保证训练稳定性。DAPO 引入动态采样，过滤掉方差为零的 Prompt（所有 rollout 都正确或都错误的实例）。DAPO 的 KL 系数为 $1 \times 10^{-4}$，学习率 $1 \times 10^{-6}$。
ProRL Agent 集成了高效 DAPO 实现，理解该算法有助于理解论文中的实验设计和优化重点。
Sandbox 环境
Sandbox 是 Agent 执行工具调用的隔离环境。在 HPC 集群中，Docker 需要 root 权限通常不可用。Singularity 不需要守护进程且支持无 root 运行。ProRL Agent 为每个容器分配唯一 loopback IP。
支持 rootless HPC 部署是 ProRL Agent 的核心创新之一，这是现有框架普遍缺失的能力。
Min-heap 负载均衡
Min-heap 是一种二叉堆，可高效获取最小元素。ProRL Agent 用它管理 LLM 后端池，每个后端维护计数器 $w_s$。每次选择计数器最小的后端 $s^* = \arg\min_s w_s$。同一任务路由到同一后端以最大化前缀缓存复用。
这是 ProRL Agent Server 的核心优化之一，直接影响推理效率和资源利用率。
研究动机
现有的多轮 Agent RL 训练框架存在根本性的架构缺陷：它们将 rollout 编排紧耦合在 RL 训练循环内部。这种设计导致两个严重问题。首先是资源冲突：rollout 是 I/O 密集型工作，需要创建沙箱、维护长生命周期的工具会话、协调数百个并发实例；而训练是 GPU 密集型工作，核心是前向和反向传播以及梯度同步。将这两类截然不同的工作负载耦合在一起会导致相互干扰，降低整体资源效率。其次是难以迁移和维护：当需要切换训练后端时，往往需要重新实现整个 Agent 执行流水线；同样地，改进 rollout 基础设施（如支持新的运行时环境或任务）也需要修改训练代码库。这种紧耦合使得在 rollout 和训练任一侧的独立实验和优化都变得困难。论文中对比了 SkyRL-Agent、VeRL-Tool、Agent Lightning、rLLM、GEM 等框架，它们都将 rollout 嵌入训练器内部。
本文的目标是本文的目标是构建一个可扩展的基础设施，将完整的多轮 Agent rollout 生命周期通过 API 服务的方式提供。ProRL Agent 旨在解决现有框架的耦合问题，使 rollout 和训练可以在不同机器上独立运行，实现 I/O 密集型执行与 GPU 密集型优化的分离。同时，它需要支持灵活的沙箱环境以容纳多样化的工具和任务，并且能够在无 root 权限的共享 HPC 集群环境中部署。具体的技术目标包括：提供标准化的三阶段异步流水线（INIT → RUN → EVAL），每个阶段有独立的 worker 池以实现流水线并行；实现 token-in/token-out 通信以避免重新分词漂移；支持 LLM 后端的动态注册和负载均衡；提供任务取消和故障隔离机制。最终，ProRL Agent 要能够与多种训练框架（如 VeRL 和 NeMo RL）无缝集成，实现端到端的 Agent RL 训练。
与已有工作不同的是，本文的独特切入点是将 inference-as-a-service 的设计理念引入到 Agent RL 训练中，提出 rollout-as-a-service 的核心原则。这不是简单的工程重构，而是从根本上重新思考了训练和 rollout 的关系。与现有框架相比，ProRL Agent 识别出 rollout 和训练具有根本不同的资源特性和操作特性，应该被设计为独立的服务。论文通过对比表格清晰地展示了 ProRL Agent 的独特性：它是唯一同时支持训练-rollout 解耦、rootless 沙箱和训练框架无关的框架。这种解耦设计不仅仅是架构上的改进，它带来了实际的性能优势。例如，在 SWE-Bench Verified 上，ProRL Agent-8B 相比 SkyRL-Agent-8B-v0 实现了接近 2 倍的性能提升（从 9.4% 到 18.0%），在 4B 和 14B 规模上也分别获得了显著的增益。
核心方法
ProRL Agent 的整体架构包含三个核心组件：可扩展沙箱环境、ProRL Agent Server 和 RL 训练器。直觉上，这就像将工厂的装配线与最终产品质检分离一样——rollout 负责在沙箱环境中执行 Agent、收集轨迹、计算奖励，而训练器专注于策略优化。技术上，ProRL Agent Server 作为一个独立的 HTTP 服务运行，接受任务实例，内部执行完整的 Agent rollout，然后返回完成的轨迹和奖励信号。训练框架只通过 HTTP 接口与服务器交互，对 RL 基础设施完全透明。这种解耦设计带来了三个实际好处：rollout 节点和训练节点可以独立开发和部署以最大化吞吐量；添加新任务只需要在 rollout 服务器端实现 handler 插件，无需修改训练代码；Agent 脚手架可以修改或替换而不影响训练基础设施。服务器内部采用三阶段异步流水线，每个阶段有独立的队列和 worker 池，允许多个 job 在不同阶段同时进行，就像工厂的多工位流水线一样。
ProRL Agent 的核心创新是 rollout-as-a-service 设计原则，将完整 Agent rollout 生命周期与 RL 训练栈解耦。通过统一 HTTP 接口，训练器只需提交任务并接收结果，无需管理任何 rollout 生命周期细节。与现有框架将 rollout 控制嵌入训练驱动器不同，ProRL Agent 将其作为独立服务。这种解耦允许 I/O 密集型执行与 GPU 密集型优化在不同机器上运行，还提高了可扩展性和可维护性。另一个关键创新是 token-in/token-out 通信机制，使用 token ID 作为整个训练过程中的标准表示，避免了重新分词导致的漂移问题。
方法步骤详情
ProRL Agent 的工作流程分为三个阶段。首先是 INIT 阶段：服务器接收任务后根据类型查找对应的 AgentHandler，调用 init 方法准备沙箱环境并配置工具集。每个容器作为子进程启动，通过 SIGTERM 优雅关闭。容器实例分配唯一 loopback IP 地址避免端口冲突。接下来是 RUN 阶段：run 方法驱动 Agent 循环，收集动作-观察轨迹。优化包括用 ptyprocess 替代 tmux 减少 shell 命令延迟、IPython 内核进程内 API 连接避免网络往返、Unix domain sockets 替代 TCP loopback 减少 IPC 开销。最后是 EVAL 阶段：eval 方法将输出与真实答案比较返回奖励。服务器通过 HTTP API 管理任务和 LLM 后端。
技术新颖性
ProRL Agent 有多个技术新颖性贡献。首先是三阶段异步流水线设计，将 rollout 分解为 INIT、RUN、EVAL 三个独立阶段，每个阶段有独立队列和 worker 池。这避免了单 worker 顺序执行导致的资源浪费——容器启动慢、Agent 执行快但大量 LLM 调用、评估时间差异大。流水线允许三个池同时处理不同 job，池大小也可独立调整。其次是 min-heap 负载均衡策略，用简单计数器实现任务级路由一致性和池级负载均衡，无需复杂协调。第三是高效 DAPO 实现，通过异步补充机制解决 naive 批次实现的 worker 空闲和数据浪费问题。
实验结果
ProRL Agent 在多个任务域上取得显著性能提升。在 SWE-Gym 的 293 实例子集上，ProRL Agent 在所有模型尺寸上持续改进性能。Qwen3-4B-Instruct-2507 基线 14.8%，ProRL Agent-4B (RL) 达到 21.2%；Qwen3-8B 基线 9.6%，ProRL Agent-8B (RL) 达到 18.0%，相比 SkyRL-Agent-8B-v0 的 9.4% 实现近 2 倍提升；Qwen3-14B 基线 15.4%，ProRL Agent-14B (RL) 达到 23.6%。在 STEM Agent 上，平均奖励从约 0.2 增加到约 0.65。Math Agent 的 AMC Pass@1 从 0.4 增加到约 0.9。Code Agent 的 Codeforces Pass@1 从 0.23 改善到约 0.42。系统分析显示 rollout 吞吐量随计算节点数接近线性增长。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SWE-Bench Verified | Resolved % | 21.2% (4B), 18.0% (8B), 23.6% (14B) | 14.8% (4B base), 9.6% (8B base), 15.4% (14B base); SkyRL-Agent: 9.4% (8B), 21.6% (14B) | +6.4% (4B vs base), +8.4% (8B vs base), +8.2% (14B vs base); +8.6% (8B vs SkyRL), +2.0% (14B vs SkyRL) |
| AMC (Math) | Pass@1 | ~0.9 (after 60 steps) | ~0.4 (initial) | +0.5 (+125%) |
| Codeforces (Code) | Pass@1 | ~0.42 (after 60 steps) | ~0.23 (initial) | +0.19 (+83%) |
| STEM QA | Mean Reward | ~0.65 (after 60 steps) | ~0.2 (initial) | +0.45 (+225%) |
局限与改进
作者承认了一些局限性，并在结论中指出将更丰富的环境和改进的集群级鲁棒性留给未来工作。我观察到一些额外的局限性。首先是任务覆盖范围：虽然论文验证了软件工程、数学、STEM 和编码任务，但其他重要领域如多模态 Agent、计算机使用、Web 浏览等尚未被充分评估。其次是沙箱环境的复杂性：虽然 SingularityRuntime 提供了 rootless 部署，但它依赖于 Singularity 容器格式，这可能限制了一些任务环境的可移植性。对于需要 GUI 的任务，需要 QEMU 虚拟机，这会增加额外的开销和复杂性。第三是 LLM 后端管理的简化：min-heap 负载均衡虽然简单有效，但它不考虑后端的实际负载或延迟，在异构硬件环境或后端性能差异较大的情况下可能不是最优策略。第四是 DAPO 实现的假设：DAPO 过滤掉方差为零的实例假设这些实例不提供梯度信号，但在某些情况下，这些实例可能包含有价值的信息。
独立分析的弱点
ProRL Agent 存在一些可改进的弱点。首先，LLM 后端管理的 min-heap 策略过于简化。它只根据任务计数分配，不考虑后端的实际负载或延迟。在生产环境中，LLM 后端可能运行在不同规格 GPU 上或受其他工作干扰，简单计数策略可能导致负载不均。改进方向是引入更智能的调度策略，如基于队列长度和预估延迟的加权选择，或使用反馈控制机制动态调整权重。其次，工具后端优化仍有改进空间。Bash 执行用 ptyprocess 替代 tmux 减少了延迟，但仍有进程启动开销。对于频繁 shell 命令，可考虑持久化 shell 会话池。第三，三阶段流水线阶段间切换有一定开销，特别是容器启动后立即进入 RUN 阶段如果失败需清理重新启动。
未来方向
作者指出将更丰富的环境和改进的集群级鲁棒性留给未来工作。基于 ProRL Agent 成果，可延伸多个研究方向。首先是支持更多样化的任务环境。当前主要集中在代码、数学和 STEM 任务，未来可扩展到多模态 Agent、计算机使用、Web 浏览、数据科学等领域。每个领域有独特工具和环境需求，需设计相应 AgentHandler 和沙箱配置。其次是改进集群级鲁棒性和可观测性。在大规模部署时，节点故障、网络分区、资源争用等问题更突出。未来可引入更完善的监控、日志和故障恢复机制。第三是探索更高效 RL 算法和训练策略，如支持 PPO、Rejection Sampling、DPO 等。第四是改进沙箱环境安全性和隔离性。
复现评估
ProRL Agent 是开源的，已作为 NVIDIA NeMo Gym 的一部分发布。论文中提供了详细的系统架构和算法描述，包括 AgentHandler 接口、三阶段流水线、LLM 后端管理、DAPO 实现等关键组件。实验设置也清晰描述：使用 DAPO 作为默认 RL 算法，批量大小为 32，小批量大小为 8，每个实例生成 8 个 rollout，KL 散度系数为 $1 \times 10^{-4}$，学习率为 $1 \times 10^{-6}$，所有 RL 训练在 32 个 NVIDIA H100 GPU 上进行。基准测试包括 SWE-Bench Verified（软件工程）、AMC（数学）、Codeforces（编码）和 SCP-116K（STEM），这些数据集都是公开可用的。然而，复现实验仍然需要相当的计算资源：32 个 H100 GPU 是不小的投资，而且大规模 rollout 需要大量的存储和网络带宽。另外，Singularity 容器的构建和部署也需要一定的 HPC 环境配置经验。总体来说，复现难度中等偏高，但对于有足够资源的实验室或公司是可行的。
论文图表