跳到主要内容

任务中断与恢复

核对日期：2026-05-09。

1. 定义与边界​

任务中断与恢复是指 Agent 在执行过程中因人工审批、用户暂停、系统重启、工具失败、速率限制、预算耗尽或等待外部事件而暂停，并在之后从一致状态继续。

恢复不是“把历史对话重新发给模型”。工程上必须有 checkpoint、当前节点、已完成副作用、pending action、计划版本和权限快照。

2. 为什么重要​

长任务和高风险任务必然会被中断。如果恢复语义不清，系统可能重复执行副作用、丢失用户审批、使用过期权限或从错误计划继续。

3. 核心机制​

checkpoint 示例：

{
  "checkpoint_id": "ckpt_42",
  "run_id": "run_9",
  "node": "approval_wait",
  "plan_version": 2,
  "completed_steps": ["read_order", "calculate_refund"],
  "side_effects": [{"tool": "preview_refund", "idempotency_key": "r1"}],
  "pending_action": {"tool": "commit_refund", "params_hash": "sha256:..."},
  "resume_policy": "after_human_approval"
}

4. 架构模式​

模式说明适用
Explicit interrupt代码在特定节点暂停人类在环、审批
Failure checkpoint异常时保存错误和上下文工具不稳定
User pause/resume用户主动暂停后恢复长研究、代码任务
Event resume等外部事件触发继续支付回调、审批结果

5. 工程实现​

def execute_node(state, node):
    if node.requires_approval:
        action = build_pending_action(node, state)
        checkpoint_store.save(state.pause(action))
        return {"status": "interrupted", "resume_token": sign(state.run_id)}

    result = run_tool(node.tool, node.params, idempotency_key=node.key)
    state.apply(result)
    checkpoint_store.save(state)
    return {"status": "running"}

def resume(run_id, resume_token, approval):
    state = checkpoint_store.load(run_id)
    verify_resume_token(resume_token, state.user_id)
    verify_permissions(state.user_id, state.pending_action)
    if approval.params_hash != state.pending_action.params_hash:
        raise SecurityError("approval parameters changed")
    return continue_from(state)

6. 生产实践​

  • 中断点只放在状态一致的位置，不在半写入期间暂停。
  • pending action 保存参数哈希，审批后执行前再次比对。
  • 恢复前重新检查权限、工具版本、外部资源存在性。
  • 对 checkpoint 设置加密、保留期和访问控制。
  • 设计取消语义：取消后是否补偿、清理或保留草稿。

7. 常见反模式​

  • 恢复时重新跑整个 Agent，重复执行写操作。
  • resume token 长期有效且不绑定用户。
  • 人工审批只记录“同意”，不记录同意了什么参数。
  • checkpoint 缺少 plan_version，恢复后计划错位。
  • 工具失败和用户暂停使用同一种状态，无法区分。

8. 评测方法​

  • Interrupt Matrix：在每个节点强制中断并恢复。
  • Approval Consistency：审批参数和最终执行参数一致。
  • Permission Drift Test：用户权限变化后旧任务无法越权恢复。
  • Duplicate Side Effect Test：重复恢复不产生重复副作用。
  • Recovery Latency：恢复到继续执行的耗时。

9. 安全与治理​

  • checkpoint 是敏感资产，可能包含用户数据、计划和工具结果。
  • resume token 使用短期签名，并绑定 run、用户和 pending action。
  • 恢复前执行最新策略，不信任旧 Agent 输出。
  • 中断期间外部资料可能变化，必要时触发重规划而非继续旧步骤。

10. 工程手册补充​

10.1 Checkpoint 设计​

中断恢复不是“把聊天记录再喂一次”，而是恢复可执行状态。

{
  "checkpoint_id": "ckpt_004",
  "run_id": "run_456",
  "created_at": "2026-05-09T10:00:00+08:00",
  "plan_version": 2,
  "current_step": "s4",
  "completed_steps": ["s1", "s2", "s3"],
  "artifact_refs": {
    "clean_data": "artifact://clean_data/v1"
  },
  "pending_side_effects": [],
  "permissions_snapshot": ["file.read", "sql.read"],
  "resume_policy": "recheck_permissions_then_continue"
}

10.2 恢复决策表​

中断类型恢复方式注意事项
模型超时从当前步骤重试限制重试次数，避免成本失控
工具只读失败换工具或等待重试不需要回滚 artifact
写工具状态未知先查外部系统不能盲目重复 commit
用户暂停保存 resume token恢复时重新校验权限
需求变更新计划版本旧 checkpoint 只能作为事实来源

上线清单：

  • checkpoint 不保存密钥和过期 token，只保存权限引用。
  • 所有可恢复工具调用都有幂等键或状态查询接口。
  • 恢复前先运行 reconciliation，确认外部系统和本地状态一致。
  • 评测要覆盖进程重启、网络断开、重复恢复、旧权限失效、部分副作用成功。
  • 监控恢复成功率、平均恢复耗时、重复副作用次数和人工接管率。

10.3 回滚与补偿示例​

并非所有中断都能“继续跑”。只读步骤可以重试，写步骤要先判断外部状态。

def recover_after_write_timeout(step, checkpoint):
    status = external_system.lookup(step.idempotency_key)
    if status == "committed":
        mark_step_done(step.id, evidence=status.receipt)
        return "continue"
    if status == "not_found":
        return retry_or_abort(step)
    if status == "partial":
        create_compensation_task(step, checkpoint)
        return "pause_for_human"
    return "manual_reconcile"
外部状态本地状态动作
committedstep 未完成补写本地状态，继续下游
not_foundstep 未完成可重试，但必须复用幂等键
partialstep 未完成暂停并创建补偿任务
committedplan 已取消执行补偿或人工确认

安全要求：

  • 恢复时不要复用旧的高风险审批结果，除非审批仍在有效期内。
  • 补偿任务必须和原始副作用绑定，不能让 Agent 自行发明逆操作。
  • 所有恢复分支都要写 trace，便于事后审计是否重复执行。

11. 权威资料​