状态机State Machine
你可能会说
我要让 AI 处理退款、审批这种流程，怎么保证它不会自己跳步骤？
状态机把一件事拆成几个固定状态，并写清楚每个状态在什么条件下才能走到下一个状态。例如退款工单停在「待审核」时，只有核对订单、确认能退，才允许进入「已退款」；想跳过审核直接退款，状态机会直接拒绝。
也常被叫作有限状态机State Machine状态图
运行结构 · 状态、转移、检查点
① 状态退款工单停在「待审核」→② 转移核对订单并通过审核，才允许到「已退款」→③ 检查点每步存一次，从断开处接着跑④ 中断点：到「已批准」先停，等人确认再退款
⑤ 走错就停越级转移 → 拒绝状态不明 → 回到检查点
任务此刻停在哪一步：待审核、已批准、已退款。状态只记录当前事实，不写下一步做什么
哪个状态能走到哪个状态、条件是什么。没写进图的走法，一律不允许
每走一步存一次状态和已填的数据；进程崩了、隔几天再处理，都从最后一步接着走
退款、对外发送、改共享配置这类动作先停下，等人确认再继续
没写进图的走法直接被拒，模型不能临场加步骤
容易混淆？这样区分
状态机≠流程图
流程图给人看，画个大概就算讲清楚；状态机要落成能执行的判断——每个状态允许去哪、条件是什么。条件说不出来，写代码时还是靠模型猜。
状态机≠让 AI 自己记住做到哪
模型只看得见当前这段对话，隔一天再聊就不记得工单走到哪了。状态存在应用这边，换模型、重开会话都能接着跑。
常见做法 · Variants
手写状态判断if / else
判断状态→改允许的字段
步骤少、改动少时最省事；流程一长，状态散在好几个文件里，改条件容易漏
用状态图编排LangGraph
状态→转移→检查点
要把流程画出来、要断点续跑或人工确认时用；多一层框架，团队得先学它的写法
模型自己管进度No state
模型判断→下一步
探索类、步骤不固定的任务；长任务容易跳步或重复，必须配检查与步数上限
典型使用场景
AI 想跳过审核直接退款，被状态机拦住
AI 建议 用户催得急，直接退了吧
状态机 待审核 → 已退款 不在允许的转移里，已拒绝
下一步 先提交审核；通过后停在「已批准」等人确认
隔三天回来，从「等待补充材料」接着走
10-26 已提交10-26 待审核10-29 接着处理
继续补材料，前面的对话不用重新讲一遍
延伸阅读 · 权威出处