为什么AI难以接手未完成的任务

尽管AI智能体能够解决复杂任务，一项新研究却表明，它们难以继续其他人已经开始的工作，因而产生重复劳动、进展放缓和成本增加。

与AI智能体及其界面打交道时，一项既令人疲惫又不可或缺的工作，就是几乎每次交流开始时都要先向AI交代当前情况。

虽然 ChatGPT 等常用语言模型能够在一定程度上使用 持久保存的个性化记忆，但这一功能的表现时好时坏。归根结底，通常还是花些力气向AI解释任务背景*更稳妥，至少可以防止模型根据训练形成的 潜在空间 猜错上下文。

接手现实世界中遗留的工作

当然，这个难题在AI出现之前就已存在。许多公司早已要求员工记录自己开发或改进的流程，部分原因是方便新员工入职熟悉工作，但也可以说是为了防止员工获得更强的议价能力。

然而在实践中，往往只有规模较大、资金更充裕的组织才真正创建、更新并维护文档。需要接手他人工作的员工却经常不得不扮演侦探，必须 耐心重建事件发生的时间线，才能弄清如今交给自己的未完工作是如何形成的。

毋庸置疑，完善的文档能够节省数天、数周乃至数月的工作，前提是编写文档在经济上划得来。

但如果任务由AI智能体执行，解决这个问题或许有更大的空间。

交接

一篇来自美国的新研究论文量化了这种缺乏文档带来的负担，并将问题称为 交接债务。

如果 技术债务 指的是今天快速、草率且廉价的技术方案导致未来系统脆弱或难以维护的现象，那么 交接债务 描述的就是 重新摸索 的成本，即根据留下的线索重建某位工作人员或其他实体的操作步骤。对方可能无法提供建议，例如因不欢而散的解雇、太忙或已经去世；也可能没有能力再提供建议，例如某个大语言模型早已丢失了形成当前工作状态的上下文。

这篇 新论文^† 由独立研究人员和与佐治亚州立大学有关联的研究人员合作完成，考察了交接债务在 编程智能体中的表现。这类智能体需要在代码库中接着另一个会话、人员或实体停下的地方继续工作。

研究目标之一是确定减少交接债务需要多少文档，以及未来可以推荐哪些程序和协议作为标准做法，以尽量减轻这个问题。

预算问题

在理想情况下，可以 将日志记录设置为 详细模式（verbose），然后直接把未完成任务的日志交给新接手任务的智能体。

然而，从如此庞大的数据中提取有用信息既耗时，又会消耗token预算，还可能受到存储空间的限制。

这确实是一个预算问题：处理原始数据转储非常费力，而筛选整理过的日志虽然更容易理解，却需要预先投入资源。

专门编写的交接笔记能够有效帮助接手者了解情况，但需要更多前期工作。如果任务的逻辑最终一目了然，或者工作被放弃、此后从未再修改，这些投入可能根本用不上。

新论文 Handoff Debt: The Rediscovery Cost When Coding Agents Take Over Interrupted Tasks的作者考虑了所有这些情形，并调整现有任务模型，以新的方式量化和处理交接债务。虽然研究专门针对编程智能体，但也可能为更广泛的AI应用和文档政策的组织实施指明有用方向。

作者指出：

“当智能体取得了可见进展，却留下继任者难以继续的状态时，就会产生交接债务，例如未作解释的修改、临时工作文件、隐含假设或缺少验证证据。

“只根据最终是否解决任务来衡量，无法区分代价高昂的重新摸索与高效的继续工作。

“两个前任智能体可能留下相同的代码库检查点，但继任者面对的继续工作成本可能截然不同：一个可以立即继续，另一个却必须进行多次工具交互，从临时文件和不完整的命令历史中重新摸索原本的意图。”

方法

作者将 前任 定义为此前的智能体，即最初开展工作或最后执行工作的智能体；将 继任者 定义为当前负责接手工作的智能体。

为了构建一个衡量智能体之间转交未完成软件工程任务之成本的基准，研究人员将 SWE-bench Verified 中的75个任务转化为181个 交接场景 ，每个场景对应一个工作被中断并移交给继任智能体的时点。随后，研究人员使用三种不同的继任模型，开展了2,172次接手尝试。

这些交接测试采用以下模型家族，并将它们按不同组合配对： Qwen、Gemma 和 Devstral。

实验考察了四个层级的继承信息。在限制最严格的条件下，继任者只收到代码库状态，等于走进一个没有文档说明的“灾难现场”。其他条件则提供越来越详尽的上下文，从活动记录和命令历史，到概述已尝试方法及已获知信息的简短摘要：

研究不只关注任务最终是否解决，而是旨在衡量 继续工作本身的成本，重点考察工具使用、token消耗，以及重建此前工作背后推理所需的努力。

实验定义了三种 交接触发时点 和三种 交接状态：

数据和测试

为构建贴近实际的交接场景，作者从SWE-bench Verified中抽取75个软件工程任务建立基准，重点关注通常需要15分钟至4小时才能解决的问题。

研究人员不只评估已完成的任务，还在工作过程中记录多个中间检查点，从而构造出一个AI智能体必须接手另一个智能体工作的情形：

接手任务基准的构建。75个SWE-bench Verified任务被扩展为181个交接点，覆盖三个工作阶段；这些交接点按接手时的代码库状态标记，并在四种信息共享条件下进行评估，共产生2,172次继任智能体接手任务的运行。 来源

由于每个任务都可能产生多个交接点，每个交接点又使用四种形式的继承信息测试，基准迅速扩大。最终数据集包含181个不同的交接任务，每种继任模型接受724次接手评估，三个受测AI系统合计运行2,172次。

编程测试使用 OpenHands 风格的智能体环境，支持终端操作、在交接点冻结代码库、编辑文件以及SWE-bench官方验证。

在主研究中，所有交接点均来自Qwen担任前任智能体的运行，以便在固定起点上比较不同智能体组合和场景的差异。

测试的配对为Qwen → Qwen、Qwen → Gemma以及Qwen → Devstral。

原始记录 对继任者工作量的削减最大，使智能体事件数减少57–59%； 摘要笔记 和 结构化笔记 使事件数减少20–46%。三种方式的输入token使用量也都下降，降幅为42–63%：

在仅代码库交接条件下，继任智能体需要进行额外交互，重建前任的意图、此前的证据和失败的方法。 原始记录、摘要笔记 和 结构化笔记 直接传递了部分信息，减少了重新摸索的需要，但也需要更长的初始提示词。

为检验收益是否真实，研究人员将每次上下文更丰富的交接，与从同一检查点开始的仅代码库交接进行配对比较。在所有模型配对中，更丰富的交接上下文都稳定减少了继任者的工作量。

完整的事件记录使工作量降幅最大，摘要笔记和结构化笔记也带来显著节省。这种效果出现在整个基准中，并非由少数异常案例造成：

为了确认效果并非由少数异常案例造成，研究人员将每次交接与从同一检查点开始的仅代码库交接进行比较。在所有模型配对中，降幅都保持一致，说明收益呈现了有意义的规律，而非只是几个例外。

主要启示…

简而言之^†，作者发现，当一个AI智能体把任务交给另一个智能体时，即使简单笔记也能帮助后者更高效地继续工作。

完整的事件记录效果最好，但任何交接信息都比让继任者仅凭代码重建一切更好；上述结果也表明，采用完整原始日志的方式必然具有更高的token成本。

结论

尽管论文本身专门面向同行研究人员，对普通读者的吸引力有限，这项新研究仍然触及当前人机界面与协议领域最有趣、最迫切的问题之一。

人们希望，这类探索开发的方法和获得的见解最终能推广到更广泛的AI使用场景，而不仅限于智能体编程。

未来还可以探索如何根据项目特点和用途，评估特定项目所需的最低文档量。然而，即使这种有助于合理安排时间和资金投入的功能，本身也要花费时间和资金。因此，文档工作面临的预算难题依然难以回避。

* 就我个人而言，对于因响应延迟和上下文过多而变慢的ChatGPT会话，我最近开始导出干净的对话PDF，虽然过程有些困难，再将其作为新会话的起点，成为“第2部分”。

^† 这不是我今年读过的最易懂的论文，因此我无法建议读者去阅读原论文，尽管经过梳理的结果仍然很有意思。

首次发布于 2026 年 6 月 3 日星期三