Muse Wonder 建模大翻車，亞歷山大·王辯護遭馬斯克無情補刀

官方承認 3D 短板，跨模型測試 Harness 不同。作者丨鄭佳美 編輯丨岑 峰 Meta 剛發佈的 Muse Wonder，沒想到因為一盞熔岩燈，在開發者社區引發了一場關於 AI 模型跑分的爭論。10 月 12 日，Meta 推出 Muse Wonder 和 Muse Wonder Full，主打 Coding Agent、工具調用和長任務執行能力。官方公佈的成績相當亮眼，Wonder Full 在 SWE-Marathon 上拿到 57.5 分，DeepSWE 1.1 達到 79.0 分，已經能夠與同期的前沿模型展開競爭。

然而，開發者社區 BridgeMind 隨後安排了一項 3D 編程測試，要求 Muse Wonder 製作一盞具有透明玻璃外殼、動態熔岩和光照效果的熔岩燈。結果模型只生成了一個紅色圓柱體。BridgeMind 隨即質疑 Muse Wonder 存在嚴重的 Benchmaxxing，也就是針對 Benchmark 進行大量優化，成績看著漂亮，碰上陌生任務卻露了怯。連馬斯克也忍不住下場，在相關帖子下意味深長地回了一句 Hmm。短短一個詞，雖然沒有明確表態，卻讓這場圍繞 Meta 新模型的刷分爭議又添了幾分戲劇性。

Meta 首席 AI 官 Alexandr Wang 很快回應，團隊確實沒有針對 3D 演示遊戲進行顯式訓練，事後看來或許應該補充相關訓練，但他仍然希望開發者實際體驗 Muse Wonder 的 Coding 能力。這場爭論有一個重要前提：熔岩燈測試針對的是普通版 Muse Wonder，而 Meta 公佈的部分突出成績來自 Wonder Full，兩者存在能力差異。同時，Meta 官方 Model Card 已經明確承認，視覺與空間推理，尤其是 3D 任務，屬於 Muse Wonder 的已知短板。

但高分模型在陌生任務中遭遇如此明顯的失敗，依然讓人好奇：當前大模型的訓練方法究竟在強化哪些能力，Agent Benchmark 又能在多大程度上反映模型的實際水平？01獎勵機制，決定模型擅長解決什麼問題Muse Wonder 的表現，與當前大模型越來越依賴 Post-training 提升任務能力的技術路線有關。在 Pre-training 階段，模型通過大規模數據學習語言、代碼、空間關係和其他通用知識。進入 Post-training 後，訓練會進一步塑造模型的行為策略，尤其是通過強化學習，讓它在特定任務環境中形成更穩定的執行能力。Coding Agent 很適合這類訓練。

例如，給模型一個存在 Bug 的代碼倉庫，要求它定位問題、修改文件並運行測試。整個過程可以通過編譯結果、單元測試和功能檢查獲得相對明確的反饋。強化學習系統據此判斷哪些操作有效，持續強化能夠提高任務成功率的行為。訓練規模擴大後，模型逐漸學會一套複雜的軟件工程策略，包括如何縮小搜索範圍、選擇工具、處理報錯，以及在多輪修改中維護任務狀態。Meta 在官方技術文章中提到，Muse Wonder 接受了多樣化長任務訓練，並引入 Active Focus，使模型能夠在遭遇阻礙後嘗試其他方案、恢復執行並繼續推進任務。但這類訓練依賴一個關鍵條件：環境必須能夠向模型提供有用的反饋。

熔岩燈恰好打破了傳統 Coding Agent 熟悉的反饋方式。從程序實現來看，熔岩燈涉及三維幾何、透明材質、光照計算和動態形變。如果使用 Three.js，模型需要構造玻璃燈罩，為內部熔岩生成不規則的幾何形態，再通過時間變量或噪聲函數驅動形狀變化。這些代碼即使能夠正常執行，畫面仍然可能完全錯誤。例如，透明材質的參數配置不當，玻璃就可能變成不透明的實體，熔岩形狀缺少連續變化機制，內部效果就可能退化為靜態色塊。編譯器和單元測試很難直接判斷這些視覺問題。這意味著，Agent 還需要具備一套視覺反饋機制，通過渲染截圖、識別畫面偏差，再把視覺問題轉換成代碼修改。

單純增加工具調用次數或延長推理時間，並不能替代這一環節。Muse Wonder 生成紅色圓柱體的具體原因，仍然需要完整執行軌跡才能確定。可能是模型沒有建立正確的空間結構，也可能是圖形工具使用不當，或者生成錯誤後缺少有效的視覺檢查。Alexandr Wang 承認沒有針對 3D 演示進行顯式訓練，至少說明這一任務沒有獲得與重點 Coding 場景相同的訓練投入。02Agent 的高分，已包含型之外的系統能力Muse Wonder 的爭議還有一層容易被忽略的問題：今天的 Agent Benchmark，已經無法簡單理解為給語言模型出題。

以 SWE-Marathon 為例，它考察的是持續性軟件工程任務。模型需要在代碼倉庫中執行多個操作，讀取文件、調用終端、修改代碼，並通過測試驗證結果。這類任務的完成率，除了依賴底層模型，還會受到 Harness 的直接影響。Harness 是圍繞模型構建的執行框架，負責組織工具接口、管理上下文、保存任務狀態，以及處理執行過程中的異常。例如，一個 Agent 正在修復複雜的軟件問題，連續運行測試後產生了數千行終端日誌。如果系統將全部日誌直接追加到上下文中，模型可能逐漸失去對原始需求和關鍵錯誤的把握。設計更完善的 Harness 可以自動提取重要報錯、壓縮無效信息，並維護當前修改進度。

當任務執行時間延長，這種上下文管理能力會直接影響系統能否持續工作。錯誤恢復機制同樣如此。假設 Agent 已經修改了多個文件，卻在後續測試中發現早期修改存在問題。如果執行系統能夠保留檢查點、定位引入錯誤的步驟，並局部回滾，就有機會避免重新執行整條任務鏈。此外，推理預算也會影響成績。允許 Agent 使用更多 Token、執行更多工具調用，或者嘗試多個候選方案，相當於增加了搜索空間和糾錯機會，代價則是更高的運行成本。Meta 官方 Model Card 對此有明確說明。在 SWE-Marathon 評測中，GPT-6 Astra 和 Claude Fable 5.

1 分別使用 Codex 與 Claude Code 執行系統，因此這一項目並非統一 Harness 條件下的受控比較。Muse Wonder Full 的 57.5 分還使用了 xhigh 推理檔位。這些配置差異不會自動使成績失效，卻會影響成績的解釋方式。如果要比較基礎模型的推理與規劃能力，就需要儘可能統一工具環境、Harness 和推理預算。但如果比較的是能夠投入生產的 Coding Agent 產品，完整執行系統的表現本身就具有工程價值。對於實際開發者而言，Agent 能否穩定處理長任務，往往比單輪生成代碼的質量更有意義。

問題在於，當各種系統配置被壓縮成排行榜上的一個分數時，外部很難判斷成績增長究竟來自模型推理能力、執行框架優化，還是更充足的計算資源。這要求 Agent 評測提供更詳細的執行信息，包括任務完成率、Token 消耗、工具調用次數、運行時間以及失敗恢復情況，否則相近的 Benchmark 成績，可能對應完全不同的工程體驗。03Meta 自己也在研究 Benchmaxxin有意思的是，Muse Wonder 官方技術文章專門設置了 Capabilities That Generalize 章節，討論的恰好是 Benchmaxxing 背後的問題。

Meta 指出，兩個模型即使在常見 Benchmark 中取得相似成績，處理陌生任務的能力仍然可能存在較大差距。為研究這一現象，團隊將測試任務劃分為兩類：一類是 Post-training 重點優化的 In-distribution 任務，另一類是沒有進行針對性優化的 Out-of-distribution 任務。研究人員進一步比較 Muse Spark 1.3 與 Muse Wonder Full，在不同推理預算下的表現變化。按照 Meta 公佈的實驗結果，Wonder Full 在陌生任務上的表現，相比前代模型對應的能力變化趨勢有所提升。

Meta 認為，這與更強的基礎模型有關，基礎能力的改善使 Post-training 收益能夠更有效地遷移到其他任務。但這裡存在一個評測設計問題：陌生任務究竟陌生到什麼程度？對於長期訓練代碼修復的 Agent，換一個未曾接觸過的代碼倉庫，仍然屬於相近的軟件工程任務。如果進一步更換編程框架、引入陌生 API，模型就需要重新理解工具環境。而製作 3D 熔岩燈，除了軟件開發，還引入了空間建模、材質渲染和視覺質量判斷。它對能力組合提出了更大的變化。因此，分佈外泛化不能只用一個綜合平均分來描述。不同任務之間的距離、需要補充的知識，以及評價結果的方法，均會影響模型表現。

判斷模型是否存在嚴重的 Benchmark 過擬合，也需要系統性實驗。單個熔岩燈失敗只能說明模型沒有完成當前任務，無法直接證明它針對公開題庫進行了過度優化。更合理的方法，是在相同執行條件下逐步改變任務分佈。例如，先測試模型能否修復陌生倉庫中的 Bug，再要求它使用未見過的 API 構建程序，隨後加入缺少明確測試腳本的視覺開發任務。這樣既可以觀察模型在軟件工程內部的能力遷移，也能檢查它跨越任務類型時出現的性能變化。評測還可以進一步改變環境約束，例如臨時替換工具接口、引入新的錯誤信息，或者要求 Agent 自行設計驗證程序。

這些設置能夠檢驗模型面對陌生條件時，是否具備閱讀文檔、建立方案、驗證假設和修正錯誤的能力。對於熔岩燈這樣的任務，除了檢查最終畫面，還應該記錄模型是否主動使用截圖工具、能否識別材質與幾何錯誤，以及在獲得反饋後是否能夠作出有效修改。相比單純統計成功率，這類執行軌跡更有助於判斷 Agent 的能力缺口，也能夠區分知識不足、工具錯誤和反饋機制失效等不同原因。隨著公開 Benchmark 越來越成熟，模型研發會持續利用已知任務結構改進訓練方法。動態任務、隱藏測試以及更完整的執行過程評估，將成為補充固定排行榜的重要手段。

04高分之外，還需要看清能力邊界Muse Wonder 的熔岩燈失敗，無法抹去它在軟件工程任務上的進步，也不足以證明 Meta 存在嚴重刷分行為。但開發者確實需要重新理解今天的 Agent 成績。當 Post-training、工具系統和推理預算共同參與能力提升，排行榜上的高分，反映的是一套特定條件下的任務完成表現。它對模型選型具有參考意義，但使用場景越複雜，單一分數能夠提供的信息就越有限。未來的 Agent 研發仍然會繼續強化 Coding、工具調用和長任務執行，但當模型逐漸能夠承擔獨立的軟件工程工作時，它需要處理的問題會不斷超出既有訓練任務的範圍。

屆時，能否識別陌生環境中的問題、自行建立有效的驗證方法，並通過反饋持續修正執行策略，將直接影響 Agent 可以承擔多大範圍的實際工作。一盞熔岩燈沒有給出 Muse Wonder 的完整能力答案，卻提供了一個具體的提醒：模型在熟悉任務中取得的成績，與它在未知環境中能夠獨立完成的工作，仍然需要分別檢驗。上車，帶你看遍全球 AI 頂會精華可獨家暢覽：專家演講PPT大會報告全文熱門論文解讀學術新星訪談掃描上方二維碼或點擊「閱讀原文」關注專區。