大家都在講 Agent Memory，但「記憶」到底存在哪裡？
最近只要談到 AI Agent，幾乎一定會碰到 Memory 這個詞。
有人說 Memory 就是把過去對話存進 Vector DB，有人把 MEMORY.md、CLAUDE.md 當作記憶，也有人把 Knowledge Graph、Fine-tuning 甚至模型內部的 hidden state 都算進去。不過問題來了，這些東西明明長得完全不一樣，為什麼全部都可以叫 Memory？
我最近在整理這方面的研究時，看到一篇 2025 年底發表的 survey《Memory in the Age of AI Agents》，提供了一個滿好用的框架，剛好可以把現在有點混亂的 Agent Memory 拆開來看。其實這篇年初時我也 PO 過，沒想到到現在還是非常有幫助，所以今天整理一次分享給大家。
這篇 paper 認為，只用過去常見的「短期 / 長期記憶」其實已經沒辦法精準描述現在的狀況，所以他們提出了三個互相獨立的觀察維度：Forms（記憶以什麼形式存在）、Functions（這段記憶拿來做什麼）、以及 Dynamics（記憶如何形成與變化）。
我個人覺得這個切法最棒的地方，是它讓很多平常混在一起講的東西突然變得超好區分，我也做了兩著圖，可以配著看。
第一個維度：到底是「什麼東西」承載了 Memory？
我們先來談談 Forms。簡單來說，paper 把形式分成三種：Token-level、Parametric 與 Latent Memory。
最直觀、也是現在實際產品裡最常用的，就是 Token-level Memory。這邊先澄清一個很容易誤會的地方，它並不是指把 token 一個個存下來。它的實際意義是，記憶成為一個個明確、離散，而且可以被讀取、修改或重新組織的資訊單位。
例如寫在 MEMORY.md 裡的使用者偏好、Vector DB 裡切好的 chunks，甚至是 Knowledge Graph 裡的關聯節點。這些東西雖然儲存方式不同，但真正的共同點是它們都屬於外顯資訊。你可以看到它、改它、刪掉它，甚至追蹤它從哪裡來，所以 paper 把這類外部可以存取的形式都歸類為 Token-level Memory。
更有趣的是，Token-level Memory 還可以依照組織方式，繼續細分成 Flat、Planar 跟 Hierarchical 三種結構。這個分類法我覺得比單純問「你是不是用 Vector DB」更有意義。
Flat Memory：有記憶，但沒有明確關係
這就像是一堆散落的記憶單位，它可能是對話紀錄、摘要或過去的 task trajectory。系統可以用 embedding 或 keyword 把相關內容找出來，但這些記憶本身沒有寫出彼此的連結。很多常見的 conversation history 加上 vector search，其實就是這種 Flat Memory。
不過這邊很容易踩坑，Vector DB 有向量空間，不代表它就是 Graph Memory。Embedding 可以告訴你 A 跟 B 很像，但沒辦法告訴你 A 導致了 B，這是完全不同的資訊。
Planar Memory：記憶開始有「關係」
再往下一步就是 Planar Memory，記憶單位不再只是散落的節點，開始擁有明確的關係（explicit relationship）。像是在 Redis timeout 節點下面，直接連著根本原因：
Redis timeout
│
caused by
▼
Connection pool exhausted
這類 Memory 可以是 Graph、Tree 或 Table，它開始回答「這些記憶之間是什麼關係」，順利補足了單純搜尋相關性的限制。
我自己的感覺是，這個差異在 Agent 系統裡非常重要，因為 Agent 很多時候需要的不是更多 chunks，而是要知道「為什麼當時這樣決定」，或是「這條規則是從哪個 incident 來的」，光靠 similarity search 是通靈不出來的 🫠。
Hierarchical Memory：不只知道關係，還知道抽象層級
如果再往上一層就是 Hierarchical Memory，它開始出現不同的抽象層級。
Team Principle
│
Avoid synchronous jobs
│
┌────────┴────────┐
▼ ▼
Project A Rule Project B Rule
最底層可能是 raw logs 或 ticket，往上一層變成 incident 或 decision，最高層甚至變成 organization principle。
這其實點出了一個盲點，Agent Memory 的問題真的是找不到資料嗎？簡單來說，很多時候是 Agent 找到了十幾段對話，卻不知道哪段是觀察、哪段是 workaround、哪段是正式規則。這時候光靠 retrieval 已經不夠了，系統更需要真正的 memory organization。
除了 Token-level 之外，第二種形式是 Parametric Memory。這類記憶已經脫離外部檔案，直接變成模型參數的一部分。相較於 Token-level 是把事情寫在外面需要時再拿回來，Parametric 比較像是模型本身就帶著這些知識，Agent 不需要經歷 search 跟 retrieve 的過程。優點是用起來非常自然，但缺點也很致命，就是你很難指著某段參數說這就是記憶的源頭，它不像外部檔案那麼容易管理跟修改。
第三種更抽象，叫做 Latent Memory。它既不是外部資料，也沒寫死在 weights 裡，而是存在模型運算中的 hidden state 或 continuous representation。
這三者之間沒有絕對的高下之分，主要是 trade-off 完全不同。Token-level 最容易檢查、編輯跟加權限，所以今天企業在做 Agent system 時大量使用它真的不意外，因為它最好管。
第二個維度：小心 Form 和 Function 是兩回事
講到這邊常有人會問：那 Working Memory 是不是 Token-level？這其實問錯維度了，因為 Token-level 描述的是「形式」，而 Working Memory 描述的是「功能」。
Paper 把記憶的功能區分成三種：
Factual Memory：回答「世界是什麼樣子」，像是知道 User 偏好 TypeScript。
Experiential Memory：回答「過去做過什麼、學到了什麼」，例如上次增加 retry count 反而更不穩。
Working Memory：回答「現在正在做什麼」，像是目前的 current goal 跟 hypothesis。
這三種不同功能的內容完全都可以存成 Markdown，所以它們同時也都是 Token-level Memory。甚至一段 Experiential Memory 還可以被整理成 Hierarchical 結構。也就是說，Token-level × Experiential × Hierarchical 這種組合是完全合理的。
我覺得這是這篇 paper 最有價值的一點，它點出這幾種分類根本在回答不同問題，順便幫大家釐清了那些滿天飛的新名詞。
第三個維度：Memory 不是靜態資料，它還有 Lifecycle
最後還有 Dynamics 這個維度。一段資訊到底怎麼變成記憶？怎麼更新？又在什麼時候被拿回來？
Paper 把這分為 Formation（萃取值得留下的經驗）、Evolution（合併衝突與淘汰過期）、以及 Retrieval（重新取回）。
從這邊就可以看出來，Memory system 從來不只是一個 Database。Database 只負責處理記憶放在哪裡，但完整的系統還必須回答：什麼值得留下？什麼該忘記？衝突時怎麼辦？這些問題其實已經從 storage problem 變成了 learning problem。
所以把過去對話丟進 Vector DB 其實最多只解決了 Token-level Memory 的儲存與取回，它沒有回答一次失敗經驗要怎麼轉化為可重用的策略，也沒有解決新舊記憶衝突時該怎麼演化。這也是為什麼現在的研究漸漸從「我們怎麼記住更多」，轉向「我們該記住什麼、記憶該怎麼進化」，蠻值得關注的。
總結：記憶是為了影響未來
如果用一句話整理我現在對 Agent Memory 的理解：這其實已經超越了單純的資料結構，變成一套讓過去資訊可以持續影響未來行動的機制。
下次再看到一個新的 Memory system，也許可以先跳過「它是用哪個 Vector DB」這種問題，回頭檢視這三個維度：
Form：記憶存在外部、模型參數，還是 latent state？
Function：它是在保存事實、累積經驗，還是維持當前任務？
Dynamics：它怎麼形成、怎麼修改，又怎麼被取回？
一旦把這三點拆開，很多統稱為 Memory 的系統就變得比較好比較了。而目前最普及的 Token-level Memory 也都不會只停留在存一堆 chunks 做 RAG。從 Flat 到 Planar 再到 Hierarchical，我們其實正在見證一條從單純保存資訊走向組織經驗的演化之路，這大概是 Agent 接下來最精彩的地方 💪。
有在實作類似 Agent Memory 踩坑經驗的朋友，歡迎在下面留言交流分享 XD
作者：Chi