Meta 推出 Muse Spark 1.3：更會做長任務、少用 25% Token，實力與限制一次看
Muse Spark 1.3 強化長任務、程式開發與使用者協作，內部比較少用約 20% 工具呼叫與 25% Token，但尚未全面領先其他模型。
Meta 在 2026 年 9 月 2 日發布 Muse Spark 1.3，主打更長時間的 AI Agent 任務、程式開發、多工作流程協作，以及更可靠的指令遵循。官方內部比較顯示，新模型比 Muse Spark 1.2 少用約 20% 工具呼叫與 25% Token。
這次更新的重點不在聊天回答是否更華麗。Meta 正在修正 AI Agent 最常見的實務問題：任務跑久後忘記要求、卡住卻不求助、把失敗說成完成，以及在不該自行決定時直接採取行動。
我的判斷是中性偏多。Muse Spark 1.3 在程式開發與長上下文評測已進入第一梯隊，也補強了真實工作流程需要的協作行為。不過，它沒有全面領先 GPT-5.6 Sol 與 Claude Opus 5，部分數據又來自 Meta 內部評測。已經使用 Coding Agent 的開發者值得試用，一般團隊則應先用自己的專案與驗收標準小規模測試，不必只因跑分就全面更換工具。
Muse Spark 1.3 是什麼？
Muse Spark 1.3 是 Meta Superintelligence Labs 推出的 Agent 與程式開發模型，目前可在 Muse Code 和 Meta Model API 使用。Muse Code 是 Meta 的終端機 Coding Agent，能直接讀取程式庫、修改檔案、執行指令與驗證結果。Meta Model API 則讓開發者把模型接進自己的產品或工作流程。
AI Agent 和一般聊天機器人的差別，在於它不只提供答案，還會使用搜尋、終端機、瀏覽器或其他工具完成任務。這類工作可能持續數十分鐘甚至更久，也可能跨越多個檔案與軟體，因此模型能否維持方向、正確求助與確認權限，通常比單次回答的文筆更重要。
Meta 表示，Muse Spark 1.3 是根據 Muse Code 與 Meta Model API 上線後數月的使用經驗改進而來。先前已有的推理模式已開放，但需要更多運算的 max reasoning 在發布時仍在進行額外安全測試，並不是所有使用者一開始就能使用。
Muse Spark 1.3 更新了哪些能力？
長任務中比較不容易忘記原始要求
長時間 Agent 任務最容易出現的問題，是模型做到一半偏離目標。它可能漏掉檔案格式、字數、不得修改的範圍，或忘記最後還要測試與交付成品。
Meta 表示，Muse Spark 1.3 更能在同一個長對話中處理多條工作流程，也更可靠地保留複雜指令中的細節。當資料來源混亂或彼此衝突時，它會使用工具補足脈絡、修正計畫缺口，並記錄已經取得的資訊。
這項改進對大型程式修改、研究報告與跨檔案工作特別有用。不過，「比較能維持方向」不等於每次都會完成。團隊仍要提供明確的成功條件，例如測試必須全數通過、輸出檔案格式固定，或正式資料不能被修改，否則模型只會更有效率地追逐一個模糊目標。
遇到歧義與卡關時，會更主動找使用者
Muse Spark 1.3 會在 Prompt 有歧義時提出問題，遇到無法自行處理的阻礙時要求協助，並在可能造成重大影響的操作前先取得確認。它也能配合使用者偏好，在長任務中持續回報進度，或安靜地在背景工作。
Meta 官方電腦操作示範。官方頁面註明，這是由 Muse Spark 建立的 Agent prototype，並非真實產品。 影片來源：Meta AI Research 官方公告。
這些行為看起來不像新的模型能力，卻直接影響產品能否放心交給 Agent 執行。真正可用的 Agent 要知道哪些決定可以自己完成、哪些資訊缺口會改變結果，以及何時必須停下來詢問，並非從頭到尾保持沉默。
對產品經理與團隊主管來說，這也提醒了一件事：不要只評估模型最後有沒有交付檔案，還要檢查它是否在正確時間升級問題。若 Agent 在資料不足時仍自行猜測，或把工具錯誤包裝成成功，產出看起來再完整也不能直接採用。
更能分辨同一對話中的不同任務
使用者常在同一個對話中改需求、插入新任務，或回頭追問前面的工作。舊模型可能把新指令套到錯誤任務，甚至將已取消的要求重新帶回來。
Muse Spark 1.3 強化了多任務對應能力，會判斷新訊息是在修改先前需求、打斷目前工作，還是新增一條獨立任務。這對需要長時間協作的 Agent 很重要，因為真實工作很少照著最初計畫一路不變。
不過，模型判斷再好，也不應取代清楚的工作管理。涉及正式資料、付款、發布或刪除時，最好把任務名稱、可修改範圍與核准規則寫清楚，不能只靠模型從聊天脈絡猜測。
比較不會把失敗說成已完成
Meta 表示，新模型更能判斷自己知道什麼、不能做什麼，以及何時已經碰到阻礙，藉此減少虛構完成結果。這類「校準」能力，指的是模型的自信程度能否接近真實成功率，而不是每次都用保守語氣回答。
對使用者來說，最實際的差異是：如果 API 沒有回傳成功、檔案沒有真的建立，或網站操作被權限擋住，Agent 應該直接回報阻礙，不該只根據原本計畫宣稱任務完成。
但這仍是 Meta 對模型行為的官方描述，不代表幻覺已被消除。高風險流程應保留可讀回的結果，例如重新開啟檔案、查詢 API 狀態，或用測試確認變更，而不是把模型的完成訊息當成唯一證據。
少用 25% Token，代表成本一定更低嗎？
Meta 工程師在內部比較中發現，Muse Spark 1.3 相較 Muse Spark 1.2 少用約 20% 工具呼叫與 25% Token，也減少了沒有必要的來回，回答更精簡。Token 是模型處理文字時使用的基本計量單位，通常會影響 API 費用、延遲與長任務可容納的內容量。
這組數字值得注意，因為 Agent 的成本不只來自最後一段回答。每次搜尋、讀取檔案、呼叫工具與重新規劃，都可能產生新的模型輸入與輸出。若模型能用更少步驟完成同一項工作，長時間任務的總成本與等待時間都有機會下降。
不過，官方沒有在公告中提供完整樣本、任務分布與 API 價格換算，因此不能直接推論每個專案都會省下 25% 費用。工具本身可能另外計價，使用 max reasoning 也可能增加運算量。比較可靠的做法，是用固定任務記錄成功率、總 Token、工具呼叫次數與完成時間，再決定是否真的更省。
Muse Spark 1.3 跑分如何？
Meta 公布的評測顯示，Muse Spark 1.3 最明顯的優勢在長上下文與程式開發，但它不是每一項都排名第一。
| 評測 | Muse Spark 1.3 | Muse Spark 1.2 | GPT-5.6 Sol | Claude Opus 5 | 怎麼看 |
|---|---|---|---|---|---|
| GDPVal-AA v2 | 1,754 | 1,615 | 1,710 | 1,824 | 真實專業工作，Opus 5 領先 |
| OSWorld 2.0 | 66.9 | 47.6 | 62.7 | 68.3 | 電腦操作明顯進步，但仍略低於 Opus 5 |
| DeepSearchQA | 89.4 | 85.9 | 93.0 | 90.4 | 網路研究由 GPT-5.6 Sol 領先 |
| AutomationBench | 49.4 | 38.2 | 46.7 | 50.3 | 商業流程自動化接近第一名 |
| MRCR 512K–1M | 98.1 | 55.5 | 73.8 | 未提供 | 百萬 Token 區間的長文資訊擷取領先 |
| DeepSWE v1.1 | 75.4 | 55.0 | 73.0 | 74.0 | 長時間軟體工程任務排名第一 |
| SWE-Atlas Codebase QnA | 59.4 | 46.2 | 53.5 | 52.7 | 大型程式庫理解排名第一 |
| Terminal-Bench 2.1 | 88.8 | 82.9 | 88.8 | 86.7 | 終端機任務與 GPT-5.6 Sol 並列 |
這張表最合理的結論，是 Muse Spark 1.3 已經成為強勢的 Coding Agent 模型，但無法證明 Meta 已全面超越 OpenAI 與 Anthropic。它在 DeepSWE v1.1 取得 75.4，高於 GPT-5.6 Sol 的 73.0 與 Opus 5 的 74.0。在 Terminal-Bench 2.1，它則以 88.8 與 GPT-5.6 Sol 並列。
長上下文的進步更大。在 512K 到 1M Token 的 MRCR v2 資訊擷取測試中，Muse Spark 1.3 得到 98.1，Muse Spark 1.2 為 55.5，GPT-5.6 Sol 為 73.8。這代表模型在很長的對話或文件中尋找指定資訊的能力顯著提升，和 Meta 強調長任務、多工作流程的產品方向一致。
反過來看，Claude Opus 5 在 GDPVal-AA v2、JobBench、OSWorld 2.0 與 AutomationBench 仍然領先，GPT-5.6 Sol 則在 DeepSearchQA 與 Meta 的內部指令遵循指標較高。若工作重點是專業文件、電腦操作或深度搜尋，只看 Muse Spark 1.3 的 coding 成績就換模型，判斷會過度簡化。
為什麼這些跑分不能直接當成模型排名？
Meta 的評測方法文件說明，Muse Spark 1.3、GPT-5.6 Sol 與 Claude Opus 5 使用 max reasoning，Muse Spark 1.2 使用 xhigh。這表示 1.3 與 1.2 的差距不全是版本更新，也可能包含推理強度不同帶來的影響。
部分程式評測使用指定的 Agent 產品或固定執行框架，因此分數可能同時反映模型、工具、系統 Prompt 與操作流程。Meta 也承認，第三方模型的設定只是盡力對齊，未必反映它們在原生產品中的最佳表現。
此外，指令遵循使用 Meta 內部綜合指標，外部無法完整重現。OSWorld 2.0 對 Muse Spark 1.2 採用的測試版本也和其他模型不同。這些數據適合用來找出值得實測的候選模型，不適合直接變成「誰是世界第一」的結論。
Muse Spark 1.3 可以在哪裡使用？
Muse Spark 1.3 已在 Muse Code 與 Meta Model API 推出。前者適合希望在終端機中直接處理程式專案的開發者，後者適合要把模型放進自有產品、內部系統或 Agent 工作流的團隊。
Meta 在發布時表示，max reasoning 會在額外安全測試完成後提供。更大的 Muse 模型與 Muse Spark 開放權重版本也被列入後續規劃，但官方沒有公布確切版本與推出日期。開放權重代表使用者可下載模型參數並自行部署。因此，現階段不能把 Muse Spark 1.3 寫成已經可以下載到本機的開放權重模型。
如果你的需求是離線執行、資料不離開裝置或自行微調，應該另外評估 Meta 已開放 Apache 2.0 權重的 Muse Glimmer。Muse Glimmer 是針對本機常駐 Agent 設計的 30B 模型，和這次透過 Muse Code、Meta Model API 使用的 Muse Spark 1.3 不是同一個產品。
哪些人值得試 Muse Spark 1.3？
Muse Spark 1.3 最適合三類使用者。第一類是已經在使用 Claude Code、Codex 或其他終端機 Agent，希望比較大型程式修改成功率的開發者。第二類是需要模型閱讀大量文件、保留長對話細節的研究與知識工作者。第三類是想建立多步驟 Agent 產品，會在意工具呼叫成本、卡關回報與高風險操作確認的產品團隊。
如果只是偶爾問程式問題，沒有讓模型直接操作工具，這次更新的主要價值未必明顯。需要本機離線部署的人也不該因為 Meta 提到「open weights」就立即投入，因為 Muse Spark 1.3 的開放權重仍是未來規劃。
團隊導入時，我會建議先建立 20 到 50 個自己的代表任務，至少記錄四項結果：是否真的完成、人工修正時間、總 Token 與工具呼叫數，以及是否出現越權或錯誤完成宣告。這比只比較公開跑分更接近實際維護成本，也能找出哪一種工作真的適合交給 Agent。
Muse Spark 1.3 常見問題
Muse Spark 1.3 是開源模型嗎？
不是。Meta 已表示未來會推出 Muse Spark 開放權重版本，但沒有說明是否就是 Muse Spark 1.3。這次發布主要透過 Muse Code 與 Meta Model API 提供。若需要已經能下載到本機的 Meta Agent 模型，可以另外了解 Muse Glimmer，兩者不是同一款模型。
Muse Spark 1.3 可以取代 Claude Code 或 Codex 嗎？
它已經值得列入比較，但不代表所有專案都應更換。Muse Spark 1.3 在多項 coding 與長上下文評測領先，Claude Opus 5 與 GPT-5.6 Sol 則在部分專業工作、電腦操作、搜尋或指令遵循評測更高。最實際的做法，是用同一組專案任務測試三者的成功率、修改品質、成本與人工介入時間。
少用 25% Token，API 費用就會少 25% 嗎？
不一定。25% 是 Meta 工程師比較 Muse Spark 1.3 與 1.2 時得到的內部結果，不是所有工作都保證達成。實際費用還會受到輸入長度、推理模式、工具成本、重試次數與 API 定價影響。
Muse Spark 1.3 的 max reasoning 已經開放嗎？
Meta 在 2026 年 9 月 2 日公告時表示，既有推理模式已開始提供，max reasoning 則要等額外安全測試完成後推出。不同帳號與地區的實際開放狀態，仍應以 Meta Model API 或 Muse Code 介面為準。
結論：Meta 這次真正補強的是 Agent 工作紀律
Muse Spark 1.3 最值得關注的，並非又多一個 coding 跑分第一。Meta 把長任務的工作紀律放進模型更新：記住複雜要求、分辨多條任務、在卡關時求助、重大操作前確認，並減少把失敗說成成功。
從公開數據看，我對它在 Coding Agent 與長上下文工作上的評價是中性偏多。DeepSWE、SWE-Atlas Codebase QnA、Terminal-Bench 與 MRCR 的成績，足以支持開發者投入時間測試。不過，專業工作、搜尋與指令遵循仍沒有全面領先，官方內部比較也需要外部實測補強。
因此，最實際的行動是先挑選一小組可驗證的長任務，讓 Muse Spark 1.3 與目前使用的 Agent 同場比較，不必立即全面遷移。若它能穩定減少人工介入、工具呼叫與錯誤完成宣告，再逐步擴大使用範圍，會比追逐單一排行榜更符合真實產品需求。
