你帶 API 來就好：Meta 把 Muse 連接器平台開放給開發者

十天。這是 Meta 從發布個人 AI 助理 Muse，到開放這個產品最具戰略意義的介面——連接器（connector）平台——給第三方開發者，所花的全部時間。

美東時間 2026 年 9 月 18 日晚間 7 點 03 分，Mark Zuckerberg 發文宣布：「開放開發者建造 Muse 連接器。」貼文連向 muse.ai/platform——一個只有一個按鈕（Submit a connector）的單頁網站，以及一段最好被視為整個消費級 Agent 時代宣言的三句話推銷：

「你帶 API 來——Muse 帶來 Agent、瀏覽器，以及這個人真正想要什麼的上下文。人們只要開口就能觸及你的服務，他們的 Agent 會接手完成後續。」

兩小時內，這則貼文瀏覽量突破 23 萬。隔天早上，整個開發者社群開始拆解這則消息——重點不在 Meta 公布了什麼，而在它略過了什麼。

實際上線了什麼

平台頁面描述的是一個流程，而不是一個完整的計畫。三個步驟：

1. 描述你的產品——告訴 Meta 你的連接器做什麼、使用者會怎麼用。
2. 提交審核——Meta 針對「功能性、安全性與法務要求」進行審查，並執行端到端測試。
3. 進入目錄——核准後，使用者就能在 Muse 裡找到你的連接器，而且「編輯團隊會審核連接器以決定精選排名」。

最後這句話承載著安靜但沉重的分量：編輯層意味著消費級 Agent 內部的精選版位——一種新型態的貨架空間，由 Meta 的編輯排名，而不是使用者看得到的演算法。

付款方面，Meta 表示已「與 Stripe 合作，透過 Link 讓收款變得簡單」——這正是 Muse 自己的 Agent 結帳已經在用的同一條支付軌道，獲超過一百萬家商家支援。

而頁面上沒有公布的，恰恰是開發者投入工程資源前真正需要的東西：

• 沒有 SDK 或 API 規格
• 沒有費用或分潤結構
• 沒有審核時程
• 沒有開發者服務條款
• 沒有首發合作夥伴或範例連接器清單

提交表單只要求描述產品——不是程式碼——而且頁面沒有說明描述送出之後，連接器由誰來寫。

一個詞，兩種連接器

Meta 的說明中心早已用「連接器」這一個詞描述兩種不同的東西，而理解這個差異是正確解讀此次開放的關鍵。

目錄連接器（directory connectors）是新平台頁開放的那一類：由企業提交、經 Meta 針對功能性、安全性與法務合規審核、列在 Muse 的設定選單裡，使用者一鍵即可連接。

自訂連接器（custom connectors）則從上架那天就存在：任何使用者都可以要求 Muse 為任何有 API 的服務建造一個連接器，Meta 當場為那一個使用者打造。Meta 對此的風險提示罕見地直白——它「不審核自訂連接器，也不審核它們如何使用你的資訊，所以授權時請謹慎，並檢視供應商的隱私政策」。

對企業而言，這形成了一個微妙的局面：你的客戶現在就已經可以透過 Muse、在沒有任何條款規範的情況下，經由未審核的自訂連接器路徑接觸你。受審核的目錄，是在 Meta 核可的條款下與客戶相會的方式。

真正的故事是時間點

這一週的順序是刻意安排的：先有觀眾，再上架櫃。

• 9 月 17 日——Muse for Mac 上線，把這個 Agent 從手機和網頁延伸到桌面，能在原生應用程式裡操作檔案、訊息、行事曆、備忘錄和郵件。
• 9 月 18 日上午——Business Insider 與 9to5Mac 報導 Muse 超越 ChatGPT，登上美國 App Store 免費 App 榜冠軍，在超過 13,000 則評論中拿到 4.9 星。
• 9 月 18 日晚間——開發者大門開啟。

從消費者上市到開發者平台推銷只隔十天，以任何平台的歷史標準都快得驚人——App Store 花了一年才開放第三方 App，Facebook 平台距離 Facebook 自己上線晚了三年。Meta 能壓縮這個週期是因為它有本錢：#1 排行榜位置讓開發者對「真的會有人用嗎？」這個問題有了具體、當下的答案，而不是假想中的未來用戶。

依照 Alexandr Wang 9 月 8 日的推文，首發連接器清單讀起來就像一般人的手機：Gmail、Google 行事曆、Outlook、Google 文件、Plaid、OpenTable、Spotify、Function Health、Withings、Tailscale、Peloton——再加上 Muse 獨占的 Instagram（含私訊）、Threads、Facebook（含 Marketplace）與 Messenger。值得注意的是，Zuckerberg 說 9 月 18 日「今天就有新連接器上線」，但在所有一手來源裡，這些連接器全都没有名字。

界面反轉：誰擁有選擇權的瞬間？

自 2008 年以來，所有 App 商店的運作方式都一樣：開發者打造用戶端，平台擁有貨架，使用者搜尋並安裝。Zuckerberg 的三句話把用戶端整個拿掉了。

在 Muse 模型下，企業保留自己的服務和 API。而 Agent——跑在 Meta 的電腦上、用 Meta 的瀏覽器、帶著 Meta 對「這個人真正想要什麼」的記憶——主動找上服務。使用者「只要開口」就能觸及一項服務。

誰擁有 Agent，誰就擁有選擇權發生的瞬間。這是每一家評估這個平台的企業都應該讀兩遍的一句話。它也解釋了編輯精選排名的存在：在 Agent 就是介面的世界裡，被 Agent 找得到就是新的 SEO，而 Meta 掌控著那個排名。

誠實的但書

這個推銷聽起來簡單得太令人起疑，因為「你帶 API 來」掩蓋了真正的工作量。一個為傳統 UI 設計的 API——特定的請求順序、分頁、表單輸入——不會因為「 technically 摸得到」就自動變得對 Agent 友善。一個好的連接器仍然需要設計：Agent 如何發現有哪些能力、如何處理模糊或缺少必要資訊的請求、如何管理需要使用者確認的副作用、以及如何把錯誤用對話方式呈現，而不是丟出原始的 HTTP 狀態碼。

還有一些 Meta 尚未回答的結構性問題：

• 安全審查：審核實際檢查什麼、有什麼機制阻止一個連接器被設計成權限過寬或惡意存取，都沒有細節。
• 單一廠商鎖定：與開放的跨 Agent 協定 MCP 不同，Muse 連接器只能觸及 Muse 的用戶。如果 Meta 日後改變條款、審核政策或分潤模式，開發者除了重寫別無退路。相較之下，一個 MCP 伺服器能在所有相容的 Agent 框架上運作。
• 未解的存取控制問題：Muse 的 Sentinel 安全架構在桌面上究竟保證什麼，本來就已被放大檢視；第三方連接器生態系又在此之上多加了一層。

對開發者的務實解讀是：Muse 連接器是 MCP 整合策略的加分項，不是替代品——為了觸及率值得做，但在第一批有正式文件的連接器展示出審核流程的實際樣貌之前，不值得把產品路線圖押上去。

接下來看什麼

未來幾週真正重要的訊號，不是 Meta 的官方說詞，而是第一波真實連接器的樣貌。如果早期連接器偏向行事曆、待辦、筆記類工具，Muse 被定位成個人助理擴充層；如果偏向商務與交易——訂位、購買、付款——Meta 就是在推更激進的「Agent 代你完成消費」願景。無論哪個方向，這個目錄和它的編輯排名，即將成為消費軟體界競爭最激烈的貨架。

Meta 花了十天證明 Muse 有觀眾。接下來的十天，將顯示開發者是否相信這批觀眾值得在 Meta 的條款上為其打造——而那些條款本身，至今仍未公開。