技术解读
Wally：把“贾维斯”塞进一块 ESP32 的工程实践
项目背景与痛点
智能音箱发展至今已经十年，但绝大多数产品仍然走同一条路：重云端。唤醒词、ASR、NLU、TTS 全在云上，设备本身只是一个麦克风加一个喇叭。这条路径的问题也已经被反复验证——断网即废、响应延迟常年在 1.5 秒以上、语音数据全量外流，而且你永远无法定义它到底能做什么。
另一条极端是纯离线方案：本地跑 KWS（唤醒词识别）加小模型，响应快、隐私好，但语义理解能力基本停留在“打开客厅灯”这种意图槽位的水平，谈不上“日常对话”。
Wally 的价值在于它站在了两者之间一个相当务实的位置：把最敏感的“常听”环节放在本地，把最吃算力的“理解”环节放到云端。硬件是 ESP32，BOM 成本压到几十元人民币量级，目标很明确——不是造一个商品化音箱，而是给开发者一个能自己掌控、能接自己大模型的“个人 AI 硬件”基座。它同时承载两类任务：闲聊对话，以及提醒 / 待办这类生产力功能。后者恰恰是纯云端音箱的软肋，因为提醒必须在断网、断电重启后依然可靠触发。
核心技术揭秘
从 ESP32 平台的能力边界倒推，这类项目的技术骨架基本可以确定：一个音频前端的实时数据管道，加上一个严格的状态机，再加一条上下行的音频流通道。
第一层是音频前端（AFE）。这是整个项目最容易被低估、也最容易出问题的地方。ESP32 上做全双工语音，绕不开 AEC 回声消除——没有它，设备播放 TTS 时会把喇叭里自己的声音当成用户输入，形成自唤醒死循环。通常需要一路 I2S 采集麦克风、另一路取播放参考信号做自适应滤波，再叠加 NS 降噪和 VAD 断句。VAD 的意义不只是“检测有没有人说话”，更是上行流量的闸门：只有检测到有效语音才推流，否则云端带宽和费用会被环境噪声吃光。
第二层是唤醒词模型。它必须是纯本地、常驻、低功耗的 TinyML 模型，跑在 MCU 的有限算力上。这里的工程权衡非常尖锐：模型复杂度直接决定误唤醒率，而误唤醒是最伤用户体验的指标——一天误触发十次的助手，用户第三天就会拔电源。因此实践中通常会在唤醒后加一道二次确认（比如短窗口内的置信度复核），而不是一次命中就直接进云。
第三层是状态机与并发。IDLE → LISTENING → THINKING → SPEAKING 这套状态转移看着简单，实则是全系统的骨架。难点在于音频流的生命周期管理：上行推流、下行播放、本地提示音、按键中断会同时争抢 I2S 和 Wi-Fi 缓冲。必须有明确的环形缓冲区（ringbuffer）和背压策略，否则在弱网下就是断音、爆音、内存溢出三连。这也是为什么这类项目对 PSRAM 有硬性依赖——音频缓冲和 Opus 编解码的工作区不是几百 KB 能扛住的。
第四层是本地调度器。提醒功能之所以必须落在端侧，是因为它不能依赖长连接存活。合理做法是用 RTC 提供时基，FreeRTOS 定时器加轻量任务队列维持待触发事项，再持久化到 NVS 或 SPIFFS，保证掉电重启后条目不丢。反过来，LLM 侧只负责把“明天下午三点提醒我交周报”解析成结构化参数，真正的守时责任交给设备自己。
功能亮点与差异
和市面上的同类项目相比，Wally 的差异点集中在三处：
一是“对话 + 任务”的双模定位。 绝大多数 ESP32 语音开源项目止步于“语音控制外设”，本质是个语音遥控器；而只做闲聊的项目又缺少实用性。把提醒、生产力纳入进来，意味着它要处理意图分流——同一个入口，一句话可能走对话链路，也可能走任务入队链路，这对 LLM 侧的输出格式约束提出了要求（结构化工具调用比自由文本更适合这种分流）。
二是可完全自托管的链路设计。 唤醒在本地，ASR / LLM / TTS 走自己的 API Key 和自己的网关，数据流向完全可控。这对于做企业内部助手、或对隐私有要求的家庭场景，比接入 Alexa / 小爱生态有本质区别。
三是成本量级。 ESP32-S3 加 I2S 麦克风和功放，物料成本压在一杯咖啡的价格区间。这决定了它作为“原型基座”的价值远大于作为成品——你可以一次性打十块板子，铺在办公室、卧室、车里，共用一个后端。
应用场景与落地建议
适合的场景：个人知识工作者的桌面助手（提醒、日程、快速问答）、企业内部语音问答终端、智能家居的语音入口网关、以及 AI 硬件方向的教学与原型验证。不适合：需要毫秒级响应的高实时场景、强噪声工业环境、以及任何无法接受语音上云的场合。
如果要往生产环境走，几个坑必须先填：
- 电源与音频布线。功放开关瞬间的电流尖峰会串进麦克风链路，表现为“咔哒”噪声，直接拉高误唤醒率。麦克风与喇叭的物理隔离、独立 LDO 供电，比换一个更大的麦克风收益更高。
- 网络鲁棒性。WebSocket 长连接在 Wi-Fi 漫游、路由器重启时必然断。必须有指数退避重连和会话状态恢复，否则用户每次都要重复唤醒一次。
- 弱网降级策略。上行音频被阻塞时，设备应尽快回落到 IDLE 并给出明确的语音反馈（“网络不太好”），而不是静默卡在 THINKING 状态让用户干等。
- 工具调用的白名单。当 LLM 能驱动本地任务甚至外设时，提示词注入就不再是聊天机器人的玩笑——一句精心构造的语音内容可能让设备执行非预期动作。意图到动作的映射表必须显式枚举，禁止 LLM 直接生成任意指令。
- 隐私告知。即使自托管，也应明确“哪些音频离开设备”，并在物理层保留一个硬开关麦克风的方案。
综合评价
优点：架构分层清晰，本地与云端的边界划在了正确的位置；成本极低，适合做个人 AI 硬件的验证基座；双模定位让它摆脱了“玩具”属性；链路可自托管，数据主权在自己手里。
缺点：体验上限被网络质量强绑定，弱网下延迟和失败率会显著劣化；唤醒词与 AEC 的调参高度依赖硬件布局，开箱即用的难度不小；作为早期项目，工程化程度（测试覆盖、异常处理、配置抽象）通常还不足以直接产品化；Opus + 云端 ASR 的组合在长句识别上的准确率，仍明显落后于手机端成熟的流式方案。
一句话结论：Wally 不是一个能直接卖的音箱，但它是目前少数把“个人 AI 硬件”这件事的骨架搭对了的开源项目——如果你想要一个能自己改造、数据不出私域的语音入口，它比从头造轮子划算得多。
评论