九月八日登場：Meta 把代理從開發者推向每個人
Meta 在 2026 年 9 月 8 日發布個人 AI 代理 Muse，並以「世界首個為所有人打造的個人 AI 代理」為題向大眾推介。官方公告對它的定義寫得很直接：Muse 是「一個安全、私密的個人 AI 代理，會主動幫助人們達成目標並提出建議」。祖克柏也在個人頁面親自向用戶介紹這款產品。Muse 首波以美國用戶為對象，已經上架美國 App Store，以獨立應用的形式推出，Meta 未公布其他市場的開放時程。
對 Meta 而言，這一步與先前冠上 Muse 之名的產品意義不同。四月以來，Meta 陸續推出基礎模型 Muse Spark、終端編碼代理 Muse Code 與本機代理模型 Muse Glimmer，對象都是開發者與研究社群；Muse 則是這條產品線第一次直接面對一般使用者——一個會替你動手做事、而不只是陪你聊天的代理。官方新聞室對它的形容是：Muse 不只回答問題，還會把你交代的事情實際做完。
不只回答問題：Muse 代辦的多步任務長什麼樣
從官方產品頁與新聞室的說明看，Muse 的任務範圍圍繞著日常代辦。它可以連結的服務橫跨電子郵件、行事曆、支付、健康、購物與智慧家庭等類別；經使用者授權後，可同步 Google 行事曆與 Gmail 等服務，作為代辦的事實基礎。
具體任務上，官方列出的例子包括代寄郵件、預約行程與訂位、追蹤價格變化與預算，以及更大型的長期目標——例如規劃一套為期一年的運動計畫。據《紐約時報》發布當天的實測報導，訂餐廳之類的任務可透過 OpenTable 等第三方服務完成。與聊天機器人最本質的差異有二：一是任務跨越多個服務、需要多步規劃與工具呼叫；二是它能長時間在背景代辦，你不在螢幕前時任務仍持續推進，並在你的方向與監督下進行。
換句話說，Muse 賭的是「代理」一詞的字面意義：不是告訴你怎麼訂票，而是拿到授權後把票訂好、把信寄出、把帳單整理成預算表。這也正是它必須先回答安全問題的原因——一旦代辦的事項涉及你的信箱、行事曆與支付帳號，出錯的代價就不再是答錯一句話，而是真實世界的損失。
Muse Secure VM：每位用戶一台隔離的專屬電腦
Muse 的安全設計核心，是一個叫 Muse Secure VM 的執行環境：每位用戶分配到一台專屬的隔離虛擬機器，配有自己的瀏覽器，代理在這台機器裡代替你瀏覽網頁、操作各項服務。Meta 研究團隊在安全架構說明文章裡寫得明白：「今日的 Muse 架構讓每位使用者的資料彼此隔離並保持安全」，並限制內部人員對用戶資料的存取——這兩句承諾都出自 Meta 研究部落格對這套架構的說明。
第二道防線在憑證。官方說明指出，各項服務的登入憑證存放在一個代理本身讀不到的安全存放區——代理能「用」你的帳號完成任務，卻無法直接「讀出」你的密碼。Meta 研究團隊並用一句話總結這套結構的用意：這台 VM 經過審慎的結構設計，把「你與你的 Muse 所做的一切」，和「為了保護你而內建的一切」分隔開來。
用白話講，Secure VM 解的是兩個問題。第一是爆炸半徑：代理要代你操作真實服務，就必須接觸你的帳號與資料；把每個人的代理關進各自的隔離機器，等於把任何單點出事的影響範圍限縮在單一使用者內，不會橫向波及其他人。第二是內部風險：資料隔離與存取限制同時約束了 Meta 內部人員翻看用戶資料的可能——這對一家以廣告業務為主的公司而言，是把「代理商代你保管信箱」與「平台拿你的資料投放廣告」兩件事在架構上脫鉤的必要承諾。
先講安全再談能力：信任是個人代理的入場券
為什麼 Meta 發布一款消費者產品，要同步讓研究團隊發一篇安全架構長文？因為 Muse 觸及的資料遠多於任何聊天機器人：郵件、行事曆、支付、健康資訊，加上背景長任務——等於把「代理在你看不到的時候替你做決定」變成常態。信任不是這款產品的加分題，而是前置條件。
媒體在發布當天也幾乎都把問題指向同一處。TechCrunch 的報導標題直接問消費者會不會信任它；CNBC 則把 Muse 的推出形容為 Meta 在隱私與安全上的一次全民公審時刻。這樣的疑慮其來有自：Meta 過去十年以廣告模式建立在個人資料之上，如今要使用者把信箱與支付帳號交給它的代理，說服成本自然高於對手。祖克柏先前「超級智慧時代的完全隱私」宣示，在這款產品上第一次面臨大規模的實際檢驗（見〈Meta 超級智慧宣言〉）。
值得注意的是，個人代理這個品類已經不是 Meta 一家的賽局。據 Virginia Business 報導，Muse 的產品形態以開源個人代理專案 OpenClaw 為藍本——換句話說，Meta 選擇把一個已在開源社群驗證過的代理形態，包上自己的安全架構與帳號體系推向大眾。差別不在於誰先想到，而在於誰能先把「敢把信箱交出去」這件事做起來。
從 Muse Spark 到 Muse：五個月生態系的最後一塊
把 Muse 放回 Meta 超級智慧實驗室五個月的節奏裡，看得出它是整條產品線的收網之作。4 月 8 日，基礎模型 Muse Spark 1.0 推出，是實驗室首個閉源專有模型；8 月初，終端編碼代理 Muse Code 隨 Muse Spark 1.2 登場，接著 30B 本機代理模型 Muse Glimmer 開源；9 月 2 日 Muse Spark 1.3 上線，開發者端的模型與工具鏈到位；9 月 8 日，消費端的 Muse 補上最後一塊。
至此，這條生態系湊齊了四個層次：基礎模型（Muse Spark）、開發者代理（Muse Code）、本機代理模型（Muse Glimmer，其權重開放爭議我們在 Muse Spark 開放權重預告追蹤過）、以及個人代理（Muse）。這樣的鋪法與對手的路徑相呼應——OpenAI 與 Anthropic 同樣從模型走到代理產品，差別在於 Meta 第一次把代理直接推到數十億社群用戶面前，而不是停在開發者與訂閱用戶。需要說明的是，官方發布並未揭露 Muse 目前由哪一個模型版本驅動，這一點仍有待後續文件補充。
對使用者與開發者的實際影響
對一般使用者，最直接的影響是「代理」從演示走進 App Store：美國用戶現在就能下載試用，免費方案與付費月訂閱並行。但初期的合理預期應該保守——跨服務多步任務的可靠度、訂票與支付環節的錯誤率、以及出錯時的補救流程，都要等真實使用者的回報才能判斷。穩妥的起步方式是先交付低風險權限（郵件摘要、行事曆整理、比價通知），觀察一段時間後再考慮支付類的授權。
對開發者與產品團隊，Muse 是一份值得拆解的參考樣本。它的批准流程、背景任務通知、憑證授權與撤銷的互動設計，會成為個人代理類產品的事實基準；Secure VM「每位用戶一台專屬機器」的架構選擇，也把成本結構的問題攤在桌上——若要規模化到數億用戶，每用戶一台常駐虛擬機器的運算成本，會是這條路線能否走下去的關鍵工程課題。對企業則是新的邊界問題：當員工把公司信箱與支付帳號接上個人代理，資安部門要管理的不只是設備，還有第三方代理的存取行為。
限制與值得追蹤的後續
這篇報導有幾個必須交代的前提。第一，關於 Muse 能力的描述主要來自 Meta 官方頁面與發布當天的媒體報導，AIDM 並未實測，獨立評測也尚未出現。第二，安全主張同樣是 Meta 自述：Secure VM 的隔離與憑證設計在文件上說得完整，但還沒有第三方安全稽核背書，研究社群對「代理讀不到憑證」這類設計在實務上能否擋住所有繞過路徑，也還需要檢驗。第三，美國以外的推出時程、定價與語言支援全部未定。
後續值得追蹤的指標依序是：首月是否傳出安全事件或濫用案例；批准流程會不會淪為使用者盲目點「同意」，使安全設計名存實亡；OpenClaw 等開源代理社群是否出現對照實作；驅動 Muse 的模型版本何時揭露；以及對 Meta 更根本的問題——用戶有沒有真的把信箱交出去。個人代理的賽局才剛開始，Muse 把第一份完整的安全敘事放上檯面，但敘事與信任之間的距離，要靠時間與第三方檢驗來縮短。
