基本信息

论文题目：RepairAgent: An Autonomous, LLM-Based Agent for Program Repair
链接：ICSE 2025

解决问题

现有的多数程序自动修复方法多基于大语言模型，且仅仅依托于单次交互或者硬编码。RepairAgent将LLM视为和人类工程师一样的能够计划、执行操作的自主智能体，该框架内部集成了一组用于修复的工具，模型可以调用它们与代码库交互，跳脱于硬编码之外，而是通过智能体收集的信息以及反馈自主决定下一步调用什么工具。
主要贡献如下：

提出一个自主的llm程序修复智能体；
一个动态更新的提示格式，指导LLM的错误修复；
一组工具，方便LLM调用；

RepairAgent

由三个组件构成，LLM代理（左）、修复工具（右）和协调两者通信的中间件（中）。修复错误时，中间件将用一个提示初始化LLM代理，该提示包含任务信息和关于如何使用所提供的工具执行任务的说明（箭头1）。LLM通过建议调用一个可用的工具（箭头2）来响应，中间件解析并执行该工具（箭头3）。然后将工具的输出（箭头4）集成到下一次调用LLM的提示符中，并且迭代地继续该过程，直到修复错误或耗尽预定义的预算。

动态提示词更新

提示词组成：

角色：提示符的这一部分定义了代理的专业领域，即解决Java代码中的错误，并概述了代理的主要目标：理解和修复错误。提示强调代理的决策过程是自主的，不应该依赖于用户的帮助。
目标：定义五个静态目标：定位bug（执行测试并使用故障定位技术来确定bug的位置。如果提示中已经提供了故障定位信息，则跳过此目标。）->收集bug相关信息（分析与bug相关的代码行以了解bug）->建议对bug进行简单修复->提出复杂方案（如果简单的解决方案无效，探索并提出更复杂的解决方案）->迭代，直到修复目标。
指导：首先，通知LLM存在单行或多行错误需要通过更改删除或添加行来修复，作者整理了一个可以通过简单迭代的模式即可修复的漏洞表格，每种模式都有简短描述和修复示例；第二，指示大模型在修复后的代码中加入注释；第三，知识模型明确下一步操作（调用工具）；最后，指定有限的工具调用次数（预算），强调效率。
状态描述：为了指导LLM代理以有效有意义的方式使用可用工具，定义一个有限状态机，这个状态机限制给定时间点可用的工具。而没有这个状态机指导，LLM经常迷失在无目的的探索中。上图描述这个状态机，模拟开发人员修复bug时经历的状态，其中每个阶段都对应一组修复工具。
理解bug：收集与失败测试用例和错误相关的位置信息，理解bug后指定一个假设描述bug的性质与成因。
收集信息修复bug：帮助建议修复由假设表示的错误，例如通过搜索特定成分或阅读可能相关的代码。
尝试修复bug：根据当前的假设和收集信息修复错误，每次尝试都会修改代码库并通过执行测试用例进行验证。
可用工具：
聚合信息：收集有关bug和代码库的信息，这些信息是决定下一步调用哪些命令的基础。为了使代理可以使用此信息，我们维护了一个提示部分，其中列出了由不同工具调用收集的信息。

中间件：

解析和精炼LLM输出：在每个周期开始时，中间件使用当前提示符查询LLM。实践中LLM可能产生偏离预期格式的回答。RepairAgent通过三个步骤将输出映射到期望的方向上，首先，检查响应中调用工具是否可用；其次，检查参数是否可用，检查原则为字串匹配，若匹配失败，进一步检查编辑距离是否高于阈值；最后该方法通过启发式地映射或替换它们来处理无效的参数值。
除了纠正响应中的小错误外，中间件还检查是否使用相同的参数重复调用相同的工具。调用工具：给定来自LLM的有效命令，中间件调用相应的工具。为了防止工具执行干扰主机环境或RepairAgent本身，中间件在隔离的环境中执行命令。更新提示：给定工具的输出，中间件将为下一个周期更新提示的所有动态部分。特别是，它更新状态描述和可用的工具，将工具的输出附加到收集的信息中，并替换显示最后执行命令的部分。