证据引导恢复机制应对智能体工具超时与部分执行

摘要：这项研究面向智能体调用工具超时后无法确认“失败、已提交或仍在执行”的难题，提出基于公开证据的任务恢复框架。系统以批准义务、供应商能力和可观测状态定义可行解，通过统一可容许性检查处理密钥过期、授权时序、依赖关系与残余副作用，并以终止证书区分实际目标达成和公开证据支持的安全完成。预注册实验覆盖19个任务家族和58个配对单元，证据规划建议认证30次完成，对照方法仅9次，提升36.2个百分点，但结果仍受任务规模、供应商语义与证明边界限制。

---

核心问题：工具超时不是简单的“失败”

当智能体调用支付、创建工单、修改资源等外部工具后发生超时，服务端可能已经完成提交，而客户端只收到一个超时信号。此时直接重试可能造成重复扣款、重复创建或状态冲突；直接判定失败，则可能把已经完成的任务误报为未完成。

这项研究把恢复问题建模为：智能体只能基于批准的操作义务、工具供应商公开声明的能力，以及与现有证据相容的系统状态选择后续动作。系统不假定工具具有“恰好一次”执行语义，也不会把客户端观察不到的状态强行推断为成功。

架构：规划器与效果历史裁决器分离

已知模型环境下的实现由两个相对独立的组件组成：

1. 观察条件规划器根据当前可见证据生成候选动作；
2. 效果历史裁决器检查工具调用是否留下可验证的副作用，并判断当前状态是否允许继续执行。

这种分离避免让同一个语言模型同时负责提出方案和证明方案安全。工程上，裁决器可以作为独立策略层接入 Agent Runtime，即使底层模型不变，也能增加一层确定性的状态约束。

统一可容许性检查

所有候选恢复动作都经过共享的 admissibility check，主要处理：

• API 密钥是否过期或即将失效；
• 授权是否已经生效，操作是否仍处于允许时间窗口；
• 前置依赖是否已经满足；
• 失败重试是否会与已提交的副作用冲突；
• 当前步骤完成后是否仍存在残余影响。

这一机制本质上是工具执行层的策略验证器。它不必理解完整业务目标，但必须把身份凭据、依赖图、幂等键、授权范围和补偿动作抽象成可检查的约束。

终止证书

研究没有把“智能体认为任务完成”作为终止条件，而是引入 terminal certificate，将两种状态分开：

• 实际目标已满足：有足够证据确认目标确实完成；
• 公开证据支持的安全完成：无法确认真实业务状态，但在已声明能力和现有证据下，可以证明继续操作不会带来更坏结果。

这种区分很关键。前者可以用于最终业务回执，后者更适合超时后的安全收尾。例如，查询工具明确保证超时后操作仍在执行，则系统可以等待或转入人工交接，而不是冒险重试。

实验结果与统计边界

研究包含两组实验。

第一组在37个任务分配上比较规划方法与三个主动对照方法，四者都认证了28次完成。规划方法通过额外计算节省了4个合成费用单位，说明该架构并非在固定成本约束下直接胜出。

第二项是预注册的 assignment-held-out 对比，测试规划建议与 evidence prompting。实验覆盖19个既有任务家族、58个配对单元，使用两个本地模型组合：

• 规划建议认证30次完成；
• evidence prompting 认证9次；
• 差值为36.2个百分点；
• family sign-flip 精确检验得到 p=0.0078；
• 两组分别产生272个与399个候选提案；
• 全部116条轨迹均通过独立重放。

按任务家族进行符号翻转检验，比把各轨迹视为独立样本更合理，可以部分控制同一任务家族内的相关性。不过，这仍是有限规模研究，两个本地模型上的正向差异尚不足以证明对所有模型、工具链和真实业务分布都成立。

为什么这不是普通的重试策略

普通重试主要回答“能否再次调用”，而该框架处理的是更完整的恢复决策：

• 当前调用是否真的失败；
• 哪些证据足以支持该判断；
• 哪些后续动作仍满足权限与依赖约束；
• 何时应该查询、转交人工或安全终止；
• 如何避免补偿动作放大原操作的副作用。

其保证边界也写得很清楚：结论依赖供应商声明的能力，不能替第三方工具凭空提供“恰好一次执行”保证。如果供应商不提供幂等语义、查询接口或状态承诺，系统最多只能给出条件化结论，而不能保证真实目标已经完成。

工程权衡

这套方案的优势是安全边界清晰，但代价同样明显：

1. 额外推理与裁决开销：规划、证据收集和状态检查会增加延迟和模型调用量。
2. 证据完整性依赖供应商：工具若不提供稳定查询、幂等键或可靠状态语义，恢复机制只能保守转交。
3. 证书可能被过度解释：“公开证据支持的安全完成”不等于业务目标真实完成，产品界面必须清楚区分。
4. 规则维护成本高：密钥、授权、依赖和补偿逻辑需要随供应商 API 演进持续更新。
5. 实验规模有限：19个任务家族与两个本地模型组合尚不足以覆盖支付、基础设施变更等高风险生产场景。

开发者落地建议

将该机制用于生产 Agent Runtime 时，可以按以下顺序实施：

1. 先定义供应商能力契约：明确幂等性、查询接口、超时后状态、撤销与补偿语义；
2. 记录完整效果历史：保留请求 ID、幂等键、返回状态、副作用类型和重试历史；
3. 实现统一准入策略层：在工具执行前检查凭据、授权、依赖与残余影响；
4. 分离规划与证明组件：让裁决器使用结构化状态，而不是只依赖模型自由文本判断；
5. 输出三类结果：实际完成、证据支持的安全完成、未知或人工转交；
6. 按风险分层评测：优先在高金额写入、不可逆操作和多工具依赖任务上做故障注入与重放测试。

真正可落地的产品形态不是“更聪明地猜工具是否成功”，而是把不确定执行变成可审计、可约束、可转交的工程状态机。

---

消息来源：Hugging Face Daily Papers (2026-10-30)

—— 完 ——

主题标签： #AI智能体 关注 #工具调用 关注 #任务恢复 关注 #证据推理 关注 #运行时安全 关注