论文翻译：理解整个软件代码库的方法 -- Alibaba Lingma Agent

原文链接：https://arxiv.org/pdf/2406.01422

理解整个软件代码库的方法？

作者：马颖伟，杨青平，曹荣玉，李彬华，黄飞，李永斌
联系方式：{mayingwei.myw, yangqingping.yqp, caorongyu.cry, binhua.lbh, f.huang, shuide.lyb}@alibaba-inc.com
所属机构：阿里巴巴集团

摘要

近年来，基于大语言模型（LLM）的代理推动了自动软件工程（ASE）的显著发展。尽管已有方法被验证有效，但现有方法的设计主要关注代码的局部信息，例如问题、类和函数，这导致在捕获软件系统的全局上下文和相互依赖关系时存在局限性。根据人类软件工程开发者的实际经验，我们认为全面理解整个代码库将是实现自动软件工程的关键路径。然而，理解整个代码库会带来各种挑战，例如超长的代码输入、噪声代码信息、复杂的依赖关系等。为此，我们开发了一种名为RepoUnderstander的新型自动软件工程方法，通过引导代理全面理解整个代码库来应对这些挑战。具体而言，我们首先以自上而下的方式将整个代码库的关键信息压缩到代码库知识图中，以减少代码库的复杂性。随后，我们通过提出一种基于蒙特卡罗树搜索的代码库探索策略，赋予代理理解整个代码库的能力。此外，为了更好地利用代码库级知识，我们引导代理进行总结、分析和计划，然后他们可以操作工具动态获取信息并生成补丁以解决现实世界中的GitHub问题。大量实验表明，所提出的RepoUnderstander具有优越性和有效性。与SWE-agent相比，该方法在SWE-bench Lite基准上实现了18.5%的相对改进。

CCS概念

• 软件及其工程 → 自动编程；
• 计算方法 → 多代理规划。

关键词

自动软件工程（ASE），代理，大语言模型（LLM），故障定位，程序修复，蒙特卡罗树搜索（MCTS）

1 引言

自动化软件工程（ASE）旨在自动完成软件工程（SE）任务，是一个有前景且具有挑战性的研究方向。近年来，在ASE领域，特别是基于大语言模型（LLM）的代理展示了其强大的通用能力，例如环境感知能力【15, 21, 37】，规划和推理能力【6, 29, 32, 37】，工具构建能力【48】等。

最近，一个名为Devin的里程碑项目【6】探索了一个端到端的基于LLM的代理系统，用于处理复杂的现实世界软件工程任务（即修复现实世界的GitHub问题）。具体而言，它规划用户需求，利用编辑器、终端和搜索引擎工具进行独立决策和推理，最终生成满足需求的代码补丁。这一创新方法引起了AI和SE社区的广泛关注，尤其在ASE方面引起了兴趣【43, 49】。例如，SWE-agent【43】战略性地设计了一个代理计算机接口（ACI），以赋予SE代理创建和编辑代码文件、导航代码库和执行程序的能力。此外，AutoCodeRover【49】通过程序中的抽象语法树，基于需求迭代搜索有用的信息，最终生成程序补丁。

虽然先驱们指出了先进ASE的发展道路并取得了令人瞩目的成绩，但他们的设计主要集中在局部信息上，未能把握函数和类之间的全局上下文和复杂的相互依赖关系。例如，SWE-agent【43】在代码文件内保持一个上下文窗口，允许代理向上和向下滚动。AutoCodeRover【49】在整个代码库中搜索函数或类。通常情况下，为特定功能组成完整逻辑链的代码不是按顺序排列在一个文件中，而是逻辑上分散在多个文件夹和文件中。从用户需求文本中检索所有相关代码文件在可能成千上万个文件的代码库中是非常困难的。本文认为，全面理解整个代码库是实现ASE的关键路径。

毫无疑问，在LLM中利用整个代码库的大量信息是具有挑战性的。首先，一个GitHub代码库可能包含成千上万的代码文件，使得不可能将它们全部包括在LLM的上下文窗口中。即使可以，LLM也难以在如此广泛的上下文中准确捕获与目标相关的代码。其次，由于用户需求通常用自然语言描述，识别代码库中的相关代码是一项重大挑战。第三，代码执行的内在逻辑与文件中代码文本的顺序完全不同。例如，触发错误消息的bug位置与实际需要修改的地方可能不在同一个文件中，但它们肯定在逻辑上是相关的。

为解决这个问题，我们提出了一种名为RepoUnderstander的新型ASE方法，通过引导基于LLM的代理全面理解整个代码库并利用已学习的代码库级知识。设想一下人类软件工程师在解决项目级问题时，他们首先会概览代码库，确保对可能涉及的功能模块和依赖关系有一个全面的理解。受这一实践洞察的启发，我们首先通过构建代码库知识图将复杂的代码库级信息浓缩成一个自上而下的层次结构树，从而实现对代码上下文和范围的清晰理解。此外，为了便于全面的依赖和交互分析，树结构进一步扩展成一个捕获函数调用关系的引用图。

接下来，我们提出了一种基于蒙特卡罗树搜索（MCTS）的代码库探索策略，以赋予基于LLM的代理收集和学习代码库级知识的能力。具体来说，代理首先通过探索和利用策略在代码库知识图上收集与SE任务相关的关键信息。然后，通过模拟多个轨迹并评估其奖励分数，我们的方法迭代地缩小搜索空间，引导代理关注最相关的区域。此外，为了更好地利用代码库级知识，我们引导代理总结、分析和规划代码库信息，以实现SE目标。通过这些设计，使代理能够有效且高效地收集和学习与任务相关的代码库级知识，从而促进精确的故障定位和知情的补丁生成。最后，代理被指示操作API工具动态获取局部信息，并通过生成补丁解决实际问题。我们通过大量实验和全面分析证明了RepoUnderstander的优越性和有效性。此外，通过在实验期间的仔细分析，我们发现了SWE-bench数据集的一个重要问题，即缺乏对新特性问题的必要接口规范。我们提出解决这一问题，以实现我们方法和基线的更可靠和有效的评估。本文的主要贡献总结如下：

• 我们强调了理解整个代码库是实现ASE的关键路径，并提出了一种名为RepoUnderstander的新型代理方法来解决这些挑战。
• 我们提出将大量代码和复杂关系浓缩成一个自上而下模式的知识图，提高性能和效率。
• 我们设计了一种基于蒙特卡罗树搜索的代码库探索策略，以帮助代理全面理解整个代码库。
• 大量实验和分析证明了RepoUnderstander的优越性和有效性。

2 相关工作

2.1 基于LLM的软件工程代理

近年来，基于大语言模型（LLM）的AI代理推动了自动软件工程的发展。AI代理通过运行环境感知【15, 21, 37】，规划和推理【6, 29, 32, 37】，以及工具构建【23, 48】等提高了项目级软件工程（SE）任务的能力。一个具有里程碑意义的项目Devin【6】探索了一个端到端的基于LLM的代理系统，处理复杂的SE任务。具体来说，它首先规划用户需求，然后采用编辑器、终端和搜索引擎工具进行独立决策和推理，最终生成满足用户需求的代码。其设计和性能迅速引起了AI和SE社区对自动软件工程（ASE）的空前关注【43, 49】。例如，SWE-agent【43】精心设计了一个代理计算机接口

（ACI），以赋予SE代理创建和编辑代码文件、导航代码库和执行程序的能力。此外，AutoCodeRover【49】通过程序中的抽象语法树，基于需求迭代搜索有用的信息，最终生成程序补丁。他们的设计主要关注代码库中的局部信息，例如代码文件、类或函数本身。尽管取得了令人瞩目的成绩，但从人类SE开发者的洞察来看，全面理解整个代码库是实现ASE的关键路径。

2.2 基于LLM的软件工程代理评估

受益于LLM的强大通用能力，基于LLM的软件工程代理可以处理许多重要的SE任务，例如代码库导航【37, 48】，代码生成【8, 15, 18, 34, 36】，调试【15, 43, 49】，程序修复【33, 43, 49】。现有方法通常将代码生成视为核心能力，主要在其上进行评估。具体来说，代码生成测试集【2, 5, 25, 28, 50】包括简短的问题描述、解决方案和相应的单元测试数据。然而，随着LLM和代理的快速发展，这些数据集已无法全面评估它们在现实世界SE任务中的能力。为此，提出了代码库级代码完成和生成任务【9, 12, 26】，以评估LLM和代理在代码库理解和生成方面的能力。最近，SWE团队【19, 43】开发了一个统一的数据集SWE-bench，用于评估代理系统自动解决现实世界GitHub问题的能力。具体来说，它从十二个代码库中收集了任务实例。与以前的评估方法一致，SWE-bench基于单元测试的自动执行。不同的是，所提供的测试集具有挑战性，要求代理具备多种能力，包括代码库导航、故障定位、调试、代码生成和程序修复。此外，SWE-bench Lite【4】是SWE-bench的一个子集，具有与原版相似的代码库多样性和分布。由于测试成本较小且筛选更详细，SWE-bench团队官方推荐将SWE-bench Lite作为LLM-based SE代理的基准。因此，与以前的方法一致，我们报告了我们在SWE-bench Lite上的性能。

2.3 代码库级代码智能

随着AI技术的发展，代码智能领域逐渐从解决单个函数级或代码片段级问题过渡到代码库级的实际软件开发。在代码库级代码智能任务中，有许多工作【3, 10, 13, 24, 27, 35, 45, 47】旨在利用当前代码库中大量可用的代码，帮助代码模型生成更好、更准确的代码。其中，StarCoder2【27】和Deepseek-Coder【13】在预训练阶段对代码库知识进行建模，根据引用依赖关系对代码库文件进行排序，并指导模型学习代码库信息的全局依赖关系。RepoCoder【47】通过迭代RAG不断检索相关内容，而CoCoMIC【10】和RepoFuse【24】等方法则联合使用RAG模块和当前文件的依赖关系模块，将其引入到LLM的上下文中。虽然上述方法在一定程度上增强了模型对代码库上下文的理解，但代码库级代码通常包含复杂的上下文调用关系，单靠RAG方法可能无法回忆所有语义相关内容。此外，RAG结果中可能包含大量复杂的无关信息，干扰模型的准确故障定位。因此，从软件工程的实际经验出发，我们模拟了人们对代码库的全局经验理解，以及经验引导的探索和定位，以实现更有效的代码库理解。

3 方法论

3.1 概述

我们首先描述RepoUnderstander的整体运行过程，并在本节后续部分详细介绍各个阶段。给定一个工作区，RepoUnderstander可以自动解决现实世界的GitHub问题。RepoUnderstander涉及三个关键步骤：代码库知识图构建阶段、MCTS增强的代码库理解阶段、信息利用和补丁生成阶段。总体工作流程如图1所示。

在代码库知识图构建阶段，RepoUnderstander首先构建一个代码库知识图，以表示整个代码库并描述实体之间的关系。这是通过解析软件结构并以自上而下的方式进行分析来实现的。代码库首先被组织成一个层次结构树，允许清晰地理解代码的上下文和范围。为了促进全面的依赖和交互分析，树结构进一步扩展成一个捕获函数调用关系的引用图。

由于代码库知识图的规模和信息复杂性，在MCTS增强的代码库理解阶段，RepoUnderstander使用蒙特卡罗树搜索算法动态探索整个图。该方法着重发现对解决问题有显著影响的关键信息（即代码库功能和依赖结构）。通过相关扩展和引用扩展，MCTS模拟多个轨迹并评估其重要性，动态缩小搜索空间，将计算资源分配到最相关的区域。此目标导航使模型能够更有效地访问和处理重要信息，从而促进精确的故障定位和知情的补丁生成。

受人类程序员实际开发经验的启发，在解决具体任务之前，需要对代码库有一定的全局先验知识。因此，在信息利用和补丁生成阶段，RepoUnderstander首先总结在代码库理解阶段收集的重要信息，形成对整个代码库的经验。然后，为了使RepoUnderstander在问题解决过程中使用全局经验获取动态信息，我们遵循AutoCodeRover【49】的信息检索方法，使用API工具从代码库知识图中提取信息。这包括特定的类和函数以及代码片段等，以在任务过程中保持局部动态知识。收集到足够的上下文后，RepoUnderstander使用全局经验总结当前获取的信息，以定位故障，生成修改后的代码并返回试图解决问题的补丁。

3.2 代码库知识图构建

对于人类程序员来说，在解决项目级问题时，开发者首先需要仔细审查和理解项目的软件代码库，以确保他们对可能涉及的功能模块和依赖关系有全面的理解。这包括构建软件代码库的层次树结构和调用图。通过层次树结构，开发者可以清楚地看到项目的整体架构以及各模块之间的关系；通过调用图，开发者可以了解函数之间的调用关系和依赖路径，以确定问题的根本原因和更改的潜在影响。

因此，为了借鉴人类程序员在理解和维护代码方面的实践，我们将整个代码库表示为一个代码库知识图，并通过解析软件结构来描述实体之间的关系（见图1中的代码库知识图构建）。

首先，我们自上而下分析软件代码库的结构，将代码库组织成一个包含文件、类和函数的层次结构树，以清晰地了解代码的上下文和范围。然后，我们将树结构扩展成一个包含函数调用关系的引用图，以便模型进行全面的依赖和交互分析。与现有方法【10, 29】不同，我们的引用关系仅涉及函数，因为函数是程序执行的基本单位，函数之间的调用关系直接影响程序的行为和执行逻辑。过多的引用关系可能会增加图结构的复杂性，影响模型的分析效率和准确性。这种结构化的代码库知识图不仅提高了模型检索相关信息的效率，还确保了自动化过程的一致性和可靠性。

具体来说，我们递归遍历代码库中的每个代码文件，使用抽象语法树分别解析相应的文件，获取类和函数等基本单元，包括它们的名称、代码片段、路径和在文件中的位置。然后，我们将这些元素自上而下添加到结构树中。最后，我们分析函数之间的调用关系，并将相应的有向边添加到图中。这种深入的理解为LLM代理提供了必要的背景知识和上下文信息，使他们能够更准确地定位问题并提出有效的解决方案。

3.3 MCTS增强的代码库理解

在构建代码库知识图之后，全面理解图中的信息对于有效解决问题至关重要。然而，鉴于现代软件系统的复杂性和规模，通常包含数百个文件和数千个函数。大型软件代码库中的搜索空间庞大，使得穷举分析变得不切实际。此外，语言模型的上下文长度限制了在给定对话中可以高效处理的信息量。因此，如果没有有针对性的方法来识别图中的高相关节点和边，模型可能难以进行准确和高效的分析，从而妨碍其解决现实世界软件工程问题的能力。

为了解决这些挑战，我们提出了一种基于蒙特卡罗树搜索（MCTS）的代码库探索方法，以增强LLM和代理对软件代码库的理解（见图1中的MCTS增强的代码库理解）。这种方法系统地探索代码库知识图，并优先发现对解决问题有较大影响的关键信息，例如代码库功能和依赖结构。通过模拟多个轨迹并评估其重要性，M

CTS动态缩小搜索空间，将计算资源集中在最相关的区域。这种目标导航使模型能够更高效地访问和处理重要信息，从而促进精确的故障定位和知情的补丁生成。MCTS过程从根节点开始，代表代码库节点，并在选择、相关扩展、模拟和评估以及回溯和引用扩展四个迭代阶段展开。下面我们详细介绍每个阶段。

选择. 选择阶段旨在平衡节点选择过程中的探索和利用问题。该阶段的主要挑战是在代码库中高度相关内容的深入分析与广泛搜索潜在重要信息之间保持平衡。过度深入高相关模块可能导致模型陷入局部最优解，忽略其他关键路径或依赖关系的存在。广泛搜索可能导致计算资源分散，处理大量无关信息，增加模型负担，降低搜索效率。为平衡上述两方面的需求，我们使用UCT算法【20】进行节点选择，公式如下：$$UCT=\frac{w_i}{n_i}+c\sqrt{\frac{2\ln n_p}{n_i}}$$，其中$w_i$是子节点$i$的总奖励。具体奖励的计算将在模拟和评估部分详细介绍。$n_i$是子节点$i$的访问次数，$n_p$是父节点的访问次数。$c$是用于调整探索和利用平衡的探索参数。在本文中，我们将$c$设置为$\sqrt{2}/2$。

相关扩展。在扩展过程中，将叶节点扩展以包含新节点。如果当前叶节点在代码库知识图中有子节点，则选择最可能的子节点而不是随机扩展。在此阶段，我们设计了两种方法：相关扩展和引用关系扩展。本节主要介绍相关扩展，引用关系扩展将在回溯和引用扩展部分介绍。相似代码最有可能与用户需求相关。用户需求或问题通常包含一些可能添加新功能或修改功能的关键词。因此，我们使用bm25得分计算相关性【9, 17, 42】，优先扩展相关性较高的代码。相关扩展可以有效匹配用户需求与代码库知识图中的相关节点，从而提高节点扩展的准确性和效率。

模拟和评估。完成扩展后，进入模拟过程。在模拟过程中，我们从新扩展的节点开始，沿可能的路径进行模拟，以评估这些路径在解决当前问题中的有效性。与相关扩展方法一致，我们在代码库知识图中持续递归选择相关性最高的子节点，直到叶节点，然后奖励这些节点。

在评估阶段，我们需要评估所选叶节点与问题的相关性，包括类、顶级函数、类方法或子函数等。然而，传统评估方法通常依赖关键词匹配和语义匹配算法，在处理复杂软件系统和多样化问题描述时表现不佳。

受大语言模型在上下文学习（ICL）【11, 40】和思维链（CoT）【38】方法中成功的启发，我们提出了一种基于ICL和CoT的奖励方法，旨在为软件代码库中的相关性评估提供更准确和可靠的解决方案。我们的方法利用大语言模型的先进能力，从有限的编程实践示例中学习和优化奖励函数，以准确评估叶节点与问题描述之间的相关性。具体来说，我们首先使用ICL让语言模型学习在给定上下文中理解奖励函数的核心功能和操作模式。然后，使用CoT让模型根据问题和代码片段中的特定信息进行深入推理，以评估叶节点的相关性。我们设计的奖励函数提示模板（见图2）以指导性系统提示开始，明确指出奖励函数的目标和职责。然后，通过一系列<问题描述、代码片段、思考过程、结果>的示例组合，展示评分过程中输入、输出和推理链。最后，提示以一组新问题描述和代码片段结束，此时模型预期从给定示例中学习中间推理步骤并输出相应的奖励分数。最终，我们只保留奖励分数不低于6的节点，并返回其内容和结构依赖关系。

回溯和引用扩展。评估结束后，我们从终端节点到根节点进行自下而上的更新。在此过程中，我们更新访问次数$n$和奖励值$w$。此外，我们在回溯阶段引入了引用关系扩展。与传统扩展方法不同，我们不仅在遇到叶节点时进行扩展，还在遇到奖励分数较高的节点（奖励分数不低于6）时，基于代码库知识图扩展其引用模块和对象，并将它们整合成新节点。洞察是，在实际开发中，当前节点调用的节点通常是功能实现的关键节点，调用的节点通常依赖于当前节点的实现和变化。因此，如果一个节点有较高的奖励分数，具有调用关系的节点也可能相关。通过扩展这些调用关系节点，可以更全面地捕捉与当前问题相关的代码片段。

3.4 信息利用和补丁生成

在此阶段，RepoUnderstander首先总结整个代码库经验，然后在此基础上动态获取代码片段信息，最后生成试图解决问题的补丁。具体步骤如下：

代码库总结。为了更有效地利用在代码库理解阶段收集的全局代码库信息，我们引入了一个总结代理。该代理旨在系统地分析和总结代码库知识图和提交问题中收集的代码片段，然后规划解决问题的方案，从而形成整个代码库的经验。具体来说，总结代理将问题和收集到的相关代码片段作为输入，然后按顺序输出相关片段的总结并规划解决方案。具体的提示模板见图3。由于收集到的全局代码库信息可能复杂，包含大量代码片段和注释描述，我们只使用相关代码片段的位置描述（即代码库中的结构依赖关系）和总结代理的输出（即总结和规划）作为RepoUnderstander的经验，以指导后续行动。这些经验不包含具体的函数实现，只关注总体代码库经验指导。位置描述形式化为a.pyClass Afunc a，总结代理输出如图3所示。

动态信息获取。全局经验信息是RepoUnderstander对当前工作区中相关信息的总结，可以帮助语言模型更快地理解问题并找到解决方案。在解决问题的过程中，为了充分利用这种全局经验信息，RepoUnderstander还需要动态地从当前代码库中提取局部信息，包括代码库中的特定类、函数和代码片段。

ReAct【44】框架（即推理然后行动）引导模型以交错的方式生成推理轨迹和特定任务动作，使模型能够与代码库交互并收集信息。具体来说，ReAct框架首先通过思维链【38】生成推理路径，然后根据推理结果输出实际行动。因此，通过使用ReAct方法，RepoUnderstander可以根据任务需求调用相应的搜索API，从当前代码库中动态提取局部信息以收集相关上下文。我们遵循AutoCodeRover的搜索API方法【49】，使用search_class、search_method和search_code的三层搜索方法。具体来说，RepoUnderstander首先独立确定需要调用的API。然后检索API将在代码库知识图中搜索类、方法和代码片段，最终将结果返回给代理。

补丁生成。在补丁生成步骤中，RepoUnderstander首先根据全局经验和动态信息总结定位故障，提取可能需要修改的代码片段上下文，然后生成修改后的代码片段。最后，根据修改前后的代码片段生成diff，并作为最终结果返回。如果由于语法问题导致diff不正确，我们将重试，直到生成语法正确的适用补丁为止。我们遵循AutoCodeRover【49】的方法，将最大重试次数设置为3，以确保生成的补丁尽可能适用。

4 实验

为了验证RepoUnderstander的性能，我们进行了实验，并与其他LLM和代理进行了比较，证明其优越性（第4.2节、第4.4节）。此外，我们发现SWE-bench【19】中由于测试补丁中包含新添加的函数名和变量名而导致的信息不对称问题（第4.3节）。我们提出了针对新功能类型问题的补丁，以解决这一问题，并在新的FIX版本测试集中测试代理。最后，我们系统地分析了RepoUnderstander在不同阶段的问题解决能力（第4.5节）。

4.1 实验设置

数据集。我们在SWE-bench Lite数据集【19】上进行评估，由于在完整SWE-bench上进行评估成本高昂，因此构建了SWE-bench Lite。SWE-bench Lite包括从SWE-bench中抽样的300个任务实例，遵循类似的代码库分布。SWE-bench团队建议未来系统在必要时在SWE-bench Lite上报告结果，以代替完整的SWE-bench集。SWE-bench Lite旨在提供一组多样化的代码库问题，可以使用代码库中的单元测试进行验证。

它要求LLM系统根据代码库中的实际问题生成相应的补丁，然后通过测试。

基线。我们将RepoUnderstander与两类基线进行比较。第一类是RAG基线【19】。这类基线使用BM25方法检索与问题相关的代码库文件，并将其输入LLM直接生成解决问题的补丁文件。第二类基线是代理基线（即AutoCodeRover【49】和SWE-agent【43】），通过复杂的多轮交互和执行反馈定位问题，最终通过迭代验证生成解决问题的补丁。

度量。按照SWE-bench【19】，我们使用解决实例的百分比和补丁应用率来评估RepoUnderstander的有效性。其中，补丁应用率指的是使用Git工具成功生成并可以应用于现有代码库的实例比例。解决比例表示解决实际GitHub问题的总体有效性，应用比例反映补丁可用性的中间结果。

表1：RepoUnderstander在SWE-bench-lite测试集上的性能主要结果。括号中的数字表示解决的问题数。

配置。 所有RepoUnderstander的结果、消融和结果分析均使用GPT4-Turbo模型（即gpt-4-1106-preview【1】，与SWE-agent【43】相同的模型）。我们使用ast2和Jedi3库解析代码库并获取代码库的语法结构和依赖关系。在MCTS增强的代码库理解阶段，我们将搜索迭代次数设置为600次，最大搜索时间限制为300秒。在信息利用和补丁生成阶段，我们将最大摘要代码片段数量设置为10。SWE-bench有一个相对复杂的环境配置。感谢开源社区的发展，我们使用AutoCodeRover团队的开源docker进行实验。

4.2 比较实验

我们首先在SWE-bench Lite（300个实例）上评估RepoUnderstander的有效性。RepoUnderstander与其他方法的性能对比分析见表1。在每个实例中，我们提供来自现实世界的软件工程问题的自然语言描述和相应版本的本地代码库，要求模型解决问题并生成可以通过本地自动化测试的补丁。解决表示当前RAG LLM系统和代理系统解决软件工程问题的端到端能力。结果表明，RepoUnderstander显著优于其他RAG和代理系统，在测试集上实现了SOTA性能。与RAG系统相比，我们的方法将性能提高了近5倍。与最先进的代理系统相比，我们将SWE-agent的准确性提高了18.5%。这些优异的表现证明了我们方法的先进性。此外，应用率表示生成补丁的可用性。我们发现代理系统都实现了较高的可用性，而RAG系统的可用性较低，这证明了代理系统可能是自动解决软件工程任务的重要手段。由于引入了运行反馈能力，SWE-agent具有最高的应用率，这表明运行反馈是一种有效的方法。本文更多关注对整个代码库信息的理解。我们将在未来工作中整合运行反馈。

此外，我们还比较了三种基于代理的方法解决问题的分布图，结果如图4所示。我们发现我们的方法与SWE-agent方法非常互补。两种方法共同解决了80个实例，实现了26.67%的任务解决率（见表2），这进一步说明了我们的方法与执行反馈方法的互补性。我们将在未来工作中详细讨论和结合这两种方法。

4.3 数据集分析与修复

用户问题通常包括错误报告、功能请求和增强等【22, 30, 31, 39】。在SWE-bench数据集【19】中，我们发现对于功能请求类型的问题存在信息不对称现象，例如添加函数或参数定义。具体来说，由于测试补丁中包含新功能的签名信息，而LLM代理输入缺乏这些接口规范信息，代理模型可能无法正确理解问题的全部上下文。即使生成的补丁逻辑正确，测试时也可能会出错。这种信息不对称可能会影响LLM代理的性能评估和实际应用。从软件工程实践的角度来看，新功能通常在系统设计文档中定义和规范。在实际开发中，这些新功能的信息应当明确规定，而不是由代理模型推断。因此，将测试补丁中的新功能接口规范合并到问题描述中，可以使代理模型更好地理解问题，减少信息不对称带来的影响。

我们对SWE-bench Lite数据集进行了修复，并提出了一个FIX版本。具体来说，我们通过手动分析，将测试补丁中的新功能接口规范合并到问题描述中，并引导代理模型根据完整的问题描述生成补丁。总共，我们修复了SWE-bench Lite中的45/300个实例。这种方法可以更好地反映实际情况，减少信息不对称引起的问题，从而提高自动软件工程技术在实际应用中的可信度和有效性。如表3所示，我们的实验结果表明，在FIX版本测试集中，RepoUnderstander和AutoCodeRover【49】的方法均有所提高，其中RepoUnderstander表现最佳，进一步证明了RepoUnderstander的优越性能。我们期待后续的代理系统工作在FIX版本上报告其性能。

4.4 消融研究

4.4.1 模块分析。此消融实验旨在研究RepoUnderstander的全局代码库理解组件的有效性。（1）移除MCTS和总结模块：RepoUnderstander没有代码库结构和功能的先验知识，即缺乏对整个代码库的经验信息，只能通过搜索问题中的有限信息来定位相关代码片段。（2）仅移除总结模块：只使用MCTS获得的相关代码库信息的签名和依赖结构作为全局经验，移除信息的总结和规划。此实验旨在验证总结代理的有效性，即对代码库信息的综合总结的重要性。（3）添加一个审查代理模块：在RepoUnderstander生成一个可以应用的补丁后，为模拟开发过程中的代码审查过程，添加一个静态审查生成的补丁的审查代理，以发现新生成代码中的可能缺陷。如果存在缺陷，根据审查原因重新生成补丁，直到生成通过审查的补丁为止。此过程最多重复三次。

我们的实验结果证明了全局经验的重要性和总结代理的有效性。如表4所示，移除这些模块均导致RepoUnderstander性能下降，尤其是在移除MCTS和总结代理后，解决的问题实例数量从64减少到48，这突显了全局经验在自动解决代码库级问题中的重要性。此外，我们发现添加审查代理后，RepoUnderstander的性能下降，表明静态审查的局限性。我们推测基于LLM的静态审查可能只依赖代码的表面语法信息，无法完全理解代码的语义意义。因此，静态审查可能忽略代码中的一些隐藏逻辑错误或不合理情况。因此，我们建议后续工作结合动态程序分析【7, 41, 46】，如程序插桩【14, 16】等，以提高LLM代理的可靠性。

4.4.2 超参数分析。我们进一步分析了MCTS迭代次数的影响。我们将最大迭代次数设置为50、200和600次，并将最大迭代时间限制为300秒。结果如表5所示。我们发现：（1）随着迭代次数的增加，RepoUnderstander解决的实际问题数量增加。这表明随着迭代轮数的增加，代理将收集更多代码库信息，即它们将对代码库有更多经验，导致更高的问题解决率；（2）随着迭代次数的增加，我们发现问题解决的相对改善逐渐减小。具体来说，50次迭代的改进相对于没有迭代显著，但随后200次和600次迭代的相对改善减少。这可能是因为在早期阶段，代理可以快速搜索和总结相关经验，但随着迭代次数的增加，模型的收敛速度逐渐减慢，新信息对性能改进的贡献变小；（3）我们观察到，从200次迭代增加到600次迭代时，应用率下降。这一现象表明，随着迭代次数的增加，模型在生成结果时可能受到一些干扰信息的影响，导致生成结果的质量下降。因此，在选择迭代次数时，需要考虑避免过多干扰信息的影响。

4.5 案例研究

4.5.1 错误原因。尽管RepoUnderstander在ASE任务中取得了比其他方法更好的结果，但该任务仍然具有挑战性（即使RepoUnderstander和SWE-agent共同工作，也只能完全自动解决80/300个实例）。为了指导后续工作的优化，我们分析了未解决问题的具体原因，并将失败类型分为三类：错误定位、补丁应用失败和错误补丁。错误定位意味着代理没有定位问题的根本原因，错误修改了其他正确的位置。补丁应用失败意味着代理没有生成语法正确的补丁，无法直接应用到现有版本的代码库中。错误补丁意味着当错误定位和补丁语法正确时，修复后的代码无法完全解决问题，即测试用例未完全通过。

我们比较了RepoUnderstander和当前SOTA代理SWE-agent在SWE-bench Lite上的结果，如图所示。结果表明：（1）在错误定位方面，我们的方法在45.0%的任务中生成了错误位置的补丁，而SWE-agent在62.0%的任务中生成了错误位置的补丁。这表明我们的方法在正确定位错误方面表现更好，代码库级的全局经验在故障定位中起到了关键作用。（2）在补丁应用性方面，我们的方法在13.7%的任务中没有生成补丁，而SWE-agent在5.0%的任务中生成了补丁。（3）在补丁正确性方面，我们的方法在20.0%的任务中生成了错误补丁，而SWE-agent在15.0%的任务中生成了错误补丁。这些指标表明我们的方法在错误位置定位方面更准确，但在生成正确补丁和确保补丁应用性方面存在一定的弱点。这可能是因为SWE-agent的执行反馈模块允许代理迭代生成和验证补丁的正确性。这也表明执行反馈对解决实际问题的重要性。因此，通过结合代码库级全局经验和有效的执行反馈机制，可以进一步优化自动软件修复的效果。

4.5.2 解决任务研究. 为了进一步分析RepoUnderstander在现实世界问题中的表现，我们从SWE-bench中选取了两个示例（如图6和图7所示），并与SOTA解决方案SWE-agent进行了比较。通过分析oracle补丁，我们确定了需要修改的实际故障位置。其中，绿色高亮表示代理正确跟踪需要修改的目标，黄色高亮表示代理错误识别了不需要修改的目标。

如图6所示，RepoUnderstander在MCTS基础的代码库探索阶段正确探索到与问题相关的函数was_modified_since；在随后的总结阶段，明确指出该函数需要更新；最后，在全局经验的指导下，代理在动态信息获取和补丁生成阶段准确搜索并定位到static.py中的was_modified_since函数，并成功实现正确修改。相比之下，SWE-agent可以通过计算机接口操作搜索文件并查看文件内容，但由于缺乏代码库经验知识的指导，SWE-agent在局部搜索中错误定位到get_conditional_response函数。尽管此函数与解决问题有一定相关性，但它并不是直接相关。因此，修改错误位置导致任务失败。

在图7中，我们分析发现，解决matplotlib-26011任务可以通过修改_set_lim或set_xlim函数实现。RepoUnderstander和SWE-agent均正确定位到需要修改的位置。然而，由于SWE-agent的运行反馈和迭代能力，代理最终通过反馈信息生成了正确的补丁。这表明执行反馈对解决实际问题的重要性。由于RepoUnderstander和SWE-agent具有一定的互补性，未来我们将结合全局经验和有效的执行反馈机制，进一步优化自动软件修复的效果。

5 局限性

5.1 资源开销。

虽然RepoUnderstander旨在指导大语言模型全面理解整个软件代码库，以有效解决自动软件工程（ASE）中的挑战，但蒙特卡罗树搜索（MCTS）过程确实需要一定的资源消耗。具体来说，我们将最大迭代次数设置为600次，最大搜索时间限制为300秒，以确保模型能够充分探索搜索空间并准确评估不同路径的奖励。然而，这些设置是可控和可调整的，以适应不同的应用场景和资源限制。通过合理的参数调整，可以找到资源消耗和结果准确性之间的最佳平衡。此外，如表5所示，仅50次迭代也可以实现优于其他代理的结果。进一步研究可能发现更有效的策略，以在保持或提高代理性能的同时减少资源需求。

5.2 运行时反馈。

RepoUnderstander旨在研究如何理解整个软件代码库，并通过软件知识图构建和MCTS增强的代码库理解等模块在依赖整个代码库知识的任务中表现出有效的ASE能力。SWE-agent【43】使用执行反馈等信息来验证生成补丁的正确性，并迭代修复补丁以通过测试，这对提高补丁生成的正确性具有一定效果。在表2中，我们分析了RepoUnderstander和SWE-agent的解决问题分布，发现两种方法具有一定的互补性，共同解决了SWE-bench Lite上26.67%的问题。受此启发，未来进一步结合RepoUnderstander与运行时反馈是一种增强ASE能力的有效途径。

6 结论

本文强调了理解整个软件代码库作为实现自动软件工程（ASE）关键路径的重要性。为此，我们提出了一种名为RepoUnderstander的新型基于LLM的代理方法，引导代理全面理解整个代码库。具体来说，RepoUnderstander首先构建代码库知识图，将大量复杂的代码库级信息浓缩成层次结构。随后，我们通过蒙特卡罗树搜索（MCTS）增强的代码库探索策略，增强代理对代码库的理解。最后，我们引导代理根据全局经验进行总结、分析和规划，然后他们可以操作工具动态获取信息并生成补丁以解决现实世界的GitHub问题。

我们通过大量实验和全面分析证明了RepoUnderstander的优越性能。我们的方法在SWE-bench Lite基准上实现了最先进的性能，优于现有的RAG和代理系统。此外，我们通过提出一个FIX版本，解决了SWE-bench Lite数据集中的信息不对称问题，将新功能接口规范集成到问题描述中。此外，我们进行消融研究，分析了RepoUnderstander各组件的有效性，并确定了需要进一步改进的领域。我们的研究强调了全局代码库经验的重要性以及整合运行时反馈机制的潜在好处。未来工作将重点结合全局经验与运行时反馈机制，以进一步增强基于LLM的代理在解决复杂软件工程任务中的能力。

致谢

感谢Robert，感谢您提供的面包圈和解释CMYK和颜色空间。

参考文献

[1] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Floren-cia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, 等。2023年。GPT-4技术报告。arXiv预印本 arXiv:2303.08774
(2023)。

[2] Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, 等。2021年。使用大语言模型进行程序生成。arXiv预印本 arXiv:2108.07732
(2021)。

[3] Ramakrishna Bairi, Atharv Sonwane, Aditya Kanade, Arun Iyer, Suresh Parthasarathy, Sriram Rajamani, B Ashok, Shashank Shet, 等。2023年。Codeplan：使用LLM和规划的代码库级编程。arXiv预印本 arXiv:2309.12499
(2023)。

[4] Carlos E. Jimenez, John Yang, Jiayi Geng。2024年。介绍SWE-bench Lite。
https://www.swebench.com/lite.html

[5] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fo-tios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji,

Shan-tanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Josh Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, 和 Wojciech Zaremba。2021年。评估训练在代码上的大语言模型。arXiv:2107.03374 [cs.LG]

[6] Cognition。2023年。介绍Devin。https://www.cognition.ai/introducing-devin

[7] Yinlin Deng, Chunqiu Steven Xia, Haoran Peng, Chenyuan Yang, 和 Lingming Zhang。2023年。大语言模型是零次学习模糊器：通过大语言模型对深度学习库进行模糊测试。第32届ACM SIGSOFT国际软件测试和分析研讨会论文集。423-435。

[8] Yangruibo Ding, Marcus J Min, Gail Kaiser, 和 Baishakhi Ray。2024年。CYCLE：学习自我优化代码生成。ACM编程语言会议论文集8，OOPSLA1（2024），392-418。

[9] Yangruibo Ding, Zijian Wang, Wasi Ahmad, Hantian Ding, Ming Tan, Nihal Jain, Murali Krishna Ramanathan, Ramesh Nallapati, Parminder Bhatia, Dan Roth, 等。2024年。Crosscodeeval：用于跨文件代码完成的多样化和多语言基准。神经信息处理系统会议论文集36（2024）。

[10] Yangruibo Ding, Zijian Wang, Wasi Uddin Ahmad, Murali Krishna Ramanathan, Ramesh Nallapati, Parminder Bhatia, Dan Roth, 和 Bing Xiang。2022年。Cocomic：通过联合建模文件内和文件间上下文的代码完成。arXiv预印本 arXiv:2212.10007
(2022)。

[11] Qingxiu Dong, Lei Li, Damai Dai, Ce Zheng, Zhiyong Wu, Baobao Chang, Xu Sun, Jingjing Xu, 和 Zhifang Sui。2022年。一项关于上下文学习的调查。arXiv预印本 arXiv:2301.00234
(2022)。

[12] Xueying Du, Mingwei Liu, Kaixin Wang, Hanlin Wang, Junwei Liu, Yixuan Chen, Jiayi Feng, Chaofeng Sha, Xin Peng, 和 Yiling Lou。2024年。评估大语言模型在类级代码生成中的表现。第46届IEEE/ACM国际软件工程会议论文集。1-13。

[13] Daya Guo, Qihao Zhu, Dejian Yang, Zhenda Xie, Kai Dong, Wentao Zhang, Guanting Chen, Xiao Bi, Y Wu, YK Li, 等。2024年。DeepSeek-Coder：当大语言模型遇到编程——代码智能的崛起。arXiv预印本 arXiv:2401.14196
(2024)。

[14] Jeffrey K Hollingsworth, Barton Paul Miller, 和 Jon Cargille。1994年。用于可扩展性能工具的动态程序插桩。IEEE可扩展高性能计算会议论文集。IEEE，841-850。

[15] Sirui Hong, Xiawu Zheng, Jonathan Chen, Yuheng Cheng, Jinlin Wang, Ceyao Zhang, Zili Wang, Steven Ka Shing Yau, Zijuan Lin, Liyang Zhou, 等。2023年。MetaGPT：用于多代理协作框架的元编程。arXiv预印本 arXiv:2308.00352
(2023)。

[16] JC Huang。1978年。程序插桩和软件测试。计算机11，4（1978），25-32。

[17] Hamel Husain, Ho-Hsiang Wu, Tiferet Gazit, Miltiadis Allamanis, 和 Marc Brockschmidt。2019年。Codesearchnet挑战：评估语义代码搜索的现状。arXiv预印本 arXiv:1909.09436
(2019)。

[18] Yoichi Ishibashi 和 Yoshimasa Nishimura。2024年。自组织代理：使用多代理的超大规模代码生成和优化的大语言模型。arXiv预印本 arXiv:2404.02183
(2024)。

[19] Carlos E Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, 和 Karthik R Narasimhan。2024年。SWE-bench：语言模型能解决现实世界的GitHub问题吗？第十二届国际学习表征会议。https://openreview.net/forum?id=VTF8yNQM66

[20] Levente Kocsis 和 Csaba Szepesvári。2006年。基于强盗的蒙特卡罗规划。欧洲机器学习会议。Springer，282-293。

[21] Jiaolong Kong, Mingfei Cheng, Xiaofei Xie, Shangqing Liu, Xiaoning Du, 和 Qi Guo。2024年。ContrastRepair：通过对比测试用例对话增强自动化程序修复。arXiv预印本 arXiv:2403.01971
(2024)。

[22] Rahul Krishna, Amritanshu Agrawal, Akond Rahman, Alexander Sobran, 和 Tim Menzies。2018年。问题、错误和增强之间的联系是什么？从800多个软件项目中学到的经验。第40届国际软件工程会议：软件工程实践论文集。306-315。

[23] Cheryl Lee, Chunqiu Steven Xia, Jen-tse Huang, Zhouruixin Zhu, Lingming Zhang, 和 Michael R Lyu。2024年。一种通过LLM多代理协同的方法实现统一的调试方法。arXiv预印本 arXiv:2404.17153
(2024)。

[24] Ming Liang, Xiaoheng Xie, Gehao Zhang, Xunjin Zheng, Peng Di, Hongwei Chen, Chengpeng Wang, Gang Fan, 等。2024年。REPOFUSE：通过融合的双上下文实现代码库级代码完成。arXiv预印本 arXiv:2402.14323
(2024)。

[25] Jiawei Liu, Chunqiu Steven Xia, Yuyao Wang, 和 Lingming Zhang。2024年。你的代码真的由ChatGPT生成正确了吗？对大语言模型代码生成的严格评估。神经信息处理系统会议论文集36（2024）。

[26] Tianyang Liu, Canwen Xu, 和 Julian McAuley。2023年。Repobench：代码库级代码自动完成系统的基准测试。arXiv预印本 arXiv:2306.03091
(2023)。

[27] Anton Lozhkov, Raymond Li, Loubna Ben Allal, Federico Cassano, Joel Lamy-Poirier, Nouamane Tazi, Ao Tang, Dmytro Pykhtar, Jiawei Liu, Yuxiang Wei, 等。2024年。StarCoder 2和The Stack v2：下一代。arXiv预印本 arXiv:2402.19173
(2024)。

[28] Shuai Lu, Daya Guo, Shuo Ren, Junjie Huang, Alexey Svyatkovskiy, Ambro-sio Blanco, Colin Clement, Dawn Drain, Daxin Jiang, Duyu Tang, 等。2021年。Codexglue：用于代码理解和生成的机器学习基准数据集。arXiv预印本 arXiv:2102.04664
(2021)。

[29] Qinyu Luo, Yining Ye, Shihao Liang, Zhong Zhang, Yujia Qin, Yaxi Lu, Yesai Wu, Xin Cong, Yankai Lin, Yingli Zhang, 等。2024年。RepoAgent：用于代码库级文档生成的LLM框架。arXiv预印本 arXiv:2402.16667
(2024)。

[30] Thorsten Merten, Matúš Falis, Paul Hübner, Thomas Quirchmayr, Simone Bürsner, 和 Barbara Paech。2016年。在问题跟踪系统中检测软件功能请求。2016年IEEE第24届国际需求工程会议（RE）。IEEE，166-175。

[31] Moran Altarac。2024年。掌握错误报告和反馈收集：综合指南。https://www.guidde.com/blog/mastering-bug-reporting-and-feedback-collection-a-comprehensive-guide

[32] OpenDevin。2023年。OpenDevin。https://github.com/OpenDevin/OpenDevin

[33] Yihao Qin, Shangwen Wang, Yiling Lou, Jinhao Dong, Kaixin Wang, Xiaoling Li, 和 Xiaoguang Mao。2024年。AgentFL：将LLM故障定位扩展到项目级上下文。arXiv预印本 arXiv:2403.16362
(2024)。

[34] Zeeshan Rasheed, Muhammad

Usman Afzaal, 和 Asad Abbas。2024年。CodeAGI：多智能体环境中的大型代码语言模型。arXiv预印本 arXiv:2404.05033
(2024)。

[35] Leonardo Rigutini 和 Leonardo Chiarugi。2024年。UnifiedTaskCodeCompletion：基于统一任务生成的代码完成框架。arXiv预印本 arXiv:2404.11875
(2024)。

[36] Philip Ross, Ryuji Imamura, Samantha Atkins, Jose Caballero。2024年。语言模型的下一代：EVAL能力。arXiv预印本 arXiv:2404.12322
(2024)。

[37] Timothy Teale, Kai Song, Xunzhe Tian, Zechun Liu, Bicheng Xu, Zhaowei Zhu, Quan Chen, Chen Qiu, Da Yin, Xin Jiang, 等。2024年。阿波罗系统：一个环境感知的跨任务、跨领域、多模式智能体。arXiv预印本 arXiv:2404.08090
(2024)。

[38] Jacob Weller, Jonathan M Francis, Alex Turner, 和 Rohin Shah。2023年。反思大语言模型的局限性。arXiv预印本 arXiv:2305.11756
(2023)。

[39] Whirl Software Limited。2024年。用于工程团队的现代问题跟踪工具。https://www.whirlsoftware.com

[40] Zhengyuan Yang, Jiacheng Liu, Yichong Xu, Yi-Lin Tuan, Ming Zhong, 和 Diyi Yang。2024年。适应多样性的多任务上下文学习。arXiv预印本 arXiv:2402.15077
(2024)。

[41] Yining Ye, Qinyu Luo, Shihao Liang, Zhong Zhang, Yujia Qin, Xueliang Fu, Yankai Lin, Yuren Xu, 和 Lei Li。2024年。ExploAgent：通过动态分析优化LLM驱动的错误探索。arXiv预印本 arXiv:2404.19192
(2024)。

[42] Chengcheng Yin, Duan Yu, Shao Zhang, Liying Huang, 和 Xiaoling Ma。2024年。CROSSAPP：用于跨文件和多程序代码补全的多层嵌入。arXiv预印本 arXiv:2401.02487
(2024)。

[43] John Yang, Yiwen Sun, Lu Yin, Carlos E Jimenez, Ofir Press, Shunyu Yao, Alexander Wettig, Kexin Pei, 和 Karthik R Narasimhan。2024年。SWE-agent：使用执行反馈解决GitHub问题的语言模型代理。arXiv预印本 arXiv:2402.14029
(2024)。

[44] Shunyu Yao, Dian Yu, Jeffrey Zhao, Nan Liu, Qian Huang, Mark Riedl, Izhak Shafran, 和 Thomas Lukasiewicz。2023年。ReAct：通过推理然后行动来激活语言模型的推理和行动能力。arXiv预印本 arXiv:2210.03629
(2023)。

[45] Lei Zhao, Zhaohong Jiang, Runzhou Han, Yichi Zhang, Chengkun Mu, Ze Yang, Yangliu Chu, 和 Chao Zhang。2024年。适应代理任务的动态插桩框架。arXiv预印本 arXiv:2404.06192
(2024)。

[46] Youcheng Zhao, Sidi Lu, Chengwei Wei, Tiancheng Yang, 和 Michael R Lyu。2024年。不同语言和错误类型的LLM自动调试能力。arXiv预印本 arXiv:2403.17478
(2024)。

[47] Xuncheng Zhu, Mengdi Wu, 和 Qiuzhao Zhang。2024年。RepoCoder：基于大语言模型的代码库级编程。arXiv预印本 arXiv:2401.06537
(2024)。

[48] Alexander Wettig, Shunyu Yao, John Yang, Kexin Pei, Ofir Press, 和 Karthik R Narasimhan。2024年。ToolPlan：通过代理支持的代码生成。arXiv预印本 arXiv:2401.14987
(2024)。

[49] Haotian Ye, Jieshan Chen, Hongxin Wei, Yue Wu, Dianshuo Wang, 和 Junchi Yan。2024年。AutoCodeRover：通过代码上下文导航的基于工具的程序修复代理。arXiv预印本 arXiv:2403.07371
(2024)。

[50] Zhirui Zhang, Lili Mou, Ziyang Liu, Minghui Yang, 和 Jieming Zhu。2024年。引导程序生成：一种用于高效代码生成的新方法。arXiv预印本 arXiv:2401.06656
(2024)。