ESP32 AI玩偶全双工音频链路重构：从对讲机到连续对话

做这行最怕听到一句话：“你家玩偶怎么跟对讲机一样？”我们的 ESP32 AI 玩偶第一版上线后，用户反馈里高频出现三个字：要按键。孩子想问下一句，得再按一次，问快了还会被“正在播放中”拦下来。这个体验说实话很劝退。于是我们启动了 WebSocket 二进制音频链路重构，目标很明确：让玩偶从“录一段、传一段、答一段”的能对话模式，升级成边说边传、随时打断、无感切换的连续对话体验。这篇文章就把当时踩过的坑、趟过的路完整拆出来，包括协议帧设计、ESP32 端音频管线改造、服务端流式 ASR 协作、以及断线重连这些平时文档里不会细讲的环节，给正准备做类似项目的朋友做个参考。

先说结论：整个重构的收益不是延迟从 2 秒降到 1 秒这么简单，而是交互模型变了——设备始终在听，服务端始终在等下一句，用户不再需要“开始”这个动作。能做到这一点的前提，是把音频链路做成真正的全双工，而全双工的第一步，是先搞清楚旧架构为什么只能做到一问一答。

1. 从“对讲机”到“连续对话”：旧架构的问题到底出在哪

1.1 旧架构的模型：半双工的 PTT 模式

第一版玩偶的思路特别直白：按下按键 → 麦克风录音到内存 → 松开按键 → 把这整段音频通过 HTTP POST 上传 → 服务端做语音识别 → 拿到文本后调大模型 → 再把 TTS 音频整体下载回来播放。流程图写出来很短，但实际体验环节全是坑。

首先是录音阶段，玩偶就像一个录音笔，孩子说话必须等录音完全结束才能进入处理。而录音结束的判定是“按键松开”，这对低龄用户来说非常反直觉——小孩说话有停顿，停一下他们以为系统应该明白了，但实际录音还在继续。就算改成长按说话，也避免不了第二个问题：整段上传的等待时间。一段 3 秒的音频，按 16kHz 16bit 单声道算，大小约 96KB，走 HTTP POST 加上服务端排队、识别、生成，用户等到第一个字响起来，普遍要 3 秒以上。对成人还能忍，对小朋友来说这个间隔足够让他们觉得“它是不是坏了”。

但最致命的还不是延迟，而是通道方向。HTTP 上传完成之后，整个链路就断开了，服务端不知道设备还在不在听。玩偶在播放回答的整个过程中，麦克风是闲置的，用户就算中途插话，系统也收不到。这就是典型的半双工 PTT（Push-to-Talk）模式，本质上和用对讲机聊天没有区别。

1.2 连续对话的本质：不是“多传几次”，而是全双工

连续对话要解决的是四个问题：第一，音频要以流的方式持续上报，而不是攒成一整包；第二，服务端要能边收边识别，在用户还没说完的时候就给出中间结果；第三，设备播放回答的同时，麦克风仍然在监听，用户随时可以打断；第四，整个交互要维护一个会话状态，而不是每次交互都从零开始。

这四个问题叠在一起，HTTP 协议基本无从下手——它就是为请求-响应模型设计的。我们需要的是一个长连接、双向、低开销的传输通道，WebSocket 是当下最合适的选择。而 WebSocket 的文本帧和二进制帧之间，我们毫不犹豫选了二进制。这背后的原因值得展开说说，因为很多项目在这里栽了跟头。

2. 二进制帧的可设计性：音频协议头与分包策略

2.1 为什么放弃 JSON 文本帧：体积、解析开销和嵌入式友好度

最早我们内部也讨论过用 JSON + Base64 的文本帧方案。毕竟 WebSocket 天然支持文本帧，调试工具一抓包就能看懂内容，看起来很美。但算了一笔账之后就果断放弃了。

ESP32 这类资源受限设备，跑 JSON 解析和 Base64 编解码不是不行，但在音频流场景下，每 20ms 就要处理一帧，CPU 开销是实打实的。实测在 Arduino-ESP32 环境下，一帧 640 字节的音频做 Base64 编码大约要多耗时 300~500 微秒，看似不大，但乘以每秒 50 帧，就是 15~25ms 的额外 CPU 时间。更重要的是，文本帧的语义是“给你一段文本”，而二进制帧的语义是“给你一段结构化数据”，对音频这种定时产生的流式数据，后者才是正解。

2.2 自定义帧结构：12 字节的头里放了什么

我们最终定义的帧头是一个固定 12 字节的结构体，用 C 描述如下：

typedef struct __attribute__((packed)) { uint8_t magic; // 固定 0xAA，用于快速校验 uint8_t version; // 协议版本，当前 0x01 uint8_t type; // 帧类型：音频/文本/心跳/事件 uint8_t flags; // 位标记：START/END/PARTIAL/INTERRUPT uint16_t seq; // 序号，用于检测丢帧和乱序 uint16_t payload_len; // 负载长度，0~1024 uint32_t timestamp; // 采集时间戳，毫秒 } audio_frame_header_t; // 总长度 = 4 + 2 + 2 + 4 = 12 字节

这里每个字段都有它的用途，不是为了凑数。magic 是首道校验，避免把乱入数据当成有效帧；type 区分音频、事件、心跳，让同一条连接承载多种语义；flags 里最关键的是 START 和 END 标记——因为音频是流式的，服务端需要知道一句话从哪里开始、到哪里结束，才能正确切片交给 ASR；seq 用于接收端发现丢帧，尤其在 WiFi 不稳定的环境下；timestamp 则是为了后续做端到端延迟分析，没有时间戳，调优寸步难行。

音频负载本身，我们初期直接用裸 PCM，16kHz 采样率、16bit 量化、单声道，每 20ms 产生 640 字节负载。之所以选 20ms 一包，是因为主流流式 ASR 的分片窗口通常在 20~40ms，这也让单帧大小适中，即使丢一帧也只损失 20ms 语音，人耳几乎无感知。

2.3 粘包与半包：TCP 字节流的经典问题

WebSocket 本身有帧边界，到了应用层不会出现 HTTP 那种粘包问题——这是选它的一个重要理由。但如果你和我一样，在服务端直接用 WebSocket 库接收二进制消息，每个消息对应一帧，那这点基本不用操心。真正的坑出现在 ESP32 客户端库和部分网络中间层上：它们可能把多个小包合并成一个大包，或者把一个逻辑帧拆成多次收到。所以在解析层，必须自己做完整的“读包头-校验-读负载-组装”流程。

服务端 Python 端的解析我贴一段核心逻辑：

import struct HEADER_FMT = "<BBBBHHI" HEADER_SIZE = struct.calcsize(HEADER_FMT) def parse_frames(buffer: bytes): """从字节流中解析出完整帧，返回 (frames, remaining_buffer)""" frames = [] offset = 0 while len(buffer) - offset >= HEADER_SIZE: magic, version, msg_type, flags, seq, payload_len, ts = \ struct.unpack_from(HEADER_FMT, buffer, offset) if magic != 0xAA: # 数据错位，丢弃一个字节继续找 offset += 1 continue frame_total = HEADER_SIZE + payload_len if len(buffer) - offset < frame_total: break # 半包，等下一个数据块 payload = buffer[offset + HEADER_SIZE: offset + frame_total] frames.append({ "type": msg_type, "flags": flags, "seq": seq, "ts": ts, "payload": payload }) offset += frame_total return frames, buffer[offset:]

这段代码看起来简单，但有一个细节很重要：当数据错位时，不要盲目丢弃整个包，而是逐字节前进找 magic。因为 WiFi 环境下的偶发坏帧可能只破坏开头一两个字节，错位后内容仍然是完整的，逐字节扫描能救回大部分帧。我们上线初期大概 5% 的帧会经历一次这样的“自愈”，如果直接丢弃，用户听到的就是偶尔的丢字。

3. ESP32 端音频管线改造：从“录一段”到“实时流”

3.1 采集侧：I2S DMA 与环形缓冲的配合

ESP32 上的音频采集，走的是 I2S 外设接 PDM 或模拟麦克风。我建议用 ESP32-S3 + I2S 标准模式接模拟 MEMS 麦克风，或者直接用内置 PDM 的板载麦克风。无论哪种，核心都是靠 DMA 把 I2S 数据搬到内存，再由应用层定时读取。

采样的关键参数如下：

// ESP-IDF / Arduino-ESP32 下的 I2S 配置要点 // 采样率 16000，位宽 16bit，单声道 i2s_config_t i2s_config = { .sample_rate = 16000, .bits_per_sample = I2S_BITS_PER_SAMPLE_16BIT, .channel_format = I2S_CHANNEL_FMT_ONLY_LEFT, .communication_format = I2S_COMM_FORMAT_STAND_I2S, .dma_buf_count = 8, .dma_buf_len = 320, // 每个 DMA 缓冲 320 个样本 = 20ms @ 16kHz .use_apll = false, .intr_alloc_flags = ESP_INTR_FLAG_LEVEL1 };

DMA 缓冲数设为 8、每个缓冲 20ms，意味着底层可以缓冲 160ms 的音频。这个配置比较保守，但好处是抗抖动：即使主控被 WiFi 任务卡住一小会，音频数据也不会丢。代价是增加了约 160ms 的“隐性延迟”——录音时刻到真正发出时刻的间隔。在实际测试中，这个延迟完全可以通过后续的流式识别弥补，因为 ASR 不需要等整句话结束。

读取侧的逻辑就一句话：每隔 20ms，从 I2S 读出一帧 PCM，打入发送队列。

// 录音任务：持续读取 I2S 并投递音频帧 const size_t SAMPLES_PER_FRAME = 320; // 20ms @ 16kHz int16_t pcm_buf[SAMPLES_PER_FRAME]; size_t bytes_read = 0; while (running) { esp_err_t err = i2s_read(I2S_NUM_0, pcm_buf, sizeof(pcm_buf), &bytes_read, portMAX_DELAY); if (err == ESP_OK && bytes_read == sizeof(pcm_buf)) { // 投递到发送队列，由独立任务负责 WebSocket 写入 xQueueSend(audio_tx_queue, pcm_buf, pdMS_TO_TICKS(10)); } }

这里有个容易犯的错误：直接在 i2s_read 返回后调 WebSocket 发送。音频采集是硬实时任务，而网络发送可能因为 WiFi 拥塞阻塞几十毫秒，一旦阻塞，I2S 的 DMA 缓冲就会溢出，丢录音。正确做法是拆两个任务：录音任务只负责往队列丢数据，网络发送任务负责从队列取数据并写入 WebSocket。队列深度至少 16 帧，也就是 320ms 的余量。

3.2 设备端 VAD：全时上传的流量优化与判停辅助

全双工意味着设备会源源不断地上传音频，但如果环境里有电视声、空调声，这些背景音没必要全量送进 ASR。我们在设备端加了一个轻量能量 VAD（Voice Activity Detection），本质就是一个均方根能量计算：

uint32_t calc_rms(const int16_t *samples, size_t n) { uint64_t sum = 0; for (size_t i = 0; i < n; i++) { sum += (uint32_t)samples[i] * (uint32_t)samples[i]; } return (uint32_t)(sum / n); }

然后设定两个阈值：低于静音阈值时，帧标记为静音，仍然发送但带一个 SILENCE 标志；超过语音阈值后，进入说话状态。这样服务端可以根据标志跳过完全无声的段落，节省 ASR 的计算量。实测在安静的房间里，静音帧占比能到 60% 以上，去掉这些空转的帧，服务端 ASR 的压力小很多。

但这里必须提一个经验：VAD 只能用于“省流量、省算力”，不能依赖它判断一句话是否结束。原因很简单——人说话时语气词、呼吸、短暂停顿产生的能量波动非常复杂，单纯靠能量阈值判停，要么在用户思考时误判结束，要么在真正停顿时迟迟不响应。我们最终的判停逻辑放在服务端，综合了静音超时、ASR 端点检测和语义完整度三重信号。

3.3 播放侧：小缓冲抗抖动与打断机制

播放链路相对简单：服务端推回来的 TTS 音频帧（同样是二进制帧，type 标记为 AUDIO），先入播放队列，播放任务逐个解帧并写入 I2S 输出。这里唯一的参数取舍是播放缓冲深度。

音频播放对网络抖动非常敏感。如果我们完全实时播放，一个网络抖动 100ms，用户听到的就是声音卡一下，非常难受。我们的做法是在播放队列里预缓冲 4~6 帧，约 200~300ms，换取播放的连续性。代价是响应延迟增加了大约 200ms。在听感实验中，用户对“晚 200ms 开始说话”的容忍度，远高于“说话过程中卡顿”的容忍度。这一笔交易非常划算。

打断机制的难点在于全双工冲突：设备正在播放 TTS 时，用户的麦克风也在录音。如果播放出来的声音被麦克风采进去，服务端就会误判为“用户在说话”，从而触发打断。这就是回环啸叫的根源。我们第一版没有做 AEC（回声消除），采用了一个折中策略：播放 TTS 期间，设备端把麦克风增益降低 6dB，同时把 VAD 语音阈值临时提高一倍，这样只有真正近距离的人声才能触发打断，扬声器出来的声音基本被忽略。实测这个方案对正常对话场景够用，但如果是大音量播放音乐或是房间里环境音嘈杂，误触发率会上升。要彻底解决，得上带 AEC 的音频编解码芯片，比如 ES8311，或者用 ESP32 的 AEC 算法库，这是后续迭代的重点。

3.4 任务调度与内存：两个核怎么分

ESP32-S3 是双核，任务分配直接影响音频流的稳定性。我实测下来比较稳的组合：

• Core 0：录音任务（高优先级）+ 播放任务（中优先级）
• Core 1：WebSocket 网络发送/接收任务 + WiFi 协议栈

这样做的理由是：i2s_read 必须及时响应，否则 DMA 溢出；而网络任务和 WiFi 栈天然在一核上可以减少锁竞争。如果反过来把网络任务放 Core 0，WiFi 的周期性中断会抢占录音任务的 CPU，直接后果就是录音偶发缺帧，表现出来就是 ASR 识别率下降。

内存方面，ESP32-S3 有 512KB SRAM，但可用空间没想象中充裕。WiFi 缓冲、TLS、JSON 解析、TTS 播放队列、音频发送队列加起来，峰值占用大约 120KB 左右。我们的经验是：发送队列每帧 640 字节 + 12 字节头，16 帧深度约 10KB；播放队列同样 16 帧深度，约 10KB；两块内存加起来 20KB，完全可接受，不需要外扩 PSRAM 就能跑。

4. 服务端：流式 ASR 的拼接、断句与轮次管理

4.1 音频网关的整体设计

服务端我选了 Python FastAPI 做 WebSocket 网关，原因很直接：异步模型适合长连接场景，生态里对 ASR/TTS 的 SDK 支持最全。整体结构是这样：每个设备建立连接后，服务端维护一个 DeviceSession 对象，里面有一个 asyncio.Queue 用于缓冲从设备收到的音频帧，还有一个流式 ASR 客户端、会话状态、以及一个“是否正在 TTS 播放”的标记。

class DeviceSession: def __init__(self, ws: WebSocket, device_id: str): self.ws = ws self.device_id = device_id self.audio_queue = asyncio.Queue(maxsize=128) self.asr = None # 流式 ASR 会话 self.context = [] # 会话历史 self.tts_playing = False # 是否正在播放回答 self.speaking = False # 是否处于用户说话状态 @app.websocket("/audio") async def audio_endpoint(ws: WebSocket): await ws.accept() device_id = ws.query_params.get("device_id") session = DeviceSession(ws, device_id) consumer = asyncio.create_task(consume_audio(session)) try: while True: data = await ws.receive_bytes() await session.audio_queue.put(data) except WebSocketDisconnect: consumer.cancel()

这个网关最重要的职责不是转发数据，而是维护“这一句话到没到可以回答的程度”。判断逻辑在 consume_audio 里。

4.2 一句话什么时候算说完了：三层信号综合

前面提到不能只用静音超时判停，这里展开讲我们最终落地的三层判停机制。

第一层是设备端 VAD 标志。设备会持续上报 SILENCE 和 SPEECH，服务端统计当前这包数据的能量状态。第二层是流式 ASR 自身给出的端点检测，主流的云 ASR 服务在流式模式里通常会有 mid-result 和 final-result 两类回调，final 意味着它认为用户这句话已经说完。第三层是一个兜底静音计时器：收到最后一个 SPEECH 帧后，如果 1200ms 内没有新的语音帧，或者 15 秒的硬性超时，就强制截断。

拿“孩子说话停顿”的场景举例：小朋友说“妈妈我想”然后停了一下，ASR 的 mid-result 会先返回“妈妈我想”，静音计时器到 800ms 时我们不会触发结束，而是等待。如果他在 1200ms 内接着说了“买那个玩具”，ASR 的 final-result 会返回完整句“妈妈我想买那个玩具”，这时才触发回答。这就是三层信号各自的价值：VAD 告诉我们物理上有没有说话，ASR 告诉我们语义上是不是一个完整体，静音超时保证系统不会无限等下去。

4.3 流式 ASR 的分片喂入与中间结果

ASR 的调优里有个细节：不是每收到一帧就立刻喂给 ASR，而是攒成 60ms 的块再喂。原因是大多数 ASR 服务的流式接口内部也有自己的缓存窗口，喂太碎的包反而增加协议开销，每 60ms 一个块实测识别效果和 20ms 喂入几乎一样，但 CPU 占用低了很多。

喂入的同时，我们把 ASR 的 mid-result 缓存起来，但并不立即触发回答。这样做是为了覆盖“用户说了半句然后改口”的情况：比如孩子先说“我要吃”，然后马上改口“我要玩积木”。如果服务端在“我要吃”的 mid-result 阶段就拿着去问大模型，回答必然是跑偏的。正确做法是：只有 ASR 触发了 final-result，或者强制超时截断，才把完整文本送入大模型。mid-result 的作用只是给系统一个“它已经在说话了”的状态提示，可以提前初始化大模型连接、预热 TTS，缩短后续响应时间。

4.4 打断与轮次状态机

全双工服务的核心状态机一共四个状态：IDLE（空闲）、LISTENING（监听用户说话）、PROCESSING（识别+生成回答）、SPEAKING（播放 TTS）。

• IDLE：设备已连接，VAD 处于静音，等待语音激活。
• LISTENING：检测到用户开始说话，音频帧持续喂入 ASR。
• PROCESSING：一句话收尾，开始调用大模型生成回答。此时设备端仍在录音，但不喂 ASR。
• SPEAKING：TTS 音频流推送给设备播放。如果此时设备端 VAD 又检测到高强度人声，设备会主动发一帧 INTERRUPT 事件，服务端收到后立刻停止当前 TTS 流，把状态机拉回 LISTENING，并且把之前的大模型上下文保留在 session.context 里。

这个状态机的价值在于，它让“连续对话”有了可维护的上下文。孩子上一句问“狗为什么会叫”，下一句接着说“那猫呢”，服务端知道“那猫呢”是承接上一句的指代，而不是要求从头聊。这在老版本 HTTP 架构里几乎没法做，每次都是无状态会话，用户必须把问题问完整。

5. 弱网与断线：WebSocket 1006 和“假死连接”的排查

5.1 1006 到底在说什么

连续对话对连接稳定性的要求比普通 WebSocket 应用高得多。我们灰度期间收到最多的报警就是 WebSocket onclose code 1006。这个错误码的准确含义是“abnormal closure”——连接在没有正常 close 握手的情况下就断了。常见的根因有几类：

最隐蔽的是第二种：ESP32 开启 modem sleep 后，WiFi 模块会在无数据时进入休眠，接收唤醒需要等 DTIM 周期，短则几十毫秒，长则几百毫秒。如果恰好心跳包在这个窗口期内到达，设备没有及时响应，服务端或中间网关就可能判定超时。我们的解决方法是：连续对话场景下，音频是持续流动的，本身足够保活；一旦进入长时间静默，就把 modem sleep 的 DTIM 间隔调大，或者干脆暂时关掉 modem sleep，换 30~50mA 的电流消耗来换连接稳定。

5.2 应用层心跳与半开连接检测

WebSocket 协议自带 Ping/Pong 帧，但服务端库对 Ping 的支持不一，客户端库更是参差。我们直接采用应用层二进制心跳帧，type 为 HEARTBEAT，每隔 15 秒由设备发一帧，服务端必须回一帧 HEARTBEAT_ACK。

这里的 15 秒不是拍脑袋定的。云厂商的 NAT 空闲回收普遍在 60 秒左右，我们要在 3 个周期内完成检测——也就是 45 秒内设备必须发出至少 3 次心跳，因此 15 秒是安全裕量。设备端连续 2 次心跳无响应，就判定连接假死，主动关闭并触发重连。实测这个策略能把“连接看似还在、实际发啥都收不到”的半开连接时间控制在 30 秒以内。

5.3 断开重连：指数退避与会话恢复

重连策略上，最忌讳的是设备一断就连、一连就断、再断再连，形成风暴。我们用的是标准的指数退避加抖动：

• 第 1 次重连：1 秒延迟
• 第 2 次：2 秒
• 第 3 次：4 秒
• 第 4 次：8 秒
• 第 5 次及以后：16 秒封顶，每 5 次随机加 0~3 秒抖动

重连成功后，设备需要重新发送一次 HELLO 握手帧，带上 device_id。服务端根据 device_id 把旧会话上下文从缓存里捞出来，恢复到断线之前的状态。这意味着如果用户上一句刚问完“今天天气怎么样”，这时候 WiFi 闪断重连，恢复后他接着说“那明天呢”，服务端依然能理解“明天”指的是明天的天气。

6. 调优记录与实测数据：一步步抠出来的体验优化

6.1 端到端延迟拆解

连续对话的体验指标里，最核心的是“首字延迟”——从用户说完最后一个字，到玩偶发出第一个音节，中间隔了多久。我们把它拆成四段：

• 采集与上行：设备 VAD 判停到服务端收到最后一帧，约 20~40ms
• ASR 识别：流式识别最终结果返回，约 200~400ms
• 大模型生成 + TTS 首包：大模型流式吐字 + TTS 流式合成，约 400~700ms，这部分取决于模型速度，是最大的大头
• 下行播放：预缓冲 200ms

四段加起来约 900ms~1.4s，实际体验比较自然。重构前整段上传模式下，首字延迟是 2.5~3.5 秒，这个体感差异是革命性的。

6.2 关键调优点记录

第一个调优点是“TTS 首包抢跑”。最初我们是等大模型完整输出一句话后才让 TTS 开始合成，后来改成大模型每输出 10~20 个字就增量喂给 TTS，TTS 每产出 200ms 音频就立即下发。这样用户听到的声音是“边生成边说”，而不是“先生成完再说”，首字延迟直接少了 400ms。

第二个调优点是播放缓冲大小。刚开始我们预缓冲 100ms，网络好的时候流畅度不错，但一旦 WiFi 信号波动，就会出现明显的“一顿一顿”。改成 250ms 后，20% 以内的网络抖动基本听不出来，体验反而更好。慢 100ms 换稳定，这笔账太值了。

第三个点比较偏门：ESP32 的 WiFi 发送突发特性。由于 WiFi 是共享信道，发送任务经常出现“要么不发，要么一连发好几包”的突发行为，导致服务端收到音频帧的间隔不均。我们在服务端解析时不对帧到达时间做严格假设，完全以帧头的 timestamp 为准来重建时间轴，避免因为网络到达抖动而错误切分语音段。

6.3 上线后的问题清单与对策

这四个对策里，最耗我们精力的是第一个——自我打断。这个问题一度让用户以为玩偶“疯了”：自己说话自己打断自己。后面通过日志确认，确实是 TTS 功放的声音到达麦克风后，能量超过了 VAD 语音阈值。降增益和抬高阈值的组合拳效果明显，但这是软方案，如果想支持大音量播放同时保持灵敏的打断，还是得上真正的 AEC 算法。

6.4 重构后的真实体感变化

量化指标之外，我更想分享一个没法用数字体现的变化：用户不再把玩偶当成“会说话的玩具”，而是当成“能聊天的伙伴”。重构后玩偶一直处于待机倾听状态，孩子跟它说话不需要先叫名字或按按钮，说错了可以立刻改口，说一半停下来想一会儿再接着说，系统都能接得住。这种无感交互才是连续对话的核心体验。

如果你们也在做类似的设备端语音交互项目，我的建议是：先别急着上复杂的语义理解，把音频链路的全双工和稳定性做扎实——协议帧设计、设备端任务分配、服务端状态机、断线恢复，这四块是地基。地基稳了，后续加离线唤醒词、声纹识别、多模态理解都是水到渠成的事。这次重构我们踩过不少坑，但也确实验证了一件事：用 WebSocket 二进制音频链路承载流式语音交互，配合 ESP32 这颗芯片的能力，做一个体验合格的 AI 玩偶，完全可行。