在做实时语音交互时，很多开发者一开始都会关注这些问题：
* WebRTC 怎么接麦克风
* 音频延迟能不能再低一点
* ASR / TTS 用哪家效果更好
这些当然重要，但只要你真正开始做**可插嘴（barge-in）的语音交互**，你很快就会遇到一个更棘手的问题：
> **系统到底知不知道自己现在在干什么？**
如果这个问题回答不上来，
那么"中断"这件事，迟早会把系统搞乱。
一、先明确一个结论：中断不是音频问题，而是状态问题
很多项目里，"中断"通常是这么实现的：
* 检测到用户说话
* 直接 stop 当前音频播放
* 重新开始一轮识别
表面上看，这好像能用。
但在稍微复杂一点的场景下，就会出现：
* 声音停了，但模型还在生成
* 新一轮输入进来，旧上下文没清
* 有时能打断，有时不行
根本原因只有一个：
> **系统没有一个统一、明确的状态来源。**
二、为什么 WebRTC 本身解决不了这个问题
WebRTC 的定位其实非常清晰：
* 音频采集
* 音频播放
* 网络传输
它解决的是 **I/O 问题**，而不是 **行为决策问题**。
WebRTC 并不知道：
* 现在系统是否"正在说话"
* 插嘴是否应该生效
* 当前这段音频是否还能继续播
如果把这些逻辑硬塞进 WebRTC callback，
结果通常只有一个：**状态越来越乱**。
三、正确的思路：引入状态机作为系统中枢
在一个可靠的实时语音系统中，
**状态机（FSM）应该是系统的"中枢神经"**。
它只负责三件事：
-
当前系统处于什么状态
-
收到一个事件，是否允许状态迁移
-
是否触发中断、清理、切换执行权
其他模块（WebRTC、ASR、LLM、TTS）
只做一件事：**产生事件或执行副作用**。
四、推荐的整体架构（工程实战向）
```
┌───────────────┐
│ 前端 / PWA │ ← 按钮、设备、状态展示
│ (JS / React) │
└───────▲───────┘
│ 控制事件
│
┌───────┴────────┐
│ WebRTC 层 │ ← 音频输入 / 输出
│ (AudioTrack) │
└───────▲────────┘
│ 音频帧 / VAD
│
┌───────┴──────────────────────┐
│ Rust 语音 Runtime（FSM） │
│ - 状态机 │
│ - 事件队列 │
│ - Cancel / 清理逻辑 │
│ - ASR / LLM / TTS 协调
└───────────────────────────────┘
```
**关键点只有一句话：**
> 所有"是否应该继续 / 是否应该中断"的判断，
> 都只能发生在 FSM 中。
五、用"事件化"避免系统失控
1. 音频输入不做判断，只产出事实
在 WebRTC AudioTrack 中，只做最基础的处理：
```
AudioFrame
↓
VAD / 能量检测
↓
Event::VadSpeechStart / VadSpeechEnd
```
是否中断、是否忽略，
**一律交给 FSM 决定**。
2. ASR / LLM / TTS 统一成事件流
统一抽象非常重要：
* ASR partial / final
* LLM token / completed
* TTS frame（只在 Speaking 状态消费）
FSM 的判断逻辑非常清晰：
> **当前状态，是否允许处理这个事件？**
六、FSM 的核心运行方式（避免回调地狱）
整个语音 Runtime 的核心，其实非常简单：
```rust
loop {
let event = event_rx.recv().await;
state = state.on_event(event);
}
```
含义是：
* callback 里不写业务逻辑
* async 只负责生产事件
* FSM 永远是唯一的决策点
这一步，直接决定系统能不能"被安全中断"。
七、音频输出的正确控制方式
一个非常常见的错误是：
> 在 WebRTC callback 里直接 stop 播放。
正确的方式应该是：
```
TTS Generator
├─(有界 channel)─▶ WebRTC AudioTrack
```
当中断发生时：
-
FSM 触发 cancel token
-
TTS 停止生成音频帧
-
channel 自然关闭
-
WebRTC 播放自然结束（不会爆音）
WebRTC **完全不知道"中断"这个概念**，
它只是在消费数据。
八、一条完整的插嘴（barge-in）流程
```
Speaking
↓
WebRTC 检测到麦克风语音能量
↓
VAD → Event::VadSpeechStart
↓
FSM 决策中断
↓
Cancel TTS
↓
FSM → Interrupted
↓
ASR Final
↓
FSM → Listening / Repair
```
如果你的系统中找不到这样一条**清晰的流程**，
那它在并发场景下一定会出问题。
九、为什么 FSM 更适合放在 Rust
并不是因为"Rust 性能更好"，而是因为：
* 状态是 enum，可枚举、可检查
* 状态迁移是 match，可审计
* 中断是协议，不是副作用
在 JS 里，这些往往会被 async / Promise 打散，
最终变成隐式状态。
十、总结
> 在 WebRTC 实时语音系统中，
> 状态机不是优化选项，
> 而是系统是否还能继续演进的基础。
当你开始支持：
* 插嘴
* 多轮对话
* 错误恢复
你最终都会回到同一个结论：
> **行为，必须由状态机托住。**