#2 Agent 的記憶到底「長什麼樣」？
上一篇我們先把一件事講清楚，Agent Memory 的核心不只是保存，所以它不等於 Vector DB，也不等於只是把歷史聊天紀錄全部 archive 起來。但接下來馬上會遇到另一個問題：那 Agent 的記憶到底存在哪裡？是 MEMORY.md？是 Vector DB？是 Knowledge Graph？還是存在模型的大腦裡？
答案是都有可能。不過這裡其實有個很容易搞混的地方，「記憶放在哪裡」和「記憶長什麼樣」其實是兩件不同的事。就像你問「我的照片在哪裡？」，你可能會回答「在 Google Drive」，這是在回答放在哪裡。如果我問「你的照片是什麼？」，答案可能是「一張 JPG 圖片」，這是在回答它長什麼樣。Agent Memory 也是一樣。
延續上一篇那個踩坑的例子，假設 Agent 上次 Deploy 的時候出包，被工程師修理後學到一個教訓：「Production migration 前，要先確認 backward compatibility。」這條記憶可以有很多種長相。它可以是一句文字：「Migration 前記得檢查 backward compatibility。」也可以變成模型的一部分，讓模型下次不用看到這句提醒，就會自己想到要檢查。甚至它也可能被壓成一堆人類看不懂的數字，藏在模型的內部狀態裡。
所以真正有趣的問題來了，到底是什麼東西在幫 Agent 記住這件事？《Memory in the Age of AI Agents》這篇 Survey，把 Memory 的長相大致分成三種：
Token-level Memory
Parametric Memory
Latent Memory
光聽名字可能覺得有點難懂，但概念其實沒那麼難，我們一個一個來探討。
1. Token-level Memory：把事情寫下來
這是目前最容易理解的一種，簡單來說就是怕忘記就寫下來。例如你今天跟 Agent 說「我不喜歡吃香菜」，Agent 可以把它存成「User 不喜歡香菜」。或者 Agent 今天 Deploy 出包，它可以存成「Production migration 前，要先確認 backward compatibility」，下次遇到相關問題再把這句話拿出來給模型看 😅。
這就是最典型的 Token-level Memory。它可能是一段文字、一個 JSON、一張 Memory Card，甚至是一整段以前的聊天紀錄。最重要的特徵是這份記憶明確存在，而且人通常看得懂。所以如果 Agent 記錯了，你甚至可以直接打開來看「奇怪，我明明喜歡香菜，它為什麼記成我不喜歡？」，然後手動把它改掉。這也是 Token-level Memory 很大的優點，就是好看、好改、好刪，也比較容易知道 Agent 到底記了什麼。
現在我們看到的 MEMORY.md 裡的文字、Vector DB 裡存放的 textual memory records、聊天摘要，其實大多都屬於 Token-level Memory。但問題來了，如果 Agent 只有 10 條 Memory 很簡單，那如果它有 10 萬條呢？於是大家開始想，這些記憶要怎麼整理。Survey 在這裡又把 Token-level Memory 分成了 Flat、Planar、Hierarchical。名字還是有點學術，我們直接翻成人話。
1-1. Flat Memory：全部丟進同一個抽屜
Flat 最簡單，你可以想像有一個超大的抽屜，每發生一件重要的事情就丟一張紙條進去。這些紙條彼此沒有什麼關係，全部都平平地放在一起，所以叫 Flat。當 Agent 要找東西時，就去問哪幾張紙條跟現在的問題最像。例如今天 Agent 要做 migration，它搜尋 migration 後找到「PostgreSQL migration 上次出過問題」。這就是很多 Vector DB Memory 最常見的做法，把每條 Memory 轉成 embedding 後做 similarity search，非常簡單而且很好用。
但它有個問題，它知道哪些東西很像，但不一定知道彼此的關聯。例如它可能找到三條記憶：第一條是 Migration 上次失敗過，第二條是舊版 API 還有人在用，第三條是 Production migration 要確認 backward compatibility。對人來說我們可能一看就知道，喔，原來就是因為舊 API 還有人用，所以 migration 才失敗，最後才學到 backward compatibility 這個教訓。可是對 Flat Memory 來說這通常只是三張分開的紙條，它不一定知道這三件事情其實是一整條故事，所以大家又開始往下一步走。
1-2. Planar Memory：開始用線把紙條連起來
Planar Memory 可以想成，不只把紙條放進抽屜，還開始用線把有關係的紙條連起來。例如 Migration 失敗是因為舊 API 還有人使用，所以下次要檢查 backward compatibility。這時候 Agent 不只可以找到哪些 Memory 跟 migration 有關，如果我們連「caused by」「depends on」這類關係也明確記錄下來，它甚至可以沿著這些關係找回事件的前因後果。這就是 Knowledge Graph 很常做的事，例如它會紀錄：ChiChi → works on → Cairn，或者 Cairn → uses → MCP。這些東西不再只是孤零零的紀錄，它們之間有關係，所以 Agent 可以開始回答「ChiChi 在做什麼？」或「Cairn 跟 MCP 有什麼關係？」，這跟單純做 similarity search 已經不太一樣了。
不過這裡有個很容易搞混的地方。很多人以為用了 Graph 就是 Hierarchical，或者用了 Vector DB 就是 Flat，其實不一定。這裡要小心，這篇 Survey 的 Flat、Planar、Hierarchical，是用 Memory topology 來切 Token-level Memory。另一篇今年的 Survey（Wu et al.）則從更工程化的 storage 視角，把「怎麼組織（Organization）」和「用什麼結構表示（Representation）」拆成兩個不同維度。
所以我們不該直接把 Flat 等同於 Vector DB、Planar 等同於 Graph、Hierarchical 等同於 Tree。實際系統完全可能是 Flat + Graph，也可能是 Hierarchical + Vector。重點是：Memory 的拓撲結構，跟底下使用的 storage 或 representation technology，並不是一一對應的。
1-3. Hierarchical Memory：開始分「小事」和「大道理」
再下一步就是 Hierarchical Memory，我自己覺得這個機制非常像人類的思考方式。
假設你第一次 Deploy 出包，Agent 記下「8 月 3 日 Deploy 的時候 migration 爆掉了」，這是一件很具體的事。後來又出包幾次，Agent 可能會慢慢整理出「Migration 很容易因為舊系統相容性出問題」。再經歷更多次之後，最後濃縮成一條原則：「Production migration 前，要先確認 backward compatibility」。你可以看到，它慢慢從單一事件，變成一種模式，最後收斂成一條原則。這就是 Hierarchical Memory 想處理的一種重要情境：讓記憶不只停在同一層，而能存在不同 granularity 或 abstraction level。如果再加上 consolidation 或 abstraction 的機制，系統就可能從很多具體事件中整理出 pattern，甚至形成更高階的原則。
這其實非常重要，因為如果 Agent 工作了一年累積了幾百萬條 execution log，你不可能每次都全部翻過一次。比較合理的做法是先找 Deployment Safety，再往下找 Migration，最後真的需要時才去翻 8 月 3 日那次事故到底發生什麼事。就很像我們在查書，不會每次都從第一頁開始翻，而是先看章節、小節，最後才看內容。這就是 Hierarchical Memory 想做的。
最近也有些研究開始認真討論，Agent 要怎麼自動把很多小事整理成比較大的概念。例如從 Raw Events 到 Episodes，再到 Patterns，最後變成 General Principles。有點像 Agent 在寫完日記後，還會自己整理心得。我個人覺得這會是未來 Memory 規模化之後很重要的一個方向。其實大家最後會發現，真正困難的挑戰往往在於要怎麼教 Agent 判斷哪些細節該留、哪些該合併，什麼時候該把經驗收斂成規則。這已經超越了單純的 storage 議題，比較像是在探討 Agent 該怎麼整理自己的人生經驗 🤣。
2. Parametric Memory：不要寫筆記，直接背起來
前面的 Token-level Memory 有個共同點，就是 Agent 要用以前的記憶時，通常得先把它找出來，很像考試的時候帶小抄。不過還有另一種方式，就是乾脆不要帶小抄了，直接背起來，這就是 Parametric Memory。
假設 Agent 累積了幾萬次 Coding Task，系統進一步把這些經驗整理成 training signal，再透過 fine-tuning 或 online adaptation 寫進模型參數裡。以後它遇到 migration 時，不一定要先從資料庫翻出那句話，自己就會順手檢查了。這很像我們學騎腳踏車，剛開始一直被提醒要注意平衡、看前面，但騎久之後我們根本不需要在腦袋裡默念這些規則，身體自己就會做。上一篇有讀者留言說這很像 Agent 跌來跌去之後養成的「肌肉記憶」，我覺得這個比喻用在這裡滿直覺的。
但要稍微區分一下，「肌肉記憶」是在形容它從經驗裡學會了什麼，而 Parametric Memory 則是在講這份經驗最後被放在哪裡。一個是在講這段記憶的功能與內容，另一個是在講它由什麼形式承載，這兩個維度不能混在一起談。
Parametric Memory 又可以粗略分成兩種。一種是直接修改模型本身，讓資訊真的寫進 base model parameters。另一種比較像是先不動整顆大腦，而在旁邊掛一小塊新的，例如 LoRA 或 Adapter 這種額外的參數。你甚至可以想像未來會有 Coding Memory LoRA、Finance Memory LoRA 或 Company-specific Memory LoRA，需要什麼能力就掛哪一塊上去，這會是個滿有想像空間的方向。
不過這也有個很明顯的問題。假設 Agent 記錯了「User 不喜歡拿鐵」，如果這句話存在 database 裡直接刪掉就好。但如果它已經被學進模型裡，你要怎麼精準地只把這件事情忘掉？事情就突然變得超級麻煩 🫠。所以 Parametric Memory 的優點是不用每次去搜尋，能更自然地影響模型行為，但缺點就是難看、難改，而且很難忘記。
3. Latent Memory：它記得，但你看不懂它記了什麼
最後一種就更有趣了，假設我們連文字都不存。Agent 看完 migration 的教訓後，直接把這些資訊壓成一堆模型內部的數字（例如 hidden state、KV Cache 或其他 latent representation），下次需要時直接把這些內部狀態拿回來用，這就是 Latent Memory。
你可以這樣想：Token-level Memory 是寫成一句話，Parametric Memory 是學進腦袋裡，而 Latent Memory 比較像是腦中還留著某種感覺，但不一定能把它完整說成一句話。就像你走進一間熟悉的房間，你腦中不會默念「桌子在右邊 1.4 公尺，門在後方 3 公尺」，但你就是知道怎麼走。有些資訊不一定需要被轉成人類語言，模型也可能保存下來。這就是 Latent Memory 很吸引人的地方，它有機會保留一些在文字 summary 壓縮過程中會被丟掉的內部訊號，也可以直接 reuse 某些模型之前計算過的狀態，不需要重新把一大段文字讀過一次。
但這也帶來一個超級大的問題，就是人類根本看不懂。如果 Token-level Memory 寫「ChiChi 喜歡拿鐵」，我們可以檢查。但如果這份記憶變成一長串向量數字 [-0.183, 0.921, 0.034, ...]，你根本不知道這到底是什麼。更麻煩的是，你不知道它到底記錯了哪一部分、不知道怎麼修改、不知道怎麼刪掉拿鐵這件事，甚至無法確定 Agent 剛才是不是因為這段 Memory 才做特定決定。這些在工程上都會變成惡夢 😭。
所以 Latent Memory 雖然在某些情境下有機會更有效率、減少重複計算，但同時也帶來了可解釋性、修改、刪除跟安全性等新挑戰。這部分我們在後面的系列還會繼續聊到。
那 MEMORY.md、Vector DB、Knowledge Graph 到底算什麼？
看到這裡，再回頭看開頭的問題就比較清晰了。
MEMORY.md：大部分時候裡面放的就是 Token-level Memory，例如用文字記錄使用者喜歡簡短回答、Deploy 前要跑 test 等等。但 .md 只是個存放的載體，它本身並不能代表這套 Memory System 有多聰明。
Vector DB：Vector DB 其實也不是一種 Memory，它比較像是記憶圖書館的搜尋系統。Memory 本身可能是一段文字，而 Vector DB 只是負責幫你找出哪幾段跟現在這個問題最相關。所以很多所謂的 Vector DB Memory，骨子裡其實是 Token-level Memory 加上 Vector Retrieval。
Knowledge Graph：Knowledge Graph 比較擅長保存實體之間的關聯（例如 A 跟 B 的關係），很適合用來建構帶有關係結構的 Token-level Memory。但就像前面提過的，用了 Graph 不代表它一定是 Hierarchical，這點滿容易誤解的。
Fine-tuning / LoRA：如果把記憶真的學進模型參數裡，這對應的就是 Parametric Memory。
Hidden State / KV Cache：如果是把記憶存在模型的 internal state 裡，這就比較接近 Latent Memory 的範疇。
所以到底哪一種比較好？
看到這裡，可能很容易會有個錯覺，覺得 Flat 很初級、Hierarchical 比較高級、Parametric 更高級，然後 Latent 最酷。其實完全不是這樣，它們單純只是適合解決不同的問題。
如果只是要記住「User 喜歡拿鐵」，我會希望它存在一條清楚的 Token-level Memory 裡，因為這樣最好改。如果是要處理公司過去 3 年的數千次事故紀錄，那我可能真的需要 Graph 或 Hierarchical Memory 來幫忙梳理脈絡。如果是 Agent 經過幾十萬次訓練後學會的 coding 習慣，用 Parametric Memory 讓他直接內化成直覺會更合理。如果是很大量的過往 model state 且希望高速 reuse，那 Latent Memory 就會有很大的優勢。
所以回過頭來，重點真的不是去爭論哪種 Memory 技術最強，我們真正該釐清的是「我到底希望 Agent 記住什麼，以及之後打算怎麼用？」。因為這兩個問題的答案不同，適合的 Memory 型態就會完全不一樣。
這剛好就帶到了我們下一篇的主題。這篇我們釐清了 Agent 的 Memory 可以長成什麼樣（文字、Graph、Parameters 或是 Latent State）。但接下來要面對的實務問題會是，Agent 到底應該記什麼？使用者喜歡喝拿鐵該記，上一次 Deploy 爆炸可能也該記。那昨天問過的一個無聊問題要不要記？Agent 每一次的 tool call 都要留下來嗎？錯誤的經驗要不要記？同樣的事情發生 100 次，我是要存 100 條還是收斂成一條？
下一篇我們會來探討 Factual Memory、Experiential Memory 與 Working Memory，簡單來說，並不是所有發生過的事情，都值得被 Agent 記住。
不曉得大家目前在開發時，都是怎麼幫 Agent 建立記憶機制的？歡迎在下面留言分享交流 🙏。
作者：Chi