2026年5月，华南一家合资车企开了一场内部复盘会。录像里，工业调度 Agent 把原本需要45分钟的物料断供响应压到3分20秒。演示很亮眼，接下来的运行却没那么顺利：旧接口延迟、实时库存数据和车间物理约束接连出现，模型频繁越权，系统最后退回半自动模式。
问题不只是模型答得对不对。当读取数据、做判断、调用接口和确认结果全写进一段长 Prompt，任何一步跑偏，后面的步骤都可能跟着失控。这次试验的完整过程见《AI Agent调度试验跑了三个月，调度员还在》。
一段 Prompt，不等于一条流程
一种常见做法，是把现有 SOP 改写成一段长 Prompt，让 Agent 从头执行到尾。步骤少时，这种方法简单直接；一旦任务超过3—5步，问题就会变得具体：
- 前面的约束容易丢。 Agent 走到中间步骤后，可能忘记最初的格式、权限或业务限制。
- 错一步，后面跟着错。 中间结果没有单独验收，后续调用会继续使用错误上下文，也找不到合适的回滚点。
- 重试成本高。 每次调用都要重新加载整段指令，失败后再跑一遍，又会重复消耗 Token。
《Prompt 写得再长，也救不了不会认错的 Agent》提到，Prompt 仍然有用，但长链路不能只靠模型自己判断对错。Schema、SQL 规则和单元测试负责验收，状态机则负责决定：通过后去哪一步，失败后又该去哪一步。
把“下一步怎么走”写成规则
状态机做的事并不复杂。它把一条任务链拆成若干状态，每个状态有明确的输入、输出和转移条件。抓取完成后才能提取字段，字段通过校验后才能生成摘要，摘要合格后才能发送到 Slack。任何一步报错，都转入单独的异常状态。
这样一来，“接下来怎么办”不再由模型临场发挥。节点内部仍然可以使用 Prompt，但节点之间如何切换，由代码和规则控制。
状态机也不是新技术。嵌入式系统、协议栈和游戏开发已经用了几十年。到2026年，LangGraph v2、AutoGPT 3.0 和 Semantic Kernel Workflow 都把状态与转移放进了 Agent 编排层。
同一条四步链，差别在失败后往哪走
内部测试选择了一条四步工作流：抓取商品页 → 提取关键字段 → 生成摘要 → 推送到 Slack 频道。两组都使用 gpt-4o-2026-05-01，只改变编排方式。
| 指标 | 单 Prompt（约1500 tokens） | 状态机（4个主状态 + 1个异常状态） |
|---|---|---|
| 成功率（100次） | 62% | 89% |
| 平均执行时间 | 45秒 | 32秒 |
| 平均 Token 消耗 | 8500 | 5100 |
| 异常处理覆盖率 | 被动，出错后出现 Prompt 死循环 | 主动，检测异常后跳转错误状态 |
这是一组内部测试，不适合直接外推成行业结论，但它说明了结构上的差别。状态机版本中，每个状态只处理一件事，上下文通过结构化 schema 传递；发生异常后，系统按照预案选择重试3次、跳过或转人工，而不是让 Agent 继续猜。
测试记录显示，100次运行中有11次进入失败路径，其中9次通过重试恢复，2次需要人工介入。比成功率更值得注意的是，失败终于有了明确去处。
三套框架怎么表示状态
- LangGraph v2使用有向图。节点定义动作，边定义转移条件，也支持条件分支、循环和子图嵌套。官方示例中，多工具调用 Agent 通常包含5—8个状态。
- AutoGPT 3.0把内部任务队列改成有限状态机。每个任务对应一个状态，执行失败后，根据预先定义的备份转移继续处理。
- Semantic Kernel Workflow在微软2025年底引入的 StepwiseStateMachine 中，允许开发者使用 YAML 或 C# 定义状态转移，并记录每一步的输入和输出，方便审计。
三套工具的 API 和使用环境不同，但处理的是同一个问题：业务流程不能完全交给模型自由发挥。正如《Agent 已经能自己写代码，工作流为什么还不能省？》所说，鉴权、状态切换和回滚仍然需要固定规则。Agent 可以在节点里写代码、生成内容，流程边界则留在节点外。
拆状态时，先守住几条硬边界
一次调用，一个状态。 可以把一次 API 请求、一次数据库查询或一次本地命令执行作为默认粒度。如果一个状态里同时查库、调用接口并执行命令，出错时只能知道这一大块坏了，很难定位具体环节。
失败必须有单独出口。 用明确的 switch-case 写清楚重试次数、间隔时间和超时后的动作：跳过、终止，还是转人工。不要把异常处理写成一句“请自行修正”。
状态之间传结构化数据。 使用 JSON Schema 约束字段和类型，不要让上一个节点写一段说明，再让下一个节点猜它是什么意思。
整条链要有刹车。 总超时和最大重试次数都应提前设定，避免流程困在某个循环分支里。
《自进化 Agent 的关键，是把失败写进工作流》强调了执行轨迹的作用。状态转移日志正好提供了这份记录：失败发生在哪个状态，当时输入了什么，之后走了哪条分支，都可以查到。
Prompt 留在节点里，不要拿来掌管全局
状态机不适合所有任务。让模型“写一首关于秋天的诗”，没有必要先画一张状态图。开放式创作需要空间，流程拆得太死，反而会限制输出。
数据 ETL、报告生成、工单处理和异常检测则不同。这些任务通常有先后顺序，也有可以检查的格式、字段和结果，更适合让状态机控制流程。
一种更稳妥的分工是：状态机决定能不能进入下一步，Prompt 负责完成当前节点里的生成任务。以“生成摘要”为例，Prompt 负责写摘要；如果长度或格式不合要求，状态机不会直接进入发送状态，而是触发修正或告警。
《长 Prompt 越写越乱，Agent 该自己拆任务了》提出要固定目标、边界和验收条件。状态机只是把这些要求从自然语言搬进了代码。
迁移不用推倒重来
可以先挑一条经常重试、又容易定位结果的工作流，而不是一次重构整个系统。
- 先在纸上画出有限状态图：有哪些独立操作，哪些必须按顺序执行，哪些可以并行，失败后分别去哪。
- 根据现有技术栈选工具。Python 团队可以使用 LangGraph v2，.NET 团队可以使用 Semantic Kernel，快速原型可以尝试 AutoGPT 插件。
- 先跑通最简单的线性链：State A → State B → State C。确认输入输出稳定后，再加入异常状态、分支和循环。
- 按状态图补测试。每个状态、每条转移都应能单步执行，失败路径也要单独验证。
不必放弃 Prompt。真正该放弃的，是让一条 Prompt 同时承担指令、状态管理、错误恢复和审计。
状态机不会让 Agent 变得更聪明，但能让错误更容易定位，让重试次数有上限，也让人工介入有明确入口。对超过3—5步、需要调用外部工具并处理回滚的任务，这通常比继续加长 Prompt 更有用。
