一個 SDK token 先被交到了手裡：Muse Gadgets 的硬體原型，是一套被設計好的依賴介面

先從一個小細節看起。Meta 公開 Muse Gadgets 裝置 SDK 之後（來源文章日期為 2026 年 10 月 3 日），開發者拿到手的並不是一個模型，而是一段配對流程：裝置要先取得 SDK token，再透過 iOS 或 Android 上的 Muse App 完成配對，才能連上 Muse 的代理服務。這個順序本身就是設計。它把「誰可以用」的答案放在手機 App 與 token 這一層，也把整套 AI 能力的所有權留在了服務端。

這次開源的範圍，依官方 GitHub 專案的說明，是 ESP32 Device SDK 與 Linux Device SDK 兩套裝置端程式碼與韌體。ESP32 路線可以把支援的開發板接上螢幕、音訊或感測器；Linux 路線則能把 Raspberry Pi 或其他 Linux 主機設定成 Muse gadget，並撰寫自訂命令。兩者的分工很清楚：裝置負責收集輸入、呈現回應或執行明確動作，Muse 透過其服務理解請求並協調工作。

「開源」兩個字在這裡容易被讀得太滿。README 寫明公開的是 SDK 與韌體，TechCrunch 在 Muse 首度公開時的報導也只提到，Meta 表示其代理由 Muse Spark 模型驅動，並未觸及模型權重是否開放。依目前可確認的資訊，裝置需要 token、需要 App、需要服務端配合作動，因此不能推論它能離線運作，或使用者可在本機執行 Muse 模型。這條界線畫在哪裡，決定了這套 SDK 的性質：它是被設計來連接的介面，能修改的只有裝置那一側。

這樣的層次切分，和介面設計裡常見的取捨很類似。一個產品選擇把複雜度收在哪一端、把控制權交出多少，往往比功能清單更能說明它的設計意圖。Muse Gadgets 把硬體端完全打開，讓人自由接感測器、寫命令、做外殼，但理解與決策的權力始終在雲端。與本站先前觀察過的Muse 開放註冊的計費介面對照著看，Meta 這一系列產品有一致的傾向：把「能用的範圍」設計成明確可讀的介面，同時把核心技術收在後面。

兩條硬體路線的表情也不一樣。ESP32 板體積小、功耗低，適合把單一互動做成實體介面，例如按鍵觸發語音、小螢幕顯示回覆。它的設計語言是「少」：一個按鈕、一個燈、一種請求。Linux 路線則相反，README 明言可加入自訂命令，讓 Muse 處理系統管理或智慧家庭設定。彈性放大，風險也放大。來源文章特別提醒，若命令權限過大，一次誤解或錯誤輸入就可能改動檔案、服務或家庭設備；概念驗證宜從只讀查詢與低影響操作開始，以非管理員帳號執行。

這段提醒其實是整個 SDK 最誠實的部分。一份官方文件願意花篇幅講「不要把 shell 權限或家庭自動化的完整控制權直接交給代理」，等於承認了這套介面的核心風險不在硬體接線，而在命令的授權邊界。裝置端被打開之後，真正需要設計的反而是那份「允許的命令清單」：哪些設備可操作、失敗時如何停止。這與我們曾分析的刪庫跑路案裡沒被設計完的權限介面是同一類問題，只是場景從企業資料庫搬進了客廳。

硬體相容性同樣不能只看例子。README 提到的螢幕、音訊與感測器是示意，不是相容清單；腳位、驅動、記憶體與供電都可能造成差異。使用者也仍須自行處理錯誤狀態與安全邊界，這些都屬於整合成本的一部分。

回到最初的判斷：Muse Gadgets 開源的，是一條通往服務的通道，而非服務本身。若目的是研究代理如何接上實體介面、測試自有感測器或家用自動化入口，這套 SDK 提供了一個門檻不高的起點；若目的是掌控完整的 AI 執行環境與資料去向，開源的裝置程式碼並不足以達成。一個 token 加一個 App 的配對畫面，已經把答案寫得很明白了。