很多 Agent 项目最初都没有状态机。
它们通常只有一条隐含逻辑：
用户发来请求，模型想一想，调用几个工具，再输出结果。
问题在于，这种流程一旦进入真实场景，就会出现大量无法回答的问题：
- 现在到底是在规划、执行，还是重试？
- 工具超时后应该回到哪一步？
- 哪些状态允许写操作，哪些只能读？
- 如果用户中途改目标，要不要沿用旧上下文？
没有状态机，这些问题全会堆到 Prompt 上，最后 Prompt 越写越大，系统却越来越不可控。
建议先配合阅读 AI Agent 必考知识点拆解、多 Agent 协作架构、AI Agent 可观测性设计 和 AI Agent 并发与可靠性。
一、为什么 Agent 必须有显式状态
状态机的价值，不是让系统更复杂，而是让边界更明确。
一个没有状态机的 Agent，通常会出现三种典型问题：
- 错误恢复依赖模型临场发挥
- 失败 run 无法稳定回放
- 新增策略时不知道应该插在哪一层
而有状态机的系统，至少可以回答：
- 当前处在哪个阶段
- 下一步允许做什么
- 失败后能回到哪里
二、一个最小可运行的 Agent 状态机
| 状态 | 主要职责 | 允许动作 | 不该做什么 |
|---|---|---|---|
RECEIVED | 接收输入与初始化上下文 | 校验输入、生成 run id | 直接调用工具 |
BUILD_CONTEXT | 组装上下文与证据 | 召回、摘要、裁剪 | 输出最终答案 |
PLAN | 生成任务计划 | 拆解步骤、选择策略 | 直接执行写操作 |
EXECUTE | 执行工具或子任务 | 调工具、等待结果 | 越过策略校验 |
VALIDATE | 校验输出是否合规 | schema 校验、policy 校验 | 偷偷吞掉异常 |
RESPOND | 生成用户可见结果 | 汇总、解释、降级 | 修改核心状态 |
DONE/FAILED | 收尾与记录 | 打点、回放、归档 | 再次进入执行态 |
这套最小状态机已经足够支撑大多数单 Agent 任务型系统。
三、典型失败案例：没有 stop condition，系统进入循环
某个报销 Agent 的逻辑是：
- 先提取票据信息
- 再查预算余额
- 最后写入审批系统
线上事故出现时，Agent 在预算接口返回空值后，不断回到“重新规划”，然后又再次尝试查询预算，最终在 30 秒后超时。
根因有三个：
- 没有给
PLAN -> EXECUTE增加最大轮次 - 工具空结果没有被视为显式失败态
- 状态流里没有“升级人工”分支
修复后，状态机变成：
PLAN -> EXECUTE_BUDGET -> EMPTY_RESULT -> VALIDATE -> ESCALATE_HUMAN
这样系统虽然不能自动完成任务，但至少不会循环烧预算。
四、状态机和权限应该一起设计
很多团队会先做状态机，再补权限。但更稳的做法是一起做。
例如：
PLAN允许生成 proposal，不允许写操作EXECUTE可以调用读工具，但写工具必须在VALIDATE通过后再进入FAILED态不能偷偷重入写操作
一旦把权限和状态分开设计，系统很容易出现“逻辑上不该执行，但技术上能执行”的漏洞。
五、状态迁移必须可观测
每次状态转移至少记录：
- from_state
- to_state
- transition_reason
- latency_ms
- 关键输入摘要
- 关键输出摘要
只有这样，你才能对一次失败 run 做真正有意义的回放。
六、验收状态机设计是否合格的 5 个问题
- 工具失败后能明确落到哪一个失败态吗？
- 写操作是否只在允许状态出现？
- 同样输入重复运行，状态迁移是否稳定？
- 每次状态转移都有 trace 可追踪吗？
- 超预算、超时、空结果是否都有明确收口路径？
七、AI Agent 状态机设计清单
- 定义最小状态集合，不把状态和策略混在一起
- 为每个状态写清允许动作和禁止动作
- 对失败路径单独建模，不靠 Prompt 临场补救
- 为关键状态迁移打 trace
- 给循环、空结果、超时设计硬收口条件
