SWE-rebench V2：语言无关的大规模软件工程任务收集 SWE-rebench V2: Language-Agnostic SWE Task Collection at Scale
提出语言无关的自动化管道，从GitHub大规模收集可执行的软件工程任务用于训练智能体
前置知识
软件工程智能体 (SWE agent)
能够自主解决代码仓库中真实问题的AI系统，通常基于大语言模型构建，通过工具交互在代码库中定位问题、提出补丁并验证修复。这类智能体需要理解代码结构、项目依赖和测试框架，能够在GitHub issue描述的指导下，自主进行代码修改和测试验证。当前最先进的SWE智能体已经在SWE-bench等基准测试上取得了显著进展，但其能力提升严重依赖大规模高质量的训练数据。
本文的核心目标就是为这类智能体提供大规模训练数据，理解SWE智能体的工作原理是把握论文价值的前提。
强化学习 (Reinforcement Learning)
一种通过试错学习最优策略的机器学习范式，智能体在环境中执行动作并根据奖励信号调整行为。在软件工程任务中，RL训练通常使用测试通过率作为奖励信号，让智能体学习如何更有效地修复代码。RLHF（基于人类反馈的强化学习）已经在大语言模型对齐中取得成功，而在SWE任务中，自动化测试提供了更客观的奖励信号。
本文强调RL训练是推动SWE智能体能力提升的关键驱动力，而大规模可执行任务是RL训练的瓶颈，这直接解释了论文的研究动机。
fail-to-pass测试
指在修复代码前失败、修复后通过的测试用例，是验证代码修复是否正确的自动化检查机制。在SWE-bench系列基准测试中，每个任务都包含一组fail-to-pass测试，智能体需要通过修改代码使这些测试从失败变为通过。这种测试预言机提供了客观、可重复的评估标准，避免了人工判断的主观性。
本文的管道核心就是自动化提取fail-to-pass测试，这是构建可靠评估环境的基础，理解其工作原理对理解整个管道至关重要。
可复现执行环境
包含代码仓库、所有依赖和运行时配置的完整执行环境，通常以Docker镜像形式封装，确保测试可以在任何机器上一致地运行。在软件工程任务中，正确的依赖安装和环境配置是测试能够稳定运行的前提。可复现性是科学研究的基本要求，对于需要大量交互式训练的RL任务尤其关键，因为训练过程需要反复执行测试来获取奖励信号。
本文的核心贡献之一就是大规模构建跨语言的可复现执行环境，解决了训练数据稀缺的基础设施问题，理解这一概念有助于把握论文的技术难点。
研究动机
现有软件工程智能体训练面临严重数据瓶颈。强化学习等交互式学习范式需要大量带有稳定奖励信号的任务，但在仓库级别的代码修复场景中，这种稳定性依赖于三个关键条件：正确的依赖安装、可靠可复现的测试执行、以及自然语言问题描述与测试预言机的对齐。目前可用的训练数据集极其有限，且大多针对Python等高资源语言设计，难以覆盖Go、Rust、Scala等长尾语言生态系统。例如，SWE-bench系列虽然推动了评估标准化，但其构建成本高昂，规模通常限制在几千个任务，远不足以支撑大规模RL训练。Multi-SWE-bench和SWE-PolyBench虽然扩展了语言覆盖，但仍以评估为导向，缺乏训练所需的大规模可执行环境和丰富的诊断元数据。这种数据稀缺性严重制约了SWE智能体在多样化真实场景中的能力提升，特别是对于长尾语言生态系统，缺乏训练数据导致智能体在这些语言上的性能远低于Python等主流语言。
本文的目标是本文旨在构建一个语言无关的自动化管道，从全球GitHub活动中大规模收集可执行的软件工程任务。具体目标包括：第一，实现真正的语言无关性，同一套构建流程能够处理20种不同的编程语言，包括长尾语言；第二，达到足够的规模以支持RL训练，目标产出超过30,000个可验证的容器化任务；第三，提供训练导向的完整资源包，包括预构建Docker镜像、安装测试脚本和丰富的诊断元数据；第四，通过自动化流程避免对单个人工验证的依赖，将构建成本降低到可接受水平。这些目标直接回应了当前SWE智能体训练面临的数据规模和多样性瓶颈，旨在为RL训练提供可靠的基础设施。
与已有工作不同的是，本文的独特视角在于同时抓住了三个被忽视的关键点。首先，现有工作大多以评估为导向设计，而本文明确以训练为导向，提供了RL训练所需的完整资源包，包括可直接执行的Docker镜像和详细的交互轨迹。其次，现有管道在语言覆盖上存在明显局限，通常只在少数几种语言上验证有效性，而本文强制实施统一的构建流程，通过少量可复用的语言特定模板实现真正的语言无关性。第三，现有数据集普遍缺乏任务级别的诊断信息，无法区分模型能力限制和环境病理问题，而本文通过系统化的诊断分析，为每个任务标注了详细的质量元数据，使得研究者能够进行分层过滤和课程设计。这些差异化的定位使得SWE-rebench V2能够同时满足评估和训练的双重需求，填补了训练数据稀缺的空白。
核心方法
SWE-rebench V2的构建流程可以类比为一条自动化的任务生产线。想象一个工厂，原料是GitHub上数以百万计的Pull Request，经过五个加工站后，产出是带有可执行测试环境的标准化训练任务。第一站是选矿，从GitHub Archive中挖掘候选PR，通过语言、星标、关闭issue数等粗筛条件快速过滤。第二站是精炼，部署交互式设置代理，为每个仓库自动推断安装和测试脚本，这个代理能够像人类工程师一样通过试错来解决问题。第三站是质检，通过多次执行验证环境稳定性，提取fail-to-pass测试作为任务信号。第四站是分拣，使用LLM集成器过滤问题描述不清晰的任务。第五站是贴标签，为每个任务添加诊断元数据，标注潜在的质量问题。整个流程在保持语言无关性的同时，通过少量语言特定模板实现跨语言支持，最终产出可直接用于RL训练的标准化任务数据集。
本文的核心创新在于交互式设置代理与LLM质量过滤的深度集成。传统非交互式管道依赖固定的文件分析序列生成安装指令，这种方法在结构化良好的Python生态系统中尚可，但在长尾语言的非标准工具链面前显得力不从心。SWE-rebench V2采用的交互式代理基于mini-SWE-agent框架，使用Qwen3-Coder-480B-A35B-Instruct作为底层模型，能够在闭合循环中检查代码库、尝试依赖安装，并根据观察到的构建错误和测试失败迭代优化脚本。这种交互能力使得代理能够处理复杂的多语言构建场景，例如在编译语言中，应用补丁后需要显式重新编译才能执行更新后的二进制文件。另一个关键创新是将质量过滤直接集成到构建漏斗中，使用三个独立的LLM评分员（gpt-oss-120b、GLM-4.7、DeepSeek-V3.2）评估问题清晰度，只有当所有三个评分员都认为规格充分时才保留任务。这种集成策略在保持高精度的同时，有效过滤了不明确的任务，确保了训练数据的质量。
方法步骤详情
管道包含五个顺序执行的阶段。第一阶段是初步数据收集：从GitHub Archive聚合公共活动，连接issue和PR元数据，克隆仓库从本地git历史中提取补丁，避免每实例的API请求。应用语言和关闭issue数量过滤，保留许可证宽松、对应已解决issue和已合并PR的候选。将整体拆分为解决方案补丁（非测试文件）和测试补丁（仅测试文件），最终产出约21,000个仓库和580,000个任务实例。第二阶段是设置合成：为每种语言预构建基础Docker镜像，包含运行时和核心工具集。使用Qwen3-Coder-480B-A35B-Instruct模型从模板生成基础Dockerfile。通过交互式设置代理为每个仓库推断安装和测试脚本，代理在闭合循环中调试，成功定义为运行项目测试套件而无基础设施或依赖失败。第三阶段是执行验证：应用测试补丁运行完整测试套件，然后应用解决方案补丁再次运行，产生修复前后的配对执行轨迹。每个候选任务运行三次，只保留结构化测试结果在运行间保持不变的实例。第四阶段是问题清晰度过滤：使用三个独立LLM评分员评估问题描述，采用Verified-E配置（同时提供问题描述、补丁和测试补丁），只有所有评分员都评为充分的任务才保留。第五阶段是元数据丰富：使用gpt-oss-120b模型自动注释每个任务的潜在限制和特征，生成辅助接口信息，包括方法/类名、签名和简要描述。
技术新颖性
SWE-rebench V2的技术新颖性体现在三个维度。第一，交互式设置代理相比非交互式管道的显著优势。实验显示，使用Qwen3-Coder-30B-A3B-Instruct的交互式代理能够超越使用Qwen3-Coder-480B-A35B-Instruct的非交互式管道，证明了交互机制本身的价值。这种优势源于代理能够像人类工程师一样通过试错来发现正确的构建配置，而不是依赖预设的规则。第二，语言无关性的工程实现。通过强制统一的构建流程，仅依赖少量可复用的语言特定模板（基础镜像、运行器、解析器），实现了20种语言的规模化支持。这种设计避免了为每种语言定制完整流程的工程负担，同时保持了足够的灵活性来处理不同生态系统的特殊性。第三，诊断驱动的质量保证。通过系统化分析七个前沿模型在300个任务上的运行轨迹，识别出测试套件耦合、隐式命名要求、外部依赖等七类环境病理问题，并基于此为每个任务添加诊断元数据。这种基于实证的质量评估方法，相比简单的通过/失败二分法，提供了更丰富的任务特征信息，支持更精细的数据筛选和课程设计。
实验结果
实验结果展示了管道的有效性和规模。最终数据集包含32,079个任务，跨越2014-2025年，覆盖20种编程语言，来自3,617个仓库。Python（21.6%）和Go（20.6%）领先，其次是JS/TS、Rust等。任务修改中位数为3个文件和34行代码，但分布重尾（第90百分位为9个文件/181行）。安装代理实验显示，交互式设置显著优于非交互式基线：使用Qwen3-480B的交互式代理pass@1为25.8%，pass@10为58.8%，而非交互式设置的pass@1仅为12.1%。增加设置尝试次数能够提高成功概率：从一次到十次运行，成功安装仓库的比例几乎翻倍。问题清晰度过滤实验显示，Verified-E配置（提供问题描述、补丁和测试补丁）达到最高精度0.83，但召回率较低0.10。模型性能分析显示，Claude Opus-4.5在Python上表现最佳（pass@1 36.11%），而在Scala上表现最弱（pass@1 19.44%），反映了语言特定挑战。诊断元数据验证显示，Code A任务（可干净解决）的通过率显著高于B*任务（有诊断标签），例如Gemini在Code A上pass@3为34.0%，在B*上仅为4.0%，证明元数据有效分离了干净任务和噪声任务。这些结果表明，管道能够大规模生产高质量的训练数据，同时通过诊断元数据支持精细化的任务筛选。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| 设置合成 | pass@1 | 25.8%（Qwen3-480B交互式） | 12.1%（非交互式） | +13.7个百分点 |
| Python问题解决 | pass@1 | 36.11%（Claude Opus-4.5） | 8.89%（gpt-oss-120b） | +27.22个百分点 |
| 任务质量分类 | 通过率差异 | Code A 34.0% vs B* 4.0%（Gemini pass@3） | 无直接对比 | 证明元数据有效分离任务质量 |
局限与改进
论文承认了几个主要局限。首先，虽然管道设计为训练基底，但本文未包含端到端RL训练消融实验，因为大规模多语言RL运行需要大量额外基础设施。这意味着管道的有效性还需要在实际训练场景中进一步验证。其次，Docker镜像虽然使主数据集对仓库演化具有鲁棒性，但无法消除所有漂移源：外部包仓库、系统包和网络资源可能变化或消失，需要持续维护和定期重建。第三，当前环境设计针对可以可复现地打包到单个Docker容器的项目，这限制了需要多服务、外部数据库、队列或分布式基础设施组件的复杂系统的覆盖。此外，管道的构建成本仍然可观：设置推断处理21,692个仓库，平均每个仓库24.67个交互轮次，总计约535K次模型API调用，按商用API定价约1.9K美元。Docker构建总计约26,400个工作小时，存储占用26.36 TiB。这些成本限制了管道的频繁运行和更新。
独立分析的弱点
基于独立分析，我认为存在以下几个弱点。首先，长尾语言的覆盖率仍然有限。虽然管道支持20种语言，但实验显示Scala等语言的通过率显著低于Python（19.44% vs 36.11%），反映了这些语言生态系统的复杂性。改进方向是针对长尾语言开发专门的设置模板和解析器，可能结合社区贡献来优化构建流程，例如建立语言特定的维护者网络来协助环境调试。其次，问题清晰度过滤的召回率过低（Verified-E配置召回率仅0.10），这意味着大量有效但描述不够清晰的任务被错误过滤。改进方向是开发更细粒度的评分维度，区分完全清晰、基本可用和模糊等级别，并为不同训练阶段提供不同质量阈值的数据子集。第三，诊断元数据的分类相对粗糙（仅A/B1-B7），无法捕捉任务难度的连续变化。改进方向是引入更多维度的元数据，如代码变更复杂度、测试覆盖范围、依赖链深度等，支持更精细的课程设计。第四，管道的维护成本较高，需要持续监控外部依赖变化并定期重建环境，这限制了数据集的长期可用性。
未来方向
作者提出了几个未来方向，基于现有成果还可以延伸更多。作者计划的扩展包括：增加设置重试次数以提高产量，策划更多子集，接入更多长尾语言。未来工作将针对将管道扩展到支持复杂、长期任务，如需要迭代跨组件修改的多服务系统。还将研究丰富超越测试正确性的奖励信号，包括自动可测量的非功能性需求如性能、延迟和内存效率。基于现有成果的延伸方向包括：第一，利用诊断元数据进行RL训练的课程设计研究，探索从干净任务逐步引入噪声任务的最优策略；第二，开发跨语言迁移学习方法，利用高资源语言的训练数据提升长尾语言的智能体性能；第三，构建更大规模的PR衍生任务数据集（已超过120,000个），研究不同问题表述对训练效果的影响；第四，开发轻量级环境构建技术，减少Docker镜像的存储和构建开销；第五，探索主动学习策略，智能选择最有价值的任务进行环境构建，提高数据收集效率。
复现评估
本文在可复现性方面做出了显著努力。首先，完全开源了数据集和构建代码，数据托管在HuggingFace上（nebius/SWE-rebench-V2和nebius/SWE-rebench-V2-PRs）。提供了预构建的Docker镜像，总计26.36 TiB存储，确保任务可以在任何支持Docker的环境中一致执行。详细记录了所有提示模板（附录A.3），包括基础Dockerfile生成、设置合成、日志解析器生成、问题陈述生成等关键步骤的精确提示。提供了丰富的诊断元数据，支持研究者根据特定需求筛选任务子集。复现的主要挑战在于计算成本：完整构建运行需要约26,400个工作小时的Docker构建时间和约1.9K美元的API调用费用。对于资源有限的团队，可以基于已发布的数据集进行训练和评估研究，而无需重新运行完整构建流程。数据集的维护需要持续投入，因为外部依赖可能变化，需要定期重建环境。总体而言，本文为可复现性设立了较高标准，但完全复现仍需要相当的计算资源和工程投入。
论文图表
