Meta Muse 小工具已开源，但平台并未开放

Meta 已发布 Meta Muse 小工具的代码，邀请开发者将其个人 AI 智能体连接至电视、显示屏、传感器、按钮和家居设备。此举让 Muse 走出聊天界面，进入实体空间，同时将大量硬件实验交给外部开发者。

这听起来像是一场开放硬件布局。但更重要的是，Meta 开放了设备层，却没有开放其背后的每一层。开发者可以修改运行在受支持开发板上的软件，但每个小工具仍需要 Meta 签发的令牌和有效的 Muse 账户。

这一成果介于业余爱好者项目与平台战略之间。Amazon、Google、Apple 和 Home Assistant 多年来一直在定义软件如何控制互联家庭。Meta 则从不同方向切入：先确立 AI 智能体，再让开发者创造人们与它交互的载体。

Meta Muse 小工具将 AI 智能体变成硬件平台

Meta 为开发者提供的是 Muse 驱动设备之间的连接基础，而非一套完整的消费电子产品目录。

该公司已为 ESP32 微控制器和 Linux 计算机发布软件开发工具包。ESP32 开发板是价格低廉、功耗较低的计算设备，常被嵌入互联设备中。Linux 方案则支持 Raspberry Pi 系统及其他小型计算机等硬件。

Meta 的小工具项目页面称，开发者可添加屏幕、音频硬件、传感器、按钮和其他组件。Linux 设备还可以为系统管理或广受欢迎的家庭自动化平台 Home Assistant 提供自定义命令。

这让 Muse 可以拥有多种形态。小型屏幕可以显示提醒事项或购物清单。麦克风和扬声器可以组成按键通话式助手。Raspberry Pi 可以向现有家庭系统转发指令。Meta 标注为即将推出的 HDMI 设备，则可将 Muse 的回复显示在电视上。

俗称的 Muse 版烤面包机并不是 Meta 已宣布的产品。不过，这套软件架构让这类实验成为可能。开发者可以将 Muse 连接至家电控制器或本地网页界面，前提是项目遵守 Meta 的访问条款和相应的安全限制。

Meta 还列出了数款围绕市售硬件打造的示例设备，包括电子墨水显示屏、口袋大小的屏幕和小型语音界面。该公司强调，这些开发板由第三方制造和销售，Meta 不对其背书或提供担保。

已发布的小工具 SDK 代码采用 Apache 2.0 许可证，但已标明的第三方组件除外。开发者可以检查实现方式、修改代码、贡献变更，并支持更多开发板。

该代码库包含 ESP32 和 Linux 项目的独立目录，以及示例技能。技能是一种软件集成，可将智能体的请求转换为互联系统能够理解的操作。

这种设计将 Muse 的智能能力与实体交互界面分离开来。小工具未必会自行运行主要的 Muse 模型，而是与 Muse 服务配对，为智能体提供新的输入或操作方式。

这一差异很重要。Meta 并未要求每个设备制造商都在电灯开关中装入大型语言模型。它提供的是一种共享连接方式，使许多设备都能成为同一智能体的端点。

这一策略降低了测试不同寻常产品构想的成本。Meta 无需自行制造电子墨水日程本、桌面角色、通用遥控器或专用厨房显示屏。开发者可利用易获得的硬件测试这些形态，并发布其中真正有效的方案。

因此，这项公告将 Muse 从一款应用转变为潜在设备网络的中心。该网络能否持久，取决于控制智能体访问权限的规则。

Meta 为何现在开放设备层

如果 Meta 希望 Muse 不止是又一个对话式助手，它就需要更多能够执行操作的场景。

Meta 将 Muse 定位为能够管理任务、记住上下文并跨互联服务工作的个人智能体。这样的定位需要文本框之外的交互界面。一个只能在应用内对话的智能体，仍依赖用户打开该应用并发出指令。

实体设备可以让智能体成为环境的一部分。屏幕可持续显示计划。按钮可将多步骤交互简化为一次按压。麦克风可将智能体带入不方便掏出手机的房间。传感器则能提供传统聊天会话所缺少的上下文。

Amazon 和 Google 采取的是硬件优先的路径，进入环境计算领域。它们的扬声器和显示屏确立了家庭端点，随后逐步积累软件集成。Meta 已通过 WhatsApp、Instagram、Facebook 和其 AI 产品触达用户，但缺乏规模相当的家用扬声器存量基础。

Meta Muse 小工具为绕开这一劣势提供了一条捷径。Meta 不必打造每一种产品形态，而是可以吸引那些已在试验 Raspberry Pi 计算机、ESP32 开发板、Home Assistant 和定制电子设备的人。

这一社群可比集中式硬件路线图更快地探索使用场景。大多数项目仍将停留在实验阶段，但少数项目可能揭示值得更广泛推广或获得官方支持的交互方式。

Meta 已打造一款名为 Muse Home Link 的参考产品。根据其硬件文档，这款紧凑型适配器采用 Espressif ESP32-C5 处理器，配备 8MB 内存、8MB 存储和双频 Wi-Fi 6。

用户将适配器插入 USB 电源，并通过 Muse 移动应用完成配对。随后，该设备接入本地 Wi-Fi 网络，让 Muse 能够通过本地 HTTP 接口访问兼容设备。

HTTP 是网络服务所使用的基础请求系统。本地 HTTP 接口将相同模式应用于家庭网络，使一个设备能够向另一个设备发送结构化命令，而无需依赖公开网页。

Meta 表示，社区技能可将 Home Link 与 Philips Hue 灯具、Sonos 扬声器、Apple TV 设备、Google Nest 扬声器及 Samsung 电视等产品连接起来。这些集成由社区开发者维护，因此可能发生变更或失效。

该公司还警告，不应将这些项目用于家庭安全、紧急情况、医疗需求或其他安全关键型任务。这一警告不只是常规法律措辞。生成式智能体可能误解请求、选择错误工具，或遇到已过时的集成。

时机同样有利于这项实验，因为本地 AI 已变得更加可行。Meta 于 8 月发布了 Muse Glimmer，这是一款为本地智能体工作流设计的 300 亿参数模型。其本地模型发布说明称，量化可将其语言模型占用空间降至 20GB 以下。

量化会以较低的数值精度存储模型权重，从而减少内存需求。Meta 表示，当纳入支持组件后，Muse Glimmer 可在 24GB 或 32GB 内存配置中运行。

Muse 小工具和 Muse Glimmer 是独立项目，但它们体现了同一方向。Meta 希望开发者将其更多 AI 技术栈部署到传统云端聊天界面之外。一个项目将智能体带到本地计算机上，另一个则将该智能体连接到实体硬件。

Meta Muse 小工具开放代码，而非开放入口

核心取舍很简单：开发者控制小工具软件，而 Meta 控制对 Muse 的访问。

每个小工具在与账户配对前都必须获得 SDK 令牌。令牌是一种用于识别和授权设备或开发者的凭证。即便设备固件仍以开源许可证提供，它也为 Meta 提供了一个控制点。

开源代码与开放服务之间的区别至关重要。任何人都可以根据其许可证复制和修改 SDK。但该许可证并不保证可以持续访问 Muse、可以获准分销商业硬件，或可以使用他人的账户。

Meta 的SDK 令牌条款将令牌限制为个人、非商业用途。根据已发布的条件，开发者最多可在与他人共享的 50 台设备中嵌入一项个人凭证。

这些设备不得销售、公开上架、通过应用市场提供，或作为促销活动的一部分提供。商业分销需要获得 Meta 的书面许可。

Meta 还可以暂停或撤销令牌访问权限。条款称，SDK 和令牌并非受支持的开发者平台，并且可能发生变更或停止工作，恕不另行通知。

这对于一项早期实验而言并不罕见。公司往往会在评估安全性、需求、基础设施成本和滥用风险时，先采取限制性访问措施。不过，这也缩小了实践中“免费提供代码”的含义。

业余爱好者可以制作个人桌面显示屏。开发者可以在符合 Meta 条件的前提下，与朋友分享数量有限的一批设备。但一家初创公司不能假定同一令牌赋予其销售数千台 Muse 互联家电的许可。

这一界限保护 Meta 免受那些暗示与其智能体有关联、却不受控制的产品影响。它也让该公司能够调整认证机制、安全要求和服务容量。

对构建者而言，这一界限带来了平台风险。即使项目在固件层面依然能正常运行，若 Meta 调整令牌访问权限，它也可能失去核心功能。Apache 许可的源代码无法消除这种依赖。

Home Link 也体现了同样的分层。其固件基于公开的 ESP32 SDK，开发者可以检查其设计并制作类似的小工具。Meta 表示，官方 Home Link 本身只接受官方固件，无法重新刷写。

这一策略类似于围绕受控中心建立开放外围。开发者可在有利于 Meta 的实验领域获得灵活性，包括外壳、传感器、显示屏、命令和集成。Meta 则保留对账户、智能体访问、认证和使用执行的权力。

这种平衡以一种特定方式给竞争性助手平台带来压力。Amazon、Google 和 Apple 已建立硬件系统，但它们的集成通常须通过公司定义的接口。Meta 正邀请开发者自行组装实体端点。

Home Assistant 构成了更鲜明的对比。它强调本地控制、广泛互操作性和由用户管理的自动化。Meta 可以从 Home Assistant 集成中受益，但 Muse 仍是一个受 Meta 服务规则约束、基于账户的智能体。

最终胜出的未必是兼容设备列表最长的平台。可靠性、响应时间、数据处理方式和开发者信心，将决定一个智能体能否赢得控制真实设备的许可。

智能家居比聊天窗口更难考验系统

将智能体从对话带入设备控制，会提高每一个错误假设的代价。

聊天中的糟糕回答可能只是浪费时间。糟糕的设备操作则可能关闭错误的设备、在共享屏幕上暴露私人信息，或触发用户未曾预料的一连串操作。

当一条自然语言请求需要对应多个工具时，问题会更加突出。“把房子准备好，今晚看电影”可能涉及灯光、音响、电视、百叶窗和温度设置。每项集成都可能拥有不同状态、权限和故障模式。

传统家庭自动化通过明确规则处理这种复杂性：在既定条件下，一个触发器会引发一系列已知操作。AI agent 则引入了解释能力，让用户能够表达目标，而无需指定每一条命令。

这种灵活性正是吸引力所在，也同样构成风险。

一个 agent 必须判断用户的真实意图、哪些设备可用、哪项 skill 值得信任，以及是否需要确认。它还必须在某项操作成功、另一项操作失败时进行恢复。

社区集成进一步复杂化了责任链。Meta 负责运营 Muse 并发放访问 token；社区成员可能编写 skill；硬件厂商提供设备；用户则配置网络和权限。

一旦出现问题，故障可能源自任何一层。模型可能选择不合适的操作；skill 可能调用过时的接口；设备可能离线；家庭网络也可能拦截请求。

Meta 目前的警告承认了这些限制。该公司告诫用户，不要将社区 skill 用于安防、紧急情况或医疗功能。这使首批应用聚焦于可撤销、低风险的操作，例如显示、娱乐、提醒和照明。

隐私则带来了另一个尚未解决的问题。一个随时可用的 agent 会通过积累上下文而变得更有用，但同样的上下文也会加剧未经授权访问或意外泄露的后果。

带屏幕的设备可能会在访客可见的位置显示提醒。麦克风可能捕捉附近的谈话。传感器可能暴露居住状态模式。自定义 skill 可能将信息传输到当前设备之外。

Meta 的条款禁止开发者保留或传输他人的提示词和回复，除非这是已披露设备功能所必需的。条款还要求开发者在用户配对前，说明共享设备如何处理信息。

规则本身无法保证实现安全。业余项目很少获得大众消费产品所预期的安全审查。凭据可能泄露，依赖项可能过时，被复制的示例代码也可能将错误扩散至许多设备。

开放仓库有所帮助，因为研究人员和开发者可以检查设备端代码。但它并未公开 Muse 背后的完整服务、模型、账户系统或所有数据流。

因此，用户应将自定义 Muse gadget 视为自己账户的延伸，而非独立设备。一个看似无害的桌面显示器，可能继承与关联 agent 相同的信息访问权或操作权限。

开发者也应围绕故障进行设计。灯光控制应显示命令是否成功。设备操作应提供手动覆盖方式。敏感操作应要求确认。日志应记录足以诊断错误的信息，同时避免保留不必要的个人数据。

Meta Muse gadgets 的评价标准，不会是最具娱乐性的演示效果，而是它们在日常故障中的表现。可靠恢复能力，才是区分周末原型和可信赖家庭基础设施的关键。

开放硬件让 Meta 获得一场分发实验

Meta 正通过开放开发，寻找用户真正想要的硬件交互界面。

消费级 AI 硬件一直难以形成稳定的产品形态。语音音箱依然有用，但许多交互最终仍会回到手机上。可穿戴助手面临电池、隐私和社交层面的限制。专用 AI 设备则必须证明，另一个需要充电和维护的物件为何值得拥有。

Meta 不必立即选择一种形态。其 SDK 将硬件选择变成了一场分布式实验。

开发者可以将 Muse 安装在低频更新、低功耗的电子墨水屏上。另一个人可以打造紧凑型语音终端。还有人可以连接按钮和灯，打造单一用途的设备。

最有力的创意或许恰恰很聚焦。专用晨间显示器在某个重复发生的时刻，可能比通用助手表现更好。实体按钮可能比寻找一个 app 更便于完成高频工作流。电视界面则可能比个人手机更适合呈现共享信息。

这种方法也能为 Meta 产生信息。社区项目会揭示人们连接哪些设备、请求哪些 skill、集成在哪些环节失败，以及哪些交互模式能够吸引持续使用。

Meta 无需收购每一个项目也能受益。它可以改进文档、优先推进官方集成，或将成功模式融入未来产品。

Home Link 为这一过程提供了受控的参考设计。它为订阅者提供受支持的实体桥接设备，同时向开发者展示 ESP32 SDK 的使用方式。Meta 表示，该设备将于 10 月按先到先得原则向美国符合条件的订阅者发货。

其初始可用范围有限。向现有订阅者免费提供设备，并不能证明存在广泛的消费者需求；Meta 也尚未发布 gadget 项目的采用数据。

GitHub 仓库提供了早期社区信号，但 stars 和 forks 只是实际使用情况的弱代理指标。开发者常会收藏项目，却不一定组装硬件或维护日常工作流。

更有意义的测试在于，独立贡献者是否会为新开发板和设备添加可靠支持。若在发布期过后仍有持续活动，将表明 Muse 提供了足以支持持续开发的价值。

商业兴趣是另一个重要信号。当前 token 条款阻止开发者将原型直接转变为零售产品。如果 Meta 建立明确的商业路径，将表明它对该项目的定位不止于业余爱好者实验室。

竞争对手依然拥有显著优势。Amazon 已拥有多年的 Alexa 兼容硬件积累。Google 将 Assistant 技术与 Nest 产品和 Android 相连接。Apple 则控制着一套高度集成的手机、电脑、手表、电视和家居设备生态。

Meta 的优势在于社交分发和开发者实验，而不是既有的家庭控制能力。它面临的挑战，是将人们对 Muse 的兴趣转化为可靠交互，并让用户更倾向于使用它，而非成熟系统。

该公司还必须避免让自身信息传达变得碎片化。Muse、Muse Glimmer、Home Link、社区 gadgets、移动 apps 和未来电视硬件服务于相关目的，但它们运行在不同层面。开发者需要清楚了解哪些内容在本地运行、哪些使用 Meta 的云服务，以及每种 token 允许做什么。

如果 Meta 能清晰传达这些边界，gadget SDK 就能成为其 agent 平台的易用入口。如果访问权限发生不可预测的变化，开发者可能会将其视为临时演示。

哪些迹象能显示 Meta 的 Muse Gadget 押注是否奏效

三项信号将决定 Meta Muse gadgets 是成为一个平台，还是停留在一组有趣的原型。

第一个信号是 Home Link 的现实部署情况。Meta 表示该适配器将于 10 月发货，但仅仅发货并非真正的考验。用户需要能够轻松完成配对、发现有用的 skill，并在新鲜感消退后继续使用这些集成。

值得关注有关设置可靠性、命令延迟、设备发现和操作失败的报告。家庭 agent 必须比用户通过现有 app 完成同类请求更稳定地处理日常需求。

第二个信号是开发者项目的演变。当前 token 政策支持个人实验和有限分享，并不支持常规商业分发。若 Meta 希望制造商或创业公司打造 Muse 产品，就需要提供更清晰的生产路径。

这一路径需要明确记录支持预期、安全要求、审查流程、服务限制和稳定认证机制。扩展商业条款将增强这样一种判断：Meta 将 gadgets 视为可持续的平台。若持续保留个人使用限制，则表明该项目更偏向研究。

第三个信号是社区维护。新的设备集成固然重要，但持续维护更重要。Skills 必须能够经受固件更新、服务更名、API 变更和安全规则演进。

有价值的证据包括活跃贡献、经过审查的安全修复、可靠发布，以及在上线数月后仍能正常运行的项目。若只是一大批被遗弃的演示项目，将削弱 Meta 的平台论点。

用户还应关注 Meta 如何区分本地与云端处理。Muse Glimmer 表明，该公司正在投入可在个人电脑上运行的模型。当前 gadget SDK 的重点是将硬件连接至 Muse，而不是把整个个人 agent 放进廉价微控制器中。

未来的架构可能会在不同层之间分工。小型开发板可处理传感器和基本控制。本地电脑可处理私密上下文或常规命令。云端模型则可管理需要更多计算能力的任务。

这种设计可以降低延迟并限制部分数据传输，但也会增加设置复杂性。Meta 尚未为 gadget 项目承诺采用这种架构，因此它应被视为观察点，而非既定路线图。

更大的问题是，人们是否希望由一个 agent 协调众多实体界面。Meta 的押注是：设备可以变化，但 agent 应保持一致。同一个 Muse 身份可以出现在手机、电视、桌面显示器、音箱或自定义控制面板上。

这一模式不同于拥有多个彼此无关的智能产品，每个产品都有自己的助手和设置。如果权限与上下文能够在设备间安全流转，它可能会简化交互；但它也可能将更多个人访问权限集中于一个平台账户之中。

考虑 Meta Muse gadgets 的开发者，应从可撤销的任务和可见反馈开始。状态显示器、媒体控制器或经手动确认的灯光命令，都为测试系统提供了空间，同时不会造成严重后果。

用户应询问 gadget 能访问什么、数据会流向何处、谁在维护其 skill，以及 Meta 撤销 token 时会发生什么。开放代码让这些问题更容易调查，但不会自动给出答案。

Meta 已让开发者更容易将 Muse 置入几乎任何能够连接至受支持开发板的物件中。接下来，该公司必须证明开放实验能够与可靠访问、易于理解的隐私控制，以及超越工作台的可信路径并存。