很多人在做 WebRTC 语音交互时，会自然地把注意力放在这些问题上：
- 音频延迟怎么降
- codec 选 Opus 还是别的
- ASR / TTS 的实时性够不够
这些都重要，但只要你尝试过可插嘴（barge-in）的实时语音交互，你很快会发现：
真正让系统崩掉的，从来不是音频质量，
而是状态失控。
一、问题不是“怎么停声音”，而是“系统知不知道该不该停”
很多系统在插嘴时的真实表现是：
- 声音停了
- 但模型还在生成
- 下一轮输入进来，状态已经污染
表面看是音频问题，
实际上是：
系统不知道自己现在处在哪个执行阶段。
这类系统通常有这些特征：
- 状态藏在 callback 或 async 里
- 用几个 flag 勉强“对齐时序”
- 逻辑靠“刚好没撞上”在暗中支撑
一旦引入 streaming + 并发，这种结构必炸。
二、正确的抽象：FSM 不是功能模块，而是系统锚点
在一个严肃的实时语音系统中，
状态机（FSM）不应该是“某个组件”，
而应该是整个系统的 System Anchor。
它只负责三件事：
- 当前系统状态是什么
- 收到一个事件，是否允许迁移
- 是否触发中断、清理、切换执行权
所有其他模块，只是 I/O 或副作用。
三、推荐的整体结构（工程结论先行）
┌───────────────┐
│ PWA / UI │ ← 设备、按钮、状态展示
│ (JS / React) │
└───────▲───────┘│ 控制事件│
┌───────┴────────┐
│ WebRTC Layer │ ← 音频输入 / 输出 / 网络
│ (AudioTrack) │
└───────▲────────┘│ audio frames / vad│
┌───────┴──────────────────────┐
│ Rust Voice Runtime (FSM) │
│ - 状态机 │
│ - 事件队列 │
│ - Cancel / Cleanup │
│ - ASR / LLM / TTS 协调
└───────────────────────────────┘
关键原则：
- FSM 不在前端
- FSM 不写在 WebRTC callback
- FSM 是唯一有“裁决权”的地方
四、WebRTC 在这里到底负责什么（别高估它）
在这套架构里，WebRTC 的职责非常克制：
- 提供音频输入
- 播放音频输出
- 负责网络传输
它不负责：
- 是否该说话
- 是否该停
- 是否允许插嘴
这些都是行为决策，不属于 WebRTC。
五、事件化是避免系统失控的关键
1. 音频输入只产生“事实”，不产生判断
在 AudioTrack 中，只做一件事：
AudioFrame↓
VAD / 能量检测↓
Event::VadSpeechStart / VadSpeechEnd
是否中断、是否忽略、是否迁移状态，
完全交给 FSM。
2. ASR / LLM / TTS 一律事件化
统一成事件流：
- ASR partial / final
- LLM token / completed
- TTS frame 只在 Speaking 状态消费
FSM 只关心一件事：
在当前状态下，这个事件是否合法？
六、FSM 的核心运行模型（避免回调地狱）
Runtime 的核心循环非常简单：
loop {let event = event_rx.recv().await;state = state.on_event(event);
}
这意味着：
- 没有业务逻辑藏在 callback
- async 只是生产事件
- FSM 永远是同步、可审计的
这是系统能否“被中断”的根本。
七、音频输出的正确控制方式
最常见的错误是：
在 WebRTC callback 里直接 stop 播放。
正确模式是：
TTS Generator├─(bounded channel)─▶ WebRTC AudioTrack
中断发生时：
- FSM 触发 cancel token
- TTS 停止生产音频帧
- channel 自然关闭
- WebRTC 播放自然结束
WebRTC 完全不知道“中断”这件事。
八、一条真实的插嘴（barge-in）路径
[Speaking]↓
WebRTC AudioTrack 检测到语音能量↓
VAD → Event::VadSpeechStart↓
FSM 决策中断↓
Cancel TTS↓
FSM → Interrupted↓
ASR Final↓
FSM → Listening / Repair
如果你的系统里找不到这样一条清晰路径，
那它迟早会在并发场景下失控。
九、为什么 FSM 更适合放在 Rust
原因并不神秘：
- 状态必须是可枚举的（enum）
- 迁移必须是显式的（match）
- 中断必须是协议，而不是副作用
在 JS 里，这些往往会被 async / closure 稀释掉。
Rust 不是更快，
而是更难写出状态不清的系统。
十、总结
在实时语音系统中，
FSM 不是锦上添花，
而是你是否还能继续扩展系统的分水岭。
当系统开始支持：
- 插嘴
- 多轮对话
- 错误恢复
你最终都会回到同一个结论：
行为必须被状态机托住。