很多团队在设计控制器时，会下意识把所有规则、所有上下文和所有异常处理都塞进一段越来越长的提示词里。短期看，这种做法启动很快；长期看，它会把系统最重要的运行状态藏进模型上下文，让调度、恢复和审计都变得模糊。
真正进入生产环境后，控制器不只是“想下一步”，它还要持有等待中的分支、失败后的回退路径、人工接管点和停止条件。到了这一步，控制器就不该再被当成一段巨型提示词，而应该被设计成一个显式状态机：状态可见、迁移有条件、异常能恢复。
为什么这个问题重要
真实运行代价
巨型提示词最大的问题不是长，而是它把不同层次的责任混在一起。当前目标、分支状态、工具结果、人工审批标记和下一步决策全都挤在同一个上下文里，一旦会话变长，控制器就很难稳定地区分“系统现在处于什么状态”和“模型此刻想说什么”。
- 状态只活在上下文里，重试后容易失真。
- 条件判断不显式，团队很难解释为什么转到下一步。
- 等待外部事件时，系统无法可靠恢复到同一个控制点。
如果不处理会怎样
如果控制器一直停留在巨型提示词阶段，系统通常会在三件事上先出问题：第一是分支越来越多时，模型记不住每个分支的真实状态；第二是工具失败后，无法稳定回到正确节点；第三是人工接手时，看不到清晰的运行轨迹，只能从一长段自然语言里倒推发生了什么。
适用场景
谁最需要这套方法
只要任务开始出现路由、并行、等待、重试或人工升级，这套方法就值得尽早引入。尤其是控制器需要跨多轮会话持有任务上下文、协调多个执行角色，或者要把失败恢复成本压下来的团队，最容易从状态机控制器里获得收益。
- 存在多个明确节点和停止条件的工作流。
- 需要处理等待外部事件或异步回调的任务。
- 希望把人工接管点和恢复路径前置设计的团队。
什么时候先不要这么做
如果当前任务仍然是单轮推理加少量工具调用，或者系统还没有清晰的输入输出契约，那么先补状态机并不会立刻创造价值。这个阶段更适合先把工具接口、返回字段和失败分类整理好，再决定是否要把控制器提升为显式状态机。
推荐系统结构
核心角色与状态
一个可用的控制器状态机，至少要把状态、事件、迁移条件和副作用边界拆开。状态表示系统当前所处阶段，事件表示什么事情触发迁移，迁移条件表示什么前提下允许切换，副作用边界则决定哪些动作可以自动执行、哪些动作必须挂上审计或人工确认。
- 用显式状态记录当前节点，而不是依赖聊天历史猜测位置。
- 用事件驱动迁移，例如“分支完成”“工具失败”“人工批准”。
- 把副作用动作挂在迁移之后，避免模型在思考阶段直接写系统。
与 TaskPilots 的映射
在 TaskPilots 的多 Agent 协作编排集群里，控制面本来就承担节点切换、分支回收和人工升级的职责。把控制器做成状态机，意味着这些决策都可以沉淀成显式结构：哪个分支在等待、哪个分支已完成、什么条件触发 join、什么时候要把任务交回人工。这样后续新增专家角色或治理规则，也是在既有状态图上增量演进，而不是重新堆一版更长提示词。
风险与失效点
常见失控方式
状态机不是银弹，设计得不好一样会失控。最常见的问题是状态名写得很漂亮，但迁移条件不清楚；或者虽然定义了状态，却仍然让模型在一个节点里承担过多决策，最后只是把巨型提示词换了个外壳。另一个高频问题，是副作用和状态变更顺序不清，导致失败后很难恢复一致性。
- 状态过粗，多个阶段被混成同一个节点。
- 迁移条件依然依赖模糊自然语言判断。
- 先执行副作用、后写状态，失败时容易出现脏数据。
需要人工兜底的地方
涉及权限提升、跨系统写入、成本较高的操作，或者多个分支结论冲突时，人工兜底点应该挂在控制器层。这样人工看到的是状态图、最近事件和待确认动作，而不是一长段提示词历史。人工接手越依赖结构化状态，恢复成本就越低。
验证指标
上线前怎么验证
上线前不要只看“是否能跑通”，而要专门验证状态迁移是否稳定。准备一组覆盖正常路径、异常路径、人工审批和外部超时的任务样本，检查控制器能否在重复运行中进入相同状态、做出相近迁移，并在失败后恢复到预期节点。
- 检查相同输入下的状态迁移一致性。
- 检查工具失败或超时后是否回到正确恢复节点。
- 检查人工接管后能否继续沿同一状态图往前执行。
上线后怎么持续判断
生产阶段建议持续跟踪非法迁移率、恢复成功率、人工接管率和单任务平均状态数。非法迁移率高，通常说明节点划分不清；恢复成功率低，说明事件和副作用边界设计有问题；状态数持续膨胀，则说明控制器开始承担过多职责，需要重新拆分。
下一步 / FAQ
下一步建议
如果你的控制器现在还是一段不断膨胀的系统提示词，先不要重写全文。先画出最小状态图，只保留关键节点、关键事件和停止条件，再把一两个真实工作流迁进来验证。只要状态图开始稳定，后续扩展多角色、恢复机制和治理策略都会顺很多。
FAQ
状态机会不会让系统变得太“硬编码”？ 不会。状态机约束的是控制流，不是每个节点里的模型推理空间；它让系统边界更清楚，而不是让模型更死板。
控制器还能保留推理能力吗？ 可以。模型仍然可以在节点内做判断，但是否允许迁移、是否触发副作用，应该由显式规则和状态共同决定。
什么时候需要把状态机继续拆细？ 当某个状态开始同时承担等待、判断、执行和恢复四类责任时，就说明这个节点已经太宽了。