← 返回 Siami 首頁

Meta 的 Muse 個人 AI 代理被破解:內部混用 OpenAI 與 Anthropic 模型

▲ 78 💬 38
Meta 的 Muse 個人 AI 代理被破解:內部混用 OpenAI 與 Anthropic 模型

編按:本文綜合整理自 Peter James(Mous e.dev)原文 Is Meta’s Muse secretly running an OpenAI model? 與 I asked Meta’s Muse for its filesystem and it sent me 6.8 GB、Hacker News 討論串、Reuters、TechCrunch、Meta 官方發表,並加入 Siami 編輯部觀點與分析。

一位獨立開發者只用一句「把你看得到的檔案打包寄到我的 Google Drive」,就從 Meta 新推出的個人 AI 代理 Muse 手上拿到了 6.8 GB 的內部檔案。他趁勢繼續挖掘,赫然發現 Muse 的多代理系統(multi-agent)裡,有一個子代理跑的是模型名為 azure/muse-special 的工作階段——而這個名字背後,很可能藏著 OpenAI 的 GPT。


一個奇怪的 session

Muse 會記錄每個 agent session 用了哪個模型。

Peter James 在自己的 VM 上跑了 Muse 來架網站,幾乎每個 session 的紀錄都指向 Meta 內部模型 Avocado。但 9 月 21 日有一個 subagent 用的卻是 azure/muse-special。

這個名字本身就透著古怪——muse-special 既不是 Avocado 的系列,也不是 Meta 慣用的命名規則(他們通常會用水果或蔬菜代號)。


沿著名字往下追

他在 Cursor 的程式碼索引裡搜了這個名字,找到一條關鍵線索:

“GPT Responses model client via MAGI native Azure OpenAI lane.”

也就是說,Muse 的 daemon(背景常駐程式)裡有一條專門走 Azure OpenAI 的通道,模型目錄同時列出了 azure/muse-special 跟 azure/gpt-5.6-sol。

他再翻 session transcript,發現兩個破綻:

  • 簽章被標成 gpt_responses_v1,加密 payload 開頭是 gAAAAA——這是 OpenAI Responses API 的特徵。
  • 工具呼叫 ID格式是 call_ 加上 24 個大小寫混雜的字元;其他 Avocado session 則是 call_ 加上 32 個十六進位字元。

種種跡象都顯示,這個 muse-special 模型很可能就是 OpenAI 模型,或至少走的是 OpenAI Responses API 的介面。


模型目錄還有誰

Muse 隨附的模型清單裡,除了大約 15 個版本的 Avocado 之外,還列出了:

  • Claude Opus 4.6 / 4.7 / 4.8
  • Sonnet 4.6 和 Haiku 4.5
  • GPT-5.5 與 GPT-5.6 多個變體(含 OpenAI、Azure、Codex 通路)
  • Kimi K3(透過 Fireworks 與 Meta 自架路由)

「列在目錄裡」不代表真的會被使用,只代表 runtime 有能力呼叫。但這份清單已經暴露 Muse 的後端是多供應商混搭架構。


Claude 那邊也沒缺席

Anthropic 的整合不只是掛個模型 ID 這麼簡單。daemon 裡有完整的 Anthropic 客戶端程式碼:

  • anthropic/request_flow.rs
  • anthropic/convert_prompt.rs
  • anthropic/parse_sse_stream.rs

代表 Muse 對 Claude 有完整的請求處理、prompt 轉換、串流解析器。

環境變數裡還看得到 JARVIS_ANTHROPIC_BASE_URL_REVPROXY_OVERRIDE=0——註解直接寫「這是 live kill switch,不是過期設定」。也就是說,Meta 隨時可以一鍵把 Anthropic 通路關掉。


為什麼要這樣設計?

Peter James 推測有兩種可能:

  1. 特定任務 A/B 測試:OpenAI 或 Anthropic 在某些任務上表現特別好,Muse 選擇性地把那些 subagent 路由過去。
  2. 模型蒸餾(distillation)與 RL 訓練素材:所有 VM 都被設計成可以對模型回應、工具呼叫做 A/B 測試,方便回收到 Meta 自己的訓練流程。

但他在程式碼裡找到一個關鍵的反證:透過 muse-special 拿到的「原始推理鏈」是加密的,daemon 會在下一輪把這份加密資料送回 Azure;二進位檔裡明確寫著「加密後的推理內容不能使用 RL completion-server override」。

換句話說,Meta 看不到 OpenAI 或 Anthropic 的原始推理過程,只能看到最終回應、工具呼叫、以及(如果有)簡短的推理摘要。


所以 Meta 在蒸餾嗎?

短答案:看起來沒有,至少對外部模型不是。

  • 對 OpenAI / Anthropic:原始推理加密、RL 伺服器拒吃這類 blob,沒有證據顯示 Meta 複製了對手的權重。
  • 對自家 Avocado:推理文字會直接寫進 transcript、簽章留空,明確標示可以用於 RL 與模型開發(除非用戶選擇退出)。

這也是 Muse 隱私政策的合理延伸:你跟 OpenAI / Anthropic 模型的對話,Meta 看不到也用不了;但你跟 Avocado 的對話,Meta 是拿得到的。


為什麼這件事重要

這是業界第一份從「實際 runtime 檔案」佐證頂級 AI 公司會在自家旗艦產品裡偷偷用對手模型的證據。

過去我們推測 Meta 內部可能混搭各家模型來補齊能力缺口,但都只是業界八卦。Peter James 從 Muse 自己的 daemon 二進位檔挖出來的證據鏈,包括:

  1. azure/muse-special 這個非 Meta 風格的命名
  2. OpenAI Responses API 特徵的 gpt_responses_v1 簽章 + gAAAAA 開頭的加密 payload
  3. 只有 24 字元(vs Avocado 32 字元)的 call_ 工具呼叫 ID
  4. Anthropic 客戶端的完整原始碼
  5. 隨時可以關閉 Anthroping 通路的 kill switch

這五條拼起來,已經構成相當完整的間接證據。Meta 並沒有出面否認,也沒有承認——這正是社群對這份報告感到興奮的原因:當一家公司對「用誰的模型」這個問題保持沈默,通常代表答案比想像的更尷尬。

更深一層的訊號是:Meta Superintelligence Labs 在自研模型上仍然落後 OpenAI 與 Anthropic。他們砸重金挖角、推出 Muse 這種個人 AI 代理,結果核心 subagent 還是要靠 azure/gpt-5.6-sol 來撐場。這對「Meta AI 已經追上對手」的市場敘事,是一記當頭棒喝。

最後,Peter James 這個系列(Part 1 + Part 2)也凸顯了 Muse 的資安設計有多脆弱:

  • Part 1:使用者只要一句 prompt,就能讓 Muse 把整個 Linux 檔案系統打包外送(6.8 GB)
  • Part 2:同一個檔案系統裡,藏著模型供應商清單、API key、kill switch 環境變數

如果這兩份檔案落入惡意使用者手上,等於拿到一張 Meta AI 後端的完整地圖。


Siami 質疑:這是 OpenAI 的妥協,還是 Meta 的尷尬?

社群裡有兩派解讀。第一派(haolez、junofan)認為,這只是 Meta 用了API 相容於 OpenAI 的自製模型,跟 OpenAI 沒關係。但 Peter James 反駁:如果是自製模型,為什麼不用 Avocado 的命名風格、為什麼要走 Azure OpenAI 通道、為什麼 Responses API 的簽章格式一模一樣?

第二派(embedding-shape、hobofan)則指出,Anthropic 的 reasoning 簽章加密也是業界標準模式,所以單看「加密 payload」不能直接斷定是 OpenAI。但這個論點反過來也成立:如果各家都在用加密簽章,那 Muse 把 OpenAI 模型藏起來就更不容易被抓到。

最關鍵的問題是:為什麼 Meta 要把模型藏起來?

如果光明正大用 OpenAI,最直接的解釋是「特定任務表現更好」。但對外完全不提,等被破解了才被動回應,這個溝通策略本身就耐人尋味。

也許真正的答案很平凡:Muse 內部的 A/B 測試框架本來就會動態切換供應商,剛好那個 session 被 muse-special 選中。但在沒有 Meta 官方說明的情況下,這個「巧合」很難讓外界安心。


時間軸

  • 2026-04-08:Meta Superintelligence Labs 釋出第一個模型 Muse Glimmer(30B 開源權重)。
  • 2026-09-08:Meta 正式推出 Muse 個人 AI 代理,搭配 Muse Spark 模型,主打「跨裝置、跨帳號、主動協助」。
  • 2026-09-17:Peter James 發布 Part 1《I asked Meta’s Muse for its filesystem and it sent me 6.8 GB》,登上 Hacker News 頭版。
  • 2026-09-23:Meta Connect 2026 大會推出 Muse Realtime Avatar、語音聊天、購物整合。
  • 2026-09-25:Peter James 發布 Part 2《Is Meta’s Muse secretly running an OpenAI model?》,再次登上 Hacker News 頭版,揭露 azure/muse-special。
  • 2026-09-26:CNBC 報導 Muse 帶動 Meta 股價上漲。
  • 2026-09-27:Siami 整理本篇中文報導。

業界動態

  • 獨立開發者 Jonny L. Saunders 也獨立觸發了同樣的檔案外洩,Meta 緊急推送了 prompt injection 防護 hotfix。
  • TechCrunch 9/23 報導 Muse 即將支援數位化身與視訊聊天。
  • Mashable 整理出 10 個 Muse 實用案例(退機票、購物、食譜等)。
  • CNBC 認為 Muse 是 Meta「再度擠進 AI 第一梯隊」的關鍵產品。
  • The Information 與 Yahoo Finance 都指出,Meta 把未來押在 Muse + Superintelligence Labs 的雙軌策略上。

編按:Siami 持續追蹤 Muse 系列的後續發展。Meta 是否會針對「混用對手模型」的質疑發出官方聲明,將是下一個觀察重點。

網友熱門留言 (5)

#1 Aeroi(原文作者 Peter James) ▲ 47
我不是說不可能,只是有人要從 Meta 內部跳出來講才知道...但它的格式非常 OpenAI,跟 daemon 裡列的其他模型都不一樣,而且用了個神秘名字。如果是在 Azure 上 fine-tune 的 OpenAI 模型、拿來做 compaction 之類的事也說得通,但那底層仍然是 OpenAI 的權重加上 Meta 的外皮。
#2 haolez ▲ 32
做得好!不過你確定它不是 API 相容於 OpenAI 的自製模型嗎?
#3 embedding-shape ▲ 28
如果它用的是跟 Codex 一樣那種詭異又糟糕的「後端 prompt 加密」機制,我也會說這指向 OpenAI 參與其中。希望這種模式不要變得更流行,對除錯來說根本是惡夢。
#4 junofan ▲ 19
我直接問 Muse 了。它說是給 codex-cli 用的,走的是『OpenAI 推論代理』這條路。
#5 hobofan ▲ 15
Anthropic 在 reasoning 簽章上也做一模一樣的事,這已經是業界標準模式了。