SWE-DIVE：用动态用户模拟评测多轮编码 Agent

研讨会标题 面向模型评测与训练的有依据用户模拟：多样性、保真度与效度

SWE-DIVE：用动态用户模拟评测多轮编码 Agent

Lorenz Brehme, Benjamin Steenhoek, Ruth Breu

编码 Agent 通常使用一次性的、表述良好的提示来评测。诸如 SWE-bench 之类的基准把现有的 GitHub issue 用作编码 Agent 的输入，并评估该 Agent 是否成功解决任务。然而，在真实使用场景中，提示往往并不像现有 GitHub issue 那样表述良好或结构清楚。此外，一次编码 Agent 会话并不限于单条提示；它通常包含多轮交互，用户在其中迭代地添加新任务与需求，而 Agent 必须予以满足。

为了对这些能力进行基准评测，我们开发了 SWE-DIVE，一个用于在多轮环境中对编码 Agent 进行基准评测的动态、交互式验证与评测框架。为此，我们引入一个用户模拟器，它可以模拟不同的行为模式，并与编码 Agent 通信。我们还引入一个对话验证器，用于评估用户模拟器的输出，以判断这些输出是否满足初始需求，并引导 Agent 成功解决任务。整个框架嵌入在一个 Harbor 环境中，该环境编排编码 Agent、用户模拟器与对话验证器，并执行测试环境，以判定 Agent 是否成功解决任务。我们的结果与源代码可在我们的 GitHub 仓库中获得（https://github.com/lorenzbrehme/swe-dive_usersim (https://github.com/lorenzbrehme/swe-dive_usersim)）。

1 引言

Agent 通常在从 GitHub issue 收集而来、或为某项特定任务精心构造的基准上接受评测，例如 SWE-bench (Jimenez et al.,, 2024)。然而，一份完整、详尽的 github issue 这种输入格式，并不是用户通常与 Agent 交互的方式——用户常常给出缺乏细节的高层提示，并在原型上迭代，直到它完成 (Baumann et al.,, 2026)。换句话说，对 Agent 的提示是一个迭代地定义问题的过程，而不是一次性尝试。

Baumann et al., (2026) 调查了人类使用编码 Agent 的行为，并发现该 Agent 被用于多轮交互，其中会浮现出不同角色，例如专家吹毛求疵者或含糊的程序员。这些多轮行为已在诸如 CodeFlowBench (Wang et al.,, 2026) 和 CodeGen (Nijkamp et al.,, 2023) 等基准中得到研究，这些基准在多轮设定下评测编码 Agent。在这些基准中，任务通常涉及迭代地添加新功能，要求 Agent 持续适应并找到解决方案。此外，AmbigSWE-bench 通过提供含糊的指令，并允许 Agent 提出澄清问题以消除这种含糊性，来探索用户的含糊行为 (Vijayvargiya et al.,, 2025)。这些多轮基准遵循预定义的流程，并不会根据 Agent 所询问的内容进行适应。Baumann et al., (2026) 表明，41% 的轮次是推回，这表明 Agent 并未按用户所期望的那样执行，因而需要澄清。此外，Vijayvargiya et al., (2025) 表明，Agent 仍然被提示以完整的任务列表，而更现实的设定则是用户提供非常吹毛求疵且含糊的指令，并在多轮对话中迭代地添加新任务。

为克服这些挑战，我们引入一个动态交互式验证与评测基准 SWE-DIVE，它建立在 DIVE 方法论之上，该方法论最初是为评测检索增强生成系统而提出的 (Brehme et al.,, 2026)。SWE-DIVE 将现有的软件工程基准（如 SWE-bench）转化为动态的、交互式的评测环境。它把原始任务拆分为增量式子任务，并使用一个 LLM 来模拟用户的发现过程。

2 相关工作

对软件工程 Agent 进行基准评测，需要一组由现有代码库以及 Agent 必须满足的相应测试套件组成的任务。诸如 SWE-bench (Jimenez et al.,, 2024) 和 Terminal-Bench (Merrill et al.,, 2026) 之类的基准，通过使用已经由人类开发者解决过其中 issue 的现有软件仓库来提供此类任务。每项任务都包含一个预定义的初始状态（所提供的测试失败）和一个期望的最终状态（在应用所需的代码修改之后，测试通过）。

这些任务通常通过一条描述待解决问题的单次提示提供给 Agent。在 Agent 修改代码库之后，基准执行相关联的测试套件，以判定任务是否已成功完成。由此得到的成功率随后被用作指标，以比较不同软件工程 Agent 的性能。

为扩展这些基准，诸如 CodeFlowBench (Wang et al.,, 2026) 和 CodeGen (Nijkamp et al.,, 2023) 之类的方法把多轮交互引入评测过程。这些基准定义一个任务序列，并迭代地提供给 Agent，使其能够在若干次交互中完成多个开发步骤。一些方法从零开始初始化 Agent (Nijkamp et al.,, 2023; Orlanski et al.,, 2025)，而另一些方法则建立在现有仓库之上，通过选择并筛选 issue，或在多次迭代中引入额外需求，例如 CodeFlowBench (Wang et al.,, 2026)。然而，这些基准在很大程度上仍然是静态的，因为任务与需求的序列是预定义的。它们并未捕捉真实的用户行为，即需求会动态演化，用户会提供反馈，并且目标可能在开发过程中发生变化 (Baumann et al.,, 2026; Vijayvargiya et al.,, 2025)。

另一种引入多轮行为的方法，是根据 Agent 实现的最终结果提供反馈。在这种设定中，Agent 会收到关于测试是否已经通过的信息；如果没有通过，则会得到测试结果，以便迭代地改进其解决方案 (Yang et al.,, 2023)。然而，这些基准仍然依赖高度结构化、形式化的任务描述。

为应对这一局限，Garg et al., (2025) 修改 SWE-bench 的任务描述，以创建更真实的用户请求。类似方法通过纳入不同的用户人格，把含糊性引入任务描述，Agent 可以在开始实现之前提出澄清问题，以获得额外信息 (Vijayvargiya et al.,, 2025; Zhou et al.,, 2026)。

尽管有这些改进，真实软件开发的一个重要方面仍未被探索：用户不仅澄清已有需求，还会在整个开发过程中引入新的任务与需求。现有基准主要聚焦于解决单个预定义的 issue，而与编码 Agent 的真实世界交互往往涉及迭代协作，用户在其中持续精炼目标并添加新请求 (Baumann et al.,, 2026)。为填补这一空白，我们引入 SWE-DIVE，一种与具体基准无关的新方法，通过动态的多轮交互来评测编码 Agent，从而更好地反映真实的用户与 Agent 协作。

3 SWE-DIVE

图 1：SWE-DIVE 概览

SWE-DIVE 是一个用于对软件工程 Agent 进行基准评测的动态、交互式验证与评测框架。它建立在现有基准之上，例如 SWE-bench (Jimenez et al.,, 2024) 和 Terminal-Bench (Merrill et al.,, 2026)，把单轮基准任务转化为多轮交互式评测。这是通过一个与 Agent 协作以完成原始基准任务的用户模拟器来实现的。该框架由三个主要组件组成：用户模拟器、对话验证器，以及任务完成评估器。用户模拟器与被评测的 Agent 交互，对话验证器评估交互的质量与有效性，任务完成评估器则判定基准任务是否已成功完成。

3.1 用户模拟器

SWE-DIVE 的第一个组件是用户模拟器。该组件利用一个 LLM 来模拟与被评测的软件工程 Agent 进行交互的用户。为了实现真实的用户交互，我们把用户模拟器锚定在现有的、已经过验证的任务描述上，这些描述规定了底层需求与实现上下文。这种锚定使模拟器能够刻画一个协作式用户，该用户在整个软件实现过程中交互式地发现、澄清并精炼需求。这使得 SWE-DIVE 有别于现有基准 (Wang et al.,, 2026; Nijkamp et al.,, 2023)；在那些基准中，交互主要用于提供缺失的信息，而不是用来刻画需求发现与精炼的迭代过程。模拟器向 Agent 呈现任务，回应它的问题，按需提供额外信息，并基于 Agent 的回应及其对代码库的修改给出反馈。它通过引入后续请求或澄清来迭代地推进对话，直到任务已成功完成，或者无法再取得进一步进展。

#### 输入：

在交互开始之前，用户模拟器会被指派一个角色。我们把用户模拟锚定在来自 SWE-Chat (Baumann et al.,, 2026) 的行为模式上，这些模式源自对真实用户与编码 Agent 交互的观察。具体而言，我们利用三种角色。专家吹毛求疵者维持一个稳定的总体目标，同时对实现提供一系列精确、有针对性的修正。每一次交互所精炼的，是 Agent 如何实现该解决方案，而不是它被期望构建什么。含糊请求者提供宽泛、规格不足的指令，并把大多数实现决策委托给 Agent。最后，改变主意者会在交互期间逆转总体目标，从根本上改变 Agent 被期望构建的东西，而不仅仅是修改实现细节。这些角色并非旨在代表彼此不同的用户群体或单个用户。相反，它们捕捉的是在 SWE-Chat 中观察到的多样行为模式，并为研究编码 Agent 如何回应不同的用户行为提供受控条件。

在第一轮中，用户模拟器被提示以初始基准任务。完整的任务规格说明，例如来自 SWE-bench (Jimenez et al.,, 2024) 的 issue 描述，会与描述期望结果的参考解决方案一起提供。这一原始目标充当用户模拟器的锚定，并提供引导交互所需的上下文。模拟器并不遵循一个预定义的子任务序列，而是根据 Agent 的进展，自适应地决定下一步应当传达什么信息、澄清或需求。在每一轮中，用户模拟器都会收到 Agent 的最新回应，以及它对代码库所做的更改，并利用这些信息来校验并调整自己的下一条消息。这使模拟器能够使交互适应 Agent 的行为，同时保持与原始任务目标一致。

#### 输出：

基于所提供的信息，用户模拟器为 Agent 生成一条包含第一个子任务的初始提示。该子任务作为起点，其设计目的是引导 Agent 完成整体基准任务。除初始提示之外，用户模拟器还会生成一份完整的子任务列表，从而为解决该 issue 提供一条总体轨迹。

在后续轮次中，用户模拟器只生成下一条用户提示。根据 Agent 的进展，这条提示可能包含修正、新的子任务、后续请求，或对 Agent 所提问题的回应。

一旦用户模拟器判定整体任务已经成功完成，它便返回‘done’，而不是再生成另一条提示，从而终止模拟。这使每个 Agent 都能按自己的节奏完成任务。此外，还会强制执行一个最大轮次上限，以防止 Agent 在无法解决基准任务时进入无尽的交互循环。

3.2 对话验证器

对话验证器确保由用户模拟器生成的对话保持在所定义的轨迹之内，遵循被指派的用户角色，并有效地引导 Agent 去解决基准任务。为此，SWE-DIVE 实现了一个验证循环，它可以看作 chain-of-verification 的一种修改形式 (Dhuliawala et al.,, 2023)。

首先，对话验证器接收用户模拟器所生成的输出。它执行两个验证步骤：子任务验证与 Agent 输入验证。在初始轮次中，它验证所生成的子任务列表。该列表必须覆盖解决问题所需的全部必要步骤，避免无关任务，并遵循一条清晰且可理解的、通向最终目标的推进过程。

在初始轮次以及后续轮次中，对话验证器评估所生成的用户提示。每条提示都必须与原始基准 issue 保持一致，遵循所定义的子任务轨迹，匹配被指派的用户角色，并且对 Agent 而言是可理解、可执行的。

对于每一个验证步骤，对话验证器都返回一个布尔值，表明所生成的输出是否有效。如果某项输出被认为无效，验证器还会另外提供一条理由，解释该输出为什么不满足要求，以及可以如何改进。该反馈在验证循环中被用来再次提示用户模拟器，使其重新生成一份改进后的输出。这一过程持续进行，直到验证器批准所生成的提示。一旦通过验证，该提示就被发送给 Agent，由 Agent 执行所请求的任务，并把其回应返回给用户模拟器，以便进入下一个交互周期。

3.3 任务完成评估器

任务完成评估器评估软件工程 Agent 的性能，并提供定量指标，以实现全面评测。当达到最大轮次数，或者用户模拟器判定对话已经完成时，它就会被执行。任务完成评估器利用原始基准的执行环境，来核验所分配的任务是否已经成功完成，并计算总体成功率。评测完成之时，SWE-DIVE 会提供一份全面的性能摘要，包括对话轮次的平均数量，以及对这些交互的详细分析。此外，评测指标可以依据被指派的用户角色来分析，从而能够比较 Agent 在不同交互场景下的性能。SWE-DIVE 还能够依据所需轮次数进行筛选，从而洞察 Agent 在真实的多轮软件工程任务中的效率与行为。

4 提议的评测计划

该框架使用 Harbor (Harbor Framework Team,, 2026) 实现，并在完全 Docker 化的环境中运行。作为初始的用户模拟器模型，我们使用 gemini-3.6-flash (Google,, 2026)，而 gemini-2.5-flash-lite (Google, 2025b,) 被用作验证模型。我们目前支持四种编码 Agent：OpenHands (Wang et al.,, 2025)、OpenCode (OpenCode,, 2026)、Pi agent (Zechner,, 2026)，以及 GitHub Copilot (GitHub,, 2026)。

我们的初步评测包括：对一项代表性任务在全部三种人格上所做的定性分析，并辅以在每种人格上额外 10 项任务的一次初始定量试点运行，以获得早期洞察。结果与源代码可在我们的 GitHub 仓库中获得。

在未来工作中，我们计划评测不同的轻量开源模型，以研究它们之间的性能差异，并确定它们是否能够有效处理这类交互式编码任务。我们还将比较三种不同用户人格的性能：专家吹毛求疵者、含糊请求者，以及改变主意者。

我们的实验将使用 SWE-bench Verified 与 Terminal-Bench 任务，二者都受 Harbor 框架支持。一般而言，Harbor 所支持的全部基准都与 SWE-DIVE 兼容，并且可以用相对较少的工作量加以集成。目前，主要局限在于我们把 Git diff 用作用户模拟器的输入，以便它评估 Agent 的进展。要使某个基准能够直接用于我们的框架，这一信息必须可用；否则，基于 Git diff 的方法就需要被该基准所提供的某种替代进展信号所替换。

我们预期，由于这些人格的行为各不相同，我们的实验将产生不同的性能结果。专家吹毛求疵者清楚地传达他们想要完成的事情，留给解释的余地更小，从而使编码 Agent 更容易识别并实现所需的更改。相比之下，含糊请求者提供的指令不那么精确，而改变主意者则会在整个交互过程中引入不断变化的需求。

除通过/失败状态之外，Agent 开发者还需要了解某一种特定的交互风格是否会导致浪费性的更改或回归，例如不必要的大规模重写。因此，我们把浪费形式化为：对相应黄金运行中未被修改的文件所做的修改，以及与黄金运行相比额外花费的 token。我们把回归定义为：在 Agent 的更改之后失败、但此前一直通过的测试。基于这些定义，我们假设，与基线 SWE-Bench issue 相比，不同的用户人格将导致不同程度的浪费与回归。

此外，我们有兴趣把 SWE-DIVE 的性能与原始基准结果进行比较。通过多轮交互把一项任务分解为更小的子任务，有可能提升 Agent 的性能，并使该基准不那么具有挑战性。这也是我们选择评测较小的模型，而不是那些已经在原始基准上表现非常好的最先进顶尖模型的原因之一。这使我们能够更好地研究：交互式设定本身是否提供性能优势，以及不同模型如何回应由多轮交互所引入的额外复杂性。

4.1 定性轨迹分析

图 2：一项定性案例研究说明了每种 SWE-DIVE 人格所引出的不同行为。

为了在实践中展示 SWE-DIVE，我们使用一项 SWE-bench Verified (Jimenez et al.,, 2024) 任务（astropy-12907）对 Agent 轨迹进行定性评测；图 2 说明了结果。该任务针对的是 separability_matrix 函数中的一个缺陷，该函数不能正确地为嵌套的 CompoundModels 计算可分离性。我们使用以 gemini-2.5-flash (Google, 2025a,) 为底层模型的 OpenCode, (2026) Agent 来运行 SWE-DIVE。我们使用三种人格——专家吹毛求疵者、含糊请求者与改变主意者——来评测该 Agent，从而得到三段用户与 Agent 的对话（参见图 3–5）。我们将其与未使用 SWE-DIVE 的基线 Agent 进行了比较；在该比较中，Agent 以一个单文件、单行的补丁解决了任务，与黄金解决方案相吻合。

三次运行各自展现出一种并未被基线运行所行使的不同行为。该 Agent 在专家吹毛求疵者与改变主意者两种人格下都成功解决了该 issue，而含糊请求者人格则使该 Agent 修复了预期的 issue，但同时也引入了额外更改，导致 10 个此前通过的测试失败。

在专家吹毛求疵者下，该 Agent 在四轮之内解决了该 issue。然而，用户模拟器在该 Agent 的实现中识别出两个真实问题：代码被添加到了错误的文件中，并且代码里还残留着一处无关的遗留更改。用户模拟器对现有实现提供了小而范围明确的修正，然后停止，从而得到一次成功的解决。因此，这一设定所测试的，是单轮基线中所没有的一种行为：该 Agent 能否正确地回应精确的评审反馈，并从实现上的弯路中恢复过来。含糊请求者在整个交互过程中维持高层提示，并不提供详细的代码级指导，这符合该人格的设定意图。然而，这些请求的开放式性质导致该 Agent 进行了一次大幅度重写。尽管预期的缺陷被成功修复，额外的更改却导致此前通过的测试失败。因此，该 Agent 实现了预期的修复，但由于该人格含糊的请求，引入了无关的回归与更改。最后，改变主意者人格也使该 Agent 成功解决了该 issue。在这一情形中，被模拟的人格在交互期间改变了自己所偏好的实现策略，要求该 Agent 在继续朝着原始目标工作的同时调整自己的方法。

这一案例研究展示了 SWE-DIVE 如何在次优用户人格下测试该 Agent 的行为——不同的交互风格可能导致显著不同的 Agent 行为，并且 SWE-DIVE 能够以回归和被浪费的 token 来量化这些影响。在这个例子中，该 Agent 似乎在含糊请求者人格下比在引导更为明确的人格下更为吃力。然而，这些观察基于单项任务和少量运行，需要进一步研究，才能确定这一行为是否能够跨任务与 Agent 泛化。

4.2 定量结果

表 1：三种被评测角色在 11 次运行上的结果摘要，以及不进行多轮对话时原始任务的性能。已解决报告已完成任务的数量；通过目标测试报告全部测试从失败转为通过的运行次数；失败的回归测试报告至少有一项测试从通过转为失败的次数。$\phi$ 轮次表示每项任务的平均 Agent 轮次数。$\Delta$ Token 显示相对于基线运行，输入/输出 token 平均数量的变化。$\Delta$ 文件显示相对于真值补丁，被读取/编辑文件的平均数量的变化。

为了初步了解不同人格如何影响 Agent 的行为与性能，我们另外抽样了 10 项任务，并使用与第 4.1 节所述相同的实验设置运行 SWE-DIVE，从而共计评测 11 项任务。对于每项任务，我们都评测了全部三种人格，并另外进行了一次基线运行；在该运行中，Agent 收到的是原始任务描述，而不进行任何多轮交互。

如表 1 所示，三种人格取得了相近的成功率，其中专家吹毛求疵者与改变主意者的表现略好于含糊请求者。

所有运行也都出现了回归，这表明这些 Agent 引入了不必要的更改，导致此前通过的测试失败。尽管目标测试在专家吹毛求疵者与改变主意者的两个案例中、以及在含糊请求者的一个案例中从失败转为通过，额外的更改仍在现有测试套件中引入了回归。因此，这些案例代表的是潜在的成功修复，但由于超出目标 issue 的更改，它们仍然伴随回归。表 2–5 提供了失败测试的详细概览，并指出该 Agent 在何时引入了回归。

总体而言，改变主意者展现出最低的回归率，11 项任务中有 4 项出现回归，而专家吹毛求疵者与含糊请求者都在 11 项任务中的 5 项上导致了回归。交互轮次数在各人格之间也略有不同。改变主意者平均需要的用户请求数量最多，而含糊请求者需要的最少。然而，尽管含糊请求者通常需要更少的轮次，它在一次运行中达到了所允许的最大轮次数。

除任务成功之外，这些人格还使我们能够评估由多轮交互产生的臃肿，其衡量方式是 token 用量的增加，以及对代码库所做的无关更改。尽管提交了多个轮次，所有人格相对于基线都展现出更高的 token 用量。对于改变主意者与含糊请求者二者，该 Agent 相对于基线读取并写入了更多文件，而专家吹毛求疵者则导致文件用量下降。总体而言，含糊请求者既有最低的通过率，又有最多的无关文件读取，尽管它使用的轮次最少。它在三种人格中也展现出最小的 token 用量增幅。

5 讨论

我们的初步结果展示了 SWE-DIVE 基准在实践中可以如何使用。这些结果揭示，不同的用户人格能够显露出不同的失败模式与稳健性属性；如果只通过单轮交互或单一交互风格来评测一个 Agent，这些模式与属性就会被遗漏。

由于 Harbor 框架 (Harbor Framework Team,, 2026) 中实现了多种多样的基准，这种用户模拟能够支持多种多样的使用场景。此外，它支持改编自真实世界用户、并受到 SWE-Chat (Baumann et al.,, 2026) 启发的多样用户角色。我们定义三种用户角色——专家吹毛求疵者、改变主意者与含糊请求者——它们在用户如何传达需求、提供反馈，以及在整个交互过程中如何演化其目标方面有所不同。这些角色提供了锚定于所观察到的真实用户交互的受控行为变异。虽然这种多样性决定了基准中所代表的用户行为范围，模拟的保真度取决于这些行为在多大程度上反映真实的用户交互。

SWE-DIVE 旨在通过把用户建模为交互式参与者、而不是静态的提示生成器，来提升保真度。用户模拟器以该 Agent 的最新回应和代码更改为条件来生成每一轮，从而使被模拟的用户能够在交互展开时提供修正、引入后续需求，或修改自己的请求。这些交互锚定于经过验证的基准任务以及底层的用户行为，使用户模拟器能够在采用所定义用户角色之一的同时，在多轮环境中运作。把 SWE-DIVE 轨迹与留出的人类 SWE-Chat 轨迹进行直接比较，仍然是未来工作的一个重要方向。

除保真度之外，被模拟用户与该 Agent 之间的交互也提出了一个关于效度的重要问题：使用不同的被模拟用户，是否会影响从一次评测中得出的结论。定性轨迹提供了一个初步迹象，表明情况可能确实如此。在同一项 Astropy 任务上，不同的被模拟用户行为导致了不同的 Agent 轨迹与结果：含糊请求者诱发了更广泛的更改并引入了回归，而专家吹毛求疵者则通过有针对性的修正，引导该 Agent 走向成功解决。这些结果表明，被模拟用户的行为可以影响一个 Agent 被观察到的性能，并因此影响从该评测中得出的结论。

6 结论

本工作为编码 Agent 引入一个新基准，它把当前各类编码 Agent 基准的多样性扩展到带有不同用户人格的多轮设定。它采用一个用户模拟器，该模拟器以某个特定角色与编码 Agent 通信，以引导其完成任务。我们在 11 项任务上的初步评测表明，SWE-DIVE 有效地诱发了不同的交互行为，揭示了不受约束或不断变化的用户需求如何导致更高的代码回归率。

致谢

作者使用了 ChatGPT、Grammarly、GitHub Copilot 和 Claude Code，以获得语言、语法与编码方面的支持。所有内容均经过作者审阅并核实。

参考文献

• Baumann et al., (2026)

Baumann, J., Padmakumar, V., Li, X., Yang, J., Yang, D., and Koyejo, S. (2026).

Swe-chat: Coding agent interactions from real users in the wild. Swe-chat：真实用户在实际环境中与编码 Agent 的交互。

arXiv 预印本 arXiv:2604.20779。

• Brehme et al., (2026)

Brehme, L., Dornauer, B., Böttcher, J.-H., Schmid, K., Racasan, M.-C., and Breu, R. (2026).

Rag-dive: A dynamic approach for multi-turn dialogue evaluation in retrieval-augmented generation. Rag-dive：一种面向检索增强生成中多轮对话评测的动态方法。

载于 Proceedings of the IEEE/ACM 5th International Conference on AI Engineering - Software Engineering for AI，CAIN ’26，第 74–84 页，New York, NY, USA。Association for Computing Machinery。

• Dhuliawala et al., (2023)

Dhuliawala, S., Komeili, M., Xu, J., Raileanu, R., Li, X., Celikyilmaz, A., and Weston, J. (2023).

Chain-of-verification reduces hallucination in large language models. Chain-of-verification 降低大语言模型中的幻觉。

• Garg et al., (2025)

Garg, S., Steenhoek, B., and Huang, Y. (2025).

Saving swe-bench: A benchmark mutation approach for realistic agent evaluation. Saving swe-bench：一种面向真实 Agent 评测的基准变异方法。

• GitHub, (2026)

GitHub (2026).

GitHub Copilot. GitHub Copilot。

https://github.com/features/copilot (https://github.com/features/copilot).

AI 驱动的编码助手。访问日期：2026-08-24。

• (6)

Google (2025a).

Gemini 2.5 flash. Gemini 2.5 flash。

• (7)

Google (2025b).

Gemini 2.5 flash-lite. Gemini 2.5 flash-lite。

• Google, (2026)

Google (2026).

Gemini 3.6 flash. Gemini 3.6 flash。

• Harbor Framework Team, (2026)

Harbor Framework Team (2026).

Harbor: A framework for evaluating and optimizing agents and models in container environments. Harbor：一个用于在容器环境中评测并优化 Agent 与模型的框架。

• Jimenez et al., (2024)

Jimenez, C. E., Yang, J., Wettig, A., Yao, S., Pei, K., Press, O., and Narasimhan, K. R. (2024).

SWE-bench: Can language models resolve real-world github issues? SWE-bench：语言模型能否解决真实世界的 github issue？

载于 The Twelfth International Conference on Learning Representations。

• Merrill et al., (2026)

Merrill, M. A., Shaw, A. G., Carlini, N., Li, B., Raj, H., Bercovich, I., Shi, L., Shin, J. Y., Walshe, T., Buchanan, E. K., Shen, J., Ye, G., Lin, H., Poulos, J., Wang, M., Nezhurina, M., Jitsev, J., Lu, D., Mastromichalakis, O. M., Xu, Z., Chen, Z., Liu, Y., Zhang, R., Chen, L. L., Kashyap, A., Uslu, J.-L., Li, J., Wu, J., Yan, M., Bian, S., Sharma, V., Sun, K., Dillmann, S., Anand, A., Lanpouthakoun, A., Koopah, B., Hu, C., Guha, E., Dreiman, G. H. S., Zhu, J., Krauth, K., Zhong, L., Muennighoff, N., Amanfu, R., Tan, S., Pimpalgaonkar, S., Aggarwal, T., Lin, X., Lan, X., Zhao, X., Liang, Y., Wang, Y., Wang, Z., Zhou, C., Heineman, D., Liu, H., Trivedi, H., Yang, J., Lin, J., Shetty, M., Yang, M., Omi, N., Raoof, N., Li, S., Zhuo, T. Y., Lin, W., Dai, Y., Wang, Y., Chai, W., Zhou, S., Wahdany, D., She, Z., Hu, J., Dong, Z., Zhu, Y., Cui, S., Saiyed, A., Kolbeinsson, A., Hu, J., Rytting, C. M., Marten, R., Wang, Y., Dimakis, A., Konwinski, A., and Schmidt, L. (2026).

Terminal-bench: Benchmarking agents on hard, realistic tasks in command line interfaces. Terminal-bench：在命令行界面中针对困难且真实的任务对 Agent 进行基准评测。

• Nijkamp et al., (2023)

Nijkamp, E., Pang, B., Hayashi, H., Tu, L., Wang, H., Zhou, Y., Savarese, S., and Xiong, C. (2023).

Codegen: An open large language model for code with multi-turn program synthesis. Codegen：一个面向代码、具备多轮程序合成能力的开放大语言模型。

ICLR。

• OpenCode, (2026)

OpenCode (2026).

OpenCode: The Open Source AI Coding Agent. OpenCode：开源 AI 编码 Agent。

https://opencode.ai (https://opencode.ai).

访问日期：2026-08-24。

• Orlanski et al., (2025)

Orlanski, G., Roy, D., Yun, A., Shin, C., Gu, A., Ge, A., Adila, D., Sala, F., and Albarghouthi, A. (2025).

SlopCodeBench: Benchmarking How Coding Agents Degrade Over Long-Horizon Iterative Tasks. SlopCodeBench：对编码 Agent 在长程迭代任务中如何退化进行基准评测。

arXiv:2603.24755 [cs.SE].

• Vijayvargiya et al., (2025)

Vijayvargiya, S., Zhou, X., Yerukola, A., Sap, M., and Neubig, G. (2025).

Interactive agents to overcome ambiguity in software engineering. 用于克服软件工程中含糊性的交互式 Agent。

• Wang et al., (2026)

Wang, S., Wang, Z., Ma, D., Yu, Y., Ling, R., Li, Z., Xiong, F., and Zhang, W. (2026).

CodeFlowBench: A Multi-turn, Iterative Benchmark for Complex Code Generation. CodeFlowBench：一个面向复杂代码生成的多轮迭代基准。

arXiv:2504.21751 [cs.SE].

• Wang et al., (2025)

Wang, X., Li, B., Song, Y., Xu, F. F., Tang, X., Zhuge, M., Pan, J., Song, Y., Li, B., Singh, J., Tran, H. H., Li, F., Ma, R., Zheng, M., Qian, B., Shao, Y., Muennighoff, N., Zhang, Y., Hui, B., Lin, J., Brennan, R., Peng, H., Ji, H., and Neubig, G. (2025).

OpenHands: An Open Platform for AI Software Developers as Generalist Agents. OpenHands：一个将 AI 软件开发者作为通才 Agent 的开放平台。

载于 International Conference on Learning Representations。

• Yang et al., (2023)

Yang, J., Prabhakar, A., Narasimhan, K., and Yao, S. (2023).

Intercode: Standardizing and benchmarking interactive coding with execution feedback. Intercode：借助执行反馈对交互式编码进行标准化与基准评测。

• Zechner, (2026)

Zechner, M. (2026).

Pi: A Minimal Terminal Coding Agent. Pi：一个极简的终端编码 Agent。

https://github.com/badlogic/pi-mono (https://github.com/badlogic/pi-mono).

访问日期：2026-08-24。

• Zhou et al., (2026)

Zhou, X., Chen, V., Wang, Z. Z., Neubig, G., Sap, M., and Wang, X. (2026).

TOM-SWE: User Mental Modeling For Software Engineering Agents. TOM-SWE：面向软件工程 Agent 的用户心智建模。

arXiv:2510.21903 [cs.SE].

附录 A 定性的智能体对话

图 3：SWE-DIVE 中采用固定模糊请求者角色的代表性多轮轨迹

图 4：SWE-DIVE 中采用固定专家吹毛求疵者角色的代表性多轮轨迹。

图 5：SWE-DIVE 中采用固定改变主意者角色的代表性多轮轨迹。

附录 B 详细结果

表 2：使用专家吹毛求疵者的 11 次运行结果。已解决表示该任务是否已成功完成。由失败到通过报告因智能体的改动而从失败转变为通过的测试数量，而由通过到失败报告原先通过、后来变为失败的测试数量。轮次表示完成该任务所需的智能体轮次数，而任务标识所评测的任务。

表 3：使用改变主意者的 11 次运行结果。已解决表示该任务是否已成功完成。由失败到通过报告因智能体的改动而从失败转变为通过的测试数量，而由通过到失败报告原先通过、后来变为失败的测试数量。轮次表示完成该任务所需的智能体轮次数，而任务标识所评测的任务。

表 4：使用模糊请求者的 11 次运行结果。已解决表示该任务是否已成功完成。由失败到通过报告因智能体的改动而从失败转变为通过的测试数量，而由通过到失败报告原先通过、后来变为失败的测试数量。轮次表示完成该任务所需的智能体轮次数，而任务标识所评测的任务。

表 5：使用不含多轮行为的基础任务的 11 次运行结果。已解决表示该任务是否已成功完成。由失败到通过报告因智能体的改动而从失败转变为通过的测试数量，而由通过到失败报告原先通过、后来变为失败的测试数量。轮次表示完成该任务所需的智能体轮次数，而任务标识所评测的任务。