介绍
(1) 发表：ISSTA'24
(2) 背景
软件工程涉及程序改进的过程，特别是软件维护（例如，程序错误修复）和软件演变（例如，功能添加）
自动化程序维修任务对实现自动软件工程愿景的重要性。鉴于自动化程序维修的动机，并且开发人员经常花费大量的时间来修复错误。本工作提出了 AutoCodeRover，实现了 SWE-bench-lite 上的 SOTA，并且提升了 19% 的效率
方法
(1) 上下文检索 API
我们观察到用户经常提及代码库中哪一部分相关的一些 "Hints"。这些提示可以是相关方法，类或文件的名称，有时还包含简短的代码段
在上下文检索阶段，基本组件是一组 API。本工作为 LLM Agents 设计了一组 API 以从这些 Hints 中找到相应的代码上下文
(2) 分层上下文搜索
提出了两个观察结果：① 上下文检索不应仅限于单个 API 调用 ② 某些 API 调用结果提供了更多的元素来构建新的 API 调用
搜索规则如下：
-
在每一层中允许 LLM 选择多个 API 调用，并指示它仅选择必要的调用，从而构建我们认为的最佳上下文
-
执行层中的 API 调用后，将新检索的代码片段添加到当前上下文中。然后提示 LLM 代理分析当前上下文是否足以理解问题，从而决定是否继续迭代搜索过程
(3) 分析增强的上下文检索
在这一步中研究了程序调试技术如何增强工作流程，具体而言将 SBFL 分析集成进来，以研究基于测试的动态分析的效果。SBFL 的主要作用是在问题陈述中提到的相关类别和方法上揭示更多的 "hints"，由于SBFL识别的方法与问题陈述一起呈现给 Agent，因此 Agent 可以在这两个信息来源之间进行交叉引用。例如，如果SBFL识别的方法名称之一与问题语句更加紧密相关，则 LLM 更有可能在此名称上调用 search_method API。
- 基于频谱的故障定位 (SBFL)：SBFL 的目的是确定软件故障的位置。给定测试套件t包含通过测试和失败测试，SBFL考虑了通过和失败的测试执行中的控制流差异，并将可疑性得分分配给不同的程序位置。具有最高可疑性分数的语句或者块被确定为可能性位置。由于LLM可以处理合理的长代码段，因此我们在AutoCoderover中使用方法级 SBFL
(4) 补丁生成
利用收集到的代码上下文来生成补丁，如果补丁无法通过测试套件，则进行重试循环 (在这一阶段还使用 linter 来检测 python 的语法特性问题)
实验结果
实现了 SWE-bench-lite 上的 SOTA，同时提升了效率和降低了成本
总结
更多的从软件视角提出了一个 LLM Agents 的框架，尽可能的利用代码上下文信息，理所当然的取得了很好的效果