半年前我把一块 ESP32-S3 开发板从防静电袋里拿出来的时候其实只打算做个玩具——一个能说话、能听懂几个简单指令的小盒子。结果做到第三个月团队内部的口径就变了大家开始认真讨论它到底该算一个硬件产品还是一套服务系统。这个定位问题恰恰是做 AI 陪伴设备时最容易被忽略、却最致命的事情。这篇文章整理了我们从一块板子到可持续演进的端云架构的完整路径。内容包括硬件选型复盘、端侧音频链路搭建、云端模型网关与会话记忆设计、弱网环境下的通信保障以及 OTA 和技能扩展这些后顾之忧。如果你正打算用 ESP32 系列做语音交互类硬件或者已经在做了但总觉得架构上撑不住后续迭代这篇应该能帮你省掉不少弯路。1. 先想清楚AI 陪伴设备到底要解决什么问题1.1 我们一开始犯的错把能对话当成了目标最早立项的时候团队给的描述是做一个能聊天的小机器人。这个描述听起来没什么问题但真正开始设计时才发现它完全没有回答一个关键问题用户为什么要持续使用这个设备而不是掏出手机打开某个 AI 应用手机上的 AI 助手已经足够强大了端侧硬件如果没有不可替代的价值做出来只会吃灰。我们后来把目标重新定义为三个具体场景一是独居场景下的随时可说不用解锁手机、不用点亮屏幕开口就能交互二是情感陪伴场景下的连续性记忆设备要记得你昨天聊过什么三是桌面场景下的低干扰存在它不抢注意力但你一转头就能看到它的状态反馈。这三个场景定义清楚之后整个架构的走向就完全不同了。你会发现随时可说意味着端侧必须有完整的音频采集、唤醒词检测和打断机制连续性记忆意味着云端不能只做无状态的大模型代理必须有会话存储低干扰存在意味着要有屏幕或者灯效来做非语言反馈。硬件选型、协议设计、服务分层全部都是从这三个场景反推出来的。1.2 给架构定一个能持续演进的基调可持续演进听起来像一句废话但在硬件项目里其实非常具体你不可能隔三差五让用户刷固件所以端侧要尽量薄把能改的部分都放在云端同时端侧又要保留足够的本地能力保证断网时不至于变成一块砖头。我们最终确立的架构原则是四句话端侧负责感知和响应不负责思考。云端负责智能和记忆但所有接口都要做到设备无关。协议层先定好版本机制后续字段只增不改。每次功能上线都要统计端侧到云端的完整链路指标而不是只看模型回答得好不好。这套原则贯穿了后面所有的开发决策。比如后来我们接入大模型时换了好几家服务商但因为模型网关层做得足够干净端侧和设备完全没有感知到底层变化。这个收益在前期投入时感觉不明显等真正上线迭代的时候才知道有多值。2. 硬件选型复盘为什么最终锁定 ESP32-S32.1 我们对比过的几个方案在锁定 ESP32-S3 之前我们实际评估过三条路线树莓派 Zero 2W、ESP32 经典系列、以及 ESP32-S3。树莓派的优势是算力强、Linux 生态成熟跑 Python 语音库毫无压力但劣势同样明显——功耗高、开机慢、尺寸大而且成本几乎是 ESP32-S3 的三到四倍。对一个需要 7x24 小时待机的桌面设备来说树莓派的方案在功耗和成本上都不太成立。ESP32 经典系列我们也测过问题集中在音频和 AI 加速上。经典 ESP32 的 I2S 接口虽然能用但处理 16kHz 双麦克风数据时 CPU 占用率很容易飙到 80% 以上再叠加 WiFi 协议栈的负载偶尔会出现音频采样丢失。ESP32-S3 相比经典系列最大的不同是内置了向量指令加速单元官方还提供了 ESP-DL 这样的神经网络推理库。这意味着唤醒词模型可以在端侧低延迟运行不用每次开机都去云端拉一个语音识别连接。2.2 ESP32-S3 在音频链路和 AI 加速上的真实底子先看硬件参数。ESP32-S3 是 Xtensa 双核 LX7 处理器主频最高 240MHz带了 512KB SRAM官方模组有 8MB 到 16MB 不等的 Flash 配置。对于语音交互场景最重要的其实是它内置的 I2S 外设、ADC 通道和 PSRAM 支持。我们用的 N16R8 模组带 8MB PSRAM这在跑音频缓冲和神经网络推理时非常关键——如果没有 PSRAM大一点的音频帧队列就会把内存榨干。音频这一块ESP32-S3 的 I2S 支持 TDM 模式理论上可以同时接入多路数字麦克风。我们在实际项目里用了双 INMP441 数字麦克风组成简单的波束成形采样率设在 16kHz、16bit 单声道这个配置在语音识别场景是性价比较高的选择。至于 AI 加速ESP-DL 提供的向量指令在跑轻量级唤醒词模型时确实有效一个参数量在 300KB 左右的 2D-CNN 模型推理耗时能控制在 80ms 以内电源电流的峰值波动也在可以接受的范围内。2.3 额外选型屏幕、麦克风与功放除了主控陪伴设备还涉及人机交互的几个外设这块我们也踩了不少坑。屏幕方面前期我们试过 0.96 寸 OLED发现显示汉字时锯齿严重、信息量不够后来换成了 GC9A01 圆形 LCD分辨率 240x240。GC9A01 是 SPI 接口接 ESP32-S3 的 SPI2 总线用 DMA 传输刷新率能到 30fps 以上显示表情动画绰绰有余。需要留意的是 GC9A01 的初始化序列比较挑剔不同批次屏幕的初始化参数可能有差异建议把寄存器配置单独做成一个模块方便适配不同批次。麦克风我们前面提到用了双 INMP441这里有个细节INMP441 的 L/R 引脚决定了它是在 TDM 时隙的左声道还是右声道两个麦克风一个接高一个接低才能在同一根数据线上分时传输。功放用的是 MAX98357A I2S 数字功放3W 输出驱动小喇叭直连 ESP32-S3 的 I2S 输出即可注意它的增益引脚 GAIN 要接对电阻否则音量会有明显的底噪。3. 端侧音频链路搭建从麦克风到可识别的对话流3.1 音频采集、回采消除与前端处理端侧音频链路是整个设备体验的地基。用户对陪伴设备最直接的感觉就是它听不听得清我说话这一步做不好后面云端模型再强都白搭。音频链路的第一个环节是采集。ESP32-S3 通过 I2S 接口从两个 INMP441 读取音频数据采样率 16kHz16bit 单声道。这里要特别强调 DMA 环形缓冲区的设计I2S 数据是持续不断流入的如果不做缓冲直接交给处理逻辑一旦 WiFi 任务抢占 CPU音频数据就会丢失。我们用了两个 DMA 描述符循环每个描述符挂 1.6KB 的缓冲区这样即使主核被短暂抢走也不至于丢帧。第二个环节是回声消除AEC。如果设备播放语音回复时还在采集麦克风信号麦克风一定会录到喇叭的声音导致语音识别把设备自己的回复识别成用户指令形成自问自答的死循环。ESP32-S3 芯片内部没有硬件 AEC我们用的是乐鑫 ESP-ADF 框架里自带的 AEC 算法基于 WebRTC 的 AEC3 移植而来。实际使用中需要把 I2S 播放的参考信号同步喂给 AEC 模块参考信号必须和硬件播放的是同一份数据时间戳对齐差了哪怕 20ms回声消除效果都会明显下降。第三个环节是降噪NS和自动增益控制AGC。我们的设备放在桌面上周围可能有风扇声、键盘声、远处的说话声。ESP-ADF 里提供了 NS 和 AGC 组件NS 的降噪程度是可调的设太高会把近端人声一起削掉我们最终拍板用中等强度再配合 VAD语音活动检测来判断用户是否真的在说话。3.2 唤醒词检测与本地 VAD 的配合唤醒词检测有三个主流方案一是用乐鑫的 esp-skainet 跑本地唤醒词模型二是用 ESP-DL 自己训练一个关键词模型三是直接音频流上云做全时识别。前两个是端侧方案第三个成本太高且依赖网络我们选的是第一个加部分自训练。esp-skainet 官方自带Hi乐鑫等唤醒词但我们需要自定义唤醒词比如小伴或者嗨小伴。自训练流程是采集 500 到 1000 条唤醒词音频、等量负样本音频用 M5STACK 提供的工具链训练小模型再通过 esp-skainet 的动态加载接口加载。这里有个很实用的经验不要把唤醒词模型和 VAD 混在一起。唤醒词模型只负责在持续音频流里识别特定词VAD 负责检测人声活动两者串行工作——VAD 先判断这一段有没有人声有人声才送唤醒词模型这样能大幅降低误唤醒和功耗。唤醒词命中之后设备进入聆听状态此时端侧会继续采集音频并实时计算音频中的语音段起始点VAD 的语音起点检测把从起始点开始的音频数据以 16kHz/16bit 的格式切片上传。整个流程的时序设计很关键我们最终做到了从唤醒到开始录音的响应时间在 150ms 到 250ms 之间这个体感上基本是随叫随到。3.3 端侧状态机离线也能响应的基础如果把端侧只当成一个采集音频、转发云端的管道那么一旦网络不稳定设备体验就会变得非常糟糕。我们在端侧设计了一个简单的状态机包含四个状态待机、唤醒、聆听、播放。待机状态下只有麦克风和唤醒词模块在工作电流控制在 80mA 左右唤醒后进入聆听边录边传播放状态由音频播放完成后自动回到待机。这个状态机的价值在于它让端侧具备了一定程度的离线兜底能力。比如断网时用户唤起设备后云端连接失败端侧会播放一段本地预置的提示音并显示一个离线表情而不是毫无反应。另外本地还预置了时间、闹钟、倒计时这类不需要云端的功能在网络恢复前设备依然有基本使用价值。这个设计回头看非常明智——它保证了产品在最坏情况下不是一块砖头也大大降低了售后的设备没反应类问题。4. 云端不是一个大模型那么简单模型网关与会话记忆层4.1 模型网关设备永远不直接绑定某个大模型很多初次接触 AI 硬件的开发者最容易犯的错就是把大模型的 API Key 直接写在固件里然后让设备 HTTP 调用大模型接口。这么做在 Demo 阶段没问题但一旦要上线立刻会遇到三个问题Key 泄露风险、模型服务商切换成本、以及无法统一控制流量和成本。我们的做法是在服务端加了一层模型网关所有设备请求先到网关由网关决定调用哪家模型。网关对外只暴露统一的对话接口内部把各家模型的请求参数、返回格式全部做了适配。这个设计带来几个直接好处换模型服务商不需要改固件可以在网关层做流式输出的缓存和重试可以用统一的 token 计量单位统计每个用户的实际消耗。4.2 会话记忆层设备怎么记住你昨天聊过什么陪伴类设备的灵魂是连续性。如果每次对话都是全新上下文用户聊了几次就会发现这个设备像第一次见我很快失去兴趣。但把所有历史对话全部塞进大模型上下文也不现实token 消耗和响应延迟都会失控。我们的会话记忆层分三级。第一级是短期记忆保留最近 10 轮对话内容随请求发送给模型第二级是长期记忆从每轮对话里抽取关键信息用户提到的名字、偏好、重要事件以结构化的键值对存入数据库第三级是今日总结每天结束时会生成一段当天的对话摘要作为次日的初始背景。这套设计与大模型能力结合得比较紧密例如通过一个专门的小模型或者一段强指令来抽取长期记忆字段再结合向量检索在请求时召回相关的历史记忆作为上下文的一部分拼接到系统提示词中。记忆层有个容易忽略的细节隐私。陪伴设备的数据几乎都属于敏感数据。我们在架构上就做了隔离设计用户原始音频数据只在端侧做临时处理上传到云端后经过 ASR 转成文本原始音频默认保存 24 小时后自动删除文本数据经过脱敏后才会进入记忆库。这个设计不仅合规也会在用户协议和产品宣传中成为信任点。4.3 技能扩展从聊天到能做事情一个陪伴设备如果只能聊天用户的新鲜感消退得会非常快。所以我们从第一天就给架构预留了技能扩展位。技能的形态是一个个独立的云端函数每个函数负责一件事查天气、设置提醒、播放白噪音、控制智能家居。网关在拿到用户意图后先做意图分类如果命中某个技能就调用对应的技能函数技能函数返回结构化结果再由大模型把这个结果组织成自然的语音回复。举个例子用户说明天早上八点提醒我吃药网关的意图模块识别为设置提醒把明天早上八点提醒吃药抽取成参数调用提醒服务写入数据库然后返回已经帮你定好明早八点的提醒了这句话。这个链路里大模型只负责自然语言理解和组织回复关键动作由确定性代码完成避免了大模型胡言乱语造成不可控后果。这里有个重要的架构决策技能调用必须和对话上下文隔离。也就是说技能函数的入参只能是网关解析出的结构化参数不能直接把用户原始输入传给技能函数。这样既保证了安全性也保证了技能可以被复用。5. 端云通信与配网弱网环境下的可用性保障5.1 通信协议选型MQTT 还是自定义 TCP设备与云端之间的通信协议我们纠结了很久。最初倾向于 MQTT因为生态成熟、支持 QoS、有大量开源 broker但实际测试后发现两个问题一是 MQTT 的报文头部相对较大在弱网环境下重传成本高二是 MQTT 的发布订阅模型和我们的请求响应模型不是完全匹配。我们最终选择了自定义的二进制协议跑在 TCP 长连接上应用层自己做心跳、重连和消息确认。设计这套协议时最重要的原则是可扩展所有消息都以消息类型开头服务端对未知消息类型可以安全忽略而不是报错。协议头里包含版本号支持一次请求带多个字段字段采用 TLV类型-长度-值格式存储。这样后续每增加一个功能只需要新增消息类型或字段不需要改变协议主体服务器和旧固件可以兼容运行。为什么不用 HTTP/WebSocket主要是设备资源受限HTTP 每次请求都要重建 header对 ESP32-S3 来说开销太大WebSocket 性能不错但协议本身在 embed 环境下依然偏重。自定义 TCP 协议看起来麻烦但一旦框架搭好后续维护反而轻松。5.2 弱网下的断线重连和幂等设计陪伴设备最常遇到的问题就是家里 WiFi 不稳定。我们的设备放在桌面距离路由器可能只有几米但依然会有信号抖动、路由器重启等意外情况。为此我们设计了比较完善的重连机制TCP 层每 30 秒发一次心跳连续 3 次心跳无响应则主动断开重连App 层每 5 秒检查一次消息队列如果有未确认的消息会按照指数退避策略重发。这里要特别强调幂等设计。设备端上传的每一条语音消息都有一个唯一 ID云端收到后先查重重复 ID 直接丢弃。这样做是为了避免设备端的重发和云端的重试导致两条相同的指令被重复执行。比如用户说播放白噪音如果这条消息被重复执行了设备里会同时响两段白噪音体验非常糟糕。有了幂等设计这类问题基本可以杜绝。5.3 BLE 配网流程把扫码变成靠近即连ESP32-S3 支持 WiFi 和 BLE 双模这给了我们一个优雅的配网方案。新设备开机后进入配网模式此时 BLE 广播名为AI-Co-XXXX的服务手机上的 App 扫描到该广播后通过 BLE 连接设备把 WiFi SSID 和密码发送过去设备收到后尝试连接 WiFi成功后通过 BLE 回传配网结果并自动退出配网模式。这套方案的体验远好于传统的 SmartConfig 或者 AP 配网。AP 配网要求手机先断开当前 WiFi 去连接设备热点用户操作成本高SmartConfig 兼容性太差很多路由器下根本扫不到。BLE 配网唯一的注意点是要做好 BLE 协议的安全验证——我们在配对时采用了一个简单的 challenge-response 机制设备的 MAC 地址后四位作为默认配对码用户在 App 端确认配对码后再进行后续数据传输防止配网参数被附近的其他 BLE 设备窃听。6. 可持续演进的关键OTA、技能扩展与可观测性6.1 OTA 升级不是能升级就行而是升级不失败硬件产品最常见的售后问题就是固件升级失败。我们把 OTA 设计成了三段式先下载固件到 OTA 分区校验 CRC 后写入激活区最后重启切换。固件包采用差分升级用乐鑫的 esp_ota_ops 接口实现差分包合成可以把 1.2MB 的完整固件压缩到 300KB 左右下载时间大幅缩短。OTA 还有一个容易忽略的细节回滚机制。我们在每次升级前把当前固件备份到备份分区新固件启动后如果 30 秒内没有上报健康状态心跳正常、WiFi 已连接设备会自动回滚到备份固件。这个机制在早期救了我们好几次——有一次新固件引入了内存泄漏设备在升级后 30 分钟内会自动重启如果没有自动回滚那个周末我们可能要处理几百台设备的售后。6.2 技能扩展的灰度发布思路云端技能上线不能一刀切。我们的做法是为技能设计了三档灰度内部测试只有白名单设备可以触发、小流量随机抽取 5% 用户触发、全量开放。灰度期间除了观察技能本身的成功率还要观察它对整体系统的影响比如是否导致模型网关延迟上升、是否拉高了 token 消耗。技能上线本质上和软件发布一样要先测再放量。技能的版本管理也很重要。我们给每个技能定义了语义化版本号网关在转发请求时会带上技能版本如果某次接口变更不向后兼容旧版本技能不会立即禁用而是通过一个过渡期逐渐把流量切换到新版本。这个设计和端侧 OTA 的迭代节奏形成互补端侧固件更新频率低云端技能迭代频率高两者通过协议兼容性解耦互不拖累。6.3 可观测性统计从唤醒到回复的每一环做硬件 AI 产品最怕的是不知道问题出在哪个环节。用户说设备没反应可能是麦克风坏了可能是唤醒词没识别可能是网络断了可能是云端 ASR 失败也可能是大模型超时。如果你没有一套端到端的链路追踪就只能靠用户描述和猜。我们在端侧和云端分别打了完整的日志和指标埋点。端侧指标包括唤醒信号出现时间、开始录音时间、音频上传完成时间、收到回复时间、开始播放时间。云端指标包括ASR 用时、意图识别用时、模型请求用时、响应生成用时、下行传输用时。通过时间戳对齐我们能在 dashboard 上还原一次完整对话的链路耗时分布哪一环慢了一目了然。实际投入运行后我们发现大部分响应慢的问题出在模型网关到 ASR 服务之间的网络延迟而不是端侧这直接影响了下一次架构调优的方向。7. 完整跑通一个对话流程从唤醒到语音回复7.1 典型对话的事件时序把前面的各个模块串起来看一次完整对话设备处于待机状态麦克风采集音频VAD 持续检测人声。用户说唤醒词嗨小伴VAD 先检测到人声活动随后唤醒词模型命中状态机从待机切换到唤醒并播放一个短促的提示音。状态机进入聆听开始录音。VAD 检测到用户说完话静音超过 800ms录音结束音频数据大约 2 到 6 秒通过 TCP 长连接上传到云端携带唯一的消息 ID。云端网关收到音频先查重然后调用 ASR 服务转成文本。文本进入意图分类模块识别出意图和参数。如果是普通聊天网关把文本和短期记忆、召回的历史记忆一起拼装成大模型的请求如果是技能类意图则先调用技能函数把结果拼装进大模型的提示词。大模型生成回复文本后网关调用 TTS 服务合成语音返回音频数据和文本。端侧收到后先做 AEC 参考信号缓存再通过 I2S 功放播放音频。播放结束后状态机回到待机一次完整交互结束。这个流程端到端的耗时我们实测WiFi 信号良好的情况下大概在 1.2 到 2.5 秒之间具体取决于大模型的响应速度。对陪伴设备来说2 秒以内是合理的交互体验超过 3 秒用户就会开始烦躁。7.2 交互体感优化的三个小细节第一个细节是边录边传而不是录完再传。如果等用户说完才开始上传整个链路会多出 2 到 4 秒的延迟。我们在 VAD 检测到语音起始点之后就开始流式上传音频分片边说边传语音结束后的最后一个分片到达云端时ASR 只需要处理很少的补全数据。这个改动让端到端时延下降了约 30%。第二个细节是回复文本先行。TTS 合成是需要时间的如果等 TTS 全部合成完再播放体验会很顿。我们采用流式 TTS第一段音频合成完就开始播放后面的音频边合成边传配合端侧的音频播放缓冲区可以实现说一句话只等 300ms的效果。第三个细节是非语言反馈。在等待云端回复的间隙设备屏幕会显示一个思考中的动态表情或者转一圈灯效。这些小反馈对陪伴感的影响非常显著用户不会觉得设备卡死了。8. 踩坑记录那些文档里不会告诉你的细节8.1 音频采样丢失问题出在 DMA 缓冲区而不是 I2S 外设项目中期我们遇到过一种偶发性问题用户说话时设备偶尔会漏听前面几个字。排查了很久一开始怀疑是麦克风虚焊后来怀疑是 I2S 配置问题最后通过抓取 DMA 缓冲区状态才发现问题是 WiFi 任务在高负载时比如正在下载 OTA 固件占用了 CPUI2S 数据在 DMA 环形缓冲区内被覆盖。解决方案有两层一是把 I2S 中断优先级调高确保音频 DMA 的中断不被 WiFi 任务阻塞二是把 DMA 环形缓冲区从 1.6KB 改为 4KB给音频数据更多缓冲余量。改动之后即使在 OTA 下载过程中音频采集也没有再出现过丢帧。8.2 I2S 参考信号没对齐AEC 判断听不到的根源另一个印象深刻的坑是 AEC 失效。现象是设备播放回复时麦克风把喇叭声音录进去ASR 把设备自己说的话识别成了用户指令造成设备自问自答。排查后发现我们把播放音频送进 AEC 的时序不对——AEC 模块需要的是即将播放的参考信号但我们却把已经播放完的数据喂给它时间差导致回声路径估计完全错误。修正方法是把 I2S 播放回调里的数据副本提前送入 AEC确保参考信号领先于实际声音到达麦克风的时间。调试 AEC 时最好用示波器同时测 I2S 输出和麦克风输入可以用一个 1kHz 的正弦波测试音频作为参考观察 AEC 输出中 1kHz 成分是否被有效抑制。8.3 模型网关的流式响应与设备播放节奏不匹配云端大模型支持的流式输出和端侧播放器的节奏很容易冲突。早期我们的 TTS 服务是一次性返回完整音频端侧播放没问题后来换成流式 TTS 后端侧播放器还没做好分段缓冲导致播放断续、卡顿。解决方案是在端侧播放模块里增加一个 FIFO 队列TTS 音频分片到达后先入队播放器按照固定节奏从队列取数据。队列的初始缓冲设为 500ms这样即使网络抖动 300ms播放也不会暂停。这个机制后来还帮我们省了一件事播放白噪音等长音频时无需在端侧单独实现长音频管理直接把音频流持续往队列里推就行。8.4 低功耗的悖论WiFi 长连接和待机电流的平衡待机功耗是陪伴设备绕不开的课题。设备需要随时接收云端推送比如用户通过 App 给设备发消息所以需要保持 WiFi 长连接但 WiFi 长连接本身就非常耗电实测 ESP32-S3 在 WiFi 连接状态下待机电流大约在 80 到 100mA靠电池供电坚持不了几天。我们的对策分两步一是默认使用电源适配器供电电池作为备用二是在电池模式下启用 ESP32-S3 的 Modem Sleep 模式WiFi 的 DTIM 间隔设为 3电台每 3 个信标周期唤醒一次。这个模式下待机电流能降到 20mA 左右基本够撑两三天虽然做不到超长待机但至少给了用户一个临时断电的缓冲。想要真正的低功耗只能走 BLE 网关方案让设备平时保持 BLE 广播、由网关代收 WiFi 消息这是下一步的优化方向。9. 回顾与下一步这套架构还能往哪里走做到现在这块 ESP32-S3 开发板已经变成了一个每天被团队实际使用的桌面设备。回顾整个搭建过程我最深的体会是端云架构不是端侧写代码、云端写接口那么简单它的核心是边界感——端侧负责什么、云端负责什么、数据在哪里落地、失败时谁兜底这些边界如果一开始不划清楚后面每加一个功能都要重构一次。下一步我们计划做三件事。第一把长期记忆的向量检索做得更细让记忆不仅是字段摘要还能按语义关联召回第二引入更丰富的端侧传感器距离、环境光、温湿度让设备能根据环境状态调整交互方式第三探索 BLE 网关的低功耗模式让设备真正脱离电源线成为移动陪伴体。如果你也在做类似的项目我的建议是先别急着追求模型的聪明把音频链路、状态机、断线重连、可观测性这些不性感的部分做扎实。陪伴设备用户最终记住的不是它哪句话回答得多精彩而是它是不是每一次叫它都在。