← 返回概念解读

Concept Fable精修版

状态机

State Machine · Software architecture / workflow

先读故事。这里不急着给定义,先让问题自己长出来。

寓言故事

渡口给每条船挂上了状态牌

河口渡口起初很简单。船来了就装货,装满就开,到了对岸就卸。老船夫凭经验知道下一步该做什么。后来货物有冷藏箱、危险品、急件和待检包裹。船也有维修、加油、候潮、复核等情况。靠喊话调度,开始频繁出错。管事先在码头挂了一块大木牌:请大家按规矩办事。可每个人理解的规矩不同,有的船没检完就开,有的船明明可走却一直等批。

第二个办法是让所有异常都问管事。结果管事被围住,船队排成长龙,最简单的装卸也要等一句口头许可。

一个年轻船匠把每条船可能处在的位置列出来:待装、装载中、待检、待审批、可出航、航行中、已到港、异常、关闭。每个位置只允许少数几种下一步。

他还规定了转移条件:检验通过才能从待检到可出航,审批拒绝必须回到待装,风暴警报会把航行中转到异常处理。

有了状态牌,船夫不必猜现在该听谁的。整套装置也能记录一条船为什么卡住、谁触发了转移、是否可以重试或回滚。

渡口最终稳定下来,不是因为船夫突然都更谨慎,而是因为复杂流程被拆成有限状态和明确转移,混乱被关进了可检查的边界里。

状态牌刚挂上时,老船夫嫌它死板。直到一艘危险品船因缺少复核印被挡在待审批,众人才发现木牌不是添麻烦,而是在关键位置替大家拦住习惯动作。

后来每次事故复盘,管事不再问“谁怎么想的”,而是问船当时处在哪个位置、允许哪些转移、是谁触发了下一步。渡口的争吵少了,因为每一步都有明确边界。有限位置和有限转移让每个人知道自己能做什么,也知道什么时候必须停下。

揭示

这个故事讲的是:状态机

State Machine 用一组明确状态和状态转移规则描述系统行为。它适合管理审批流、任务执行、Agent 生命周期、复杂 UI 和异常处理,因为系统在任何时刻都处于可识别状态,并且只能按允许的条件进入下一状态。企业 Agent 落地时,状态机能减少隐式流程、口头约定和不可复现的临场判断。

它重要的地方在于:它不只是一个术语,而是在真实 AI / Agent 系统里会反复出现的结构性问题。理解它,才能判断什么时候该加模型,什么时候该改流程,什么时候该补治理。

隐喻映射

  • 渡船:一个任务、工单、对话或 Agent run
  • 待装、待检、可出航等牌子:显式状态
  • 检验通过、审批拒绝、风暴警报:状态转移条件
  • 所有异常都问管事:缺少状态设计导致的人肉调度
  • 卡住原因和触发人记录:可观测、可审计的流程执行
  • 重试或回滚:状态机里的恢复路径
  • 有限状态和明确转移:State Machine 的核心结构

Soloharness 判断

这个概念的实战价值,是帮你把“看起来聪明的 AI 功能”拆成可交付、可验收、可治理的工作单元。

Workflow engineorchestrationfinite state machinetransitionsagent runtime