Long-Context SWE Agent：用 0/1 奖励训练多轮软件工程智能体

先分清“赌博机式任务”和“部分可观察的交互任务”，这决定了 RL 能优化什么。

论文的出发点是一个建模差异。数学推理、单次代码生成这类任务可以写成 (问题 → 答案 → 奖励) 的单步过程：模型看不到中间状态，也没有机会根据环境反馈改变策略。论文把它称为 bandit-style 或退化的 MDP（§1、Figure 2 上半）。

软件工程任务不是这样。一个 issue 只给出自然语言描述，仓库的真实状态（文件内容、依赖、测试结果）对智能体是部分可观察的；它只能通过动作去获取观察：运行 ls 或 grep 看目录和代码，打开文件，修改某几行，运行测试，读失败日志。每个动作都会产生可观察的转移（其中一部分会改变仓库状态），下一步的决策依赖完整的动作—观察历史。论文把它写成 POMDP（§2.1），Figure 2 的下半部分给出与单步任务的对比（§1）。

这个建模带来两个直接后果。第一，轨迹会很长：一个任务可能要几十轮命令和修改，上下文里堆满文件片段、报错和 diff。论文最终把训练上下文推到 131k，单条 episode 最多 80 轮（§3.3）。第二，奖励是稀疏的 0/1：中间步骤没有人工奖励，唯一信号是最终补丁有没有通过验证测试。论文明确把 R(τ) ∈ {0,1} 作为策略优化的唯一任务信号（§2.1）。

这也解释了为什么“直接上 RL”不够。基础模型常常连工具格式都写不对：命令格式错误、编辑时缩进不符合要求（§2.3 的 edit 要求精确缩进）。论文说初始 checkpoint 在 SWE-bench Verified 上只有约 11%，主要失败原因是指令跟随不正确（§3.2）。如果 RL 从这种状态开始，大部分 rollout 都会因为格式错误拿 0 分，组内比较没有有效梯度——原文没有直接给出这个实验，推断（依据：§3.2 说初始 checkpoint 的主要失败是指令跟随/格式，RFT 正是为修正它而设计）。RFT 的作用就是先把这些“无效动作”清掉。

论文要证明的是：不靠教师模型，RL 阶段只靠环境交互和 0/1 奖励（RFT 仍用自生成成功轨迹做 SFT），也能把开源模型推到同一档。

论文在引言里列出当时做高性能 SWE 智能体的三条常见路线（§1）：

Table 2 把近期的专用 SWE 智能体按“是否使用教师蒸馏”分了类。这个分类很重要：教师蒸馏路线里，32B 模型可以在 SWE-bench Verified 上到 40.2%（SWE-agent-LM-32B）；不用教师的方法里，DeepSWE-32B 到 42.2%。论文的最终模型在 Table 2 的 after 列是 39.0%（与 Table 1 的 Pass@1 39.04% 对应），处在这个区间的同一档，但它的卖点不是“最高分”，而是不用教师数据；RL 阶段只用 0/1 环境奖励（RFT 用自生成成功轨迹做 SFT）。

论文选择 RFT + RL 的组合。RFT 仍然需要模型自己产生成功轨迹，但不需要外部教师；RL 则在 RFT（采样筛选 + SFT）的基础上继续用环境反馈优化策略（§3.2、§3.3）。论文在 §1 的论点是：RL 通过与环境交互直接优化策略，可能在不依赖教师模型的情况下取得更强性能。

方法不新在网络，而在把多轮交互、长轨迹和 0/1 奖励接进 DAPO。

智能体怎么动：工具、轮数与 submit

智能体采用 ReAct 式循环，动作—观察历史会拼进每一次决策。工具集包括（§2.3）：任意 shell 命令（ls、cat、grep 等）；一个按行替换文件内容的 edit 命令，要求给出精确缩进；search_file、open、goto 这类检索与导航工具；以及一个无参数的 submit 命令，调用后 episode 结束。智能体可见的是 issue 描述、失败测试套件与仓库快照（§2.3）；数据集记录还含 ground-truth patch（§3.1）。

奖励在 episode 结束时计算：最终补丁通过验证测试套件则 R(τ)=1，否则为 0。中间步骤的即时奖励全为 0，所以整条轨迹只有终点信号（§2.1）。这个设定和真实开发接近，但也把信用分配问题留给了算法。

RFT：先让模型学会“怎么用工具”

RFT 的流程在论文里写得很具体（§3.2）：用初始 checkpoint 在 7,249 个 SWE-rebench 任务上各生成 10 条轨迹，只保留补丁通过测试的轨迹，一共得到 6,548 条；在这批成功轨迹上做 1 个 epoch 的监督微调。训练时屏蔽掉所有触发环境格式错误的 agent turn，Loss 只落在格式正确的动作上。

口径提示：原文 §3.2 的 6,548 条与 §4.3 的 batch 64 / 50 个梯度步不吻合（6,548 / 64 ≈ 102.3；50 × 64 = 3,200）；推断 可能 batch 是全局/每设备口径，或只用了部分轨迹，论文未说明。此处按原文并列，不替它消解。

这一步不是“学解题思路”，而是“学接口”。原文说基础模型的主要失败是指令跟随不正确、命令不符合要求格式（§3.2）；§2.3 的 edit 命令还要求精确缩进。把这些无效动作从 Loss 里去掉，模型会更快稳定在可执行的交互模式上。RFT 后 Verified Pass@1 从 11.42% 到 20.46%，差 9.04 个百分点（base 用 131k、RFT 用 65k 评测，见 Table 1 caption；差值含评测上下文变化）。

DAPO：组内比较，不需要 critic

RL 阶段用 DAPO。它属于 GRPO 一系：对同一个初始 observation 采一组 G 条完整轨迹，用组内奖励的均值 R̄ 和标准差 σR 归一化每条轨迹的终点奖励，得到这条轨迹的优势：

DAPO 相对 GRPO 的改动有四条，论文都写进了 §2.2：token-level loss（按 token 平均，而不是每条轨迹等权）；动态采样（优势为 0 的样本被丢掉，不让它们占据计算）；软超长惩罚（超过长度阈值后线性扣分，而不是直接把轨迹截断）；以及非对称 clip（上下界分开设置，Stage 1 为 [0.2, 0.3]，Stage 2 为 [0.2, 0.26]）。

软超长惩罚的公式是：

为什么不用 PPO：PPO 需要一个学出来的 critic 来估计优势，critic 本身要训练、会引入额外的不稳定；组内比较直接用同一组轨迹的终点奖励做基线，省掉了这个网络（§2.2）。代价是每组必须采多条完整轨迹，而 SWE 的轨迹很长，所以采样成本高。

这一节把两阶段超参数、数据过滤和基础设施摊开。

数据：从 21,336 到 7,249

训练数据来自 SWE-rebench：21,336 个任务，覆盖约 3,400 个 Python 仓库；每个任务包含 GitHub issue、失败测试套件、可复现的仓库快照，以及 ground-truth solution patch（§3.1），原文没有把任务类型限定为 bug fix（§3.1）。论文按四条规则过滤（§3.1）：任务正确性（去掉测试因无效引用/导入而失败的任务，如 AttributeError、ImportError）；受控复杂度（只保留最多修改 7 个文件、少于 500 行代码的任务）；LLM 质量评分（去掉原数据集中 LLM 评分 3.0 的任务，理由包括 issue 描述不清、任务过复杂或测试补丁有缺陷）；确定性测试（50 次重复运行，去掉 flaky 任务）。最终留下 7,249 个任务，也就是过滤掉 14,087 个。

Stage 1 用 65k 上下文，已经超过多数开源模型默认的 32k；论文说这个长度还不够覆盖长堆栈或长 diff 历史，所以在性能到约 32% 后切到 Stage 2（论文未说明该阈值对应哪个评测集；Figure 1/4 的中间评测用 Verified-50，Table 1 的完整 Verified 上 Stage 1 为 35.74%）：上下文升到 131k，最大轮数从 40 翻到 80，同时降低高 clip 上界、增大 batch、降低每轮问题数，让训练更接近 on-policy（§3.3）。131k 是通过 YaRN 位置编码（factor = 4.0）实现的（§4.3）。

课程：去掉“已经会做”和“从来没做对”的任务

Stage 2 开始前做一次性的课程调整。论文定义任务的累计解决率：它在之前所有训练迭代中的成功率。累计解决率超过 2/3 的任务被移除（说明已经能稳定解决），累计解决率始终为 0 的任务也被移除（说明大概率不可解）。训练池因此从 7,249 缩到 2,028，筛掉 5,221 个任务（§3.3）。

优化与基础设施

RFT：1 个 epoch，学习率 5×10−6，AdamW，weight decay 0.1，10 步 warmup，cosine 衰减到 0，batch 64，共 50 个梯度步。RL：学习率 10−6，1 个 epoch，梯度裁剪 1.0，AdamW（β₁=0.9、β₂=0.999、ε=1e−8、weight decay 0.1）（§4.3）。6,548 条成功轨迹与这里的 batch 64 / 50 步不吻合（6,548/64≈102.3，50×64=3,200）；原文未说明，见 §3.2 后的口径提示。

整个流程是同步的：rollout 生成完再训练，没有策略滞后（on-policy）。每个问题采 10 条轨迹，每轮产生 2–8 个优化步，具体取决于 batch size 和优势非零的轨迹数。训练与推理都在 16 个 H200 节点上完成；为了在 131k 序列上做全参数训练，用了 context parallelism（§4.2）。论文未报告总 GPU 小时、token 数或单轮墙钟；§4.2 给出 16 个 H200 节点；Appendix C 给出单 pod 配置（8×H200、32 CPU、960 GiB、JAX、vLLM 0.7.4），但没有总量指标。同步训练的一个已知问题是 straggler：一轮的耗时取决于最慢的那条轨迹。

RL 总共跑了 100 多个训练迭代（over 100 RL iterations，§4.1）。论文未给出 Stage 2 的迭代次数，也未说明每轮采样是否放回；因此无法判断 2,028 个任务是否被重复采样（Stage 1 的 300 问题/轮、Stage 2 的 100 问题/轮见 Table 3）。

上半部分是训练流水线，下半部分是一条 episode 内的交互循环。

流水线里只有 RL 两段用环境 0/1 奖励更新策略。RFT（采样筛选 + SFT）负责把模型带到“能正常跑完 episode”的起点；Stage 1 在 65k 上下文、最多 40 轮上训练；课程筛选把已经稳定解决和完全解不出的任务拿掉；Stage 2 把上下文扩到 131k、最大轮数提到 80（§3.3）。评测时不再更新参数，只把最终 checkpoint 放到同样的工具环境里跑。

先看主表和分阶段柱状图，再看三个反直觉点：Stage 2 的 Pass@1 在 Verified 上涨、May 下降、June 小幅上涨（Pass@10 下 May/June 不涨）、Pass@1 与 Pass@10 的差距、以及与 DeepSeek 的逐项对比（结论按 Pass@1 / Pass@10 分开）。

Table 1 是主结果。Pass@1 是 10 次运行的平均值，括号里是标准误；最终模型和基线用 131k 评测，中间模型用各自训练阶段的上下文长度（65k）评测。

交互：切换 Pass@1 / Pass@10，看四个训练阶段

下面把 Table 1 的四个训练阶段画成柱状图，按基准分组。切换指标会重画全部柱子；同一组里从左到右是 Base、RFT、Stage 1、Stage 2。数值逐字来自 Table 1。

训练账：阶段差 9.04 / 15.3 / 3.3，口径不同不能直接当贡献拆分

在 Verified 上，RFT 把 Pass@1 从 11.42% 拉到 20.46%，差 9.04 个百分点（base 用 131k、RFT 用 65k 评测）；Stage 1 的 RL 把它拉到 35.74%，差 15.3 个百分点（同为 65k，是唯一同口径的阶段差）；Stage 2 再差 3.3 个百分点（同时改了上下文、轮数、batch、clip，以及训练池——课程筛选从 7,249 到 2,028——和每轮问题数（§3.3、Table 3），不是纯算法贡献）。RL 两段合计比 RFT 高 18.6 个百分点，最终是 RFT 基线的 1.91 倍（39.04 / 20.46）。

反直觉 1（Pass@1）：Stage 2 在 Verified 和 June 上涨、在 May 下降。按 Pass@1，把上下文从 65k 扩到 131k、轮数从 40 扩到 80 后，Stage 2 在 Verified 和 June 上涨、在 May 下降：Verified 从 35.74 涨到 39.04，涨 3.3 个百分点；June 只涨 0.49 个百分点；SWE-rebench May 从 36.50 掉到 35.00，低 1.5 个百分点。推断 只有 Verified 的涨幅明显——June 的 +0.49 落在两个阶段各自的标准误（±0.80 与 ±1.31）之内（依据：Table 1 的 Pass@1 ±SE 比较；原文没有这句显著性判断）。按 Pass@10，方向不同：Verified 54.6 → 58.4，May 55.0 → 52.5，June 53.7 → 53.7（持平）；三个分片里只有 Verified 上涨。论文没有对 May 的下降给出解释，也没有把它归因于课程筛选或上下文变化；这里按 Table 1 原样并列，不替原文消解。

反直觉 2：Pass@10 远高于 Pass@1。最终模型 Verified Pass@1 是 39.04%，Pass@10 是 58.4%，相差 19.4 个百分点。论文据此指出，模型生成的候选里经常存在正确解，只是单次选择没选中；这为后续接重排或 best-of-n 留了空间（§3.3）。注意这是“候选里有没有”和“最终提交哪一个”的差别，不是模型不会做。

反直觉 3：对 DeepSeek 的比较要分片看，而且 Pass@1 / Pass@10 方向不同。按 Pass@1，Verified 上 DeepSeek-V3-0324 是 39.56%，比最终模型高 0.52 个百分点；SWE-rebench May 上 DeepSeek 36.75%，高 1.75 个百分点；June 上 DeepSeek 31.46%，最终模型 31.71%，最终模型高 0.25 个百分点（31.71 − 31.46）。按 Pass@10，DeepSeek 在三个分片都更高：Verified 62.2 对 58.4、May 60.0 对 52.5、June 58.5 对 53.7（Table 1）。按 Pass@1，只有 June 略高 0.25，Verified/May 分别低 0.52/1.75，不能概括为追平；按 Pass@10 三个分片都低。

和专用 SWE 智能体比：不是 Table 2 的最高分

Table 2 汇总了专用 SWE 智能体。下表转录 Table 2 全部 9 行。“Teacher Distillation”列表示训练是否用了教师模型生成的轨迹。

表里有三个不用教师的方法：最终模型 39.0%，DeepSWE-32B 42.2%，SkyRL-Agent-14B-v0 21.6%。Table 2 的 after 列原文只写 final performance，未注明指标；Ours 的 39.0 与 Table 1 的 Pass@1 39.04 对应，DeepSWE/SkyRL 的 42.2/21.6 按原文转录，不能断言均为 Pass@1。按 Table 2 的 after 数值，DeepSWE-32B 比最终模型高 3.2 个百分点。用教师蒸馏的 32B 模型里，SWE-agent-LM-32B 也到 40.2%。所以这篇论文的位置是“不用教师、RL 阶段只用环境奖励的强基线”，不是“所有设置下的最高分”。

训练里的两个坑

坑 1：不要一概丢掉超长轨迹。常见做法是把超过上下文长度的轨迹过滤掉，以减少奖励噪声。论文说这要谨慎：在它的设定里，超长轨迹往往意味着智能体陷入了重复循环；把这些轨迹丢掉，也就丢掉了“循环”这个失败模式的负样本，模型反而学不会如何跳出循环，训练中这种循环会更频繁（§4.4）。

坑 2：训练 rollout 必须来自 πold。训练中途升级 vLLM 后，运行时默认启用了 top_k 和 min_p。一开始评测指标变好，但继续训练 5–10 个迭代后开始下降。论文把这个现象归因于 rollout 分布和训练分布的错配：DAPO 的重要性采样比只有在 rollout 来自 πold 时才有意义，换解码参数相当于从另一个分布采样（§4.4）。这里说的是训练 rollout 的采样解码（§4.3 的 temperature=1.0、禁用 top_p/top_k 等），不是 Table 1 评测所用的默认解码。这是一个工程细节，但会直接影响复现。

这些限制决定了这套方法能不能搬到别的任务，以及复现成本有多高。

没有解决“选择”问题。Pass@1 39.04%、Pass@10 58.4%，说明候选里经常已经有正确补丁，但模型自己选不中。论文只把这个差距作为一个观察和未来方向，未描述重排器或提交前的验证/自我检查。实际部署时，这个差距会直接变成“再多试几次”的成本。

没有风险意识。智能体被训练成“尽力提交一个补丁”，没有“这题我没把握，先停下或求助”的动作。论文在讨论里把不确定性估计和放弃机制列为未来工作；当前模型在低成功率的任务上也会走完 episode 并提交。

同步训练的限制。论文明确说异步框架可能有更好的扩展性，但为了消除轨迹滞后选择了同步；同步的 straggler 问题会让每轮时间取决于最慢的轨迹（§4.2）。这意味着吞吐和资源利用率还有优化空间，但论文未报告异步版本的对照实验。

什么时候别用：如果任务没有可自动运行的验证测试、代码执行有安全风险、或者仓库状态无法快速快照和回滚，这套方法的奖励和 rollout 都搭不起来。反过来，在有测试、有沙箱、任务类型稳定的软件工程场景里，它的路径很直接：先用成功轨迹教会模型用工具，再用 0/1 结果做多轮策略优化。