状态机 (State Machine / Finite State Machine)

1. 定义

状态机（更常说有限状态机 FSM, Finite State Machine）是一个抽象模型：系统在任意时刻只处于有限个状态中的某一个，在收到某个事件/输入时，按预先定义的转移规则从一个状态跳到另一个状态。

核心就三样：状态 (State) + 事件/输入 (Event/Input) + 转移 (Transition)。

类比：红绿灯就是个状态机。状态 = {红, 绿, 黄}；事件 = “计时器到点”；转移 = 红→绿→黄→红，固定循环。它任何时刻只能是其中一个颜色，不会又红又绿。

2. 解决了什么问题

当一个系统的行为”随所处阶段不同而不同”时，用一堆 if/else 或 flag 变量描述会越写越乱、状态爆炸、难以维护。状态机把”有哪些状态、能怎么跳、跳的条件”显式画出来，带来：

清晰：所有合法路径一目了然
可控：非法转移（不该发生的跳转）被自然禁止
易验证：可以枚举、测试、画图，甚至形式化证明
好维护：加一个状态/转移，改动局部而非满地 if

3. 核心概念

概念	含义
状态 (State)	系统当前所处的阶段，如”待机""运行中""已完成”
初始状态 (Initial State)	启动时所处的状态
事件 / 输入 (Event/Input)	触发转移的信号，如”点击""收到数据""超时”
转移 (Transition)	“在状态 A 遇到事件 X → 跳到状态 B”的规则
动作 (Action)	转移时或进入/离开状态时执行的操作（副作用）
终止状态 (Final State)	结束状态（不是所有状态机都有，循环型的就没有）

4. 图示：一个订单状态机

   [待支付] ──支付成功──▶ [已支付] ──发货──▶ [已发货] ──确认收货──▶ [已完成]
      │                                             
   取消/超时                                          
      │                                             
      ▼                                             
   [已取消]

状态：待支付 / 已支付 / 已发货 / 已完成 / 已取消
事件：支付成功、发货、确认收货、取消、超时
规则约束：比如”已完成”不能再跳回”待支付”——非法转移被禁止

5. 两种经典类型（了解即可）

类型	输出取决于	一句话
Moore 机	只由当前状态决定输出	输出跟”你在哪个状态”绑定
Mealy 机	由当前状态 + 输入共同决定输出	输出跟”状态 + 触发事件”绑定

日常写业务代码不太需要区分这两者，理解”状态 + 事件 → 转移”这个核心就够了。

6. 极简代码示例

用一张”转移表”实现，比一堆 if/else 清晰得多：

# 状态 -> { 事件: 下一个状态 }
transitions = {
    "待支付":  {"支付成功": "已支付", "取消": "已取消"},
    "已支付":  {"发货": "已发货"},
    "已发货":  {"确认收货": "已完成"},
    "已完成":  {},
    "已取消":  {},
}
 
def next_state(state, event):
    rule = transitions.get(state, {})
    if event not in rule:
        raise ValueError(f"状态[{state}]下不允许事件[{event}]")  # 非法转移被拦截
    return rule[event]
 
s = "待支付"
s = next_state(s, "支付成功")   # -> 已支付
s = next_state(s, "发货")       # -> 已发货

7. 应用场景（状态机无处不在）

网络协议：TCP 连接的 CLOSED → SYN_SENT → ESTABLISHED → ... → CLOSED
词法/语法分析：正则引擎、编译器的词法分析器本质是状态机
UI 交互：按钮的 idle / hover / pressed / disabled
游戏开发：敌人 AI 的巡逻 / 追击 / 攻击 / 逃跑
业务流程：订单、审批、工单的状态流转
AI Agent 的运行循环：思考 → 调工具 → 观察 → 再决策，本质是状态间的流转（见下）

8. 和 AI Agent 的关系（为什么会关联到这）

状态机是通用 CS 概念，不专属于 agent，但它是理解现代 agent 运行机制的底层模型：

Agent 的 运行循环（模型思考 → 调用工具 → 看结果 → 再决策）就是不断在状态之间转移
ReAct（Thought → Action → Observation → 循环/结束）可以直接画成一个状态机
LangGraph 的 graph-based runtime 更是把这点显式化——用”节点=状态、边=转移条件”的图来定义 agent 执行流程，就是状态机思想的直接工程化

详见 ../ai-agent-guide/agent.md。

9. 常见误区

❌ “状态机是 AI/agent 专属概念” → 错。它是通用模型，网络、编译器、UI、游戏里到处都是
❌ “状态越多越好” → 状态过多会”状态爆炸”，难维护；应保持状态最小、语义清晰
❌ “用一堆 boolean flag 也一样” → 多个 flag 组合出的隐式状态难以枚举和验证，显式状态机更安全
❌ “所有状态机都有终止状态” → 循环型（如红绿灯、协议保活）没有终点，一直转移

10. 延伸阅读 / 关联概念

有限状态机 (FSM) / 下推自动机 / 图灵机 — 自动机理论里的层级，FSM 是最基础的一层
状态图 (Statechart) — Harel 提出的扩展，支持嵌套状态、并发状态，比 FSM 更强
XState — JS 里流行的状态机库，把状态机工程化
AI Agent 运行机制 — 见 ../ai-agent-guide/agent.md，agent 循环 / LangGraph 本质是状态机思想

第二大脑 / Knowledge Bank

探索

state-machine