夜雨聆风25年12月来自浙江大学和新加坡管理大学的论文“Agentic Software Issue Resolution with Large Language Models: A Survey”。
软件问题解决任务旨在基于用户提供的自然语言描述，处理软件代码库中的实际问题（例如，错误修复、效率优化），是软件维护工作中的一个关键环节。随着大语言模型（LLMs）在推理和生成能力方面取得飞速发展，基于LLM的方法在自动化软件问题解决领域已取得了显著进展。另一方面，现实世界中的软件问题解决本质上具有高度复杂性，往往需要长程推理、迭代探索以及由反馈驱动的决策制定——这些需求对智体（Agent）能力提出更高要求，远非传统的单步处理方法所能满足。近期，基于LLM的智体系统已逐渐成为软件问题解决领域的主流范式。智体辅助软件问题解决技术的进步，不仅能大幅提升软件维护的效率与质量，还能为验证智体系统的推理、规划及执行能力提供一个切实的实践环境，从而在人工智能与软件工程两大领域之间架起一座桥梁。
本文对126项处于基于LLM的智体软件问题解决研究前沿的近期文献进行系统性的综述。文中概述该任务的通用工作流程，并从基准测试、技术方法及实证研究这三个维度构建一套分类体系。此外，本文还重点阐述“智体强化学习”（Agentic Reinforcement Learning）的兴起如何为软件工程领域中智体系统的设计与训练带来一场范式变革。最后，本文总结当前面临的关键挑战，并展望未来研究中极具潜力的发展方向。
1 自动问题解决
自动问题解决任务旨在自动识别代码仓库中的问题，并生成相应的补丁，以解决用户通过自然语言描述的问题。如图 1 展示该问题解决任务的典型框架。
代码库（Repo）预处理。此阶段旨在为代码库构建一种易于访问且通俗易懂的知识表示。基于预先构建的知识，大语言模型（LLM）或智体（Agent）能够更便捷、高效地从代码库（repository）中挖掘有用信息。例如，构建代码知识图谱 [32, 173] 有助于 LLM 检索类与函数之间的继承关系或调用关系。
问题定位。在给定问题描述的情况下，此阶段旨在准确地定位那些最相关且待编辑的代码片段，这些片段极可能是导致所报告问题的根源。定位方法可利用信息检索 [131]、静态与动态程序分析 [193] 以及基于 LLM 的推理 [164] 等技术，来识别可疑的文件、类或代码行。高效的问题定位能够显著缩小补丁生成时的搜索空间，从而提升整个修复流程的整体效率。
代码修复。在给定待修改的代码片段及相关上下文的情况下，此阶段旨在利用提示工程技术驱动 LLM 生成用于解决问题的补丁。具体而言，智体通过替换代码文件中的指定区域来生成修改内容 [157]，并利用 Git 工具 [174] 来生成补丁文件。通常，在此阶段会生成多个候选补丁，以最大化获得正确修复方案的概率。
补丁验证。此阶段被现有的一些技术所采用。在给定问题描述的情况下，该阶段旨在生成复现测试用例，或从代码库中选取回归测试套件。复现测试旨在依据原始问题报告来模拟问题发生的场景 [156]；而回归测试则旨在确保候选补丁不会在代码库的其他部分引入新的错误 [164]。通过运用各类测试技术，此阶段能够过滤掉部分错误或有害的补丁。
补丁选取。在给定一组候选补丁的情况下，此阶段旨在从中选出最有希望的一个，并将其提交以解决问题。例如，智体可以基于“自洽性”原则，通过多数投票机制来选取补丁 [164]；或者利用强大的推理模型，采用“LLM 作为裁判”的方式对补丁进行评估 [36]。最终选定的补丁将被应用到代码库中，作为该问题的正式解决方案。
2 用于问题解决的基于大语言模型（LLM）智体系统
用于问题解决的基于 LLM 智体系统由 LLM 和“支架”（scaffolds）两部分组成 [18, 161]。其中，LLM 充当系统的核心推理与生成引擎，负责理解自然语言（NL）描述的问题、分析代码语义，并生成候选补丁或中间推理步骤。相比之下，支架则通过编排任务工作流、协调多步推理，以及调用工具进行代码检索与执行，为系统提供外部的结构化控制与操作框架；借此，支架引导 LLM 进行迭代式优化，使系统能够在真实世界的软件代码库中实现闭环的问题解决。
现有的智体系统大致可归类为“智体流水线”（agentic pipelines）和“智体”（agents）[135]。智体流水线强调将问题解决过程拆解为一系列可控的、分阶段的步骤，并通过预定义的流水线或类似状态机的工作流来组织 LLM 的行为。而智体则侧重于赋予 LLM 在特定环境中自主行动的能力，使其能够动态地制定规划、调用工具、执行动作，并依据环境反馈持续调整其策略。尽管流水线提供一种高度结构化、且具备强确定性与可控性的框架，但智体则体现出更高程度的自主性与灵活性。
继先前的综述 [63, 73, 98, 102] 之后，采用 Kitchenham [85] 提出的系统化方法。完整的流程如图 2 所示。
系统地介绍针对软件工程智体系统在“问题解决”任务及其子任务上的评估方法，重点关注三个维度：基准数据集构建、基准数据集演进以及评估指标，如图5所示。
1 基准数据集构建
基准数据集划分为“人工构建”和“自动构建”两大类。此外，还提供所有基准数据集中涉及的代码仓库数量、实例数量、编程语言、发布时间以及数据来源等方面的统计数据。
人工构建的基准数据集。与问题解决任务相关的人工构建基准数据集通常包含五个阶段，如图6所示。首先，从GitHub等代码托管平台上精心挑选维护良好的代码仓库，并收集所有的拉取请求（PR）数据。其次，利用人工制定的解析规则对原始数据进行处理，以过滤掉与目标任务无关的实例。第三，通过查阅相应文档，人工配置所选项目的执行环境，以确保其可执行性。第四，在应用与每个PR相关的补丁之前和之后，分别执行所有的测试用例；仅保留那些测试结果呈现出一致性变化的实例，将其作为有效的基准数据。最后，开发者可以选择性地对“问题描述的清晰度”和“测试用例的覆盖率”等因素进行标注，并利用这些标准筛选出一个高质量的数据子集用于评估。
在问题解决任务的早期阶段，几乎所有的基准数据集都依赖于人工构建。SWE-bench [76] 是首个实现图6所示构建流程的基准数据集。它从12个精心挑选的代码仓库中收集约90,000个PR；经过基于规则的过滤和基于执行的验证后，最终筛选出2,294个实例用于评估。随后的研究工作通常将SWE-bench作为参考范式，对其方法论进行增强与扩展，以纳入多模态 [59, 175, 192]、多语言 [82, 181, 182] 以及多样化的代码仓库 [64, 103, 129, 191] 数据，从而拓宽了问题解决任务评估的范围。
自动构建的基准测试集。自动构建问题解决基准测试集旨在快速收集大规模的问题解决数据，以弥补静态基准测试集在时效性方面的不足。具体而言，现有方法主要聚焦于环境搭建这一环节，因为这是整个流程中人力投入最为密集的阶段。SWEE/SWA-bench [151] 采用一种名为 SetupAgent 的智体，通过“命令提取”、“迭代测试与改进”以及“验证”这三个阶段实现环境搭建的自动化，从而构建出安装命令、测试命令以及结果解析器。SWE-rebench [15] 利用大语言模型（LLMs）来识别与拉取请求（PR）相关的文件及环境依赖项，进而实现自动化配置；此外，该方法还训练三个判别器，用于评估问题描述的清晰度、任务的复杂程度以及补丁的正确性，以此对数据进行筛选。SWE-bench-Live [191] 采用一种名为 RepoLaunch 的端到端智体工作流，该工作流能够阅读相关文档、迭代执行并调试命令，并根据反馈信息不断优化策略，最终完成环境的搭建工作。
2 基准数据集的演进
基于现有基准数据集的演进方向，从“增强”与“扩展”这两条主要路径出发，探讨问题解决类基准数据集的演进历程。
2.1 基准数据集的增强
基准数据集增强旨在通过人工或自动化手段，对现有基准数据集进行高质量子集的筛选或修复工作；其重点关注问题描述的清晰度、单元测试的覆盖率等关键维度，从而确保能够进行可靠的评估。
A. 问题描述的清晰度
在基准数据集中，问题描述通常源自开发人员在实际代码合并请求（Pull Requests）中提供的自然语言解释。然而，由于自然语言往往具有歧义性和模糊性，大语言模型（LLMs）可能无法准确捕捉任务需求，进而阻碍其完成任务的能力。
现有研究已探索出多种用于识别不清晰问题描述的方法。OpenAI [35] 聘请93位经验丰富的软件工程师，对 SWE-bench 数据集中1,699个样本的问题描述清晰度进行标注，并依据标注者之间的一致性程度来筛选样本实例。Xia [164] 通过人工审查问题描述，识别出其中具有误导性或描述不详尽的陈述；在此基础上，他们从 SWE-bench Lite 中筛选出252个高质量任务，构建 SWE-bench Lite-S 数据集。Aleithan [9] 对 SWE-bench 进行实证研究，结果发现，在32.67%的任务中，其解决方案已明确地包含在问题描述文本之中。基于上述研究发现，Oliva [119] 提出 SPICE——首个自动化标注方法；该方法利用 OpenAI 的标注数据构建出包含推理依据（rationale-informed）的提示（prompts），并通过提示工程技术实现对问题描述清晰度的自动化标注。
B. 单元测试的覆盖率
在实际的软件代码仓库中，单元测试往往是针对特定问题而编写的。因此，用于评估解决方案正确性的单元测试可能存在过度具体（overly specified）或过于宽泛（excessively broad）的问题；在某些极端情况下，这些测试甚至可能与待解决的实际问题毫无关联。这种状况可能导致错误的评估结果：正确的解决方案被判定为错误而遭到拒绝，或错误的解决方案却被判定为正确而得以通过。
近期研究工作的重点在于如何自动化地识别单元测试覆盖率方面存在的问题。具体而言，OpenAI [35] 通过人工标注的方式识别出那些过于具体的测试用例，并基于此项工作构建 SWE-bench Verified 数据集。Aleithan[9] 研究最先进的软件工程智体 SWE-Agent 在 SWE-bench 上的表现，并发现其中 31.08% 的测试用例过于宽泛。Yu [179] 采用差分测试（differential testing）来检测“真值”补丁（ground-truth patches）与候选补丁之间的差异。随后，这些差异被用作上下文，以指导大语言模型（LLM）自动增强测试用例，从而强化 SWE-bench 中的单元测试。Oliva [119] 利用 Aider [54] 构建一个自主智体，该智体能够探索软件代码库，并自动评估测试用例的覆盖率。
2.2 基准扩展
基准扩展旨在拓宽问题解决基准在多模态输入、多种编程语言、时间跨度、问题类型及相关子任务方面的覆盖范围，从而实现全面且彻底的评估评估。
A. 多模态
仅以文本形式 [35, 76, 182] 呈现的问题描述，不足以捕捉软件工程领域中多样化的应用场景。例如，在前端开发和游戏开发等领域，往往需要依赖图像等视觉元素来表达需求。为了拓宽问题解决任务的覆盖范围，研究人员通过引入多模态问题描述作为输入，对现有的基准框架进行了扩展。
B. 多语言
早期的问题解决基准几乎完全聚焦于 Python 代码库中的任务 [9, 35, 76, 92, 151]，这导致对大语言模型在多样化软件生态系统中的表现评估不足。为了解决这一局限性，研究人员将问题解决任务扩展至多种编程语言，以实现更广泛的评估。
C. 时效性
静态的问题解决基准测试集 [35, 59, 76, 82, 129, 175, 181] 仅涵盖有限数量的代码仓库，且自发布以来便未曾更新。随着更先进的大语言模型（LLMs）被训练出来，这些基准测试集中的数据很可能已被模型接触过，从而引发过拟合和数据污染的风险。为解决这一问题，研究人员构建动态且持续更新的基准测试集。
D. 其他问题类型
SWE-bench 及其变体主要侧重于评估端到端的 Bug 修复任务 [35, 76, 82, 175, 181]。然而，在现实世界的软件代码仓库中，问题类型还包括 Bug 修复以外的任务，例如效率优化。因此，探索 LLM 在非 Bug 修复任务上的表现至关重要。研究人员对基准测试集进行扩展，使其涵盖“功能新增”和“性能优化”这两类软件开发场景中最常见的任务。
E. 子任务
问题解决是一项多阶段的任务。然而，大多数基准测试集仅专注于端到端的准确率评估，缺乏对软件工程智体系统在各个阶段子任务上的细粒度评估能力。为了应对这一挑战，研究人员针对两个任务——缺陷复现（issue reproduction）和缺陷定位（issue localization）——构建独立的基准测试集，旨在对这些子任务获得细粒度的深入洞察。
3 评估指标
评估指标在端到端的缺陷解决评估以及细粒度的阶段性评估中均发挥着重要作用，因为它们能够对软件工程智体系统（agentic systems）的缺陷解决能力进行量化。从三个视角探讨评估指标：基于执行的指标、基于匹配的指标以及基于统计的指标。
3.1 基于执行的指标
通常而言，与代码生成相关的基准测试集往往依赖于测试套件来进行评估。作为一项极具挑战性的代码生成任务，缺陷解决任务在进行端到端评估时，主要依赖于两类测试套件。第一类测试套件包含这样一组测试用例：在应用“黄金补丁”（即标准正确补丁）之后，其执行结果由“失败”（FAIL）转变为“通过”（PASS）；换言之，这类测试用于验证缺陷是否已得到解决（记作 𝐹 → 𝑃）。第二类测试套件包含这样一组测试用例：无论是在应用黄金补丁之前还是之后，其执行结果始终保持为“通过”（PASS）；换言之，这类测试属于回归测试（记作 𝑃 → 𝑃）。基于这两类测试套件的执行结果，现有的研究工作主要采用以下指标进行评估。
• Applied%：能够成功应用至代码仓库并触发测试套件执行的候选补丁所占的比例。 • Resolved%：通过所有 𝐹 → 𝑃 和 𝑃 → 𝑃 测试的候选补丁所占的比例。 • Pass@k（亦称 Resolved@k）：在由智能体系统生成的 𝑘 个补丁中，至少有一个补丁通过了所有 𝐹 → 𝑃 和 𝑃 → 𝑃 测试的案例所占的比例。 • 复现成功率：在问题复现阶段，所生成的复现测试符合 𝐹 → 𝑃 测试的条件，且在应用所生成的测试补丁后，通过了所有 𝑃 → 𝑃 测试。
3.2 基于匹配的指标
基于匹配的指标主要用于评估智体系统在定位阶段的性能。由于真值（Ground Truth）是确定的，因此可以通过匹配的方式来评估定位性能。然而，鉴于智体决策的自主性，并非所有的智体系统都会显式输出定位阶段的中间结果。因此，从两个视角来探讨以下指标：一是基于生成的补丁（文件匹配率/函数匹配率），二是基于中间定位结果（Top-k、MAP、MRR）。
• 文件匹配率（File Matched Rate）：指候选补丁所修改的文件集合与真实文件集合之间存在交集的实例所占的比例。形式上，对于第 i 个实例，若其预测文件集合为 Fˆ_i、真实文件集合为 F_i，则当 𝐹ˆ_𝑖 ∩ 𝐹_𝑖 ≠ ∅ 时，该实例即被判定为正确。 • 函数匹配率（Function Matched Rate）：指候选补丁所修改的函数或方法集合与真实函数集合之间存在交集的实例所占的比例；即对于第 i 个实例，满足 𝐺ˆ_𝑖 ∩ 𝐺_𝑖 ≠ ∅ 的比例。 • Top-k：给定定位阶段生成的一份候选位置排序列表，该指标衡量的是至少有一个真实位置出现在列表前 k 个位置内的实例所占的比例。当存在多个正确位置时，只要其中任意一个正确项位于前 k 的排名之内，即视为成功。 • 平均精度均值（MAP）：该指标通过计算推荐列表中所有被正确识别的缺陷元素（buggy elements）所在排名的精度值，并对这些精度值取平均，以此来评估排序质量。 • 平均倒数排名（MRR）：该指标通过计算推荐列表中首个被正确识别的缺陷元素所在排名的倒数，以此来评估排序质量。
3.3 基于统计的指标
智体系统通常依赖大语言模型（LLMs）来进行多轮推理。因此，除了有效性之外，还有必要对系统效率进行评估。衡量这一指标的方法是：在系统运行期间，追踪每个问题所消耗的平均输入与输出 Token 数量（#Token）、美元成本（$Cost）以及耗时（Time）。
从支架/方法设计和学习策略这两个维度，展示范式转变前后问题解决技术演变的过程，如图7所示。
1 脚手架/方法设计
由于大语言模型（LLMs）的上下文窗口有限 [2, 57]，因此无法将代码仓库中的所有代码一次性输入给 LLM，以定位关键方法或生成补丁。鉴于此，研究人员设计针对 LLMs 的“脚手架”（scaffolds），旨在协助其解决问题修复任务或其子任务。在 2025 年 1 月之前，研究人员倾向于为 LLMs 设计复杂的脚手架，以提升其在问题修复方面的性能。根据目标任务的范围，现有的脚手架/方法初步划分为“端到端脚手架”和“单阶段方法”。
1.1 端到端脚手架
基于智体系统在设计过程中对人类先验知识的依赖程度，将端到端脚手架划分为“基于智体”和“基于流水线”两类。基于智体的脚手架与基于流水线的脚手架通常都遵循通用工作流程。基于智体的脚手架为单个或多个智体配备用于规划、仓库访问和代码编辑的工具，使其能够自主地做出决策并更新代码库。
A. 代码库表示（代码库预处理阶段）
受限于自然语言需求与源代码之间存在的语义鸿沟，大语言模型（LLMs）在捕捉代码库内部复杂的依赖关系及语义信息方面面临诸多挑战。为了更好地理解代码库的结构与代码语义，部分方法会在代码库预处理阶段生成代码库的结构化表示，从而弥合自然语言与代码之间的鸿沟。现有的代码库表示策略大致可划分为以下两类：
A.1 基于树的表示（Tree-based Representation）。该方法首先利用静态解析器对代码库内的所有源文件进行解析，以识别出库中包含的所有代码文件、类及函数。随后，它构建出一种轻量级的、基于树结构的代码库表示形式，从而确保在LLM有限的上下文窗口（context window）内，能够提供理解代码库所需的关键上下文信息。
A.2 代码图（Code Graph）。该方法通过从代码库中提取各类关系（例如函数调用、文件包含、继承关系及数据流等），构建出代码库层级的代码图（Code Graph），从而捕捉代码库内部更为深层的语义信息。
针对基于智体（agent-based）的脚手架，阿里巴巴的 LingmaAgent [107] 构建一种函数层级的调用引用图，以此来表征整个代码库的整体结构。 MarsCode Agent [101] 构建一个代码知识图谱，整合了来自多个数据源的代码、文档及相关信息。Prometheus [31] 将文件、抽象语法树（AST）和自然语言文本编码为一个图结构，该图由带类型的节点及五种通用边类型构成。CodexGraph [100] 和 SWE-Debate [90] 构建一种静态依赖图，该图整合函数调用、类继承、模块导入以及变量引用等信息。
对于基于流水线（pipeline）的脚手架，RepoGraph [122] 在代码行级别上定义“定义”与“引用”之间的依赖关系，从而为大语言模型（LLMs）提供对代码仓库更为细粒度的理解。DARS [4] 也采用这种图结构。与 Alibaba LingmaAgent [107] 和 SWE-Debate [90] 类似，SynFix [143] 和 CGM [146] 构建一种跨越仓库多个层级（包括文件、类和函数）的调用图。
B. 定位（Localization Phase）
准确的定位是有效解决问题（Issue Resolution）的关键基础 [113]。其目标是在仓库文件的指定范围内，识别出一组潜在的错误代码片段。现有的定位方法大致可分为五类：
B.1 BM25。BM25 [132] 是一种概率检索算法，特别适用于键（keys）和查询（queries）内容均较长的场景 [76]。
B.2 基于谱的方法（Spectrum-based Methods）。在故障定位领域，基于谱的故障定位（SBFL）方法已取得了显著的进展 [43, 136]。给定一个包含通过测试用例和失败测试用例的测试套件，SBFL 会分析在执行通过测试与失败测试时所观察到的控制流差异（分析粒度可涵盖函数、代码行等不同层级），并为每一个程序元素分配一个“可疑度分数”。
B.3 基于嵌入的方法。基于嵌入的方法 [164, 196] 通过将问题描述与代码表示投影至同一个共享语义空间中，从而识别出可疑的代码片段；这种做法使得基于相似度的匹配成为可能，进而实现精准定位。
B.4 基于导航的方法。基于导航的方法为 LLM 配备一套代码搜索操作指令，使智体系统（Agentic System）能够对代码仓库内的目录和文件进行遍历与检查。
B.5 基于图的方法。基于图的方法利用在代码仓库预处理阶段构建的仓库级知识图谱。典型的基于图的方法利用大语言模型（LLM）在代码图谱上进行多跳推理，从而为故障定位收集与问题相关的上下文。
C. 复现测试用例生成（补丁验证阶段）
成功解决问题的关键在于创建一个能够准确复现该问题的测试用例；因为有了这样的测试用例，开发者便能更精确地定位问题所在，筛选出合理的补丁方案，并验证该补丁是否符合问题的预期修复意图。然而在实际操作中，并非所有的缺陷报告（Issue）描述都附带了复现测试用例。因此，许多自动化脚手架（Scaffolds）都将“生成复现测试用例”这一环节纳入补丁验证阶段。将复现测试用例生成功能集成至自动化脚手架中，通常有两种实现方式：一是通过“提示工程”（Prompt Engineering）技术直接向 LLM 发送指令 [45, 66, 91, 123, 133, 139, 163, 164]；二是通过构建智体（Agent）来实现——此类智体能够访问代码仓库，在生成测试用例之前先行收集相关的上下文信息 [4, 13, 26, 31, 51, 101, 115, 140, 143, 144, 157, 173, 174]。
D. 回归测试选择（补丁验证阶段）
正确修复问题的先决条件是确保所引入的补丁不会破坏代码库中的其他功能。为此，一些脚手架在补丁验证阶段纳入了回归测试选择机制。具体而言，它们从代码库中选取与目标方法（focal method）相关的一组测试用例作为回归测试，以此协助筛除那些会损害现有功能的补丁。当前的脚手架 [51, 91, 133, 140, 143, 144, 157, 163, 164] 几乎完全依赖大语言模型（LLM）来识别代码库中的相关测试用例。然而，这种识别方式存在固有的局限性，因为 LLM 识别出的错误测试用例可能会导致正确的补丁被误筛除。
E. 补丁重排序（补丁选择阶段）
基于补丁验证阶段中复现测试和回归测试的执行结果，系统会对貌似合理的补丁进行初步筛选。筛选完成后，部分脚手架会对剩余的候选补丁进行进一步的重排序，从而推荐出那些最有可能解决问题的补丁，并将其提交给最终用户。多数投票法（Majority voting）是其中最常用的方法之一 [45, 51, 66, 101, 122, 139, 163, 164, 173, 192]；该方法利用了 LLM 输出结果所具备的“自洽性”（self-consistency）[158] 特征，从而选出生成概率最高的补丁作为最终的提交方案。
1.2 单阶段方法
当前的单阶段方法主要聚焦于两个子任务：缺陷定位（Issue Localization）和缺陷复现（Issue Reproduction）。缺陷定位要求智体系统识别出代码库中需要修改的具体位置，从而为后续的代码编辑工作奠定基础。缺陷复现旨在针对目标缺陷生成一个测试用例，该用例在包含缺陷的代码库中执行失败，而在修复后的代码库中执行成功；通过这种方式，该任务既辅助缺陷的定位工作，也协助验证缺陷修复的有效性。鉴于这两个子任务在缺陷解决流程中占据关键地位，优化其执行效能将显著提升整个缺陷解决任务的整体效率。
A. 缺陷定位
与脚手架（Scaffold）架构中的定位组件不同，这里探讨专门针对缺陷定位任务的方法；这些方法的输出结果可被进一步利用，以增强后续的代码修复阶段的性能。
A.1 基于 RAG 的方法。检索增强生成（Retrieval-Augmented Generation，RAG）[14] 旨在从代码库中检索相关的上下文信息，以此辅助大语言模型（LLM）进行决策。
现有的基于 RAG 的方法主要包括：基于向量的 RAG（Vector RAG）、基于图结构的 RAG（Graph RAG）以及基于导航的 RAG（Navigation-based RAG）。
基于向量的 RAG 通过计算缺陷描述文本与代码片段之间的嵌入向量相似度，来收集用于缺陷定位的上下文信息。基于图结构的 RAG 利用大语言模型（LLM）在预先构建的代码图谱上执行多跳推理，从而汇集上下文信息。
A.2 基于微调的方法。基于微调的方法主要分为两大类：微调生成模型和微调嵌入模型。
B. 问题复现
能够根据问题描述自动复现问题，有助于实现缺陷的及时定位与修复，从而显著提升软件开发的效率。现有的相关研究主要聚焦于特定且狭窄的缺陷类别 [118]。
2 学习策略
继 DeepSeek-R1 [57] 发布之后，针对问题解决智体系统（agentic systems）的研究经历一场范式转变。强化学习在智体训练中展现出的显著成效，促使研究重心从设计复杂的辅助脚手架（scaffolds）转向开发更具能力的基础模型——即专门针对问题解决任务进行训练的模型。
2.1 数据准备
为训练问题解决领域的专用模型而准备真实世界训练数据集的过程，与基准构建过程相仿。鉴于带标注数据的稀缺性以及真实问题解决样本的日渐枯竭，研究人员也探索基于真实代码仓库生成合成数据的方法，以扩充训练数据的规模。
A. 真实世界数据
真实世界数据集主要通过抓取开源代码仓库及“问题—提交（issue–commit）”配对数据构建而成。SWE-bench (Train) [76] 是首个大规模数据集，它整理收录了 1.9 万对真实的问题修复配对数据，从而提供能够反映真实世界数据分布的训练样本。
B. 合成数据
尽管从现实世界数据源收集数据的流程已相对成熟 [15, 76, 166]，但对这些数据集进行整理依然极其复杂，且往往耗费数百小时的人工精力 [176]。即使采用自动化方法，在构建可执行环境时也常面临成功率低、开销巨大的难题 [155]，从而限制了数据集的可用性与可扩展性。为缓解上述问题，近期研究开始探索数据合成方法，旨在基于现有的已标注数据集，生成大规模的数据实例及相应的可执行环境。
2.2 模型训练
针对问题解决任务的领域特定模型训练，正伴随着 SWE-bench 类数据集的扩充，以及 OpenHands [157]、Agentless [164] 和 SWE-agent [174] 等开放式框架的涌现而迅速演进。表 7 总结了各类代表性模型、其训练范式，以及它们在 SWE-bench Verified 数据集上的性能表现。
A. 有监督微调
有监督微调（SFT）是一种训练领域特定模型的基础方法，其核心在于通过输入-输出对的形式，向模型注入特定的任务知识。在问题解决这一应用场景中，常见的 SFT 策略主要包括面向流程的方法以及教师模型蒸馏法。
B. 强化学习
强化学习（RL）已展现出一种独特的能力，即能够培养出静态监督方法所无法捕捉的、具有长远视角的决策行为 [57, 104]。近期的一些开源工作已开始借助基于强化学习的训练框架，对这种复杂性展开探索。根据所采用的奖励模型类型，强化学习训练方法可划分为过程奖励模型（PRM）和结果奖励模型（ORM）。
研究人员已提出了各种智体系统，旨在解决问题解决领域现存的技术挑战。另一方面，该领域的进展也得益于多项实证研究；这些研究从基准完整性、技术局限性及其他评估视角出发，系统性地探究了当前问题解决基准与技术中潜在的风险，从而为未来的研究提供了宝贵的指导。图9总结现有实证研究的分类体系，将既往工作归纳为三个相互补充的维度：基准完整性、技术局限性以及其他评估视角各异的性能表现；若能结合利用这些系统之间互补的优势，将有助于提升整体的问题解决能力。
1 基准完整性
基准完整性旨在考察问题解决基准能否公正且准确地反映智体系统的真实性能。Wang[160]提出PatchDiff，这是一种差异化补丁测试技术，能够自动揭示不同补丁之间的行为差异。他们的研究结果表明，部分系统生成的补丁虽看似合理，但其行为却与“真值”（ground-truth）补丁存在偏差；这暗示着SWE-bench[76]基准可能高估系统的实际性能。Liang[94]仅依据问题描述来推断文件路径，以此评估模型潜知识的影响；研究揭示，当前最先进的模型可能存在对SWE-bench解决方案的死记硬背现象，或受到数据污染的影响。Martinez[111]对SWE-bench Lite和SWE-bench Verified排行榜进行分析，旨在归纳总结驱动已报告性能提升的架构选择及相关因素。
2 技术局限性
技术局限性维度的研究旨在分析不同智体系统的执行轨迹、评估结果及结果差异，从而识别技术瓶颈，并提供有助于指导未来技术进步的洞见。现有研究大致可归为三大类：补丁变异性、行为分析以及故障模式。
A. 补丁变异性
DEI[189]的研究表明，智体系统在不同任务中呈现出各异的性能表现；若能结合利用这些系统之间互补的优势，将有助于提升整体的问题解决能力。
B. 行为分析
Vijayvargiya [152] 研究基于大语言模型（LLM）的智体在交互式代码生成过程中如何处理歧义指令。研究表明，尽管模型难以区分显性与隐性需求，但能够针对规范不足的输入有效地向用户进行问询，从而提升其性能。
C. 故障模式
Chen [30] 分析来自八个领先智体的 3,977 条求解轨迹和 3,931 份测试日志，结果表明，大多数故障源于频繁的 Python 运行时错误——这些错误与较高的推理开销及较低的成功率呈正相关——此外，该研究还指出 SWE-bench 中三项与公平性相关的缺陷。
3 额外的评估视角
除了问题解决率之外，近期研究还从代码质量、效率和资源消耗等额外视角对智体系统进行了评估。Yadavally [169] 提出一种基于大语言模型（LLM）的“评论家”机制，能够对代码仓库层面的代码修改执行无需实际运行的、逐步骤的评估。Sajadi [134] 通过分析代码、问题和项目层面的因素，对 SWE-bench 基准测试中生成补丁的安全性进行评估；研究发现，相比人类开发者，独立的 LLM 引入的新漏洞要多得多，且往往呈现出独特的模式。Fan [46] 引入 SWE-Eiff，这是一套用于从整体有效性角度重新评估智体系统的指标集；该研究还指出诸如“Token 滚雪球效应”以及高昂的失败模式等挑战。Garg [52] 分析开发者与智体之间的交互模式，并将形式化的基准测试转化为更贴近实际的用户查询；研究结果表明，现有的基准测试高估模型的实际能力，为此，他们提出一种用于评估交互式软件工程智体的新范式。
研究机会和方向
略
