Meta 已公开 Muse Gadget SDK，ESP32 设备可以通过官方固件与 Muse 配对，并向 Muse 暴露自定义命令。做一个自用的传感器或按钮原型，已有明确入口；把同一固件烧进准备出售的设备，则不能因为仓库采用 Apache-2.0 就认为接入 Muse 的权利也随之开放。SDK 仓库和SDK token 条款分别管理代码与服务凭证，这两个边界必须分开判断。
对产品团队而言，第一道问题不是“ESP32 算力够不够跑 Muse”。官方 ESP32 固件通过手机完成 BLE 配对、加入 Wi-Fi，再与 Muse 的 VM 建立加密会话；Muse 的 Agent 不在 ESP32 上本地运行。开发板承担的是输入、输出和设备动作，智能体能力来自外部服务。如果需求写的是离线语音、无云端依赖或可向客户长期交付的独立产品，直接沿着这个 SDK 做量产规划，会在架构和授权两个层面同时走偏。以下判断只依据截至 2026 年 10 月 9 日的官方公开资料；我们没有在目标开发板完成刷机、配对或性能测试。
能做的事：让 Muse 看见一个设备，不是把 Muse 装进 MCU
官方 ESP32 Device SDK把设备连接分成几个责任：ESP32 固件在本地运行，手机 App 负责首次配对和网络配置，设备联网后保持与 Muse 的加密会话。开发者可以接入屏幕、按键、传感器或执行器，也可以为设备注册自己的命令。屏幕和音频体验取决于具体板卡；不能把某块带屏 S3 的展示能力，直接推给默认的 C5 DevKitC-1。
这里最容易误解的是“支持 ESP32”四个字。它意味着仓库提供面向 ESP32 家族的固件和若干板卡配置，不意味着任意模组、任意屏幕、任意音频链路都能直接烧录。官方文档把 ESP32-C5 DevKitC-1 作为最快起步的默认板：它有状态灯和 BOOT 按键，默认构建针对这块板。换成其他型号，需要核对 devices/ 下对应的配置、Flash/PSRAM、按钮、显示与音频驱动；没有列出的目标板还需要自行适配，而不是只替换 IDF_TARGET。
开发板功能也有分层差异。官方 README 指出，缺少 PSRAM 的部分板卡不运行 home-network tunnel，但仍能与 Muse 建立控制会话。需要经设备访问本地 HTTP API 时，不能只看到“可以配对”就把隧道能力写进需求；反过来，如果只是读取一个传感器或切换一个 GPIO，也不应为完整带屏 UI 和隧道付出额外硬件成本。先把设备要提供的能力列出来，再从官方设备清单反选板卡，比先买一块热门 ESP32 再追功能更稳妥。
Muse app 与云端仍是这条链的组成部分。即使传感器接在本地引脚，命令何时被识别、如何到达设备、断线时怎样表现，都受手机配对和外部会话影响。它适合体验“让 Muse 控制我的一个 Gadget”，不等价于一个由设备独立完成唤醒、理解、决策和动作的离线助手。评估原型时应把这两种产品叙事写成不同验收条件，避免 Demo 可用后才发现目标客户所在网络或隐私条件根本不允许相同链路。
最小原型：先证明一条无危险动作的命令闭环
若只是验证官方路径，默认 C5 开发板比立即选带麦克风、屏幕和继电器的复杂组合更适合作为第一步。ESP32 README指定 ESP-IDF v6.0.1；开发者还需要数据线、自己的 Muse 账号、SDK token 和手机 App。固件构建前通过配置输入 token，烧录后在 App 的 Settings > Devices 打开 Developer mode、添加 MuseGadget-… 设备，并在状态灯提示时按板上 BOOT 键确认。这里描述的是官方步骤，不是本次已经完成的刷机记录。
第一条自定义命令最好选择只读数据，例如返回演示设备的按钮计数和采样时间，而不是立即控制门锁、加热器或电机。官方开发说明要求在 main/noise_control.cpp 的 build_register_json() 中通过 link.register 公告命令，再由 link.invoke 到达 main/app.c 的 on_ws_command()。注册描述是能力声明，真正执行仍在固件。环境传感器已有 sensors.read 约定；要增加温湿度一类读数，宜沿用这一接口，不为每块板另造命令名。
图里刻意把 link.register 与 link.invoke 分开：前者告诉 Muse 设备能做什么，后者才触发本次处理。它不是一张“ESP32 本地运行 Muse”的架构图。
把命令当成设备 API，而不是一句提示词
状态或传感器读取至少要回答四个工程问题：返回值来自哪一个采样点，单位是什么，超过多长时间算过期，设备断线或传感器失效时返回什么。一个裸露的 23.5 无法区分摄氏温度、电池电压或缓存数据；一个永远返回成功的模拟值，则会让 App 侧的演示掩盖设备实际故障。原型可以先用明确标记的假数据验证命令路由，但应把“路由可达”和“真实测量可信”设成不同验收项。
执行类命令还要更谨慎。设备固件应限制参数范围，给动作设置明确超时和安全默认状态，让断线、重试和重复调用的后果可预期。比如让 Muse 调节灯光亮度，参数应有上限和下限，重复设为同一亮度应保持幂等；如果是继电器，就必须说明上电默认态、动作确认与失败回退。官方提供的命令扩展点解决的是接入方式，不会替项目自动补齐物理安全和异常恢复设计。
原型通过的证据也应分层保存。编译成功只能证明当前源码和工具链相容；设备在 App 中出现，只能说明发现与配对流程推进；一次 link.invoke 得到预期 JSON，才说明该命令在那次会话下走通。要评价断网、重连、错误参数和多次调用，则需要各自的日志与测试记录。本篇没有这些一手制品，因此只给出验证顺序，不给出成功率、响应时间或稳定性结论。
真正需要先读的两份“产品说明”：token 条款与安全默认值
代码开放，不等于接入服务可以销售
代码许可证与服务接入权利是不同的对象。仓库代码采用 Apache-2.0，但Meta 的 Gadget SDK Token Terms明确把 token 限定在个人、非商业使用，并说明源码许可不赋予 token 权利。条款还限制分享设备的数量，禁止把 token 嵌入出售、公开宣传或上架的设备。对计划收取设备费用、替客户部署或以 Muse 联名能力宣传的团队，这不是未来量产前再补的一纸协议，而是决定原型目标是否合理的前置条件。若确需商业合作，应先取得 Meta 的明确许可与相应授权安排，再讨论产品方案；本文不把公开仓库当成商用授权。
token 也不应被当作万能设备密钥。官方 README 提醒它会进入固件，泄露后需要撤销、生成新 token 并重新构建。Wi-Fi 凭据和设备 token 存在 NVS，官方建议在板卡支持时启用 NVS encryption。默认开发构建还使用仓库内开发签名密钥，并未启用 Secure Boot；这有利于反复刷机，却不是交付给外部用户时可以直接沿用的生产安全基线。把这几个点合在一起看，开源原型的“方便修改”与商业设备要求的密钥管理、固件可信启动和更新治理存在真实差距。
加密会话之外，还要验证设备身份
社区设备配对还有一条不能遗漏的边界。官方文档说明，配对需要在设备上按键确认，每次建立新的加密会话；但社区设备没有制造商身份验证，无法阻止主动中间人攻击。因此，“会话是加密的”不能直接推导出“设备身份已被生产级认证”。在受信任网络上做个人实验可以按说明操作；如果目标是客户场所、共享网络或受监管环境，就必须重新审视配对威胁模型，而不能用这套开发流程替代正式安全评审。
这些限制也解释了为什么“把现有设备接上 Muse”不能直接转成销售承诺：除了硬件适配，接入 token 的使用权、个人数据处理、设备身份、OTA、凭据撤销与故障支持都需要交付责任人。条款当前还把 SDK 定位为不受支持的产品，接口可能变化或撤回。产品负责人若据此对客户承诺多年可用性，承诺的其实是团队无法单方面控制的外部条件；这与简单的 MCU 选型风险不是一个级别。
怎么决定下一步
如果目的是个人非商业实验，且能接受手机 App、Muse 账号和云端会话作为前提，可以从官方 C5 默认配置开始，先完成只读命令，再按需要扩展按键、显示或音频。每增加一类外设，都应把板卡支持、资源占用和失败状态单独验证。这样的路线把未知量压缩到一个命令和一块板，不需要先设计完整“AI 终端”。
如果目标是自有品牌设备、客户交付或付费销售，应先暂停“直接集成 Muse token”的计划。即使样机已经能配对，当前公开 token 条款仍不能支持把它当作可售方案；即使获取许可，也还要补齐设备身份、安全启动、凭据保护、更新、区域可用性和服务退出预案。许可、技术和运营是三个不同的通过条件，任何一个都不能由一次成功演示代替。
如果需求的核心其实是本地语音或离线控制，Muse Gadget SDK 也不是自然答案。可以把 ESP32 保留为音频/控制端点，另行选择符合授权和离线要求的推理及设备控制架构；这需要重新定义系统边界，不能简单把 Muse 的远端 Agent 改叫“边缘 AI”。本站的 ESP32-S3 语音流水线文章讨论设备侧音频处理，与 Muse 接入是两个不同任务。需要评估固件、外设接入或设备产品化路线时，可参考 ESP32 开发服务；与服务讨论时，应先说明目标是个人验证还是商业交付，避免把许可和安全问题混在一次技术估算里。
参考资料与核验范围
以上资料于 2026 年 10 月 9 日核对。官方仓库与 token 条款可能变化；动手或立项前应重新阅读现行版本。本文没有测试设备、SDK token、Muse 账号或商业许可记录，不代表已验证刷机、配对、命令调用或量产可行性。
