Anthropic 拆解代理記憶：Dreaming 如何修正筆記，為什麼不是記愈多愈好？
代理記憶不是存愈多愈好。Anthropic 新工程文拆解筆記、知識頁與 Dreaming，從 25 題評估、合約事實保存與錯誤修正，看懂長任務的收益與維護成本。
代理記憶最實際的用途，是讓 AI 隔天接著工作時，能找到昨天試過什麼、哪個規則已經證實，而非再讀一次所有訊息。
但把每一步都寫進記憶，可能讓代理花更多時間整理舊資料，甚至把早已失效的資訊當成事實。
Anthropic 在 2026 年 11 月 6 日的新工程文拆解代理記憶，說明如何讓 Claude 回看紀錄、修正筆記，並把分散資料整理成互相連結的知識頁。
這種背景整理稱為 dreaming。它使用模型運算維護外部文字，不代表模型真的睡覺，也不是修改模型權重。
我會把這篇視為設計長期工作代理的工程證據，適合已有紀錄與跨任務需求的團隊；單次問答未必需要額外建整座知識庫。
要判斷值得記什麼，先得分清原始紀錄、整理過的筆記與每次開工自動讀入的內容。
代理記憶保存什麼，與聊天上下文有何不同？
跨工作階段能再次讀取的經驗，才是這篇研究所談的代理記憶。
例如代理昨天試出一個資料庫查詢規則，今天能從檔案重新讀到，就有跨階段記憶。只把同一串聊天拉長，仍是在目前的對話裡工作，保存方式和負擔不同。
Anthropic 的新工程文把原始對話、即時筆記、知識頁與開工自動讀入的內容，放進一個記憶層級。不同層負責不同問題，所以沒有要求所有內容都擠進同一份摘要。
原始對話像工作紀錄，保留當時看過什麼、做過什麼。筆記則挑出值得再用的規則與經驗，因此它較容易閱讀，也可能因為省略脈絡而寫錯。
知識頁會把同一主題分散的資料連起來。開工時自動注入的內容，則像一份入口索引，先讓代理知道哪些事情已經有人整理過，再決定是否向下查找。
這個分工也說明記憶如何影響工作。系統可以保存一百份檔案，卻只先讀其中的索引，因此「存了多少」與「每次塞進多少」是不同的成本。
官方在這裡排除修改模型權重。權重是訓練時形成的內部參數，而這篇談的是代理能在後續工作重新讀取的文字，改善來自取用與整理方式。
保存下來只解決資料還在，下一步仍要決定哪些經驗值得保留。
為什麼記得更多，反而可能妨礙代理工作？
可隨時從環境讀到的狀態，不一定需要再複製成長期筆記。
官方以《寶可夢》遊戲觀察模型會挑什麼來記。角色位置、金錢與地圖狀態會持續改變，而且畫面每回合都能提供，所以把這些資料反覆存檔，容易很快過期。
相較之下，走某條路的策略、試過才知道的規則與目前計畫，未必能直接從畫面看出。若代理沒有寫下來，換工作階段之後就可能得重新摸索。
在各一次、約 1 萬個步驟的遊戲紀錄中，Sonnet 3.7 寫了413個記憶檔案，取得一個徽章。Fable 5 用較小的記憶集合，取得四個徽章。
兩次執行使用不同模型，無法只把進度差距歸因於檔案數量。這組觀察比較有用的地方，是看見大量記錄如何反過來占用遊戲時間。
其中一段，Sonnet 3.7 用17 個步驟建立6 個檔案、刪除9 個檔案，卻沒有在遊戲裡採取行動。當整理本身成了主要工作，更多筆記就未必代表更多進展。
另一個資料庫基準也顯示提示方式要看模型。只准記錄失敗，會削弱部分較強模型從記憶得到的收益，因為成功經驗與已驗證規則同樣可能有用。
資料減少之後，留下的規則是否正確，反而成為更重要的問題。
Dreaming 如何回查紀錄並修正記錯的規則？
背景整理的價值，是用原始紀錄檢驗筆記，而非把錯誤摘要寫得更漂亮。
遊戲裡曾出現一則錯誤筆記，把一棟建築放到山洞的錯誤一側。代理離開建築後，以為已經穿越山洞，沿著錯方向走，最後又回到先前的路線。
這則筆記看起來像一個已完成的結論，因此後續代理會沿用它。問題並非完全沒有記憶，而是保存下來的解釋與實際發生的事不一致。
研究團隊讓 Claude 在背景回看原始工作紀錄，對照這個位置說法。它找出錯誤並修改筆記，後續執行便重新進入山洞，最後抵達目標城市。
這是一個具體案例，無法直接換算成所有導航任務的成功率。不過它把修正路徑說得很清楚，整理者需要能回到當時的證據，才能知道該刪掉哪個錯誤假設。
資料庫評估提供另一種檢查條件。每題完成後會給正確答案，代理可以把猜測拿去測試，再把確認過的規則留下，因此學習迴圈有可核對的回饋。
圖中的 Opus 5 在資料庫任務裡，有記憶的平均獎勵為0.828，沒有記憶為0.564。平均獎勵是這套基準的評分值，仍要和單題回饋及模型條件一起理解。
較舊的 Sonnet 4.6 則從0.330升到0.364，改善幅度小得多。同樣提供記憶目錄，不代表模型就會主動讀取、驗證與改寫，因此工具存在與善用工具之間仍有差距。
若企業紀錄裡只有代理自己宣告成功，回看它不一定能得到同樣效果。把執行結果與原始來源一起保存，才讓後續整理有機會分辨完成、誤判與仍未證實的猜測。
當正確筆記愈來愈多，代理接著面對的是如何找到它們。
Wiki 與搜尋一起使用，25 題評估測到了什麼？
研究裡知識頁搭配搜尋的效果，比只靠知識頁更好。
Wiki 在這裡是一組互相連結的知識頁，代理可以沿主題找資料。它把搜尋到的零散片段整理成關係，因此可能幫助需要跨很多文件回答的工作。
團隊使用 Stainless 約35 萬個檔案、4.2 億個 token 建立評估。Token 是模型讀取文字的計量單位，這個規模也說明原始資料不適合每次全部讀進對話。
評估只有25 個問題，分數計算的是符合評分條件的程度。當建立知識頁的工作由兩個階段擴到128 個階段，只靠知識頁作答的分數由13%升到48%。
同時有搜尋工具與知識頁時，分數由54%升到61%。只用搜尋則是53%，因此整理過的內容在這組問題上有幫助，原始搜尋也仍然有價值。
這些數字不能寫成二十五題裡答對多少題，或一般企業的準確率。它們是指定資料、模型與評分條件下的結果，換一份資料庫仍可能不同。
搜尋加知識頁也讓每題少用約 2 萬個 token，但建置與維護知識頁同樣需要運算。這個節省描述回答階段，不能直接宣稱整體服務成本已下降相同比例。
官方知識頁範例也把它定位在變動較慢、會反覆提問的文件集合。若資料每分鐘都改變，維護負擔便可能抵銷重複查詢省下的成本。
這些改善有任務條件，另一組合約案例更顯示整理方式本身會改變結果。
多人維護同一份記憶，為何可能互相覆寫？
共享筆記需要與任務結構相容，否則多代理同時整理會漏掉關鍵事實。
在另一個合約工作中，團隊讓多個代理把條款寫到共用表格。它們有時覆蓋彼此的內容，也把原本需要精確保留的條文過度摘要，最後只留下57 項評分事實中的41 項。
調整後，每份合約交給一個代理維護各自頁面，重要條款保留原文。這次57 項事實都留下來，因為寫入責任與文件邊界較清楚，代理不再同時改同一個共用表格。
這個結果衡量的是該案例的事實保存，無法證明法律分析全面正確。它真正支持的工程選擇，是把容易互相覆寫的工作拆開，並依任務決定哪些文字必須精確保留。
Wiki 也不是每次都較好。另一些法律文件任務，只需搜尋單一文件就能找到答案，新增知識頁沒有明顯收益，反而多一份需要維護的內容。
某個案例甚至把115 KB的原始文件，整理成203 KB的知識頁。整理結果比來源還大，表示它沒有有效減少後續讀取負擔。
所以，記憶表示方式需要配合問題。若工作重點是跨文件對照，連結與分頁可能有用；若答案已集中在一段文字，直接搜尋可能更省事。
整理越有效，也越需要控制每次預先載入的大小與持續更新的成本。
哪些長任務適合加入記憶整理？
有可回查來源、重複任務與跨文件推理需求的團隊，較容易從記憶整理得到實際收益。
例如固定處理同一套產品文件的支援代理，可以反覆使用已確認的版本差異與例外。因為問題會重來，建立可回查的筆記，才有機會在後續工作收回整理成本。
相反地，若每次都換一份無關資料，先建立完整知識頁可能用不上幾次。資料變動很快時，代理還得持續檢查哪些規則已過期，因此保存本身不是完成治理。
開工自動載入的層也要保持精簡。官方以 Claude Code 為例，會讀取 MEMORY.md 的前 200 行或 25 KB 作為入口，其他內容按需要查找，避免每次都帶入全部筆記。
這個數字是該產品的載入規則，不是每個代理通用的最佳大小。它呈現的是一個設計原則，常用入口要足以帶路，又不能把大量細節強塞進每次工作。
記憶維護頻率也需要配合變動速度。每次都重新查所有內容會耗費運算，只在存檔時確認一次，則可能留下日後失效的規則，因此團隊必須知道哪些資訊最容易變。
如果整理後只是多了漂亮分類，回答仍找不到來源，改善就很有限。比較有意義的結果，是代理能更快找到原資料、發現前後衝突，並在條件改變時修正已保存的結論。
先保留一個能回到來源的工作紀錄，再決定是否值得建立更複雜的知識頁。
代理記憶 常見問題 FAQ
Dreaming 會把新知識訓練進模型嗎？
這篇工程文描述的是維護外部紀錄、筆記與知識頁。代理在後續工作讀取它們，並沒有因此更新模型的訓練權重。
記憶一定要做成 wiki 嗎？
未必。官方也把原始對話搜尋視為重要基礎，部分單文件任務使用知識頁沒有明顯收益，應依問題是否需要跨文件整合理解。
61%可以當所有企業的準確率嗎？
它是指定文件集合二十五題的評分條件分數，不能直接換成全企業資料問答表現。建置知識頁的費用，也沒有包含在每題節省的文字用量裡。
延伸閱讀：Claude Managed Agents 推出 dreaming 研究預覽
延伸閱讀：CORAL 代理記憶研究：先寫進度再清空對話，為何能少讀文字又答得更準？
結論
需要跨階段持續工作的團隊，可以先保存來源與結果，再讓代理維護少量有用途的規則。等到反覆搜尋與跨文件整理真的成為瓶頸，再加入更完整的知識頁與背景整理，較容易看出額外運算換回了什麼。
