摘要

大型语言模型（LLM）智能体已经展示出在解决现实世界软件工程（SWE）问题方面的巨大潜力。最先进的开源SWE智能体在SWE-Bench Lite中可以解决超过27%的真实GitHub问题。然而，这些复杂的智能体框架表现出不同的优势，在某些任务上表现出色，而在其他任务上表现不佳。为了充分利用这些智能体的多样性，Salesforce提出了DEI（Diversity Empowered Intelligence），这是一个利用它们独特专长的框架。DEI作为现有SWE智能体框架的元模块，管理智能体集合以增强问题解决能力。实验结果表明，DEI引导的智能体委员会能够大幅超越最佳个体智能体的表现。例如，一组开源SWE智能体在SWE-Bench Lite上的最大单个解决率为27.3%，而使用DEI后可以达到34.3%的解决率，实现了25%的改进，并击败了大多数闭源解决方案。我们表现最佳的组在SWE-Bench Lite上以55%的解决率表现出色，获得了最高排名。Salesforce的研究结果为协作型人工智能系统以及它们解决复杂软件工程挑战的潜力做出了贡献。

目录

1简介

2相关工作

3集成SWE智能体的专业知识

3.1背景说明

3.2SWE智能体的多样性

3.3方法论

3.3.1软件工程师智能体问题形式化

3.3.2我们的框架：多元化赋能智能（DEI）

3.3.3DEIBASE：一个简单但有效的实现。

4实验

4.1实验设置

4.1.1基准和智能体 

4.1.2评估指标

4.2主要结果

4.2.1研究问题1：LLM基于SWE智能体有多种多样？

4.2.2研究问题2：DEI对帮助有多大？

4.3消融和分析

5结论

参考文献

1 简介

最近，大型语言模型（LLMs）的进展已经改变了软件工程。

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

在本文中，我们研究了SWE智能体的一个特定任务 - 根据其描述解决现实世界的GitHub问题。在代码存储库中自动修复错误是一项极具挑战性的任务，涉及导航庞大的代码库，理解复杂的函数交互，检测微妙的错误，并生成正确的修复补丁。 SWE智能体的大行动空间，以及长路径，不可避免地导致Github问题解决方案的多样性，如图1所示。我们观察到，不同的SWE智能体解决了完全不同的一组问题（图1a中的彩色网格），尽管它们的解决率相似（图1b）。这可能是由于SWE智能体的不同技能集。例如，OpenDevin（Wang等，2024c）明确指示LLM首先在问题中复制错误，并在开发工作区中执行其复制，为其生成的补丁提供反馈，但其他智能体如Moatless Tools（Orwall¨，2024）和Agentless（Orwall¨，2024）实际上不在问题特定存储库中执行代码。

一个花园的美丽从来不只存在于一朵花中。多样性以其各种形式是通向伟大的路径。

Code, data and leaderboard results at: salesforce-research-dei-agents.github.io联系方式：kexun@cmu.edu, weiran.yao@salesforce.com

同样，SWE智能体社区的趋势也反映出这种多样性- 没有任何单一的智能体框架在所有能力上占主导地位。正是在这个社区中的多样繁荣，激发了新的想法，并促使更好的智能体的发展。

SWE智能体能力的多样性激发了我们开发DEI，即多样性增强智能，这是一个利用不同智能体的优势的框架。DEI旨在利用这些不同的技能，通过多智能体集成系统和重新排序管道更有效地解决更广泛范围的问题，如图1c所示。 DEI作为一个元模块，可以与任何现有的智能体框架集成，实现可扩展的管理和协作，以形成一个更强大的多智能体软件工程组织。

每列代表SWE-Bench Lite中的一个问题。彩色格子表示问题已解决。

(a) matplotlib sphinx django

图1：不同的SWE智能体（Aider、Moatless、Agentless、OpenDevin）解决非常不同的问题集（图1a中的彩色网格），尽管它们有类似的解决率（图1b）。我们提出的DEI委员会接收候选的补丁，并试图选择最佳的“神谕”选择（图1c），明显提高了解决率，使其优于委员会中任何单个智能体。

我们在SWE-Bench Lite上对7组候选智能体进行了DEI评估。其中7个中有3个是单个开源SWE智能体的不同运行。另外4个是SWE-Bench Lite排行榜上的不同智能体，包括一个仅包含开源智能体的组。通过实验，我们发现不同智能体在解决问题时表现出很高的多样性：一个平均解决率为26.6%的智能体组，如果有一个oracle评审人员能够始终选择最佳候选者，他们集体可以解决54.3%的问题。作为开发利用多样性的第一步，DEI可以将该组的解决率提高至34.3%（↑ 25%），这表明LLMs是出色的代码评审员。这些发现反映了科技行业多样性的好处，不同的视角和技能可带来更大的创新和问题解决能力。

总结一下，我们的贡献如下：

1.首次，我们全面评估了由SWE智能体提供的解决方案的多样性，揭示了不同智能体解决的GitHub问题类型存在显著差异，尽管整体解决率相似。这些发现表明，通过更有效地利用这些智能体的多样化专业知识，有很大潜力改善整体性能。

2.本文介绍了DEI，这是一个多智能体元策略模块，旨在利用SWE智能体的多样性，无缝地促进具有不同专长的智能体之间的合作。通过采用多阶段评分和重新排序管道，DEI持续改善问题解决，展示了在SWE-Bench Lite排行榜上性能提升25%。

2 相关工作

我们在本节中审查了基本语言智能体架构的工作、最近针对SWE智能体的发展以及多智能体或集成方法。

基础语言智能体。在这一工作领域的开创性AI智能体方法包括ReAct (Yao等，2023年)，Reflexion (Shinn等，2023年)，CodeAct (Wang等，2024b年)等，其中ReAct解释用户查询，生成功能API调用，并实时获取工具输出；Reflexion进一步将失败的尝试经验附加到内存中，使得进行有效的重试以防止重复错误。CodeAct (Wang等，2024b年)不是生成函数调用，而是使用代码生成将AI智能体的操作 consolide到一个统一的动作空间中。

软件工程智能体.我们介绍了SWE智能体，这些智能体已经在SWE-bench Lite排行榜上披露了技术细节。

阿里巴巴灵码智能体（马等人，2024年）构建了一个知识库图来表示代码和依赖关系，使用基于蒙特卡洛树搜索的策略进行知识库探索，并生成补丁来解决真实世界的GitHub问题。

AutoCodeRover（张等人，2024年）为智能体添加了高级代码搜索工具，如抽象语法树和基于频谱的故障定位，以增强上下文理解和问题解决能力。

Code-R（陈等人，2024年）选择了一个具有预定义任务图的多智能体框架来解决Github问题。无智能体（夏等人，2024年）是一种简化的两阶段方法，用于解决软件开发问题,它侧重于本地化和修复，不依赖于LLM来做决策，突出了直接技术在自主软件开发中的潜力。

OpenDevin（王等人，2024年）是一个社区贡献智能体的中心，包括CodeAct（王等人，2024b）、浏览器智能体、GPTSwarm（诸葛等人，2024年）和特定任务的微智能体。

最后，SWE智能体（杨等人，2024年）开发了智能体计算机接口，由LM友好命令和环境反馈组成，使LM智能体能够自主使用计算机解决软件工程任务。

多智能体和集成智能体.最近的研究发现，组织多个专业化人工智能智能体（Hong等，2024年；Li等，2023年；Liu等，2024年）能够提高智能体系统的任务分解能力，从而提高任务解决性能。目前的多智能体框架根据它们的执行模式可分为三种类型。

首先是静态智能体工作流（Wu等，2024年；Github，2023年），该工作流预定义了智能体的执行流程，并通过指定条件点燃智能体转换。通过预定状态控制多智能体系统是稳健的，但在未知状态或条件方面缺乏灵活性。

其次是通过群聊实现集成（Wu等，2023年；Hong等，2024年；Wang等，2024年a；Chen等，2023年）。这是建立在一个环境之上的，其中多个智能体在群组频道中互发消息，使它们的想法汇聚在一起。群聊的变体包括辩论（Liang等，2023年；Chan等，2023年）和基于模型的集成（Wang等，2024年a）。

最后，是分层任务分配（Liu等，2024年；2023年）。将多智能体组织成分层结构有利于自上而下的任务分解，从而实现高效的多智能体协作。

3 集成SWE智能体的专业知识

3.1 背景说明

解决SWE-Bench中的问题。 在软件工程中一个重要的任务是解决开发人员提出的问题。 SWE-Bench通过从Github上的开源代码库中收集成功解决的问题的实例来管理此任务。 SWE-Bench中的每个实例包括文本问题描述，问题解决前的存储库版本，以及（隐藏的）单元测试，这些单元测试在人工编写的补丁之后从失败变为通过。 要解决一个实例，模型需要生成一个能够通过这些单元测试的补丁。

SWE智能体。在本文中，我们使用术语“SWE智能体”来指代任何基于LLM的系统，用于生成修补程序来解决代码库中的问题，例如SWE-Bench中的一个实例。虽然具体的实现可能有所不同，但典型的SWE智能体通常会向它们底层的LLM提供几种可调用函数工具，以便浏览代码库、找到相关上下文、编辑文件和运行测试。SWE智能体的工作流通常涉及多次LLM调用，每次调用都会接收前几个步骤的一些或全部输出作为输入。

3.2 SWE智能体的多样性

我们考虑两种类型的多样性：内部智能体多样性和外部智能体多样性。

智能体内部多样性被定义为同一智能体的不同运行在解决不同问题实例时的程度。这很可能是由于底层LLM的非确定性引起的，这是由于解码和专家混合架构的采样所导致的 (Chann, 2023)。由于SWE智能体的工作流涉及多个步骤和LLM调用，较早步骤的轻微差异很容易传播并导致最终结果的显著差异。

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

3.3  方法论

3.3.1  软件工程师智能体问题形式化

我们根据上下文马尔可夫决策过程（CMDP）框架（Hallak等，2015）制定了SWE智能体问题，表示为元组M =（S，C，A，R，P，p0，ρ）。这里，S表示状态空间，包括智能体可能遇到的所有可能状态，例如文件的当前状态。上下文空间C包括相关的存储库信息和问题描述。动作空间A代表SWE智能体可以利用的所有潜在动作或工具，例如搜索或编辑。上下文相关的奖励函数R：S×A×C→R根据智能体采取的动作分配分数。例如，如果智能体成功解决一个问题，则奖励很高；如果动作导致存储库中出现新的错误，则奖励很低。上下文相关的转移函数P：S×A×C→Δ（S）定义了在特定动作后存储库或信息的状态如何变化。上下文相关的初始状态分布由p0：C→Δ（S）表示，ρ∈Δ（C）表示上下文分布。

给定初始环境上下文 c ∼ ρ 和初始状态 s0 ∼ p0(· | c)，在每个时间步 t，智能体按照策略 π : S ×C → ∆(A) 选择一个动作 at ∼ π(st,c)，并获得奖励 R(st,at,c)。环境随后转移到下一个状态 st+1 ∼ P(· | st,at,c)，为智能体提供新的状态观测。随着迭代进行至时间 T，获得了一个样本轨迹。一个 SWE 智能体的目标是最大化沿着轨迹的累积奖励，这由价值函数来捕捉：

3.3.2      我们的框架：多元化赋能智能（DEI）

许多努力已经做出来实施复杂的智能体系统，其目标是实现方程式1中描述的目标。然而，正如第1节讨论的那样，这些系统在不同情境下的效果往往不同。设计一个能够在所有可能情境下始终表现出色的单一智能体是具有挑战性的。

形式上，假设有N个智能体策略，表示为{π1,π2,...,πN}，其中每个策略都是为了应对特定情境{ρ1,ρ2,...,ρN}而制定的。这些情境的并集是整个情境空间的子集，即，ρ1 ∪ ρ2 ∪ ··· ∪ ρN ⊆ ρ。对于每个智能体策略πi，目标是：

 (2)

然而，一个智能体政策πi在不同的上下文ρj（其中j ≠ i）中可能表现不佳。为了解决这一限制，我们提出了我们的框架：多元赋能智能（DEI）。DEI 框架利用每个智能体在其各自的上下文中的优势，以增强跨所有上下文的整体性能。

我们引入了一个元策略，表示为πDEI，其旨在根据上下文最优地选择可用的智能体策略。πDEI的目标定义为：

,(3)

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

3.3.3   DEIBASE：一个简单但有效的实现

我们提出了DEIBASE，这是DEI框架的一个简单而强大的实现，专门针对类似SWE-Bench的问题。设置中的上下文包括存储库，相关文件和问题描述。元策略的动作空间由不同智能体框架生成的最终补丁组成，每个框架都专门用于解决问题的各个方面。

DEIBASE利用一个大型语言模型（LLM）作为代码审查委员会。LLM通过分析所提议改动前后的代码库状态以及问题描述中的上下文信息来评估候选补丁。它为每个补丁生成详细的解释，根据确定的问题、上下文和具体的改动来证明修改的合理性。

其他的代码审查和评分方法，比如基于规则的方法，可以被整合到我们的框架中，但是基于LLM的委员会的使用具有独特优势。LLM在评估解决方案方面通常表现出色，当评估比生成容易时。因此，DEIBASE作为LLM-based SWE评估的有效基准，突出了多样化SWE智能体之间潜在的性能变化，并展示了我们方法的能力。

图2：框架概述。DEI首先检查候选补丁之前和之后的代码库，以及其他相关上下文。然后，它生成有关问题、上下文和补丁的解释，并尝试证明补丁的正确性。通过自己的解释，它对候选补丁进行评分，并挑选评分最高的补丁，认为其更有可能是正确的。

如图2所示，DEIBASE为单个问题提供多个候选补丁。这些补丁可能来自多次运行单个SWE智能体或运行多个SWE智能体。DEIBASE为每个候选补丁打分，然后选择得分最高的候选者作为最有可能奏效的补丁。

步骤1：输入构建。对于每个补丁，DEIBASE提供四个输入：问题描述本身，相关上下文（由SWE工程师标识为与问题相关的代码片段），补丁前的代码和补丁后的代码。输入形式反映了两个设计选择。首先，整个存储库通常太大，无法直接适应LLMs的上下文限制，因此我们使用相关上下文来节省记号成本并帮助模型集中注意力。其次，一个补丁的格式对于LLM来说不是最容易阅读的，因为它在改变前后的代码之间来回切换，因此我们将补丁前后的代码分别提供给模型以便更容易理解。在实践中，我们直接使用Moatless Tools标识的相关代码段，这是一个开源SWE智能体（Orwall，2024）。可能有一些潜在的方法可以通过使相关代码段特定于问题和候选补丁而不仅仅依赖于问题本身来提高相关代码段的质量。

Step 2: Explanation Generation.为了帮助模型在评分之前更好地“理解”补丁，我们指示它按照特定顺序生成各种关于补丁的解释。顺序是决定的，这样早期的解释也可以帮助后期的解释。我们按照它们生成的顺序描述每个解释：1) 问题解释解释了问题是关于什么，可能导致什么问题。2) 上下文解释解释了每个相关代码段（可能有很多）如何以及为什么与问题相关。3) 位置解释解释了补丁是否以及为什么修改了有问题的代码的正确部分。4) 补丁解释解释了补丁如何以及为何修复了问题。5) 冲突检测是关于检查补丁是否与其他相关的代码片段发生冲突。我们明确指示模型在生成后续解释时参考之前的解释。

第三步：修补评分。根据其自身的解释，要求模型为候选修补给出1到10的分数。我们向模型提供详细的评分标准，指出哪些违规/错误会导致较高的分数扣除，哪些只应被视为轻微违规。例如，如果模型发现修改位置错误，那就被认为是严重错误。

4  实验

我们的实验旨在回答两个研究问题：1）基于LLM的SWE智能体在智能体内和智能体间多样性方面有多少差异？2）DEI在多大程度上可以利用这种多样性并提高这些SWE智能体的性能？

4.1 实验设置

4.1.1 基准和智能体 (BENCHMARK AND AGENTS)

基准测试。我们在SWE-Bench Lite上进行实验，这是从完整的SWE-Bench中抽样的包含300个实例的数据集，用于提供对功能性错误修复的更为完整的评估（Jimenez等，2024年）。与完整的SWE-Bench相比，SWE-Bench Lite在排行榜上有更多的提交，使我们能够进行更全面的互操作智能体多样性分析。

智能体。对于智能体内部的多样性，我们考虑了三种在公开源上表现良好的智能体。

SWE-Bench Lite排行榜：通过使用相同参数连续运行十次，对无智能体 (Xia 等人，2024年)、无壕沟 (Orwall¨，2024年) 和增强器(Gauthier，2024年) 进行评估。为了考虑智能体间的多样性，我们考虑了十个智能体（开源或非开源），它们的解决率都在26.0% 到 31.0% 之间，并直接使用它们提交的补丁来解决 SWE-Bench 问题。对于 DEIBASE 在不同智能体上的评估，我们考虑了三组形成不同 DEI 委员会的智能体，包括一个只包含开源智能体的组。

基于单个智能体商的多次运行，我们使用了三个前述智能体商的生成 - 无智能体商、无护栏工具和辅助人员。更多详细信息请参见附录A.1。

4.1.2  评估指标

我们对内部和外部智能体的多样性使用相同的一组指标，因为这些指标是为多个候选解决方案定义的，而不需要它们来自同一候选者：

解决率衡量了一个SWE智能体人的表现。它被定义为智能体人解决的问题的百分比。我们用它来衡量单个SWE智能体人和DEI的表现，以确定DEI提供了多少帮助。

Union@k通过计算任何 k 个解决方案解决问题的数量来衡量在智能体人完全一致的最佳情况下的性能。在智能体人完全一致的理想情况下，Union@k 应该与 Union@1 相同。Union@k 也可以被视为在存在一个总是选择正确候选者的神谕奖励函数 Roracle 的情况。

Intersect@k通过计算所有k个解决方案解决的问题数量来衡量最坏情况性能。假设是问题只有始终被解决才被认为是被稳定解决。姚等人(2024)称这个度量为pass^k。Intersect@k也可以被视为当我们拥有一个敌对奖励函数Radv时的情况，该函数在存在错误候选时会尝试选择一个不正确的候选。

Average@k通过计算解决问题的平均数量来衡量平均情况表现。它对应于具有随机奖励函数Rrandom的情况，该函数为每个问题均匀抽样一个候选解。

n@k通过计算从k个样本中选择的n个提交解决的问题数量来衡量任何重新排序机制的性能。重新排序机制越擅长区分好的解决方案和坏的解决方案，n@k的值就越高。请注意，对于总是选择正确解决方案而非错误解决方案的oracle，n@k与Union@k相同。对于选择均匀随机解决方案的随机重新排列器，n@k与Union@n相同。在我们的案例中，我们评估n = 1。

我们的研究问题可以通过这些指标之间的差距来回答。Union@k - Intersect@衡量了智能体的多样性，而n@k - Average@k衡量了DEI在从这些智能体中选择正确候选人方面的帮助程度。请注意，随着k的增大，将不同运行添加到堆中的顺序很重要，特别是当k个候选解来自k个不同智能体时。在我们的实验中，我们按照生成的顺序添加来自单个智能体的候选解，而按照固定顺序添加来自不同智能体的解决方案（参见附录A.1）。

4.2 主要结果

4.2.1  研究问题1：LLM基于SWE智能体有多种多样？

为了回答这个问题，我们在图3中报告了10个不同智能体和10次单个智能体的“@k”指标。这些指标的详细数值也可以在表2中找到。

图3：随着涉及更多候选解决方案，不同指标的变化情况。在所有4种场景中，Union@k和Average@k之间存在很大差距。

关于结果，可以得出几点观察结果：

不同的智能体程序解决的问题比同一个智能体程序的不同运行解决的问题更具有独特性。换句话说，多样性确实增强智能。在第一个子图中，Union@k 和 Average@k 之间的绝对/相对差异比接下来的三个子图要大得多。对于“10个不同智能体程序”的设置，在 k 接近10时，解决的独特问题是单个智能体程序在该组中解决问题平均数量的2倍。

表1：SWE-Bench Lite中排名前列提交的解决率。我们评估了由不同群体的智能体组成的3个DEI委员会。每个DEI委员会的表现都显著优于其中最好的智能体。DEIBASE-Open是由4个开源智能体组成的委员会，可以击败许多闭源智能体。

Salesforce Research DEIBASE-Open选择了字节跳动的Marscode,阿里巴巴的灵码（Lingma）,亚马逊Q Dev.,IBM的研发智能体，开源的Aider，OpenDevin+CodeAct进行对比。

他们的repo 还没有任何代码。一个早期版本是开源的。当前的版本不是。

候选者是通过“不带壕沟工具的修改”生成的。

4.2.2    研究问题2：DEI对帮助有多大？

我们将DEIBASE应用于图3中添加到组中的候选人。我们的发现是：

DEIBASE在大多数情况下都有所帮助。在所有子图中，对于大多数k值，我们观察到n@k相比于平均值@k有显著的提升，表明DEIBASE选择正确的候选项比随机基线要好得多。

DEIBASE在候选人来自不同智能体商时发挥更大的作用。这一发现与研究问题一的类似发现 resonates：由于来自多个智能体商的候选人有更大的改进潜力（Union@k - Average@k），DEIBASE创造的实际改进也更大（n@k - Average@k）。这表明，在有限的候选人预算下，选择不同智能体商的多样性要好于多次运行同一智能体商。

随着 k 值的增大，DEIBASE 的改进首先增加，然后趋于稳定。虽然较大的 k 通常表示更高的 n@k，但边际效益会变小，在某些情况下，增加 k 可能导致性能略微下降。这表明目前的 DEIBASE 对于大规模智能体群体并不理想，还有改进排序机制的空间。

基于以上的教训，我们提出了三个DEIBASE组，每个候选者来自不同的智能体商，每个实例最多存在5个候选者。这些DEIBASE组的成员及其表现在表1中报告。DEIBASE-1包括排名前2的智能体商。DEIBASE-2包括5个在排行榜上表现优异的闭源智能体商。DEIBASE-Open包括4个开源智能体商，以便我们知道未来的研究人员可以运行整个流程。如表1所示，所有三个DEIBASE实例的性能均优于组中最佳候选者。令人惊讶的是，DEIBASE-Open显示出解决率提高了7%，击败了大部分闭源系统。

表2：随着涉及更多候选解决方案，不同指标的变化情况。随着候选数 k 的增加，从 DEI 获得的改进也显著增加。

4.3  消融和分析

在这个小节中，我们进行了一些消融研究，以探究框架中不同组件的有效性，以回答以下问题。为了倡导开放科学，所有的消融实验都是在我们自己复制的开源SWE智能体或官方生成的智能体上进行的。

问题1：DEI是否随着更多的投票而变得更好？

图 4：随着为LLM提供更多评分票，DEIBASE的表现如何变化。

图 4：随着 LLM 获得更多评分票数，DEIBASE 的性能如何变化。

答案1：是的。可以说，DEI本身具有与SWE智能体相同的潜在特征，可能导致多样化的输出。因此，对我们来说很重要的是利用DEI的多样化输出。然而，与输出为代码补丁的SWE智能体不同，DEI的输出是一个整数分数，可以轻松地聚合和平均。这就是为什么我们给予DEI更多票数，并根据分数的平均值重新排列候选人。在大多数DEIBASE实验中，我们允许每个候选补丁获得10票。为了研究更多的投票是否会导致更好的补丁审查，我们直接使用为DEIBASE-Open、DEIBASE-Agentless、DEIBASE-Aider和DEIBASE-Moatless生成的分数，并检查在各种m的值下，前m个分数如何帮助我们找到最佳的补丁。

正文段落内容： 如图4所示，更多的投票通常会导致更高的解决率。另一个发现是，在4个评估设置中，DEIBASE能够比仅有一个投票的平均候选者表现得更好。即使DEIBASE在一个投票时未能超过平均水平，它也成功在仅有三个投票时取得了进步。这些结果表明，DEIBASE本身也产生不同的输出，但通过得分平均化更容易进行聚合。问题2：解释是否必要？

答案2：是的。我们从提示中删除了要求解释的部分，然后进行比较。

在相同的评估设置下，我们对DEIBASE-Open、DEIBASE-Agentless、DEIBASE-Aider和DEIBASE-Moatless进行评估，其中包括带有解释和不带解释的情况。我们在表3中报告它们的解决率。对于我们评估的所有4个设置，带有解释的DEIBASE表现略优于没有解释的DEIBASE。

表3：比较DEIBASE在有和没有解释的情况下的处理率。

5  结论

本文介绍了多样性增强智能（DEI），这是一个设计用来与任何现有的SWE智能体框架集成的元策略模块，以实现专业智能体之间的可扩展管理和协作，从而促进更强大的软件工程组织。通过广泛的评估，我们发现不同的智能体在解决问题方面表现出很大的多样性：一组平均解决率为26.6%的智能体实际上如果有一个选择正确候选者的"oracle"，可以解决54.3%的问题。 DEI 是我们采取的第一步，旨在利用这种多样性，可以将该组的解决率提高到34.3%（+7%），表明LLMs是出色的代码审阅者。这些发现反映了科技行业多样性的好处，多样化的观点和技能可以带来更大的创新和问题解决能力。

更广泛的影响。DEI代表着我们迈出实现完全自动化组织AI的第一步。我们相信，多智能体AI系统的全部潜力不仅在于提高任务完成准确性与智能工作流程的当前重点，而是DEI提供了一种水平、扩展性的方法，促进了现有多样智能体的协作和集成，而无需重构工程工作。这种能力不仅优化并加快了即时软件开发任务，还为基于AI的组织管理未来创新奠定了基础。