引言：GitHub问题解决的挑战与LLMs的潜力

在软件开发的演进过程中，解决GitHub仓库中出现的问题是一个复杂的挑战。这不仅涉及到新代码的加入，还要维护现有功能的稳定运行。大型语言模型（LLMs）在代码生成和理解方面展现出了巨大的潜力，但在代码变更，尤其是在仓库级别的任务上，它们仍面临着挑战。这些挑战包括处理过长的上下文输入以及在输入上下文长度方面的限制，这在解决GitHub问题时尤为明显，因为上下文可能包含整个仓库的信息。

为了充分发挥LLMs的潜力，研究人员提出了基于LLM的多智能体系统。这些系统在代码生成方面取得了显著的进步，使得这些系统能够基于LLM构建代码仓库。然而，这些方法很少考虑到软件演进的处理，例如解决GitHub问题。对于GitHub仓库，尤其是那些受欢迎的仓库，每天都有大量的提交，这些提交源于各种演进需求，包括修复bug、添加功能、性能提升等。

为了探索LLMs在解决GitHub问题的能力，Jimenez等人开发了一个基准测试SWE-bench，对流行的LLMs进行了全面分析。研究发现，即使在提供了需要修改的文件路径的情况下，LLMs也无法解决超过5%的问题。这一低效率的解决率凸显了LLMs的局限性。LLMs在GitHub问题解决方面表现不佳的原因以及如何发挥其潜力的策略仍有待深入探索。

论文标题、机构、论文链接

论文标题：MAGIS: LLM-Based Multi-Agent Framework for GitHub Issue ReSolution

机构：Fudan University, University of Macau, Rice University

论文链接：https://arxiv.org/pdf/2403.17927.pdf

本研究提出了一个新颖的基于LLM的多智能体框架MAGIS，它由四种类型的智能体组成：管理者、仓库管理员、开发者和质量保证工程师。这个框架通过在规划和编码过程中不同智能体的协作，解锁了LLMs解决GitHub问题的潜力。在实验中，我们使用SWE-bench基准测试来比较MAGIS和包括GPT-3.5、GPT-4和Claude-2在内的流行LLMs。MAGIS能够解决13.94%的GitHub问题，显著优于基线模型。具体来说，与直接应用GPT-4相比，MAGIS在解决问题的比例上实现了八倍的提升。

MAGIS框架概述：多智能体合作解决GitHub问题

1. 研究背景与动机

在软件演进过程中，解决GitHub仓库中出现的问题是一个复杂的挑战，它不仅涉及到新代码的合并，还包括现有功能的维护。大型语言模型（LLMs）在代码生成和理解方面展现出了潜力，但在代码变更特别是在仓库级别的任务中面临困难。为了克服这些挑战，我们提出了一个基于LLM的多智能体框架MAGIS，旨在通过各种智能体在规划和编码过程中的协作来解锁LLMs解决GitHub问题的潜力。

2. MAGIS框架的四种智能体角色

MAGIS框架包括四种类型的智能体：管理者（Manager）、仓库管理员（Repository Custodian）、开发者（Developer）和质量保证工程师（Quality Assurance Engineer）。每种智能体在软件演进中扮演着独特的角色，共同协作以解决问题。

3. 智能体间的协作流程

在MAGIS框架中，智能体间的协作流程涉及规划和编码两个阶段。在规划阶段，GitHub问题被分配给项目经理和仓库管理员，仓库管理员确定与问题相关的候选文件。项目经理根据问题描述和候选文件列表定义任务并组建团队。在编码阶段，开发者执行由项目经理分配的任务，质量保证工程师对每次代码变更进行审查，直到代码变更满足质量标准或达到设定的迭代限制为止。

实证研究：分析LLMs在GitHub问题解决中的表现

1. 问题解决率的影响因素

实证研究表明，LLMs在解决GitHub问题时的成功率受到多种因素的影响，其中包括代码行的定位和代码变更的复杂性。研究发现，文件位置和文件内部的行位置与解决GitHub问题的表现有关联。

2. 文件与行定位的重要性

文件定位的有效性在没有Oracle设置的情况下显得尤为重要。研究发现，即使在提供了需要修改的文件路径的情况下，LLMs也只能解决一小部分问题。这强调了在解决GitHub问题的过程中，准确定位需要修改的代码行的重要性。

MAGIS框架的方法论

1. 框架总览与智能体角色设计

MAGIS框架是为了解决GitHub仓库中出现的问题而设计的多智能体系统。该框架包括四种类型的智能体：管理者（Manager）、仓库管理员（Repository Custodian）、开发者（Developer）和质量保证工程师（Quality Assurance Engineer）。每种智能体在软件演化过程中扮演着独特的角色。

管理者：负责规划阶段，将问题分解为任务，并根据任务需求设计并组建开发团队。

仓库管理员：负责定位与问题相关的代码文件，以及在规划阶段为管理者提供候选文件。

开发者：执行由管理者分配的编码任务，与质量保证工程师合作，确保代码变更符合质量标准。

质量保证工程师：审查开发者的代码变更，提供反馈，并确保代码变更达到质量标准。

2. 协作过程：规划与编码

MAGIS框架的协作过程分为规划和编码两个阶段。

规划阶段：在这一阶段，GitHub问题首先被分配给项目管理者和仓库管理员。仓库管理员识别与问题相关的候选文件，管理者则根据问题描述和候选文件列表定义任务，并组建团队。管理者与开发者召开启动会议，制定计划。

编码阶段：开发者根据管理者分配的任务进行编码，质量保证工程师对每次代码变更进行审查。如果代码变更未达到质量标准，质量保证工程师会提供反馈，要求开发者进行修订，直到代码变更满足质量标准或达到预设的迭代次数限制。

实验设置与评价指标

1. 数据集与实验环境

实验采用了SWE-bench基准数据集，该数据集从12个流行的Python仓库中提取了2,294个问题，代表了真实的软件演化需求。实验环境包括两种设置：Oracle检索和稀疏检索。在Oracle检索设置中（w/ Oracle），LLM接收到需要修改的文件；而在稀疏检索设置中（w/o Oracle），方法需要检索出需要修改的文件。

2. 性能评价指标

性能评价指标包括应用比率和解决比率。应用比率指的是成功生成代码变更并能够使用Git工具应用到现有代码仓库的实例比例。解决比率则指的是代码变更成功应用并通过一系列测试的实例比例。此外，还使用了召回得分与文件数量曲线来衡量无Oracle设置下文件定位的有效性。召回得分指的是成功定位的文件比例，而文件数量则是达到给定召回得分所需处理的平均文件数量。

实验结果与分析

1. MAGIS与其他LLMs的性能比较

在实验中，我们使用SWE-bench基准测试集来比较MAGIS框架与其他流行的大型语言模型（LLMs），包括GPT-3.5、GPT-4和Claude-2的性能。结果显示，MAGIS在解决GitHub问题方面的表现显著优于基线模型。具体来说，MAGIS解决了13.94%的GitHub问题，相比之下，直接应用GPT-4的解决率仅为1.74%，MAGIS实现了相对于GPT-4的八倍性能提升。此外，与之前的最佳模型Claude-2相比，MAGIS的解决率提高了两倍多。这些结果强调了MAGIS在利用LLMs进行软件演化任务中的潜力。

2. 规划与编码过程的有效性分析

在规划过程中，我们分析了仓库管理员和项目经理代理的表现。仓库管理员代理在文件定位的召回率与文件数量曲线上表现出色，这表明我们的方法能够以尽可能少的文件数量找到尽可能多的相关代码文件。项目经理代理生成的任务描述与参考代码变更之间的一致性得分较高，表明规划方向的准确性和有效性。

在编码过程中，开发者代理的行定位和问题解决能力在不同复杂性的实例中进行了分析。结果表明，行定位的准确性对问题解决有积极影响。此外，我们还进行了逻辑回归分析，量化了几个复杂性指标与问题解决之间的相关性。结果显示，与GPT-4相比，MAGIS在文件和函数数量等复杂性指标上的负相关性较小，这表明MAGIS在处理这些复杂性指标方面的挑战有所减轻。

讨论：代码变更的复杂性与软件库差异

1. 解决问题实例的代码变更统计

我们的框架在解决问题的实例中生成的代码变更的统计数据显示，平均修改的代码文件数量、函数、代码块和删除的行数与人类编写的参考解决方案相差不大。这表明对于这些实例，我们框架生成的代码变更的复杂性与人类相似。此外，我们的框架能够处理涉及多个位置和长上下文的复杂问题的代码修改。

2. 应用但未解决问题实例的分析

对于未解决问题的实例，我们的框架能够生成包括多达13个文件和28个代码块的适用代码变更，修改位置可达到7,150行，单次修改可达到9,367行。这些结果表明，我们的方法在生成适用代码变更方面具有很强的适应性。然而，由于这些代码变更没有通过所有潜在的测试用例，这表明我们的框架在解决这些复杂问题方面的性能仍有提升空间。

此外，不同软件库之间的差异可能会影响代码变更的有效性。我们统计了不同软件库中解决率的差异，发现在我们的框架中，不同库的解决率差异显著，有些库的解决率高达40%，而有些接近0%。这表明不同软件的代码结构和编码风格可能会影响代码变更的生成和应用。

MAGIS框架的局限性与未来研究方向

1. 局限性

MAGIS框架虽然在解决GitHub问题上取得了显著的进步，但仍存在一些局限性。首先，MAGIS框架在处理长输入上的表现仍有限。尽管LLMs，如GPT-4，已经扩展了上下文限制，但在处理整个代码库时，仍然存在计算成本高和性能下降的问题。其次，MAGIS框架在复杂性指标上的表现与人类开发者存在差异，例如在删除代码行数上的策略不同，这可能指向不同的问题解决策略或态度。此外，MAGIS框架在不同软件仓库之间的表现差异显著，这表明不同的代码结构和编码风格可能会影响代码变更的生成和应用。

2. 未来研究方向

针对以上局限性，未来的研究方向可以包括以下几个方面：

提升长输入处理能力：研究如何降低计算成本并提高LLMs在处理长输入，特别是整个代码库时的性能。

优化复杂性指标的处理：探索如何使MAGIS框架在处理复杂性指标时更接近人类开发者的策略，以提高问题解决的成功率。

适应不同软件仓库：研究如何使MAGIS框架更好地适应不同的软件仓库，考虑代码结构和编码风格的差异，以提高在各种软件环境中的有效性。

跨语言和领域的泛化能力：扩展MAGIS框架的适用范围，使其能够处理不同编程语言和专业领域的软件项目。

集成环境反馈：考虑如何将环境反馈集成到MAGIS框架中，以进一步提高问题解决的准确性和效率。

总结：MAGIS框架在GitHub问题解决中的应用前景

MAGIS框架通过引入多代理系统，显著提高了LLMs在GitHub问题解决中的表现。它通过精心设计的代理角色和协作流程，实现了在SWE-bench数据集上超越现有流行LLMs的性能。然而，MAGIS框架在长输入处理、复杂性指标处理以及不同软件仓库适应性方面仍有提升空间。

未来，MAGIS框架有望通过进一步的研究和优化，在软件演化中发挥更大的作用，特别是在解决跨语言和领域的GitHub问题上。随着LLMs技术的不断进步和多代理系统的完善，MAGIS框架的应用前景广阔，有潜力成为软件开发和维护中的重要工具，帮助开发者更高效地解决软件问题，提升软件质量和开发效率。