Anthropic 於 2026 年 11 月在官方研究部落格發表代理記憶框架，把 Claude 的記憶拆成四個元件：工作階段中的標記、記憶筆記、離線整理與主動注入。研究團隊以 CL-Bench 資料庫任務、寶可夢紅版與三十五萬份內部文件測試，發現記憶檔案的數量與品質同樣影響表現，而離線整理可以修正錯誤筆記。
這篇研究的作者為 Lance Martin，切入角度是人類睡眠期間的海馬迴重播。人在清醒時快速記錄經歷，真正沉澱成長期知識的過程多數發生在離線時段。研究團隊把這個類比搬到代理身上，用「dreaming」描述模型在互動空檔回頭整理日誌、修正錯誤、重寫筆記的動作。
Claude 的代理記憶是什麼？
代理記憶指 Claude 從互動與任務獲得、跨工作階段保留的知識，形式是可再讀取的上下文。它與調整權重、單次對話內的學習、壓縮舊對話都不同。
官方定義寫得相當收窄。凡是改動權重、在單一對話內臨時學會的內容、以及為了騰出上下文空間而寫的摘要，都不算在這套框架裡。剩下真正被稱為記憶的，是模型主動寫進資料夾、檔案或資料庫，之後另一個工作階段還讀得到的那部分。
這個區分在工程上有實際意義。權重與對話上下文會隨工作階段結束而消失，記憶則需要模型自己判斷什麼值得留下。研究團隊因此把問題拆成兩半：一是當下如何辨認重要性，二是事後如何整理。
所謂 dreaming 是什麼機制？
dreaming 指模型在任務空檔回頭閱讀工作日誌，核對筆記與原始紀錄的落差，修正錯誤、合併重複內容並重建易檢索的表示法，屬背景程序。
研究團隊引用 Letta 與柏克萊提出的睡眠期運算概念，把閒置算力用於重整既有上下文。實作上，Claude 會比對記憶筆記與當時的工作紀錄，找出寫錯或已過期的條目並改寫。
這一點回應了記憶系統最根本的兩難。模型在寫筆記的當下，只看得到眼前這一段對話，無法預知未來需要什麼。dreaming 把判斷時點往後推，讓模型在掌握更多結果之後再回頭檢查。
寶可夢實驗顯示記憶策略有什麼差別？
Sonnet 3.7 在約一萬步時寫下四百一十三個記憶檔案、分散於兩百二十五個資料夾，只取得一枚徽章。Fable 5 只寫九個檔案加一份總覽，取得四枚徽章。
差別在於兩個模型對「什麼值得記」的判斷。Sonnet 3.7 假設所有遭遇都可能有用，於是為每場戰鬥、每件道具、每個角色各開一份檔案。這些紀錄在遊戲進行中快速過期，模型反而要花更多時間翻查舊資料，實際遊玩的步數被壓縮。
Fable 5 把記憶當成儀表板。它的總覽檔案存放當前目標、挑戰道館的預定計畫與使用記憶的規則，另外兩個資料夾分別記錄路線與戰鬥策略。曾有一次連續七顆球都抓不到鯉魚王，它寫下的規則是連續三顆失敗後改變投擲節奏，這條規則在後續回合直接生效。
記憶份量寫得越多越好嗎？
不是。研究團隊在 CL-Bench 測試中發現，對較強模型加固定規則反而削弱記憶增益。指定只記錄失敗時，Opus 5 與 Opus 4.7 的表現明顯回落。
測試方法是逐條加規則、逐條比對增益。當指令限定為只記錄失敗案例，兩個較強模型的記憶效益大幅縮水。研究團隊的解釋是，硬性規則把模型在當下觀察到的細微差異排除掉，而這些差異往往正是後續判斷的依據。
對較舊的模型，情況相反。Sonnet 4.6 經常不去讀記憶檔案，也不會驗證自己對錯誤原因的推測。研究團隊在提示中要求它先讀記憶再作答、並且明確測試推測，得分幾乎翻倍。Sonnet 5 未經提示也會主動讀取，十次之中有九次先查記憶。
wiki 形式的記憶能帶來多少提升？
研究團隊以三十五萬份內部文件建立 wiki，離線整理由兩輪擴至一百二十八輪後，二十五條問題的得分由百分之十三升至四十八，配合搜尋則升到六十一。
測試素材來自 Anthropic 於五月收購的軟體公司 Stainless。研究團隊讓多個代理在共享日誌上協作，逐輪新增、修改、刪除互相連結的 wiki 頁面，並核對頁面陳述與原始文件是否一致。單獨使用 wiki 答題時最高分為百分之四十八，配合搜尋工具則升至六十一。
wiki 的效益並非一致。在一組併購案的法律摘要任務中，需要跨多份文件整合的題目，用 wiki 得八十七分，只用搜尋得七十三分。若題目答案本來就藏在單一文件裡，wiki 沒有明顯優勢。研究團隊亦記錄了失敗案例：有一輪 wiki 長得比原始文件還大，等於沒有做任何抽象。
記憶階層為何需要保持精簡？
主動注入的記憶會進入每個工作階段，佔用權杖並影響遵循度。Claude Code 的自動記憶只載入 MEMORY.md 前兩百行，其餘留在下層待查。
官方文件提醒，指令檔越長，模型遵循的程度越低。dreaming 在這個環節的主要工作是把細節往下層移動，只留連結在頂層，讓模型知道哪裡找得到，而不是把所有內容一次塞進上下文。
這個設計也對應到成本。每次工作階段都載入的內容必須付費，錯誤的筆記一旦進入頂層，就會被帶進之後的每一次對話。研究團隊承認，注入本身不保證模型會照著做，因此頂層的內容需要持續修剪。
開發者可以怎麼開始實作？
先給模型一個可讀寫的記憶資料夾並說明用途，而非規定寫法。接著安排離線整理，最後只把關鍵條目提升到每次載入的頂層。
CL-Bench 的測試經驗是，只告知有記憶資料夾可用，就足以讓較新的模型建立有效的學習迴路。研究團隊建議把「何時該寫筆記」的判斷留給模型，因為預先設定的規則難以覆蓋任務的多樣性。
第二項工作是安排整理節奏。研究團隊提出幾種可調整的參數：多久跑一次整理、優先整理哪些容易被讀取的記憶、以及是否針對特定目標調整整理方向。這些選擇會直接影響算力支出。
出處連結有哪些？
本文資訊來自 Anthropic 官方研究部落格 2026 年 11 月的文章，作者 Lance Martin，數據出自 CL-Bench 1.0 與寶可夢實驗。
- 研究原文：The components of agent memory
- Anthropic 官方網站：anthropic.com
- 相關概念：sleep-time compute（Letta 與 UC Berkeley）
總結：這套記憶框架適合什麼團隊？
適合已把代理用於長流程任務、且需要跨工作階段延續脈絡的團隊。任務短、每次重來成本低的場景，額外維護記憶目錄與整理排程並不划算。
這篇研究的價值在於把記憶從模糊概念拆成可驗證的元件。標記、筆記、整理、注入各有對應的失敗模式，也各有可量測的指標。對正在自建代理的團隊而言，這是一份可以照著除錯的清單。
值得留意的是成本結構。dreaming 需要額外算力，wiki 需要維護，頂層注入需要持續修剪。研究團隊自己也留下未解問題，包括何時該寫記憶、以及如何讓記憶不過期。這些問題沒有標準答案，取決於任務變化速度與可接受的錯誤率。
