MANTRA:通过上下文感知的RAG和多智能体LLM协作增强自动方法级重构

软件系统的维护和扩展高度依赖于有效的代码重构，然而这一过程仍然非常耗费人力，需要开发者仔细分析现有的代码库并防止引入新的缺陷。尽管最近的研究利用大型语言模型（LLMs）实现了重构任务的自动化，但当前解决方案在范围上受到限制，并缺乏保证代码可编译性和测试成功执行的机制。在这项工作中，我们介绍了MANTRA，这是一种基于LLM代理的全面框架，用于自动化方法级重构。MANTRA集成了上下文感知检索增强生成、协调的多代理协作以及口头强化学习，以模拟重构过程中的人类决策，同时保持代码的正确性和可读性。我们的实证研究基于从10个具有代表性的Java项目中抽取的703个“纯重构”实例（即仅涉及结构改进的代码变更），涵盖了六种最常见的重构操作。实验结果表明，MANTRA显著超越了基线LLM模型（RawGPT），在生成可编译并通过所有测试的代码方面取得了82.8%的成功率（582/703），而RawGPT仅为8.7%（61/703）。此外，与IntelliJ的基于LLM的重构工具（EM-Assist）相比，MANTRA在生成提取方法转换方面的表现提高了50%。一项涉及37名专业开发者的可用性研究进一步表明，由MANTRA执行的重构被认为与人类编写代码一样可读且可重用，在某些情况下甚至更受欢迎。这些结果突显了MANTRA的实际优势，并强调了基于LLM的系统在推进软件重构任务自动化方面的巨大潜力。

1 ## 尼古拉·桑塔利斯

计算机科学与 软件工程系，康考迪亚大学 蒙特利尔，加拿大 nikolaos.tsantalis@concordia.ca

ACM参考格式：

许义森，林峰，杨锦秋，陈泽逊（Peter），尼古拉·桑塔利斯。2025年。MANTRA：通过上下文感知的RAG和多智能体LLM协作增强自动方法级重构。ACM会议论文集（Conference’17）。ACM，纽约，NY，美国，12页。https://doi.org/10.1145/nnnnnnn.nnnnnnn

1 引言

重构是不改变代码整体行为的情况下改进代码总体设计和结构的过程[16]。重构的目标是提高可维护性并促进未来功能扩展[34]，使其成为适应不断变化的软件需求的关键。然而，尽管重构有许多好处，许多开发者由于时间和精力的投入而不愿进行重构[45]。开发者通常需要首先分析重构的可能性，然后修改代码以进行重构，最后确保重构不会引入新问题。

为了帮助开发者进行重构，研究人员和集成开发环境（IDE）开发者（如Eclipse和Intellij IDEA）提出了自动重构技术。例如，Tsantalis和Chatzigeorgiou [57, 58] 提出了JDeodorant来检测代码气味，如特征嫉妒和长方法，并应用重构操作。WitchDoctor [15] 通过监控代码变更是否触发预定义规范来提供建议。这些工具的一个共同特点是基于预定义规则或度量。虽然有用，但它们缺乏对项目领域特定结构的深入理解，无法生成类似开发者编写的重构，导致实际开发中的接受度较低。

最近关于大型语言模型（LLMs）的研究展示了其在处理复杂编程任务上的巨大潜力和能力[30, 62, 66, 68]，使它们成为克服先前挑战的可能解决方案，即生成高质量的重构代码，类似于人类编写的代码。一些研究[5, 13, 已经探索了LLMs在重构中的应用，展示了它们在分析重构机会和应用代码变更方面的强大能力。然而，现有技术主要依赖于简单的提示式重构生成，专注于有限类型的重构，并缺乏适当的验证

本文中，我们提出了一种端到端的基于LLM代理的解决方案MANTRA（Multi-AgeNT Code RefAactoring），用于自动方法级重构。给定一个需要重构的方法和指定的重构类型，MANTRA生成完全可编译、可读且通过测试的重构代码。MANTRA包括三个关键组件：(1) 上下文感知检索增强重构代码生成，构建一个可搜索数据库，提供少量示例以改善重构质量；(2) 多代理重构代码生成，采用开发者代理和评审者代理来模拟真实的重构过程并生成高质量的重构；(3) 使用口头强化学习进行自我修复，通过迭代识别和纠正导致编译或测试失败的问题，使用口头强化学习框架[50]。

我们使用来自先前重构研究[21, 22, 28]的10个Java项目评估了MANTRA。这些项目涵盖不同的领域，具有丰富的提交历史记录，并包含大量测试。由于大多数重构变更伴随着无关的代码变更（例如，错误修复或功能添加）[53]，我们收集了“纯重构变更”（即，除了重构之外没有其他代码变更）以消除在评估MANTRA的重构能力时的噪声。我们应用PurityChecker[36]过滤提交，最终获得了703个用于实验的纯重构，涵盖了最常见的六种重构活动[20, 40, 53]：提取方法、移动方法、内联方法，以及相关的复合重构活动：提取和移动方法、移动和内联方法、移动和重命名方法。使用这些重构，我们将MANTRA与我们的LLM基线（RawGPT）、IntelliJ的基于LLM的重构工具（EM-Assist[42]）以及人类编写的重构代码进行了比较。此外，我们进行了一项用户研究以获取开发者对MANTRA生成代码的反馈，并进行了消融研究以评估MANTRA中每个组件的贡献。

我们的结果表明，MANTRA在功能正确性和人类相似性（与开发者重构相比的相似度）方面均优于RawGPT。MANTRA在生成可编译并通过测试的重构代码方面的成功率达到了显著更高的82.8%（582/703），而RawGPT仅为8.7%。与EM-Assist相比，MANTRA在生成提取方法重构方面的表现提高了50%。与人类编写的代码相比，我们的用户研究（涉及37名开发者）发现MANTRA和人类重构在可读性和可重用性评分上相似。然而，在提取和移动及移动和重命名重构方面，由于MANTRA清晰的注释和更好的代码命名，其表现更好。相比之下，人类在内联方法重构方面通过额外改进表现更好。最后，我们的消融研究表明，移除MANTRA的任何组件都会导致明显的性能下降（40.7%-61.9%），其中评审者代理对整体有效性贡献最大。

我们总结主要贡献如下：

• 我们提出了一种端到端的基于代理的重构解决方案MANTRA，该方案在重构过程中考虑了编译成功和功能正确性。MANTRA利用上下文感知检索增强生成来学习开发者的重构模式，整合多个LLM代理以模拟开发者的重构过程，并采用口头强化学习框架来改进重构代码的正确性。
• 我们进行了广泛的评估，MANTRA成功生成了582/703可编译并通过测试的重构代码，显著优于仅生成61个成功重构的RawGPT。与主要关注提取方法重构的最先进的基于LLM的技术EM-Assist相比，MANTRA实现了50%的改进。
• 我们进行了一项用户研究，比较了MANTRA生成的和人类编写的重构代码。对37份响应的分析表明，MANTRA生成的重构代码在可读性和可重用性方面与开发者编写的代码相似。此外，MANTRA生成的代码在方法命名和代码注释方面具有更好的优势。
• 我们将数据和代码公开可用[6]。

论文组织结构。第2节讨论相关工作。第3节详细说明MANTRA的设计和实现。第4节展示MANTRA的评估结果。第5节讨论局限性和潜在的有效性威胁。最后，第6节总结我们的发现并概述未来工作的方向。

2 相关工作

传统的重构方法。重构在软件开发中起着至关重要的作用，并极大地影响软件质量。传统重构研究通常集中在两个主要方面：识别重构机会和推荐重构解决方案。在机会识别方面，现有方法已经探索了各种方法，例如计算实体和类之间的距离以进行Move Method重构[57]，评估结构和语义凝聚度以寻找Extract Class机会[10]，并利用逻辑元编程技术揭示重构可能性[56]。另一方面，解决方案推荐通常涉及自动化技术。[37]介绍了一个名为CODe-Imp的工具，该工具使用基于搜索的技术来进行重构。WitchDoctor [15] 和BeneFactor [19] 监控代码变更并自动建议重构操作。然而，这些方法往往受到其基于规则的性质的限制，可能将其限制在某些类型的重构上，或者在重构过程中遇到未处理的问题。 基于LLM的重构代码生成技术。最近关于LLM的研究展示了它们在处理复杂任务方面的显著能力，使其成为克服传统重构方法局限性的有希望的解决方案。现有研究利用LLM进行各种重构任务：直接通过GPT-4提示重构任务[13, 41]，通过精心设计的提示准确识别重构机会[31]，以及推荐特定类型的重构，如提取方法[52]。其他研究通过强调提示清晰度[5]、使用精心挑选的少量示例[51]和应用结构化提示技术[65]进一步改进了基于LLM的重构。此外，结合基于规则系统和LLM的混合方法在单方法技术之上实现了优越的结果[69]。自动框架和工具，如Context-Enhanced Framework for Automatic Test Refactoring [17]和工具如EM-Assist [43]，进一步展示了这些技术的实际应用，强调了将LLM集成到全面、反馈驱动的重构工作流中的价值。EM-Assist甚至在Move Method重构上超过了所有先前的工具[43]。

虽然这些技术利用LLM进行自动重构，但它们通常只关注一种或两种类型的重构，忽略了复合或仓库级别的转换（如Extract and Move Method），并且未能确保重构后的代码可以编译并通过所有测试。相比之下，MANTRA使用LLM代理来模拟开发者的重构过程，并整合传统工具以提供反馈。MANTRA为更广泛的重构活动生成重构代码，并确保生成的代码可以编译并通过所有测试。 基于LLM的代码质量改进方法。以往的研究还探讨了使用LLM来改进软件质量的其他方面，如安全性、性能和设计。例如，Lin等人[30]提出利用软件过程模型来增强代码生成任务中的设计质量。Ye等人[68]引入了LLM4EFFI，进行了全面研究以提高代码效率。Wadhwa等人[62]提出了CORE，这是一种利用指令跟随型LLM协助开发人员通过有针对性的修订解决代码质量问题的方法。Wu等人[66]提出了iSMELL，它将LLM集成到代码气味检测和后续重构中，从而系统地提高软件质量。受这些研究的启发，我们在生成过程中通过集成代码风格检查器（即CheckStyle[11]）设计了MANTRA，以考虑代码可读性。

3 方法论

在本节中，我们介绍MANTRA（Multi-AgeNT Code RefAactoring），一种基于LLM和代理驱动的自动代码重构解决方案。由于方法级重构在实践中广泛采用[29, 35]，MANTRA专注于方法级重构。特别是，我们实现了总共六种重构活动，构成三种最常见的重构活动[20, 40, 53]：提取方法、移动方法和内联方法；以及这三种活动的复合重构活动：提取并移动方法、移动并内联方法和移动并重命名方法。这些重构活动考虑了简单和复杂的重构场景。

MANTRA以需要重构的方法代码和指定的重构类型作为输入。然后，它自动在方法中找到重构机会，并生成完全可编译且高度可读的重构代码，能够通过所有测试。MANTRA包含三个关键组件：1）RAG：上下文感知检索增强重构代码生成，2）重构代码生成：多代理重构代码生成，3）修复：使用口头强化学习进行自我修复。RAG组件构建了一个包含之前重构作为少量示例的可搜索数据库，以指导MANTRA。重构代码生成组件使用多代理框架，利用LLM的规划和推理能力生成重构代码。最后，自我修复组件实施口头强化学习框架[50]，自动识别并纠正生成的重构代码中的问题。

3.1 上下文感知检索增强重构代码生成

图1展示了MANTRA的RAG构建过程概述。RAG为LLM提供了少量学习的相关示例，从而提高了生成准确且上下文相关输出的能力[23, 51]。RAG通过将外部知识整合到信息检索和文本生成中，采用两阶段过程——检索和生成[18]。下面，我们讨论MANTRA的RAG设计细节。 构建纯重构代码示例数据库。我们的目标是构建一个仅包含纯重构代码变更的数据库，这些变更涉及改进代码结构而不改变功能。然而，在现实中，重构通常伴随无关的代码变更，例如错误修复或功能添加[53]。这些变更包含噪音，使得此类重构代码变更无法作为引导LLM生成通用重构代码的少量示例。

我们使用Refactoring Oracle Dataset [61]构建纯重构数据库，该数据集中包含了从188个开源Java项目的547次提交中收集的12,526次重构（主要是不纯的重构）（2011年至2021年）。我们选择这个数据集是因为它包含了各种项目和重构类型，并被用作评估重构检测工具（例如，RefDiff [54]和RefactoringMiner [60, 61]）准确性的基准，因此非常适合我们的目的。我们纳入了PurityChecker [36]，这是RefactoringMiner的一个扩展，专门用于评估方法级重构的纯度，排除与功能性功能修改相关的重构。我们选择使用RefactoringMiner和PurityChecker，因为它们得到了良好的维护，并以其高检测准确性著称。RefactoringMiner的平均精确度和召回率分别为99%和94% [61]，而PurityChecker在Refactoring Oracle Dataset上的平均精确度和召回率分别为95%和88% [36]。在此阶段结束时，我们从GitHub存储库中提取了905次纯重构及其关联的元数据（例如，类名、方法签名、文件路径和调用图）。 结合代码描述和调用者-被调用者关系进行上下文感知的RAG检索。仅使用源代码构建RAG数据库存在几个挑战。首先，具有相似结构的代码不一定具有相同的功能或逻辑，这两者都会影响重构策略。例如，在Move Method重构中，测试方法应仅移动到测试类，而不是生产代码。如果上下文中没有明确指出类类型，则仅依赖源代码结构进行检索可能导致错误匹配。其次，代码依赖关系在重构中起着重要作用，因为像Extract Method和Move Method这样的重构通常是由代码依赖关系驱动的[59]。如果不捕获这些依赖关系，检索到的示例可能无法与预期的重构过程对齐。

图1：MANTRA如何构建仅包含纯重构的RAG数据库的概述。

因此，在MANTRA中，我们结合了1）重构代码的自然语言描述和2）重构方法的所有直接调用者和被调用者作为代码特定的上下文，以增强RAG的检索能力。为了生成自然语言描述，我们遵循NLP社区的一项最新研究[7]。我们使用LLM为每次重构生成上下文描述，并将此描述与相应的代码连接起来构建上下文数据库。为了引导LLM生成这些描述，我们使用一个简单的提示：“(Code)(Caller/Callee)(Class Info) 请给出简短简洁的描述，以在改进代码搜索检索的背景下定位此代码。”，其中(Code)指重构前的代码，(Caller/Callee)表示直接调用者/被调用者，(Class Info)呈现包含待重构代码的类的结构信息，如包名、类名和类签名。提示中包括待重构方法的直接调用者和被调用者，以协助生成描述，因为依赖方法可能会影响重构决策。具体来说，提示中包含所有直接调用者和被调用者的方法签名和主体，使检索机制能够考虑这些依赖关系。 检索最相似的代码作为少量示例。在RAG的检索阶段，通常结合并融合两种主要检索方法以获得最佳结果[23]，即稀疏检索和密集检索。稀疏检索使用文本相似性高效检索相关文档，而密集检索依赖于语义相似性。MANTRA分别使用稀疏和密集检索生成两个相似性排序列表，然后将这两个列表合并成一个统一的排序列表。对于稀疏检索，MANTRA使用BM25 [48]，这是一种稳健的排名技术，基于文本相似性生成排序列表。对于密集检索，MANTRA使用all-MiniLM-L6-v2，这是一个来自Sentence Transformers [46]的预训练模型，以其速度和质量著称，用于嵌入生成。MANTRA然后计算输入重构请求和存储的重构示例嵌入之间的余弦相似性，以根据语义相似性生成另一个排序列表。最后，MANTRA使用互惠秩融合（RRF）算法[12, 49]组合排序列表并对结果进行重新排序。

3.2 多代理重构代码生成

MANTRA通过开发者代理、评审代理和修复代理之间的多代理协作来模拟现实世界中的代码重构过程。如图2所示，MANTRA采用混合代理架构[63]来组织两层代理通信。在第一层，开发者代理 负责生成和改进代码，而评审代理则审查代码并为开发者代理提供反馈或建议。如果重构代码无法编译或通过测试，生成的代码进入代理架构的第二层，修复代理尝试基于LLM推理和口头强化学习[50]修复任何编译或测试失败。 3.2.1 开发者代理。给定一个需要重构的方法和指定的重构类型，开发者代理首先根据观察（即重构类型和提供的输入）通过调用自定义静态分析自主提取必要的信息（例如，存储库结构、类信息）。然后，它使用我们的上下文RAG方法（第3.1节）检索类似的重构作为少量示例，以增强代码生成。最后，它使用提取的信息和检索到的示例生成重构代码。 Dev-Agent-1: 使用静态代码分析提取存储库和源代码结构。开发者代理可以访问我们的自定义静态分析工具，以分析存储库并提取代码和项目结构信息。代码结构信息包括类层次结构、继承关系、方法签名及其在类中的实现以及跨过程方法调用图。项目结构信息包括项目目录结构和具体的Java文件内容。其中，方法签名及其实现对于所有重构类型都是必需的，而其他信息仅对特定类型的重构是必要的。

为了减少静态分析开销和不必要的信息传递给LLM，开发者代理根据给定的重构类型和目标代码自主决定要执行哪些分析。例如，对于Move Method重构，开发者代理首先调用get_project_structure来检索整个项目结构。基于这些信息，它确定要检查的相关文件目录。然后，它调用get_file_content从目录中检索源代码文件，并评估该方法是否应移动到目标类/文件。开发者代理随后在下一阶段使用分析结果来指导重构过程并生成重构代码。 Dev-Agent-2: 通过RAG和思维链自动生成重构代码。基于前一步的静态分析结果，开发者代理1）使用RAG检索类似的重构作为少量示例，2）使用思维链推理生成重构代码[64]。开发者代理将要重构的代码、生成的代码描述和直接调用者/被调用者作为输入提供给RAG数据库，以检索

图2：MANTRA的概述。 类似的重构用于少量学习。然后，开发者代理遵循结构化的思维链推理方法，依次分析提供的信息。以下是简化后的提示示例，展示代码生成过程。 ###任务：基于指定重构类型的代码重构 ###指示：请遵循逐步分析： 步骤1：代码分析。分析需要重构的具体代码段。并输出要重构的代码的简要摘要。 步骤2：重构方法参考。从RAG系统中搜索并检索最多三个类似的重构示例。 步骤3：结构信息提取。基于重构类型和代码摘要，使用提供的工具收集所需的任何结构信息。这可能包括代码结构信息以及项目结构信息。 步骤4：重构执行。使用提取的结构信息和检索到的示例生成重构代码。 ### 输入：‘[要重构的代码，重构类型]’ ### 响应：‘[重构代码]’ 如示例所示，开发者代理分析方法源代码和其所在的整个类。然后，代理自主决定是否要进一步分析更广泛的上下文信息，包括直接调用者/被调用者、继承图和存储库结构。在收集源代码和其他结构信息后，代理生成一份针对给定重构类型的潜在重构机会列表，例如方法的哪些部分可以被提取（例如，对于提取方法）或可能将方法移动到的类（例如，对于移动方法）。最后，代理基于检索到的少量示例和潜在重构机会列表生成重构代码。最后，代理从列表中选择最有可能的重构机会，并基于检索到的少量示例生成重构代码。 3.2.2 评审代理。评审代理负责评估开发者代理生成的重构代码，确保其在两个关键方面正确：重构验证和代码风格一致性，以确保可读性。评审代理首先通过利用RefactoringMiner检测代码中的重构活动来验证代码是否经历了指定类型的重构。如果代码未能通过此检查，评审代理立即生成包含重构验证结果的反馈报告，并将其返回给开发者代理进行修正。如果重构验证成功，评审代理继续进行代码风格一致性分析，该分析使用静态分析工具CheckStyle [11]进行。如果检测到任何代码风格问题，例如不符合标准的变量命名或格式不一致，评审代理生成突出这些问题的反馈报告，并将其发送回开发者代理进行修正。一旦重构代码通过重构验证和代码风格一致性检查，评审代理将对其进行编译和测试。如果没有失败且所有测试都通过，生成过程完成，MANTRA返回最终的重构代码。如果有任何失败，生成的代码和错误日志将被转发到下一阶段。 3.2.3 开发者代理和评审代理之间的通信。在MANTRA中，开发者代理和评审代理在一个迭代过程中协同工作，模拟人类团队协作。生成重构代码后，开发者代理提交进行评审。评审代理随后验证重构和代码风格，提供结构化反馈。如果发现问题，开发者代理将细化并重新提交代码，重复此循环直到满足所有要求标准。

在验证重构活动和代码风格后，评审代理触发编译和测试阶段。代理将生成的重构代码集成到项目中，并根据项目的构建系统（Maven或Gradle）创建编译命令。然后执行命令以编译项目并运行测试。如果有任何编译问题或测试失败，问题将升级到修复代理进行修复。

3.3 使用口头强化学习进行自我修复

修复代理通过利用口头强化学习迭代修复无法编译和通过测试的重构代码，以增强其自我修复能力。为了整合和适应Reflexion框架[50]，我们对其进行了调整，该框架通过四个不同阶段系统地指导修复过程：初始分析、自我反思、规划和行动。Reflexion旨在通过结合迭代反馈使系统能够自我改进。

修复代理开始进行（1）初始分析，其中修复代理检查重构代码、代码所在的整个类以及相关的错误日志。然后，它基于有问题的代码段和相应的错误描述生成初始补丁。随后，代理应用补丁，重新编译代码并重新运行测试。如果存在问题，代理进入（2）自我反思阶段，批判性地自我审查编译和测试结果。代理通过比较应用补丁前后代码和相关错误消息生成错误推理。例如，如果之前的补丁未能解决空指针异常，代理通过明确引用堆栈跟踪中的相应行反映必要空检查的缺失或不足。

基于自我反思结果，修复代理进入（3）规划阶段，在此阶段生成精炼的修复策略，具体说明解决已识别问题所需的具体代码修改（例如，添加必要的空检查、修正变量声明或修订错误的方法调用）。最后，在（4）行动阶段，修复代理应用计划的补丁，随后进行编译和测试执行。这是一个迭代过程，直到代码成功编译并通过所有测试或达到预定的最大修复尝试次数（即20次）。为确保代码语义不变，在修复过程中，我们在提示中指定代理不应修改代码的功能，而只专注于修复。

4 评估

在本节中，我们首先介绍所研究的数据集和评估指标。然后，我们回答四个研究问题。

表1：用于评估MANTRA的Java项目。

项目	星数	提交数	纯重构数
checkstyle	8,462	14,606	91
pmd	4,988	29,117	125
commons-lang	2,776	8,404	59
hibernate-search	512	15,716	89
junit4	8,529	2,513	18
commons-io	1,020	5,455	93
javaparser	5,682	9,607	56
junit5	6,523	8,990	105
hibernate-orm	6,091	20,638	63
mockito	15,032	6,236	4
总计	59,615	121,282	703

研究数据集。表1显示了我们用来评估MANTRA的Java项目。我们选择了这10个Java项目，这些项目在以前的变更历史跟踪研究[21, 22, 28]中使用，基于三个关键考虑因素。首先，这些项目覆盖了多样化的应用领域，提供了广泛的软件开发实践代表。其次，每个项目都有大量的提交历史，超过2,000次提交，表明更丰富的开发历史和更高的识别涉及重构活动的提交的可能性。第三，我们选择了可以手动解决编译问题并成功执行测试以验证生成重构质量的项目。

我们将MANTRA生成的重构代码与人类开发者生成的重构代码进行评估和比较。为了减少与无关变更（如错误修复）相关的噪声，我们仅分析这些项目中的“纯重构变更”（即，除了重构之外没有其他代码变更）。与第3.1节类似，我们应用PurityChecker [36]仅选择包含纯重构的提交。由于我们需要通过运行测试来评估生成重构的功能正确性，我们编译每一个纯重构提交及其父提交（以确保重构前没有编译或测试失败），仅选择可以成功编译并通过测试的提交。

我们分析测试覆盖率以验证测试是否覆盖重构代码（即，它是否测试重构代码的功能行为）。我们使用Jacoco [26]执行测试用例以收集代码覆盖率信息，并过滤掉重构变更无覆盖率的提交。最后，我们验证了Move Method、Extract and Move Method和Move and Inline Method重构的目标类的存在。这一步是必要的，因为Move Method操作可能会将方法移动到新创建的类中，而MANTRA很难预测新创建的类。在应用上述所有数据选择步骤后，我们在10个Java项目中识别出703个纯重构。 评估指标。我们从两个维度评估重构代码：功能正确性和人类相似性。对于功能正确性，我们使用以下指标评估代码：1）编译成功，2）测试通过，3）RefactoringMiner验证（即，RefactoringMiner检测到确实发生了重构活动）。具体来说，我们将生成的重构代码集成到项目中。然后我们编译它并执行测试以验证构建是否成功。由于LLM的幻觉问题[24]，生成的代码可能通过测试用例但并未准确执行预期的重构。因此，我们使用RefactoringMiner [60]验证生成的代码是否包含目标重构。 即使我们给MANTRA输入一个目标方法，它仍需要找到可以重构的具体代码部分。因此，我们评估MANTRA生成代码的人类相似性，以比较其重构决策与开发者的决策。我们使用CodeBLEU度量[47]和抽象语法树（AST）差异精度和召回率[3]来测量差异。CodeBLEU评估人类编写重构代码与MANTRA生成代码之间的语法和语义一致性。AST差异表示一组映射，捕捉原始代码和重构代码之间的代码变化。每个映射由原始版本和重构版本之间差异中的匹配AST节点对组成。这些映射通过RefactoringMiner获得。为了评估结构相似性，我们将MANTRA生成的重构代码产生的映射与开发者编写代码产生的映射进行比较。MANTRA的映射与开发者编写映射相匹配的数量被视为真阳性（TP）。精确度计算为TP与MANTRA产生所有映射的比例，表示MANTRA映射的准确性。召回率是TP与所有开发者编写映射的比例，反映成功捕获开发者重构的程度。CodeBLEU和AST Precision/Recall的值范围从0到1，其中1表示完美匹配。 环境。我们选择OpenAI的ChatGPT模型[2]进行实验，因其流行性和通过OpenAI-API易于集成。具体而言，我们使用gpt-4o-mini-2024-07-18版本，因为它提供了性价比和性能的良好平衡。我们使用LangGraph [25]的0.2.22版本和各种静态分析工具实现MANTRA，这些工具使用RefactoringMiner API、修改版的RefactoringMiner和Eclipse JDT [14]的组合实现。平均而言，在Linux机器（Intel Core i9-9900K CPU @ 3.60GHz，64GB内存）上，一次完整的重构代码生成（从查询数据库、代码生成和测试执行到修复编译和测试失败）耗时不到一分钟，成本低于。

RQ1：MANTRA在重构代码方面的效果如何？

动机。在本RQ中，我们从功能正确性和人类相似性两个维度评估MANTRA生成的重构代码。我们还分析了MANTRA在不同类型重构中的表现。本RQ提供了关于MANTRA在执行重构任务方面的有效性和在哪些具体类型的重构任务中最有效的见解。 方法。我们使用从10个研究的Java项目中收集的703个纯重构提交来评估MANTRA。首先，我们对每个纯重构提交前的提交使用git checkout，以便我们可以提取重构操作前的原始代码。然后将代码存储库输入MANTRA以生成重构代码。为了比较，我们包括RawGPT作为基线（它使用与MANTRA相同的LLM）。RawGPT直接向LLM发送简单提示以执行代码重构。我们向RawGPT输入基本代码信息，即由MANTRA开发者代理的静态分析组件生成的相同信息（例如，类内容和项目结构）。RawGPT没有多代理组件，并且未提示 通过RAG检索到的少量示例。完整的提示可以在网上找到[6]。 结果。MANTRA成功生成了582/703（82.8%）的重构代码，这些代码可编译、通过所有测试并通过RefactoringMiner验证，而RawGPT只能成功生成61/703（8.7%）。如表2所示，MANTRA生成的重构代码显著多于RawGPT。在703次重构中，MANTRA生成的636次成功编译并通过测试用例，其中604次重构进一步通过RefactoringMiner验证为真正的重构操作。相比之下，RawGPT生成的只有100次重构可以编译并通过测试用例，但只有61次通过RefactoringMiner验证。请注意，可能存在一些通过RefactoringMiner验证但未通过编译/测试的生成重构代码，反之亦然，因此总成功重构数为582。

RawGPT在生成Move Method、Extract and Move Method和Move and Rename Method方面存在困难，无法生成任何重构。在进行这些重构时，RawGPT总是忽略提示中的项目结构信息，无法将方法移动到正确的类。相比之下，MANTRA拥有评审代理，该代理提供重构验证反馈以指导开发者代理执行Move操作。尽管如此，即使对于不需要仓库或类结构的重构（即Extract Method和Inline Method），MANTRA也实现了更高的成功率（317 vs. 47 和 22 vs. 8 分别）。 MANTRA在代码相似性方面优于RawGPT，生成的重构代码更接近人类。在所有成功的重构中，MANTRA的CodeBLEU得分为0.640，而RawGPT为0.517，展示了MANTRA生成的代码与人类编写的重构代码的高度一致性。在结构准确性方面，MANTRA的AST Diff精度为0.781，优于RawGPT的0.773，而其AST Diff召回率达到0.635，明显高于RawGPT的0.574。这些结果表明，MANTRA生成的代码更相似，并更好地与开发者编写重构的结构转换相一致。 MANTRA的结果更接近开发者的决策，其中MANTRA生成的重构代码中有10%（105/582）与开发者的重构完全相同，而RawGPT为13.1%（8/61）。我们进一步分析了与开发者实现相同的重构代码分布情况。MANTRA正确生成了84个Move Method重构，而RawGPT未能生成任何有效的重构。此外，MANTRA应用了11个Extract Method和8个Inline Method重构，与开发者的重构相同，而RawGPT仅分别完成了4个。MANTRA还生成了两个与开发者相同的复合重构（Extract and Move Method）。简而言之，MANTRA的结果更接近开发者的重构决策，这可能是由于其检索增强生成（RAG）组件，该组件提供了类似的过去重构作为少量示例。

表2：RawGPT和MANTRA的重构结果。表格展示了重构数量、编译和测试成功率、重构验证（RM验证）以及与人类编写重构的代码相似性度量（Code BLEU和AST Precision/Recall）。成功重构是指编译、通过测试并经RefactoringMiner验证的重构数量。我们计算Code BLEU和AST Precision/Recall的平均值，以及其他字段的总数。

表3：与开发者生成的重构代码完全相同的重构代码数量（可编译并通过所有测试用例）。

重构类型	RawGPT	MANTRA
提取方法		11
内联方法	4	8
移动方法	0	84
提取并移动方法	0	2
移动并重命名方法	0	0
移动并内联方法	0	0
总计	5	105

表4：EM-Assist和MANTRA-3.5-turbo成功提取方法重构的数量。

项目	提取方法	EM-Assist	MANTRA-3.5-turbo
checkstyle	34	14	34
pmd	55	24	48
commons-lang	54	18	41
hibernate-search	28	25	27
junit4	11	3	9
commons-io	68	33	49
javaparser	35	22	29
junit5	9	6	6
hibernate-orm	52	39	40
mockito	5	1	1
总计	359	185	277

MANTRA在功能正确性和人类相似性方面均优于RawGPT，成功生成了582/703（82.8%）可编译并通过测试的重构，而RawGPT仅为61/703（8.7%）。MANTRA还具有更高的CodeBLEU分数、AST Diff精度和召回率，其重构中有18%（105/582）与开发者的相同，而RawGPT为13.1%（8/61）。

RQ2：MANTRA与Intellij基于LLM的重构工具相比如何？

动机 我们将MANTRA生成的代码与IntelliJ基于LLM的重构工具生成的代码进行比较。IntelliJ IDEA [27] 提供了一个插件，称为EM-Assist [43, 44]，它使用LLM进行一种特定类型的重构，即Extract Method。EM-Assist利用上下文学习，在提示中提供所有必要的指令，包括任务定义和相关上下文信息。EM-Assist的输入是需要重构的方法，输出是一个建议列表，包括要提取的起始行和结束行以及新方法的名称。为了确保建议有效，EM-Assist使用IntelliJ的静态分析能力过滤掉会导致编译错误的建议。一旦确定了有效的建议，EM-Assist通过IntelliJ IDEA API根据抽象语法树（AST）应用重构。鉴于其相对于JDeodorant [32]和GEMS [67]等工具的卓越性能，我们选择了EM-Assist作为我们的比较基线。方法。我们使用最新版本的EM-Assist 0.7.5 [42] 进行Extract Method重构。此版本的EM-Assist使用gpt-3.5-turbo-0125进行重构。由于EM-Assist 0.7 .5已完全集成到IntelliJ IDEA中且没有接口更改LLM版本，我们也使用相同版本的GPT模型（即gpt-3.5-turbo-0125）运行MANTRA的所有Extract Method重构。结果。MANTRA（3.5-turbo）能够重构77.1%（277/359）的Extract Method重构，而EM-Assist只能重构51.5%（185/359），提供了几乎50%的改进。表4显示了EM-Assist和MANTRA的Extract Method重构结果。EM-Assist成功重构了359个方法中的185个。相比之下，MANTRA成功重构了277个方法。在这些重构中，有142个方法被两个工具成功重构。 这一发现表明，MANTRA也是EM-Assist的补充，因为它成功处理了显著不同的重构案例子集，并展示了结合两种技术的潜力。我们还看到，当将MANTRA的基础LLM从GPT-4o-mini更改为3.5-turbo时，成功重构的Extract Method数量从317（表2）减少到277（减少了12.6%）。这种性能下降显示了基础LLM的影响，但总体结果仍然很有希望。

MANTRA（3.5-turbo）在Extract Method重构方面显著优于EM-Assist，成功重构了277个方法，比EM-Assist的185个提高了50%。

RQ3：MUARF生成的重构代码与人类编写的代码相比如何？

动机。在之前的RQ中，我们展示了MANTRA可以成功生成许多重构。然而，重构代码是否易于理解并与人类编码实践一致也很重要。因此，在本RQ中，我们进行了一项用户研究，以比较MANTRA生成的和人类编写的重构代码。 方法。我们从研究的项目中随机选择12个重构，每种六种重构类型各选择两个。对于每个抽样重构，我们准备了1）重构前的代码，2）MANTRA生成的重构代码，以及3）开发者的重构代码。为了增加样本的丰富性并减少开发者的评估时间，我们将这12个样本分为两个单独的调查问卷[8, 9]，每个问卷涵盖六种重构类型的样本。对于每个样本，参与者比较两段代码（MANTRA生成的和开发者编写的）。我们遵循之前的研究[1, 4, 33, 55]，要求参与者评估代码的可读性和可重用性（从一到五评分，其中五表示高度可读或可重用），并选择他们认为更直观和结构良好的代码。对于可读性，我们询问参与者重构代码的可读性如何。对于可重用性，我们询问参与者重构代码的重用或扩展容易程度如何。为了避免偏见，我们在参与者完成调查之前不说明哪个是由人类编写或由LLM生成的。然后我们在揭示这些信息后征求他们的自由形式文本意见。结果。我们通过社交媒体分享了问卷，总共收集了37份针对两个问卷的回答（分别为20和17）。我们将两个问卷的结果结合起来，并在下面展示结果。总的来说，参与者的编程经验从1年（5.4%）到超过5年（54.1%）不等，超过45%的参与者将Java作为主要编程语言。 平均而言，参与者认为MANTRA生成的代码在可读性和可重用性方面与人类编写的代码相似。如图3所示，LLM生成的代码在可读性和可重用性方面的平均得分分别为4.15和4.13，而人类编写的代码得分为4.02和3.97。我们进一步应用了学生t检验，未发现统计学上的显著差异。这一发现表明，在考虑所有重构类型时，参与者认为MANTRA 生成的代码在可读性和可重用性方面与人类编写的代码相似。

然而，对于特定类型的重构（即提取和移动及移动和重命名），MANTRA生成的代码在可读性和可重用性方面大约提高了20%，并且比人类编写的代码更受欢迎，统计学上显著差异（p值<0.001）。相比之下，人类开发者在内联方法方面得分更高，平均高出8.5%的可读性和14.5%的可重用性，并且比MANTRA生成的重构代码更受青睐439%（统计学上显著，p值<0.05）。尽管人类开发者在移动和内联方法方面实现了略高的平均可读性和可重用性得分，但差异并不显著。

图4显示了一个例子，参与者更喜欢MANTRA生成的代码（可读性和可重用性得分分别为4.50和4.35，而人类重构代码分别为3.65和3.75）。MANTRA和人类开发者都通过提取相同的代码片段到相同的超类中进行了提取和移动重构。然而，它们在方法名、注释和参数类型上有所不同。一位参与者说：“[LLM生成的代码]显然更容易理解。从注释和名称中，我可以猜到代码的功能…[人类编写的代码]可能是一个非常通用的骨架代码。”

总的来说，我们根据参与者的评分和回应发现了一个趋势：MANTRA生成的代码通常包含详细的注释，并且更接近于其预期目的的重构。例如，MANTRA倾向于使用更具描述性的方法名称来提高清晰度。一位参与者提到：“[LLM生成的代码]更有条理和清晰，并且看起来更详细也更容易理解。” 相比之下，开发人员重构的代码在执行特定类型的重构时有时会提高代码的可读性，特别是在内联方法方面。例如，在问卷中的一段内联方法代码片段中，开发人员在重构过程中改进了代码，而MANTRA生成的重构代码只是直接移动了代码。一位参与者提到：“[LLM生成的代码]添加了两行代码而不是一行，使其在未来更难维护。” 研究表明，参与者普遍更喜欢MANTRA生成的代码，因其清晰和详细的注释。然而，在某些情况下，例如内联方法，人类开发人员通过额外改进超出直接重构，写出了更易读和更易维护的代码。

参与者发现，MANTRA生成的代码在可读性和可重用性方面与人类编写的代码相似。MANTRA在提取和移动以及移动和重命名方面表现更好，这是由于其清晰的注释和更好的命名。对于内联方法，人类开发人员通常通过额外改进写出更易读的代码。

RQ4：MANTRA中每个组件的贡献是什么？

动机。在本RQ中，我们进行了一项消融研究，以检查每个组件对MANTRA整体有效性的影响。结果将突出每个组件的重要性，

图3：左侧面板：箱线图描绘了问卷中MANTRA生成代码与人类编写代码的可读性和可重用性评分。白色标记表示每种重构类别的平均分。右侧面板：可视化参与者对其偏好的代码的偏好。

图4：一个示例说明了MANTRA和人类开发者如何实现提取和移动重构。

图5：MANTRA中每个组件的贡献。Compile&Test Success 显示生成的代码编译并通过所有测试的数量。Successful refactorings 表示包含特定重构的验证代码数量。 组件，激发未来针对相关任务调整它们的研究。 方法。我们的消融研究考察了三个关键组件：RAG、评审代理和修复代理。我们定义了三种可配置模型以评估关键组件在MANTRA中的影响：MANTRA RAG、MANTRA Reviewer 和 MANTRA Repair。每次配置移除相应的关键组件，使我们能够评估每个组件对MANTRA整体性能的贡献。 结果。移除一个组件会使成功重构的数量从582减少到222-345（40.7%-61.9%的减少）， 突显了它们对MANTRA能力的贡献。图5展示了每个组件的贡献。仅移除RAG组件就会使成功编译/测试的重构代码数量和成功重构数量分别减少到405和345（分别减少了36.3%和40.7%）。研究结果表明，高质量的RAG数据库对生成的重构代码有不可忽视的影响。同样，移除修复代理显著减少了成功编译/测试的重构代码数量，从636减少到376（减少了40.9%），因为修复代理负责修复编译问题和测试失败。移除修复代理还会使成功重构的数量从582减少到287（减少了50.7%），因为最终阶段的修复过程在最终化重构变更中起着至关重要的作用。在这三个组件中，移除评审代理对生成的重构代码通过编译/测试的数量（从636减少到359）和成功重构的数量（从582减少到222）的影响最大。评审代理利用传统工具在重构过程中提供反馈。我们的结果强调了如果没有来自外部工具（如RefactoringMiner）的反馈，MANTRA在生成有效重构代码时会遇到挑战。我们的研究结果还显示出将传统软件工程工具与LLM结合以产生更好结果的有前途方向。

MANTRA的每个组件在确保成功的重构中起着至关重要的作用，其中评审代理通过利用外部工具验证和优化重构代码具有最大的影响。研究结果还强调了将传统软件工程工具与基于LLM的方法相结合的重要性，因为它们提供的关键反馈改善了LLM的结果。

5 对有效性的威胁

内部有效性。由于LLM的生成性质，其响应可能会因不同运行和模型版本而有所不同。在我们的实验中，我们将温度值设置为0以减少结果的变异性。我们在实验中使用了OpenAI的LLM（即40-mini和3.5turbo）。未来的研究需要研究LLM对生成重构代码的影响。 外部有效性。我们专注于方法级重构，因为它们很流行[29, 35]。虽然我们包括了简单和复合重构，但结果可能无法推广到 其他类型的重构，例如类级别的重构。此类重构较少见，通常涉及其他代码变更（例如错误修复）[39]，使得数据收集困难。需要进一步研究以评估MANTRA在更广泛的重构场景中的有效性。我们专注于Java，因为它在重构相关研究方面有大量的文献。未来的工作应评估MANTRA在多种语言中的表现。 构建有效性。我们使用CodeBLEU和AST Precision/Recall来评估MANTRA生成代码与开发者编写重构之间的相似性。然而，尽管这些指标富有信息量，但仍可能遗漏代码中的一些差异。因此，我们进行了一项用户研究以比较MANTRA生成代码与开发者编写代码。虽然我们从37位具有不同经验水平的开发者那里收集了反馈，但一些发现可能是主观的。为了避免偏见，我们直到参与者完成问卷后才告诉他们哪段代码是由MANTRA重构或由人类开发者编写的。

6 结论

在本文中，我们介绍了MANTRA，这是一种端到端的基于LLM代理的解决方案，用于自动化方法级代码重构。通过利用上下文感知检索增强生成、多代理协作和口头强化学习，MANTRA生成类似人类的重构代码，同时确保正确性和可读性。我们对10个多样化的Java项目中的703个真实世界的重构进行评估，结果表明MANTRA在生成可编译并通过测试的代码方面显著优于基于LLM的重构基线，成功率达到82.8%，远远超越。它在IntelliJ的基于LLM的工具（EM-Assist）基础上还有50%的改进。此外，我们对37名开发者的用户研究表明，MANTRA重构的代码与人类编写的代码一样可读且可重用，某些特定重构类型的代码甚至更好。简而言之，我们的研究结果突显了基于LLM的重构工具在自动化软件维护方面的潜力。

参考文献

[1] Chaina Abid, Vahid Alizadeh, Marouane Kessentini, Thiago do Nascimento Ferreira, and Danny Dig. 软件重构研究30年：系统文献综述。arXiv预印本 arXiv:2007.02194, 2020. [2] Josh Achiam, Steven Adler, Sandhini Agarwal, Lama Ahmad, Ilge Akkaya, Florencia Leoni Aleman, Diogo Almeida, Janko Altenschmidt, Sam Altman, Shyamal Anadkat, et al. Gpt-4 技术报告。arXiv预印本 arXiv:2303.08774, 2023. [3] Pouria Alikhanifard 和 Nikolaos Tsantalis. 一种新的重构和语义感知抽象语法树差异工具及其基准，用于评估差异工具的准确性。ACM软件工程与方法学事务，sep 2024. ISSN 1049-331X. doi: 10.1145/3696002. URL https://doi.org/10.1145/ 3696002. 刚刚接受。 [4] Eman Abdullah AlOmar, Philip T Rodriguez, Jordan Bowman, Tianjia Wang, Benjamin Adopoju, Kevin Lopez, Christian Newman, Ali Ouni, and Mohamed Wiem Mkaouer. 开发者如何通过重构代码来提高代码可重用性？ 在新兴软件工程实践中的重用：第19届软件和系统重用国际会议，ICSE 2020，突尼斯哈马梅特，2020年12月2-4日，会议录19，第261-276页。Springer, 2020. [5] Eman Abdullah AlOmar, Anushkrishna Venkatarishnan, Mohamed Wiem Mkaouer, Christian Newman, and Ali Ouni. 如何重构这段代码？关于开发者与ChatGPT重构对话的探索性研究。在第21届采矿软件存储库国际会议论文集，第202-206页，2024. [6] 匿名. MUARF的数据和代码，2025. URL https://anonymous.4open.science/r/MUARF-B49B. 访问日期：2025年3月13日。 [7] Anthropic. 引入上下文检索，2024. URL https://www.anthropic.com/news/contextual-retrieval. 访问日期：2024年9月19日。 [8] 文章作者. 重构调查1，2024. URL https://prettyform.addxt.com/a/form/vf/1FAlpQLSdJf97mC3NVAPPvvgdtbvFNqW9XOp65wmexXNdbZ1WH. 访问日期：2024年6月23日。 [9] 文章作者. 重构调查2，2024. URL https:// http://prettyform.addxt.com/a/form/vf/1FAlpQLSsVTtqD2sUlosRQMWGKf_

5wH2CcJgBAu0TMWGtdv0QxvtHLQ. 访问日期：2024年6月23日。 [10] Gabriele Barota, Andrea De Lucia, 和 Rocco Oliveto. 使用结构和语义凝聚度度量识别提取类重构机会。J Syst. Softw, 84(3):397-414, 2011. doi: 10.1016/J.JSS.2010.11.918. URL https://doi. org/10.1016/j.jsx.2010.11.918. [11] Checkstyle团队. Checkstyle, 2024. URL https://checkstyle.org/index.html. 访问日期：2024年11月20日。 [12] Gordon V. Cormack, Charles L. A. Clarke, 和 Stefan Büttcher. 互惠秩融合优于孔多塞法和个体秩学习方法。在James Allan, Javed A. Aslam, Mark Sanderson, ChengXiang Zhai, 和 Justin Zobel 编辑的《第三十二届年度国际ACM SIGIR会议记录》，SIGIR 2009, Boston, MA, USA, July 19-23, 2009，第758-759页。ACM, 2009. doi: 10.1145/1571941.1572114. URL https://doi.org/10.1145/1571941.1572114. [13] Kayla DePalma, Isabel Miminoshvili, Chiara Henselder, Kate Moss, 和 Eman Abdullah AlOmar. 探索ChatGPT的代码重构能力：一项实证研究。专家系统与应用，249:123602, 2024. [14] Eclipse基金会. Eclipse JDT（Java开发工具），2024. URL https: //http://github.com/eclipse-jdt/. 访问日期：2025年3月13日。 [15] Stephen R Foster, William G Griswold, 和 Sorin Lerner. Witchdoctor：IDE支持实时自动完成重构。在2012年第34届国际软件工程会议(ICSE)上，第222-232页。IEEE, 2012. [16] Martin Fowler. 重构 - 改善现有代码的设计。Addison Wesley对象技术系列。Addison-Wesley, 1999. ISBN 978-0-201-48567-7. URL http://martinfowler.com/books/refactoring.html. [17] Yi Gao, Xing Hu, Xiaohu Yang, 和 Xin Xia. 基于上下文增强的FIM框架用于自动测试重构。arXiv预印本 arXiv:2409.16739, 2024. [18] Yunfan Gao, Yun Xiong, Xinyu Gao, Kangxiang Jia, Jinliu Pan, Yuxi Bi, Yi Dai, Jiawei Sun, Qianyu Guo, Meng Wang, 和 Haofen Wang. 大型语言模型的检索增强生成：综述。CoRR, abs/2312.10997, 2023. doi: 10.48550/ARXIV.2312.10997. URL https://doi.org/10.48550/arXiv.2312.10997. [19] Xi Ge, Quinton L DuBose, 和 Emerson Murphy-Hill. 手动和自动重构的协调。在2012年第34届国际软件工程会议(ICSE)上，第211-221页。IEEE, 2012. [20] Yaroslav Golubev, Zarina Kurbatova, Eman Abdullah AlOmar, Timoloy Bryksin, 和 Mohamed Wiem Mkaouer. 一千零一个故事：大规模软件重构调查，2021. URL https://arxiv.org/abs/2107.07357. [21] Felix Grund, Shailul Alam Chowdhury, Nick C. Bradley, Braxton Hall, 和 Reid Holmes. CodeShovel：构建方法级源代码历史。在第43届IEEE/ACM国际软件工程会议，ICSE 2021, Madrid, Spain, 2021年5月22-30日，第1510-1522页。IEEE, 2021. doi: 10.1109/ICSE43902.2021. 00135. URL https://doi.org/10.1109/ICSE43902.2021.00135. [22] Mohammed Tayeeb Hasan, Nikolaos Tsantalis, 和 Pouria Alikhanifard. 提交历史中考虑重构的块跟踪。IEEE软件工程汇刊，50(12):3330-3350, 2024. doi: 10.1109/TSE.2024.3484586. [23] Pengfei He, Shaowei Wang, Shailul Chowdhury, 和 Tse-Hsun Chen. 在RAG中探索演示检索器在编码任务中的应用：是与否？ CoRR, abs/2410.09662, 2024. doi: 10.48550/ARXIV.2410.09662. URL https://doi.org/10. 48550/arXiv.2410.09662. [24] Lei Huang, Weijiang Yu, Weitao Ma, Weihong Zhong, Zhangyin Feng, Haotian Wang, Qianglong Chen, Weihua Peng, Xiaocheng Feng, Bing Qin, 和 Ting Liu. 关于大型语言模型幻觉现象的综述：原则、分类、挑战和开放问题。CoRR, abs/2311.05232, 2023. doi: 10.48550/ARXIV. 2311.05232. URL https://doi.org/10.48550/arXiv.2311.05232. [25] LangChain公司. Langgraph, 2024. URL https://langchain-ai.github.io/langgraph/. 访问日期：2024年12月2日。 [26] Jacoco. Jacoco, 2009. URL https://www.jacoco.org/jacoco/trunk/index.html. 访问日期：2009年6月1日。 [27] JetBrains. IntelliJ IDEA, 2024. URL https://www.jetbrains.com/idea/. 访问日期：2024年6月10日。 [28] Mehran Jodavi 和 Nikolaos Tsantalis. 准确的方法和变量跟踪在提交历史中。在第30届ACM联合欧洲软件工程会议和软件工程基础研讨会论文集，ESEC/FSE 2022, 第183-195页，纽约，NY，美国，2022年。计算机协会。ISBN 9781450394130。doi: 10.1145/3540250.3549079。URL https://doi.org/10.1145/3540250.3549079。 [29] Miryung Kim, Thomas Zimmermann, 和 Nachiappan Nagappan. 微软重构挑战与收益的经验研究。IEEE软件工程汇刊，40(7):633-649, 2014. [30] Feng Lin, Dong Jae Kim, Tse-Hsun, 和 Chen. Soen-101: 使用大型语言模型代理模拟软件过程模型进行代码生成，2024. URL https://arxiv.org/abs/2403.15852. [31] Bo Liu, Yanjie Jiang, Yuxia Zhang, Nan Niu, Guangjie Li, 和 Hui Liu. 自动化软件重构中大型语言模型潜力的实证研究。arXiv预印本 arXiv:2411.04444, 2024. [32] Davood Mazinanian, Nikolaos Tsantalis, Raphael Stein, 和 Zackary Valenta. Jdeodorant: 克隆重构。在Laura K. Dillon, Willem Visser, 和 Laurie A. Williams编辑的《第38届国际软件工程会议论文集》，ICSE 2016, Austin, TX, USA, May 14-22, 2016 - Companion Volume, 第613-616页。ACM, 2016. doi: 10.1145/2889160.2889168. URL https://doi.org/ 10.1145/2889160.2889168. [33] Raimund Moser, Alberto Sillitti, Pekka Abrahamsson, 和 Giancarlo Succi. 重构能否提高可重用性？ 在国际软件重用会议上，第287-297页。Springer, 2006. [34] Emerson Murphy-Hill, Chris Parnin, 和 Andrew P Black. 我们如何重构，以及我们如何知道这一点。IEEE软件工程汇刊，38(1):5-18, 2011. [35] Atas Negara, Nicholas Chen, Mohsen Vakilian, Ralph E. Johnson, 和 Danny Dig. 手动和自动化重构的比较研究。在第27届面向对象程序设计欧洲会议，ECOOP’13, 第552576页，柏林，海德堡，2013年。Springer-Verlag. ISBN 978-3-642-39037-1. doi: 10.1007/978-3-642-39038-8_23.

[36] Pedram Nouri. ParityChecker: 一种用于检测方法级重构操作奇偶性的工具。博士论文，康考迪亚大学，2023年。URL https://spectrum.library.concordia.ca/id/epirit/993129/.

[37] Mark Kent O’Keeffe 和 Mel Ó Cinnside. 基于搜索的重构用于软件维护。J. Syst. Softw., 81(4):502-516, 2008. doi: 10.1016/J.JSS.2007.06.003. URL https://doi.org/10.1016/j.jss.2007.06.003.

[38] Javgenija Pantinchina, Bin Lin, Fiorella Zampetti, Massimilano Di Penta, Michele Lanza, 和 Gabriele Bavota. 为什么开发者在开源项目中拒绝重构？ACM Trans. Softw. Eng. Methodol., 31(2), 2021年12月。ISSN 1049513,3. doi: 10.1145/3487062. URL https://doi.org/10.1145/3487062.

[39] Massimiliano Di Penta, Gabriele Bavota, 和 Fiorella Zampetti. 关于重构动作与漏洞之间关系的研究：差异化的复制研究，2020年。URL https://arxiv.org/abs/2009.11685.

[40] Anthony Peruma, Steven Simmons, Eman Abdullah AlOmar, Christian D. Newman, Mohamed Wiem Mkaouer, 和 Ali Ouni. 我该如何重构这段代码？关于Stack Overflow上重构趋势和主题的实证研究。Empirical Software Engineering, 27(1)，2021年10月。ISSN 1573-7616. doi: 10.1007/s10664-021-10045-x. URL http://dx.doi.org/10.1007/s10664-021-10045-x.

[41] Russell S. Poldrack, Thomas Lu, 和 Gaïper Begait. AI辅助编码：GPT-4实验。arXiv预印本 arXiv:2304.13187, 2023.

[42] Dorin Pomian. 基于LLM的提取方法，2024年。URL https://plugins.jvtheains.com/plugins/23403-llm-powered-extract-method. 访问日期：2024年6月23日。

[43] Dorin Pomian, Abhiram Bellur, Malinda Dilhara, Zarina Kurbatova, Egor Bogomolov, Timofey Bryksin, 和 Danny Dig. 下一代重构：结合LLM见解和IDE功能进行提取方法。在IEEE国际软件维护与演化会议，ICSAIE 2024, Flagstaff, AZ, USA, October 6-11, 2024, 第275-287页。IEEE, 2024. doi: 10.1109/ICSAIE58944. 2024.00034. URL https://doi.org/10.1109/ICSAIE58944.2024.00034.

[44] Dorin Pomian, Abhiram Bellur, Malinda Dilhara, Zarina Kurbatova, Egor Bogomolov, Andrey Sokolov, Timofey Bryksin, 和 Danny Dig. Ext-Assist: 使用LLM的安全自动化提取方法重构。在Marcelo d’Amorim编辑的《第32届ACM国际软件工程基础会议随刊》，FSE 2024, Porto de Galinhas, Brazil, July 15-19, 2024, 第582-586页。ACM, 2024. doi: 10.1145/3663529.3663803. URL https://doi.org/10.1145/3663529.3663803.

[45] Soumaya Rebal, Marouane Kessentini, Vahid Alizadeh, Oussama Ben Sghaier, 和 Rick Kazman. 通过提交消息分析推荐重构。Inf. Softw. Technol., 126:106332, 2020. doi: 10.1016/J.INFSOF.2020.106332. URL https://doi.org/10.1016/j.infsof.2020.106332.

[46] Nils Reimers 和 Iryna Gurevych. Sentence-BERT: 使用孪生BERT网络生成句子嵌入。在《2019年经验方法自然语言处理会议记录》。计算语言学协会，2019年11月。URL https://arxiv.org/abs/1908.10084.

[47] Shuo Ren, Daya Guo, Shuai Lu, Long Zhou, Shujie Liu, Duyu Tang, Noel Sundaresan, Ming Zhou, Ambrosio Blanco, 和 Shuai Ma. CodeBLEU: 一种自动评估代码合成的方法。arXiv预印本 arXiv:2009.10297, 2020.

[48] Stephen Robertson, Hugo Zaragoza 等人. 概率相关性框架：BM25及更多。信息检索基础和发展趋势，3(4):333-389, 2009.

[49] Keshav Santhanam, Omar Khattab, Jon Saad-Falcon, Christopher Potts, 和 Matei Zaharia. Colbertv2: 轻量级后期交互实现有效且高效的检索。在Marine Carpuat, Marie-Catherine de Marneffe, 和 Ivan Vladimir Meza Ruiz 编辑的《2022年北美计算语言学协会年会记录：人类语言技术》，NAACL 2022, Seattle, WA, United States, July 10-15, 2022, 第3715-3734页。计算语言学协会，2022年。doi: 10.18633/V1/2022.NAACL-MAIN.272. URL https://doi.org/10.18633/v1/2022.naucl-main.272.

[50] Noah Shinn, Federico Cassano, Ashwin Gopinath, Karthik Narasimhan, 和 Shunyu Yao. Reflexion: 使用口头强化学习的语言代理。在Alice Oh, Tristan Naumann, Amir Globerson, Kate Saenko,

Moritz Hardt, 和 Sergey Levine 编辑，《神经信息处理系统进展36年度会议记录》，NeurIPS 2023, 新奥尔良，LA，美国，2023年12月10日至16日，2023年。URL http://papers.nipcs.cc/paper_files/paper/2023/hash/ 104488788678266954cdf000628510e90-摘要-会议.html.

[51] Atsushi Shirafuji, Yusuke Oda, Jun Suzuki, Makoto Morishita, 和 Yutaka Watanabe. 使用大型语言模型和少量示例进行程序重构。在2023年第30届亚太软件工程会议（APSEC），第151-160页。IEEE, 2023.

[52] Danilo Silva, Ricardo Terra, 和 Marco Tulio Valente. 推荐自动提取方法重构。在第22届国际程序理解会议论文集，第146-156页，2014年.

[53] Danilo Silva, Nikolaus Tsantalis, 和 Marco Tulio Valente. 为什么我们重构？GitHub贡献者的忏悔。在Thomas Zimmermann, Jane Cleland-Huang, 和 Zhendong Su 编辑的《第24届ACM SIGSOFT国际软件工程基础研讨会论文集》，FSE 2016, Seattle, WA, USA, November 13-18, 2016, 第858-870页。ACM, 2016. doi: 10.1109/TSE.2020.2968072.

[54] Danilo Silva, João Paulo da Silva, Gustavo Santos, Ricardo Terra, 和 Marco Tulio Valente. RefDiff 2.0: 多语言重构检测工具。IEEE Transactions on Software Engineering, 47(12):2786-2802, 2021. doi: 10.1109/TSE.2020.2968072.

[55] Yahya Tashrioush, Zeinah Odat, Izzat M Ahmadi, 和 Maryan Tatim. 编程特性对代码可读性的影响。2013年.

[56] Tom Tourwe 和 Tom Mens. 使用逻辑元编程识别重构机会。在第七届欧洲软件维护与重构大会（CSMR 2003），2003年3月26-28日，意大利贝内文托，会议录，第91-100页。IEEE计算机学会，2003年。doi: 10.1109/CSMR.2003.1192416. URL https://doi.org/10.1109/CSMR.2003.1192416.

[57] Nikolaus Tsantalis 和 Alexander Chatzigeorgiou. 移动方法重构机会的识别。IEEE Trans. Software Eng., 35(3):347-367, 2009年。doi: 10.1109/TSE.2009.1. URL https://doi.org/10.1109/TSE.2009.1.

[58] Nikolaus Tsantalis 和 Alexander Chatzigeorgiou. 方法分解的提取方法重构机会识别。J. Syst. Softw., 84(10):1757-1782, 2011年。doi: 10.1016/J.JSS.2011.05.016. URL https://doi.org/10.1016/j.jss.2011.05.016.

[59] Nikolaus Tsantalis, Victor Guana, Eleni Stroulia, 和 Abram Hindle. 关于重构活动的多维实证研究。在James R. Cordy, Krzysztof Czarnecki, 和 Sang-Ah Han 编辑的《协作研究中心会议记录》，CAXCON’13, 加拿大多伦多，2013年11月18-20日，第132-146页。IBM / ACM, 2013年。URL http://dl.acm.org/citation.cfm?id=2555539.

[60] Nikolaus Tsantalis, Matin Mamouri, Laleh M Eshkevari, Darood Mazinanian, 和 Danny Dig. 在提交历史中准确高效地检测重构。在第40届国际软件工程会议记录中，第483-494页，2018年。

[61] Nikolaus Tsantalis, Ameya Ketkar, 和 Danny Dig. RefactoringMiner 2.0. IEEE Transactions on Software Engineering, 48(3):930-950, 2020.

[62] Nalin Wadhwa, Jui Pradhan, Athare Somwane, Surya Prakash Sahu, Nagarajan Natarajan, Aditya Kanade, Suresh Parthasarathy, 和 Sriram K. Rajamani. CORE: 使用LLMs解决代码质量问题。Proc. ACM Softw. Eng., 1(PSE):789-811, 2024. doi: 10.1145/3643762. URL https://doi.org/10.1145/3643762.

[63] Junlin Wang, Jue Wang, Ben Athiwaratkun, Ce Zhang, 和 James Zou. 混合代理增强大型语言模型能力。CoRR, abs/2406.04692, 2024. doi: 10.48550/ARXIV.2406.04692. URL https://doi.org/10.48550/arXiv.2406.04692.

[64] Jason Wei, Xucchi Wang, Dale Schuurmans, Maarten Bosma, Brian Ichter, Fei Xia, Ed Chi, Quoc Le, 和 Denny Zhou. 链式思维提示激发大型语言模型中的推理，2023年。URL https://arxiv.org/abs/2201.11903.

[65] Jules White, Sam Hays, Quchen Pa, Jesse Spencer-Smith, 和 Douglas C Schmidt. Chattgyt提示模式以改进代码质量：重构、需求获取和软件设计。在《生成AI促进有效软件开发》一书中，第71-108页。Springer, 2024.

[66] Di Wu, Fangwen Mu, Lin Shi, Zhaoqiang Guo, Kui Liu, Weiguang Zhuang, Yuqi Zhong, 和 Li Zhang. iSMELL: 将LLM与专家工具集结合用于代码气味检测和重构。在Vladimir Filkov, Shahakhi Ray, 和 Minghui Zhou 编辑的《2024年IEEE/ACM自动化软件工程国际会议论文集》，ASE 2024, Sacramento, CA, USA, October 27 - November 1, 2024, 第1345-1357页。ACM, 2024. doi: 10.1145/3691620.3695508. URL https://doi.org/10.1145/3691620.3695508.

[67] Sihan Xu, Aishwarya Sivaraman, Siao-Cheng Khoo, 和 Jing Xu. GEMS: 提取方法重构推荐器。在2017年IEEE第28届软件可靠性工程国际研讨会议录（ISSRE），第24-34页，2017年.

[68] Tong Ye, Weigang Huang, Xuhong Zhang, Tengfei Ma, Peiyu Liu, Jianwei Yin, 和 Wenhai Wang. LLnseff: 利用大型语言模型提高代码效率和正确性，2025年。URL https://arxiv.org/abs/2502.18489.

[69] Zejun Zhang, Zhenchang Xing, Xiaoxue Ren, Qinghua Lu, 和 Xiewi Xu. 重构为Pythonic惯用法：一种混合知识驱动的方法，利用大型语言模型。ACM软件工程论文集，1(PSE):

参考：https://arxiv.org/pdf/2503.1434