当前位置：首页 > news >正文

WebRTC 实时语音交互如何支持“可中断”？为什么状态机（FSM）是绕不开的方案

news 2026/5/12 12:32:36

在做实时语音交互时，很多开发者一开始都会关注这些问题：

* WebRTC 怎么接麦克风
* 音频延迟能不能再低一点
* ASR / TTS 用哪家效果更好

这些当然重要，但只要你真正开始做**可插嘴（barge-in）的语音交互**，你很快就会遇到一个更棘手的问题：

> **系统到底知不知道自己现在在干什么？**

如果这个问题回答不上来，
那么“中断”这件事，迟早会把系统搞乱。

---

## 一、先明确一个结论：中断不是音频问题，而是状态问题

很多项目里，“中断”通常是这么实现的：

* 检测到用户说话
* 直接 stop 当前音频播放
* 重新开始一轮识别

表面上看，这好像能用。
但在稍微复杂一点的场景下，就会出现：

* 声音停了，但模型还在生成
* 新一轮输入进来，旧上下文没清
* 有时能打断，有时不行

根本原因只有一个：

> **系统没有一个统一、明确的状态来源。**

---

## 二、为什么 WebRTC 本身解决不了这个问题

WebRTC 的定位其实非常清晰：

* 音频采集
* 音频播放
* 网络传输

它解决的是 **I/O 问题**，而不是 **行为决策问题**。

WebRTC 并不知道：

* 现在系统是否“正在说话”
* 插嘴是否应该生效
* 当前这段音频是否还能继续播

如果把这些逻辑硬塞进 WebRTC callback，
结果通常只有一个：**状态越来越乱**。

---

## 三、正确的思路：引入状态机作为系统中枢

在一个可靠的实时语音系统中，
**状态机（FSM）应该是系统的“中枢神经”**。

它只负责三件事：

1. 当前系统处于什么状态
2. 收到一个事件，是否允许状态迁移
3. 是否触发中断、清理、切换执行权

其他模块（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
```

当中断发生时：

1. FSM 触发 cancel token
2. TTS 停止生成音频帧
3. channel 自然关闭
4. 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 实时语音系统中，
> 状态机不是优化选项，
> 而是系统是否还能继续演进的基础。

当你开始支持：

* 插嘴
* 多轮对话
* 错误恢复

你最终都会回到同一个结论：