直接说结论把 AI 玩偶从“能对话”做成“连续对话”关键不在模型选得多大而在音频链路的实时性设计。我这次用 ESP32 搭配 WebSocket 二进制帧重构了整个音频通路把原来一拍一停的按键式对讲改成了可以随时打断、连续轮流的自然会话体验。这篇文章就把完整方案拆开讲透覆盖链路设计、协议帧格式、数据处理、时序控制和踩坑记录给做智能玩具、桌面机器人、语音交互硬件的朋友一个可以直接复用的参考。1. 为什么“能对话”和“连续对话”是两码事很多人觉得玩偶能对话不就是“录音上传→拿回复→播放”三步吗确实很多早期方案就是这么干的也是市面上不少“智能玩具”的真实实现。但这种方案本质上还是 HTTP 短连接思维一段音频录完POST 上去等服务器把整段 TTS 结果生成完、合成完、返回来再开始播放。用户听到的永远是“你说完、它停顿几秒、然后机械回答”的节奏根本没有对话感。体验好的产品底层一定不是这个逻辑。1.1 传统方案到底卡在哪我拆过几款市面上的 AI 玩偶和语音助手设备交互链路基本都是这样用户按下按键开始录音录完松开整段音频上传到服务器服务端跑完 ASR语音识别→ LLM大模型→ TTS语音合成把完整音频文件返回设备下载完整音频后播放这个链路有三个致命问题。第一是延迟不可控一次完整请求下来顺利的话 2 到 3 秒服务端负载一高直接奔 5 秒去。第二是完全无法打断播放过程中用户说话没有任何途径让设备停下来只能傻等。第三是每轮都要重新建立连接、上传、下载网络开销巨大对电量和流量都是灾难。有朋友会说那我不按键用 VAD语音活动检测实现“唤醒→说话→自动结束→回复”行不行行但体验上只是把“手动按键”换成了“自动按键”本质上还是请求-响应模式用户必须严格遵循“说完停一下→等待→再继续说”的节奏真实对话里的人自然会觉得它很“笨”。1.2 “连续对话”的真实需求拆解真正自然的连续对话至少要满足四个条件全双工通路说话和接收回复可以同时进行至少要做到“边说边听”打断能力AI 在播报时用户一开口设备立刻能通过 VAD 检测到暂停播放、重新采集指令流式返回大模型回复不用等完整文本生成完TTS 边合成边下发设备边收边播低延迟从用户说完到 AI 开口控制在 500ms 到 800ms 以内人类对话的节奏感才能建立起来这些条件用 HTTP 那一套很难满足尤其是“低延迟”和“打断能力”这两条从架构上就要换成长连接、双向实时通信的链路。WebSocket 几乎是为这个场景量身定的它天然支持全双工、支持二进制帧传输、支持服务端主动推送迁移成本也不高。2. 为什么选 WebSocket 二进制帧而不是 JSON 文本这一步是架构落地最核心的决策点。我第一版原型其实用的是 JSON 文本传输把 PCM 音频 base64 编码后塞进 JSON 字段里。调通后发现两个问题一是虽然能跑但每一帧音频都要经过 base64 编码和解码CPU 占用率高尤其是 ESP32 这种资源受限的 MCU采样率一高就吃不消二是 JSON 本身有解析开销帧率一高串行化解析变成了瓶颈。后来我把协议改成 WebSocket 二进制帧直接传输裸 PCM 数据整体延迟降了 30%CPU 占用也明显下降。2.1 裸 PCM 还是 Opus 压缩这里有个计算过程先说采样率。语音识别侧主流模型常用 16kHz 采样率这也是 WebRTC、Kaldi、Whisper 的标准输入之一。16kHz、16bit、单声道每秒数据量是 16000 × 2 × 1 32000 字节也就是 32KB/s。这个体量在局域网或者 4G/5G 移动网络下其实不大WiFi 环境实测发送延迟稳定在 20ms 到 50ms 之间。但如果你要跑公网、跨国或者弱网环境32KB/s 就不算小了我会建议上 Opus 压缩。Opus 在 16kHz 语音场景下24kbps 码率就已经能达到不错的清晰度相比裸 PCM 的 256kbps 压缩了 10 倍以上。代价是 ESP32 端需要跑 Opus 编码器如果你想用 top-level 的 opus_encode API一条指令调用并不复杂但要注意踩内存和算力的坑。实测 ESP32-S3 240MHz 跑 Opus 编码一帧 20ms 语音编码耗时大约 3ms 到 5ms完全可以接受。如果做原型验证我建议先用裸 PCM把链路调通后再决定要不要上压缩。2.2 帧大小的选择逻辑音频采集端我选了 20ms 一帧。为什么不是 10ms 也不是 60ms10ms 一帧延迟最低但帧率太高每秒 100 个帧包WebSocket 包头、WiFi 网络包头的开销占比大幅上升而且 ESP32 处理中断过于频繁20ms 一帧每秒 50 帧16kHz × 2 × 0.02 640 字节净荷加上 2 到 4 字节自定义协议头一个包不到 650 字节网络效率高延迟也可控60ms 一帧延迟偏高服务端做 VAD 检测时要等足够长的缓冲才敢判定用户是否说完对话节奏受影响我做压测时对比过20ms 是延迟和带宽最平衡的点。这个值也是 WebRTC 和很多实时语音系统的标准选择生态兼容性好。2.3 二进制帧格式怎么设计才不会给自己挖坑裸 PCM 帧直接发肯定不行因为接收方不知道一帧从哪开始、到哪里结束也不知道这是音频数据还是控制指令。所以我设计了一个 4 字节头部 可变长负载的格式偏移长度字段说明01版本号固定 0x0111帧类型0x01音频帧0x02控制指令0x03心跳22负载长度大端序说明负载字节数音频帧的负载就是 640 字节的裸 PCM控制指令的负载是一段 JSON比如{type:start,sample_rate:16000}或者{type:stop,reason:vad_end}心跳帧负载为空用于长连接保活。这个设计的核心思想是把“数据”和“信令”放在同一个连接里传输但通过帧类型区分。这样服务端解析时先读 4 字节头部判断是音频还是信令再决定走哪条处理管线逻辑清晰调试时抓包也一目了然。3. 设备端 WebSocket 客户端与音频采集播放的实现这一节是整篇的硬核部分从硬件选型到代码结构我把直接可用的方案铺开来讲。3.1 硬件选型与接线我在这个项目里用的是 ESP32-S3-WROOM-1 模组的开发板选它的原因很直接240MHz 双核、内置向量指令加速、原生支持 I2S 外设、带 WiFi 和 BLE关键是性价比高。如果你只做原型ESP32 经典款也能跑但 S3 在做音频处理时算力余量明显更足双核可以一个核跑采集发送、一个核跑接收播放不容易被打断。音频采集端我用的是 INMP441 数字 I2S 麦克风接线是标准的 I2S 四线引脚INMP441ESP32-S3SCKSCKGPIO 4WSWSGPIO 5SDSDGPIO 6L/RGNDGND选择左声道播放端用 MAX98357A I2S 功放模块接一个 3W 小喇叭。接线类似BCLK 接 GPIO 15LRC 接 GPIO 16DIN 接 GPIO 17。两边共用 I2S 外设的话注意 ESP32-S3 有多个 I2S 控制器采集和播放可以分别挂在不同的控制器上避免时钟互相干扰。实测 INMP441 和 MAX98357A 共用同一个 I2S 总线也能跑但偶尔会有数据冲突分开更省心。3.2 工程配置ESP-IDF 环境的三个关键点我用 ESP-IDF v5.1 作为开发环境创建工程后需要配置几处关键项其一启用 WebSocket 客户端组件。新版 IDF 直接idf.py add-dependency esp_websocket_client即可组件本身基于 esp_http_client 实现支持 ws:// 和 wss://。其二打开全局事件循环。WebSocket 组件的连接、断开、数据接收事件需要事件循环来分发必须在 menuconfig 里确认Enable EVENT_LOOP已勾选。其三增加内存和栈配置。音频缓冲区、播放队列占内存较多建议在 menuconfig 里把Component config → ESP System Settings → Main task stack size调到 8192 以上。WiFi LwIP 的 socket 接收缓冲默认 4096 不够用改到 8192 或 16384否则高频音频帧容易被内核丢弃。3.3 核心代码结构三个任务加一个队列整个设备端程序我拆成三个 FreeRTOS 任务和一个共享队列// 音频帧队列生产者和消费者解耦 QueueHandle_t audio_tx_queue; // 接收播放队列 QueueHandle_t audio_rx_queue; // 任务1I2S 采集 - 队列 void task_mic_capture(void *arg) { int16_t pcm_buf[320]; // 20ms * 16kHz 320 samples while (1) { size_t bytes_read 0; i2s_channel_read(mic_channel, pcm_buf, sizeof(pcm_buf), bytes_read, pdMS_TO_TICKS(100)); if (bytes_read sizeof(pcm_buf)) { xQueueSend(audio_tx_queue, pcm_buf, 0); } } } // 任务2从队列取数据 - WebSocket 二进制帧发送 void task_ws_send(void *arg) { int16_t pcm_buf[320]; while (1) { if (xQueueReceive(audio_tx_queue, pcm_buf, portMAX_DELAY) pdTRUE) { uint8_t header[4]; header[0] 0x01; header[1] 0x01; // 音频帧 header[2] (uint16_t)sizeof(pcm_buf) 8; header[3] (uint16_t)sizeof(pcm_buf) 0xFF; // 拼包发送 uint8_t send_buf[4 sizeof(pcm_buf)]; memcpy(send_buf, header, 4); memcpy(send_buf 4, pcm_buf, sizeof(pcm_buf)); esp_websocket_client_send_bin(client, send_buf, sizeof(send_buf), pdMS_TO_TICKS(50)); } } } // 任务3接收播放 void task_ws_recv_play(void *arg) { // 由 WebSocket 事件回调喂数据到 audio_rx_queue // 本任务只负责从队列取数据并写入 I2S DAC }队列在这个架构里是核心。采集任务和发送任务通过队列解耦采集快了能自动积压采集慢了发送任务会阻塞等待不会互相踩踏。播放端同理WebSocket 回调收到二进制帧后解析、把 PCM 数据推入播放队列播放任务从队列取数据写 I2S这样回调里不做耗时操作避免阻塞 WebSocket 底层处理。3.4 WebSocket 事件的接收与解析ESP-IDF 的 esp_websocket_client 是通过事件回调上报数据的核心事件有WEBSOCKET_EVENT_CONNECTED、WEBSOCKET_EVENT_DISCONNECTED、WEBSOCKET_EVENT_DATA和WEBSOCKET_EVENT_ERROR。其中WEBSOCKET_EVENT_DATA回调里需要判断op_code如果等于 0x02 就表示收到的是二进制帧这时候data_ptr指向的就是原始二进制数据data_len是长度。我盘过的坑是ESP-IDF 官方的 WebSocket 客户端默认把收到的数据按文本推送如果服务端发送二进制帧需要手动识别 op_code。具体做法是static void ws_event_handler(void *handler_args, esp_event_base_t base, int32_t event_id, void *event_data) { esp_websocket_event_data_t *data (esp_websocket_event_data_t *)event_data; switch (event_id) { case WEBSOCKET_EVENT_DATA: if (data-op_code 0x02) { // 二进制帧解析自定义协议头 process_binary_frame(data-data_ptr,>
