可恢复性作为长期AI代理的系统原语
摘要
介绍了可恢复性作为长期AI代理的系统原语,强调基于证据的恢复决策,以在任务中断时保持合理的进展。
arXiv:2609.13672v1 公告类型:新
摘要:AI代理在编辑文件、调用工具或执行多步任务时可能会被中断。重启会重复已完成的工作,但从未经验证或过时的进展继续可能会将早期错误带入。保存的状态不一定适合恢复。我们引入可恢复性作为系统原语,使重用成为明确决策:选择支持的起点和允许的恢复动作,或阻止自动继续。其行为契约将该选择绑定到支持证据、执行和独立检查。参考架构连接持久性、验证和控制,通过互补的运行时实例测试不同职责。四个确定性和20个配对文件挑战证明,准确的恢复和成功的完成可能隐藏不允许的起点。进度控制将保留的工作归因于共享恢复。事件时间测试显示,权限还必须约束动作,并且独立持有的策略证据即使在影响发生后也能暴露违规。这些发现确立了为什么恢复决策需要自己的评估,超越恢复的字节和最终任务成功。在提供的策略和声明的信任模型中,贡献是一个通用的、可测试的接口,用于保留合理的进展,并使其重用的条件明确且可执行。
查看缓存全文
缓存时间: 2026/09/15 08:59
# 可恢复性作为长时程AI智能体的系统原语 来源:https://arxiv.org/html/2609.13672 作者:魏巍†† 北京信息科技大学 邮箱:[email protected] ###### 摘要 AI智能体在编辑文件、调用工具或执行多步任务时可能被中断。重启会重复已完成的工作,但从未经验证或过时的进度继续推进可能会将早期错误向前传递。已保存的状态不一定适合作为恢复点。我们引入**可恢复性**作为系统原语,使重用成为一个显式决策:选择一个受支持的起始点和一个允许的恢复操作,或者阻止自动继续。其行为契约将该选择与支持证据、执行和独立检查绑定。参考架构连接了持久化、验证和控制,其互补的运行时实例测试了不同的职责。四个确定性挑战和20个配对文件挑战表明,准确的恢复和成功的完成可能掩盖了被禁止的起始点。进度控制将保留的工作归因于共享的恢复。事件时间测试表明,权限还必须约束操作,并且独立持有的策略证据即使在效果发生后也能暴露违规行为。这些发现确立了为何恢复决策需要超越恢复的字节和最终任务成功而进行单独评估。在所提供的策略和声明的信任模型内,其贡献是一个共同的、可测试的接口,用于保留有依据的进展,并使其重用条件变得显式且可执行。 ## 1 引言 一个AI智能体可能在编辑文档、转换表格或调用工具时花费了许多步骤,然后其执行被中断。它也可能在重复执行无效操作或无法取得经过验证的进展时持续运行。此时,恢复提出了一个实际的选择。从头开始会重复已经检查过的工作,而从最新状态继续则可能重用未通过验证或当前证据不再支持的工作。系统需要确定哪些进展仍然可以使用,以及如何从此处继续。 考虑一个文档编辑任务。检查点A包含一个已批准的版本。智能体后来在检查点B保存了一个探索性的编辑,但该编辑未能通过所需的检查。随后的工具调用失败了。重启整个任务会重复A中已批准的工作;恢复最新的检查点会选择B,尽管它未能通过检查。如果A的批准仍然有效并且允许重试,智能体可以选择从A恢复。这个有用的区分很简单:**一个状态被保存并不意味着它仍然适合继续。** 图1:选择恢复点。A通过了所需检查,并在失败时仍然符合条件;较新的B被排除。任何一个快照都可以被精确恢复并随后修复为有效的文档。这些结果并不能揭示所选的起始点是否满足继续条件。 选择恢复点只是决策的一部分。重试一次读取可能是合适的,而重试一个可能已经改变了外部状态的工具调用可能会重复操作。旧的批准也可能已经过期。因此,即使是先前验证过的检查点也可能无法提供自动继续的合理方式。系统必须将保存的状态与下一个恢复操作一起考虑,并在其条件不满足时能够停止或请求审查。 核心问题是: > 在智能体失败或丢失可靠进展之后,它可以保留哪些工作,应该从哪里恢复,接下来应该做什么? 检查点提供了保存的状态和恢复机制。验证器提供关于特定版本的证据,诊断识别出错原因,而规划器或工作流选择可能的纠正操作。这些机制是必不可少的,但它们的输出必须相互连接:存储的版本需要支持其重用的证据,而提出的操作需要其可能运行的条件。单独的重试规则无需检查这些关系。 检查点管理器或工作流引擎可以通过明确决定允许从何处以及如何继续执行来提供这种控制。我们将此职责称为**可恢复性**:系统在性能降级后选择一个有证据支持的恢复点和一个允许的恢复操作的能力,或者当管理规则要求时,阻止自动继续。我们将其视为一个*系统原语*,因为它有自己的输入、决策和其他组件可以实现的要求。它通过执行控制平面协调检查点、验证和修复。它本身并不生成修复内容。 为了精确起见,我们将所选状态称为**继续源**,将纠正操作称为**恢复路线**,将执行该特定组合的权限称为**继续授权**。授权是在故障事件时根据证据和策略授予的;它不是检查点上的永久标签。所提出的契约要求决策能够管理执行、后续保持可检查性,并尊重重复恢复的限制。这使得恢复质量超越最终任务结果而变得可见。 在文档示例中,智能体可能恢复了B,然后成功修复了它。最终文档将掩盖先前选择了一个被策略排除的恢复点。检查保存的字节是否被精确恢复会错过同样的错误。因此,源、操作和执行权限必须与恢复和完成一起进行评估。 本文做出三项贡献: 1. **一个用于重用进展的可测试契约。**我们形式化了哪些保存的状态和恢复操作可以一起使用,包括所需的继续和所需的阻止。四项要求将此决策与其支持证据、执行和边界联系起来。它们使得恢复的正确性可以从恢复保真度和任务完成度中单独检查,包括那些观察掩盖了被禁止选择的情况。 2. **参考架构和有界实现。**我们将候选管理、证据评估、决策、执行和审计组织成一个显式的控制过程。该架构将现有的检查点和验证机制连接到特定恢复转换的权限。互补的实现使源选择、恢复和事件时间权限变得具体,其支持的行为和假设单独陈述。 3. **用于评估恢复决策的受控证据。**源选择挑战证明,准确的恢复和成功的端点可能掩盖一个被禁止的起始点。进度控制将保留的工作归因于共享的检查点恢复。授权测试区分执行决策与独立检查执行该决策的策略。这些结果共同确立了仅靠任务成功无法发现的可观测恢复错误。 目标是保留其重用有依据的工作,并使继续的条件变得显式。实验使用了提供的验证器和策略,因此它们测试的是对这些条件的符合性,而非在开放环境中发现信任。 ## 2 相关工作 恢复涉及保存工作、评估其有效性、决定接下来做什么以及执行该决策。这些职责出现在多个成熟的研究领域中。我们通过询问每个领域如何为选择有依据的继续点和操作做出贡献来定位可恢复性。 ### 2.1 容错与检查点 分布式快照捕获一致的全局状态[1],回滚恢复协议解释了计算如何在故障后从一致检查点恢复[2]。它们为保存和恢复工作提供了基础。对于智能体,一个计算一致的快照可能仍然包含一个验证失败的文档或假设已过时的计划。恢复机制需要对状态是否仍然适合使用做出决策。 智能体检查点越来越关注对话之外的状态。Crab使用感知效应的检查点来捕获智能体沙箱中的操作系统效应,并提高恢复正确性[13]。它的重点在于检查点必须捕获什么以及何时捕获有用。可恢复性则考察在可用状态中进行选择以及从这些状态允许的操作。 更完整的快照有助于准确执行该选择;但它本身并不能确立所选版本满足当前的继续条件。 最接近的替代方案是具有语义守卫的检查点管理器。通过验证过滤候选者已经实现了部分职责。如果管理器还检查从选定状态是否允许执行某个操作、支持必要的拒绝、执行决策并记录其理由和边界,则它可能满足完整的可恢复性契约。 我们的贡献是将这种组合指定为一个可观测的恢复决策,并将其有效性与恢复和任务结果分开评估。恢复一个被拒绝的版本并成功修复它,在一个排除它的策略下仍然是一个错误的恢复选择。该标准可以应用于现有的检查点管理器,而无需声称对其组件拥有独占所有权。我们实验中的恢复最新基线是一种刻意明确的选择策略,并非对所有检查点系统的特征描述。 ### 2.2 记忆与智能体持久化状态 Reflexion使用语言反馈来改进后续尝试[10],Voyager在探索过程中保留可执行技能[12],生成式智能体检索并合成存储的经验[8]。MemGPT为长期的语言模型交互组织多个记忆层次[7]。这些方法使信息超越单次上下文而持久化。记住一个任务是有用的,但无法确定接下来应编辑哪个版本。保留的声明可能引用一个较旧的工件,或与后续的验证结果冲突。 在可恢复性设计中,记忆可以为恢复点的选择提供信息,而其相关性必须根据当前的工件和证据进行检查。当前的运行时并不评估记忆冲突的解决方案。 ### 2.3 诊断、适应与工作流控制 ReAct交错推理和行动[15],而Toolformer扩展了模型对外部工具的使用[9]。工作流系统组织依赖关系、重试、回退和持久执行。可观察性提供了检查这些行为所需的跟踪。 关于智能体恢复的研究也考察如何在失败后选择更好的操作。*"Hell or High Water"*研究了当先前可用的功能失败时的替代规划[11]。AgentDebug在模块化轨迹中定位错误并提供针对性的修正[17]。这些方法解决了诊断和适应问题。 然而,在修正执行之前,系统仍然需要确定哪个持久状态支持它,以及从该状态允许哪些效果。可恢复性将这些输出连接到被重用的状态。例如,对失败工具调用的诊断本身并不能确定该调用在失败前是否更改了文件、现在应该选择哪个快照,或重试是否可能重复该效果。工作流可以通过自己的策略回答这些问题,并实现所提出的契约。该契约使答案变得显式且可检查,而无需特定的模块布局。 ### 2.4 评估智能体执行 SWE-bench衡量软件仓库中的问题解决[3],WebArena评估网络交互[16],OSWorld评估计算机使用[14],GAIA测试需要工具和推理的一般助理能力[5]。ToolSandbox添加了有状态的工具执行、隐式依赖和中间里程碑[4]。因此,智能体评估同时涵盖结果和执行行为[6]。 我们的评估询问恢复是否使用了允许的起始点和操作,以及任务是否完成。仅凭端点分数无法显示验证过的工作被丢弃,或者执行从被拒绝的版本恢复。因此,我们分别记录源选择、恢复、操作计数、权限及其执行,以及最终的不变量。 这些研究是对这些区别的受控演示,而非对智能体智能或已部署可靠性的大规模工作负载比较。这种定位是行为层面的。一个语义检查点管理器或工作流引擎可能已经满足部分或全部提出的要求。确定这一点需要检查其决策和执行行为,包括接受执行的依据是否独立于可能更改已执行策略的客户端。 当前的实验在共享机制上隔离了选定的要求;与此类完整系统的直接经验比较仍然超出其范围。 ## 3 问题表述 运行中的示例提出了三个问题:哪个保存的状态可以重用,从该状态允许哪个操作,以及是否应该继续执行。我们现在将这些问题独立于特定运行时进行表述。该表述将决策与两个后续观察区分开来:所选状态是否被准确恢复,以及任务最终是否成功。 ### 3.1 执行状态与降级 考虑一个执行轨迹 τ=(o₀,a₀,o₁,a₁,...,o_T),其中观察包括指令、工具结果、工件状态和验证信号,操作包括模型输出、工具调用、编辑和验证请求。因为操作可以改变持久状态,所以对话上下文只是执行的一部分。 记 X_t=(S_t, A_t, M_t, H_t, C_t, V_t),其中 S_t 是操作状态,A_t 是工件版本,M_t 是保留的声明,H_t 是执行历史,C_t 是存储的检查点,V_t 是验证记录。实现可以省略或扩展这些组件。该模型允许它们之间存在分歧:记忆可能描述一个较旧的工件,检查点可能包含未经验证的工作,跟踪可能记录一个外部效果仍不确定的调用。 当执行无法在其通常假设下继续进行,除非再次检查它们时,状态是**降级的**。令 f_t 表示检测到的事件。显式错误是一个例子;其他包括重复操作而没有经过验证的进展、过时的证据、工件损坏、上下文不完整,以及对工具副作用的不确定性。
相似文章
我开始认为可恢复性是自主代理的真正考验
作者认为可恢复性是自主AI代理的真正考验,强调了任务持久性和健壮恢复机制的必要性,以确保真正的自主性。
当长时间运行的代理任务被中断时,哪些部分得以保留?
探讨长时间运行的AI代理任务被中断时,哪些状态或进度得以保留,并讨论对可靠性和恢复的影响。
AI代理最棘手的部分似乎是恢复,而不是任务理解?
文章讨论的是,AI代理在真实工作流程中的主要挑战并非理解任务,而是处理意外变化的恢复、状态跟踪以及知道何时需要人工输入。
你们是如何处理AI代理在生产中中途任务失败的?以及这种情况对你们来说有多频繁?
一个讨论提问,询问开发者如何处理AI代理在生产中中途崩溃的情况,探讨重启、持久化状态、使用检查点或手动检查等方法。
没有停止策略的AI智能体只是一个昂贵的循环
关于AI智能体可靠性的实用说明,主张生产环境中的智能体需要明确的门控机制,包括证据阈值、重试预算和影响评估,而不是仅依赖记忆来确定任务是否完成。