华为推出软工代码智能体SWE-Lego,解锁SFT训练极致性能

“软工任务要改多文件、多轮工具调用，模型怎么学透？高质量训练数据稀缺，又怕轨迹含噪声作弊？复杂 RL 训练成本高，中小团队望而却步？”

华为研究团队推出 SWE-Lego， 仅基于监督微调（SFT）的软件工程代码智能体，无需复杂 RL 流程，在 SWE-bench Verified 基准中斩获同等规模开源模型 SOTA，甚至超越部分更大规模闭源模型！项目已开源，代码、模型和全部数据一键获取！

• arXiv 地址：https://arxiv.org/abs/2601.01426

• GitHub 地址：https://github.com/SWE-Lego

• HuggingFace 地址：https://huggingface.co/SWE-Lego

SWE-Lego 具有三大创新，包括数据、训练和测试时扩展。

1. 混合数据集构建：

• 双数据管道互补：GitHub 真实 PR 数据 + 注入真实场景 Bug 的合成数据，产出 32k 高质量任务实例 + 18k 专家轨迹；

• 严格轨迹筛选：过滤 Git 历史泄露、工具错误等噪声，重用部分解决的优质轨迹，提升 SFT 训练有效性。

2. 改进的监督微调：

• 两大亮点：① 步骤级错误掩码，让模型从长轨迹中学习有效子轨迹；② 课程学习，按交互轮次分级提升任务难度；

• 性能提升：比传统 SFT 在不同模型上提升 2~4%，筑牢 SOTA 基础。

3. 测试时扩展策略（TTS）：

• 扩展优先级：先串行扩展（增大轨迹最大交互轮数）至饱和，再分配资源给并行扩展（多备选答案选最优）；

• 打分器优选：生成式打分器在并行扩展中，全程优于回归式打分器，适配不同模型规模与测试预算。

引言

在软件工程领域，Code Agent 需要处理复杂的任务：修复 bug、重构代码、理解大型代码库。这些任务要求 Code Agent 具备长序列推理、多文件操作和工具使用等能力。现有的训练方法通常需要复杂的训练范式，比如强化学习（RL）或者 RL 和 SFT 的迭代组合。

这些方法虽然有效，但计算成本高，训练过程复杂。能否用更简单的方法达到同样的效果？

华为的研究团队提出了 SWE-Lego，一个仅基于监督微调（SFT）的软工代码模型的解决方案。在 SWE-bench Verified 基准测试上基于 Qwen3 系列模型作为起始模型，经过 SFT 之后得到 SWE-Lego-Qwen3-8B 和 32B 分别达到 42.2% 和 52.6%，达到了开源模型的 SOTA 水平，并超越了一些更大规模的闭源模型。基于测试时扩展策略（TTS）可以进一步把性能提高 6~7%。

图 1：SWE-Lego 系列模型在 SWE-bench Verified 上的性能对比，在同等规模模型中表现达到 SOTA

一、挑战与动机

软件工程任务与传统的单文件编程任务有着明显区别：一个 bug 修复可能涉及代码项目里多个文件的修改，需要多轮工具调用（读取文件、执行测试、编辑代码等），必须在真实的代码库环境中验证修复效果，还需要理解代码逻辑、定位问题、设计修复方案等复杂推理能力。

为了训练具备软件工程项目级代码编写能力的代码模型，研究者们尝试了多种方法。强化学习（RL）虽然不需要预定义的轨迹，但训练成本极高。复杂组合方法将多种训练范式结合，比如 SFT 和 RL 的迭代训练，进一步增加了训练复杂度。更重要的是，高质量的训练数据稀缺。现有的数据集要么规模有限，要么缺乏可执行环境，要么难以扩展到足够大的规模。

二、SWE-Lego 的三大核心组件

SWE-Lego 包含三个核心组件：

图 2：SWE-Lego-Qwen3-32B 的性能提升分解，混合数据集贡献最大（+25.6%），改进的 SFT 贡献 + 3.8%，TTS 贡献 + 6.2%

从图 2 可以看到每个组件的贡献：混合数据集贡献 + 25.6%（最大贡献），改进的 SFT 贡献 + 3.8%，测试时扩展贡献 + 6.2%。总计从基线 23.2% 提升到 58.8%，提升了 35.6 个百分点。这些结果清楚地表明，好的数据集是性能提升的最大驱动力，而改进的 SFT 和测试时扩展提供了不错的增量收益。

核心组件一：混合数据集构建

SWE-Lego 数据集包含 32,119 个高质量任务实例，18,110 个验证轨迹（其中 14,110 个完全解决，4,000 个半解决），覆盖 3,251 个代码仓库。

SWE-Lego 采用混合数据构建策略，结合真实世界数据和合成数据。真实世界数据来自严格筛选的 GitHub Pull Requests （PRs），这里的 PRs 中非测试文件作为 Golden Patch, 也就是这个任务的解决方案。真实 PR 数据具有贴近生产环境的优势，能够提供真实的 bug 的复杂性，真实的任务参考 SWE-rebench [1]。但是真实数据数量有限，且每个任务需要独立的沙箱环境，成本较高。

参考 SWE-smith [2] 的通过故意引入 Bug 来合成软工任务的方式，SWE-Lego 通过 AST 转换和 LLM 重写，基于真实代码仓得到相应的合成软工数据，对可以通过测试的代码库故意引入一些 Bug。具体地，AST 转换提取抽象语法树（AST）并应用随机变换，如移除条件 / 循环、修改运算符或依赖关系，而 LLM 重写则提示模型使用函数头和文档字符串等信息重写代码。引入 Bug 的补丁进行反转就可以得到解决这个任务的 Golden Patch。合成数据具有可扩展、成本低、多个任务可共享沙箱的优势，但复杂度相对较低。

在下一步，团队对真实和合成数据采用测试驱动的方式去得到验证后的软工数据实例，筛选出合格的软工任务。具体地，在应用 Golden Patch 前可以通过的测试在应用 Golden Patch 之后仍然可以通过， 而应用 Golden Patch 前不通过的测试在应用 Golden Patch 之后也需要通过。

图 3：SWE-Lego 数据管道，结合真实 PR 和合成的软工任务实例，基于专家模型去生成可执行的轨迹用于 SFT 训练

真实数据提供深度（复杂性和真实性），合成数据提供广度（数量和覆盖范围）。两者互补：真实数据提供主要收益但难以扩展，合成数据通过进一步扩展提供额外收益。实验证明，增加合成数据可以显著提升有效轨迹数量和下游性能。

图 4：随着合成实例的增加，有效轨迹数量显著增长

图 5：随着混合数据的增加，模型的性能逐步提升

• 轨迹质量优化

为了确保训练数据的质量，SWE-Lego 实施了严格的轨迹生成和验证流程。

防止解决方案泄露：最近 SWE-Bench 社区 [3] 发现，LLM 可能通过查看 Git 历史来 "作弊"，直接找到正确答案。为了防止这种解决方案泄露，对于真实实例，SWE-Lego 移除问题创建日期之后的所有提交和日志消息，使未来的修复不可见；对于合成实例，由于有 bug 的版本在无 bug 的版本之前（由于故意的 bug 注入），完全移除整个 Git 历史和所有日志，只暴露 buggy 代码库的单个快照。这迫使模型真正推理代码和测试，而不是从版本控制中读取答案。

处理工具调用错误：在使用 Qwen3-Coder-480B-A35B-Instruct 作为教师模型时，观察到对 str_replace_editor 工具的频繁格式错误调用，例如将字符串传递给 view_range 或指定超出范围的行范围，导致工具失败并浪费交互预算。为了缓解这些错误，SWE-Lego 应用轻量级后处理：如果 view_range 是字符串，则在执行工具之前将其转换为整数；如果请求的行范围超过文件长度，则返回有效行的子集而不是引发错误，使得模型能够更可靠地检查代码。

精简工具集：虽然任务管理工具（如 task_tracker）已被一些最近的专有模型采用，但发现 Qwen3-Coder-480B-A35B-Instruct 无法有效使用它们，经常导致执行错误。因此，SWE-Lego 丢弃此工具，将工具集限制为四个基本操作：execute_bash、str_replace_editor、think 和 finish，以保持轨迹精简。

轨迹过滤策略：SWE-Lego 通过应用预测补丁并运行测试集来验证轨迹。如果轨迹通过所有测试，则分类为已解决，否则为未解决。然后，过滤低质量的已解决轨迹（例如，通过修改测试文件来 "作弊" 的轨迹），并重用部分解决轨迹（那些正确识别了所有相关文件但未能修复的轨迹）。这些部分解决轨迹提供了有价值的故障定位监督，我们发现加入此类数据会适当提升模型的性能。

图 6：轨迹生成中的关键实践，包括防止 Git 泄露、处理工具错误、精简工具集

表 1：SWE-Lego 的可验证的任务实例和有效训练轨迹的统计以及和其他 SWE 相关工作的数据对比

具体的数据统计和对比见表 1，可以看出 SWE-Lego 的混合数据管道提供了数量充足的、代码仓多样的、环境可验证的 SWE 任务实例和轨迹。

总结：混合数据集是性能提升的最大驱动力。真实数据与合成数据互补确保了数据数量，严格的轨迹验证确保了轨迹的质量。

核心组件二：改进的监督微调

通常的监督微调将通过测试验证的整条轨迹拿去训练，但实际上在软工的场景，专家轨迹需要多轮在沙箱中交互得到最后的预测补丁，即使最终成功解决的轨迹也可能包含中间错误步骤，盲目学习这些错误可能强化不良行为。另外，不同数据的难度不同，在训练初期让模型学习难题可能比较吃力。针对这些情况，SWE-Lego 提出了两个改进：

• 改进 1：步骤级错误掩码

核心思想：保持完整轨迹上下文，但只对正确的步骤计算损失。

图 7：步骤级错误掩码示例，错误步骤被掩码，模型只学习正确的操作

实现方法：使用正则表达式识别终端环境提供的错误消息，对相应的模型响应应用错误掩码。关键是要排除因复现 bug 或执行测试文件而产生的错误。这种方法保持完整的轨迹上下文，但只对正确的步骤计算损失，使模型能够学习正确的操作和恢复策略，而不会强化错误。通过强调学习正确操作，直接减少了核心推理失败，如 "错误实现" 和 "定位错误"。

• 改进 2：基于难度的课程学习

核心思想：从简单任务开始，逐步增加难度。

SWE-Lego 探索了两种难度分类方法：基于模型的评分和基于轨迹轮数的启发式。研究发现，轨迹轮数与解决率之间存在强负相关（相关系数 - 0.95）。基于这一发现，SWE-Lego 采用可以直接获取的指标，轨迹轮数，作为轨迹的难度指标，将数据分为三个难度等级：简单（0-50 轮）、中等（50-70 轮）、困难（70-100 轮）。训练策略采用三阶段课程：先训练简单任务，再逐步加入中等和困难任务。这种课程学习与训练动态一致：首先让模型在 "简单" 任务上克服基本的 "无法复现" 错误，然后引入 "困难" 任务以发展避免 "超出最大轮次" 失败所需的战略规划。

图 8：轨迹轮次与平均解决率之间的强负相关关系

• 训练过程分析

通过分析训练过程中的错误类型演变，可以清楚地看到模型的学习轨迹：

图 9：训练过程中解决率的提升趋势

图 10：训练过程中错误类型的演变，从早期的 "无法复现" 到后期的 "错误实现"

错误类型的变化：训练初期时 "无法复现" 错误占主导，表明模型此时缺乏对软工任务基本的理解能力；训练中期时 "无法复现" 比例大幅减少，但 "定位错误" 比例仍有较多，表明缺乏战略规划；训练后期 "错误实现" 成为瓶颈，表明从过程失败转向推理失败。

改进的 SFT（错误掩码 + 课程学习）带来 3.8% 的性能提升。在 SWE-bench Verified 上，SWE-Lego-Qwen3-8B 达到 42.2%，SWE-Lego-Qwen3-32B 达到 52.6%。通过渐进式训练和选择性学习，模型能够更有效地掌握复杂任务。

核心组件三：测试时扩展

测试时扩展（TTS）可以在不重新训练的情况下，通过在测试阶段分配额外的计算资源来提升性能。SWE-Lego 系统研究了两个正交维度：

• 维度 1：串行扩展 vs 并行扩展

SWE-Lego 研究了串行扩展和并行扩展之间的资源分配。串行扩展通过增加最大交互轮次实现，在低测试预算的区域非常高效。额外轮次都能获得环境反馈，使模型能够纠正错误并迭代改进解决方案。这使得串行扩展在预算有限时成为首选策略。然而，模型性能在约 100-140 轮后开始饱和，此时相比于串行扩展，更加需要并行扩展来提升性能。

并行扩展生成多个候选轨迹，用打分器选择最佳的轨迹。在串行扩展饱和后，并行扩展变得更加有效，因为每个独立轨迹探索解决方案空间的不同路径。

图 11：串行扩展和并行扩展的权衡，等延迟曲线显示了最优资源分配策略

在有限的测试阶段计算预算下，应优先进行串行扩展；在串行扩展饱和后，将剩余计算资源分配给并行扩展。图 11 中的等延迟等高线说明了这种权衡：在等效延迟下，最优分配随着总延迟预算的增加从顺序主导转向并行主导。

• 维度 2：生成式 vs 回归式打分器

打分器用于从多个候选轨迹中选择最佳方案。SWE-Lego 比较了两种范式：回归式打分器和生成式打分器。

回归式打分器在模型上添加一个头输出，使用二元交叉熵损失训练，对整个轨迹转化为单个标量去打分。生成式打分器将验证表述为文本生成任务，预测 "是" 或 "否"，从输出 "是" 或 "否的"token 概率计算分数。生成式打分器的训练目标与预训练的下一个 token 预测目标对齐，可能更好地利用模型的固有知识。

图 12：生成式打分器与回归式打分器的对比，生成式打分器在 K 值较大时持续改进

在 rollout 的个数（K 值）比较小时，生成式打分器与回归式打分器两者的性能相近；随着 rollout 的次数（K）的增加，回归式打分器趋于饱和，而生成式打分器持续改进。对于 SWE-Lego-Qwen3-8B，在 K=16 时差距达到 2.8%（49.6% vs 46.8%）。

图 13：SWE-Lego 打分器与现有公开打分器的对比

SWE-Lego-Verifier-8B 在 TTS@16 上达到 49.6%，超越了 OpenHands-Critic-32B（44.0%）和 R2E-Gym-Verifier-14B（47.0%）。除了绝对性能外，还观察到不同打分器范式的定性不同缩放行为。OpenHands-Critic-32B 采用回归式范式，在更高的 K 值下表现出性能下降，这是一个反直觉的结果，表明更大的候选池压倒了其判别能力。相比之下，生成式打分器（SWE-Lego 和 R2E-Gym）保持单调改进，趋向于 Pass@K 上限，进一步确认生成式表述提供了更稳健的缩放属性。

总结：测试时扩展可以在测试阶段带来额外提升。在测试的计算预算比较低的时候，串行扩展优先于并行扩展。生成式打分器在并行扩展中表现更优。

三、结语与展望

SWE-Lego 证明了轻量级方法也能达到 SOTA，不一定需要复杂的 RL 或 SFT 和 RL 的迭代训练，SFT 也可以取得软工任务的 SOTA 性能。数据质量至关重要，混合数据集和严格验证是性能提升的关键。训练技巧的价值也不容忽视，错误掩码和课程学习等看似简单的改进也带来了性能提升。

未来将探索更大模型和更多数据的组合，扩展到 Python 之外的其他编程语言和其他类型的代码任务，处理企业级的长序列、多文件任务，并将 SWE-Lego 应用到真实的软件开发流程中。

参考文献

[1] Badertdinov, I., Golubev, A., Nekrashevich, M., Shevtsov, A., Karasik, S., Andriushchenko, A., ... & Yangel, B. (2025). SWE-rebench: An Automated Pipeline for Task Collection and Decontaminated Evaluation of Software Engineering Agents. arXiv preprint arXiv:2505.20411.

[2] Yang, J., Lieret, K., Jimenez, C. E., Wettig, A., Khandpur, K., Zhang, Y., ... & Yang, D. (2025). Swe-smith: Scaling data for software engineering agents. arXiv preprint arXiv:2504.21798.

[3] https://github.com/SWE-bench/SWE-bench/issues/465

© THE END

转载请联系本公众号获得授权

投稿或寻求报道：liyazhou@jiqizhixin.com