昨天結尾留的問題：對話裡產生的資訊（使用者的偏好、任務的進度、踩過的坑）不在任何文件裡，沒人幫你 reindex。想像一個場景：使用者在對話中糾正了 agent 一次「我們專案的測試要用 pytest，不要用 unittest」，三個月後的某個 session，agent 還記得嗎？答案取決於一件事：當時有沒有人決定把這句話存下來，以及是誰決定的。

「誰決定什麼值得記」是記憶系統的第一個設計決策。把 mem0、agentmemory、engram、letta 這些開源記憶系統的做法攤開對照，這題的答案可以粗分成三種，而選了哪種答案，幾乎決定了整個系統的長相。

路線一：背景 LLM 幫你決定

代表：mem0（目前最多人用的開源記憶層之一）。它的思路是別讓 agent 分心管記憶：在 agent 的執行路徑之外，另起一個背景 LLM 分析對話、提取值得記住的事實，存成一條條精簡的 fact。

mem0 的版本演進藏著一個很值錢的教訓。舊版讓 LLM 做兩步：先提取事實，再判斷這條新記憶該「新增、更新還是刪除」哪條舊的。結果第二步一直出錯，因為 LLM 擅長從對話裡提取重點，卻不擅長對資料庫做精確的增刪改決策。新版把這個判斷拿走：LLM 只負責提取，重複交給 hash 比對擋掉，關聯交給實體關係圖去連。在記憶系統的 LoCoMo benchmark 上，分數從 71.4 跳到 91.6。

這條路線的代價是有損：LLM 提取是一次改寫，數字、精確的字詞都可能在過程中變形或消失。

路線二：機制全量捕捉，讓時間去篩

代表：agentmemory。它掛在 agent 的 lifecycle hook 上（agent 每做一件事就觸發一次通知），把工具呼叫、對話事件全部自動存進來，再依知識類型分層：怎麼做事的程序性知識幾乎不過期，今天的臨時觀察一個 session 後就衰退。

好處是 agent 什麼都不用管、幾乎不會漏。代價是雜訊：每個 bash 指令、每次檔案編輯都進了庫，搜尋的訊號很快被這些低價值觀察稀釋。

路線三：Agent 自己決定，紀律換信噪比

代表：engram 和 letta。立場相反：寧可漏記，也不讓雜訊進系統。

engram 要求 agent 主動呼叫 mem_save，並在指引文件裡寫死觸發時機：做完架構決策要存、修完 bug 要存、使用者確認慣例要存。它還有一個聰明的設計叫 topic key：同一個主題用 upsert 寫入（有就覆蓋、沒有就新增），保證「認證方案」這個主題永遠只有一筆最新紀錄，避免三個月後搜出五個互相矛盾的版本。

letta 更直接：記憶就常駐在 system prompt 裡，agent 在對話當下自己判斷「這件事值得更新記憶嗎」，直接呼叫工具改。沒有背景 pipeline，記憶是 agent 的一部分。

這條路線的信噪比最高，搜尋結果的排名最有意義。代價是完全依賴 agent 的判斷力和紀律，沒有指引約束的話，它可能什麼都不存。

還有一層大家都躲不掉：compaction 前的搶救

三條路線之外，所有記憶系統都要面對同一個敵人：context 滿了要壓縮的那一刻（Day 8 講過的分層防禦，最貴那層）。壓縮發生時，還在窗口裡、沒被存進記憶的工作脈絡會直接蒸發。所以成熟的系統多半有第三層機制：在壓縮觸發前，把還沒存的東西搶救出來。engram 掛了一支 post-compaction 腳本，letta 有一個背景 agent 在 session 之間做這件事。記憶系統的核心難題與其說是「怎麼存」，更多時候是「壓縮來臨之前，來得及存嗎」。

怎麼選：看你的場景在光譜的哪一端

一個要記住百萬使用者偏好的 SaaS，不可能指望每個 agent 自己決定存什麼；一個 coding agent 如果讓 hook 把每條指令都存進去，一個月後記憶庫就退化成雜訊堆。這題沒有標準答案，有的是場景。

存進去只是一半。存的內容長什麼樣（壓縮過的 fact、精煉的決策、還是原始全文），直接決定了它之後能用什麼方式被找到。這個耦合關係是明天的主題：記憶的檢索，以及為什麼寫入和搜尋其實是同一個決策。