CodeFuse-AAIS：改进低智能体框架助力高效程序修复

引言：

自动化程序修复（APR）技术旨在借助语言模型（LLM）强大的推理生成能力和程序分析工具简化软件开发过程中编码和维护阶段的时间成本。近年来，在大语言模型（LLM）的反复刷屏过程中，研究人员不断追求通过构建更强大的软件工程智能体实现更精确的 APR 性能。然而，随着相关研究的深入，人们发现复杂的软件工程智能体并不是解决问题的唯一途径，人为设计推理框架在软件工程任务同样出色。因此，如何将智能体的自适应性与低智能体的控制流有机结合是当前的一项挑战。

在本文中，作者从智能体决策的视角剖析了现行软件工程智能体的局限，并基于低智能体框架提出了自适应的改进方案。文章主要聚焦于自适应的缺陷定位与多模型辅助生成两个方面的改进。实验表明，所提出的方法在 SWE-Bench 的函数级定位提高了 46.94% （TOP5）-113.32% （TOP1）并在 Issue solving 任务上达到了 35.67% 这一有竞争力的性能。

简介

一直以来，软件工程都是一项极具挑战的任务。开发人员需要综合运用编码、测试、调试等多种技术来进行软件工程活动。在软件开发的过程中，程序修复所需的时间成本约为软件维护的 50%-75%，因此需要自动化程序修复（APR）技术来降低开发成本并提高开发效率。最近，Issue Solving 任务已经引起学术界和工业界的极大关注。大语言模型（LLM）热度的持续走高促使研究人员构建多样化的软件工程智能体来完成自动程序修复的过程。

目前，Issue Solving 方法主要分为两类：基于智能体的方法和基于低智能体的方法。前者通过构建一系列复杂的 Agent-Computer Interface，使得 LLM 具有访问代码仓库，编写测试用例，执行测试脚本，修复程序等行为，通过自主计划与决策实现 Issue 的修复。这种方法容错性高，适应性强，但往往需要高额的推理成本，同时存在陷入无终止循环的风险。后者通过设计一套人工的修复流程，通过静态分析预先提取代码仓库的全部结构，进而基于定位-修复-筛选的基本流程，分阶段向 LLM 提供相关信息以实现程序修复的目的。这种方法极大的节约了推理成本，但受制于 LLM 的上下文窗口大小，有效信息可能无法被检索或存在丢失。

为了结合智能体的适应性和容错性，同时保留低智能体的控制流，并拓展其上下文长度。本文提出了 AAIS，一种基于低智能体框架的低成本自适应程序修复解决方案。AAIS 首先通过静态分析工具抽取代码仓库结构和代码文件结构，在缺陷定位阶段引入了交互设计，以全局的视角实现自适应（观察－决策－反思）这一过程。这使得 LLM 可以实现仓库中的 API 的学习和理解。除此之外，AAIS 利用两个开源模型辅助主模型的生成，这增大了可搜索的样本空间，同时利用了不同 LLM 对信息理解的差异性。

本文在 SWE-Bench 上已验证 AAIS 的有效性，实验结果表明，与最先进的低智能体方法 Agentless-1.5 对比，我们的函数粒度定位准确率提高了 46.94%-113.32%。在 Issue Solving 这一任务上，我们实现了 35.67% 这一有竞争力的性能。

本文的主要贡献如下：

1. 引入了低智能体框架中的交互式模块，拓展了 LLM 理解代码仓库的视角，实现了更准确的函数粒度定位。
2. 引入多个模型辅助主模型生成，拓展了 LLM 采样空间，增大了正确生成的可能。
3. 开源了一套 Issue Solving 工具，能够帮助开发人员自动修复现实 GitHub 仓库中的 Issue。

方法框架

图 1 AAIS 解决方案

在前人研究的基础上，本文保留了三阶段的 Issue solving 推理框架，包括缺陷定位、补丁生成和补丁选择。所提出方法的主要框架如图 1 所示，以下是对每一个阶段的详细说明。

①缺陷定位

缺陷定位阶段的目的是通过分析所提供的问题描述和存储库的当前状态，判断导致问题产生的代码段在存储库中的具体位置。本文采用了自适应的分层定位方法，充分利用 LLM 在各个粒度下获取的不同信息，通过提升工程引导 LLM 判断所需要修改的代码行。

如图 1 上方所示，首先基于存储库的当前状态，通过静态分析工具格式化存储库结构，使用 BM25 检索算法，匹配与问题描述中最相似的 Top-5 代码文件；然后进一步抽取文件格式，采用 Agent 的思想使 LLM 在有限次问答中判定最有可能出错的 Top-5 函数代码/类；最后提供所获得的完整函数代码，获得所需修改的行号信息。

值得一提的是，为了充分利用不同 LLM 在不同分布中采样的随机性，以增大采样的样本空间。在函数粒度的定位时，独立使用三个不同的模型进行采样，以获得更多样化的定位信息，便于后续生成多样化的补丁。

②补丁生成

补丁生成阶段需要根据已获得的位置信息和代码段，生成一个 git 补丁来修复问题。基于前人的工作，本文使用 Search/Replace Edits 来生成补丁，这种格式能有效降低直接生成全部补丁内容导致的格式不正确的风险。受 LLM 有效上下文长度的影响，不宜在 prompt 中提供过长的上下文信息，因此采用了定位阶段中 Top-3 的行粒度信息，每个行粒度前后会提供额外的 10 行代码，以提供相关上下文。

定位阶段中由四个模型产生的四组独立的位置信息将被独立使用，每个模型各自独立产生 11 组独立的补丁，包括1组 temperature=0 的补丁和 10 组 temperature=0.85 的补丁。这种做法是为了产生多样化的补丁，增大问题被修复的可能。

③补丁筛选

补丁筛选阶段的目的是从已产生的 44 组补丁中选择出最有可能修复问题的一个。基于前人的工作，本文使用回归测试和复现测试两种测试用例进行筛选。回归测试用例由 LLM 所有存储库中当前可通过的测试用例中选出；复现测试用例则由 LLM 根据问题描述直接生成，并过滤出在当前存储库状态下失败的用例。AAIS 的选择以最大化复现测试用例通过的数量同时最小化回归测试用例失败的数量为原则，并且当二者都不能选择时，采用多数投票法选出被生成次数最多的补丁。

实验

以 Claude-3.5-sonnet 为主模型，gpt-4o-0513，DeepSeek-v2.5 和 Llama-3.1-Instruct 为辅助模型，在 SWE-Bench-Lite 的 300 个真实世界的 Issue 上测试了所提出方法的性能。评估主要包括两个方面，Top-n 的定位成功率和问题解决的比例（Resolved%）。

表格 1 基于低智能体的 Issue solving方法在缺陷定位上的性能对比

从实验结果上看，使用 Claude-3.5-Sonnet 模型时，AAIS 在 Function-level 上的 Top-1 定位准确率，相较于低智能体的基线方法提高了 113.32%，在 Top-5 上提高了 46.94%；使用 gpt-4o-0513时，AAIS 获得了 30%-92% 的提升，如表1所示。除此之外，即使使用 DeepSeek 和 Llama3.1 等开源模型，依然可以获得 25.32%-60% 的提升，这证明了自适应定位模块的有效性。

表格 2 文件级定位时 BM25 检索对于性能的影响

实验还探究了文件粒度上的 BM25 检索对定位成功率的影响，如表 2 所示，结果表明检索提高了 23% 的函数级 Top1 定位成功率。实验仅在文件粒度和函数粒度上进行了评估，而不包括行粒度，这是因为对于一个特定的问题而已，可能存在多种解决方案均通过所有的测试用例。

表格 3四组定位信息生成补丁的通过情况

进一步地，实验评估了多模型定位的信息对结果的影响。如表 3 所示，对于 AAIS，Samples-1-4 分别对应了 DeepSeek-v2.5 与 Llama3.1，GPT-4o 和 Claude-3.5-Sonnet 的定位结果生成的补丁。对于 Agentless 则为四组基于 GPT-4o 的定位结果生成的补丁。结果显示，使用 gpt-4o 时，尽管 AAIS 每组补丁的筛选结果都小于 Agentless，但 AAIS 却实现了与 Agentless 近乎等同的性能；使用 Claude-3.5-sonnet 时，在平均每组补丁的通过率与 Agentless 相近时，AAIS 获得了 11.4% 的提升，这表明了多样化的补丁生成对解决问题存在正作用。

表格 4 AAIS 在 SWE-Bench Leaderboard 上的表现

对比所有 SWE-Bench-Lite 的开源解决方案，AAIS 获得了具有竞争力的性能，在所有开源解决方案中位列第六，在全部的解决方案中位列第十。这既得益于混合多种模型获得的更大的模型采样空间，也依赖于更准确的定位信息。

总结

本文提出了一种基于低智能体框架的自适应自动化程序修复解决方案 AAIS，结合了智能体的自适应性和低智能体的高效控制流。通过引入自适应缺陷定位和多模型辅助生成，AAIS 显著提高了程序修复的准确性和多样性。实验结果表明，其在函数粒度定位和 Issue Solving 任务上取得了显著性能提升。该方法在 SWE-Bench 基准测试中表现出色，展示了未来在实际软件开发环境中的应用潜力。

CodeFuse 相关模型和数据集陆续开源中，如果您喜欢我们的工作，欢迎试用、指正错误和贡献代码，也可以给我们的项目增加 Star ，支持我们💪

如您想更快地获取到最新信息

欢迎加入我们的微信群

企业用户如有需求，加入群聊时还可私聊“CodeFuse服务助手”联系解决方案专家~