UI 状态机（state machine） 前端与交互

它是什么

UI 状态机（state machine）把流式界面建模为显式状态 + 纯函数转移：事件（wire 事件 + 本地事件）是唯一的转移输入，状态机的六个状态（idle/streaming/waiting_approval/interrupted/done/error）决定每个事件是否合法。它解决的核心问题是：状态不再藏在 DOM 各个角落，任何时刻都有一份显式的状态机在回答「现在界面上到底是什么」。

六态与转移

streaming 是主战场（文本、工具、审批前的所有事件都在这里消费）；waiting_approval 是暂停（审批门把流钉住，approval_result 必须 requestId 匹配才放行，乱序或过期的审批结果不会误放行）；interrupted 是冰封（进入后所有 wire 事件被丢弃，只有旧流的 done/error 能解冻、关闭回合并触发排队）；done/error 是终态，也是「下回合的起点」（user_input 可从任意非忙碌状态开新回合，done 自动排空输入队列）。

为什么用状态机而不是散落的 if

流式界面的本质是事件驱动的状态：同样一段话可能是「正在生成」「已完成」「被打断」，一个工具调用有「发起/执行中/成功/失败」四种状态，被几十个乱序到达的事件反复改写。状态机把「哪些事件在当前状态合法」变成结构化规则——每个事件先过状态守卫，不合法原样丢弃。这是本教程反复出现的那条线：core 发事件、界面表达，界面自己的状态也要「事件化」。

在本教程的位置

第 17 章用 mermaid 状态图给出六态转移，reduceViewModel 的 switch 就是状态机；OpenAI Responses API 的细粒度流式事件与 OpenAI Agents SDK 的条目级生命周期事件是同一思想的厂商实践。