摘要： Meta 於 2026 年 7 月 9 日發表 Muse Spark 1.1，並讓 Meta Model API 進入公開預覽。官方稱這款代理導向多模態模型能管理 100 萬 token 上下文、泛化到新工具與 MCP server，並編排平行子代理。安全結論屬官方自評，API 也未公布定價、速率限制與資料處理條款，導入前應以內部流程小規模對照。
接模型這一年來，真正卡住多數團隊的通常不是模型不夠聰明，而是工具層的架構撐不住長時間流程。Meta 選在 2026 年 7 月 9 日一口氣做了兩件事：發表 Muse Spark 1.1，並讓 Meta Model API 進入公開預覽。這個時間點，等於把工具層的問題直接搬上產品架構的檯面。
這次發布的具體內容
Meta AI 的發布說明寫得很清楚：Muse Spark 1.1 出自 Meta Superintelligence Labs，是一款多模態推理模型，任務定位放在 agentic 場景，官方稱它在工具使用、電腦操作、coding 與多模態理解上都有明顯進步。上線方式分兩路——一般使用者在 Meta AI app 與 meta.ai 可切到 Thinking 模式取用；開發者則透過全新的 Meta Model API 公開預覽來接。
值得留意的是，開發者首次能透過這個 API 動手建東西。發布說明引用了 Replit 執行長 Amjad Masad 的評語，他形容這個模型具備百萬 token 上下文、多模態支援、附引用的內建搜尋、結構化輸出與平行工具呼叫，而且包裝成 OpenAI 相容的形式。
對建構者的實際差異：上下文管理與多代理
官方敘述中最該讓產品團隊停下來的，是模型被訓練成會主動管理自己的上下文視窗。發布說明指出 Muse Spark 1.1 能管理 100 萬 token 的上下文，它會記住先前做過的動作、把較早工作裡的資訊調回來，並在壓縮過程中保住後續工作需要的關鍵步驟。
這表面上是模型能力，骨子裡卻是一道架構選擇題。模型自己處理上下文壓縮，團隊就不必另外在應用層刻一套摘要與截斷邏輯；但另一面是，「哪些資訊會被留下」這件事，控制權有一部分已經交到模型手上。
多代理方面，發布說明說這個模型被訓練來編排多代理系統，目標是壓低端到端延遲。它擔任主代理時負責收集上下文、規劃，再把執行分派給平行子代理；換到子代理的位置，它會守住自己的職責範圍，也知道什麼時候該把問題升級回主代理。此外官方也聲稱它能 zero-shot 泛化到新的原生工具、MCP server 與自訂 skill。
假如你的產品已經在用 MCP 或自己養一套工具層，這就意味著工具介面的設計品質會直接牽動成敗。工具描述寫得不清楚、權限邊界畫得含糊，模型再擅長規劃也補不回來。這個思路和我們之前談過的 OpenRouter Shell 工具如何改變代理的執行邊界 指向同一個問題：代理碰得到什麼、在哪裡執行，對產品能否上線的影響，遠比模型跑分來得大。
電腦操作與 coding：什麼時候該寫腳本
在電腦操作方面，發布說明給出的是一個具體的設計判斷：模型不會對每一次桌面點擊都逐步推理，而是先判斷這件事該自動化、還是該直接操作介面——自動化更快就寫腳本，直接互動更單純就直接點，並且在每個步驟產生一批批次動作。
Coding 方面，官方說在大型且複雜的程式庫上處理真實任務有大幅改善，包括診斷並修掉複雜 bug、在企業級系統裡實作新功能、執行大規模程式碼遷移，也支援 planning mode、goal conditioning、子代理委派與上下文壓縮這些常見的 agentic coding 設定。發布說明裡的示範場景是：在 OpenCode 中建一個聊天 web app，靠自動截圖抓出使用者看得見的失敗，再往回追到對應程式碼修正並驗證。
安全與可用性：先看限制
Meta 表示，部署前已依照 Advanced AI Scaling Framework 做過安全評估，在 Chemical & Biological、Cybersecurity、Loss of Control 這三類前沿風險上都落在安全範圍內；同時聲稱對直接越獄、來自不可信資料的間接攻擊、prompt injection 以及開發者提示攻擊都有較強抵抗，幻覺率與諂媚傾向也一併降低。這些都是官方自評，完整內容收在 Muse Spark 1.1 Evaluation Report 裡，第三方驗證還得再等。
回到實務面，Meta Model API 目前仍是公開預覽，發布說明並沒有交代定價、速率限制與資料處理條款，而這幾項對成本與合規決策的份量並不輕。假如你正在評估要不要導入，比較合理的起手式，是挑一個內部工具流程做小規模對照測試，重點盯兩件事：模型自行壓縮上下文之後，關鍵步驟還在不在；以及工具呼叫失敗時，它是會正確升級，還是硬撐下去。