我手里的这块 ESP32-S3 开发板按理说是玩物联网的老熟人了。但我一直觉得如果只是拿它连个 Wi-Fi 收发传感器数据多少有点屈才。真正让我下定决心搞事的是有一次我把它接到一个扬声器上再用 I2S 接口挂了一块数字麦克风准备做“能对话的 AI 陪伴设备”。第一版跑通的时候我说了一句“今天天气怎么样”等了几秒喇叭里真的传回了天气结果那一刻我意识到这不是小玩具这是一套完整的端云架构。整个项目用一句话概括就是设备端负责唤醒、录音、播放和本控云端负责语音识别、大模型对话和语音合成两端通过一套可持续演进的协议连接起来。对不是把大模型塞进单片机也不是做一个纯云端音箱而是让 ESP32-S3 这块小芯片做它擅长的事把重活交给云端再通过 OTA 和接口抽象让整套系统能不断升级。这篇文章我就把从硬件选型、固件实现到云端编排的全过程拆开讲清楚适合想做端云结合语音设备的开发者参考也适合对 AIoT 方向感兴趣但还没入门的朋友至少看完你能知道一条完整链路长什么样。1. 项目定调为什么非要做成套“端云架构”1.1 一块开发板能做的事和不能做的事ESP32-S3 的配置放在单片机领域不算低双核 Xtensa LX7 处理器主频能跑到 240MHz带有 512KB SRAM还能外挂 PSRAM支持 2.4GHz Wi-Fi 和 BLE 5.0I2S、PDM、SPI、UART 这些外设也一应俱全。这么看它确实比老 ESP32 更适合做音频相关产品因为双核可以一个核跑业务逻辑另一个核处理音频流或协议栈另外乐鑫的 ESP-SR 唤醒词引擎也能在它上面跑起来。但你要是真打算在 ESP32-S3 上本地跑一个像样的对话大模型那就想多了。哪怕是一个 1B 参数的小模型光权重就要几百 MB 起步而 S3 的外挂 Flash 和 PSRAM 容量根本不够算力也不在一个量级。语音识别ASR也一样本地跑一个受限词汇集还行真要开放领域的中文识别板子上撑不住。语音合成TTS更是如此效果好的声音模型动辄几十 MB解码还要消耗大量 CPU。所以当时我就下了个结论这个设备的“大脑”必须在云端。这不是偷懒是边界分工的必然。设备端几十到几百毫瓦的功耗、几百 KB 的可用内存决定了它只适合做四件事——“听、说、传、控”。听就是麦克风采集和唤醒词检测说就是解码云端返回的音频并播放传就是通过 Wi-Fi 把音频上传、把结果拉回来控就是控制指示灯、按键、屏幕和电源。云端则负责“听懂、思考、回答”这三件事两边加在一起才是一个完整的陪伴设备。1.2 端云边界的划分逻辑很多人做这类项目时会在边界上犹豫到底哪些东西放端侧哪些放云侧我的经验是不要按“技术难度”划分而是按“实时性、资源消耗、可更新性”这三个维度划分。设备端必须保留的部分包括唤醒词检测、录音、按键交互、状态灯/屏显、本地音频播放、电源管理和 OTA 升级。这些功能对实时性要求极高比如唤醒词必须在 100ms 内响应否则用户会觉得“叫不醒”这部分如果放到云端一次往返延迟就有几百毫秒而且必须时刻保持网络连接电量和体验都受不了。云端则承担ASR 识别、语义理解、多轮对话、知识检索、TTS 合成、内容安全过滤、用户画像和日志分析。这些功能资源密集且迭代频繁放在云端最大的好处是“今天改模型明天就能生效”用户设备完全不用动。我见过一些项目试图把语音识别也塞进设备端理由是“断网也能用”。但实测下来一个离线的语音识别模型加上 NLP 规则只能覆盖很少的固定句式用户一旦说得随意一点设备就变“人工智障”。对于 AI 陪伴设备来说开放对话能力才是核心所以我的边界划分很明确本地只做必然实时、必然低功耗的感知和控制其他全部上云。1.3 可持续演进到底指什么“可持续演进”这个词听起来像 PPT 黑话但在这个项目里它有非常具体的落地含义。第一层是固件可升级设备出厂后不是一锤子买卖通过 OTA 可以持续修复 bug、增加新交互。第二层是协议可兼容设备端和云端之间不能锁死一种数据结构必须带版本号方便云端升级后老设备还能工作。第三层是服务可替换ASR、LLM、TTS 三层服务全部做成可插拔适配器今天用这家的识别服务明天觉得另一家效果好切换到那边只需要改云端配置设备端一行代码都不用动。说白了我想要的不是一台“能聊天的音箱”而是一个能跟着模型进步、跟着服务升级、跟着用户需求长的硬件底座。底座不换上面的能力不断换新这才是“可持续演进”的真正含义。2. 硬件搭建ESP32-S3 周边怎么选、怎么接2.1 为什么选中 ESP32-S3其实市面上可选的方案不少树莓派也能做而且算力更强但功耗和体积都不适合做桌面陪伴设备价格也高。ESP32 经典版我也试过问题在于它没有专用向量指令跑唤醒词和音频处理的余量比较紧而且 BLE 是 4.2配网体验不如 5.0。ESP32-S3 在这两方面都做了补强双核 240MHz 跑音频流和 Wi-Fi 协议栈完全不冲突BLE 5.0 配网更快再加上 I2S 和 PDM 接口的支持几乎是这个价位上做语音终端的最优选择。S3 模组也有讲究别只看“S3”三个字就下单。我推荐选带 PSRAM 和较大 Flash 的版本比如 ESP32-S3-WROOM-1 N8R88MB Flash 8MB PSRAM预算够就上 N16R8。PSRAM 的作用在跑 HTTPS、TLS 加密、音频缓存和 JSON 解析时特别明显没有 PSRAM 的话内存经常在几个大任务同时工作时爆掉。Flash 大一点则是为了 OTA 双分区后面升级固件会轻松很多。模组型号FlashPSRAM适合场景ESP32-S3-WROOM-1 N88MB无简单传感节点不适合音频 AI 设备ESP32-S3-WROOM-1 N8R88MB8MB语音设备入门推荐性价比最高ESP32-S3-WROOM-1 N16R816MB8MB需要更多存储或复杂 OTA 策略的项目2.2 麦克风、功放与喇叭选型麦克风我前后试过三种方案模拟麦加运放、PDM 数字麦、I2S 数字麦。模拟麦需要对信号做前置放大和偏置电路电路面积大还容易被电源噪声干扰我第一次做的时候就是在这里踩了坑模拟麦采集到的人声里混着 50Hz 工频噪声怎么滤都滤不干净。PDM 麦接口简单但 PDM 数据流要靠 CPU 做抽取滤波抢占不少算力。最后我选了 INMP441 这款 I2S 接口的 MEMS 数字麦克风它直接输出数字音频信号不需要额外的放大电路只需接好 BCLK、WS、SD 三个引脚就能读到干净的 PCM 数据对新手非常友好。功放我用的是 MAX98357A这是一颗 I2S 输入的 D 类功放芯片3W 左右输出功率驱动 3W/4Ω 的小喇叭绰绰有余。它和 ESP32-S3 之间也只有三根线BCLK、LRCK、DIN和麦克风共用同一组 I2S 总线的时钟只是数据线分开。选它还有一个原因芯片自带增益设置引脚可以调节喇叭响度避免调试时突然爆音震耳朵。音频模块接口类型优点缺点模拟麦克风运放ADC成本低需额外电路信噪比难保证PDM 数字麦克风PDM引脚少需要 CPU 做 PDM 解调INMP441 I2S 数字麦I2S无需放大电路信号质量稳定单麦无定向降噪2.3 引脚接线与供电注意事项我的接线方案供参考INMP441 的 SCK 接 GPIO 4WS 接 GPIO 5SD 接 GPIO 6L/R 引脚直接接地表示数据在左声道输出MAX98357A 的 BCLK 接 GPIO 4LRCK 接 GPIO 5DIN 接 GPIO 7。这里要特别提醒一句GPIO 6、7 在部分 ESP32-S3 模组上默认连接 Flash 的 SPI 引脚使用前要确认你的板卡是否将这两个引脚引出否则会出现“看起来初始化成功但读不到数据”的诡异问题。稳妥做法是查阅板卡原理图换用 GPIO 15、16 这类安全引脚。供电是整个项目里最容易翻车的地方。MAX98357A 在音量较大时瞬间电流能到 1A 以上如果用 USB 线从电脑取电线材压降一大板子就会反复重启或者播放时出现“滋滋”声。我的做法是单独用 5V/2A 的电源适配器供电或者上一块 18650 电池加 DC-DC 升压模块。另外麦克风和功放的地线一定要处理好尽量采用单点接地否则喇叭工作时的电流变化会耦合进麦克风信号录音里全是“嗡嗡”声这个问题的排查难度比想象中大得多。3. 固件侧从零到一唤醒、采集、配网、上传3.1 固件框架怎么选ESP32-S3 的主流开发方式有两套Arduino-ESP32 和 ESP-IDF。Arduino 上手快库多我一开始就是用 Arduino 做的原型接麦克风、连 Wi-Fi 几行代码就搞定。但做到后面发现两个问题一是内存管理不够透明跑 TLS 和音频一起处理时经常莫名其妙重启二是 OTA 和蓝牙配网的底层控制不如 IDF 方便。所以第二版我整体迁移到了 ESP-IDF 框架虽然开发效率初期慢一些但可控性、稳定性和后续演进空间都强很多。工程结构上我按模块拆成几个文件夹audio 负责麦克风采集和音频播放network 负责 Wi-Fi 和 BLE 配网protocol 负责与云端的消息编解码ota 负责固件升级interaction 负责按键和状态灯控制。这样每次只改一个模块出了问题也能快速定位。对这个体量的项目来说模块化不是装样子而是真实提升迭代效率的手段。3.2 麦克风采集与唤醒词实现音频采集用的是 I2S 外设采样率 16kHz16bit单声道这个参数几乎匹配所有主流 ASR 服务的输入要求。以下是一段基于 ESP-IDF v4.4 风格的初始化代码新版驱动 API 有所不同但核心参数思路是一样的i2s_config_t i2s_config { .mode I2S_MODE_MASTER | I2S_MODE_RX, .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, .intr_alloc_flags ESP_INTR_FLAG_LEVEL1, .dma_buf_count 8, .dma_buf_len 1024, }; i2s_pin_config_t pin_config { .bck_io_num 4, .ws_io_num 5, .data_out_num I2S_PIN_NO_CHANGE, .data_in_num 6, }; i2s_driver_install(I2S_NUM_0, i2s_config, 0, NULL); i2s_set_pin(I2S_NUM_0, pin_config);这里 dma_buf_count 和 dma_buf_len 的参数不建议随意调小音频数据是通过 DMA 持续写入内存的缓冲区太小会导致音频丢帧听起来就是一卡一卡的。我最终用了 8 个 1024 长度的缓冲区实测 16kHz 采样下能稳定跑 30 分钟不掉数据。唤醒词我用的是乐鑫 ESP-SR 方案它支持在设备端运行 WakeNet 模型可以自定义唤醒词。这个库编译后占用的 RAM 不算小所以强烈建议使用带 PSRAM 的 S3 模组。唤醒词模型的阈值需要反复调阈值调太低电视声音或者环境音都会把设备叫醒阈值调太高离远一点就喊不醒。我的经验是白天环境噪声较大时用偏高的阈值晚上安静模式下用偏低阈值这里可以做成自适应噪声门限或者允许用户通过 App 手动调节灵敏度。3.3 BLE 配网用户体验的第一个坎AI 陪伴设备没有屏幕第一次怎么让它联网这是产品化绕不开的问题。我调研过两种方案一种是 ESP SoftAP 配网设备开一个热点手机连上去然后通过网页配置另一种是 BLE 配网。实测下来 SoftAP 在小屏幕上操作麻烦手机要切换网络用户很容易迷路。BLE 配网体验好得多手机 App 或者小程序扫码后直接通过蓝牙连接设备把 Wi-Fi 名称和密码写进去设备拿到后自动连接 Wi-Fi 并保存到 NVS 分区。具体实现我选择了自定义 GATT 服务因为可控性比 protocomm 更强也能顺便下发服务器地址和 Token。流程是这样的设备上电后检测 NVS 里有没有 Wi-Fi 凭据没有就进入配网模式广播一个特定名字的 BLE 设备手机连接后向指定 characteristic 写入 Wi-Fi SSID 和密码设备收齐后尝试连接路由器把成功或失败状态通过另一个 characteristic 返回给手机。配网成功后设备重启并自动连接 Wi-Fi同时关闭 BLE 广播以省电。这里有个细节必须注意不要在 BLE 断开后立刻重连同名的周边设备我调试时发现手机蓝牙会缓存旧的服务特征导致连接后找不到写入通道。解决办法是 App 扫描时附带设备 MAC 地址做精细匹配连接前先 clear 之前的缓存。3.4 上传协议与 OTA 升级音频上传的格式我第一版用的是裸 PCMWAV 文件16kHz 16bit 单声道一秒 32KB一条 10 秒的语音也就 320KB传到云端的耗时大概在 300 到 800 毫秒其实还可以接受。但如果用户连续说话或者语速慢录音时长上去后整包上传的延迟会变得很明显。更好的做法是在设备端做 Opus 编码或者先把 WAV 分包上传、边录边传我最终选择了边录边传的方案这样最后一段录完前面的音频已经在网上了能省下一整个“先录完再传”的等待时间。与云端通信必须走 HTTPS音频数据属于用户敏感信息明文传输在公网上等于裸奔。TLS 握手会占用不少内存这也是我强调用 PSRAM 的原因。同时要注意证书管理我遇到过设备端内置的 CA 证书过期导致 TLS 握手失败的问题排查了半天才发现不是代码问题。OTA 是“可持续演进”最核心的机制。设备每次开机后先请求云端版本检查接口带上当前固件版本号如果云端有新版固件就返回下载链接设备通过 esp_https_ota 下载新固件并写入另一个分区成功后切换启动失败则自动回滚到旧版本。没有 OTA 的设备永远是出厂那个智商有了 OTA 才有持续进化的可能。4. 云端能力编排语音识别、大模型对话与语音合成4.1 云端服务选型与接口抽象云端部分我一开始也想全部自建毕竟开源方案很多但后来想通了自有硬件项目的核心竞争力在体验设计和端云协同不在重复造轮子。ASR 我对比过开源 faster-whisper 和云厂商识别服务前者部署自由但延迟波动大后者在网络好的情况下识别速度和准确率都更稳定所以我选了云厂商的 ASR 接口。TTS 类似云端合成的声音自然度远超老式离线合成而且可以通过参数调整语速和音色。LLM 这一层直接接入大模型 API配合 system prompt 来定义陪伴人设。这里最关键的工程决策是三层服务全部抽象成独立接口asr(audio) 返回文字chat(messages) 返回回复文本或工具调用tts(text) 返回音频地址。每层都支持多个厂商适配器通过云端配置中心切换当前启用哪家。这样做的底气在于模型供应商的价格、延迟、稳定性都会变接口层抽象好了切换成本就是改一个配置项。能力层候选实现选型标准ASR云厂商语音识别、开源 Whisper 服务延迟、中文准确率、并发成本LLM通用大模型 API、私有化部署回复质量、上下文长度、安全可控TTS云厂商语音合成、开源 TTS 引擎音色自然度、合成延迟、多音色支持4.2 一次对话的消息链路设计设备端和云端之间我采用的是 HTTP 短连接加 JSON 消息的协议。有朋友建议用 MQTT说长连接省电但实际场景里设备大多数时间处于待机状态没必要维护一条长连接。只有唤醒词被触发后设备才需要上传音频并等候结果这是典型的请求-响应模式HTTP 最合适也最容易做负载均衡和缓存。请求消息长这样POST /v1/agent/converse HTTP/1.1 Host: api.example.com { protocol_version: 1.2, device_id: esp32s3_0a1f, session_id: sess_9f8e2a, action: audio_converse, audio: { format: wav, sample_rate: 16000, bits_per_sample: 16, channels: 1, data_base64: ... } }云端处理完返回{ code: 0, text: 北京今天晴气温 20 到 28 度适合出门散步。, audio_url: https://cdn.example.com/tts/sess_9f8e2a.mp3, stream_type: http_url }协议版本号必须带这是可持续演进的基础。我见过太多设备端和云端一次性把协议写死后面想加字段老设备解析失败直接崩溃。带版本号之后云端可以根据设备上报的版本号决定返回什么结构老设备继续用旧结构新设备用新能力。4.3 AI Agent让陪伴设备会“做事”如果设备只能一问一答那它充其量是个会说话的音箱不是 AI 陪伴设备。真正的陪伴设备应该能帮用户做事情所以我把大模型接成了 Agent 形态通过 function calling 调用各种工具。举一个最常用的“天气查询”场景。用户说“今天适合穿什么”设备把音频上传ASR 转成文本后云端把文本交给大模型。大模型判断需要天气信息就会生成一个工具调用{ tool: query_weather, params: { city: 北京, date: today } }云端网关收到这个调用后去天气服务取数据再把天气结果作为额外上下文回传给大模型。大模型综合天气和当前的陪伴人设生成一句口语化回复比如“北京今天晴天最高 28 度穿件短袖就行但早晚温差大记得带件薄外套。”整套流程里硬件的角色只是录了一段音、放了一段音中间的理解和决策全部发生在云端。这带来的想象空间很大加一个“提醒事项”工具设备就能语音设置提醒加一个“播放白噪音”工具设备就能在睡前放雨声加一个“智能灯控制”工具它就能控制家里的灯。而且这些能力完全不用改设备固件云端发布新工具配置就行。硬件还是一块 ESP32-S3但它的能力会随着云端工具库的增长不断变强。5. 端到端跑通一次对话实测链路5.1 状态机是关键骨架我刚写固件时用的是“遇到回调就处理”的思路结果经常出现用户正在说话时设备又录到自己的喇叭声形成回声循环。后来我把设备跑成了一个状态机所有事件只有匹配当前状态才会被处理。状态定义如下IDLE 空闲态设备监听唤醒词WAKE 唤醒态用户正在说话设备开始录音UPLOAD 上传态录音结束音频正在上传WAIT 等待态音频上传后等待云端返回PLAY 播放态设备正在播放云端合成的音频。每个状态都有超时保护比如 WAIT 超过 8 秒没返回就自动回 IDLE并播报一句“网络有点慢请稍后再试”。这里要特别提一句“播放态回声”的问题。如果设备播放 TTS 时麦克风还开着扬声器声音会顺着麦克风又传回云端造成设备“自问自答”。我的处理是在进入 PLAY 状态时把麦克风增益调到最低同时 DSP 里加了一个简单的回声路径抑制实测效果可接受。5.2 完整请求示例与返回解析我们跑一次完整链路按一下设备上的唤醒键或者说“你好小智”唤醒设备然后问一句“北京今天天气怎么样”。第一步WakeNet 在本地被唤醒设备通过 VAD 检测到用户说完自动截取 3 到 5 秒音频。第二步固件把这段音频分包上传到云端接口带上设备 ID、会话 ID 和音频格式。第三步云端 ASR 服务把音频转成文本“北京今天天气怎么样”这一步我实测延迟大约 500ms。第四步云端把文本交给大模型大模型识别出这是一个天气查询生成 tool_call 给网关。第五步网关调用天气服务拿到结果让大模型生成一句自然语音回复。第六步TTS 服务把回复合成 mp3 文件返回给设备。第七步设备开始下载并播放这段音频。这整个过程从用户说完话到喇叭出声我在联通宽带下实测大约是 3.5 秒到 5 秒已经接近主流智能音箱的体验。其中录音和网络上传占了一部分模型推理占了一部分合成占了一部分后续优化空间还很大。5.3 延迟优化与降级策略延迟是 AI 陪伴设备体验的生死线。用户对着设备说一句话如果 8 秒内没反应他会觉得设备坏了。我的优化路径有三条。第一步是边录边传。传统做法是录完一整段再上传10 秒的录音加上传光这里就多出 1 秒多延迟。改成边录边传后用户刚说完最后一个字前面的音频已经到了云端ASR 立刻开始识别整体感知延迟明显下降。第二步是 TTS 流式播放。云端 TTS 可以边生成边返回音频流设备边下载边播放不用等整段音频合成完再播放。实测长文本回复下这一步能省下 1 到 2 秒。第三步是缓存常见回答。比如“你好”“你是谁”“讲个笑话”这类高频问题云端把生成的 TTS 音频缓存起来第二次命中直接返回 CDN 链接设备只需下载一段现成的音频延迟极低。降级策略也要提前想好。如果云端服务超时或者 Wi-Fi 突然断了设备不能傻等。我在固件里加了一层本地兜底回复当 HTTP 请求连续两次失败设备播放一句预置的“我现在网络不太好等会儿再聊吧”同时断开重连 Wi-Fi。这既保护了用户体验也避免设备在无网状态下反复尝试耗尽电量。6. 避坑实录与调试技巧人工踩过的坑6.1 常见问题速查表我把整个开发过程中遇到最频繁的问题整理了一张表每个问题背后都是一段真实的调试经历照表排查能省不少时间。问题现象可能原因解决办法I2S 麦克风读不到数据引脚被 Flash 或其他外设占用查板卡原理图换用安全 GPIO录音有“嗡嗡”电流声功放与麦克风共地回路干扰单点接地功放独立供电BLE 配网后 Wi-Fi 连接失败SSID 包含特殊字符NVS 存储截断限制 SSID 长度禁止特殊字符JSON 解析时设备重启RAM 不足JSON 对象过大换带 PSRAM 模组增大堆空间Wi-Fi 断开后不重连没有实现断线重连逻辑注册连接事件自动重连并重新查询TTS 播放出现爆音音频格式或采样率不匹配统一播放器的采样率与声道配置OTA 升级失败固件签名校验失败或分区表不对检查签名、确认双分区配置6.2 调试心法从工具到流程调试这套系统最大的心得是必须建立“端到端追踪”能力。设备端、云端、模型服务是三层独立的系统任何一个环节出问题表现都是用户侧“没反应”或者“反应慢”如果不对关键节点埋点排查起来就像大海捞针。我在固件里加了分级日志在关键位置打上 audio_capture_done、http_upload_done、tts_play_done 这类标记云端也把 ASR 时长、LLM 时长、TTS 时长分开记录。这样用户反馈一个问题我先看日志就能定位在哪个环节省去了大量瞎猜时间。还有一个很实用的技巧给设备预留一个“测试模式”按钮。长按进入测试后设备会自动播放一段固定音频然后录一段麦声音并上传用来检查麦克风、扬声器、网络、云端连接是否全链路正常。这个功能对产线质检特别有用我后来做小批量验证时全靠这个测试模式快速筛出硬件不良的板子。6.3 个人经验与后续扩展如果你也想做类似的设备我给你的第一个建议是别急着追求功能丰富先把“唤醒、录音、上传、云端回复、本地播放”这条最短闭环打通。闭合链路通了设备的“魂”就有了剩下的都是锦上添花。我见过太多人一开始就规划做手势识别、人脸检测、多设备联动结果核心对话还没跑通热情先被繁杂的周边需求消耗光了。第二个建议是尽量从一开始就设计好可替换的云端服务接口。哪怕第一版只接一家 ASR、一家 LLM、一家 TTS也把每层包成一个独立模块。这个抽象在初期看起来是“多写了代码”但当你要换模型、比价格、做灰度时它就是救命稻草。第三个建议是给设备留出足够的调试冗余比如在 PCB 上引出 UART 日志引脚、在固件里保留默认打开调试等级的编译开关。这些细节看似不起眼真正进了联调阶段每一个都能帮你从“看现象猜原因”升级为“看日志定位置”。我自己在这套设备上踩过的坑最多的是供电和内存最让我意外的反而是 BLE 配网后设备不会自动重连 Wi-Fi 这种基础问题所以调试时别忽略最基础的能力验证。目前我手头这块板子已经能完成天气查询、定时提醒、白噪音播放和基本陪伴对话下一步我打算给它加一块小屏幕显示时间与表情再挂一个温湿度传感器让它从“能聊天”变成“会感知环境”。整个演进过程中底层的端云架构不会变变的是云端不断增长的 Agent 工具库和设备端逐渐丰富的外设模块。这才是当初设计“可持续演进”时最想看到的结果。