基于大语言模型的软件工程问题修复：进展与前沿综述 Advances and Frontiers of LLM-based Issue Resolution in Software Engineering: A Comprehensive Survey
首篇系统综述LLM在SWE问题修复中的数据、方法与分析，涵盖175篇论文
前置知识
SWE-bench
SWE-bench 是由 Jimenez 等人在 2024 年提出的软件工程基准测试，通过从热门 Python 开源仓库（如 scikit-learn、Django 等）中收集真实的 GitHub Issue 和对应的 Pull Request 来构建测试实例。每个实例包含问题描述、完整的代码仓库快照以及用于验证的测试用例。评估时要求模型生成一个补丁（patch）来修复问题，并通过运行测试来判断是否成功。其核心指标是 Resolved Rate（解决率），即成功通过所有测试的实例比例。SWE-bench Verified 是经过人工验证的子集（500 个实例），解决了原始数据集中存在的无效测试和描述不清晰等问题。
SWE-bench 是本文讨论的核心基准，几乎所有方法都在其上进行评估。理解这个基准的设计理念、评估方式和局限性，是理解整篇综述的基础。
Issue Resolution（问题修复）
问题修复是软件工程中的一个复杂任务，要求自动化系统根据自然语言描述的问题报告（issue），在完整的代码仓库中定位相关代码、理解上下文、生成正确的代码修改（patch），并通过测试验证。形式化地，一个实例可以表示为三元组 $I = (D, C, T)$，其中 $D$ 是问题描述，$C$ 是代码库，$T$ 是测试集。评估标准是 $\text{Resolved Rate} = \frac{1}{|I|} \sum_{i=1}^{|I|} r_i$，其中 $r_i \in \{0, 1\}$ 表示第 $i$ 个实例是否通过测试。
这是本文的核心研究对象。与简单的函数级代码生成不同，问题修复需要处理仓库级的复杂性，包括多文件交互、环境配置、测试执行等，这使其成为评估 LLM 真实软件工程能力的关键任务。
Agent-Computer Interface（智能体-计算机接口）
Agent-Computer Interface 是指 LLM 代理与代码执行环境之间的交互机制。它使代理能够自主地进行文件导航、代码编辑和测试执行，将自然语言理解与仓库级操作连接起来。例如，SWE-agent 首创了这种接口设计，允许代理通过 shell 命令浏览文件、搜索代码、编辑文件和运行测试。这种设计的核心在于定义了代理可以使用的工具集（如 bash 命令、文件读写）以及代理与环境之间的反馈循环。
这是理解训练自由方法（training-free methods）的关键概念。不同的接口设计直接影响代理的效率和能力，也是区分不同框架（如 SWE-agent、OpenHands、Agentless）的重要维度。
SFT（Supervised Fine-Tuning，监督微调）与 RL（Reinforcement Learning，强化学习）
SFT 是指使用标注好的数据（如成功的修复轨迹）对预训练语言模型进行微调，使其学会特定的代码修复模式。RL 则通过与环境的交互来优化模型策略，通过奖励信号（如测试是否通过）来指导模型学习。在问题修复场景中，RL 的奖励设计尤为关键，通常包括基于结果的稀疏奖励（如测试通过/失败）和基于过程的密集奖励（如每步操作的反馈）。常用的 RL 算法包括 GRPO（Group Relative Policy Optimization）、PPO（Proximal Policy Optimization）和 DPO（Direct Preference Optimization）。
这两种训练方法是本文方法部分的核心分类。理解 SFT 和 RL 的区别、各自的优缺点以及它们如何结合使用，是理解当前问题修复方法演进的关键。
Inference-time Scaling（推理时扩展）
推理时扩展是一种在不修改模型参数的情况下，通过增加推理时的计算资源来提升性能的策略。在问题修复场景中，这通常表现为：（1）使用蒙特卡洛树搜索（MCTS）等算法进行更深入的解空间探索；（2）并行运行多个独立的代理实例以最大化解决方案覆盖；（3）利用记忆机制生成多样化的经验来指导搜索。这种策略的核心思想是，与其训练更大的模型，不如在推理时投入更多计算来获得更好的结果。
这是当前问题修复研究的重要趋势之一。理解推理时扩展如何与训练方法互补，对于设计高效的修复系统至关重要。
研究动机
随着大语言模型（LLM）在代码生成领域的成功，研究者开始探索更复杂的软件工程任务——问题修复（issue resolution）。然而，现有研究面临多重挑战：首先，现有综述主要关注代码生成，未能系统性地覆盖问题修复这一更复杂的任务。其次，该领域的研究文献高度碎片化，从数据构建、方法设计到评估分析，缺乏统一的分类框架。具体而言，在数据层面，SWE-bench 等基准存在无效测试、描述不清晰等质量问题；在方法层面，从无训练框架到基于训练的方法，技术路线多样但缺乏系统梳理；在评估层面，研究者发现代理的成功率可能因解决方案泄漏、模糊的问题描述和不充分的测试套件而被高估。此外，现有方法在处理多模态任务、跨语言泛化、计算效率等方面仍存在明显不足。
本文的目标是本文的目标是提供该领域首篇系统性综述，通过建立一个涵盖数据（Data）、方法（Methods）和分析（Analysis）三个核心维度的分类框架，对基于 LLM 的问题修复研究进行全面梳理。具体而言，作者希望：（1）系统整理 175 篇公开论文和在线资源，建立该领域的知识图谱；（2）揭示当前方法的优势和局限性，为后续研究提供参考；（3）识别关键挑战并提出有前景的研究方向；（4）通过维护一个开源仓库（https://github.com/DeepSoftwareAnalytics/Awesome-Issue-Resolution）为社区提供持续更新的资源。
与已有工作不同的是，本文的独特切入角度在于其「全栈」视角。与以往专注于代码生成的综述不同，本文聚焦于问题修复这一更具挑战性的任务，并首次将数据构建、无训练方法、基于训练的方法以及实证分析整合到一个统一的框架中。更重要的是，本文不仅关注方法的创新，还深入分析了数据质量和代理行为等被忽视的问题。例如，作者指出 SWE-bench 等基准存在数据泄漏和质量问题，这直接影响了评估的可信度；同时，代理在推理过程中可能出现「分析瘫痪」等行为病理，这些问题在以往的综述中鲜有提及。这种全面的视角使本文成为该领域的权威参考。
核心方法
作为一篇综述论文，本文并没有提出新的技术方法，而是构建了一个系统化的分类框架来组织现有研究。这个框架的设计思路可以类比为一个「三层蛋糕」：底层是数据层（Data），包括评估数据集和训练数据集的构建方法；中间是方法层（Methods），分为无训练方法（training-free）和基于训练的方法（training-based）；顶层是分析层（Analysis），包括数据质量和代理行为的实证分析。这种分层设计使读者能够清晰地理解每个研究贡献在整体图景中的位置，以及不同层次之间的相互作用。例如，数据集的设计直接影响训练方法的选择，而训练方法的性能又需要通过分析来验证和改进。
本文最核心的贡献是建立了问题修复领域的首个系统分类体系。这个分类体系的关键创新在于它不仅涵盖了技术方法，还将数据和分析纳入其中，形成了一个完整的研究范式。在数据维度，本文区分了评估数据集和训练数据集，并详细讨论了数据构建的两个主要途径：自动化数据收集和自动化数据合成。在方法维度，本文将现有方法分为训练自由方法（包括框架、工具模块、记忆模块和推理时扩展）和基于训练的方法（包括 SFT 和 RL）。在分析维度，本文深入讨论了数据质量（如基准缺陷、数据泄漏）和方法分析（如代理行为病理、效率评估）。这种多维度的分类框架为该领域的研究者提供了一张清晰的「地图」，有助于识别研究空白和未来方向。
方法步骤详情
本文的组织结构遵循以下逻辑流程：首先，在「任务定义」部分（第 2 节），作者形式化地定义了问题修复任务，将其实例表示为三元组 $I = (D, C, T)$，并明确了评估指标 Resolved Rate。接着，在「数据」部分（第 3 节），作者系统梳理了评估数据集（如 SWE-bench 系列、多语言和多模态扩展）和训练数据集（如 R2E-Gym、SWE-Gym），并讨论了数据构建的两种范式。然后，在「方法」部分（第 4 节），作者首先介绍无训练方法，包括单代理、多代理和工作流三种框架，以及工具模块、记忆模块和推理时扩展三个子类别；随后介绍基于训练的方法，包括 SFT 和 RL 两个方向，详细讨论了算法选择、奖励设计和训练脚手架。最后，在「分析」部分（第 5 节），作者讨论了数据质量问题和代理行为分析，并在「挑战与机遇」部分（第 7 节）总结了八大研究挑战。
技术新颖性
本文的技术新颖性主要体现在三个方面：第一，这是首篇专注于问题修复（而非通用代码生成）的系统综述，填补了该领域的文献空白。第二，本文建立了一个多维度的分类框架，将数据、方法和分析有机整合，这在以往的综述中是没有的。第三，本文对基准质量和代理行为进行了深入的批判性分析，指出了 SWE-bench 等基准存在的数据泄漏和质量问题，以及代理在推理过程中可能出现的「分析瘫痪」等行为病理。这些分析为后续研究提供了重要的警示和改进方向。此外，本文还维护了一个持续更新的开源仓库，这使其具有了「活文档」的特性，能够跟上该领域的快速发展。
实验结果
作为综述论文，本文的核心发现体现在对现有研究的系统梳理和批判性分析中。在数据层面，作者发现 SWE-bench 已从单一的 Python 基准扩展到支持 10 种编程语言（如 Java、Go、Rust、C++ 等）的多语言基准，如 Multi-SWE-bench 包含 76 个仓库的 4,723 个实例。同时，多模态基准（如 SWE-bench Multimodal、OmniGIRL）的出现使评估范围扩展到前端开发等视觉相关任务。在训练数据方面，SWE-Fixer 数据集已达到 115,406 个实例的规模，远超原始 SWE-bench 的 2,294 个。在方法层面，作者发现当前最先进的系统在 SWE-bench Verified 上的解决率已达到 73.4%（MiMo-V2-Flash 和 KAT-Coder），相比 2024 年初的水平有了显著提升。在基于训练的方法中，RL 方法展现出巨大潜力：例如，Kimi-Dev（72B 参数）在 SWE-bench Verified 上达到 60.4% 的解决率，而专门优化的小模型（如 SWE-Lego-Qwen3-32B）也能达到 57.6%。作者还发现，推理时扩展策略（如 MCTS、并行搜索）能够显著提升性能，且不需要修改模型参数。在分析层面，作者指出当前基准存在严重的数据质量问题：SWE-bench Verified 的引入正是因为原始数据集中存在无效测试和不清晰的描述；同时，代理的成功率可能因解决方案泄漏而被高估，模型可能无意中记住了训练数据中的解决方案。
查看结构化数据
| 任务 | 指标 | 本文 | 基线 | 提升 |
|---|---|---|---|---|
| SWE-bench Verified（问题修复基准） | Resolved Rate（解决率） | MiMo-V2-Flash: 73.4%, KAT-Coder: 73.4% | SWE-agent (2024): ~12% | 提升约 61 个百分点（从 12% 到 73.4%） |
| SWE-bench Verified（RL 训练的小模型） | Resolved Rate | Kimi-Dev 72B: 60.4% | SWE-RL 70B: 41.0% | 提升约 19 个百分点 |
| SWE-bench Verified（SFT 训练的小模型） | Resolved Rate | SWE-rebench 235B: 59.9% | 原始 Qwen3-235B: 未报告 | SFT 显著提升基础模型的问题修复能力 |
| 多语言问题修复（Multi-SWE-bench） | Resolved Rate | 多语言方法在 Java、Go 等语言上的表现 | 仅 Python 的方法 | 扩展到 10 种编程语言 |
局限与改进
本文作为综述论文，存在以下局限性：首先，由于篇幅限制，作者优先进行高层次总结而非详尽细节，这可能导致某些技术细节被忽略。其次，本文的文献检索方法依赖于引用追踪（如对 SWE-bench 的引用）和滚雪球法，虽然全面，但可能遗漏了一些小众或新兴的工作。第三，本文主要关注问题修复任务，对软件工程其他阶段（如需求分析、架构设计）的覆盖不足。第四，本文的分析主要基于现有文献，缺乏独立的实验验证。此外，作者还指出，该领域发展极为迅速，论文中的某些数据和结论可能很快就会过时。尽管作者承诺持续更新开源仓库，但综述本身的时效性仍然是一个挑战。
独立分析的弱点
基于对本文的深入分析，我认为该领域存在以下主要弱点：第一，计算开销问题。在线 RL 训练需要同时编排大量沙盒容器，存储和计算成本高昂。例如，在数据构建阶段验证每个实例需要大规模并行验证。改进方向包括开发轻量级沙盒技术和优化资源调度算法。第二，缺乏效率感知的评估。当前评估主要关注解决率等有效性指标，忽略了 API 成本和推理时间等效率指标。这导致高计算成本的方法可能在排名上占据优势，但在实际部署中并不经济。改进方向是建立综合评估框架，同时考虑解决率和效率指标。第三，多模态推理能力有限。当前基准中多模态任务稀少，且现有方法通常只是将视觉信息「扁平化」为文本，未能捕捉渲染与代码之间的关键对齐关系。改进方向是构建专门的多模态基准和训练代码中心的视觉语言模型。第四，奖励信号稀疏。大多数 RL 方法仍依赖于测试通过/失败的二元奖励，但问题修复需要多轮交互，这种稀疏奖励使得信用分配变得模糊。改进方向是设计更细粒度的过程奖励模型。第五，缺乏自主的上下文管理机制。长时间的多轮交互会导致「上下文腐烂」（context rot），降低性能。改进方向是构建能够主动压缩和管理交互历史的上下文管理机制。
未来方向
本文和相关研究提出了多个有前景的未来方向：第一，数据质量与去污染。随着 SWE-bench 接近饱和，评估的可靠性受到数据泄漏和质量问题的威胁。未来需要建立严格的数据筛选和去污染协议，确保比较评估的有效性。第二，安全的自主修复。近期一些代理在编码任务中表现出不安全行为（如删除用户代码库）。未来需要开发更安全的代理框架和更 robust 的模型安全对齐，防止在实际部署中出现奖励黑客行为。第三，跨软件工程领域的通用性。现有研究主要集中在实现和集成阶段，未来应扩展到需求分析、架构设计等更广泛的生命周期阶段。第四，人机协作界面。为了弥合信任差距，未来研究应优先开发以人为中心的界面，如可视化解释和简洁摘要，帮助开发者高效审查和接受模型生成的解决方案。第五，细粒度过程奖励。当前大多数 RL 方法依赖结果级奖励，未来需要设计更细粒度的过程奖励模型，为中间行为（如上下文管理、轨迹搜索）提供密集的逐步反馈。
复现评估
本文作为综述论文，本身不涉及实验复现，但为后续研究提供了丰富的资源支持。在开源方面，作者维护了一个持续更新的开源仓库（https://github.com/DeepSoftwareAnalytics/Awesome-Issue-Resolution），包含所有讨论的数据集、实现和新发展。在数据方面，本文系统整理了 30 多个评估数据集和 10 多个训练数据集，涵盖了从 Python 到 10 种编程语言的广泛范围。在算力需求方面，基于训练的方法（特别是 RL）需要大量计算资源：在线 RL 需要同时运行多个沙盒环境，而 SFT 需要处理大规模的训练数据。例如，SWE-Fixer 数据集包含超过 11.5 万个实例，训练需要大量 GPU 资源。然而，无训练方法（如 Agentless、SWE-agent）相对容易复现，只需要一个 LLM API 和适当的工具配置即可。总体而言，复现难度取决于具体方法：无训练方法复现难度较低，基于训练的方法复现难度较高，需要大量计算资源和工程经验。
论文图表
