最近看大家在聊 Agent Memory，我反而越來越覺得，真正困難的環節通常不是怎麼把記憶存進去，而是怎麼讓它在規模變大之後，還能被正確地取回、更新、合併，甚至刪掉。

如果把 memory 只理解成 storage 問題，很容易做出一個一開始看起來很完整，三週後就開始拖垮系統的設計。

很多團隊的第一個誤會

很多人想到 memory，第一反應就是接一個 Vector DB，然後把對話摘要、tool trace、user preference、error log 全部塞進去。這個方向當然不能說錯，因為它確實解決了「先存下來」的問題。但論文裡常常被簡化掉的一件事是，能存，不等於能用。

假設一個 coding agent 一天執行 3,000 次 tool call，一個月就是將近 10 萬條 execution log。這時候如果每次新任務都去做 retrieval，哪怕只取 top-k = 20，看起來量不大，實際上也很容易把無關的噪音一起撈回來。更麻煩的是，這些記憶之間可能互相矛盾。

例如兩週前 agent 還記得「這個 repo 的 deploy script 要先跑 migration」，三天後流程被改了，現在改成先做 schema check，再由 CI 自動排 migration。舊記憶如果沒有過期，新的記憶如果沒有覆蓋規則，最後模型看到的是兩套都像真的 policy。這時候系統表面上有 memory，實際上是在餵 agent 一個逐漸失真的世界模型。

記憶一多，瓶頸就會換位置

我自己覺得 memory system 很像 cache design。小規模時，大家都在討論要不要加。規模上來之後，真正關鍵的是 eviction、invalidation、freshness 跟 consistency。

Agent memory 也是一樣。

當記憶量還小的時候，retrieval quality 看起來不錯，因為資料本身夠少，錯誤也不明顯。可是一旦累積到數萬條以上，問題就會從「記不住」快速變成四個更實際的工程痛點。

1. Retrieval cost

不是只有 token cost，還包括排序、重寫 query、summary refresh 的額外延遲。如果每輪任務都要先掃一遍長期記憶，再做二次整理，整體 latency 會很快逼近使用者不能接受的範圍。

2. Staleness

很多記憶曾經是真的，但現在已經不是了。user preference 會變，workflow 會變，tool schema 也會變。沒有 retention window 的 memory，最後通常會把過時資訊包裝成經驗。

3. Contradiction

同一件事在不同時間留下不同版本，系統如果沒有 conflict resolution，retrieval 出來的是「多個互相競爭的真相」。模型有時候會自己猜，有時候會硬湊，這就是 production 裡很難 debug 的那種錯。

4. Deletion difficulty

大家都喜歡談 persistent memory，但比較少談可刪除性。尤其一旦某些記憶被 summary 過、被引用過、又再被抽象成高階規則之後，你已經很難回答「我要刪掉的是哪一層」。這個問題如果放到企業流程或個人偏好，其實非常敏感。

我比較務實的切法

如果今天要做一個真的能上線的 agent，我會先把 memory 粗分成三層，而不是一開始就追求一個萬能記憶庫。

Working memory

這一層只服務當前任務，保存期限最短，像是最近 1 到 3 次 task 的上下文、臨時決策、尚未完成的假設。它應該更接近 scratchpad 或 active state。任務結束後，不是全部保留，而是只挑少數值得升格的片段往上送。

Episodic memory

這一層保存具體事件，例如「8 月 17 日某次 deploy 因為 backward compatibility 沒檢查而失敗」。它有時間戳記，有情境，有結果，也最好有可信度。這一層我會設 retention 與 consolidation 規則，例如 7 天內保留細節，30 天後只留摘要，累積 50 個相似 episode 後再嘗試抽成 pattern。

Policy memory

這一層才是比較穩定的原則，例如「production migration 前先做 schema compatibility check」。它不應該直接從單一 episode 自動生成，而應該經過多次驗證，或者至少有 review gate。否則很容易把一次偶發事件誤學

成永遠正確的規則。

這三層最重要的差別，不是存放格式，而是保存期限、更新機制、刪除方式都不同。 如果 working、episodic、policy 全部混在同一個 retrieval pool，系統最後通常會分不清楚眼前是暫時筆記、過往案例，還是正式原則。

真正需要的是 consolidation，不是無限累積

我最近越來越相信，memory system 的核心能力其實是 consolidation。也就是說，系統要能把很多局部事件慢慢整理成比較穩定的 pattern，再把 pattern 收斂成少數可操作的 principle。這有點像人類做研究時，不會把每一筆實驗 raw log 永遠放在桌上，而是先整理成結果，再整理成結論。

如果 agent 只能一直累積，不能定期收斂，那它最後得到的通常不是智慧，而是記憶債。短期看起來資訊越來越多，長期卻會讓 retrieval 越來越貴，判斷越來越混亂，修正成本越來越高。

所以我目前的看法很簡單。做 agent memory 時，第一個問題不該只是「存哪裡」，而應該先問三件事：這條記憶要保留多久、它何時該失效、它有沒有資格被提升成規則。

這三個問題如果沒有先答，memory 加得越快，系統通常壞得越慢而已。等你真的發現它有問題時，往往已經不是少記幾條就能解決了。