選型的第一個問題不是「哪個框架最好」，而是「我需不需要記憶層」。決策樹 的前兩題就淘汰了相當比例的專案——需要對話續接的不是記憶問題，是 checkpointer 問題。以下建議都以「已經確定需要跨 session 記憶」為前提。
貫穿所有類型的一條原則：先做常駐層。 一個設計良好的常駐層（規則 ＋ 使用者畫像，全量載入，有 token 配額）在多數專案裡就提供了記憶價值的大半，而它的實作成本是一個檔案加一段組裝邏輯。召回層、圖層、時間模型都應該在常駐層被證明不夠之後才加。
聊天助理 / 個人化產品
特徵：大量使用者、每人記憶量中等、以語意事實與偏好為主、對延遲敏感、需要可刪除性。
建議：Mem0 或自建的「常駐畫像 ＋ 召回事實」兩層結構。
理由：這類產品的記憶幾乎全是語意型，Mem0 的 extract-update 管線正是為此設計的；它非侵入、不綁 orchestration，整合成本最低；user_id scope 天然處理多租戶隔離與刪除請求。
必須自己補上的三件事：
常駐畫像。 Mem0 的召回是 top-k 相似度，這意味著「使用者的名字」有機會不被召回。把身份與核心偏好維持成一份常駐的結構化畫像（可以由 Mem0 的條目定期綜合出來），與召回層並存。這正是 ChatGPT 的雙層設計（saved memories ＋ reference chat history）在解決的同一個問題。
寫入搬離 hot path。 Mem0 每次寫入至少兩次 LLM 呼叫，放在使用者等待路徑上既慢又貴。改成對話結束後或週期性批次處理。
成長監控與歸檔。 Mem0 沒有容量控制。
不建議：圖架構（多跳推理在這類產品裡幾乎用不到，運維成本卻高一個量級）、Letta（runtime 綁定對已有架構的產品太重）。
編碼 agent / 開發者工具
特徵：記憶以程序型規則為主（專案約定、建置流程、慣用寫法）、需要被人類審閱與修正、單使用者或小團隊、記憶量中等。
建議：檔案原生路線。
理由：這類記憶的核心是規則，而規則必須不漏召回，因此只能常駐或精確定址，不能經過相似度篩選。同時開發者需要能直接讀、改、diff 記憶——CLAUDE.md / AGENTS.md 這類慣例之所以成為事實標準，正是因為它命中了這個需求（舊專欄的 規則記憶：Agent 的工作憲法 完整處理了這一層）。
具體結構可以直接參考 OpenClaw 與 Hermes：規則檔（常駐、唯讀或人工維護）＋ 長期記憶檔（常駐、嚴格寫入門檻）＋ 每日日誌（append-only、按需檢索）＋ SQLite 索引（向量 ＋ FTS，衍生物）。
必須注意：規則檔的成長要嚴格控制（每輪都在付 token 稅）；日誌的檢索需要索引層，不能靠 grep 撐到後期；規則的變更應該走人工審核而非自動寫入，這同時是品質與安全的要求。
不建議：向量為主的方案（規則會漏召回）、圖架構（過重）。
多 agent 系統
特徵：多個 agent 協作、需要共享知識、記憶的一致性與污染擴散是主要風險。
建議：Letta，或自建並把共享層設計成唯讀。
理由：Letta 的 block 共享是目前最成熟的多 agent 記憶原語（同一個 block_id 掛在多個 agent 上），而且它的唯讀 block 直接提供了污染防護的結構性手段。sleep-time agent 可以扮演「唯一的共享層 writer」這個角色。
必須自己處理的：
併發寫入語意。 Letta 沒有定義這件事。實務上把共享 block 的寫入序列化（單一 writer 或樂觀鎖）。
污染擴散的阻斷。 共享層應該唯讀，或寫入需要額外驗證。單一 agent 能直接寫入所有 agent 都會讀的層，是設計缺陷。 詳見 多 agent 共享。
agent 層級的 provenance。 每條共享記憶要知道是哪個 agent 寫的，才能在發現污染時精確撤銷。
這個類型的生態成熟度最低。 選 Letta 是因為它最接近，不是因為它解決了問題。預期要自己寫相當多的東西。
知識密集型 / 企業內部應用
特徵：需要把大量既有資料（文件、工單、程式碼、資料庫）變成 agent 的記憶、有存取控制需求、領域實體型別穩定、需要多跳推理。
建議：Cognee，或 Cognee 的管線設計 ＋ 自己的實作。
理由：它是唯一把「多來源攝取」當成一等公民的方案（官方稱支援三十種以上來源），而權限檢查在 cognify 管線內部——對有存取控制需求的企業場景這是正確的設計。ontology 支援讓抽取品質可控，而穩定的領域實體型別正好讓 ontology 的維護成本可以接受。
必須注意：cognify 成本高，只能批次或非同步；時間模型弱，如果「事實隨時間改變」重要，需要另外補（或改用 Graphiti）；學習曲線陡，元件多。
需要時序與稽核的領域
特徵：事實會隨時間改變且歷史有價值（客戶關係、病歷、專案狀態、法規遵循）、需要向稽核者解釋「系統為什麼這樣判斷」。
建議：Zep / Graphiti。
理由：雙時間軸是它獨有的能力，而且沒有便宜的替代品。 如果你的產品需要回答「三個月前他的偏好是什麼」或「系統在什麼時點知道這件事」，其他所有方案都答不出來。episode-level provenance 同時滿足了稽核需求。
必須注意：寫入成本與延遲最高；需要營運圖資料庫；實體消解錯誤（把兩個不同的人合成一個節點）造成的污染比向量庫的錯誤更難發現與修復——這是它最大的品質風險，需要對消解結果建立抽樣審核；失效邊會單向累積，歸檔策略必須事先設計，它沒有內建。
一個省成本的中間選項：如果只需要雙時間軸而不需要多跳推理，在 SQL 表上加四個時間戳欄位就成立（見 schema 草案），不必引入圖資料庫。這是本專欄推薦給多數專案的做法——抄 Graphiti 的時間模型，不抄它的儲存。
已經在用 LangGraph 的專案
建議：LangMem。
理由摩擦最低，而且 checkpointer 與 Store 的二分本來就是最清楚的概念切割。但要清楚它提供的是機制與分類，不是完整的記憶治理——去重、衝突解決、失效、容量控制都要自己實作。實際上這意味著你會照著 藍圖 自建，只是用 Store 當儲存後端。
如果不在 LangChain 生態：不值得為 LangMem 引入整個框架。抄它的概念設計（checkpointer / Store 分離、三型記憶、hot path / background 顯式選擇）比引入它的相依更划算。
一組跨類型的預設建議
如果不想讀完上面所有類型，以下是我會給任何新專案的預設起點：
先做常駐層，用檔案。 規則 ＋ 使用者畫像，Markdown，全量載入，各自有 token 配額。這一步在多數專案裡就交付了記憶價值的大半。
確認 checkpointer 是誰的責任。 多數 orchestration 框架已內建；不要用記憶框架解這個問題。
需要召回層時，用混合檢索。 向量 ＋ 關鍵字，不要純向量。儲存可以就用你既有的資料庫（Postgres ＋ pgvector 或 SQLite ＋ FTS5），不需要專門的向量服務。
寫入實作完整四操作，含 NOOP，並記錄理由。 這一步是防止庫膨脹與失去可稽核性的關鍵。
在 SQL 表上加雙時間軸的四個欄位。 成本幾乎為零，而且事後補很痛。即使現在不用時效查詢，資料先記著。
第一週就加上 assemble trace 與 decision log。 見 評測。
把記憶做成可替換插槽。 照 介面草案 定義自己的 MemoryStore / MemoryIndex / MemoryPolicy，用框架實作其中一部分。在一個一年內變動這麼大的領域裡，這層薄抽象的價值遠超它的成本。
只在證明常駐層 ＋ 召回層不夠之後，才加圖或換 runtime。 過度設計記憶層是這個領域最常見的浪費，而每一個多出來的層都是一個新的失效模式。