AI Agent 断点恢复怎么做：检查点、任务状态和重复执行要同时设计

一个 Agent 任务可能需要读取资料、调用多个工具、等待审批，再生成最终结果。只要其中一步网络中断，简单重试就可能重复下载、重复写入或重新消耗大量 token。断点恢复不是把聊天记录保存下来，而是保存足够让系统判断“已经完成什么、下一步能否继续”的任务状态。

检查点应该保存什么

每个重要步骤至少保存任务节点、输入摘要、工具参数哈希、工具结果引用、资源版本、审批状态和执行时间。大段正文和文件不要直接塞进状态表，可以保存受控存储的版本 ID。检查点要能区分“未开始”“执行中”“已完成”“结果未知”和“需要人工确认”。

结果未知尤其重要：工具可能已经执行，但回包在网络中断时丢失。恢复时先查询工具侧状态或幂等记录，再决定是否继续，不能因为本地没有回执就再次提交。

版本变化不能被忽略

恢复任务时，模型、系统提示、工具 schema、策略和业务数据可能已经更新。系统应记录生成检查点时的版本，并在恢复前做兼容性检查。低风险的读取步骤可以继续，高风险写入步骤最好重新预览并要求确认。不要默默把旧计划套到新资源上。

多 Agent 框架可以帮助组织工作流，但持久化和权限边界仍需由应用负责。OpenAI Agents Python 等项目强调多 Agent 工作流的轻量编排，实际生产还要补上外部状态、重试和审计机制。

如果模型需要在不同上游之间切换，可以用 top-api.cc 保存请求 ID、模型和回退信息，把任务检查点放在自己的数据库。网关负责调用可追踪，业务系统负责判断恢复是否安全。

测评恢复能力

• 在模型响应前、工具执行中和工具完成后断开网络；
• 恢复时更换模型、工具 schema 和策略版本；
• 模拟队列重复投递与结果未知；
• 检查是否重复收费或重复产生副作用；
• 验证人工接管能看到完整的状态摘要；
• 任务取消后，旧检查点是否还能被错误恢复。

断点恢复的目标不是让所有任务自动续跑，而是让系统在不确定时停在可解释状态。对于删除、付款、发布和跨租户动作，恢复前重新确认通常比追求全自动更稳妥。

参考资料：OpenAI Agents Python、LangGraph 等工作流项目的状态管理思路，以及各工具服务的幂等和查询接口文档。

想比较多个模型的任务恢复行为时，可用 top-api.cc 统一路由和请求记录，再用相同故障注入脚本验证检查点逻辑。