论文翻译：AGENTLESS：揭开基于LLM的软件工程代理的神秘面纱

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

论文标题

AGENTLESS：揭开基于LLM的软件工程代理的神秘面纱

作者
Chunqiu Steven Xia, Yinlin Deng, Soren Dunn, Lingming Zhang

机构
伊利诺伊大学厄巴纳-香槟分校

摘要
近年来，大型语言模型（LLM）的显著进步推动了软件开发任务的自动化，包括代码合成、程序修复和测试生成。最近，研究人员和行业从业者开发了各种自主的LLM代理，以执行端到端的软件开发任务。这些代理具备使用工具、运行命令、从环境中获取反馈并计划未来行动的能力。然而，这些基于代理的方法的复杂性，加上当前LLM能力的有限性，提出了一个问题：我们真的需要采用复杂的自主软件代理吗？

为了解答这个问题，我们构建了AGENTLESS——一种无需代理的方法来自动解决软件开发问题。与基于代理的方法相比，AGENTLESS采用简化的两步流程：本地化和修复，不允许LLM决定未来行动或操作复杂工具。我们在流行的SWE-bench Lite基准测试上的结果表明，AGENTLESS能够在所有现有开源软件代理中达到最高的性能（27.33%）和最低的成本（0.34美元）。此外，我们还对SWE-bench Lite中的问题进行了细粒度分析，发现其问题存在精确补丁描述或信息不足的问题。我们构建了SWE-bench Lite-S，通过排除这些问题来进行更严格的评估和比较。我们的工作突出了一种简单、可解释的技术在自主软件开发中的潜在价值。我们希望AGENTLESS能够帮助重置基准、起点和自主软件代理的未来方向，并激励在这一重要方向上的更多工作。我们已将AGENTLESS开源：https://github.com/OpenAutoCoder/Agentless

介绍

大型语言模型（LLM）已成为代码生成任务的首选工具（如GPT-4和Claude-3.5），展示了其根据用户描述合成代码片段的能力。然而，与单一、独立问题的主要评估设置相比，应用LLM解决代码库级别的软件工程任务仍未得到充分研究。软件工程任务如特性添加、程序修复和测试生成需要不仅理解文件内的信息，还要理解文件之间的依赖关系。

为了弥补这一差距并评估工具自动解决现实世界软件工程问题的能力，开发了流行的SWE-bench基准测试。每个问题包含一个现实世界的GitHub问题描述及对应的Python代码库。任务是修改代码库以解决问题，既可以修复错误，也可以引入新特性。最近，作者发布了SWE-bench Lite基准测试，包含300个问题，进一步过滤并专注于错误修复问题。

为了解决SWE-bench中现实世界的软件开发问题，受Devin AI软件工程师的启发，从学术界和工业界都有大量关于开发基于代理的方法的研究。尽管没有固定的定义，这些方法通常为LLM配备一套工具，允许代理自动执行各种操作、观察反馈并计划未来步骤。例如，解决一个问题的每次尝试，基于代理的方法将具有多个步骤，每个步骤由某个操作组成。后续步骤依赖于先前操作及环境提供的反馈信息。

乍看之下，基于代理的方法似乎是解决软件开发任务的自然且直接的方法。然而，人类和当前LLM能力之间的差距导致了基于代理的方法存在以下局限性：

• 复杂的工具使用/设计。为了利用工具，当前的基于代理的方法在代理和环境之间应用了抽象层。例如，将真实操作映射到API调用，以便代理可以通过输出API调用指令来使用工具。然而，这种抽象和API调用规范要求对输入/输出格式进行仔细设计，很容易导致设计/使用的不准确或不精确，特别是在更复杂的操作空间中。由于代理的方法具有迭代特性，其中当前的动作/计划取决于先前的步骤，不准确或不精确的定义/使用工具可能会降低性能并在浪费的LLM查询中产生额外成本。
• 决策规划的控制不足。除了使用工具外，当前的基于代理的方法还将决策过程委托给代理——代理决定执行什么操作。代理根据先前的动作和环境提供的反馈决定当前的操作，而最少的检查以确保所采取的行动合理。由于可能的操作空间和反馈响应的庞大，代理很容易变得困惑并执行次优探索。此外，为了解决一个问题，代理可能需要30或40个步骤，这使得很难理解代理的决策以及调试错误的步骤。
• 有限的自我反思能力。现有的代理缺乏自我反思的能力。也就是说，它们往往缺乏过滤不相关、错误或误导信息的能力。例如，代理的方法中的常见步骤是使用最小测试用例重现问题。然而，重现的测试用例可能并不总是正确或精确的。有限的自我反思能力意味着错误的步骤可能会被轻易放大，并对代理未来的决策产生负面影响。

本文中，我们提倡在急于开发越来越复杂的基于代理的方法之前（这些方法也可能因完全自动化的设置而难以使用或复制），我们应该首先退一步，问自己一个具有深刻内省的问题：我们真的需要采用复杂的自主软件代理吗？

我们的工作设法通过构建AGENTLESS来回答这个重要问题——一种无需代理的方法来自动解决软件开发问题。为解决每个问题，AGENTLESS遵循简化的两步流程：本地化和修复。在本地化过程中，AGENTLESS采用分层方法首先将故障定位到特定文件，然后定位到类或函数，最后精确定位到代码行。为了进行修复，AGENTLESS选择编辑位置并生成多个候选补丁。AGENTLESS随后执行简单过滤，移除任何存在语法错误或无法通过代码库中先前测试的补丁。最后，AGENTLESS重新排序所有剩余的补丁，并选择一个提交以解决问题。

AGENTLESS利用LLM执行每个详细任务，与之前复杂的基于代理的方法不同，AGENTLESS不允许LLM自动决定未来的行动或操作复杂工具。我们有意选择不使用代理不仅使得AGENTLESS具有易于理解的简洁设计，还帮助避免了上述LLM代理在软件开发中的局限性。我们在流行的SWE-bench Lite基准测试上评估AGENTLESS，并证明AGENTLESS不仅在所有开源方法中取得了最高的性能（27.33%），而且成本最低。

此外，我们对SWE-bench Lite数据集进行了细粒度的手动分析，将其问题分类到不同维度，如问题描述、补丁准确性和定位信息。令人惊讶的是，我们观察到SWE-bench Lite包含问题（4.3%）的补丁描述精确，但信息不足以解决问题，及问题（9.3%）在问题描述中包含误导性解决方案。鉴于这些问题，我们构建了SWE-bench Lite-S，去除这些问题，并作为更严格的基准来评估解决现实世界软件开发问题的能力。

总体而言，在一个专注于在排行榜上取得成绩的时代，我们的工作强调了一种简单、可解释的技术在自主软件开发中的潜在价值。我们希望AGENTLESS能够帮助重置基准、起点和自主软件代理的发展方向，并激励未来在这一重要方向上的更多工作。

2 AGENTLESS方法

图1展示了AGENTLESS的概述，包含两个阶段：本地化和修复。我们首先接收问题描述和现有的项目代码库作为输入。然后，我们通过将项目代码库转换为展示每个文件在项目中相对位置的树形结构格式开始我们的分层本地化过程。接下来，使用这种存储库结构格式以及原始问题描述，我们请LLM本地化并排名需要编辑以解决问题的最可疑文件。然而，并非每个文件中的所有内容都需要修改。因此，我们为每个文件提供一个框架（即类和函数的声明头列表），并请LLM输出我们应该进一步检查的特定类和函数列表。然后，我们提供之前位置的完整代码内容，并请LLM确定一个更小的编辑位置集（即类、函数甚至特定行）。对于修复阶段，我们在这些编辑位置提供代码片段和问题描述，并请LLM采样多个补丁以解决问题。接着，我们进行简单的过滤以移除任何存在语法错误和回归测试失败的补丁，并使用多数投票排名剩余的补丁。最终，AGENTLESS选择排名最高的补丁作为提交的最终补丁。现在我们将详细描述AGENTLESS两个阶段中的每个步骤。

2.1 本地化

要修复或实现一个新特性，第一步是获取源代码中的位置，因为没有正确的位置，提供正确的编辑几乎是不可能的。难点在于可能有数百个包含数千行代码的文件在存储库中，而正确的编辑位置可能只是少数几行代码。AGENTLESS通过使用简单的三步层次本地化过程解决这一问题：1）本地化到选择的文件；2）本地化每个选择的文件到相关的类、函数和变量；3）本地化到代码编辑位置。

• 本地化到可疑文件：首先，AGENTLESS将可能的位置本地化到具体的可疑文件。我们构建一个表示存储库文件和目录结构的紧凑表示形式。我们称之为“存储库结构格式”，从存储库的根文件夹开始，组织代码文件和文件夹。文件和文件夹在同一目录级别对齐垂直排列，子目录中的文件和文件夹缩进。我们递归遍历整个存储库以获取存储库结构格式，并将其作为LLM的输入。存储库结构格式提供必要的文件路径以及相邻文件名称以保持原始信息。AGENTLESS然后将处理后的存储库结构格式以及原始问题描述输入LLM，请其识别需要进一步检查或修改的前N个可疑文件列表以解决问题。

• 本地化到相关元素：获取可疑文件列表后，AGENTLESS继续本地化过程的第二部分：本地化到可疑文件中的相关元素。直接提供完整的文件内容可能很大。因此，AGENTLESS为每个文件构建一个压缩格式，包含类、函数或变量声明的列表。我们称这种格式为“框架格式”，如图2所示。在框架格式中，我们只提供类和函数的声明头。对于类，我们进一步包括任何类字段和方法（签名）。此外，我们还保留类和模块级别的注释以提供更多信息。与直接提供整个文件上下文相比，框架格式是一种更紧凑的表示形式，特别是当文件包含成千上万行代码时，使得使用现有的LLM处理整个文件变得不切实际。我们一次提供所有可疑文件的框架格式，使得模型能够全面分析相关信息并决定最相关的元素。使用这种输入，我们请LLM提供一个应检查的相关类和函数列表以解决所提供的问题。
  

• 本地化到编辑位置：上一步本地化步骤提供了相关的类和函数列表。然后我们提供这些元素的完整代码内容并请LLM本地化到具体的编辑位置（例如类、函数或特定行）。简单的层次本地化过程允许AGENTLESS选择一组相关代码片段作为编辑位置进行修复。

2.2 修复

在修复阶段，目标是生成正确的补丁以解决问题。参考现有的基于LLM的程序修复工作，我们首先利用识别的编辑位置并构建一个上下文窗口的代码片段供LLM修复。例如，如果识别的编辑位置是从第40行到78行，我们将生成一个上下文窗口【40 - x，78 + x】，其中x表示上下文窗口大小。背后的直觉是在识别位置之前和之后添加额外代码以为LLM提供更相关的上下文信息以便更好地进行修复。如果识别到多个编辑位置，我们将连接这些上下文窗口，用“……”表示中间缺失的上下文。

补丁格式：使用这些代码片段，我们请LLM生成补丁以解决问题。然而，AGENTLESS请LLM生成一个搜索/替换编辑格式以高效创建每个补丁。图3展示了一个示例：1）搜索：我们要替换的原始代码片段；2）替换：我们要替换的新代码片段。应用生成的搜索/替换差异到原始文件，我们可以简单地匹配代码片段并用替换代码替换它。这个简单的差异格式避免了生成整个代码并专注于生成小编辑，这不仅成本效益更高，而且更可靠和准确（减少幻觉的可能性）。

过滤和补丁选择：对于每个问题，AGENTLESS使用LLM生成多个潜在补丁（从贪婪开始然后使用更高温度采样多个补丁）。我们还应用传统的软件工程技术回归测试以运行存储库中的所有生成补丁上的测试。任何未通过现有测试的补丁都可以被过滤掉，因为它们错误地更改了先前代码的正确行为。AGENTLESS对剩余补丁应用重新排名，使用多数投票：我们首先归一化每个补丁以忽略表面级差异（例如额外的空格、换行和注释），然后选择出现次数最多的补丁作为最终补丁提交。为了标准化补丁，我们首先解析旧代码和新代码（在应用补丁之前），然后将树转换为规范的源代码格式，最后计算标准化代码之间的文本差异以获得规范化补丁。

AGENTLESS通过使用简单的逐步方法解决存储库级别的问题。我们注意到，AGENTLESS中使用的技术没有单独使用，而是结合现有技术构建一个易于理解的方法。与现有的基于代理的方法相比，AGENTLESS使用简单的两步方法，首先本地化然后修复错误而不依赖代理进行决策。通过层次化本地化，AGENTLESS能够高效计算细粒度的编辑位置。通过简单的差异格式修复，AGENTLESS能够高效生成和评估多个补丁。

3 实验设置

数据集
我们使用流行的SWE-bench数据集评估AGENTLESS和基线方法，以测试解决实际软件工程问题的能力。SWE-bench中的每个问题都需要提交一个补丁来解决输入问题描述中描述的基本问题。特别是，我们专注于过滤后的子集SWE-bench Lite，其中包含300个带有测试的问题，以评估提交补丁的功能正确性。此外，我们还在SWE-bench Lite基准上进行了详细研究，不仅展示潜在问题和偏差，还产生了更严格的过滤问题集以进行更好评估。

实现
我们使用GPT-4o实现AGENTLESS。默认情况下，我们使用贪婪解码查询LLM。在采样过程中，我们使用采样温度0.8。对于每个问题，我们首先本地化到三个可疑文件，然后本地化到这些文件中的不受限制的可疑类和函数数目，使用贪婪解码。接下来，为了最大化找到正确编辑位置的机会，我们每个问题抽取四组编辑位置（即本地化阶段的第三步），并结合两个采样运行以提供更多修复上下文。这给我们每个问题两组编辑位置。对于每组，我们采用一个上下文窗口±10行围绕每个编辑位置，并生成21个补丁（1个贪婪和20个采样）。这导致每个bug总共421个补丁。我们采用先前工作中的相同搜索/替换编辑格式，并使用Python ast库进行解析以在我们的补丁规范化步骤中执行解析。由于在编写时存在的原始SWE-bench评估脚本问题，我们采用SWE-bench-docker评估设置。

基线
我们将AGENTLESS与13种基于代理的方法进行比较，这些基线工具代表了SWE-bench上性能最先进的方法。我们包括开源以及商业或闭源基线。我们注意到，大多数闭源基线不提供任何轨迹，只提供提交的补丁。因此，我们无法验证到达最终补丁的步骤。此外，我们还包括一个简单的基于检索增强生成（RAG）提出的基线，以供比较。在这种情况下，基线使用LLM直接生成补丁文件，通过提供最相关文件内容的文件列表，使用BM25检索。

指标
遵循先前工作，我们报告1）已解决的百分比：基准中解决的问题百分比；2）平均$成本：运行工具的平均推理成本；3）平均#令牌：用于查询LLM的输入和输出令牌的平均数量。此外，我们还报告正确位置的百分比：工具提交的补丁与地面真相开发者补丁编辑位置匹配的问题百分比。我们在文件、函数和行三个粒度上计算此指标。对于基线工具，我们直接使用它们报告的结果，或者来自官方排行榜或工具的官方论文/存储库。

4 评估

修复性能
表1展示了AGENTLESS和之前基于代理的方法在SWE-bench Lite上的主要评估结果。我们观察到AGENTLESS能够解决300个问题中的82个（27.33%）。虽然这不是在SWE-bench Lite上解决问题的最高百分比，但AGENTLESS与之前的基于代理的方法相比具有极高的竞争力，同时使用了更简单的设计和整体技术。重要的是要注意，许多顶尖技术是闭源/商业的，并且没有发布任何源代码以复制实验或进一步验证的轨迹。与开源方法相比，AGENTLESS能够实现最高的性能。

独特问题修复
图4展示了AGENTLESS解决的独特问题，相对于顶尖的闭源/商业和开源方法。“Others”表示每个类别中的所有其他方法。首先，我们看到相对于开源基于代理的技术，AGENTLESS能够解决15个其他现有开源代理无法解决的问题，显示出使用简单无代理方法在解决困难问题上的成功。此外，即使与高性能商业方法相比，AGENTLESS仍然能够提供独特修复，甚至比顶级商业解决方案Alibaba Lingma Agent更多。这表明AGENTLESS可以与现有的商业基于代理的设置互补。

本地化性能
在现实世界的软件开发中，除了直接修复问题，提供正确的编辑位置给人类开发者对于调试非常有帮助。因此，我们检查了每个技术生成的补丁位置与地面真相补丁的比较。我们在此注意到，修复bug可以在与地面真相不同的位置进行，然而比较地面真相补丁仍可以作为一个近似度量。表1还显示了每个工具提交补丁的正确位置百分比，跨行、函数和文件级别。我们首先观察到，具有正确位置的补丁百分比与解决率高度相关。令人有趣的是，在文件级别位置上的最高结果是OpenCSG StarShip，显著高于即使是表现最佳的方法，同时解决率相对较低（23.67%）。由于OpenCSG StarShip是一个不提供源代码或详细轨迹的商业产品，很难解释这种本地化性能和修复性能之间的巨大差异。通过使用我们简单的层次本地化方法，AGENTLESS仍然非常具有竞争力，与先前的基于代理的方法相比（功能级别和行级别本地化在所有开源方法中排名第二）。

AGENTLESS组件的消融研究
接下来，我们研究了本地化和修复阶段中每个组件对AGENTLESS最终性能的贡献。表2显示了AGENTLESS本地化阶段每个步骤的性能（对于步骤3，指标在两组位置上平均，成本为总成本）。我们展示了每个本地化步骤仍保留的地面真相编辑位置百分比，每个步骤中的行数，以及每个步骤的平均成本。我们观察到AGENTLESS能够在77.7%的情况下本地化地面真相文件；然而，使用所有本地化文件导致包含上下文的大量代码行。在第二步中，我们本地化到相关类和函数，能够显著减少上下文窗口。最后，AGENTLESS本地化到精确的编辑位置，进一步减少上下文而不失去大部分本地化准确性。此外，我们观察到，通过使用层次本地化步骤，AGENTLESS能够在执行有效本地化的同时最大限度地减少成本。

我们现在研究不同修复设置对最终性能的影响。表3显示了我们可以生成或选择提交最终补丁的不同方法。从生成单个样本（即贪婪解码）开始，AGENTLESS能够实现70个正确修复，同时每个bug的平均成本为0.11美元（总成本，包括本地化）。我们注意到，即使在这个简单的补丁生成步骤中，AGENTLESS也能够击败大多数先前的开源基于代理的方法（成本减少4倍以上）。我们可以通过多次采样LLM并使用多数投票选择补丁进一步提高性能至78个修复。最后，通过进一步过滤以仅选择能够通过现有回归测试的补丁，实现了AGENTLESS的最终性能。我们多次采样每个问题补丁，由此观察到AGENTLESS能够解决的总问题数为123个（41.0%）。这显示了AGENTLESS的修复潜力，同时表明通过重新排名和选择技术可以进一步提高总体性能。

5 其他分析在SWE-bench Lite上

5.1 问题分类

我们现在更仔细地看SWE-bench Lite中的问题。我们首先对现有问题进行分类，以更好地理解并获得更多关于AGENTLESS和以前的方法能解决什么类型的问题的见解。具体来说，我们基于每个问题的描述和地面真相开发者补丁对其进行手动分类。下面详细描述了每个分类维度及其类别：

描述质量
我们首先检查每个问题描述是否包含执行所需任务的足够信息。图5a显示了每个类别的分布：（i）仅包含自然语言中的信息，（ii）包含可重现的故障示例，（iii）包含部分可重现的示例，（iv）不包含足够信息。我们观察到，虽然SWE-bench Lite中的大多数任务包含足够的信息，其中许多包含一些小的失败示例来展示错误，但有9.3%的问题不包含足够信息。这样的问题包括需要实现一个带有特定名称的新函数，或者添加一个带有特定字符串的错误消息，而该字符串在问题描述中没有提供。这意味着如果函数名称或错误消息字符串不完全匹配，即使底层功能正确实现，测试也会失败。另一个信息不足的例子是问题有多个不同的解释，只有其中一部分可以通过地面真相测试。例如，问题描述将概述两个可能的解决方案建议，但只有一个与开发者意图一致。实现另一个建议将导致测试失败。这突显了进一步清理/改进SWE-bench Lite的必要性，在描述不完整的信息问题应该被排除。

解决方案在描述中
我们还检查了解决问题的解决方案或步骤是否已经在问题描述中提供。图5b显示了我们类别的分解：（i）未提供解决方案或步骤，（ii）提供部分解决方案（例如，自然语言中的某些步骤），（iii）提供完整解决方案（例如，自然语言中的完整步骤），（iv）提供了确切补丁，（v）提供了误导性解决方案或步骤。有趣的是，我们观察到4.3%的问题在问题描述中包含确切的地面真相补丁，另外10.0%的问题描述了得出正确解决方案所需的确切步骤。这表明在某些情况下，SWE-bench Lite中的问题可以更容易解决，因为它们提供了确切的代码片段或自然语言中的解决方案。此外，我们观察到4.3%的问题包含提出的解决方案或步骤，这些描述引入了开发者的误导性补丁。这进一步突显了基准中的潜在问题，因为这些差异可能会误导工具通过遵循问题描述生成不正确的解决方案。

位置信息
我们进一步检查问题描述是否包含正确的位置信息。我们将粒度划分为行、函数和文件级位置。我们的类别是：（i）自然语言中提供的确切位置，（ii）描述中提供的故障堆栈跟踪，（iii）可以用于搜索位置的相关关键字，（iv）未提供。我们首先观察到在极少数情况下（<10%），问题提供了解决错误所需的确切代码行。然而，当我们将粒度增加到函数和文件时，我们发现大约一半的问题已经在描述中提供了编辑文件的位置。为了修复错误或引入新特性，找到编辑位置非常重要。因此，我们利用这一分类并在后续分析中重点关注提供位置对AGENTLESS和基线方法修复性能的影响。

这些分类维度和类别提出了SWE-bench Lite问题的潜在问题，如无法解决的问题、误导性潜在解决方案和问题难度的显著差异。这些问题在基准创建过程或之前的方法中都没有得到适当考虑。此外，我们希望我们的分类能提供更多关于现有和未来方法可以解决的问题类型的见解。

5.2 SWE-bench Lite-S

表4展示了SWE-bench Lite-S基准上的性能和排名。我们还包含了原始300个问题在SWE-bench Lite上的结果以供比较。虽然所有方法的总体排名几乎相同，但我们观察到一些小的排名变化。与原始SWE-bench Lite相比，我们过滤后的SWE-bench Lite-S更准确地反映了基准的难度水平，提供了更真实的自主软件开发工具的能力。

基于上述问题分类，在接下来的评估部分，我们将更严格地比较和对比AGENTLESS和现有工作。具体来说，我们专注于SWE-bench Lite的子集，移除包含确切补丁的问题描述、误导性解决方案或不提供足够信息的问题。这消除了不合理的问题并规范了基准的难度水平。为了未来的工作，我们希望与维护人员合作，为SWE-bench Lite基准做出贡献，通过修复这些不合理的问题以添加额外信息，以及移除问题描述中的确切补丁。然而，由于我们无法运行商业工具自身，我们简单地排除了修改后的问题作为我们的SWE-bench Lite-S子集。

图6显示了在SWE-bench Lite-S上不同问题类别中的选择方法的解决率。红色虚线表示每种方法在整个SWE-bench Lite-S上的平均解决率。

使用分类结果，我们进一步研究了AGENTLESS和之前方法在SWE-bench Lite-S上解决的问题类型。图6显示了各种顶尖开源和闭源方法在不同问题类别上的解决率。我们首先检查问题描述中是否包含重现错误的代码示例以帮助LLM更好地解决问题。我们发现所有先前方法在评估包含可重现代码示例的问题时解决率下降。许多基于代理的方法首先尝试重现错误，但这可能不会提高对已提供重现示例的问题的性能。这表明仍有进一步提高的空间，特别是针对重现错误步骤。接下来，我们查看问题描述中提供地面真相补丁/解决方案的影响。图6b显示了预期结果，所有选择技术在已经提供解决方案步骤的问题上表现更好。此外，在图6c中，我们检查问题描述中包含的位置信息。毫不奇怪，我们发现解决率最高的是自然语言中提供位置的问题，其次是堆栈跟踪。最困难的问题是不包含任何位置线索的问题。我们观察到，与闭源方法相比，AGENTLESS在自然语言、堆栈跟踪或关键字中提供位置时表现相当。然而，当未提供位置线索时，闭源方法表现更好。这突显了基于代理的方法在解决这些更复杂问题上的优势，这些问题需要使用复杂的代码搜索工具。这代表了未来工作的潜在方向，以进一步提高AGENTLESS在这些类型问题上的性能。

读后感

论文为何称为"Agentless"

这篇论文称为"Agentless"的原因在于其提出的方法不依赖传统的代理（agent）机制。传统的代理机制通常包括复杂的工具使用和设计、决策规划和自我反思的能力。而"Agentless"方法摒弃了这些复杂性，采用了一种简化的两步流程：本地化和修复。这种方法不让LLM自动决定未来的行动或操作复杂的工具，而是通过简单的分层方法来定位和修复代码问题。这使得"Agentless"方法更易于理解和实现，同时避免了传统代理方法的很多局限性。

"Agentless"与"Devin"这种代理的区别

"Agentless"方法的特点：

1. 简化的工具使用和设计：不像传统的代理方法需要复杂的工具映射和API调用设计，"Agentless"方法使用简单的文件和代码结构来定位问题。
2. 明确的决策过程：决策过程不依赖代理的复杂规划，而是通过分步和层次化的方法来确定编辑位置。
3. 无自主决策："Agentless"方法中的LLM不自动进行未来的决策或操作复杂工具，而是按预设的步骤和规则操作。
4. 两步流程：本地化和修复的两步流程使得整个过程更简洁明了，避免了迭代性的复杂决策链。

Devin这种代理方法的特点：

1. 复杂的工具使用和设计：需要将实际操作映射到API调用，这涉及到复杂的输入输出格式设计和工具使用。
2. 自主决策和规划：代理自主决定每一步的操作，基于先前的动作和环境反馈不断调整计划。
3. 自我反思和调整：需要代理具备自我反思能力，能够过滤不相关或误导的信息，并调整自己的行为。
4. 多步迭代：解决问题的过程中，代理可能需要进行多次迭代，每次迭代都包括多个步骤的操作和反馈处理。

对比表

特点	“Agentless” 方法	Devin 代理方法
工具使用和设计	简单的文件和代码结构	复杂的工具映射和API调用
决策过程	分步和层次化方法，明确的预设规则	自主决策和规划，基于反馈不断调整
自主决策和操作	无自主决策，按预设步骤操作	代理自主决定每一步操作
自我反思和调整	无需自我反思，预设规则简单明了	需要自我反思能力，过滤误导信息
迭代过程	两步流程，本地化和修复	多步迭代，每次迭代包括多个步骤的操作和反馈

总结

"Agentless"方法通过简化工具使用、明确的决策过程和两步流程的设计，避免了传统代理方法的复杂性和局限性。Devin这种代理方法虽然更为自主和灵活，但其复杂的工具设计和决策过程可能带来更高的成本和错误风险。Agentless方法的简洁性使其在某些应用场景中更为有效和高效。