AI 代理可以記錄一次失敗的指令或關鍵需求，卻仍在之後重複犯同樣的錯。Meta 研究人員正提出第二個代理來解決這個問題：一個記憶教練，負責監控任務進度、維持結構化紀錄，並有選擇地提醒主要代理什麼才重要。

這項方法在一篇新的研究論文中被描述，並由 The Decoder 報導，目標是命令列環境中的長時間任務，以及使用工具的客服情境。Meta 報告的測試顯示，在兩個基準上最高提升 8.3 個百分點，但結果也指出了幾個尚未解決的問題，包括介入頻率、模型校準、營運成本，以及記憶系統應該擁有多少自主性。

一個可以選擇沉默的記憶代理

研究人員把這種底層失敗稱為「行為狀態衰減」（behavioral state decay）。當代理的任務歷史愈來愈長時，限制條件、診斷資訊與先前嘗試可能會被埋在上下文視窗裡。這些資訊在技術上也許仍然可用，但已無法可靠地影響下一個決策。

Meta 的系統把這個問題與傳統記憶儲存分開處理。未經修改的動作代理負責執行任務，而另一個獨立的記憶代理會在固定間隔檢視最近步驟。記憶代理更新一個結構化記憶庫，並決定下一次呼叫動作代理時，是否需要一個簡短提醒，或根本不需要提醒。

能夠保持沉默，是這項設計的核心。若每次都把整個記憶庫送回動作代理，可能會增加 token 使用、延遲與干擾。Meta 的系統反而把介入本身視為一個獨立決策。

記憶庫有三個組成部分。私有狀態欄位追蹤進度與未解風險，但不會顯示給動作代理。Knowledge Memory 儲存相對穩定的資訊，例如需求、檔案路徑與設定。Procedural Memory 則記錄動作與結果，包括失敗的命令、成功的修正，以及被拒絕的解釋。

記憶代理透過預先定義的工具呼叫來修改這些紀錄，而不是任意重寫整個記憶庫。之後，它可以透過產生有針對性的提醒，重新喚起已儲存的狀態。Meta 將這個模組描述為與既有代理與 harness 相容，而不是主模型的替代品，也不是通用的策略顧問。

報告中的基準測試顯示了什麼

這套系統在 Terminal-Bench 2.0 上進行評估，該基準測試真實命令列任務中的自主代理；也在 tau2-Bench 上評估，後者衡量航空、零售與電信情境中的對話式工具使用。

在報告的設定中，Claude Sonnet 4.5 擔任動作代理，Claude Opus 4.6 擔任記憶代理。合併系統首次嘗試就完成了 46% 的 Terminal-Bench 任務，對照組則是 38%。在 tau2-Bench 上，按任務加權的平均值從 55% 提升到 62%。

結果並不均勻。航空與零售的分數各自上升約 10 個百分點，而電信約提升 3 分。研究人員將這種差異解讀為：介入的價值取決於任務，而不是遵循某種通用提醒頻率。

即使將更強的 Opus 4.6 模型用作動作代理，報告中的增益仍然存在，雖然較小：Terminal-Bench 提升 2.4 個百分點，tau2-Bench 提升 2.5 個百分點。這代表記憶層不只是補強較弱的主模型而已。

這些是 Meta 作者報告的研究結果，並非獨立驗證，也不是生產環境採用的證據。論文也指出，記憶代理有時會把推測性推論當成比實際更確定的事情。因此，剩下的失敗通常與校準有關，而不只是相關資訊是否已經被儲存。

為什麼選擇性回想對開發者很重要

對 AI 開發者來說，這個提案處理的是代理工作流程中的一個實際弱點：任務歷史不等於可靠的任務狀態。更長的上下文雖然能保留更多文字，卻無法保證模型在後續決策與先前警告衝突時會使用到那個警告。

這種區別對編碼代理、支援自動化，以及其他反覆呼叫工具的系統都很重要。失敗的 shell 指令應該影響下一次嘗試。已驗證的客戶紀錄應該比沒有根據的說法更重要。即使代理已把注意力轉到除錯或其他子任務，硬性要求也應持續生效。

Meta 的消融測試支持這種較窄的解讀。若每一步都把完整記憶庫提供給動作代理，表現會比選擇性提醒更差。移除「保持沉默」的選項，也會讓不同領域的結果更不一致。沒有持久記憶庫的顧問式系統在某些領域有幫助，但在其他領域反而有害。

在報告的比較中，這個設計也勝過 Mem0。根據研究描述，這項差異不僅限於檢索品質。Meta 的記憶代理會決定一個已儲存狀態是否應進入代理迴圈，以及該如何把它表述成提醒。

這可能讓這種架構在「可靠性比最大對話回憶更重要」的場景中特別有用。但它也會增加另一個模型呼叫、另一個延遲來源，以及另一個可能因錯誤判斷而影響工作流程的環節。團隊需要衡量提醒的成本，與重複動作、失敗工具呼叫和人工復原的成本。

訓練與部署問題仍未解決

主要版本不需要特別訓練的模型；它使用提示詞與受工具限制的更新。Meta 也測試了較小的 Qwen3.5-27B 模型作為記憶代理，同時保持更大的動作模型不變。在沒有額外訓練的情況下，較小模型會降低表現。監督式微調彌補了損失，之後的強化學習又改善了它何時應回想儲存狀態的決策。

這個結果使「記憶可以像外掛一樣簡單加入」的想法變得更複雜。以提示詞驅動的記憶層，對能力夠強的模型可能可行，但較低成本的部署可能需要針對任務的訓練，才能可靠地做出介入決策。系統固定的檢視排程也是另一項營運限制：未來版本或許會在需要時才呼叫記憶，而不是依預定間隔檢查。

Meta 也指出一些尚未定案的選擇，例如：逐字紀錄與更抽象的任務摘要哪個更好，以及記憶代理與動作代理是否應該一起訓練。這些決定會影響可稽核性、跨模型移植性，以及診斷代理為何採納或忽略某個記憶的能力。

接下來要觀察什麼

最重要的後續工作，是在更多代理任務上進行獨立測試。現有證據來自兩個基準與一項研究評估，因此目前還不清楚這種方法在軟體工程、企業營運，或長時間瀏覽器工作流程中的可轉移性有多一致。

開發者也應該關注成本與延遲，而不只是任務成功率。若一個記憶教練能提升完成率，卻增加頻繁的模型呼叫，那對昂貴失敗的場景很有吸引力，但對高吞吐量自動化可能不切實際。

其他值得注意的訊號包括：改成自適應呼叫而非固定間隔檢查、加強信心校準，以及與其他記憶系統的比較。若有開源實作或可重現的評估，將更容易判斷這些增益究竟來自雙代理結構、選擇性提醒策略、模型配對，還是任務特定提示詞。

Creati.ai 觀點

Meta 的提案把代理記憶視為一個控制問題，而不只是儲存問題。真正有價值的能力，是判斷何時先前狀態應該改變下一個動作，同時避免大量提醒淹沒主要代理、讓它失去效率。

這對正在打造可靠 AI 代理 的團隊來說是一個有用方向，但基準提升應被視為早期研究訊號。實際考驗將是：在計入額外推論成本、錯誤提醒，以及第二個代理介入政策難以稽核的情況後，選擇性記憶是否真的能減少真實營運失誤。