[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$f1n9jq84qco9i0":3},{"code":4,"message":5,"data":6,"timestamp":29},10000,"success",{"full_name":7,"position":8,"description":9,"language":10,"stars":11,"forks":12,"stars_gained":13,"age_days":14,"hn_threads":15,"one_liner":16,"summary_md":17,"topic":18,"github_topics":21,"license":25,"homepage":26,"updated_at":27,"history":28},"78\u002Fxiaozhi-esp32",2,"An MCP-based chatbot | 一个基于MCP的聊天机器人","C++",31875,7459,1729,784,[],"把常见 ESP32 开发板变成语音助手终端的固件，含唤醒词与 MCP 设备控制。","## 解决什么问题\n\n在单片机上做语音助手，通常要自己拼：离线唤醒、Opus 音频推流、稳定的传输通道、ASR\u002FLLM\u002FTTS 串联，以及让模型真正能操作硬件。大多数个人项目卡在其中某一环。这个项目提供一套完整的 ESP32 固件，把受支持的板子直接变成语音终端；设备侧 MCP 让模型可以控制扬声器、LED、舵机和 GPIO，云端 MCP 则把能力扩展到智能家居、PC 操作等场景。\n\n## 有什么不同\n\n自己基于 ESP-SR 加 WebSocket 客户端搭一套，也能跑通，但这里的优势是覆盖面和整合度：138 个板型目录、171 个发布变体，支持 WebSocket 与 MQTT+UDP 两种传输，离线唤醒词可自定义，同时兼容传统 ASR+LLM+TTS 链路和实时端到端语音模型。与芯片厂商的语音套件 SDK 相比，它跨 ESP32\u002FC3\u002FC5\u002FC6\u002FS3\u002FP4，且 MIT 协议允许商用。真正拉开差距的是 MCP 这层抽象：把设备当作 MCP server，而不是为每个外设硬编码指令。\n\n## 适合谁\n\n适合做 AI 语音硬件原型的爱好者和小团队——桌面陪伴、挂件、机器狗之类——不想从零写音频栈。固件工程师也可以把它当作多板型抽象的参考实现。如果你需要带 SLA 的量产设备云服务，或者主控不是 ESP32，那就别选它：代码与 ESP-IDF 及其组件生态绑定很深。\n\n## 上手成本\n\n工具链要求不低：最低 ESP-IDF v6.0.1，推荐 release\u002Fv6.1，明确不支持 5.x；切换 SDK 后还要做 submodule 更新和 fullclean 重编。实际使用通常意味着注册官方 xiaozhi.me 作为默认后端，或者自己部署社区服务端（Python\u002FJava\u002FGo）。刷预编译固件对新手友好，改固件则不友好。项目已有两年且维护活跃，但板型矩阵持续膨胀，引脚与 IDF 兼容性的边缘问题是不小的维护负担。\n\n## 点评\n\n这是成熟项目而非短期爆发：约 31.9k star，本月 C++ 月榜第 2、单月 +1,729 star，关注度仍在上升。变动集中在硬件适配上而不是核心设计，对固件基座来说是健康信号。如果你在做 ESP32 语音产品，想直接跳过音频链路，值得采用；但要把它当成需要跟随升级的 SDK，而不是刷完就完的固件。主要风险是绑定厂商工具链节奏，以及默认依赖官方托管后端。",{"slug":19,"name":20},"hardware","硬件与物联网",[22,23,24],"chatbot","esp32","mcp","MIT","https:\u002F\u002Fxiaozhi.me","2026-10-24T17:36:37Z",[],1792869720]