SWE-bench直播上线！微软携手上海人工智能实验室推出实时更新的代码修复基准测试

2025年5月29日，微软和上海人工智能实验室的研究团队联合发布了一篇重要论文《SWE-bench Goes Live!》（arXiv:2505.23419v1）。这项由微软实习生Linghao Zhang和对应作者Shilin He领导的研究，为软件工程领域的大语言模型评估带来了全新的基准测试方法。论文已在arXiv预印本平台公开，研究团队同时提供了完整的代码库、数据集和在线排行榜。

在软件开发领域，大语言模型（LLM）已经彻底改变了我们的工作方式。从GitHub Copilot到Cursor等工具，它们已经成为现代开发流程中不可或缺的助手，帮助开发者自动生成代码、检测bug并解决问题。为了评估这些模型在真实软件工程任务上的表现，研究人员开发了各种基准测试，其中SWE-bench及其变体因为聚焦于真实世界的代码问题解决能力，逐渐成为业界标准。

然而，这些现有的基准测试存在三个关键问题：首先是数据老化问题，SWE-bench自2023年10月发布以来从未更新，这导致新模型可能已经在训练中"见过"这些测试案例；其次是仓库覆盖有限，仅包含约12个代码仓库，缺乏多样性；最后是高度依赖人工建设，从案例构建到环境搭建都需要大量手工劳动。想象一下，你有一套多年不变的考题，学生迟早会背下所有答案，这并不能真实反映他们的实力。

为了解决这些问题，研究团队推出了SWE-bench-Live，这是一个能够持续更新的基准测试平台。想象它就像一个永不重复考题的考试系统，不断收集最新的真实世界软件问题，确保AI模型不可能通过"记忆"答案获得高分。该平台的初始版本包含1,319个来自93个代码仓库的真实GitHub问题，这些问题全部是2024年以来创建的，确保了数据的新鲜度。每个测试任务都配有专用的Docker镜像，保证了执行环境的一致性和可重现性。

SWE-bench-Live的核心是一个名为REPOLAUNCH的自动化流水线。想象它像一个自动化的考试出题系统，能够从GitHub上找到有价值的问题，为每个问题准备好评估环境，并验证解决方案的正确性。这个系统解决了以往基准测试构建过程中最费时费力的环节——环境配置。

在传统的SWE-bench中，研究人员需要手动为每个代码库设置环境，这就像为每道考题手工准备一套实验设备一样繁琐。而REPOLAUNCH则像一个熟练的实验室助手，能够自动识别项目的依赖项、选择合适的基础环境、安装必要的软件包，并确保测试能够正常运行。这种自动化不仅大幅提高了效率，还保证了环境配置的一致性和可靠性。

为了验证SWE-bench-Live的实用性，研究团队使用多种最先进的代码助手和大语言模型进行了测试，包括OpenHands、SWE-Agent和Agentless框架，搭配GPT-4.1、GPT-4o、Claude 3.7 Sonnet和DeepSeek V3等模型。测试结果令人深思：即使是表现最好的组合——OpenHands搭配Claude 3.7 Sonnet，在SWE-bench-Live上的解决率也只有19.25%，远低于它们在SWE-bench验证集上的43.20%。

这种显著的表现差异突显出动态、新鲜基准测试的重要性。通过对仓库来源、问题新近度和任务难度的详细分析，研究团队发现性能差距不仅来自基准测试的熟悉度，还源于SWE-bench-Live提供的更广泛的代码库和问题类型多样性。

一个特别有趣的发现是，模型在修复单文件、小范围的代码问题时表现相对较好（约48%的成功率），但一旦需要修改多个文件或大量代码行，成功率就急剧下降至不到10%。同样，在较小的代码库（少于100个文件和2万行代码）上，模型通常能达到20%以上的解决率，而在大型项目上则很少超过5%。

研究团队计划每月更新SWE-bench-Live，持续提供新的测试案例，确保它能够反映软件开发领域的最新变化和挑战。这种持续更新的特性使SWE-bench-Live成为评估代码大语言模型真实能力的更可靠工具，为未来的研究和开发提供了坚实的基础。

对于普通开发者而言，SWE-bench-Live的出现意味着我们可以更准确地了解当前AI编码助手的真实能力和局限性。当我们在日常工作中使用这些工具时，了解它们在什么类型的问题上更可能成功，什么情况下可能需要更多人工干预，这对提高工作效率至关重要。

此外，REPOLAUNCH作为一个独立工具已经开源，它不仅对基准测试构建有价值，对日常开发也有实用价值。开发者可以使用它来快速为陌生或遗留代码库设置开发环境，简化项目入门过程。

总的来说，SWE-bench-Live代表了软件工程领域AI评估方法的一次重要进步。通过提供持续更新、多样化、可执行的基准测试，它为代码大语言模型的公平评估铺平了道路，也为研究人员和开发者提供了更清晰的发展方向。

SWE-bench-Live的构建流程

SWE-bench-Live遵循一个三阶段的构建流程，类似于一条自动化的生产线，将原始的GitHub问题转化为标准化的测试任务。

第一阶段是原始问题和修复抓取。研究团队从GitHub上筛选出符合条件的代码仓库——这些仓库必须星标超过1,000，以Python为主要语言，拥有200多个问题和PR，超过200个分叉，至少60%的代码是Python，并且带有有效的开源许可证。经过这些筛选，最终确定了2,609个适合的仓库。从这些仓库中，团队提取了2024年1月之后创建的问题及其对应的修复PR，确保数据的新鲜度，降低数据污染风险。

第二阶段是自动化环境设置，这是整个流程中最具创新性的部分。传统上，为代码问题创建执行环境是一项极其耗时的工作，SWE-Gym报告称，他们花了超过200小时来为一个相对较小的数据集设置环境。REPOLAUNCH彻底改变了这一过程。

REPOLAUNCH就像一个熟练的开发者，它能够阅读项目文档，尝试各种命令，解决出现的错误，并不断调整策略直到环境配置成功。具体来说，它首先会识别项目中的重要文件，如README、CI/CD配置等；然后根据这些信息选择合适的Docker基础镜像；接着在容器中启动一个交互式会话，开始逐步安装依赖、构建项目；最后验证测试是否可以正常运行。

特别值得一提的是，REPOLAUNCH引入了一个"时间机器"机制来解决版本不兼容问题。在设置历史代码库的环境时，一个常见挑战是依赖版本漂移——未固定的依赖项会解析到最新的包版本，导致向后不兼容性，经常破坏构建。REPOLAUNCH通过一个自定义的代理服务器解决了这个问题，该服务器只允许使用截至代码库基础提交时间点之前发布的包版本。这就像真的让环境回到了那个时间点，确保兼容性。

第三阶段是任务实例验证。每个候选任务必须经过严格测试，确保PR的修复确实解决了问题，并且这种修复是可靠稳定的。研究团队重点关注两种测试结果变化：从失败到通过的转变（表明bug被修复了）和持续通过的测试（表明修复没有引入新问题）。为了处理不同测试框架的输出格式，团队开发了专门的解析器。只有展示出至少一个从失败到通过转变的任务才会被纳入基准测试，而且必须在多次运行中表现一致，避免测试不稳定性的干扰。

通过这三个阶段的处理，最终构建出的SWE-bench-Live数据集包含1,319个任务实例，来自93个开源Python仓库。这些任务在时间上分布均匀，涵盖了2024年1月至2025年4月的问题。从仓库类别来看，数据集涵盖了多种应用领域，包括AI/ML（26个仓库）、DevOps（23个）、Web开发（17个）、数据库（8个）和科学计算（8个）等，保证了问题类型的多样性。

为了支持轻量级实验，研究团队还提供了一个名为SWE-bench-Live-Lite的子集，通过从2024年10月至2025年3月期间每月抽样50个实例，形成了一个紧凑的300实例集合，平衡了新近性、多样性和评估效率。

模型评估和发现

在SWE-bench-Live上的评估结果揭示了当前代码大语言模型和助手在真实世界代码修复任务上的能力和局限。研究团队使用了三种代表性的代理框架进行测试：通用编码代理OpenHands（搭配CodeAct代理）、专为问题解决设计的SWE-Agent和Agentless。每个框架都与四种先进的大语言模型搭配：GPT-4o、GPT-4.1、Claude 3.7 Sonnet和DeepSeek V3。

测试的主要指标是解决率（成功修复问题的百分比）、补丁应用率（语法正确并能成功应用的补丁百分比）以及定位成功率（识别出正确修改文件的能力）。

在lite子集上的测试结果显示，Claude 3.7 Sonnet搭配OpenHands或SWE-agent的组合表现最佳，两者都达到了17.67%的解决率。GPT-4.1搭配SWE-agent紧随其后，达到16.33%。有趣的是，DeepSeek V3展现了很强的竞争力，在三种框架中都取得了不错的成绩（13.00%至15.33%）。

当研究团队将表现最好的三种组合在完整数据集上进行测试时，发现OpenHands/Claude 3.7 Sonnet达到了19.25%的解决率，略高于SWE-agent/GPT-4.1的18.57%。

这些结果与同样的模型和代理在SWE-bench上的表现形成了鲜明对比。为了进行公平比较，研究团队使用完全相同的设置（OpenHands/Claude 3.7 Sonnet）在SWE-bench验证子集上进行了测试，得到的解决率高达43.20%，是其在SWE-bench-Live上表现的两倍多。

为了深入理解这种性能差距，研究团队按照仓库来源对SWE-bench-Live实例进行了分类。有216个实例来自8个原始SWE-bench中包含的仓库，而剩余的1,103个实例来自新的仓库。有趣的是，即使在非SWE-bench仓库通常更简单（文件更少，代码量更小）的情况下，模型在原SWE-bench仓库上的表现仍然更好——解决率为22.96%，而在新仓库上仅为18.89%。这支持了一个假设：当前的代理模型可能对SWE-bench数据集过度拟合或隐式优化。

研究团队还分析了问题创建时间与解决率的关系，发现从2024年第一季度到2025年第一季度，解决率相对稳定，仅在2024年第四季度有轻微下降。这表明较新的问题并不本质上更难解决，SWE-bench-Live提供了一致的挑战水平。

最后，研究人员从两个互补的角度分析了任务难度：补丁难度（由修改的文件数量和行数衡量）和仓库难度（由项目的整体大小衡量）。

结果显示，当修复局限于单个文件且修改少于5行代码时，模型表现最好，接近48%的成功率。但随着任务规模的扩大，性能迅速下降——一旦补丁编辑3个或更多文件，或跨越超过100行代码，成功率就降至10%以下；对于修改7个或更多文件的补丁，甚至从未成功解决。

同样，仓库规模也显著影响成功率。对于小型项目（少于100个文件和2万行代码），模型通常能达到20%以上的解决率，而对于超过500个文件的大型项目，很少超过5%。

这些发现清晰地表明，当前的代码代理在协调跨多文件的连贯编辑或处理大型内部文件变更方面存在明显局限。因为SWE-bench-Live涵盖了这些难度因素的全谱，同时不断添加新的、未见过的实例，它为大规模程序修复的未来进展提供了严格且最新的测试平台。

SWE-bench-Live的意义与展望

SWE-bench-Live的推出标志着代码大语言模型评估方法的一次重要变革。通过解决静态基准测试的三大核心问题——数据老化、有限覆盖和手工构建瓶颈，它为软件工程领域的AI系统提供了更公平、更真实的评估标准。

对于研究人员来说，SWE-bench-Live的持续更新特性尤为宝贵。想象一下，这就像为AI系统提供了一个永不停止的挑战赛，每个月都会有新的、前所未见的问题需要解决。这种设计从根本上避免了数据污染和过度拟合的风险，确保评估结果能够真实反映模型的泛化能力，而非简单的记忆表现。

对于开发者来说，SWE-bench-Live提供的多样化仓库和问题类型，让我们能够更清晰地了解当前AI编码工具的能力边界。它揭示了现有模型在处理单文件小修改时相对得心应手，但在涉及多文件协调或大规模代码库时仍面临显著挑战。这种认识有助于开发者更有效地利用这些工具，知道何时可以依赖AI助手，何时需要更多人工介入。

而REPOLAUNCH作为一个独立工具的价值也不容忽视。在软件开发中，环境配置一直是一个令人头疼的问题，特别是对于陌生或遗留代码库。REPOLAUNCH提供的自动化环境设置能力，不仅服务于基准测试构建，也能直接应用于实际开发工作流，帮助开发者快速上手新项目，提高工作效率。

从更广泛的角度看，SWE-bench-Live代表了AI评估方法的一个重要趋势——从静态、封闭的测试向动态、开放的评估转变。这种转变不仅适用于代码生成和修复领域，也可能影响其他AI应用领域的评估方法。

随着SWE-bench-Live的持续更新和扩展，我们可以期待它在未来涵盖更多编程语言和应用场景。目前，它主要关注Python仓库，但研究团队已经表示计划将其扩展到Java、Go等其他语言。这种扩展将进一步提升基准测试的代表性和实用价值。

对于普通开发者而言，SWE-bench-Live的出现意味着我们可以对AI编码助手的评价更加客观和理性。当我们在日常工作中使用GitHub Copilot或Cursor等工具时，了解它们的真实能力和局限性，能够帮助我们形成更合理的期望，更有效地与这些工具协作，而不是过度依赖或完全排斥。

总的来说，SWE-bench-Live不仅是一个新的基准测试，更是软件工程领域AI评估方法的一次重要创新。通过提供新鲜、多样、可执行的测试案例，它为代码大语言模型的公平评估铺平了道路，也为未来的研究和开发指明了方向。正如研究团队所言，它建立了"评估代码LLM和基于代理系统真实能力的新的、稳健的标准"。