Salesforce软件工程智能体专家—DEI

摘要

大型语言模型（LLM）智能体在解决现实世界软件工程（SWE）问题上展现出的潜力已经不容忽视。目前，最先进的开源SWE智能体在SWE-Bench Lite测试中能够成功解决超过27%的真实GitHub问题。但有趣的是，这些复杂的智能体框架并非全能选手——它们各有侧重，在特定任务上表现亮眼，在其他任务上则可能掉链子。正是这种“偏科”现象激发了Salesforce研究团队的灵感：为什么不把它们的特长组合起来呢？于是，DEI（Diversity Empowered Intelligence）框架应运而生，它就像一个元模块，专门用来管理一群智能体，让它们协同作战。实验数据很说明问题：一组开源SWE智能体单独作战时，最大个体解决率只有27.3%，但挂上DEI后，解决率直接飙到34.3%，提升了整整25%，甚至碾压了不少闭源方案。我们表现最好的组合在SWE-Bench Lite上拿下了55%的解决率，直接登顶排行榜。这项研究为协作式AI系统如何攻克复杂软件工程难题提供了新的思路。

---

1 简介
2 相关工作
3 集成SWE智能体的专业知识
3.1 背景说明
3.2 SWE智能体的多样性
3.3 方法论
3.3.1 软件工程师智能体问题形式化
3.3.2 我们的框架：多元化赋能智能（DEI）
3.3.3 DEIBASE：一个简单但有效的实现
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 简介

大型语言模型（LLM）最近的发展可以说是彻底改变了软件工程的玩法。最初，它们只是聊天机器人（比如Schulman等人2022年的工作，以及Team 2024年的工作），但现在已经进化成AI智能体的核心，既能理解和生成类人对话，还能在真实环境和数字世界中自主执行操作。SWE智能体就是这些AI智能体里的一个专业分支，它们把LLM的能力和软件工程工具、技术整合在一起，负责代码生成、自动化测试、项目管理等任务，目标就是识别并修复真实世界的软件问题（Zhang等人，2024年）。

本文聚焦于SWE智能体的一项具体任务：根据问题描述来解决真实的GitHub issue。在代码仓库里自动修bug，这可不是闹着玩的——你得在大规模代码库中导航，理解复杂的函数交互，揪出那些微妙的错误，最后生成正确的修复补丁。SWE智能体的动作空间极大，加上路径又长，导致不同智能体解决GitHub问题的思路千差万别，如图1所示。我们观察到，不同的SWE智能体解决的完全是不同的问题集合（见图1a的彩色网格），尽管它们的解决率差不多（图1b）。这很可能是因为每个智能体都有自己的“独门绝技”。举个例子：OpenDevin（Wang等，2024c）会明确告诉LLM先在问题里复现bug，然后在开发工作区里执行复现脚本，用运行结果来反馈生成的补丁；但其他智能体，比如Moatless Tools（Örwall，2024）和Agentless（Xia等，2024），压根不执行代码。

一个花园的美从来不会只靠一朵花。多样性——无论以何种形式——都是通往卓越的途径。

SWE智能体社区的趋势同样反映了这种多样性：没有任何一个智能体框架能在所有能力上全面称霸。正是这种百花齐放，才不断催生新想法，推动更好的智能体出现。

SWE智能体能力的多样性，直接催生了DEI（多样化增强智能）框架的诞生——它的核心就是利用不同智能体的优势。DEI通过多智能体集成系统和重新排序管道，更高效地解决更广泛的问题，如图1c所示。DEI本身是一个元模块，可以和任何现有的智能体框架集成，实现可扩展的管理和协作，打造一个更强大的多智能体软件工程组织。

我们在SWE-Bench Lite上对7组候选智能体进行了DEI评估。其中3组是单个开源SWE智能体的多次运行结果，另外4组是SWE-Bench Lite排行榜上的不同智能体，包括一组纯开源智能体。实验发现，不同智能体在解决问题时的多样性非常高：一个平均解决率只有26.6%的智能体群体，如果能有一个“神谕”评审员始终选出最佳候选，它们合起来能解决54.3%的问题。作为开发多样性的第一步，DEI就能把该群体的解决率提升到34.3%（提升25%），这说明LLM确实是个出色的代码评审员。这些发现也呼应了技术行业中多样性的好处——不同的视角和技能能带来更大的创新和问题解决能力。

1. 首次全面评估了SWE智能体提供的解决方案的多样性
   ，揭示了不同智能体解决的GitHub问题类型存在显著差异，尽管整体解决率相似。这说明通过更有效地利用这些智能体的多样化专长，整体性能还有很大提升空间。
2. 本文提出了

   DEI——多智能体元策略模块
   ，目的就是利用SWE智能体的多样性，无缝促进具有不同专长的智能体之间的合作。通过多阶段评分和重新排序管道，DEI持续改善问题解决，在SWE-Bench Lite排行榜上实现了性能提升25%。

2 相关工作

这部分我们梳理一下基础语言智能体架构、近期专为软件工程开发的智能体，以及多智能体或集成方法。

该领域开创性的AI智能体方法包括ReAct（Yao等，2023年）、Reflexion（Shinn等，2023年）、CodeAct（Wang等，2024b年）等。ReAct能解释用户查询、生成功能API调用并实时获取工具输出；Reflexion进一步把失败的尝试经验附加到内存中，让重试更有效，避免重复犯错。CodeAct（Wang等，2024b年）不是生成函数调用，而是用代码生成把AI智能体的操作统一到一个动作空间里。

下面介绍几个在SWE-Bench Lite排行榜上披露了技术细节的SWE智能体。

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

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

• Code-R（Chen等，2024年）
  ：采用预定义任务图的多智能体框架来解决GitHub问题。

• Agentless（Xia等，2024年）
  ：简化两阶段方法，专注于定位和修复，不依赖LLM做决策，展示了直接方法在自主软件工程中的潜力。

• OpenDevin（Wang等，2024年）
  ：一个社区贡献智能体的中心，包含CodeAct（Wang等，2024b）、浏览器智能体、GPTSwarm（Zhuo等，2024年）和特定任务的微智能体。

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

近期的研究发现，组织多个专业化AI智能体（Hong等，2024年；Li等，2023年；Liu等，2024年）能提高智能体系统的任务分解能力，从而提升任务解决性能。目前的多智能体框架根据执行模式可分为三类。

第一类是静态智能体工作流（Wu等，2024年；GitHub，2023年），预定义智能体的执行流程，通过指定条件触发智能体切换。通过预定状态控制多智能体系统很稳健，但对未知状态或条件缺乏灵活性。

第二类是通过群聊实现集成（Wu等，2023年；Hong等，2024年；Wang等，2024a；Chen等，2023年）。多个智能体在群组频道中互发消息，让想法汇聚在一起。变体包括辩论（Liang等，2023年；Chan等，2023年）和基于模型的集成（Wang等，2024a）。

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

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

3.1 背景说明

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

本文中，“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→ℝ 根据智能体采取的动作分配分数。举个例子：如果智能体成功解决一个问题，奖励很高；如果动作导致存储库出现新错误，奖励就低。上下文相关的转移函数 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，目标是优化在对应情境上的表现。然而，一个策略 πi 在非自身的情境 ρj (j ≠ i) 中可能表现不佳。为了解决这个问题，我们提出了DEI框架。它利用每个智能体在其各自最适合的上下文中的优势，来提升整体性能。

我们引入了一个元策略 πDEI，根据上下文最优地选择可用的智能体策略。πDEI 的目标定义为：根据观察到的上下文 c，从 {π1, π2, ..., πN} 中选择最优的智能体策略。通过为每个上下文动态选择最合适的智能体策略，DEI框架旨在最大化所有可能上下文中的期望累积奖励。

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

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

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

当然，其他代码审查和评分方法（比如基于规则的方法）也可以整合进来，但基于LLM的委员会有独特优势。LLM 通常擅长评估解决方案——评估比生成容易时尤其如此。因此，DEIBASE 为基于LLM的SWE评估提供了一个有效基准，突出了不同SWE智能体之间的性能差异，也展示了我们方法的能力。

DEI首先检查候选补丁前后代码库的状态，以及其他相关上下文。然后，它生成关于问题、上下文和补丁的解释，并尝试论证补丁的正确性。基于这些解释，它对候选补丁打分，并挑选出分数最高的那个，认为它更可能是正确的。

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

对每个补丁，DEIBASE提供四个输入：问题描述本身、相关上下文（由SWE工程师标识为与问题相关的代码片段）、补丁前的代码和补丁后的代码。这种输入形式体现了两个设计考量。首先，整个存储库通常太大，直接塞进LLM的上下文窗口不现实，所以用相关上下文来节省token开销并帮助模型聚焦。其次，补丁的格式对LLM来说不太容易阅读，因为它要在改动前后的代码之间来回切换，所以我们把补丁前后的代码分别提供给模型，便于理解。在实践中，我们直接使用了 Moatless Tools 标识的相关代码段（一个开源SWE智能体，Örwall，2024）。未来或许可以通过使相关代码段更针对问题和候选补丁（而不仅仅依赖问题本身）来进一步提升质量。

为了帮助模型在评分之前更好地“理解”补丁，我们指示它按特定顺序生成关于补丁的各种解释。这个顺序是精心设计的，让前面的解释也能帮助后面的解释。按生成顺序，每个解释如下：1) ：解释问题是关于什么的，可能导致什么问题。2) ：解释每个相关代码段（可能有很多）如何以及为什么与问题相关。3) ：解释补丁是否以及为什么修改了有问题的代码的正确部分。4) ：解释补丁如何以及为何修复了问题。5) ：检查补丁是否与其他相关代码段冲突。我们明确指示模型在生成后续解释时参考之前的解释。

基于自己的解释，模型被要求给候选补丁打1到10分。我们给出了详细的评分标准，指出哪些违规/错误会导致扣大分，哪些只算轻微违规。比如，如果模型发现修改位置错误，那就是严重失误。

4 实验

我们的实验围绕两个研究问题展开：1）基于LLM的SWE智能体在智能体内和智能体间多样性上到底有多大差异？2）DEI能在多大程度上利用这种多样性，提升这些SWE智能体的性能？

4.1 实验设置

4.1.1 基准和智能体

我们在SWE-Bench Lite上进行实验，这是从完整SWE-Bench中抽样的300个实例的数据集，用于更全面地评估功能性错误修复（Jimenez等，2024年）。相比完整SWE-Bench，SWE-Bench Lite在排行榜上有更多提交，让我们能进行更全面的智能体间多样性分析。

对于智能体内部多样性，我们选择了三个在开源排行榜上表现优异的智能体：Agentless（Xia等，2024年）、Moatless Tools（Örwall，2024年）和Aider（Gauthier，2024年）。我们用相同参数连续运行十次，收集结果。对于智能体间多样性，我们考虑了十个智能体（包括开源和非开源），它们的解决率都在26.0%到31.0%之间，并直接使用它们提交的补丁。对于DEIBASE在不同智能体上的评估，我们组建了三组不同的DEI委员会，其中包括一个纯开源智能体组。更多细节见附录A.1。

4.1.2 评估指标

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

• 解决率
  ：衡量SWE智能体的表现，即智能体解决的问题百分比。用来衡量单个智能体和DEI的表现，以判断DEI的提升幅度。

• Union@k
  ：衡量在智能体完全一致的最佳情况下的性能，即任何 k 个解决方案能解决的问题数量。在理想情况下，Union@k 应与 Union@1 相同。也可以看作存在一个总能选对候选者的“神谕”奖励函数 R_oracle 的情况。

• Intersect@k
  ：衡量最差情况性能，即所有 k 个解决方案都解决的问题数量。相当于存在一个“敌对”奖励函数 R_adv，它总是试图选错候选。

• A verage@k
  ：衡量平均情况性能，即解决问题的平均数量，对应随机奖励函数 R_random 均匀抽样一个候选解。

• n@k
  ：衡量任何重新排序机制在从 k 个样本中选 n 个提交时解决问题的能力。重新排序机制越善于区分好坏方案，n@k 越高。对于总能选对的神谕，n@k 与 Union@k 相同；对于随机选择器，n@k 与 Union@n 相同。这里我们评估 n=1。

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

4.2 主要结果

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

为了回答这个问题，我们在图3中报告了10个不同智能体和10次单个智能体运行的“@k”指标。具体数值见表2。

从结果中能看出几点：

• 不同智能体解决的问题比同一个智能体不同运行解决的问题更具独特性。
  换句话说，多样性确实增强了智能。在第一个子图中，Union@k 与 A verage@k 之间的绝对/相对差异比后面三个子图大得多。对于“10个不同智能体”的设置，当 k 接近10时，解决的独特问题数量是单个智能体在组内平均解决数量的两倍。

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

我们将DEIBASE应用于图3中添加到组里的候选者，发现：

• DEIBASE在大多数情况下都有帮助。
  在所有子图中，对于大部分 k 值，n@k 相比于 A verage@k 都有显著提升，说明DEIBASE选择正确候选的能力远强于随机基线。

• DEIBASE在候选来自不同智能体时作用更大。
  这与研究问题1的发现一致：由于来自多个智能体的候选有更大的改进潜力（Union@k - A verage@k），DEIBASE带来的实际改进也更大（n@k - A verage@k）。这说明在有限的候选预算下，选择不同智能体比多次运行同一个智能体更有价值。

• 随着 k 增大，DEIBASE的改进先增加后趋于稳定。
  更大的 k 通常意味着更高的 n@k，但边际效益会递减，某些情况下增大 k 甚至可能导致性能略微下降。这表明目前的DEIBASE在大规模智能体群体上还不理想，排序机制还有改进空间。

基于以上结论，我们组建了三个DEIBASE组，每个候选来自不同的智能体，每个实例最多有5个候选。成员和表现见表1。DEIBASE-1包含排名前2的智能体，DEIBASE-2包含5个在排行榜上表现优异的闭源智能体，DEIBASE-Open包含4个开源智能体（方便未来研究人员复现整个流程）。如表1所示，所有三个DEIBASE实例的表现都优于组中最佳候选。令人惊讶的是，DEIBASE-Open的解决率提升了7%，击败了大部分闭源系统。

4.3 消融和分析

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

可以说，DEI本身也具备SWE智能体那样的潜在特征，可能导致多样化输出。因此，利用DEI的多样化输出很重要。但与输出代码补丁的SWE智能体不同，DEI的输出是一个整数分数，可以轻松聚合和平均。所以我们给DEI更多票数，根据分数平均值重新排列候选。在大多数DEIBASE实验中，每个候选补丁获得10票。为了研究更多投票是否带来更好的补丁审查，我们直接使用DEIBASE-Open、DEIBASE-Agentless、DEIBASE-Aider和DEIBASE-Moatless生成的分数，检查在不同 m 值下，前 m 个平均分如何帮助我们找到最佳补丁。如图4所示，更多投票通常带来更高的解决率。另一个发现是，在4个评估设置中，DEIBASE都能比仅有一票的平均候选者表现更好。即使DEIBASE在一票时未能超过平均值，在只有三票时也成功进步了。这些结果表明DEIBASE本身也产生多样输出，但通过分数平均化更容易聚合。

我们从提示中删除了要求解释的部分，然后在相同评估设置下比较DEIBASE-Open、DEIBASE-Agentless、DEIBASE-Aider和DEIBASE-Moatless的表现。表3报告了结果：在所有4个设置中，带解释的DEIBASE表现略优于不带解释的版本。

5 结论

本文提出了多样性增强智能（DEI），一个设计用于与任何现有SWE智能体框架集成的元策略模块，实现专业智能体之间的可扩展管理和协作，从而打造更强大的软件工程组织。通过大量评估，我们发现不同智能体在解决问题方面展现出很大的多样性：一组平均解决率只有26.6%的智能体，如果有一个总能选对候选者的“神谕”，能解决54.3%的问题。DEI是我们迈出的第一步，利用这种多样性，将该组的解决率提升到34.3%（+7%），证明LLM确实是出色的代码评审员。这些发现也映射了技术行业多样性的好处——不同的视角和技能能带来更大的创新和问题解决能力。

DEI代表着我们向完全自动化的AI组织迈出了第一步。我们相信，多智能体AI系统的全部潜力不仅在于通过智能工作流提高任务完成准确率——DEI提供了一种水平、可扩展的方法，促进现有多样化智能体的协作和集成，而无需重构工程工作。这种能力不仅优化和加速了即时的软件开发任务，也为基于AI的组织管理未来创新奠定了基础。