交接债务：编码代理接管中断任务时的重新发现成本

# 交接负债：编码代理接管中断任务时的重新发现成本
来源：https://arxiv.org/html/2606.02875
Dipesh KC1，Anjila Budathoki2

1独立研究员，2佐治亚州立大学 通讯作者：kcdipesh429@gmail\.com (https://arxiv.org/html/2606.02875v1/mailto:email@domain)

###### 摘要

编码代理基准测试评估的是单个不被中断的代理能否解决仓库问题。真实的软件开发工作要杂乱得多：任务会被中断、重新分配、审查，并从另一个代理或工程师留下的部分状态恢复。我们通过*交接负债*来研究这个缺失的维度：当前任的工作不透明或不完整时，强加给后任的重新发现成本。我们的接管协议在确定性的交接点中断编码代理，冻结仓库，并在四种交接视图下评估后继代理：仅仓库状态、原始追踪、摘要笔记和结构化笔记。在75个源任务中，该协议生成了181个交接点任务和每个后继模型724次接管运行。在三个后继模型上，相对于仅仓库的接管，带有上下文的交接将中位代理事件减少了20–59%，累计提示词令牌减少了42–63%。解决率的影响较小且依赖于模型，但效率提升是一致的。这些发现表明，编码代理的评估不仅应报告任务是否解决，还应报告该工作对于另一个代理来说恢复的成本有多高。

交接负债：编码代理接管中断任务时的重新发现成本

Dipesh KC1，Anjila Budathoki2
1独立研究员，2佐治亚州立大学
通讯作者：kcdipesh429@gmail\.com (https://arxiv.org/html/2606.02875v1/mailto:email@domain)

## 1 引言

近期的软件工程基准测试通过询问给定一个仓库问题，代理能否生成通过官方测试的补丁，使编码代理变得可测量。这种抽象对于在真实仓库上评估代理来说是有效且可重复的（Jimenez等人，2024 (https://arxiv.org/html/2606.02875#bib.bib1)；Yang等人，2024 (https://arxiv.org/html/2606.02875#bib.bib2)）。然而，这种抽象遗漏了一个常见的真实世界情况：*接管*，即一个代理继承了另一个被中断的仓库，必须重建哪些被更改、哪些已尝试过、以及哪些中间产物可以信任。在这种交接中，部分工作只有在后继能够充分理解它以从中恢复时才有价值。

我们将这种成本称为*交接负债*，并引入一种协议来衡量它。当代理取得了可见进展，但留下的状态导致后任无法轻易继续时，交接负债就产生了。例如，未解释的编辑、临时文件、隐藏的假设或缺失的验证证据。仅基于最终解决的指标无法区分代价高昂的重新发现和高效的延续。两个前任代理可能留下相同的检查点仓库，但它们的后任可能面临截然不同的继续成本：一个可能立即继续，而另一个必须花费大量工具交互来从临时文件和不完整的命令历史中重新发现意图。

我们使用SWE-bench Verified（Jimenez等人，2024 (https://arxiv.org/html/2606.02875#bib.bib1)；Chowdhury等人，2024 (https://arxiv.org/html/2606.02875#bib.bib8)）在OpenHands风格的编码代理环境（Wang等人，2025 (https://arxiv.org/html/2606.02875#bib.bib3)）中进行实验。一个前任代理开始一个源任务。我们在可观察的交接点中断代理：*首次源代码编辑之后*、*首次验证结果之后*或*首次失败后编辑之后*。每个交接点成为一个接管任务，在该任务中，后任从相同的检查点仓库在四种交接视图下恢复，即关于前任所做工作的四种上下文格式。

这四种视图在后任接收的前任上下文数量上有所不同。*仅仓库*询问仅文件系统状态是否足够。*原始追踪*暴露前任事件日志，但它庞大、非结构化且无边界。*摘要笔记*测试自由格式的压缩是否能从追踪中保留意图和证据。*结构化笔记*测试固定延续契约是否能使交接变得有界且可审计。核心问题是：

*哪种交接视图能让后继代理正确且高效地恢复中断的编码工作？*

图1 (https://arxiv.org/html/2606.02875#S1.F1) 总结了由此产生的评估架构。我们的贡献如下：

图1：交接负债评估架构。前任在中断前产生仓库状态和轨迹证据。在检测到的交接点，检查点仓库被固定，同时后任接收四种交接视图之一。最终状态通过官方SWE-bench验证和效率指标（包括代理事件和提示词令牌）进行评分。

- • 我们将*交接负债*形式化为编码代理接管的一个可测量属性，捕捉继承部分工作的成本。
- • 我们引入了一个接管协议，将SWE-bench Verified任务转换为交接点任务，每个任务在多种交接视图下进行评估。
- • 我们在固定检查点仓库的同时比较四种交接视图，隔离交接视图的效果。
- • 我们提出了一种结构化交接模式，作为有界的延续契约，具有用于更改文件、验证证据、不确定性、回滚风险和验证的固定字段。
- • 我们表明，前任上下文主要减少重新发现工作，即使在解决率提升不大的情况下，也显著减少了中位代理事件和提示词令牌。

## 2 问题设置

### 2.1 交接负债

我们使用*前任*来指代开始任务的代理，使用*后任*来指代在中断后恢复任务的代理。*交接*是它们之间部分工作状态的转移，后任的继续情节称为*接管*。设前任代理AA在任务xx上操作，并到达中间检查点tt。检查点包含仓库状态sts\_\{t\}和前任轨迹τ≤t\\tau\_\{\\leq t\}，包括中断前观察到的命令、文件编辑、观察结果、验证结果和模型消息。我们稍后以*代理事件*（OpenHands轨迹记录，包括LLM动作和工具观察结果）来衡量后任的工作量。后继代理BB接收原始任务提示、检查点仓库sts\_\{t\}以及从τ≤t\\tau\_\{\\leq t\}的某个子集或转换派生的交接视图hth\_\{t\}。

如果BB产生一个最终仓库状态，该状态被SWE-bench框架官方解决，即修补后的仓库通过官方验证，则接管成功。交接负债是由不足的交接视图引起的额外后任工作量。在我们的实验中，这个工作量通过代理事件和累计提示词令牌来量化，而官方验证则检查接管是否解决了任务。在继续过程中，负债可能表现为重复验证、冗余文件检查、回归或对前任意图的歧义。

这个交接负债的定义将可恢复性与原始模型能力分开。一个强大的后继代理可能在没有前任上下文的情况下解决任务，但仅在重建状态之后。一个较弱的后继代理即使在有良好交接的情况下也可能失败。我们的主要比较隔离了交接格式的效果。我们固定前任、交接点、仓库状态和后继模型，仅改变交接视图。

### 2.2 交接点检测

我们从可观察的前任事件中确定性地导出交接点，而不是从官方解决方案中导出。一个交接点只有在具有检查点仓库状态、事件边界和预计算的交接视图记录（在第3节 (https://arxiv.org/html/2606.02875#S3) 中定义）时才合格。这些合格规则使得协议仅使用交接时可用的日志就可实现。

当前的交接点类型是：

*首次源代码编辑之后*：前任进行的第一次非测试源代码编辑；

*首次验证结果之后*：源代码编辑后第一次观察到的验证、构建、lint或测试结果；

*首次失败后编辑之后*：第一次观察到的失败验证结果后进行的第一次源代码编辑

并非所有前任运行在完成或超时前都经历验证失败。在我们的选定池中，75个源任务中有31个包含合格的失败后编辑交接点。

我们对选定的源任务运行所有检测到的交接点，而不是仅选择有希望或失败的状态。因此，我们的比较是在交接点上进行的，而不仅仅是原始的SWE-bench问题。

### 2.3 交接状态

我们使用交接状态来区分两种可能共享相同最终已解决标签的接管情况：完成未解决的工作和保持已经正确的工作。因此，我们在接管前标记检查点仓库的状态。我们将这些标签称为*交接状态*，它们描述了后任在交接点接收到的仓库状态。

#### *需要完成*。

检查点仓库未解决，成功的接管能解决它。

#### *已解决；保持*。

检查点仓库已解决，成功的接管使其保持解决状态。

#### *现有行为被破坏*。

这个罕见的诊断类包含10个实例，仅用于诊断分解。检查点仓库未能通过前任编辑前通过的测试，成功的接管必须在没有保留该回归的情况下修复任务。

## 3 交接上下文格式

每次接管运行都从相同的检查点仓库sts\_\{t\}和原始任务提示开始。干预因素是交接视图hth\_\{t\}，即给予后任的前任上下文。以下四种格式仅在它们暴露或压缩的前任轨迹τ≤t\\tau\_\{\\leq t\}的数量上有所不同。

#### *仅仓库*。

后任接收检查点仓库和原始任务提示，但没有明确的前任历史。这种条件仍然是一种交接，但仅将文件系统状态转移给后任。它衡量了前任的进展中有多少可以仅从代码中恢复。

#### *原始追踪*。

后任接收截至检查点的前任事件追踪，并标记为历史上下文。这种条件最大化可观察信息，包括命令、观察结果、编辑和失败的尝试。它是可用上下文的上限，但不是可扩展的文档记录策略。

#### *摘要笔记*。

后任接收从检查点之前的前任事件时间线生成的自然语言笔记。一个前任代理（不是后任）在接管开始前从事件日志生成这些笔记。这种格式测试了自由格式压缩是否能在不暴露每个事件的情况下保留足够的意图和证据。

#### *结构化笔记*。

后任接收一个简洁的结构化交接笔记，使用预定义字段记录恢复任务所需的信息。一些字段从检查点元数据和日志中确定性地填充，包括更改的源文件、非源代码产物、最新源代码更改、最新验证命令和交接状态。前任代理仅使用前任可观察的证据（如原始问题、事件日志、命令输出和检查点仓库状态）来填写剩余字段。

接管提示将交接文本呈现为历史证据而非基本事实，并指示后任在依赖它之前检查并验证仓库。在附录B (https://arxiv.org/html/2606.02875#A2) 中，我们提供了笔记生成设置，而附录C (https://arxiv.org/html/2606.02875#A3) 展示了提示模板、完整模式以及一个示例结构化交接摘录。

## 4 实验设计

### 4.1 源任务和交接任务

我们从SWE-bench Verified任务开始（Jimenez等人，2024 (https://arxiv.org/html/2606.02875#bib.bib1)；Chowdhury等人，2024 (https://arxiv.org/html/2606.02875#bib.bib8)）。我们保留15分钟–1小时和1–4小时难度等级，创建种子为20260430的固定随机顺序，并使用前75个源任务。这些等级足够长，可以产生有意义的交接点，同时使完整的接管评估可行。接管基准测试比源任务数量大，因为每个前任轨迹可以产生多个确定性交接点，并且每个交接点都在四种视图下进行评估。选定的75个源池产生了181个交接点任务和每个后继模型724次接管运行（跨四种视图），即跨三个后继模型共计2,172次接管运行。由此产生的基准测试构建总结在表1 (https://arxiv.org/html/2606.02875#S4.T1) 中。

阶段分解计数
源任务 SWE-bench Verified 75
前任运行 Qwen 75
交接点 *首次源代码编辑之后* 75 *首次验证结果之后* 75 *首次失败后编辑之后* 31 总交接点 181
交接状态 *需要完成* 110 *已解决；保持* 61 *现有行为被破坏* 10 总状态标记交接点 181
交接视图 *仅仓库* 1 *原始追踪* 1 *摘要笔记* 1 *结构化笔记* 1 每个交接点视图数 4
接管运行 181个交接点 × 4个视图 = 724/模型
总接管运行 724/模型 × 3个后继 = 2,172

表1：接管基准测试的构建。选定的75个任务池扩展为181个交接点，跨三个后继模型共2,172次接管运行。

### 4.2 运行时

我们使用OpenHands风格的编码代理环境（Wang等人，2025 (https://arxiv.org/html/2606.02875#bib.bib3)），具有终端操作、文件编辑、在交接点冻结仓库以及官方SWE-bench验证。提供者原生的工具调用被禁用，但模型仍然通过OpenHands的文本动作协议使用工具，这保持了跨后继的工具接口一致性，同时保留了一个真实的完整代理运行时。

### 4.3 模型

在主要研究中，所有交接点来自Qwen前任运行。这固定了前任分布，使得主要干预是后任的交接视图。我们评估Qwen、Gemma和Devstral后继。111模型页面：Qwen/Qwen3.6-27B (https://huggingface.co/Qwen/Qwen3.6-27B)，google/gemma-4-31B-it (https://huggingface.co/google/gemma-4-31B-it)，以及mistralai/Devstral-Small-2-24B-Instruct-2512 (https://huggingface.co/mistralai/Devstral-Small-2-24B-Instruct-2512)。所有模型通过兼容OpenAI的本地端点提供服务，确保跨后继的运行时协议一致。

我们评估Qwen到Qwen、Qwen到Gemma以及Qwen到Devstral的接管对。跨模型接管测试了当后继改变时交接效果是否持续。我们不将这些条件解释为模型排行榜，因为干预因素是交接格式，而不是模型选择。

### 4.4 验证与指标

我们对每个交接视图使用相同的评分程序。主要结果是接管后的官方SWE-bench解决情况。主要成本指标是累计提示词令牌和代理事件，它们衡量后任在收到交接后需要多少交互。我们在附录B (https://arxiv.org/html/2606.02875#A2) 中详细说明了运行时限制和笔记生成设置。

## 5 结果

带有上下文的交接在所有三个后继上都降低了重新发现成本。关键模式是上下文对工作量的帮助大于对最终解决的帮助：它显著减少了重新发现工作，而解决率的提升较小且不太一致。一个仅仓库的后任会接收到相同的