Meta 在 10 月 12 日 推出 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，即針對基準測試大量最佳化，成績好看但遇到陌生任務就露怯。
馬斯克也在相關帖子下回復了一個詞 Hmm，雖未明確表態，卻讓爭議更添戲劇性。Meta 首席 AI 官 Alexandr Wang 很快回應稱，團隊確實沒有針對 3D 演示遊戲進行顯式訓練，事後看來或許應補充相關訓練，但他仍希望開發者實際體驗 Muse Wonder 的 Coding 能力。
這場爭論有一個重要前提：熔岩燈測試針對的是普通版 Muse Wonder，而 Meta 公佈的部分突出成績來自 Wonder Full，兩者存在能力差異。同時，Meta 官方 Model Card 已明確承認，視覺與空間推理，尤其是 3D 任務，屬於 Muse Wonder 的已知短板。但高分模型在陌生任務中遭遇如此明顯的失敗，依然讓人追問：當前大模型的訓練方法究竟在強化哪些能力，Agent Benchmark 又能在多大程度上反映模型的實際水平？
獎勵機制決定模型擅長什麼
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 場景相同的訓練投入。
Agent 高分已包含模型之外的系統能力
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 成績可能對應完全不同的工程體驗。
Meta 自己也在研究 Benchmaxxing
有意思的是，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 越來越成熟，模型研發會持續利用已知任務結構改進訓練方法。動態任務、隱藏測試以及更完整的執行過程評估，將成為補充固定排行榜的重要手段。
高分之外，還需看清能力邊界
Muse Wonder 的熔岩燈失敗，無法抹去它在軟體工程任務上的進步，也不足以證明 Meta 存在嚴重刷分行為。但開發者確實需要重新理解今天的 Agent 成績。當 Post-training、工具系統和推理預算共同參與能力提升，排行榜上的高分反映的是一套特定條件下的任務完成表現。它對模型選型具有參考意義，但使用場景越複雜，單一分數能夠提供的資訊就越有限。
未來的 Agent 研發仍會繼續強化 Coding、工具呼叫和長任務執行，但當模型逐漸能夠承擔獨立的軟體工程工作時，它需要處理的問題會不斷超出既有訓練任務的範圍。屆時，能否識別陌生環境中的問題、自行建立有效的驗證方法，並通過反饋持續修正執行策略，將直接影響 Agent 可以承擔多大範圍的實際工作。一盞熔岩燈沒有給出 Muse Wonder 的完整能力答案，卻提供了一個具體的提醒：模型在熟悉任務中取得的成績，與它在未知環境中能夠獨立完成的工作，仍然需要分別檢驗。