[2025] SWE-rebench V2：破解 SWE Agent 训练荒，跨 20 种语言的大规模自动化可执行任务集

TL;DR

软件工程（SWE）Agent 的进化正从“仅评估”转向“大规模强化学习训练”，但开发者面临的核心瓶颈是：缺乏涵盖多语言、可稳定复现的、带测试反馈的训练环境。SWE-rebench V2 横空出世，通过一种语言无关（Language-Agnostic）的自动化流水线，不仅将任务规模推到了 3.2 万个（可执行）和 12 万个（PR 衍生），更重要的是，它实现了从 2014 到 2025 年间、覆盖 20 种编程语言的端到端自动化环境配置。

痛点深挖：为什么大规模 SWE 数据这么难做？

目前的 SWE 基准测试（如 SWE-bench）主要集中在 Python 生态，且大多依赖人工校验来保证质量。当研究者想要利用强化学习（RL）通过测试反馈来优化模型时，会遇到三个“硬骨头”：

1. 环境异构性：不同语言、不同仓库的构建系统（Maven, npm, Cargo等）千差万别，手动配置成本极高。
2. 测试不稳定性（Flaky Tests）：自动化提取的测试可能因为环境依赖或代码耦合导致不确定性的失败。
3. 任务描述模糊：GitHub 上的原始 Issue 往往描述不清（Underspecified），导致 Agent 即使逻辑正确也无法通过测试。

核心方法论：交互式 Setup Agent 与多模型过滤

SWE-rebench V2 的核心创新在于它不再使用死板的脚本，而是引入了一个交互式的调试循环。

1. 架构解析：交互式环境合成

系统会根据仓库特征生成基础 Dockerfile，并部署一个基于 Qwen3-Coder 的 Setup Agent。这个 Agent 会在终端执行命令，观察报错信息（如编译错误、缺少依赖），然后自我迭代地修复安装脚本。这种“观察-执行-修复”的闭环显著提升了长尾语言仓库的安装成功率。

表 1：SWE-rebench V2 的五阶段过滤漏斗，从 2950 万 PR 中精炼出可执行任务

2. 多模型“评审团”过滤

为了确保任务描述的质量，作者采用了 GPT-OSS、GLM-4 和 DeepSeek-V3 三个 SOTA 模型组成评审团。只有当三个模型一致认为 Issue 描述足够清晰时，任务才会被选入核心数据集。这种 Consensus 机制极大提升了数据作为训练信号的 Precision。

实验与结果：多语言能力的大型阅兵

作者挑选了 7 种顶尖模型（包括 Claude 4.5、Gemini 3、DeepSeek V3.2 等）在 Python, JS, Go, Rust, Scala 五种语言上的 300 个随机任务进行评测。

表 2：顶尖模型在不同语言下的 pass@1 表现，Claude Opus-4.5 展现了最强的多语言适应性

关键发现：

• 交互式优于静态：相比非交互式流水线，交互式 Agent（如 DeepSeek 驱动）在环境安装后的 pass@10 成功率提升了近 300%（从 15.7% 升至 59.8%）。
• 诊断标签赋能：作者为任务打上了 B1（测试套耦合）、B2（隐式命名需求）等标签。结果显示，模型失败往往不是因为逻辑错，而是因为测试中包含了 Issue 里没提到的“强制函数命名”。这为未来的课程学习（Curriculum Learning）提供了依据。

深度洞察：数据噪声是 RL 的下一个战场

SWE-rebench V2 不仅仅是一个数据集，它其实是对“自动化 SWE 研究可行性”的一次深度验证：

1. 测试反馈并非金标准：作者诚实地揭示了即使 SOTA 模型修补好了 Bug，也可能因为导致了无关模块的 Regression 而被判定为失败。这种“信噪比”问题将是 RL 算法必须解决的。
2. PR 描述作为新边界：通过直接从 PR 描述生成问题（而不是依赖传统的 Issue Link），数据集规模扩大了 4 倍。这对需要海量样本的轨迹合成（Trajectory Synthesis）至关重要。

总结

SWE-rebench V2 填补了从“实验室玩具”到“工业级训练基座”的鸿沟。它告诉我们，要训练真正强大的工程师模型，我们需要的不再是单纯的 Issue 对，而是一套能够自我感知的、带有丰富诊断元数据的多语言可执行生态系统。

局限性：目前系统主要支持单容器任务，对于需要外部数据库或复杂微服务编排的工程任务，环境配置依然是未来的挑战。