Anthropic Agent 記憶解讀：61% 的 wiki 成績，「做夢」改善了什麼？（2026）

2026 年 11 月 6 日，Anthropic 在官網發布 Lance Martin 撰寫的〈The components of agent memory〉，討論 Agent 記憶如何跨工作階段留下來，以及離線整理能修正什麼。最值得追問的，是一份筆記從「上次寫過」變成「下次可信」之間，究竟經過了哪些檢查。

下面先讀清楚報告的實驗，再對照官方實作與外部研究，最後判斷開發者該把預算花在哪裡。這是一組由 Anthropic 執行的特定任務實驗；文中的成績不代表 AlphaLab 重現，也不等於所有 Agent 的成功率。

一、Agent 記憶的四層：先分清紀錄、筆記與常駐脈絡

Memory is, occasionally, a prediction.

中文：記憶有時是一種對未來需求的預測。

Lance Martin，Anthropic 原文

把一句話保存下來，等於押注未來還會用到它。但當下有用的資訊，未必適合永久保存。虛構例子：今天會議改到三點，是一項有日期的狀態；「所有會議都在三點」則是錯誤的長期規則。差別不在資料能不能寫入，而在你如何保留適用範圍。

原文的分層可濃縮為：逐字紀錄保留事件，筆記挑出重點，wiki 串起關係，注入脈絡則把少量資訊帶進下一回合。「做夢」（dreaming）指工作間隙的回顧整理；本文討論的是可再次讀取的外部脈絡，不是靠這些筆記更新模型權重。

可以把這四層想成倉庫、便條、地圖與桌面。桌面放太多東西，就失去一眼找到重點的功能；只留下地圖、卻丟掉倉庫的原始紀錄，又會讓你難以查清地圖畫錯在哪裡。這個比喻也指出一條設計原則：整理後的內容應能指回依據，常駐內容則要付得起每次載入的成本。

原文另以 CL-Bench 資料庫任務與遊戲紀錄比較模型如何挑選重點：有的留下未驗證猜測，有的把已測過的規則存起來；在該 CL-Bench 任務中，限定「只記失敗」反而削弱了部分較強模型的記憶收益；提示要多具體，也因模型而異。這些案例讓「先記下、再驗證、再重用」的循環變得可見，卻不足以推出所有任務都該套同一份記憶提示。

二、Agent 記憶的 61% 對 53%：分母是評分條件

Anthropic 使用約 35 萬份、4.2 億 tokens 的 Stainless 內部文件，設計 25 道問題，讓 Opus 5 跨最多 128 個工作階段建立 wiki。報告中的搜尋加 wiki 最後達到 61%，只用搜尋為 53%，只用 wiki 最高 48%；這些百分比量的是評分條件達成程度。

61 減 53 是 8 個百分點。它不是「回答 25 題，答對其中 61%」的同義句，也不足以推出任意公司導入後都會進步相同幅度。評分可以一題包含多個條件；模型、搜尋器、文件結構與題目都會影響結果。

比較值得採取的解讀是：在這組工作裡，事先整理關係與臨時查證可以互補。wiki 提供線索，搜尋保留回到文件的路。若問題只是問某張表的一個欄位，事先編一整本百科可能沒有必要；若答案橫跨多份資料，整理關係才有機會省掉重複探索。這是值得測的假說，不能直接當作採購保證。

三、失敗案例的價值：記憶也會把錯誤帶到下一次

原文也記錄了筆記誤導遊戲導航、部分單文件任務的 wiki 沒有明顯增益，以及多個 Agent 寫同一頁而覆蓋資訊的情形。換成分頁、明確指定保留原文等做法後，特定法律任務的條件覆蓋改善；這說明內容整理與寫入協調，也會影響最後成績。

The wiki grew to be larger than the raw files.

中文：wiki 長得比原始檔案還大。

Lance Martin，Anthropic 原文

「有保存」與「保存正確」應該分開驗收。想像助理把一筆未確認的猜測寫成結論，下一次再從筆記讀回來；如果驗證器只問「是否有相關記憶」，它甚至會把這次成功取回錯誤當作進步。真正要檢查的，是那條規則能否被支持、適用範圍有沒有變，以及使用後是否改善交付。

這也解釋了為什麼「反思一次」不宜成為通過條件。若回顧只是把同一個故事改寫得更流暢，沒有增加可核對的觀察，它就沒有提供新的保證。檢查者應看修改前後的差異與依據，而不是只讀模型聲稱自己修好了。

四、外部證據與官方實作：背景運算早有研究，接法仍有差別

2025 年的 Sleep-time Compute 原始論文研究在問題到來前，先對共用脈絡做運算，並討論查詢可預測性與效益的關係。它支持「把部分工作移到等待期間」這個研究方向；其數學題與軟體案例，並非這次 Stainless 內部文件結果的獨立重現。

這個差異很實際：背景先讀十份文件，若之後會被問一百次，整理成本可能被分攤；若資料天天變、每次只問一題，同樣的背景工作可能大半用不上。應比較完整工作週期的品質與總成本，不能只看查詢當下少讀了多少 tokens。

截至 2026 年 11 月 9 日查閱，Managed Agents 的 Dreams 官方文件將功能標為 research preview：它讀取既有記憶與過往工作階段，產生另一份輸出記憶庫，輸入庫保留。這提供了比較與丟棄候選版本的條件；是否採用新版本仍是一個獨立決定。

另一方面，11 月 2 日發布的官方 cookbook示範自行建立 dynamic workflow，依選定的逐字紀錄整理 wiki，也可接夜間排程；該範例會就地更新自己的記憶庫。預覽 API 的「產生副本」與 cookbook 的「就地更新」不能混成同一項安全保證。開發者應先認清自己接的是哪一條路。

Claude Code 的記憶文件也提供較小尺度的例子：啟動時讀入 MEMORY.md 前 200 行或 25 KB，以先到的門檻為準；其他主題檔案按需要讀取。這是索引與細節分開的產品設計，不能拿來推算前述企業文件評估的分數。

五、AlphaLab 的判讀：把記憶當成需要維護的推論產物

我同意：保留回查路徑，比只把摘要寫漂亮更有用

一份摘要的價值，不只在變短，也在讓下一個使用者用更少力氣找到對的證據。對 Agent 也一樣。原始內容與整理版本各有用途：前者可供追溯，後者降低定位成本。如果你能看出一條記憶從哪裡來、何時被修過，就能把錯誤定位到某次觀察、某次整理或某次取用。

相較之下，一段沒有來源、日期與條件的「經驗法則」，即使過去答對，也很難判斷今天還能不能用。建議把每條重要記憶的依據、適用範圍與最後查核時間放在附近；對尚未確認的解釋，明確維持假說身分。這些是本文的設計建議，不是聲稱官方產品會替你完成所有欄位。

我存疑：更長、更密、更常整理，能否直接換成更可靠？

頁數、連結數、整理次數都是投入或結構的指標。它們可以幫你找瓶頸，卻還沒有回答工作是否做對。若增加十條連結，同時把一條過期規則推到常駐脈絡，整體效果未必更好。若候選版本只是讓平均分上升，卻讓一項關鍵限制更容易漏掉，也可能不適合接上正式任務。

所以，值得追的下一份證據，是固定題目與模型後，把搜尋基準、筆記版與整理版放在同一張成績單，再保留逐題差異。這樣才能判斷改善來自資訊定位、正確更新，還是單純增加了更多運算。想建立這張表，可以接著讀 AI Evals 入門。

整理結果的採用權，要和寫入能力分開

能修改記憶，不等於該讓任何修改立即進入所有任務。對重要流程，我更偏好把整理視為產生候選版本：先檢查差異、跑固定案例，再選擇升級或保留舊版。失敗時能回退，才有辦法放心改進。官方 Dreams 保留輸入庫，提供了實作這種流程的材料；驗收策略則需要系統負責人自己定義。

同樣的邊界也適用於權限。筆記可以記住「使用者上次想寄信」，但這件往事不該自動變成今天的寄送授權。記憶提供背景，執行仍要受當前任務與權限控制。Agent Harness 的分工與 最小 Harness 實作能幫你把兩者放回同一個執行循環。

六、下一步：先驗一條錯誤能否被改正，再決定是否擴大

如果你正準備替 Agent 加記憶，先用自己建立的假資料，做一個能看清過程的小練習。今天先選一條會更新的事實、一條有例外的規則，以及一個需要跨文件才能回答的問題；把正確答案與可接受的來源寫在測試開始之前。這裡提供的是驗收設計，沒有預填產品成績。

1. 保留搜尋基準：固定資料、模型與題目，先記錄只查原始文件的輸出、時間與資源。
2. 加入同一批筆記：觀察哪些問題改善、哪些退步，確認答案仍能接回依據。
3. 產生整理候選：保留舊版，檢查新增、刪除與改寫，特別看過期資訊與適用範圍。
4. 用保留題驗收：整理時不提供驗收答案；通過後才讓下一批工作使用候選版。

每輪至少記四欄：答案是否合格、錯誤規則是否失效、完整週期花費多少、失敗能否回退。若整理花費 C，每次查詢可省 s，預計可重用 n 次，單看成本至少要比較 C 與 n × s；品質退步與更新頻率還要另列。這是記帳方法，並非本次報告的成本估計。

Meta 的另一組記憶更新，可接著讀 Active Memory 成績的分母分析；兩家公司的不同題目不適合排成同一個名次。若要讓筆記與權限一起接受檢查，永久批准與秘密值留存分析則補上了另一段資料生命週期。

Agent 記憶值得期待的，是減少重複探索；值得防範的，是把一次誤判保存成反覆生效的規則。今天先找一條曾經寫錯的筆記，確認系統能指出依據、改正內容，並在下一次工作真正使用修正。這條路走通，再增加頁數與背景運算，才有可累積的進步。