DeepSWE: 基于纯 RL 训练的 Agent

一、引言与项目概览

DeepSWE 是一个全新的、完全开源的强化学习训练项目，其目标是构建一个具备多步代码理解与修改能力的大型语言模型智能体（coding agent）。该项目训练起点是 Qwen3-32B 模型，不依赖任何监督微调（SFT）或教师模型蒸馏，仅通过强化学习完成整个 agent 的建构。最终模型 DeepSWE-Preview 在 SWE-Bench-Verified 基准任务上取得 42.2% 的 Pass@1 成绩，并通过测试时轨迹扩展（Test-Time Scaling）将 Pass@16 提升至 59%，在所有开源模型中表现最佳。

图 1：经 SWE-Bench 验证的 LLM 代理的性能与模型大小对比。通过仅使用强化学习 (RL)从头开始训练，结合测试时间扩展 (TTS) 的 DeepSWE-Preview 解决了 59% 的问题，大幅超越所有开源代理。我们注意到，DeepSWE-Preview 的 Pass@1 性能（42.2%，16 次运行的平均值）在开放权重编码代理中名列前茅.

图 2：SWE-Bench-Hard 的验证分数，如果代理提交最终答案并通过所有测试，它将获得正向奖励。仅需 200 步强化学习训练，SWE-Bench-Verified 的Pass@1分数就从 23% 提升至 42% (+20%）。

二、问题定义与环境构建

在 DeepSWE 中，软件工程任务（如修复 GitHub Issue）被建模为一个强化学习环境。该环境依托 R2E-Gym 框架实现，将每个任务封装为一个完整的 Docker 镜像，包含代码仓库、测试框架与构建脚本。模型作为 agent 与环境交互，拥有类 IDE 的工具接口：包括 Bash 执行、代码搜索、文件编辑以及“完成”指令。当 agent 判断任务完成后，会调用 finish 操作提交补丁，此时环境会运行测试套件以判定补丁有效性，并据此给予奖励。

此类任务天然是长时序的（long-horizon）、多步骤（multi-turn）的问题，不仅涉及程序逻辑的理解，还包括测试驱动的验证、文件结构的浏览与代码编辑等细粒度操作。这要求 agent 能够逐步积累上下文并动态调整决策策略。

三、数据集与训练基础设施

为避免训练集与评估集重叠，DeepSWE 使用 R2E-Gym 中约 4,500 个任务实例，并明确排除如 sympy 等 SWE-Bench-Verified 中出现的项目。这些问题各自独立包装为 Docker 镜像，确保环境的一致性与可控性。

在大规模训练中，训练系统需支持高并发容器调度。初期使用 Docker API 直接启动容器，但在每轮需并发运行 512 容器（64 任务 × 8 个 rollouts）的情况下，Docker daemon 容易崩溃。因此，项目改用 Kubernetes 管理容器调度，配合集群弹性扩缩容机制，实现上千核 CPU 与 TB 级本地 SSD 资源的分布式训练。每台工作节点预热镜像层以加速启动，集群调度逻辑则自动按负载动态增减节点，显著降低训练中断率与资源浪费。

四、强化学习算法设计：GRPO++

一、什么是强化学习（Reinforcement Learning, RL）？

在机器学习中，强化学习是一个研究“如何通过试错，让智能体（agent）学习在一个环境中采取行动以最大化长期收益”的方向。

强化学习的基本框架可以用五个元素表示：

- Agent：智能体（比如一个 AI 模型），它要在环境中“行动”。
- Environment：环境，即 agent 所处的世界（比如一个游戏、软件项目、机器人控制系统等）。
- State：某一时刻环境的状态（比如当前文件夹下的代码结构、终端输出等）。
- Action：agent 在该状态下可执行的动作（比如“查看文件”、“运行 bash”、“提交代码”等）。
- Reward：agent 每次行动后，环境给予的反馈（比如修复 bug 成功 = +1，失败 = 0）。

强化学习的目标是学会一个策略（policy），这个策略能告诉 agent 在每种状态下应该做什么，以获得最大的长期总奖励。

---

二、为什么在 DeepSWE 中使用强化学习？

DeepSWE 是一个“多步代码智能体”，也就是说它的目标不是生成一个答案，而是一步步地完成一个修复软件 Bug 的任务。这个任务非常像人类程序员 debug 的过程：

1. 阅读报错日志
2. 搜索错误位置
3. 编辑代码修复 bug
4. 运行测试验证结果
5. 如果失败，返回第一步重新尝试

这样一个过程很难用传统的“监督学习”方法解决。因为监督学习只是告诉模型：“这是输入，这是输出”。但在真实开发中，没有唯一正确的过程，只有最终结果是否成功。因此，这种“只有成功/失败反馈、没有明确中间答案”的情况，正是强化学习最适合的场景。

---

三、传统 RL 方法在 LLM 上的挑战

在使用 LLM（大型语言模型，如 ChatGPT、Qwen3）作为 RL 的 agent 时，会面临几个新挑战：

1. 输出是离散的自然语言，而不是数值动作
2. 每条轨迹很长（动辄几千个 token，数十步交互）
3. 奖励非常稀疏（只有在任务完全成功时才有 +1，否则全为 0）
4. 模型参数非常庞大，梯度容易爆炸或消失

这些问题导致传统 RL 方法（比如 PPO）在 LLM 上经常出现训练不稳定、策略坍塌、奖励失效等问题。

为了解决这些问题，DeepSWE 团队基于 GRPO（Generalized Reward Policy Optimization）提出了一个适用于多轮、长轨迹、大模型的强化学习方法，叫做 GRPO++。

---

四、什么是 GRPO（Generalized Reward Policy Optimization）？

GRPO 是一种专门为语言模型设计的强化学习方法，原始思想类似于 PPO（Proximal Policy Optimization），但做了多项适配性修改。

GRPO 的核心思想是：

- 让 LLM 输出序列时，不是简单地“模仿人类写法”，而是根据是否能完成任务来学习；
- 每一个序列的 log-prob（生成的概率）都会根据是否获得奖励，来调整策略；
- 这种方法对语言模型的 tokenizer 和多步结构做了改良。

不过 GRPO 也并不完美，它对一些因素仍然比较敏感，比如轨迹长度、策略偏移幅度、奖励不均衡等。

---

五、DeepSWE 的 GRPO++ 做了哪些改进？为什么？

为了在复杂、多轮的 Agent 场景下稳定训练，DeepSWE 对 GRPO 做了系统性的改造，形成了 GRPO++。下面我们逐项解释这些改进的内容和原因。

1. Clip High：鼓励探索，避免早期收敛

在 PPO/GRPO 中，为了防止策略在训练中变化太大，通常会对策略更新的幅度做“裁剪”，也就是限制新旧策略的比值不超过一个阈值。

然而，在 DeepSWE 中，一开始 agent 对环境几乎一无所知，如果裁剪得太严格，它将永远学不到新东西。
    
于是 GRPO++ 采用 Clip High 策略：只限制劣势样本的策略退步，但允许优势样本（即获得奖励的）策略放开更新。这样 agent 能在早期大胆尝试，找到正确的路径。

2. No KL Loss：取消对原模型的约束

一般的 RL 方法会对策略加一个 KL 距离惩罚项，目的是让它“不要离初始模型太远”。但在 DeepSWE 中，初始模型是 Qwen3，它并不懂如何 debug，所以如果一直围绕它打转，就永远学不会新策略。

因此 GRPO++ 直接移除 KL 惩罚项，让策略可以完全跳出初始行为，自由调整。

3. No Reward Std：保留原始奖励差异

原始 GRPO 会对所有样本的 reward 做标准化（减去均值除以方差），这样“容易的”和“难的”任务对模型影响一样。

但 DeepSWE 团队认为这是不合理的：如果一个补丁特别难修好，模型就应该花更多力气去优化它。于是他们保留了原始奖励数值，不做标准差处理。

4. Length Normalization：抵消长回复的劣势

在语言模型中，如果你生成的回复越长，累积的 loss 会越大。这样会导致模型偏向于写短代码、不完整的补丁。

为解决这个问题，GRPO++ 对每条序列的 loss 做了长度归一化（除以 token 数量），让长序列不会在训练中被惩罚。

5. Leave-One-Out Advantage（LOO）：降低梯度波动

在 RL 中我们需要估计每个样本的“优势”（即它比平均水平好多少），这个值太抖动会让训练不稳定。

GRPO++ 使用了Leave-One-Out技术：计算平均 reward 时，先把当前样本排除在外。这样可以减少估计偏差，降低训练震荡。

6. Compact Filtering：屏蔽掉无效的“坏轨迹”

在多步环境中，agent 经常会出现：

- 一直卡在某个死循环里
- 想了很多步却没提交补丁
- 提交后挂掉测试但仍被计算为“有用轨迹”

这些轨迹如果参与训练，会导致模型学到错误行为。

GRPO++ 引入了 Compact Filtering 策略，过滤掉：

- 超过上下文长度限制的轨迹（max context）
- 超时未提交的轨迹（timeout）
- 走到最大步数还没提交的轨迹（max steps）

只有“有头有尾”的有效轨迹才会被用于训练，避免奖励污染。

紧凑过滤有利于训练，原因有二：

- 防止或延迟训练期间的奖励崩溃（图 6）。LLM 代理可能会在不知情的情况下偶然发现正确的补丁并通过所有测试。使用这些积极的奖励进行训练会强化各个步骤中的不良行为（例如，LLM 在前 10 步中正确回答，但之后会修补随机文件），当此类行为累积时会导致崩溃。确保仅在 LLM 代理主动提交时才分配奖励，可以鼓励进行严格的测试，从而使 LLM 对其最终提交的内容更有信心。
- 减少每一步的过度思考，鼓励跨步骤进行长篇推理。图 7 说明了这一现象。在训练过程中，平均响应长度缩短，但平均环境步骤数增加，这表明每步的平均思考时间急剧下降。

奖励设计采用极简的稀疏策略奖励模型（ORM）：只有当补丁通过回归测试（包括 Fail2Pass 和 Pass2Pass）且在 5 分钟时间限制内完成时，才给予奖励 1；否则奖励为 0。相较 SWE-Bench 的 30 分钟窗口，5 分钟训练限制更有利于加速并发采样。

## 奖励函数详解：结果导向的稀疏奖励机制（Outcome Reward Model, ORM）

在强化学习中，奖励函数（Reward Function）是智能体（Agent）学习的关键来源。每次 agent 与环境交互后，环境会根据 agent 的行为反馈一个数值（reward），这个数值就像“打分”一样，告诉 agent 刚才的行为是否正确、是否值得学习。

在 DeepSWE 中，agent 的任务是修复一个真实的软件问题，也就是对代码做出修改（补丁 patch）并提交，然后让环境判断：这次修改成功了吗？

为了让这个判断过程简单而可靠，DeepSWE 使用了一个叫做 Outcome Reward Model（结果奖励模型）的策略，它是一种非常稀疏（sparse）的奖励函数。

---

一、奖励定义（Reward Definition）

奖励的逻辑如下：

- 如果 agent 生成的补丁在规定时间内通过了所有选定的测试用例（包括 Fail2Pass 和 Pass2Pass），那么：
  - 奖励 = 1

- 如果补丁有任何一个测试用例失败或在规定时间内没有完成测试超时），那么：
  - 奖励 = 0

这就形成了一个“非黑即白”的奖励机制：只有成功才算奖励，部分正确不算

---

二、什么是 Pass2Pass 和 Fail2Pass？

要理解奖励机制，我们必须先明白两个测试集合的含义：

1. Pass2Pass（P2P）：
这是指问题提交之前，项目本身已有的测试用例，也就是“原来就应该能通过”的测试。

agent 修改代码之后，这些测试仍然必须通过，否则就意味着 agent 可能引入了新的 bug。

2. Fail2Pass（F2P）：
这是指该问题的特定回归测试用例，也就是为了确认这个 bug 是否被修复而新增的测试。如果这个测试没通过，说明 agent 根本没解决问题本身。

只有当 agent 生成的 patch 同时通过 F2P 和 P2P 的测试时，我们才可以认为它“完美地修好了这个 bug”。

---

三、为什么奖励函数要设计成这么“苛刻”？

这是因为在真实的软件开发中：

- “修了 bug 但引入新 bug”是非常危险的；
- “只部分修复”是无法通过代码审查的；
- “运行超时”在真实 CI/CD 系统中会直接 fail。

因此，奖励函数必须高度对齐现实世界的评判标准，否则 agent 可能学到“做表面功夫”的策略，比如只为了让新测试通过而破坏旧逻辑。

此外，这种 0/1 奖励也带来了设计上的简洁性：它可以直接用作强化学习的标量反馈，而无需复杂的多维评分系统。

---

四、时间限制为什么是 5 分钟，而 SWE-Bench 是 30 分钟？

官方评估系统 SWE-Bench 给 agent 每个问题最长 30 分钟时间来运行测试。这么长的时间主要是为了兼容大型项目构建时间，例如运行 `pytest`、构建 Cython、安装依赖等。

但在训练期间，agent 需要和成千上万个问题交互，每一个都等 30 分钟根本不现实，训练会变得极其缓慢。

所以，DeepSWE 使用了一个加速训练的简化策略：把每次测试的最长运行时间限制为 5 分钟。如果 5 分钟内 agent 的补丁没有跑完或通过测试，那就视作失败（奖励 = 0）。

> 这个 5 分钟限制是一种 trade-off：牺牲了部分训练时的拟真性，但换来了训练速度的大幅提升。

---

五、这种奖励方式对训练带来了什么影响？

这种“1 或 0”的稀疏奖励设计，虽然简单，但对训练提出了很大挑战，尤其是：

1. agent 很难一开始就拿到正奖励
   - 初期几乎所有 patch 都失败，agent 看不到任何“正确例子”，学习信号为 0。
   - 为了解决这个问题，DeepSWE 采用了“clip high”鼓励探索策略，让 agent 大胆尝试。

1. 成功轨迹的误强化风险
   - agent 可能“误打误撞”修复了 bug，但补丁过程本身有问题（比如瞎改、乱删代码）。
   - 如果直接用这类轨迹训练，会强化错误行为。
   - 为此，DeepSWE 引入了 Compact Filtering，只使用“成功且干净”的轨迹参与 loss 计算。

1. reward variance 高，training 不稳定
   - 所有样本的 reward 只有两个值：0 或 1，这使得每一轮训练的 reward 波动非常剧烈。
   - DeepSWE 通过 Leave-One-Out Advantage、去除 reward std 等方法来抑制这种震荡。

---

六、和其他 RL 方法的奖励函数相比有什么不同？

| 方法 | 奖励类型 | 适用场景 | DeepSWE 对比 |
|------|----------|----------|---------------|
| PPO + KL | dense reward + KL 惩罚 | 语言建模、偏好学习 | DeepSWE 没有 KL loss，更自由探索 |
| RLHF | 人类偏好打分（如 1-5 分） | 对话质量优化 | DeepSWE 用客观 pass/fail 作为唯一评判 |
| Score-based RL | BLEU/ROUGE 分数 | 翻译、摘要任务 | 不适用于代码补丁，没有明确参考答案 |
| DeepSWE ORM | 完全稀疏的 Pass/Fail 奖励 | 软件工程任务 | 更贴近现实软件开发逻辑 |

---

七、小结

DeepSWE 的奖励函数采用了最简单但最贴合实际开发场景的设计：要么你修好了 bug 且没有破坏别的功能（奖励 1），要么你失败了（奖励 0）。没有中间地带。

这个奖励设计虽然稀疏，训练起来更难，但结合 GRPO++ 的多项改进（clip high、compact filtering、advantage 校正等），它最终让 DeepSWE 成功学会了一个通用的、多步 debug 策略，在真实的代码仓库中实现了自动修复能力。

这也说明了一个重要事实：复杂任务并不一定要有复杂奖励，有时简单的“是否成功”就足以引导模型学会非常复杂的行为，只要训练方法设计得当。

五、测试时扩展（Test-Time Scaling）与推理机制

与传统模型通过增加 token 数量提高推理表现不同，DeepSWE 的测试性能依赖的是 trajectory 数量扩展，即在推理时生成多个完整问题求解轨迹，并通过 Verifier 模型或程序测试集对它们进行打分排序，最终选择最优答案。

DeepSWE 综合使用了两种评估机制：execution-based verifier（通过代码测试自动评估补丁）和 execution-free verifier（用训练过的 LLM 直接判断补丁正误）。混合型策略（hybrid TTS）结合两者优点，在 K=16 rollout 情况下将 Pass@1 从基础的 42.2% 提升至 59.0%，远超其它开源方法（如 Skywork-TTS 的 47.0%）。值得注意的是，实验显示 context 长度从 16K 提升至 128K 所带来的性能提升非常有限（≤2%），远不如 trajectory 数量的增长所带来的效益。

六、涌现行为与学习分析

有趣的是，在纯强化学习的训练过程中，模型展现出若干“涌现行为”。一方面，agent 在提交补丁前往往会主动生成多个 edge case 测试并运行已有的 regression test，以确保修改不会破坏现有逻辑。(相比之下，当前 SWE 代理面临的最大挑战之一便是虽然它们可能修复了提出的错误，但生成的补丁可能不会考虑极端情况，或者会引入新的错误，从而破坏代码库的现有功能。）此行为并未显式引导，纯属在 RL 奖励驱动下自然学习到的通用测试意识。

另一方面，模型能根据任务复杂度动态分配“思考 token”。当任务需要深入理解代码结构或定位复杂 bug 时，模型往往会生成长达 2K tokens 的响应；而在执行脚本、搜索关键词等低复杂度任务中，其响应精炼至不足 200 tokens。这种 token 调度策略进一步提高了 RL agent 的样本效率与策略合理性。

七、结语

DeepSWE 是首次在无任何监督指导（无 SFT、无蒸馏）情况下，使用纯强化学习成功训练出表现卓越的多步智能体模型。其训练机制、调度基础设施与奖励设计共同构建了一个可拓展、高可复现的代码代理训练方案。借助 rLLM 框架和 R2E-Gym 环境，该项目已将全部数据、模型、日志、源码开源，为社区在 RL-agent 方向的研究奠定了重要基础。未来的智能体系统，将可能正是从 DeepSWE 这样严谨而开放的 RL 训练体系中诞生。