DeepSWE:纯强化学习训练开源代码智能体

Agentica 团队与 Together AI 合作推出了 DeepSWE-Preview,这是一个基于 Qwen3-32B 模型、仅通过强化学习(RL)训练而成的推理型代码智能体。它在 SWE-Bench-Verified 基准测试中实现了 59% 的准确率(测试时扩展后),达到了开源权重代码智能体的最高水平(Pass@1 42.2%,Pass@16 71.0%)。
DeepSWE 使用 Agentica 的 rLLM 框架进行训练,这是一个用于后训练语言智能体的执行框架(Harness)。我们开源了所有内容——数据集、代码、训练和评估日志,让每个人都能在强化学习扩展和改进智能体方面取得进展。
DeepSWE-Preview

图 1:LLM 智能体在 SWE-Bench-Verified 上的性能与模型大小对比。 通过仅用强化学习从头训练,DeepSWE-Preview 在测试时扩展(TTS)下解决了 59% 的问题,大幅领先所有开源智能体。我们注意到,DeepSWE-Preview 的 Pass@1 性能(42.2%,16 次运行平均)是开源权重代码智能体中最好的之一。

图 2:SWE-Bench-Hard 的验证分数, 智能体提交最终答案并通过所有测试时获得正奖励。仅经过 200 步强化学习训练,SWE-Bench-Verified 的 Pass@1 分数从 23% 提升到 42%(+20%)。
最近几个月,使用强化学习训练基于推理的大语言模型(LLMs)取得了巨大进展,包括我们之前的工作 DeepScaleR [1] 和 DeepCoder [2]。然而,将基于强化学习的推理模型扩展到长视野、多步骤、智能体任务仍然是一个具有挑战性的开放问题。
自主软件工程(SWE)——涉及解决 GitHub 问题、实现新代码功能和调试等复杂任务的领域——是这种具有挑战性的多步骤场景的一个突出例子。现实世界的软件工程提出了独特而困难的需求,要求智能体能够导航广泛的代码库、理解文件交互、应用有针对性的代码编辑、运行 shell 命令进行构建和测试,并在解决实际拉取请求时迭代改进和验证解决方案。
在这篇博客中,我们完全公开了将 32B 模型开发成智能代码智能体的训练方法。我们介绍了 DeepSWE-Preview,这是一个最先进的开源代码智能体,完全从头开始,基于 Qwen/Qwen3-32B 仅使用强化学习训练。在 64 个 H100 GPU 上训练了六天,使用了来自 R2E-Gym 训练环境 [3] 的 4,500 个真实世界 SWE 任务,我们的模型在具有挑战性的 SWE-Bench-Verified 基准测试中达到了开源/开源权重模型的最高性能。
DeepSWE 使用 rLLM 训练,这是 Agentica 用于后训练语言智能体的框架。查看 rLLM 的博客文章 了解更多。
1. 背景
LLM 智能体

图 3: LLM 智能体生成由思维引导的动作,以函数或工具调用的形式与环境交互,环境返回下一个观察和奖励。随着时间的推移,LLM 智能体积累了一个轨迹,即观察、动作和奖励的累积序列。
在强化学习(RL)中,智能体是执行动作并从环境接收反馈(以新观察和奖励的形式)的自主实体。这样的环境多种多样,从简单的 Atari 游戏到更复杂的领域,包括机器人控制、代码库中的软件开发、数据库管理和蛋白质发现任务。
作为强化学习智能体的大语言模型(LLMs)与环境交互,由先前观察和动作构建的内部表示引导。利用这些表示,基于 LLM 的智能体调用外部工具或函数来执行环境中的特定动作。
软件工程(SWE)

图 4:SWE 智能体概述。 LLM 智能体配备标准 IDE 工具(例如 Bash 命令、文件搜索、文件查看器/编辑器)与模拟的软件工程环境交互,该环境包括终端和项目文件系统。
一般的软件工程任务——例如解决拉取请求——被表述为强化学习环境(图 3)。给定一个拉取请求,智能体导航一个基于计算机的环境,配备终端和包含相应代码库的文件系统。类似于人类开发者与 IDE(如 VSCode、Cursor、IntelliJ)交互的方式,智能体被提供一组工具,包括 bash 执行、搜索和文件查看器/编辑器。智能体还可能被赋予一个额外的完成工具,在它认为任务完成时调用。为了在强化学习中分配奖励,项目的自动化测试套件在 LLM 修改的代码上运行。所有测试成功执行产生正奖励(拉取请求解决),而测试失败则获得零奖励。
2. 训练方法 🍽️
我们的代码智能体 DeepSWE-Preview,以及之前的发布 DeepCoder-14B-Preview 和 DeepScaleR-1.5B-Preview,都是在 Agentica 的后训练系统 rLLM 上训练的。
2.1 - 使用 R2E-Gym 进行可扩展的数据集整理 🗄️
我们的数据集包含来自 R2E-Gym 子集的 4.5K 个问题。为了避免训练期间的数据污染,我们过滤掉了与 SWE-Bench-Verified 来自相同仓库的问题,例如 sympy。所有问题都映射到单独的 Docker 镜像。
2.2 - 环境 🌐
我们的环境包装了 R2E-Gym [3],这是一个用于可扩展整理高质量可执行 SWE 环境的现有 Gym 环境。
状态与动作
R2E-Gym 定义了一组四个工具作为动作空间的一部分。每个工具的输出(一个带有 stdout/stderr 的 Python 程序)代表返回的状态。更具体地说:
- 执行 Bash - 输出 LLM 生成的 bash 命令的 stdout 和 stderr。
- 搜索 - 搜索并返回 LLM 定义的查询在目录或单个文件中的所有出现。
- 文件编辑器 - 允许查看、创建、替换字符串、插入和撤销对特定文件的编辑。
- 完成/提交 - LLM 决定它已解决拉取请求,终止轨迹生成。
奖励
为了保持简单,我们的奖励函数采用稀疏的结果奖励模型(ORM):
- 1 - LLM 生成的补丁在时间限制内通过选定的一组测试(Pass2Pass 和 Fail2Pass)。为了加速训练,我们的最大时间限制是 5 分钟,而官方 SWE-Bench 评估是 30 分钟。
- 0 - 如果 LLM 的代码在至少一个测试用例上失败或超时,我们分配零奖励。
Kubernetes(可扩展智能体轨迹收集)
我们遇到的一个挑战是扩展 SWE-Bench 环境。在我们的最终训练运行中,每个强化学习迭代并行生成 512 个 Docker 容器(BS=64,8 次通过)。强化学习的苛刻要求,加上并行实验,在任何给定时间都会生成数千个容器,使 Docker 的 API 服务器过载,最终导致 Docker 守护进程(dockerd)崩溃。
为了消除这个瓶颈,我们将 Kubernetes 支持集成到 R2E-Gym 中,让编排器在节点池中调度容器。每个工作节点大约有 200 个 CPU 核心和超过 6 TB 的本地 NVMe SSD。我们预加载 SWE-bench 镜像,确保几乎所有层都从磁盘提供,以实现快速启动并避免从 Docker Hub 过度拉取。
集群可以扩展到超过 1000 个 CPU 核心,并依赖 Kubernetes 集群自动扩缩器自动添加或删除节点。当 Pod 在短时间内无法调度时,自动扩缩器会配置额外的工作节点;相反,它会删除大约二十分钟内未充分利用的节点。这种弹性设置让我们能够可靠地收集数百万条轨迹,同时保持计算成本与负载成比例。
2.3 - 通过规模化 RL 训练 SWE 智能体
将 GRPO 扩展到多轮交互
自 Deepseek-R1 以来,数学和代码推理作为单步 RL 环境,主要通过 GRPO 进行训练。根据先前的工作(如 RAGEN [7]、Verl [11]、ROLL [8]、ART [9]、Sky-RL [10]),将 GRPO 扩展到多轮或智能体(Agent)场景,需要在每条轨迹中屏蔽环境观察值,或者 ChatML 格式中的用户消息。
GRPO++:一个更稳定、性能更强的 GRPO

图 5:GRPO++ 与 GRPO 在 Frozenlake 环境上的平均训练奖励对比。 GRPO++ 学习速度更快,这得益于 clip high、无 KL 损失以及 leave one out 策略。
与我们在 DeepCoder 工作中提出的 GRPO+ 类似,我们改进了原始的 GRPO 算法,整合了来自 DAPO [12]、Dr. GRPO [13]、LOOP/RLOO [14] 的见解以及我们自己的创新,以实现稳定的训练和更好的性能,如图 4(应为图 5)在 FrozenLake 环境上的展示。我们最终融合的算法包括:
- Clip High (DAPO): 提高 GRPO/PPO 替代损失的上限,鼓励探索并稳定熵值。
- No KL Loss (DAPO): 消除 KL 损失,防止 LLM 被限制在原始 SFT 模型的信任区域内。
- No Reward Standard Deviation (Dr.GRPO): 移除奖励标准差,消除了 GRPO 损失中的难度偏差,确保难题和易题能被更好地区分。
- Length Normalization (Dr.GRPO): 将替代损失除以最大上下文长度,消除了 GRPO 中存在的长度偏差,这种偏差会增加错误响应的长度。
- Leave One Out (Loop/RLOO): 在优势估计中移除一个样本,可以在不引入偏差的情况下减少策略梯度的方差。
- Compact Filtering (Us): 受 DAPO 启发,我们对那些达到最大上下文长度、生成超时(20 分钟)或达到最大步数的轨迹进行损失屏蔽。下文将进一步描述。
- No Entropy Loss (Us): 熵损失会引入更高的不稳定性,并最终导致熵值呈指数级增长,从而使训练崩溃。只要基础模型的词元级熵值在 0.3-1 之间,就不需要熵损失。
Compact Filtering:扩展超长过滤
DAPO 引入了超长过滤(overlong filtering),即达到最大上下文的轨迹在损失计算中被有效屏蔽。对于多轮、智能体场景,轨迹会在超时(由于生成时间过长或环境执行超时)或达到最大环境步数时终止。自然地,我们引入了 紧凑过滤(compact filtering),它会屏蔽那些达到最大上下文、最大步数或超时的轨迹。

图 6:Qwen3-14B 模型在有/无紧凑过滤情况下的消融实验。

图 7:启用紧凑过滤的训练运行中,平均响应长度和环境步数的变化。
紧凑过滤对训练有益,原因有二:
- 防止或延迟训练期间的奖励崩溃(图 6)。LLM 智能体可能会偶然发现正确的补丁并通过所有测试,但自身并不知晓。用这些正向奖励进行训练,会强化跨步骤的不期望行为(例如,LLM 在前 10 步回答正确,但随后却随机修补文件),当此类行为累积时会导致崩溃。确保仅在 LLM 智能体明确提交时分配奖励,可以鼓励其进行严格的测试,从而使 LLM 对其最终提交更有信心。
- 减少每步的过度思考,鼓励跨步骤的长形式推理。图 7 说明了这一现象,训练期间平均响应长度下降,但平均环境步数增加,这表明平均每步的思考量急剧下降。
3 - 测试时扩展 📈

图 8:轨迹的测试时扩展(TTS)。 给定 N 条候选轨迹列表,目标是选择包含正确答案(对于编码任务,即正确的输出补丁)的轨迹。
现有的数学和代码推理模型通过扩展词元数量来扩展其测试时计算量和 Pass@1 性能。例如,我们之前的 DeepCoder-14B-Preview 模型通过将最大上下文长度从 32K 扩展到 64K 词元,将 LiveCodeBench 的 Pass@1 性能从 57.8% 提升到 60.6%。对于智能体,测试时性能也随着推理过程中计算的轨迹数量而扩展。在图 8 中,给定 N 条生成的轨迹,智能体必须识别出哪一条能正确解决任务。
在 免执行验证器(execution-free verifier) 方法中(例如 R2EGym [3]、Openhands Critic [4]、Skywork [6]),最佳轨迹由验证器 LLM 选择。通常,验证器 LLM 被训练来识别正确和错误的轨迹。值得注意的是,我们的免执行验证器 DeepSWE-Verifier 在正确/错误补丁上训练了 2 个轮次。相比之下,基于执行的验证器(execution-based verifier)(例如 R2EGym)使用另一个 LLM 生成多样化的测试和边界情况,最佳轨迹是通过最多测试的那条。最后,DeepSWE-Preview 的测试时扩展结合了这两种范式,采用 混合扩展(hybrid scaling)(参考我们最近的论文 R2E-Gym [3]),以实现显著更好的 Pass@1 性能。
下面我们评估 DeepSWE-Preview 在不同 TTS 策略下的表现:

图 9:SWE-Bench 性能随最大输出词元数的变化。 DeepSWE-Preview 在 128K 上下文下达到 43.2% 的 Pass@1。无论基线如何,性能随上下文长度的扩展效果都不佳。

图 10:SWE-Bench Verified 性能随不同 TTS 策略的变化。 采用混合 TTS,DeepSWE-Preview 达到 59%,比当前开源的 SOTA 模型(SkyWork + TTS,47%)高出 12%。我们注意到,仅使用基于执行的验证器和免执行验证器仍然有效,可以带来超过 10% 的性能提升。
随词元数量扩展。 在图 9 中,当最大上下文长度从 16K 扩展到 128K 词元时,DeepSWE-Preview 和其他基线的性能有所扩展。然而,超过 32K 上下文后的性能提升微乎其微(≤2%)。对于 SWE 相关任务,扩展输出词元数量似乎效果不佳。
随轨迹数量扩展。 图 10 展示了 DeepSWE-Preview 在不同 TTS 技术下的性能消融实验。Pass@K 指的是轨迹级 TTS 技术理论上能达到的最佳性能(100% 准确率)。值得注意的是,现有的 TTS 技术远未达到最优。然而,混合扩展的表现明显更好,DeepSWE-Preview 使用 K=16 条轨迹时达到 59.0%,优于基于执行的验证器和免执行验证器。
对于大多数实际场景,TTS 的大部分性能增益可以通过 K=8 条轨迹实现。
4 - 评估 📝
DeepSWE-Preview 通过官方的 R2E-Gym 代码库进行评估,最大上下文长度为 64k,最大环境步数为 100。然后,将 DeepSWE 生成的补丁移植到官方的 SWE-bench 仓库以计算最终得分。下面,我们报告了 16 次运行平均后的 Pass@1 准确率。

图 11:DeepSWE-Preview 与其他开源模型的完整评估。 DeepSWE-Preview 的 Pass@1 和 Pass@16 分别为 42.2% 和 71%。采用混合测试时扩展(TTS)后,DeepSWE-Preview 达到 59%。
| 模型 | 框架 | 类型 | SWE-Bench Verified (%) |
|---|---|---|---|
| DeepSWE-Preview (32B) | R2E-Gym | Agent + Hybrid Best@16 | 59% |
| DeepSWE-Preview (32B) | R2E-Gym | Agent + Hybrid Best@8 | 57.9% |
| DeepSWE-Preview (32B) | R2E-Gym | Agent | 42.2% |
| Devstral-Small (24B) | OpenHands | Agent | 46.6% |
| Openhands-LM (32B) | OpenHands | Agent (Iterative) | 37.2% |
| SWE-Agent-LM (32B) | SWE-Agent | Agent | 40.2% |
| R2EGym-Agent (32B) | R2E-Gym | Agent | 34.4% |
| Skywork-SWE (32B) | OpenHands | Agent | 38.0% |
| Skywork-SWE (32B) | OpenHands | Agent + Execution-Free Best@8 | 47.0% |
| SkyRL-Agent (14B) | OpenHands | Agent | 21.6% |
我们的 DeepSWE-Preview 模型在 SWE-Bench Verified 基准测试中达到了 42.2% 的 pass@1,这仅仅是在 Qwen/Qwen3-32B 模型之上进行强化学习(RL)的结果。值得注意的是,仅使用强化学习的训练,其性能就超过了各种先前的方法,这些方法利用了相似或更多的训练数据,以及从更强的专有教师模型 [3, 4, 5, 6] 进行的蒸馏或监督微调(SFT)。
5 - 分析涌现行为 🔎
有意思的是,我们发现,当使用纯 RL 配合 0/1 可验证奖励进行训练时,智能体自动学会了一些有趣的行为,帮助它更可靠地解决复杂的现实世界软件工程任务。接下来,我们通过一些实例来分析 DeepSWE-Preview 模型展现出的有趣涌现行为,更多例子见附录。
总是尝试思考边界情况和仓库回归测试
当前软件工程智能体面临的最具挑战性的问题之一是,它们或许能修复提出的 bug,但生成的补丁可能没有考虑边界情况,或者引入了破坏代码库现有功能的新 bug。令人惊讶的是,我们发现,在 RL 训练过程中,智能体学会了在尝试修复 bug 时自动思考边界情况(不同的输入、数据类型等)。此外,智能体似乎总是尝试在当前仓库中找到相关测试,以确保提议的更改不会破坏代码库上现有的回归测试。

图 12:边界情况的定性示例: DeepSWE-Preview 智能体在通过其复现测试后,会思考它是如何修复 bug 的 → 思考不同的边界情况 → 编写详细的脚本来测试不同的边界情况 → 最后尝试查找并运行回归测试,以确保修复没有破坏现有代码库功能。
根据步骤复杂度自适应使用更多思考 Token
与单步非智能体编码任务不同,多步软件工程任务的一个关键特征是,不同步骤的复杂度可能差异很大。例如,想象一下人类解决一个软件工程任务或 GitHub issue 的场景。他们可能会花更长时间思考根本原因以及如何修复 bug,而其他步骤,比如滚动浏览文件或运行现有脚本,可能只需要很少甚至不需要思考。
我们发现,随着 RL 训练的进行,DeepSWE-Preview 模型也出现了类似的行为。模型学会了在尝试定位和思考如何修复 bug 时分配大量思考 Token(单个步骤通常使用约 2K Token 进行思考)。然而,对于其他步骤,比如在文件中移动或在代码库中搜索术语,它使用的思考 Token 非常少(约 100-200 个)。

图 13:短思考的定性示例: DeepSWE-Preview 智能体学会了根据步骤复杂度分配思考 Token。例如,当它试图理解代码库时,会使用更多 Token;而对于低复杂度步骤(比如运行一个它之前编写的脚本),它学会了只使用少量 Token。
6 - 其他尝试过的实验 🔬
我们也分享一些在训练过程中尝试过但效果不佳的其他实验。虽然这些结果不一定代表否定性结论,但或许能为研究社区提供一些洞见,供其借鉴或进一步构建。
使用 Claude-Sonnet 3.7/4 进行 SFT,而非冷启动
我们尝试了在四种经过 SFT 的模型上进行 RL,即在 Qwen3-32B 基础上使用 Claude-Sonnet 3.7/4 的思考/非思考轨迹进行 SFT。在所有尝试中,模型性能在 100 次迭代后均未提升。我们经过 SFT 的模型性能略低于 SWE-agent-LM-32B。
不同的 RL 训练数据集和环境
除了 R2E-Gym,我们还尝试了在另外两个数据集上进行 RL——SWE-Smith [5] 和 SWE-Gym [6]。在我们的实验中,到目前为止,使用其他数据集观察到的性能提升有限,在训练过程中经常出现较高的 solve-none 率(在不同的 GRPO 尝试中)。总体而言,我们发现 R2E-Gym 最适合 RL 训练,因为它为智能体提供了足够的课程学习,使其能够随着时间的推移解决越来越困难的问题。
我们将为软件工程智能体进行可扩展 RL 的最优数据策展研究,留作未来令人兴奋的工作方向。
非思考模式
我们还尝试了在 Qwen3-32B 的非思考模式上进行 RL,观察到性能提升有限。然而,考虑到 Claude-4 的非思考模式和思考模式在 SWE-Bench-Verified 上取得了相似的性能,这可能只是一个模型容量问题。
7 - 未来工作
DeepSWE-Preview 标志着我们的第一步,证明了在 R2E-Gym 这样的高质量执行环境下,纯 RL 驱动的推理可以用于扩展长视野多步智能体。未来,我们计划探索一些非常令人兴奋的进一步研究方向,这些方向由于时间和资源限制我们尚未探索。
由于 DeepSWE-Preview 是从头开始训练的,类似于 DeepSeek-R1-Zero,我们计划在 DeepSWE-Preview 之上进一步训练另一个模型,类似于 DeepSeek-R1,此外还将训练具有更长上下文窗口的更大模型。最后,我们正在扩展到不同的智能体领域,例如网页智能体。
8 - 结论
我们很高兴发布 DeepSWE-Preview,这是一个完全通过强化学习(RL)从 Qwen3-32B 模型训练而来的编码智能体。它在 SWE-Bench-Verified 上实现了 59.2% 的 TTS 通过率(Pass@1 为 42.2%,Pass@16 为 71.0%)。
DeepSWE-Preview 由 rLLM 驱动,这是 Agentica 用于后训练语言智能体的开源框架。我们的使命是让 RL 在 LLM 领域民主化,DeepSWE-Preview 是我们最新的里程碑,建立在我们之前的数学和编码模型 DeepScaleR 和 DeepCoder 的基础之上。
为了加速社区进步,我们正在开源一切:数据集、训练代码与配方,以及评估日志。我们相信扩展智能体能力是一项集体事业。探索我们的工作,复现我们的结果,并帮助我们推动 RL 和智能体 AI 的前沿。
让我们一起构建未来。
主要个人贡献
这个项目是 Agentica 团队和 Together AI 之间美好合作的成果。以下是不同成员的贡献:
- Michael Luo - 训练了 DeepSWE RL 模型;为 R2E-Gym 开发了 Kubernetes 包装器;为 rLLM 实现了智能体/环境抽象,并优化了 rLLM 的性能。
- Naman Jain, Jaskirat Singh - 开发了 R2E-Gym 并对高质量 RL 数据集进行了广泛的数据过滤。设计了 DeepSWE 智能体脚手架;准备了 SFT 数据(思考/非思考),训练了 SFT 模型,并训练了验证器(混合型、免执行型和基于执行型)以进行有效的测试时扩展。
- Sijun Tan, Colin Cai - 设计并实现了用于训练 DeepSWE 的初始 rLLM 系统;共同开发了轨迹级和步骤级的 GRPO/PPO 算法;验证了 RL 训练循环并支持了早期智能体训练。
- Ameen Patel, Qingyang Wu, Alpay Ariyak (Together AI 团队) - 与 Michael 和 Sijun 共同领导项目,包括实验设计。为 SFT+验证器训练生成了 R2E-Gym 轨迹;为最终实验评估了 DeepSWE 和基线模型;并管理了 GPU/Kubernetes 基础设施,在整个 RL 训练生命周期中解决了技术挑战。
引用
觉得有用?分享给更多人