AI代理如何安全重试？关键不只是重新发起调用

导语

对能够调用工具的AI代理而言，“失败后再试一次”并不是一个简单的工程动作。代理可能已经向外部系统发出请求，但本地进程尚未确认结果；恢复时，原有授权也可能已经失效或发生变化。此时直接重试，既可能重复执行，也可能绕过新的权限边界。

arXiv论文《Permission to Retry》将问题聚焦在代理的执行时可靠性，并刻意把恢复决策与语言模型本身的生成行为分离开来。研究关注的不是模型能否写出正确指令，而是系统在中断、重启和不确定结果下，是否知道何时可以继续、何时必须拒绝，以及何时只能保留未解决状态。

核心要点

• 四类义务不能混为一谈。 检查点状态只能说明代理保存了什么；当前是否有权发起调用，是另一项判断；外部系统是否已经产生效果，需要独立证据；即使效果已发生，应用是否仍获准进行结算或后续处理，也不能自动推定。
• 测试覆盖多种执行条件。 研究预先冻结了一轮包含336条历史的测试活动，横跨原生LangGraph和Temporal主机、14种调度安排、3种提供方契约及4套匹配的应用策略。两类主机的168个配对单元在检查结果上完全一致，说明差异并非简单来自工作流框架。
• 保留账本的恢复策略最完整。 研究让应用看不到提供方的真实效果账本，再用账本对恢复结果评分。在每个主机的42条历史中，保留账本并进行对账的方案全部通过：包括21条已核实完成、15条拒绝，以及6条仍未知但保留预约的结果。
• 常见重试策略各有缺口。 仅依赖缓存的重试通过30条；重试前重新验证权限通过36条；使用稳定键重试通过31条。数字显示，重新检查权限很重要，但它不能取代对外部效果的持久观察。
• 组件验证提供了补充视角。 研究还用仓库中的模拟对象，对InfinityOS的授权导出、工作者、恢复和结算代码进行了16个案例的测试。这部分不是完整生产环境评估，而是对关键组件行为的独立检查。

意义与影响

这项工作给代理系统设计提出了一个清晰的边界：授权决定“现在能不能做”，效果证据决定“之前是否已经做过”，而结算权限决定“确认后能不能完成后续动作”。把三者压缩成一个布尔值，往往会让恢复逻辑在最危险的灰色状态下失去信息。

对开发者而言，可靠的恢复机制应保存可核验的外部观察，使用稳定的幂等键，并在恢复时重新评估当前权限。同时，测试报告不应只统计完成率，还要分别呈现安全结果、完成结果和仍未解决的义务。论文的实验规模有限，且InfinityOS部分依赖仓库模拟环境，因此结果更适合作为一致性检查和设计原则，而不是对所有代理平台的普遍性能排名。

当AI代理开始执行付款、发信、改写数据或触发业务流程时，真正重要的能力可能不是“更积极地重试”，而是能够在证据不足时暂停，并明确留下待解决事项。

arXiv