多样性赋予智能：整合软件工程智体的专业知识

24年8月来自Salesforce和CMU的论文“Diversity Empowers Intelligence: Integrating Expertise Of Software Engineering Agents”。

大语言模型 (LLM) 智体在解决实际软件工程 (SWE) 问题方面表现出巨大潜力。最先进的开源 SWE 智体可以在 SWE-Bench Lite 中解决超过 27% 的真实 GitHub 问题。然而，这些复杂的智体框架表现出不同的优势，在某些任务上表现出色，而在其他任务上表现不佳。为了充分利用这些智体的多样性，提出 DEI（多样性赋予智能），这是一个利用其独特专业知识的框架。DEI 作为现有 SWE 智体框架之上的元模块，管理智体集合以增强解决问题的能力。

大语言模型 (LLM) 的最新进展已经改变了软件工程 (SWE) 和其他领域。LLM 最初是作为聊天机器人开发的（Schulman，2022；Team，2024），现已发展成为 AI 智体的核心，能够理解和生成类似人类的对话，以及在现实世界和数字环境中自主执行操作。SWE 智体是这些 AI 智体的一个专门子集，它们将这些功能与软件工程工具和技术相结合，用于代码生成、自动测试和项目管理等任务，旨在识别和解决实际软件问题（Zhang，2024）。

如图所示，不同的 SWE 智体（Aider-Moatless-Agentless-OpenDevin）解决的问题集（图a中的彩色网格）非常不同，尽管解决率相似（图b）。提议的 DEI 委员会会选择候选patches并尝试选择最佳的，oracle选择（图c），从而显著提高解决率，使其优于委员会中的任何单个智体。

阿里巴巴 Lingma 智体（Ma，2024）构建了一个存储知识图谱来表示代码和依赖关系，使用基于蒙特卡洛树搜索的策略进行存储库探索，并生成patches来解决现实世界的 GitHub 问题。AutoCodeRover（Zhang，2024）向智体添加了高级代码搜索工具，例如抽象语法树和基于频谱的故障定位，以增强上下文理解和问题解决能力。CodeR（Chen，2024）选择了一个具有预定义任务图的多智体框架来解决 Github 问题。Agentless（Xia，2024）是一种解决软件开发问题的简化两阶段方法。它专注于定位和修复，而不依赖 LLM 来做出决策，凸显了直接性技术在自主软件开发中的潜力。 OpenDevin (Wang, 2024c) 是社区贡献的智体中心，包括 CodeAct (Wang, 2024b)、浏览器智体、GPTSwarm (Zhuge, 2024) 和特定于任务的微智体。最后，SWE-agent (Yang, 2024) 开发了智体-计算机接口，该接口由 LM 友好的命令和环境反馈组成，使 LM 智体能够自主使用计算机来解决软件工程任务。

组织多个专门的 AI 智体（Hong，2024；Li，2023；Liu，2024）可以实现智体系统的任务分解能力，从而提高任务解决性能。当前的多智体框架根据其执行模式分为三类。首先，静态智体工作流程（Wu，2024；Github，2023），它预先定义智体执行流程并通过指定条件触发智体转换。使用预定状态控制多智体系统是鲁棒的，但在未见过的状态或条件方面失去了灵活性。其次，通过群聊进行集成（Wu，2023；Hong，2024；Wang，2024a；Chen，2023）。这是建立在多个智体在群频道中互相发送消息的环境之上的，这样他们的想法就可以整合在一起。群聊的变体包括辩论（Liang et al.，2023；Chan et al.，2023）和模型集成（Wang et al.，2024a）。最后但并非最不重要的是，分层任务分配（Liu et al.，2024；2023）。以分层结构组织多智体有利于自上而下的任务分解，从而实现高效的多智体协作。

SWE-Bench 通过从 Github 上的开源存储库收集已成功解决的问题来整理此任务的实例。SWE-Bench 中的每个实例都包含一个文本问题描述、一个问题解决前的存储版本，以及人工编写patches之后从失败到通过的（隐藏）单元测试。要解决一个实例，模型需要生成一个可以通过这些单元测试的patch。

“SWE 智体”指基于 LLM 的系统，其能生成patch来解决代码库中的问题，例如 SWE-Bench 中的实例。虽然具体实现各不相同，但典型的 SWE 智体通常会以可调用函数的形式为其底层 LLM 提供多种工具，以浏览代码库、查找相关上下文、编辑文件和运行测试。SWE 智体的工作流程通常涉及多个 LLM 调用，每个调用都将之前部分或全部的输出作为输入。

考虑两种类型的多样性：智体内的多样性和智体间的多样性。

智体内多样性，定义为同一智体不同运行解决不同问题实例的程度。这很可能是由于解码中的采样和专家混合架构导致的底层 LLM 不确定性（Chann，2023）。由于 SWE 智体的工作流程涉及多个步骤和 LLM 调用，因此早期步骤中的细微差异很容易传播并导致最终结果的显着差异。

智体间多样性，定义为不同智体解决不同问题实例的程度。除了共享智体内多样性的潜在原因外，智体间多样性很大程度上还因为智体设计的差异，包括不同的工具、工作流程和提示。

在上下文马尔可夫决策过程 (CMDP) 框架 (Hallak，2015) 下制定了 SWE 智体问题，用元组 M = (S, C, A, R, P, p0, ρ) 表示。其中，S 表示状态空间，它包含智体可能遇到的所有可能状态，例如文件的当前状态。上下文空间 C 包括相关存储库信息和问题描述。动作空间 A 表示 SWE 智体可以利用的所有潜动作或工具，例如search或editing。上下文相关的奖励函数 R : S × A × C → R 根据智体采取的动作分配分数。例如，如果智体成功解决问题，则奖励很高，而如果该动作导致存储库中出现新错误，则奖励很低。上下文相关的转换函数 P : S × A × C → ∆(S) 定义了存储库或信息的状态在特定操作之后如何变化。上下文相关的初始状态分布表示为 p0 : C → ∆(S)，ρ 表示上下文分布。

给定初始上下文 c ∼ ρ 和初始状态 s0 ∼ p0(· | c)，在每个时间步骤 t，智体遵循策略 π : S × C → ∆(A) 在 ∼ π(st, c) 处选择一个动作并获得奖励 R(st, at, c)。然后环境转换到下一个状态 st+1 ∼P(·|st,at,c)，为智体提供新的状态观察。随着迭代进行到时间 T，获得采样轨迹 τ := {st,at,rt}。SWE 智体的目标是最大化沿轨迹的累积奖励，该奖励由价值函数捕获：

实现复杂的智体系统，对应（1）描述的目标。然而，这些系统在不同环境中的有效性水平往往不同。设计一个能够在所有可能的环境中始终表现良好的单个智体是一项挑战。

正式地，假设有 N 个智体策略，表示为 {π1、π2、…、πN}，其中每个策略都针对特定上下文 {ρ1、ρ2、…、ρN} 进行定制。这些上下文的并集是整个上下文空间的子集，即 ρ1 ∪ ρ2 ∪ ··· ∪ ρN ⊆ ρ。对于每个代理策略 πi，目标是：

但是，智体策略 πi 可能在不同的上下文 ρj（其中 j 不等于 i）中表现不佳。为了解决这一限制，提出了多样性赋予智能 (DEI)框架。DEI 框架利用每个智体在各自环境中的优势来提高所有环境中的整体性能。

引入一个元策略，表示为 πDEI，旨在根据上下文在可用的智体策略中进行最佳选择。πDEI 的目标定义为：

其中 π© 表示根据观察的上下文 c 从 {π1, π2, . . . , πN } 中选择最佳智体策略。通过动态选择最适合每个上下文的智体策略，DEI 框架寻求在所有可能的上下文中最大化预期累积奖励。

DEIBASE 是 DEI 框架的一个简单但功能强大的实现，专为 SWE-Bench 之类的问题量身定制。设置中的上下文包括存储库以及相关文件和问题描述。元策略的操作空间由不同智体框架生成的最终patches组成，每个框架都专门用于解决问题的各个方面。

DEIBASE 使用大语言模型 (LLM) 作为代码审查委员会。LLM 通过分析那些提议的更改之前和之后的代码库状态，结合问题描述中的上下文信息来评估候选patches。它为每个patch生成详细的解释，根据已识别的问题、上下文和所做的具体更改来证明修改的合理性。

虽然其他代码审查和评分方法（例如基于规则的方法）可以纳入该框架，但使用基于 LLM 委员会具有独特的优势。当评估比生成更容易时，LLM 通常在评估解决方案方面表现出色。因此，DEIBASE 可作为基于 LLM SWE 评估的有效基线，突出显示不同 SWE 智体之间的潜在性能差异，并展示方法的功能。

如图所示，针对单个问题，DEIBASE 会获得多个候选patches。这些patches可能是通过多次运行单个 SWE 智体或运行多个 SWE 智体获得的。DEIBASE 会为每个候选patch打分，然后选择得分最高的候选patch作为最有可能起作用的patch。

步骤 1：输入构造。每个patch都会向 DEIBASE 提供四个输入：问题描述本身、相关上下文（SWE 智体识别为与问题相关的代码片段）、patch前的代码和patch后的代码。输入的形式反映了两种设计选择。首先，整个存储库通常太大，无法直接容纳在 LLM 的上下文限制中，因此用相关上下文来节省token成本并帮助模型聚焦。其次，patch的格式对于 LLM 来说，不是最容易读取的，因为它会在更改前的代码和更改后的代码之间来回切换，因此将patch前后的代码分别提供给模型以便于理解。在实践中，直接使用开源 SWE 智体 Moatless Tools（Orwall，2024）识别的相关代码范围。通过使相关代码范围特定于问题和候选patch，而不是仅仅依赖于问题本身，可能存在提高相关代码范围质量的潜在方法。

步骤 2：解释生成。为了帮助模型在评分之前更好地“理解”patch，指示它按指定顺序生成有关patch的各种解释。决定顺序是为了让前面的解释也能帮助后面的解释。按照生成的顺序描述每个解释：1）问题解释，解释了问题是什么以及可能导致什么问题。2）上下文解释，解释了每个相关代码范围（可能有很多）与问题相关的方式和原因。3）位置解释，解释了patch是否以及为何修改了代码中错误的正确部分。4）patch解释，解释了patch是否以及如何修复问题。5）冲突检测，检查patch是否与其他相关代码片段冲突。其明确指示模型在生成后面的解释时参考前面的解释。

步骤 3：patch评分。根据模型自身的解释，要求模型为候选patch打出 1 到 10 分的分数。其为模型提供了详细的规则，说明哪些违规/错误会导致更高的分数扣分，哪些违规/错误只应被视为轻微违规。例如，如果模型发现修改位置有误，则将其视为严重错误。

最后，关于实验部分的说明。对于代理内多样性，考虑 SWE-Bench Lite 排行榜上表现良好的三个开源智体：Agentless（Xia，2024）、Moatless（Orwall，2024）和 Aider（Gauthier，2024），使用相同参数运行它们 10 次。对于智体间多样性，考虑了 10 个具有相似解决率的智体（开源或非开源），通过直接使用它们提交的 SWE-Bench 问题patch，它们在排行榜上的解决率都在 26.0% 到 31.0% 之间。对于不同智体上 DEIBASE 的评估，考虑了组成不同 DEI 委员会的 3 组智体，其中一组仅由开源智体组成。对于在单个智体多次运行中评估 DEIBASE，用上述三个智体（Agentless、Moatless Tools 和 Aider）的生成。