人工智能难以接手半成品任务的原因

尽管人工智能代理可以解决复杂任务，但一项新研究表明，他们难以继续由他人开始的工作，从而导致重复劳动、进度变慢和成本增加。

与人工智能代理和接口打交道中最令人筋疲力尽但又至关重要的任务之一，就是在每次交流开始时，人工智能需要“跟上进度”，几乎每次都需要这样做。

虽然像 ChatGPT 这样的流行语言模型提供了一些“持久”的自定义内存访问，例如 内存FAQ，但这种实现通常是偶然的；最终，为了避免人工智能“猜测”错误的上下文，还是更安全地接受为任务提供上下文的努力——至少可以防止人工智能从其训练的 潜在空间 中“猜测”错误的上下文。

解决现实世界中的松懈问题

这个挑战当然不是人工智能独有的；许多公司已经要求员工维护他们开发或改进的流程的文档（部分是为了更顺畅的入职，但也可以避免员工获得权力）。

然而，在实践中，通常只有较大且资金充足的组织才会承诺创建、更新和维护文档。相反，员工们经常被要求接手他人的工作，需要进行“侦探式”的任务，需要他们仔细地 还原时间线，以了解他们被分配的已放弃的工作的经过。

当然，完美的文档可以节省数天、数周甚至数月的工作——如果这在经济上是合理的，那就好了。

然而，在人工智能代理是相关操作员的情况下，可能有更大的潜力来解决这个问题。

交接

这份“无文档债务”的负担在一篇来自美国的新研究论文中被量化，论文将这个问题称为 交接债务。

如果 技术债务 是一种快速而简单（且廉价）的技术解决方案今天会导致未来的脆弱或难以维护的解决方案，那么 交接债务 就定义了 重新发现 的成本——这是对一个不再可用或无法提供建议的工作者或实体的步骤的法医重建（例如，敌对解雇、太忙、死亡等）。

这篇 新论文^† 是独立研究人员和佐治亚州立大学附属研究人员之间的合作，研究了交接债务如何应用于 编码代理，这些代理被要求在代码库中接手其他会话、人员或实体留下的工作。

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

预算问题

在理想世界中，可以 将日志设置为 详细，然后将与不完整任务相关的日志提供给新代理（接手任务的代理）。

但是，将如此大量的数据解析为有用的数据将既耗时又占用令牌预算，并且还会带来存储空间限制的问题。

这确实是一个预算问题，因为使用原始转储会耗尽资源，而使用精心策划的日志虽然不那么混乱，但需要事先投入资源。

适当的、专门的笔记将非常有效地使“接手者”快速上手，但这需要更大的努力投入——这种努力可能永远不会被需要，如果工作的逻辑最终被证明是自明的，或者如果工作被放弃或永远不会被修订。

这项新工作的作者，题为 交接债务：编码代理接手中断任务的重新发现成本，已经考虑了所有这些场景，并将现有的任务模型适应了新的方式来量化和解决交接债务。虽然这项工作专门针对编码代理，但它可能表明，在更广泛的人工智能背景下以及文档政策的后勤方面，可能会有有用的前进道路。

方法

作者将 前任 定义为先前的代理（最初或最后处理工作的代理），将 继任者 定义为当前代理（被要求接手工作的代理）。

为了支持一个旨在衡量在代理之间转移未完成软件工程任务的成本的基准，75 个来自 SWE-bench Verified 的任务被转换为 181 个 交接 场景，每个场景代表工作被中断并传递给继任代理的点。然后，三个不同的继任模型在 2,172 次接管尝试中进行了测试。

在这些交接测试中使用的模型家族是 Qwen、Gemma 和 Devstral。

实验检查了四个级别的继承信息：在最严格的设置中，继任者只接收到存储库的状态（有效地进入一个没有文档的“灾难区”）。其他设置提供了越来越详细的上下文，从活动跟踪和命令历史到描述已尝试和学习的内容的紧凑摘要：

与仅关注任务完成情况不同，这项研究的设计目的是衡量 继续的成本，关注工具使用、令牌消耗和重建以前工作背后的推理所需的努力。

为实验定义了三个 交接点检测 定义和三个 交接状态：

数据和测试

为了创建现实的交接场景，作者的基准是从 SWE-Bench Verified 中提取的 75 个软件工程任务，重点关注通常需要 15 分钟到 4 小时才能解决的问题。

与仅评估已完成的任务不同，研究人员在工作过程中捕获了多个中间检查点，创建了一个代理必须从另一个代理接手的场景：

接管基准的构建。从 SWE-bench Verified 中提取的 75 个任务被扩展到 181 个交接点，涵盖三个工作阶段，根据接管时的存储库状态进行标记，并在四个信息共享条件下进行评估，产生 2,172 次总的继任代理接管运行。 来源

由于每个任务可以生成多个交接点，每个交接点使用四种不同形式的转移信息进行测试，因此基准迅速扩大，最后的数据集由 181 个不同的交接任务和每个继任模型的 724 个接管评估组成，产生了 2,172 次接管运行，跨越三个被测试的 AI 系统。

用于测试的环境是 OpenHands 风格的编码代理环境，具有终端操作、存储库冻结、文件编辑和来自 SWE-Bench 基准的官方验证等功能。

在主要研究中，所有交接点都来自 Qwen 基础的前任运行，以提供一个固定的起点来评估不同代理组合和多样场景之间的差异。

测试的接管对包括 Qwen 到 Qwen、Qwen 到 Gemma 和 Qwen 到 Devstral。

原始跟踪 产生了最大的努力减少，减少了 57-59% 的代理事件，而 摘要笔记 和 结构化笔记 分别减少了 20-46% 的事件。提示令牌的使用也在所有三个方法中下降，减少范围从 42-63%：

在仅存储库交接的情况下，继任代理必须花费额外的交互来重建前任的意图、以前的证据和失败的尝试。 原始跟踪、摘要笔记 和 结构化笔记 直接传递了部分信息，减少了需要重新发现的量，尽管这需要更大的初始提示。

为了测试这些收益是否真实，每个信息丰富的交接都与一个从同一点开始的仅存储库交接进行了匹配。跨所有模型配对，信息丰富的交接一致地减少了继任代理所需的工作量。

完整的事件跟踪产生了最大的减少，而摘要和结构化笔记也带来了大量的节省。这种效果出现在基准中，而不是由少数异常案例驱动的：

为了确认这种效果不是由少数异常案例驱动的，研究人员将每个交接与一个从同一点开始的仅存储库交接进行了比较。减少保持一致，表明这些收益反映了一个有意义的模式，而不是少数例外情况。

总结…

简而言之，作者发现，当一个代理将任务交给另一个代理时，即使是简单的笔记也能帮助第二个代理更高效地继续工作。

完整的记录效果最好，但任何交接信息都比让继任者仅从代码中重建一切要好；上述结果表明，“原始”原始日志方法不可避免地具有更高的令牌成本。

结论

尽管这篇论文本身针对的是同行研究人员，具有有限的吸引力，但这项新工作仍然解决了人工智能界面和协议当前状态下最令人着迷和最紧迫的问题之一。

人们希望在这种探索中开发的范式和获得的见解最终能够扩展到比仅仅是代理编码更广泛的上下文中的人工智能使用。

另一个值得探索的途径可能是未来项目考虑如何根据项目的特点和用例评估可能被认为是最低限度的文档水平。然而，即使这种功能本身也需要时间和金钱；因此，文档场景中的预算难题仍然难以克服。

* 个人来说，对于那些因上下文过载而变得缓慢的 ChatGPT 会话，我最近开始（带着一些困难）导出干净的聊天记录的 PDF，并将其用作新会话的起点，这个新会话变成了“第 2 部分”。

^† 不幸的是，这不是我今年读过的最容易理解的论文，因此我不建议读者阅读原始作品，尽管消化后的结果仍然很有趣。

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