声网RTC+MQTT替代WebSocket：AI语音交互设备架构解耦实战

引言

当前AI语音交互设备开发中，大多数方案基于WebSocket构建语音通道。这种做法虽然简单直接，但在设备与服务端耦合度、跨平台通信、低带宽环境适配等方面存在明显短板。B站UP主王师兄基于自己的嵌入式开发板项目，分享了一套采用声网Agora RTC + MQTT协议替代传统WebSocket的语音交互系统架构方案，实现了设备端与服务端的完全解耦，具备商用级的稳定性和可扩展性。

为什么要抛弃WebSocket方案？

传统WebSocket方案的痛点

目前市面上主流的AI语音交互方案，无论是开源项目还是商业产品，基本都依赖WebSocket作为语音数据和信令的传输通道。这种架构下，设备端与服务端是强耦合的——服务器一旦没有启动，设备端就无法正常联网工作，整个系统直接不可用。

WebSocket是基于TCP的全双工通信协议，诞生于2011年（RFC 6455），最初设计目标是解决HTTP协议无法服务器主动推送的问题。然而在嵌入式IoT领域，WebSocket的设计假设暴露出结构性缺陷：协议本身需要维护持久TCP连接，一旦服务端不可达，客户端即进入不可用状态；其次，WebSocket没有内置的QoS（服务质量）机制，在弱网环境下丢包处理完全依赖上层应用自行实现；此外，完整的WebSocket协议栈在ESP32等MCU上的ROM占用通常在50-100KB量级，对于只有4MB Flash的设备而言压力不小。

对于嵌入式设备而言，WebSocket协议在ROM内存占用上也相对较大。在ESP32等单片机开发中，内存空间和资源消耗是开发者时刻需要关注的核心问题。

RTC + MQTT双通道架构的优势

王师兄将系统改造为声网Agora RTC负责语音通道，MQTT负责信令通道的双通道架构。这种将信令通道（Signaling）与媒体通道（Media）分离的设计，实际上是电信级实时通信系统的经典架构模式，其历史可追溯到SIP（会话初始协议）的设计——SIP协议本身只负责会话的建立、修改和终止，实际的语音数据通过独立的RTP流传输。在本方案中，MQTT承担信令角色（设备状态上报、会话控制、LLM响应文本下发），声网RTC承担媒体角色（双向音频流），两者各司其职，故障互不影响。

这种设计带来了几个关键好处：

• 设备与服务端完全解耦：即使服务器未启动，设备也能正常连接声网通道或MQTT的EMX服务器
• 设备与设备之间独立运行：每个终端都是独立节点，通过频道机制灵活组合
• MQTT协议更轻量：低延时、低带宽，在嵌入式设备上的ROM占用远小于WebSocket
• RTC保障音频质量：即使在弱网环境下，也能保证稳定的音频传输质量

MQTT（Message Queuing Telemetry Transport）由IBM于1999年为石油管道SCADA系统设计，其核心设计哲学是「为不可靠网络上的受限设备服务」。协议头最小仅2字节，相比HTTP的数百字节头部开销，在带宽受限的蜂窝网络（如2G/NB-IoT）上优势极为显著。MQTT采用发布/订阅（Pub/Sub）模型，通过Broker（代理服务器）解耦消息发送方与接收方——这正是实现设备与服务端解耦的关键机制。协议内置三级QoS保障信令可靠性，还支持遗嘱消息（Will Message）机制，设备异常断线时Broker会自动发布预设消息，非常适合IoT设备的在线状态管理。

跨平台通信：一套协议覆盖所有终端

统一的RTC通信协议

这套架构最大的亮点在于其跨平台扩展能力。基于RTC协议，无论是ESP32嵌入式设备、手机APP、小程序、H5页面，还是Linux设备端，都可以通过同一套通信协议实现互联互通。

RTC（Real-Time Communication）实时通信技术的底层基础是WebRTC标准，由Google于2011年开源并推动纳入W3C/IETF标准体系。其核心传输层使用的是SRTP（安全实时传输协议）over UDP，而非TCP——这是与WebSocket最本质的区别。UDP的无连接特性使得RTC在网络抖动、丢包场景下能够通过FEC（前向纠错）、JitterBuffer（抖动缓冲）、NetEQ等算法主动补偿，而不是像TCP那样等待重传导致延迟累积。声网Agora在WebRTC基础上构建了自己的SD-RTN（Software Defined Real-time Network）全球加速网络，通过智能路由在国内外复杂网络环境下将端到端延迟控制在100ms以内，这是其相比原生WebRTC的核心商业价值所在。

具体的多平台接入方式如下：

• ESP32设备端：基于ESP32的C语言SDK创建房间
• 手机APP端：基于移动端SDK创建房间
• Linux设备端：基于Linux版本的RN架构SDK创建房间
• 小程序/H5：基于Web SDK接入

只要保证两个设备在信令服务器上处于同一个频道中，就能实现实时通话。代码层面不需要做大幅修改，只需遵循各平台SDK的规范即可。

可扩展的应用场景

这套方案不仅限于AI语音聊天，还可以扩展到多种实时通信场景：

• 语音对讲：类似对讲机的实时语音通信
• 多人会议：多人实时语音会议室
• 门禁系统：远程语音对话与控制
• 设备间通话：ESP32板子与Linux板子之间的跨设备实时通话

服务端架构改造与技术选型

基于小智开源项目的深度改造

王师兄的服务端基于开源项目"小智