"Demystifying LLM-Based Software Engineering Agents" 论文笔记

介绍

(1) 发表：FSE'25

(2) 挑战

现有工作都在探索基于 Agent 的方式来解决软件问题，但人与当前 LLM 能力之间的差异会导致基于 Agent 的方法的以下局限性：

• 复杂的工具使用/设计：当前基于 Agent 的方法在 Agent 和环境之间采用抽象层，将真实操作映射到 API 调用中，以便 Agent 可以通过输出 API 调用指令来使用工具。但是，此类抽象和 API 调用规范需要仔细设计输入/输出格式，并且很容易导致不正确或不精确的工具设计/用法，尤其是对于更复杂的动作空间。考虑到基于 Agent 的方法的迭代性质，当前的动作/计划取决于上一轮，错误或不准确的定义/使用工具会降低性能，并且浪费 LLM 查询，产生额外的成本

• 决策计划缺乏控制：由于可能的动作反馈响应空间很大，因此 Agents 很容易变得困惑并进行亚最佳探索。此外为了解决问题，Agents 能需要超过 30 或 40 次以上的轮次，这使得理解 Agents 做出的决定以及调试错误的轮次会变得难以理解

• 自我反思能力有限：现有工作倾向于获取所有信息/反馈，并且不知道如何过滤或纠正无关紧要、错误或误导信息。Agents 自我反思的有限能力意味着不正确的步骤可以很容易地放大，并对代理商做出的所有未来决策产生负面影响

(3) 贡献

本工作提出了 Agentless，旨在以无代理的方式来解决这些问题，在 SWE-bench-lite 实现了低成本和 SOTA

方法

(1) 问题定位

该工作采用了简单的三步分层定位方法：

• 定位到可疑文件：

  ① 本工作没有为每个文件提供完整的代码段，而是使用与 Linux 树命令类似的存储库文件和目录结构的简明表示。将处理后的存储库结构以及原始问题说明输入到 LLM，并要求其确定需要进一步检查或修改的 Top-k 个可疑文件列表

  ② 此外本工作还使用一种简单的基于嵌入的检索方法来识别其他可疑文件作为补充。(无需嵌入所有文件，首先会要求 LLM 根据问题描述输出无关文件夹列表以排除) 接着将每个剩余的文件分成一块块的代码段，并使用嵌入式模型计算每个块的嵌入。然后嵌入原始问题描述（即查询），并计算产生的查询嵌入与每个代码块嵌入之间的余弦相似性，以检索包含与查询最高相似性的代码段的相关文件列表

  最后本工作结合两种定位结果，选择其中的最常见文件，得到可以文件的最终列表

• 定位到相关元素：所有文件的上下文都可能很大。因此本工作构建了每个文件的压缩格式，其中包含类、函数或可变声明列表。我们将此格式称为骨架格式。接着一次将所有可疑文件的骨架提供给 LLM，以单个提示提供给 LLM，从而使模型能够全面分析相关信息并确定最相关的元素

  

• 定位到编辑位置：直接根据相关元素获取代码片段，然后提供给 LLM 要求其定位特定的编辑位置。要求 LLM 确定按行号、功能或类指定的最终编辑位置集

(2) 修复

根据现有工作，本工作构建上下文窗口给 LLM 进行修复 (例如，如果确定的位置是从 40 行到 78 行的类，我们将产生 [40- x，78 + x] 的上下文窗口，其中 x 表示上下文窗口大小)。要求LLM生成搜索/替换编辑这种格式来创建补丁，这种简单的差异格式避免生成完整的代码，而是专注于生成小型编辑，这样不仅更具成本效益而且更可靠和准确。最后对于每个问题使用LLM生成多个潜在的补丁

(3) 补丁验证

• 复现测试生成：在现实场景中，原始项目代码库只能提供回归测试（修改前就通过的测试），而不能提供任何复现测试（即错误触发测试）。因此为了生成复现测试，本工作提供了原始问题描述和一个示例复现测试给 LLM。与修复类似，我们也抽样了多个候选复现测试，然后在原始存储库上执行每个测试，过滤掉错误信息不一致的测试。最后，我们对每个测试进行规范化然后选择出现次数最多的测试作为每个问题的最终复现测试

• 补丁选择：本工作首先运行代码库中现有的测试，然后获得一组成功通过的测试。然后通过测试的列表提供给 LLM，并要求其识别出 "在问题修复期间可以更新/修补的测试"。移除 LLM 识别出的非回归测试后，得到了最终的回归测试集。然后，我们对所有生成的补丁运行这组回归测试，保留回归失败次数最少的补丁。对于这些补丁，随后运行选定的复现测试，并仅保留解决问题的补丁（由于复现测试由 LLM 生成不稳定，如果没有补丁通过复现测试，则回退到回归测试）。最后选择出现次数最多的补丁作为最终提交的补丁

实验

总而言之在低成本的基础上实现了 SWE-bench-lite 上的 SOTA

总结

这篇工作的主要思想是解决基于代理的方法的局限性，通过基于程序的方式实现了很好的效果