很多 AI Agent 演示看起来很顺，但一放到真实任务里，就会遇到三个麻烦：任务跑到一半卡住了，失败后不知道该不该重试，人工确认回来以后又重复执行了一次。表面上是工具调用问题，底层其实是状态没有设计清楚。
如果一个 Agent 只知道“开始”和“结束”，它很难进入长期自动化。前面讲 任务规划 时，我们讨论过计划器和反思循环；讲 工具权限模型 时，也把只读、草稿、执行和回滚拆开。任务状态机就是把这些动作真正落到运行层。
为什么要有状态机
状态机不是为了把系统做复杂，而是为了让每一步都能被接管、恢复和复盘。一个任务从用户提交开始，可能会经历排队、资料检索、工具执行、等待人工确认、失败重试、最终完成。每个阶段能做什么、不能做什么，都应该明确。
比如“等待确认”就不是失败，也不是完成。它代表 Agent 已经准备好下一步高风险操作，但需要人决定是否继续。如果这一步没有独立状态，系统很容易把任务误判成超时，或者在重启后再次发送同一封邮件。
最小状态可以先这样拆
对大多数团队来说，第一版不需要设计几十个状态。可以先保留六个核心状态：queued 表示排队中，running 表示执行中，waiting_for_review 表示等待人工确认，retrying 表示正在重试，failed 表示失败，done 表示完成。
这套设计已经能覆盖不少真实场景。比如 会议纪要复盘 生成行动项后，可以进入 waiting_for_review；负责人确认以后再写入任务系统。又比如 竞品监控周报 抓取失败，可以进入 retrying，而不是直接生成一份缺数据的报告。
状态变化要写进日志
状态机最大的价值，是让复盘有线索。日志里不仅要记录工具调用，还要记录状态从哪里变到哪里、为什么变、是谁触发的。这样任务失败时，团队能知道是模型判断错、工具返回错、人工确认超时，还是外部系统不可用。
这和 OpenClaw 日志复盘 是同一件事。没有状态记录，日志只是一堆零散文本；有了状态流转，日志才像一条可追踪的工作流。
不要把重试当成重新开始
很多重复发送、重复写表、重复建任务的问题，都来自“失败后从头再跑”。更稳的做法是让每一步有自己的执行标记：哪一步已经成功，哪一步可以重试，哪一步必须等人确认。
比如邮件已经发送成功，但后面的日志写入失败，重试时就不应该再发一次邮件。状态机要和幂等设计配合，才能避免自动化越帮越忙。
总结
AI Agent 任务状态机的核心，是把真实任务里的中间态说清楚。排队、执行、等待确认、失败重试和完成不能混在一起。状态拆清楚以后，Agent 才能被暂停、恢复、审计和优化。
