AI Agent 实战教程 13：状态机、断点续跑与任务恢复

长任务 Agent 最怕两件事：执行到一半失败，以及失败后不知道从哪里恢复。状态机、断点续跑和任务恢复，就是为了解决这个问题。

很多 Agent Demo 只有一次模型调用，不需要复杂状态。但真实任务往往包含多个步骤：查询数据、等待授权、创建资源、上传文件、绑定关系、验证结果。任何一步都可能失败。如果系统没有状态，Agent 只能从头再来，甚至重复执行已经完成的写操作。

为什么需要状态机

状态机把任务执行过程拆成明确阶段。每个阶段代表当前任务处于什么状态，以及下一步允许去哪里。

常见状态包括：

• pending：任务已创建但未开始；
• running：任务正在执行；
• waiting_approval：等待用户确认；
• waiting_auth：等待授权；
• retrying：正在重试；
• failed：执行失败；
• completed：任务完成；
• cancelled：用户取消。

这些状态不是为了形式化，而是为了让系统在中断、失败、等待用户时保持可恢复。

步骤级状态

除了任务状态，还需要步骤状态。比如创建一个教程模块，可能包含：

1. 检查标签是否存在；
2. 创建缺失标签；
3. 上传标签图片；
4. 创建文章；
5. 创建 tutorial；
6. 绑定文章；
7. 验证结果。

每一步都应该记录输入、输出、状态、错误、开始时间、结束时间。这样第 4 步失败时，系统可以知道前 3 步已经完成，不需要重复执行。

断点续跑

断点续跑的核心是“执行前先检查”。例如创建文章前，根据 short 查询是否已存在；上传图片前，判断 URL 是否已经是自有素材；绑定 tutorial 前，查询当前已绑定文章。

这样即使脚本中断，重新执行时也能跳过已完成部分。

等待用户

Agent 经常需要等待用户授权或确认。比如缺少某个 API scope，需要用户打开授权链接；删除数据前，需要用户确认。

等待期间任务状态应进入 waiting_auth 或 waiting_approval，并保存当前步骤和上下文。用户回来后，系统继续执行，而不是重新发起整个任务。

错误分类

错误恢复要基于错误类型。网络错误可以重试；参数错误需要修正；权限错误需要授权；资源冲突需要合并；高风险操作需要确认。

不要对所有错误都简单重试，也不要所有错误都直接失败。分类越清楚，恢复策略越稳定。

防止重复执行

重复执行是 Agent 长任务中的高频问题。解决方式包括唯一 key、查重、幂等接口、操作日志和步骤状态。

例如创建资源时使用 short 作为唯一标识；绑定关系时先读取现有关联；更新内容时保留原 ID。这些都能降低重复执行风险。

小结

状态机让 Agent 从一次性对话变成可恢复任务系统。只要任务包含多个步骤、用户确认、外部工具或写操作，就应该考虑状态、断点续跑和错误恢复。

实战案例：创建内容教程的断点续跑

假设 Agent 要创建一套 18 篇文章的教程。这个任务很容易中断：前几篇文章可能创建成功，后几篇失败；tutorial 可能创建成功，但文章绑定失败；图片可能上传成功，但更新标签失败。

如果没有状态机，重跑任务时 Agent 可能重复创建文章，或者覆盖已经绑定好的顺序。更稳的方式是为每个步骤记录状态：文章创建步骤记录 short 和 articleId，tutorial 创建步骤记录 tutorialId，绑定步骤记录当前 sortIds。重试时先读取线上状态，再决定跳过、更新还是继续执行。

这种设计看起来麻烦，但它能把“失败后人工排查”变成“失败后自动恢复”。对于任何包含写操作的 Agent，断点续跑都应该尽早纳入设计。