Muse 解析：Meta 的個人 AI 代理、其安全虛擬機器，以及沒人拿得到的邀請碼

如果你搜尋過 Muse 代理，你大概有兩個問題。第一個是你能否取得使用權：Meta 的 Muse 在 Meta 自家文件中完全沒有邀請碼、候補名單或存取碼，而本頁會向你展示這個答案從何而來，而不是要你憑信心接受。第二個是 Muse 究竟是什麼，因為這個名字會被冠在許多 Meta 推出的東西上。Muse Spark 是底層模型；Muse 是它所驅動的產品。Muse 是一款個人 AI 代理，Meta 在為此目的打造的電腦上運行它，而值得理解的工程重點不在於它能做什麼，而在於 Meta 已決定絕不能讓它觸及什麼。

這裡有兩個日期值得注意，但兩者都不是撰寫本頁面的理由。Meta 於 2026 年 9 月 8 日推出 Muse，並於當天在美國啟用；在 2026 年 9 月 23 日的 Connect 大會上，Meta 表示將把 Muse 引進其 AI 眼鏡。第二個日期是過去七天內唯一的 Muse 事件，此處僅用來標定產品時間，並非作為撰寫文章的依据。這是該名稱的參考頁面——供搜尋「muse agent」卻只找到我們發布報導的讀者造訪，那是唯一值得提供的連結，沒有什麼值得重述的內容。以下所有內容均出自 Meta 自家的公告和 Meta 自家的安全報告，兩者皆於 2026 年 9 月 29 日重新閱覽，且其中每一項數據均為 Meta 所提供，除非本頁面另有說明。

Muse 是什麼，以及它不是什麼

Meta 自家的摘要盡可能直白地劃出差異：「Muse 是一款個人 AI 代理。它不只是回答問題，而是真的完成工作。」實際上，這意味著 Meta 描述 Muse 會處理離散任務，例如寄電子郵件或預訂旅行，也會承接開放式目標——把一個表達出來的抱負轉化為個人化計畫，然後自行推進。對於比一次工作階段更久的工作，Meta 表示 Muse 會在應用程式關閉後繼續運作，並在有事項變更或需要核准時回來。互動模式是傳訊，而不是聊天視窗：你可以在 Muse 應用程式裡或直接在 WhatsApp 中與它交談，而且它「由 Muse Spark 驅動，這是 Meta 迄今為止能力最強大的模型，專為像這樣的現實世界代理式工作而打造。」

Muse 不是什麼，對任何從搜尋入口進來的人來說同樣重要。它不是你能從 API 呼叫的模型，也不是披著人格的聊天介面。它是一款 Meta 代表你營運的消費級產品，跑在 Meta 掌控的基礎架構上，而且它不是你能自行安裝的東西。Meta 並未針對 Muse 本身發布任何基準測試——沒有分數、沒有排名、沒有正面對決——而這個缺席是文件本身的事實，不是本頁能用替代指標填補的缺口。評估 Muse 的誠實方式，是去讀它的架構與可用性，這也是本頁接下來要談的內容。

為什麼代理需要一台屬於自己的電腦

要從 Meta 的這句話開始：「Muse 在 Muse Secure VM 上執行，那是一台配有自己的瀏覽器的專用安全電腦」，同一則貼文他處將它描述為「一台專用的虛擬機器（VM），同時容納代理程式與個人的資料」，並加以隔離，讓其他任何人的代理程式都無法觸及。那裡儲存著每個人所連接的每一項服務的憑證與資料。在閱讀時，Meta 對設計目標的表述值得放在心上：同一部機器上有兩個彼此隔離的安全網域，而不是一個擁有 root 權限的語言模型。

Meta 的安全說明文章〈我們如何將安全性打造進 Muse〉遠比公告來得具體，任何關於這個代理程式值得多少信任的主張，都應該引用它作為來源。代理程式執行框架、工作區檔案，以及 Muse 執行的每一項工具，都運行在systemd-nspawn執行階段容器內。該 cell 內部的 root 會對應到主機上的一個非特權使用者，因此 cell root 並不是 host root。該 cell 擁有自己的根檔案系統，與存放更敏感資料的主機檔案系統分開，另外還有虛擬網路介面、經過篩選的系統呼叫——例如沒有 io_uring——以及一組受限制的能力：沒有 CAP_SYS_PTRACE，也沒有 CAP_NET_ADMIN。在 cell 之外，另有一些獨立的 systemd 單元負責執行那些不能從 cell 內部切換的保護措施，包括一層獨立模型與分類器，用來檢查推論請求和回應是否含有提示注入與前沿風險。Meta 將這些保護措施放在外面的理由是，執行階段 cell 預期會處理不受信任的資料。

綜合來看，這些選擇回答了讀者真正想知道的問題：Muse 能觸及什麼？它能觸及網路，但只能經由另一個系統控制的路徑。它能驅動瀏覽器，但無法觸及瀏覽器的內部。它能持有憑證，卻無法看見它們。

Sentinel 決定；Muse 僅提出建議

Meta 的公告用一句話介紹了這個元件：「一個獨立的 Sentinel 代理程式會在該同一台機器上執行，並在系統層級與 Muse 保持隔離。」安全性說明文件才是明確載明權限的地方，而且毫不含糊——「Sentinel 是連接器動作與網路出口的唯一權限授權者」——順序也是如此：Muse 提出動作，但只有 Sentinel 能授予執行這些動作的權限。Sentinel 會根據使用者所設定的連接器政策，對任何提議的動作回傳三種答案之一：允許、拒絕或詢問。除非 Sentinel 批准，否則 Muse 所做的任何事都不會連上網際網路；而 Sentinel 在有必要時會詢問當事人。

這背後的機制異常具體。就網路出口而言，Sentinel 會在第 4 層與第 7 層進行檢查——主機名稱、解析後與最終 IP、連接埠、協定、方法、路徑，以及解碼後的請求本身——並套用 SSRF 限制，讓公開主機名稱無法解析到私有基礎架構。憑證會即時插入於網路邊界，只在使用的那一刻將代理權杖替換為真實憑證，這就是為什麼 Meta 形容透過提示注入誘騙代理交出真實密鑰的嘗試是徒勞的。汙染傳播以 eBPF cgroup 程式與 LSM 鉤子實作，決定某個動作何時失去其自動允許。這是 Meta 在 Meta 產品內部的架構：這不是我們的功能，我們也不會揭露或轉售其中任何部分。

核准、憑證與瀏覽器

對任何決定要讓代理做多少事的人來說，另外三項設計選擇最具關鍵影響。

核准是能力，不是對話。Meta 的句子很明確：「透過 human in the loop 系統授予的核准是嚴格的能力，不是對話式的建議。」每一項授予都綁定到特定的連接器或目的地，以及特定的使用情境，而系統支援一次性、工作階段範圍、任務範圍、有時間限制或永久的權限。Sentinel 會選擇要提供哪些授予類型，並驗證後續的呼叫是否符合當初授予的範圍。請求會傳送到 Muse 用戶端介面，而不是透過對話傳遞，而回覆會直接路由回 Sentinel。購買每次都需要人工核准。唯讀、先前已允許或可證明為低風險的動作會跳過這個中斷，而這正是 Meta 明確表明、而非隱藏起來的取捨。

認證資訊存放在 VM 內部。hatch-authd是執行於執行環境單元（runtime cell）之外、具安全敏感性的服務之一，負責處理認證資訊的儲存與代理，因此主要代理程式永遠不會看到敏感的認證資訊。已連線服務的 OAuth 權杖儲存在使用者的 VM 中，而非集中式的 Meta 基礎架構。另外，有一項名為privsep的服務，以嚴格限縮的權限執行內建的連接器程式碼，讓已連線的認證資訊不會落入代理程式的可及範圍。Meta 自己對這項結果的總結是，Muse 無法看到任何密碼或付款方式，包括使用者自己輸入瀏覽器的密碼。

瀏覽器是由仲介管理的。Meta 將該瀏覽器描述為由一個獨立的仲介管理，該仲介擁有 Chrome DevTools Protocol 連線，而子代理則透過頁面的無障礙樹快照（而非原始 DOM）來驅動它。其後果被明確陳述：無法在頁面上下文中執行 JavaScript、沒有腳本動詞、無法在瀏覽器處理程序中執行，且 DevTools 已停用。由於輸入是無障礙樹，子代理無法讀取從認證資料庫輸入的認證資訊，也無法從 DOM 中退出以尋找它們。當有人接管瀏覽器時，或當認證資料庫正在填寫表單時，代理會暫停且完全無法行動。

漏洞賞金計畫才是應該當作訊號來解讀的部分

Meta 表示，它透過內部試用（dogfooding）、代理式紅隊演練以及私有的漏洞賞金計畫來強化 Muse，接著將該計畫開放給所有人：針對根據已證實影響的有效報告，最高提供 30 萬美元，其中包括對影響單一使用者的成功提示注入嘗試，最高提供 13 萬美元。這些是 Meta 所稱的計畫最高金額，並非實測結果，而且 Meta 以外沒有人能說這些獎金實際多常發放。

這份披露之所以有用，在於它的樣貌。單一最大的具名類別既不是越獄，也不是 Meta 端的資料外洩——而是一個網頁或一封電子郵件，在單一使用者的工作階段內誘導代理去做某件事。那就是 Meta 正在計算成本的威脅模型，也告訴你第一天該注意什麼：使用者授予的連接器權限，以及代理在依這些權限行事時所讀取的內容。

可用性，完全如 Meta 所述

Meta 的話，於 2026 年 9 月 29 日重讀：「Muse 正在美國的 iOS、Android 和 muse.ai 上逐步推出，並即將登上 AI 眼鏡。對大多數人的需求而言，它是免費的，並為想做得更多的人提供訂閱方案。」這兩半都值得按字面解讀。這是在一個國家、橫跨三個介面的逐步推出，AI 眼鏡則被列為未來的一員。而定價那句話是有關 Meta 自家消費產品的陳述——它對任何其他平台的層級隻字未提，包括我們的在內，而本頁面並未延伸其意涵。

過去七天內唯一有明確日期的一則消息，就是眼鏡產品線：Meta 在 2026 年 9 月 23 日的 Connect 大會上把它說明白了——該公司要把個人 AI 代理 Muse 帶進旗下 AI 眼鏡，主軸圍繞著以免持方式打理日常生活。這項發表並未給出上市日期。值得關注的藍圖項目是 Muse 機密虛擬機器（Confidential VM），Meta 表示將於今年稍晚推出；在這項技術中，整個 VM——包括個人資料以及與 Muse 的對話——都會以只有使用者本人持有的金鑰加密，因此就連 Meta 也無法存取。

這一頁無法查核的一件事：Muse 的第一方產品頁面存在於 ai.meta.com/muse，且標題有回傳，但在我們 2026 年 9 月 29 日的讀取中，其內文並未成功取得。那是我們無法檢視的頁面，而不是釐清了任何事情的頁面，因此這裡沒有任何內容取自它。

邀請碼：Meta 未記載任何內容

大家都在 Meta Muse 底下尋找邀請碼、邀請代碼，以及一個進入的方法。老實說，這些在 Meta 自己的資料裡全都不存在。9 月 8 日的公告完全沒有邀請、推薦、等候名單或存取碼這類措辭；存取方式純粹以地理區域與平台來描述，而限制條件就是美國加上 iOS、Android 與 muse.ai。9 月 23 日的眼鏡貼文同樣沒有提到任何取得存取權的方法。所以，沒有代碼可找，沒有隊伍可加入，也沒有任何有紀錄的機制能讓別人給你一組。

有兩點值得直說，因為把猜測包裝成答案，會比直接給出否定答案更糟。我們只能報導 Meta 公開的內容；如果某個需代碼才能參與的計畫存在於某處而未列入清單，Meta 自家頁面並未記載它，而我們任何頁面都不應被解讀為承諾有這樣一個計畫。而這個章節之所以存在，正是因為這個名稱正以這樣的形式被搜尋：這個詞組有穩定的搜尋量，而我們目前所有回應這項搜尋的頁面，都是那篇發布文章——這正是需要一個參考頁面、而不是再一篇公告的情況。

你能呼叫 Muse 嗎？不行——而這就是我們路由的方式

Meta 的 Muse 是一款消費性產品，不是我們所列出的模型；而 OrcaRouter 是否提供任何與其對應的服務，答案是我們沒有：muse-agent 不是我們目錄中的路由，而 Meta 的代理程式也不是我們所代管、代理或轉售的東西。承載底層模型與承載代理程式是兩回事，而本頁不會模糊兩者。截至 2026 年 9 月 29 日，Meta 的 Muse Spark 價目表也未以我們能讀取到的任何形式發布，因此此處沒有任何內容是將價格歸因於 Meta。

我們目前的即時模型清單確實有收錄、且今天查核過的，就是模型本身：Muse Spark 1.2，這是 Meta 所描述、用於複雜代理式任務的推理模型檢查點，上下文視窗為 1,048,576 個 token，並與 Muse Spark 1.1 並列。我們為它建立的模型卡是一條即時路由，本週有實際流量導入，依供應商費率計費、我們不加價——因為我們是直接轉嫁供應商的定價，而不是加上利潤，所以 Meta 一旦調整價格，當天就會反映在我們這邊。較新的 1.3 檢查點不在我們目錄中，而我們不會列出無法供應的項目。如果你想要的是以開發者身分、而非以產品形式取得該代理的能力，呼叫我們確實有在路由的檢查點，才是你真正能完成的購買，而同一把金鑰也能直接觸及目錄中其餘項目，無須再申請第二把。

未解決的問題

Meta 並未為 Muse 發布任何基準測試，因此沒有計分板可爭論，剩下的問題在於：一個異常嚴格的權限模型，能否在與實際工作接觸後依然成立。有三件事值得觀察：當代理在連接數個連接器的情況下執行長時間、無人看管的任務時，Sentinel 的能力授權是否仍站得住腳；Meta 將懸賞定在最高 13 萬美元的提示注入類別，是否會在真實環境中出現，因為懸賞公開意味著未出現的報告是一項可被檢驗、而非僅憑信任的主張；以及 Muse Confidential VM 是否會如 Meta 所言在今年稍晚推出，這將把信任錨點從 Meta 的基礎架構轉移到使用者持有的金鑰上。

對今天正在做決定的讀者來說，這個決定並不重大。如果你在美國，使用 iOS、Android 或網頁版，Muse 並沒有被任何你得費心尋找的東西擋住——你打開它，選擇要連接哪些服務，留意它要求哪些權限，並讓稽核軌跡保持在視線範圍內。如果你在其他任何地方，或是在 Meta 尚未推出的平台上，那就沒有東西可以兌換，也沒有代碼可找，而誠實的建議是：別再找了。而如果你想要的是模型，而不是代理，那是另一筆簡單得多的購買，是在路由檢查點上完成，而不是透過訂閱。