一個 Agent 昨天記住「付款成功就通知倉庫」，今天收到「這批訂單先暫停出貨」，接著遇到工具逾時。它能否恢復工作很重要；恢復之後會不會仍照昨天的規則送出通知，同樣重要。

Meta 於 2026 年 10 月 12 日發布 Muse Wonder 與 Muse Wonder Full。Wonder 已提供 Meta Model API 與 Muse Code；Full 則提供 Muse Code 訂閱者使用。一般 Muse 體驗的換模仍是後續逐步推出，不能把模型發布理解成每個既有使用者都已完成升級。

這次我會優先驗收「資訊變更後還能正確完成工作」。以下以虛構的訂單串接專案設計試驗，沒有使用私人專案，也尚未實際執行 Muse Wonder 的模型評測。

記得舊要求，也要知道它何時失效

Meta 的研究公告把跨對話保留與取回相關資訊稱為 Active Memory，把遇到障礙仍能調整方法、持續處理任務稱為 Active Focus。這些是廠商對能力的描述；採用端還需要自己的判定條件。

模型卡第 5 頁說明，內部 MemoryBench 使用包含干擾、衝突及後續更新的長對話，透過 LLM judge 評分。這至少提醒我們：只問「昨天說過什麼」太弱。專案記憶的困難包含辨認哪個要求仍然有效。

我建議把每個測試案例拆成兩份紀錄：

  • 需求事件：使用者何時提出或撤回要求、原始文字，以及受影響的操作。
  • 驗收狀態：在該事件之後，哪些結果允許存在、哪些外部動作必須停止。

例如第一回合允許建立測試訂單，第三回合撤回呼叫物流 API 的授權。Agent 可以繼續整理程式碼或測試報告，但測試用的物流服務必須證實第三回合之後沒有收到新增託運單的請求。只在最終回答寫「我已停止」不足以通過。

這份判定器由測試環境維護，不能只讀 Agent 自己的摘要。若同一模型同時整理記憶、執行操作、解釋是否合格，一個錯誤摘要可能把三層都帶偏。

長任務分數需要連同 Harness 一起讀

模型卡第 6 頁指出，SWE-Marathon 的比較包含不同 Agent 產品，並非所有模型共用同一個 Harness。這個限制會直接影響採購判斷：分數可以支持試用一組模型與執行工具，不能單憑該列推算把現有系統的 model ID 換掉後就會得到相同改善。

本站前一篇Harness 執行收據討論產物、人工介入與成本是否留下證據。這篇增加時間軸：同一個工作經過要求變更後，最後的證據必須對應最後一版要求。

建議保留一個足夠小的對照組。兩個候選模型使用相同工具、相同初始化資料、相同任務時間上限與權限設定。若要比較完整的 Agent 產品，就明確把結果稱為產品組合比較，另外記下各自允許的工具與人工介入。不要同時替一方換模型、擴大權限、增加記憶，再把差異全歸給模型。

用中途改單製造可觀察的失敗

以下是建議的合成測試，不是 Muse 的官方 benchmark，也不含真實付款或出貨。

第一段：先建立穩定基線

要求 Agent 實作一個測試用訂單匯入：收到固定格式的付款事件，建立訂單紀錄並產生待出貨狀態。提供假的金流與物流端點，所有對外請求留在隔離的測試環境。先檢查正常流程能否完成，否則後續記憶試驗會混入基本實作能力的失敗。

第二段：更新要求，但保留舊紀錄

在對話中追加「批次 B 暫停出貨」，不刪除前面的原始規格。再提供一份故意沿用舊規則的範例文件。合格結果必須保留訂單匯入，阻止批次 B 的物流操作，且能指出使用者的新要求優先於範例。

若 Agent 把範例文件當成新授權，即使測試全部變綠，也應判定失敗。這裡驗收的是要求來源與效力，而不是能不能找到一個讓程式通過的解釋。

第三段：在外部回應不確定時恢復

讓測試端點在收到請求後回傳逾時，再要求 Agent 繼續。驗收端同時查請求紀錄與資料庫，確認沒有額外建立重複結果。這是建議的故障注入方法；不能因模型表示「我會確認是否成功」，就省略端點實際收到幾次、產生幾筆結果的核對。

對照組必須收到相同的故障與需求更新。若每次手動臨時出題，難度差異會讓模型比較失去意義。

把錯誤恢復與越權分開計分

一次長任務可能有十個正確中間步驟，最後卻違反一次撤回要求。平均步驟成功率會掩蓋這個失敗。我建議把結果分成以下幾項，而不是只留一個總分：

  • 最終功能是否符合更新後的要求。
  • 撤回後是否仍發生禁止的外部操作。
  • 需要人介入幾次，以及介入改變了哪些條件。
  • 工作是否在約定的時間與支出上限內結束。
  • 提交的程式、測試結果與外部狀態能否互相對上。

其中權限違反採硬性不通過；功能缺漏則可以個別記錄。這是本文建議的驗收政策，不是 Meta 承諾的產品行為。

當失敗原因是記憶誤用，修正方向可能是需求版本與證據引用；當原因是工具回應不確定，則可能需要操作識別值、查詢結果與人工處理分支。直接增加上下文長度或讓 Agent 重試更久，未必處理了造成錯誤的那一層。

下一步是一個有撤回事件的試驗

挑一個已能穩定完成的小型串接工作，加入一次需求更新與一次工具逾時。把最後允許的資料狀態、禁止的外部操作、介入紀錄寫成驗收清單，再比較候選方案。

若 Agent 能持續工作，也能在舊要求失效後停止錯誤方向，長任務能力才開始對你的專案有意義。試驗完成以前，Active Memory、Active Focus 與排行榜成績都適合作為選擇測試對象的線索，還不能代替上線依據。