前三篇一路寫下來，我們已經釐清了三個核心問題。

第一篇我們先定義了到底什麼才叫 Agent Memory，第二篇接著拆解 Memory 長什麼樣，它可以是 Token-level、Parametric，也可以是 Latent。到了第三篇，我們探討 Agent 到底拿 Memory 來做什麼，所以又延伸出 Factual、Experiential 跟 Working Memory 的概念。

但到目前為止，我們大多都偷偷把 Memory 想成了一張靜態照片。例如「使用者不吃牛肉」、「正式環境使用 PostgreSQL」，或「資料庫轉移前要檢查向下相容」。好像 Memory 一旦寫進去就會乖乖待在那裡。

但真實世界顯然沒這麼簡單。

假設去年你跟 Agent 說你住台北，今年你搬到東京，跟它說你現在住東京了。那請問「住台北」這條 Memory 現在算什麼？是錯誤資訊還是歷史紀錄？應該直接刪掉，還是保留但標記成已過期？

換一個更麻煩的例子。Agent 第一次部署出包，學到轉移前要確認向下相容。後來它又踩了五次不同的坑，這五次經驗要全部留下來，還是應該慢慢整理成一條更完整的 Migration Strategy？如果這條 Strategy 被驗證了一百次，它有沒有一天應該乾脆被內化成 Skill，甚至直接寫進模型的 parameters 裡？

做到這裡，我個人覺得 Memory 真正有趣的地方才要出現。前三篇我們都在看 Memory 的「靜態分類」，第四篇開始看的，是 Memory 的「新陳代謝」。

Memory 本身有自己的生命週期，這在《Memory in the Age of AI Agents》中被稱為 Dynamics。如果前兩篇的 Form 和 Function 是在回答 Memory 現在是什麼，Dynamics 就是在探討 Memory 接下來會發生什麼事。

這份 Survey 把 Dynamics 拆成 Formation、Evolution 與 Retrieval 三個大階段。其中 Evolution 裡面又包含了 Consolidation、Updating 與 Forgetting。

一段資訊從出現開始，其實不斷在面臨決策，包含該不該變成 Memory、怎麼跟舊有記憶相處、要不要合併或淘汰，以及最後什麼時候該被拿出來用。

作為第一季的收尾，這篇我們就來看一段 Memory 到底是怎麼「活」起來的。

1. Formation：發生過的事，不一定值得記住

我們先看第一步。

你今天跟 Agent 工作了一整天，中間可能產生 300 句對話、50 次 Tool Call、12 個 Error、3 次修改、2 個 Decision，外加 1 個真的很痛的踩坑經驗。

這些東西全部都是 Memory 嗎？

其實不是，這裡有一個很關鍵的區別，就是發生過的事情只是 Raw Experience，它必須經過 Formation 才會變成真正的 Memory Unit。

例如 Agent 直接執行轉移導致正式環境報錯，工程師退回版本後發現舊版 API 還有人使用，最後提醒要確認向下相容性。前面這整段只是工作紀錄，最後被萃取出來的「轉移前先檢查向下相容性」就可能是一條影響未來行為的 Memory。

所以 Memory Formation 真正在做的事情，是從發生過的一大堆事情裡，決定什麼值得成為 Memory，以及它應該以什麼樣子留下來，單純把 Log 存下來是不夠的。

目前 Survey 整理的 Formation 方法很多，像是語意摘要可以把一大段對話壓成精簡摘要，知識蒸餾是從完整的執行軌跡裡萃取出真正有用的經驗。甚至是結構化建構，把原始資訊整理成事實、圖譜、實體或關聯。如果再往模型裡走，也可能形成 Latent Representation，甚至透過訓練直接內化到參數裡。

到底什麼時候才值得正式記住？

我們很直覺會想寫一個規則，規定每次 Session 結束就讓 LLM 總結一次。

這樣做當然可以，但有個滿明顯的問題。如果使用者今天隨口說最近好像有點想學日文，你立刻把它整理成「User is learning Japanese」，這可能記太快了，搞不好他三天後自己都忘了。

要解決這個問題，一個很直覺的做法是「先緩一緩」。我們不急著把每次互動都立即做昂貴的記憶整合，而是讓新資訊先進到一層比較輕量的 memory 裡。只有當相似的事情持續重複出現時，系統才認為這東西看起來真的不是偶然，值得花成本正式整理，這時才呼叫 LLM 萃取 episodic 或 semantic memory。

今年 ACL 的 RecMem 剛好就是用這個思路。在他們的實驗裡，這種 recurrence-based consolidation 讓記憶建構的 Token 成本相較幾個 SOTA 的 memory systems 最多降低了 87%，同時還能維持甚至提高準確率。

這裡要特別注意，RecMem 論文使用的「consolidation」，比較接近延後進行正式的記憶萃取與整理；和這篇 Survey 後面把 Consolidation 放在 Memory Evolution 裡的 taxonomy，術語使用上並不完全相同。

這個思路我自己滿喜歡的，因為這很像人的運作方式。朋友有一天說他最近好像喜歡喝美式，你不一定馬上把它刻進腦子，但如果每次見面他都點美式，你就會覺得這可能真的是一個穩定偏好。

所以一個成熟的 Memory System，第一個需要的可能不是 Save 按鈕，而是一道 Memory Admission Policy。我們該問的不是這件事發生了嗎，而是這件事情有沒有資格影響未來。

2. Evolution：新 Memory 進來後，麻煩才剛開始

假設一段資訊已經通過 Formation，我們順利得到「User 住台北」這條記憶。半年後又來了一條「User 搬到東京」，這時候最笨的系統可能會把兩條一起留下來。

下一次你請 Agent 幫忙找附近的餐廳，Agent 用 Vector Search 一撈，台北跟東京的相似度都超高，兩邊的餐廳都找給你。

這時候問題已經不是 Retrieval 做得好不好，而是你的 Memory 根本沒有被維護。這正是 Memory Evolution 要處理的事情。

這份研究把 Evolution 大致拆成三種操作：

• Consolidation：把分散、重複的 Memory 整理起來

• Updating：有新證據時，修改舊的理解

• Forgetting：讓已經沒有價值或不再有效的 Memory 離開有效記憶

這三個操作背後都在回答同一個核心問題，也就是新經驗來了，我原本相信的東西要不要跟著變。

2-1. Consolidation：五次踩坑，不一定要留五份 Log

以 Consolidation 為例。假設 Agent 半年內做了五次轉移，每一次都踩了不同的坑，像是忘了檢查舊版 API、忘了準備版本退回、沒確認手機端、下游服務還沒更新，或是資料表架構變更不向下相容。

最簡單的系統可以保存五個 Case，這沒有錯，但如果 Agent 每次碰到這種狀況都要讀完五份事故報告，久了還是會很累。所以 Memory 可能會慢慢 Consolidate 成一個包含檢查 client、驗證向下相容、準備 rollback 再執行的 Migration Strategy。

這也就是我們在第三篇提到的從 Case 走向 Strategy，但從 Dynamics 的角度來看，現在我們關心的是什麼時候應該把很多 Case 合成一個 Strategy。

今年另一篇 ACL 2026 Survey《From Storage to Experience》把 Agent Memory 的演化整理成 Storage、Reflection 跟 Experience 三個階段。最早期的做法只是把 trajectory 存起來，接著進步到對 trajectory 做反思整理，最後才開始跨多個 trajectory 抽象出可以重複使用的 Experience。

也就是說 Memory 的進化方向已經不只是存得更多，大家反而在嘗試從大量經驗中留下更少但更有用的東西。這跟我們上一篇 Experiential Memory 的主線完全接起來了。Memory 最初可能是在記 8 月 3 日發生了什麼，慢慢變成探討這類事情通常為什麼失敗，最後變成總結下次應該怎麼做。這才比較接近我們所謂的從記憶變成學習。

2-2. Updating：新的 Fact 可能會讓舊的 Fact 失效

再來是 Updating，這可能是現在 Memory System 最容易出大事的地方。

就像前面提到的住台北與搬到東京，對人來說我們自然能理解台北是以前、東京是現在。但對一個單純跑 Vector Search 的系統來說，"User lives in Taipei" 跟 "User lives in Tokyo" 語意結構非常接近，Retrieval 時很可能讓新舊兩條狀態一起被召回。

我們常常以為只要餵給 Agent 新資料，它自然就會把舊的覆蓋掉。但實務上，Agent 其實很容易遇到隱性衝突 (Implicit Conflict)。例如使用者不是明確說「不住台北了」，而只是隨口提了「東京的新家附近有間好吃的店」。人類可以輕鬆推論他的居住狀態變了，但 Memory System 往往沒有意識到該主動更新舊狀態。

像把 Implicit Conflict 做成 benchmark 來測試 Agent 的 STALE，或是進一步把 supersession gap 變成可訓練環境的 Supersede，這些近期研究都直指同一個 Memory-update gap。Agent 明明看過甚至理解了新的 Fact，但在 self-maintained memory 裡還是沒有正確淘汰舊值。而且研究也發現單純給更大的 Memory budget 並不能自動解決這件事，因為重點根本不在記得夠不夠多，而是記憶有沒有正確演化。

所以一個比較成熟的設計，可能不是直接把台北刪掉換成東京，而是保留歷史狀態。這就是為什麼現在越來越多人開始討論 Temporal Validity 或是 Bi-temporal Memory 概念。舊的 Fact 不一定消失，它仍然是歷史上發生過的事，只是它現在已經沒有資格代表 Current State。

這個區別非常重要，因為 User 曾經住台北依然是對的，但 User 現在住台北已經錯了。Memory 要管理的不再只是 True 或是 False，還必須包含這件事「在什麼時候是 True」。今年也開始出現像 MemStrata、Engram 這類近期 preprint，嘗試透過 temporal validity 或是 bi-temporal representation 來處理這種 stale fact，不再只把希望寄託在相似度搜尋上。

2-3. Forgetting：忘記不是 Bug，可能是 Feature

說起來可能有點反直覺，但一個成熟的 Memory System 其實必須學會忘記。

做 AI 的人通常會覺得好不容易記住了為什麼還要刪，但想像一下，如果 Agent 跟你工作了十年，它把你 8 年前用的 Email、6 年前的公司地址、3 年前廢掉的專案規則還有兩千條重複的 Experience 全部永久保留，這往往比失憶還可怕。失憶的 Agent 不知道會直接說不知道，你會有所防備，但拿著過期 Memory 的 Agent 會非常有自信地給你一個以前是對的答案，這通常更危險。

Survey 裡的 Forgetting 大致可以依據三種訊號來做：時間、使用頻率與重要性。例如長時間沒用的 Memory 可以逐漸 decay，低頻資訊可以被降權或淘汰，而低重要性、低價值的 Memory 則可以被主動 pruning。

更重要的是，「忘記」也不一定代表真的把資料刪除。實務上可能只是降權、退出正常 Retrieval、移到冷儲存，或標記成 inactive。至於前面提到的 Supersession 比較接近 Updating，而把很多 Case 壓成 Strategy 則比較接近 Consolidation。

所以我滿喜歡把 Forgetting 理解成「失去影響未來決策的資格」。

在記憶容量、能源與安全都有成本的情況下，Agent 本來就不能無限囤積經驗。我們在設計系統時，其實應該根據 Memory 的 value、harm、size 等因素，主動決定這條記憶該不該留。也就是說，忘掉低價值或有害的記憶，反而能讓 Agent 的效能與決策品質變得更好。這剛好也是近期論文 Forget to Improve 在 on-device Agent 場景裡的核心思想。

順著這個邏輯，未來的 Forgetting Policy 就不會只是寫死一個「30 天沒用就刪除」的規則，而是直接去評估這份 Memory 對未來的價值。我們需要把記憶價值拆成 goal relevance、task utility、reliability 以及 usage history 等因素來綜合評分（像是一篇近期 preprint《Learning What to Remember》所做的嘗試）。這件事會越來越重要，因為當 Memory 越來越大，真正稀缺的資源不是硬碟，而是 Agent 的注意力。

2-4. 什麼時候 Memory 應該被「內化」？

這裡剛好可以接上一篇讀者留言問的問題。

他把 Token-level 到 Parametric 再到 Latent 的過程，比喻成職員逐漸資深化的階段。新人剛進公司先拿 SOP 照著做，做久了慢慢內化成自己的做事方式，最後非常資深時，有些判斷甚至已經變成很難寫成規則的直覺。這個比喻雖然不完全精準，但確實點出了一個很核心的問題，到底什麼時候一段 Memory 才值得被內化？

所以我不會把 Token 到 Parametric 再到 Latent 想成初階到高階，也不會把它們當成一條固定的內化階梯。我認為這三種 Form 在可見性、可編輯性、持久性與撤回成本上，各自有著不同的 trade-off。

至於「把一段反覆驗證的 explicit experience 慢慢學進 parameters」，則是其中一種可能的 internalization path，而不是所有 Memory 最後都必須走的方向。今年的 TMEM 剛好就是在實作這樣的一套機制。它同時保留 explicit memory，又將從經驗裡 distilled 出來的 supervision 訊號，透過 online LoRA update 寫進 fast weights 裡，真的改變了後續的 policy。

更巧的是，今年 8 月剛出的一篇 COVE，直接把問題問成「什麼該 Remember，什麼該 Internalize」。它把易變的工具名稱、API 等資訊留在可快速修改的 external memory，把比較穩定、可泛化的 reasoning pattern 才交給 parameter update，甚至在確認模型已經內化後，再把原本的 external memory 釋放掉。這跟前面提到的穩定性、可修改性與撤回成本，其實是同一個 trade-off。

至於什麼東西適合內化，首先要看它夠不夠穩定。像公司規定一定要向下相容就相對穩定，但這週先不要部署這種指令顯然就不適合內化。其次是有沒有反覆被驗證，只出現一次的經驗可能只是偶然，跨很多 Task 都有效的 Pattern 才比較像真的 Rule。泛化能力也是個考量，使用者明天下午三點開會太 specific 了，但 API 變更前先檢查 dependency 就比較能跨任務重複使用。

另外如果錯誤代價很高、容易改變又需要 Audit，可能最好還是留在 explicit Token-level。高風險 Policy 有時候反而不該完全變成直覺，你可能會希望 Agent 每一次都能明確展示它遵守了哪條規則。綜合來看，一段 Memory 越穩定、越高頻、越能泛化就越值得內化；相對地，越常變、越需要 Audit、越可能被修正的東西就越該保持 explicit。

這可能會慢慢變成 Memory System 裡一個很重要的 Internalization Policy 問題。到底什麼時候 Case 要變成 Strategy，什麼時候 Strategy 要變成 Skill，又什麼時候 Explicit Memory 該轉成 Parametric Memory，甚至如果後來發現錯了還能不能退回來，都是很有趣的設計考量。

3. Retrieval：記得了，還得在對的時候想起來

嚴格來說，《Memory in the Age of AI Agents》談的 Dynamics 除了 Formation 和 Evolution 外，第三個大階段其實是 Retrieval。

Memory 已經存在了，那什麼時候該拿出來？

這件事我們前幾篇一直有提到，所以這裡不展開太深，但它至少包含了幾個層面的問題。When 是評估現在需要 Memory 嗎，What 是釐清我要找的是 Fact、Experience 還是某段 Task State，How 是決定要用 Vector、Keyword、Graph 還是直接 Generate，最後找到十條資料後，Post-processing 要決定哪些真的該塞進 Working Memory。所以 Retrieval 絕對不是單純跑一句 vector_db.search(query) 就結束了。

這裡會形成一個很重要的循環。Agent Action 產生 Raw Experience 後，透過 Formation 決定什麼值得記，接著經過 Evolution 決定怎麼合併、更新或忘記，最後在適當的時機透過 Retrieval 拿出來放進 Working Memory，進而影響下一次的 Action 並產生新的經驗。

這個迴圈跑久了，Agent 才真的有可能變得跟昨天不一樣。

4. 這些 Memory 操作，開始不再由人寫規則了

前面講的機制看起來好像都是工程師在寫規則，像是判斷重要性大於某個值就新增記憶，發現重複就合併，如果過期就刪除。但我們其實可以換個思路，與其由工程師寫死條件，不如讓 Agent 試著把「管理記憶」當作一種技能來學習。

例如 Memory-R1 讓 Memory Manager 學習 ADD、UPDATE、DELETE、NOOP；AgeMem 更進一步把 Store、Retrieve、Update、Summarize、Discard 等操作暴露成 Agent 可以自主選擇的 Memory Actions，再用 downstream task reward 去訓練管理策略。

以前做 Memory System，很像是工程師在幫 Agent 寫規則決定怎麼記憶。但現在已經出現一條很明顯的新方向：開始探討 Agent 能不能自己學會管理記憶。這也會是我們系列第 7 篇 Learned Memory Policy 會重點展開的地方。

說到底，Memory 不是資料庫，它是新陳代謝

看過前面這麼多機制後會發現，我們真的不該再把 Agent Memory 當成一個單純只能「新增」的資料庫。

一個真正運作良好的 Memory System，做的事情更像生物的新陳代謝。它必須持續吸收新經驗裡值得留下的東西、把零散事件整理成模式、更新那些已經不成立的舊觀念，最後再把不再有效的資訊代謝掉。

在這個動態循環裡，有些被反覆驗證的經驗，會從一張隨手記的紙條，慢慢變成一套 Strategy，最後長成 Agent 的 Skill 與行為傾向。

一個只會記、卻不會改也不會忘的 Agent，最後累積下來的通常不會是智慧，而是越來越沉重的歷史包袱。

講到這裡，下一個問題就有點可怕了。因為我們現在開始讓 Agent 自己決定什麼值得記、自己整理經驗、自己修改與刪除 Memory，甚至自己把經驗內化成技能。那請問它怎麼知道自己改對了？

如果它從一次偶然成功裡反思出一條錯的策略怎麼辦？如果兩段 Memory 互相衝突它刪錯了那一條怎麼辦？如果一段 hallucination 被寫進 Memory，之後每一次它都拿它當真的怎麼辦？更可怕的是，如果有人故意餵它一段假的經驗呢？

這也自然帶出了我們即將在「第二季」要探討的核心主軸：

當 Memory 活起來之後，我們該怎麼信任與管理它？

因為 Memory 一旦開始影響未來的 Action，錯誤就不再只是一個單純的 Output Error，它會變成一個被反覆使用、甚至被反覆強化的系統性錯誤。這也是為什麼我最近越看 Agent Memory，越覺得最後真正難的問題不是 Capacity，而是 Reliability（記對了嗎）、Security（會不會被惡意投毒）、Governance（多 Agent 之間怎麼共享與治理），以及 Agent 到底能不能自己學會管理這一切。

第一季我們釐清了 Agent Memory 到底是什麼、長什麼樣、拿來幹嘛、怎麼演化。接下來的第二季，我們就準備進入深水區，來看看當 Memory 真正落地到複雜應用時，會面臨哪些更嚴峻的挑戰。