SkyRL：首个现实环境、长周期LLM Agent的端到端RL流水线框架

最新推荐文章于 2025-05-24 15:58:27 发布

大靠山

最新推荐文章于 2025-05-24 15:58:27 发布

阅读量575

点赞数 15

文章标签：人工智能前端服务器运维数据库

本文链接：https://blog.csdn.net/m0_59235245/article/details/148185696

版权

如今众多的AI Agent智能体正在超越静态基准，进入需要长期规划、多步骤工具使用和环境反馈的现实世界任务。此前大多数现有的RL强化学习框架都针对涉及短期无状态交互的任务进行了优化，例如搜索增强推理或简单的代码执行。相比之下，现实世界中的任务（例如 SWE-Bench 中所示的任务）则受益于在有状态的动态环境中进行长期规划。这给基础设施和训练算法都带来了新的挑战。

在这种背景下，为了有效地训练这些Agent，我们推出了SkyRL，这是我们针对Multi-Turn多轮工具使用 LLM 的 RL 训练流程，它针对 SWE-Bench 等长期真实环境任务进行了优化，建立在VeRL和OpenHands之上。使用 SkyRL，我们能够使用大约 300 个训练数据样本，在各个模型线上的SWE-Bench-Verified上取得令人满意的结果！

SkyRL-Agent-7B-v0：11.0% → 14.6%
SkyRL-Agent-8B-v0：3.6% → 9.4%
SkyRL-Agent-14B-v0：18.0% → 21.6%

图 1：SkyRL 构建于 VeRL 之上，继承了 VeRL 对学习算法的丰富支持。SkyRL 通过引入Agent层扩展了 VeRL，使其具备以下优势：(1) 高效的异步多轮Rollout；(2) 通用工具的使用；以及 (3) 通用且可扩展的环境执行。

概述

强化学习的最新进展使语言模型能够成为主动Agent。近期的开源框架，例如 Search-R1 和 ToRL（基于 VeRL 构建），在这方面取得了令人瞩目的进展，实现了多轮强化学习，并能够交叉使用单一工具（例如搜索或代码执行）。这些系统为工具增强推理奠定了重要的基础。然而，诸如 SWE-Bench、WebDev 和 Web 浏览等复杂的现实世界任务需要高级Agent能力，其中模型需要调用多个工具、编写和运行测试、响应环境反馈并执行长期规划。

图 2：使用 CodeAct Agent 解决 SWE-Bench 问题的示例工作流程。

虽然这些更先进的Agent智能体标志着令人兴奋的进化，但在它们上运行在线强化学习却极具挑战性。首先，高效的训练框架需要快速的环境执行和高效的环境交互Rollout。其次，高效的训练需要强大的长周期算法（这不是本文的重点）。总而言之，这使得问题比训练先前的工具增强推理法学硕士（LLM）复杂得多。

为了填补这一空白，我们推出了SkyRL——我们的强化学习训练流水线，用于在复杂环境中执行多轮工具使用LLM的长周期任务，包括SWE-Bench，它基于VeRL和OpenHands构建。

SkyRL 功能：

- 支持训练执行具有复杂环境交互的多步骤计划的LLM智能体。

- 通过异步并行Rollout操作，在轨迹上重叠计算密集型阶段和环境交互密集型阶段，实现更高吞吐量的生成（比基线实现加速 4-5 倍）。

- 预填充（并扩展）强化学习算法，方便快速启动。

在 v0 版本中，我们支持 SWE-Bench 的端到端在线强化学习训练流程。接下来计划支持其他长周期任务，例如 WebArena 和 WebDev。本文章的其余部分将讨论我们在基础设施方面面临的挑战和经验教训，以及我们的初步模型结果。

系统设计

在 SkyRL-v0 中，我们主要致力于解决环境扩展和低效Rollout阶段的挑战。我们集成了OpenHands项目中的CodeAct抽象作为****Agent循环部分，并采用远程沙盒服务器实现可扩展的环境Rollout。

挑战 1：环境扩展 - 远程沙盒服务器

在许多实际的Agent训练任务中，例如 SWE-Bench，每次Rollout都必须在隔离且有状态的环境中运行，通常通过 Docker 容器进行配置。这些环境通常都是资源密集型，每个环境消耗1 个以上的 CPU 和约 7GB 的存储空间。即使是中等配置（例如，批次大小为 16，Rollout 8 次）也可能需要 100 多个 CPU 和接近 1TB 的磁盘空间。

将环境执行与训练共置会导致隔离受限，并且扩展并行运行环境数量的灵活性不足，这可能导致LLM 推理引擎的请求速率不足，最终导致GPU 资源利用率低下。为了解决这个问题，我们实现了一个可扩展的远程沙盒服务器，将环境执行与训练分离。这种分离式设计支持独立扩展环境Worker，以保持较高的环境交互速率，从而确保在Rollout阶段实现较高的 GPU 利用率。

图 3：远程沙盒服务器的 Kubernetes Deployment。

我们将服务器部署在 Kubernetes 上，利用存储优化的实例来缓存容器镜像并实现快速启动。为了高效处理并发请求，我们利用aidocker和crun容器运行时，它提供轻量级且高性能的容器执行。我们的设置支持在 16 CPU 节点上每个副本运行大约 80-100 个容器，而不会遇到稳定性问题。虽然仍有很大的优化空间，但我们目前的实现简单、高效且公开可用。我们将服务器代码和Deployment配置开源，以支持有意自行托管强化学习训练所需的可扩展远程沙盒环境的研究人员。

挑战 2：费用昂贵的生成阶段

在基于Agent的强化学习训练中，Rollout阶段需要Agent与环境进行多轮交互。近期在多轮强化学习 (MDRL) 领域取得的进展，例如 RAGEN、Search-R1 和 ReTool，通常每个轨迹仅涉及有限数量的交互步骤。相比之下，像 SWE-bench 这样的任务通常需要 20 到 50 个轮次（甚至更多）才能让智能体使用 OpenHands 框架完成整个流程，这通常涉及识别相关文件、编写测试用例以重现问题、应用代码编辑以及通过测试验证修复。此外，每个步骤的环境执行时间在不同轨迹之间可能存在显著差异，具体取决于智能体操作的性质。例如，列出文件通常很快，而执行 Python 脚本进行单元测试则可能要耗费更多时间。

图 4 不同 rollout 实现方式的可视化。我们的异步 Rollout + 3 阶段生产者-消费者流水线有效加速了 rollout 的生成。

如图 4 上半部分所示，单轮强化学习中常见的 rollout 实现（例如 VeRL和 OpenRLHF对于Agent式推理工作负载而言效率低下。这种低效源于每个 LLM 生成步骤的同步障碍，而同步障碍是由于依赖离线批量生成造成的。因此，系统无法利用现代 LLM 服务引擎支持的连续批量优化，导致资源利用率低下和吞吐量降低。

为了解决这个问题，我们采用了两项优化措施，与原始基线实现相比，总共实现了4-5 倍的加速：

1. 异步****Rollout – 依赖现代 LLM 服务引擎（例如SGLang和 vLLM）的 async_generate 方法，每条轨迹可以独立推进，从而避开全局同步点，如上图 4 中间部分所示。

2.三阶段生产者-消费者流水线 – 此外，为了减少 GPU 空闲时间，我们可以将 (i) 运行时初始化（例如构建镜像、启动和连接容器）、(ii) 轨迹生成和 (iii) 奖励计算（例如发送补丁、运行测试）这几个阶段解耦并重叠，以最大化并行性和系统吞吐量，如上图 4 底部所示。

a. 我们通过三个队列实现此流水线：init queue、run queue 和 eval queue。每个阶段都充当下一个阶段的生产者：init queue从init_queue 中拉取数据，准备环境，然后推送至 run_queue；Agent Runner从 run_queue 中拉取已初始化的实例，执行多轮Rollout，并将完成的轨迹推送至 eval_queue；然后，eval queue从 eval_queue 中拉取数据来计算最终奖励。
b. 我们使用 asyncio 任务，并根据队列占用情况和剩余工作动态生成任务。每个任务都异步地将其结果推送至下一阶段，使用有Bounded的队列可以提供自然的反压机制（back-pressure），防止过载并确保跨阶段的负载平衡。这种流水线执行通过将计算和环境交互密集型阶段重叠在许多轨迹上，显著提高了系统吞吐量。

早期训练探索

我们采用Openhands中的CodeAct 框架和OpenHands 脚手架来生成 rollout，并利用基于规则的奖励来执行策略更新。

Rollout 生成

我们利用 OpenHands 脚手架在软件工程任务环境中迭代地提示模型。在每个回合中，模型都会编写代码并执行函数调用作为操作。该模型提供三种类型的操作：(1) execute_bash：在终端中执行 bash 命令；(2) finish：在任务完成或助手无法继续执行任务时结束交互；(3) str_replace_editor：用于查看、创建和编辑文件的自定义编辑工具。

具体来说，Rollout操作通过以下流程生成：

Input: Model M, Environment E, Task description P, a set of available actions A. # OpenHands manage the history of interaction, # initialized with the task description.history = P 
while not done:    # The CodeAct framework prompt the model with the history and     # the available tool. The model generates an action in the form    # of execuatble code, e.g., view_file(file_path).    action = M(history, A)    # The action is then sent to the environment for execution    # and gets an environment observation.    # e.g. the content of a view_file action.    # The loop terminates if the action is a termination action.     done, observation = E(action)    # OpenHands then tracks the history by appending the action    # and the observation in this turn.    history.append(action)    history.append(observation)
# Returns a git patch written by the model in the history of interactionpatch = E.get_patch()return patch

奖励设计

我们使用一种简单的基于结果的奖励机制。在Agent完成交互后，我们会从环境中获取 Git 补丁。然后，我们将该补丁应用到原始代码库，并针对目标 GitHub 问题运行测试套件。如果测试通过且问题得到解决，我们将奖励 1；否则，奖励为 0。尽管简单，但这种信号有效地指导了模型，从而提高了问题解决率（参见结果部分）。我们还跟踪了两种常见的故障模式：

- 陷入循环：模型连续三轮重复相同的操作。

- 未完成操作：模型未能在规定的轮次预算内输出完成操作。

我们的实验表明，这种奖励方案可以减少循环并鼓励及时完成。我们目前正在探索更丰富的多轮强化学习奖励设计。

数据选择

我们从SWE-Gym中选择问题，该数据集包含 2,438 个真实的 Python 任务实例。然而，这些任务极具挑战性——即使是 GPT-4o 的成功率也只有 4.55% 到 9.13%（详情请参阅 SWE-Gym 论文中的表 10）。因此，性能较弱的模型（例如 70 亿规模的模型）通常无法完成一次成功的Rollout，导致在 GRPO 和 PPO 等算法下没有学习信号，训练崩溃。为了缓解这个问题，我们构建了三个经过筛选的数据子集，并以模型生成成功率作为选择标准：

方案与结果

在此版本中，我们开源了三个不同规模、使用不同算法训练的模型，以满足社区的需求：

SkyRL-Agent-7B-v0（基于 OpenHands-7B-Agent 训练，基础模型 Qwen2.5-Coder-7B-Instruct）、
SkyRL-Agent-8B-v0（基于 Qwen3-8B 训练，非推理模式）
SkyRL-Agent-14B-v0（基于 Qwen3-14B 训练，推理模式）。

评估设置

我们使用 OpenHands 脚手架和 CodeAct Agent 评估我们的模型，并使用相同的操作集：bash_execute、finish 和 str_replace_editor。我们在 SWE-Bench Verified 基准上进行评估，最大轮次预算为 50，最大序列长度为 32k。评估说明可在以下位置找到：

[SkyRL-OpenHands](https://github.com/NovaSky-AI/SkyGym-OpenHands/tree/main/evaluation/benchmarks/swe_bench)

- SkyRL-Agent-7B-v0

SkyRL-Agent-7B-v0基于OpenHands-7B-Agent模型进行训练，该模型是 Qwen2.5-Coder-Instruct模型的监督微调版本。我们采用基于结果的强化学习，分两阶段进行训练，批次大小为 16，每个实例 8 次 rollout。训练时，学习率为 1e-6，KL 系数为 1e-3，rollout 温度为 0.5，最大轮次为 25 次，并采用 GRPO 算法。

- 使用 SkyRL-v0-80-data 进行 15 步训练（3 个 epoch，在 8xH100 GPU 上耗时 7 小时）

- 使用 SkyRL-v0-220-data 进行 15 步训练（1 个 epoch，在 8xH100 GPU 上耗时 8.5 小时）

我们按照 SWE-Gym 论文中的建议，将训练温度设为 0，并与基线一起对模型进行了测量。我们发现，在 8xH100 GPU 上训练 15.5 小时后。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了 3.6%。

- SkyRL-Agent-8B-v0（非思考模式）

SkyRL-Agent-8B-v0 在 Qwen3-8B 上进行训练，未启用思考模式（通过在apply_chat_template 中设置 enable_thinking=False）。我们使用一个基于结果的强化学习阶段进行训练，批次大小为 32，每个实例的 rollout 数量为 8。训练时学习率为 1e-6，KL 系数为 1e-3，rollout 温度为 0.6。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了5.8%。

- 使用 SWEGym-293-data 进行 47 步训练（4.7 个 epoch，在 8xH200 上训练 27 小时）。

- SkyRL-Agent-14B-v0（思考模式）

使用思考模式进行多轮训练很容易超出上下文长度，尤其是对于较小的模型，它们更容易陷入推理阶段。因此，对于思考模式，我们尝试使用 Qwen3-14B作为基础模型。

SkyRL-Agent-14B-v0 在 Qwen3-14B的基础上使用 PPO 进行训练。我们采用基于结果的强化学习进行单阶段训练，批次大小为 32，每个实例的 rollout 为 8。我们训练时，学习率为 1e-6，KL 系数为 1e-3，rollout 温度为 0.6，裁剪提升率 (clip higher ratio) 为 0.28，以鼓励探索。我们使用Qwen3-14B本身作为基础评价模型。该模型在 SWE-Bench-Verified 数据集上解决的问题数量提高了3.1%

- 使用 SkyRL-v0-293-data 进行 25 步训练（2.7 个 epoch，在 8xH200 GPU 上耗时 20 小时）。

如何学习大模型 AI ？

由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。

但是具体到个人，只能说是：

“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。

这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。

我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。

我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。

在这里插入图片描述