Muse 值得注意的地方，不只是 Meta 又推出一個 AI 產品，而是它同時出現在個人 Agent、模型、程式開發與硬體裝置四個層次。把這些東西合稱為「Muse SDK」很方便，卻會誤判它的邊界：截至 2026 年 10 月，並不存在一套涵蓋全部 Muse 能力、狀態各自相同的單一 SDK。
比較準確的讀法是：Muse personal agent 是面向使用者的服務；Muse Spark 與 Meta Model API 是模型層；Muse Code SDK 是控制程式代理 session 的開發介面；Muse Gadget SDK 則把 Agent 接到 ESP32、Linux 裝置與感測器。它們彼此相關，但用途、成熟度、授權與承諾都不同。
Muse 的重要訊號，不是某一個功能已經勝出，而是個人 Agent 正從聊天產品長成一個同時管理脈絡、長任務、權限、介面與裝置的運算平台。
這是 Meta 的產品路線所顯示的方向，也是我的分析；它不等於獨立驗證，也不代表 Muse 已經證明 Personal Context、BYOC 或 Agent Experience 的完整方案。
先把四個 Muse 分清楚
Muse personal agent 是使用者層
Meta 在 2026 年 9 月 8 日發布 Muse personal AI agent，將它描述成能主動協助目標、執行跨網站任務，並在使用者關閉 App 後繼續工作的個人 Agent。使用者可以在 Muse App 或 WhatsApp 與它溝通；官方也表示，Muse 會在寄信、購買等敏感動作前要求確認，提供 audit trail，讓人選擇連接哪些服務，並可要求它忘記特定內容。
截至本文發布日，這些安全、隱私與成效敘述主要來自 Meta 自己的產品公告。它們可以用來分析產品設計，卻不能當成第三方已驗證的可靠度、安全保證或使用者成效。特別是「會記得」這件事，真正需要觀察的不只是記憶量，而是記錯時如何修正、權限撤回後如何處理，以及不同工作情境能否隔離。
Muse 也沒有支持「App 已經消失」的字面說法。它本身有 App，也進入 WhatsApp，背後還要操作其他服務。真正的改變是 Agent 成為主要意圖入口，既有 App 與網站轉成能力與執行環境。
Muse Spark 與 Meta Model API 是模型層
Muse Spark 1.1 公告把它定位成面向 agentic tasks 的多模態推理模型，並同時推出 Meta Model API 的 public preview。這一層提供推理、工具使用、程式與多模態能力，開發者可透過 API 取得模型，而不是直接取得某個人的 Muse 狀態。
Meta 公告中的效能比較、內部評測與合作夥伴引言，都應當作官方或合作方自述。public preview 也表示介面與服務仍可能調整。要評估是否適合正式流程，仍需用自己的任務、成本、延遲、工具成功率與失敗型態測試，不能只以模型榜單代替端到端驗證。
Muse Code SDK 是程式代理 session 介面
Muse Code SDK是用 TypeScript 控制 Muse Code agent sessions 的開發工具，透過 Muse Session Protocol 進行 session 啟動、互動、權限處理、取消與恢復。套件名稱是 @muse-code/sdk，官方 README 明確標示 Developer Preview、pre-1.0，且尚未承諾 API 穩定性。
所以它不是「把完整 Muse personal agent 嵌入任何產品」的通用 SDK，也不能與 Meta Model API 混為一談。前者管理程式代理的 session 與控制流程，後者提供模型推論。對開發團隊而言，這個差別會直接影響資料邊界、錯誤處理與版本策略。
Muse Gadget SDK 是裝置連接層
Muse Gadgets提供 ESP32 Device SDK 與 Linux Device SDK，讓開發者把螢幕、按鈕、感測器、致動器或 Raspberry Pi 接到 Muse。SDK 與韌體程式碼以 Apache 2.0 開源，但連接 Muse 服務所需的 token 另受條款限制。
Gadget SDK Token Terms截至 2026 年 10 月限定個人、非商業使用；一個 token 最多連結 50 台裝置，並明示 Gadget SDK 不是受支援產品、不是正式 developer platform，可能變更、停止或撤回。這表示「程式碼開源」與「服務存取可自由商用」是兩件事。若要把它放進產品路線，必須分別審查程式授權、token 條款、服務穩定性與資料風險。
從產品集合看見 Agent 平台的六個層次
把四組 Muse 放在一起，可以看見個人 Agent 平台正在形成的六個層次：
- 模型層：理解指令、規劃、使用工具與處理多模態內容。
- 個人脈絡層：保存目標、偏好、關係、限制與進行中狀態。
- 執行層：在隔離環境中使用瀏覽器、服務與憑證完成任務。
- 治理層：處理核准、權限、稽核紀錄、忘記與存取撤回。
- 開發介面層：透過 API、session protocol 與 SDK 讓其他程式接入。
- 環境層：把 Agent 從 App 與瀏覽器延伸到眼鏡、感測器與實體裝置。
單一聊天機器人只需要第一層與一小段介面；個人 Agent 要持續工作，就必須同時處理後面五層。Meta 隨後公布的 Meta Enterprise Platform也把 Muse agent、Muse API、Muse Code 等列入企業與開發者技術堆疊。這是平台化意圖的官方訊號，但仍是早期產品宣示，不是成熟開發者體系的證明。
Muse 為什麼與 Personal Context 有關
個人 Agent 若要在 App 關閉後繼續處理長任務，必須知道這次目標、已完成步驟、等待中的外部事件與需要人確認的決策。若要主動提出建議，還要知道哪些偏好具有長期效力、哪些只是單次對話內容。這些都不是把完整聊天紀錄塞回模型就能穩定解決。
從 Personal Context 的角度，我會把需要管理的內容至少分成四類：
- Profile：相對穩定的身份、偏好、關係與權限邊界。
- State：專案、任務、承諾、等待事件與任務進度。
- Knowledge：有來源、版本與適用條件的可用資訊。
- Experience：過去行動、實際結果、修正與已審閱的做法。
Muse 的產品描述顯示大型平台也在投入這些問題，卻不等於它已經實現使用者可攜、跨供應商的 Bring Your Own Context。記憶存在某個服務裡，和個人能匯出、審閱、選擇性帶到另一個 Agent，是不同命題。
因此，Muse 對我的論述比較像一個強烈的產業訊號：Personal Context 正從「聊天便利功能」走向 Agent 的基礎設施。它支持問題的重要性，但不能替代架構、治理與可攜性的實證。
平台化之後，真正難的是控制與回寫
當 Agent 可以操作網站、程式碼與裝置，風險不再只是回答錯誤。它可能真的寄出郵件、改動檔案、購買物品，或讓實體設備改變狀態。這時「記得更多」未必更好，系統更需要知道什麼脈絡能在什麼權限下被使用。
我會用五個問題評估這類平台：
脈絡能不能被看見與修正
使用者不只要能說「忘記」，還需要知道系統記錄了哪些判斷、來源在哪裡、何時寫入，以及修正會影響哪些任務。否則記憶越長，錯誤延續的範圍也越大。
任務狀態能不能跨時間延續
背景執行不能只依靠長對話。任務應有明確狀態、等待條件、期限、重試與取消語意，App 關閉後才能安全恢復，而不是讓模型猜測做到哪裡。
高風險動作是否有獨立的授權層
模型提出動作、系統執行動作與使用者核准動作，應留下不同紀錄。核准必須對應具體內容與影響，不能只靠一次廣泛授權涵蓋未來所有行為。
結果是否真的經過驗證
Agent 說「已經完成」只是聲稱。寄信後要查寄件狀態，訂位後要取得確認號，改程式後要跑測試。只有外部狀態被查回，這次行動才有資格進入經驗層。
經驗如何回寫而不污染個人脈絡
一次成功不必然等於永久規則。系統需要把觀察、候選做法與已審閱規則分開，讓反思先經過驗證與治理，再更新個人脈絡。
開發者現在可以怎麼做
不必等 Muse 或任何單一平台成熟，團隊就能先把自己的 Agent 架構做對。
第一，將身份、任務、知識與經驗拆成不同資料類型，不用一份無邊界的 memory 承擔全部責任。第二，將 action、approval、result 與 reflection 記成可追查事件，避免只有最終文字回覆。第三，為外部能力建立穩定介面，讓模型、Agent runtime 與裝置連接可以替換。第四，為匯出、刪除、來源與版本預留欄位，讓未來的可攜性不是事後補洞。
Muse 的發展值得持續觀察，但不需要把它神化成答案。更務實的結論是：當個人 Agent 同時擁有模型、長期狀態、背景執行、開發介面與裝置入口，產品競爭已經從「誰的聊天回答比較好」移到「誰能建立一個可控制、可驗證、可延續的運作環境」。
這正是 Personal Context → Agent Experience 要補上的整體視角：不是再增加一個零碎工具，而是把脈絡、狀態、行動、結果、反思與回寫放進同一個可治理循環。
這條整合路徑可見Personal Context → Agent Experience母文；Muse 是重要的產品趨勢證據，但仍只是完整循環中的一組平台實作。