AI Agent 实战教程 13：状态机、断点续跑与任务恢复
长任务 Agent 最怕两件事：执行到一半失败，以及失败后不知道从哪里恢复。状态机、断点续跑和任务恢复，就是为了解决这个问题。
很多 Agent Demo 只有一次模型调用，不需要复杂状态。但真实任务往往包含多个步骤：查询数据、等待授权、创建资源、上传文件、绑定关系、验证结果。任何一步都可能失败。如果系统没有状态，Agent 只能从头再来，甚至重复执行已经完成的写操作。
为什么需要状态机
状态机把任务执行过程拆成明确阶段。每个阶段代表当前任务处于什么状态，以及下一步允许去哪里。
常见状态包括：
- pending：任务已创建但未开始；
- running：任务正在执行；
- waiting_approval：等待用户确认；
- waiting_auth：等待授权；
- retrying：正在重试；
- failed：执行失败；
- completed：任务完成；
- cancelled：用户取消。
这些状态不是为了形式化，而是为了让系统在中断、失败、等待用户时保持可恢复。
步骤级状态
除了任务状态，还需要步骤状态。比如创建一个教程模块，可能包含：
- 检查标签是否存在；
- 创建缺失标签；
- 上传标签图片；
- 创建文章；
- 创建 tutorial；
- 绑定文章；
- 验证结果。
每一步都应该记录输入、输出、状态、错误、开始时间、结束时间。这样第 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，断点续跑都应该尽早纳入设计。