ESP32 本地语音助手搭建

要解决什么问题

很多语音助手默认把唤醒、识别、大模型推理、TTS 全丢到云端。结果就是隐私难保证、网络延迟不稳定，长期调用成本也上去了。另一方面，ESP32 这块板子算力和 RAM 有限，直接塞大模型很容易频繁重启。这个技能要解决的是：在低成本边缘设备上，搭一条“本地优先、按需上云”的语音 agent 链路，让你能在硬件上自己跑通唤醒、对话和工具联动。

它如何工作

这个技能按嵌入式语音 Agent 工程师的思路组织，核心是把整条语音链路拆成四段来处理：

• 唤醒（Wake Word）：用 Wakenet 这类本地轻量模型，不上云就判断是否触发。
• ASR 语音识别：本地轻模型或云端 API 二选一，看你对网络和隐私的取舍。
• LLM 思考：本地小模型优先离线，需要更强能力时再切云端大模型；配合 MCP 调用外部工具。
• TTS 合成：选低延迟中文音色，同时留意首次合成的冷启动延迟。

在硬件和固件选型上，技能建议以 ESP32-S3 为主控，配合数字麦克风、功放和喇叭，注意 I2S 接线；固件基线用开源的 xiaozhi-esp32，先用 idf.py flash monitor 或网页烧录工具跑通官方示例再改。本地和云端的取舍也有一张决策表：本地方案隐私强、延迟低但能力受限，云端方案能力强但隐私弱、按量付费、网络依赖明显。

适用边界与注意点

它适合想做离线语音助手、开发板跑大模型对话、ESP32 + MCP、智能音箱 DIY 的人，触发词包括 ESP32、语音助手、硬件 chatbot、边缘 AI、离线对话。

但要注意几个常见陷阱：不做唤醒就直连云端 ASR，会带来流量和隐私双输；忽略功放供电会导致杂音或啸叫；在 RAM 不足的开发板上硬跑大模型会频繁重启。更稳妥的做法是先用云端验证链路，再逐步把环节搬到本地。

另外，AI 输出要以官方为准；涉及麦克风采集时，注意当地隐私与录音合规要求，公共场景录音前要告知并取得同意。