一份以「平台 VP 事故复盘」形式組織的可商業交付產品管理 Deck。
沿著認知建立 → 自研實作 → 生產升級 → 落地治理四條敘事線，
把「為什麼記憶是工程責任」、「短期/長期記憶如何協同」、
「何時該從自研遷徙到 mem0 等中間件」三件事講清楚。
本 Deck 把記憶系統的學習拆成兩個不可省略的階段：第一階段用最基礎的 Python + OpenAI SDK 從零搭建 mini-OpenClaw 自研記憶系統（第二至七章）；第二階段引入生產級開源中間件 mem0（第八至十章）。
先建立三個不可繞過的認知：記憶是應用層責任、上下文窗口 ≠ 記憶、人類記憶的設計類比。
整條路徑分兩個階段。第一階段（第二至七章）從零搭建 mini-OpenClaw 自研系統；第二階段（第八至十章）用 mem0 生產級中間件取代手工規則。兩階段合起來構成「先理解原理、再掌握工具」的完整閉環。
讓天生無狀態的大型語言模型，具備跨對話、跨會話的持久化記憶能力。
先理解原理，再掌握工具 —— 不學會工具在解決什麼問題之前，先不急著用工具。
| 階段 | 產物 |
|---|---|
| 第二至七章 | mini-OpenClaw 自研 |
| 第八至十章 | mem0 生產中間件 |
五分鐘代碼演示揭示記憶系統存在的根本動機。兩版代碼唯一差別是後者維護了 messages = [] 列表，第二輪問「我叫什麼名字」時，第二版正確回答「你叫小明，你在學 Python」。
R1: client.chat.completions.create(
messages=[{"role":"user","content":"我叫小明"}]
)
# 第 2 輪：全新請求，沒有上下文
R2: client.chat.completions.create(
messages=[{"role":"user","content":"我叫什麼名字"}]
) → "抱歉，我沒有您之前對話的記錄"
# 有記憶版：維護 messages 列表
R1: messages = [{"role":"user","content":"我叫小明"}]
R2: messages.append(...); messages.append(新提問)
client.chat.completions.create(messages=messages)
) → "你叫小明，你在學 Python"
messages = []關鍵洞察：記憶系統是應用層的責任，不是 LLM 本身自帶的功能。
messages = [] 作為記憶系統的最簡實現messages.append(...) 追加用戶與助手訊息messages 一起傳給 LLM2026 年主流模型上下文窗口已大幅擴展（GPT-5.4 200K、Gemini 3.1 Pro / Claude Opus 4.6 達 1M、Llama 4 Scout 突破 10M tokens）。但上下文窗口存在三個硬限制：Token 上限、成本線性增長、推理延遲退化。
| 模型 | 窗口 |
|---|---|
| GPT-5.4 | 200K tokens |
| Gemini 3.1 Pro | 1M tokens |
| Claude Opus 4.6 | 1M tokens |
| Llama 4 Scout | 10M tokens |
100 輪對話 ≈ 第 1 輪成本的 100×
致命問題：上下文隨進程結束而消失，無法跨會話保留。
把 Agent 記憶系統對應到人類認知結構，建立一套從第一頁用到最後一頁的設計哲學：人腦不會記住每天遇到的所有事，而是選擇性地提煉關鍵信息寫入長期記憶——Agent 也應如此。
| 人類記憶 | Agent 機制 |
|---|---|
| 工作記憶 | messages[] 短期 |
| 長期陳述記憶 | MEMORY.md 注入 |
| 圖書館檢索 | 向量庫 RAG 檢索 |
| 通訊錄備註 | USER.md 用戶畫像 |
| 睡前整理筆記 | compressed_context 摘要 |
人類不會把每天遇到的所有事都永久記住，而是有選擇地提煉關鍵信息寫入長期記憶。
在動手實作前先建立結構性認知：Agent 系統是執行層與記憶層的雙子系統，四種記憶層路線代表四種哲學。
Agent 系統內部有兩個職責完全不同的子系統協同運作：執行層回答「下一步該做什麼」，記憶層回答「我知道什麼、該記住什麼」。兩層解耦帶來的工程收益是：修改記憶策略不會影響推理循環，升級執行框架也不會丟失歷史數據。
核心組件：
回答的問題：下一步該做什麼？
核心組件：
回答的問題：我知道什麼、該記住什麼？
langchain-deepseek 的 ChatDeepSeek + create_agent()mini-OpenClaw 文件系統記憶架構工程實踐中記憶層存在四條主流路線，理解這張地圖能幫助快速定位任何開源專案屬於哪條路線。四條路線沒有絕對優劣，選型取決於場景。
| 路線 | 代表 |
|---|---|
| 文件系統 | OpenClaw / mini-OpenClaw |
| 多後端存儲 | LangChain 1.x + LangGraph |
| 多源召回 | LlamaIndex |
| 分層自管理 | Letta（原 MemGPT） |
橫軸：透明度（人可讀 vs 黑盒）
縱軸：自主智能度（手工規則 vs LLM 裁判）
本課程採用 文件系統記憶路線，理由：
mem0 中間件打基礎很多開發者在此模糊處理導致系統設計混亂。短期記憶是「今天的便籤紙」，用完即扔只服務當前任務；長期記憶是「多年的日記本」，記錄穩定的、值得跨時間保留的信息。
| 維度 | 短期 | 長期 |
|---|---|---|
| 生命週期 | 單次會話 | 跨會話永久 |
| 消失條件 | 進程結束 | 顯式刪除 |
| 存儲介質 | messages[] / JSON | MEMORY.md / 向量庫 |
| 主要挑戰 | 超出長度後截斷 | 何時寫入/更新/刪除 |
選擇這條路線有三個明確理由：透明可讀、熱更新、人機共同維護。這條路線的局限也很明確：當記憶文件體積超過上下文容量時，全文注入會失效，需要引入 RAG 機制做語義檢索。
MEMORY.md，下次對話即生效MEMORY.md 超過約 2000 tokens（約 1500 中文字），全文注入成本上升適合：
不適合：
從「messages = []」開始，三大機制封裝成完整的 SessionManager：JSON 持久化、消息截斷、壓縮摘要。
工程化的第一步是加上會話持久化能力：關閉程序後重啟，歷史對話依然存在。mini-OpenClaw 用 JSON 文件存儲每個會話，四個欄位結構清晰。一個容易忽略但至關重要的實現細節：json.dump(..., ensure_ascii=False)。
{
"title": "會話標題",
"created_at": "2026-07-27T10:00:00Z",
"updated_at": "2026-07-27T10:30:00Z",
"compressed_context": "",
"messages": [...]
}
load_session(session_id) 加載會話（不存在則創建新結構）save_session(session_id, session) 持久化ensure_ascii=False 缺失，中文會被轉義成 \u 序列session_id（UUID 或時間戳）sessions/{session_id}.jsonsave_sessionload_session 恢復ensure_ascii=Falsemessages 列表會無限增長，第 50 輪對話時可能已累積上百條消息，若全部傳給 LLM，Token 成本是第一輪的百倍，推理延遲也顯著上升。最直接的解法是只保留最近 N 條消息傳給 LLM，mini-OpenClaw 默認 MAX_HISTORY = 20（後續版本調整為 30）。
| 設置 | 效果 |
|---|---|
MAX_HISTORY = 5 | Agent 顯得健忘 |
MAX_HISTORY = 20 | 工程經驗平衡點 |
MAX_HISTORY = 30 | 後續版本默認 |
MAX_HISTORY = 100 | 長會話成本失控 |
DeepSeek-V3.2 支援 128K 窗口，20-30 條僅佔極小比例。
用戶在第 3 輪說「我叫小明，我在做機器學習項目」，到第 25 輪問「幫我繼續優化上次那個模型」，如果第 3 輪已被截斷：
compressed_context核心思路：當對話歷史超過閾值，把較早的對話讓 LLM 壓縮成一段自然語言摘要，存入 compressed_context 欄位，下次對話時先注入這段摘要，再接上最近 N 條歷史。
system 角色注入壓縮 prompt 明確要求保留：
第三人稱描述、100-200 字內、固定前綴開頭。
system 角色注入 → 避免 LLM 誤把摘要當成用戶說過的話temperature=0.1 → 摘要穩定可重現存儲、截斷、壓縮三個機制最終封裝進一個完整的 SessionManager 類，這是短期記憶層的核心，所有會話操作都通過它完成。四個核心方法各司其職，並內建 v1→v2 向後兼容自動遷移邏輯。
load(session_id)add_message(...)get_messages_for_llm()save(session)messages[] 正常增長證明整套機制的持久化可靠性。
list 格式（舊版）dict 結構（新版）前三節使用 openai SDK 直接調用，幫助理解每一步。mini-OpenClaw 源碼實際用 langchain-deepseek 的 ChatDeepSeek。關鍵實驗揭示：InMemorySaver 的兩大局限證明自建 SessionManager 的必要性。
| 維度 | OpenAI SDK | LangChain |
|---|---|---|
| 調用方式 | 原生 | 封裝 |
| 流式輸出 | 支援 | 支援 |
| 工具綁定 | 手寫 | 生態齊全 |
| Checkpointer | 無 | 內建 |
| 生態集成 | 單點 | 完整 |
| 持久化 | 無 | 多後端 |
實驗：create_agent() 不傳 checkpointer → Agent 沒有自動記憶。
checkpointer=InMemorySaver() + thread_id → 記住上下文但 InMemorySaver 有兩個致命局限：
langchain-deepseek + 自建 SessionManager 取代 InMemorySaver選擇什麼存儲類型，決定了後續寫入邏輯和檢索邏輯的一切。四種存儲對應四種哲學。
向量資料庫解決的問題：當用戶說「上次我提到的那個 Python 項目」時，Agent 怎麼在幾百條歷史記憶中找到相關片段——即便措辭和原始記憶完全不同。關鍵洞察：向量距離近代表語義相近而非字面相近。
text-embedding-3-small (1536 維)「想吃東西」和「有點餓了」在向量空間中距離很近，傳統關鍵詞搜索找不到，向量檢索能找到。
VectorStoreIndex + SentenceSplitter + OpenAIEmbeddingindex.storage_context.persist() 持久化 → 重啟後索引全丟text-embedding-3-small）chunk_size=256, chunk_overlap=32）persist()三種非向量存儲各擅勝場。mini-OpenClaw 採用 KV（文件系統輕量實現）作為短期會話的精確存取介質；自然語言文本用 RDB 的 LIKE '%偏好%' 做檢索是典型的工具誤用。
mini-OpenClaw 的 sessions/ 目錄本質上就是文件系統級 KVNeo4jLIKE '%偏好%'把四種存儲類型放在一張表裡對比，能快速做出工程選型決策。大多數對話 Agent 只需向量庫 + KV 存儲的組合，這也是 mini-OpenClaw 的選擇。
| 類型 | 檢索方式 |
|---|---|
| 向量 | 語義相似度 |
| KV | 精確 Key |
| 圖 DB | 圖遍歷路徑 |
| RDB | SQL 精確/聚合 |
典型工具：FAISS/Chroma/Pinecone · Redis/JSON · Neo4j · PostgreSQL/SQLite
關鍵原則：組合而非單選。大多數對話 Agent 只需向量 + KV。
sessions/{id}.json（短期會話精確存取）MEMORY.md 索引（長期語義檢索）回顧四種存儲類型的選型邏輯，可以提煉出一條核心工程原則：存儲類型選錯，後續的寫入邏輯和檢索邏輯都會跟著跑偏，就像把圖書館的書隨機堆在倉庫裡，查閱效率必然是災難級別的。
sessions/{id}.jsonLlamaIndex 的 SentenceSplitter + VectorStoreIndex 實現文檔分塊和語義檢索解決了「存在哪裡」之後，下一個問題是「何時寫入」、「如何高效讀取」、「如何避免記憶退化」。四個機制構成自適應長期記憶系統。
寫入觸發是長期記憶系統最關鍵的設計決策之一：寫入太頻繁，記憶庫充滿噪音；寫入太保守，有價值的信息被遺漏。mini-OpenClaw 採用「LLM 主動判斷」策略，判斷標準是事實性、穩定性、跨會話復用性。
值得寫入：用戶叫小明，是 Python 開發者
不寫入：用戶剛問了 for 循環語法
把所有對話都寫入長期記憶 → 100 條對話裡通常只有 5-10 條真正值得長期保留。
temperature=0.1 調用 LLM{"worth_memorizing": true/false, "memory_text": "..."}最簡單的方式是 Direct 注入：每次對話開始時把 MEMORY.md 全文讀出，直接拼接到 System Prompt 頭部。這種模式實現極簡單、信息完整無遺漏，是 mini-OpenClaw 的默認模式，唯一限制是體積——當 MEMORY.md 超過約 2000 tokens 時需切換到 RAG。
計算當前 MD5 → 比對快取 MD5
├─ 相同 → 直接返回快取
└─ 不同 → 重讀磁盤 + 更新快取
性能開銷接近零。寫入後必須主動使快取失效（將 md5 置空）。
MEMORY.md 約 1500 中文字閾值判斷函數 should_use_rag() 估算當前記憶內容的 Token 數。
MEMORY.mdshould_use_rag() 判斷是否切換當 MEMORY.md 體積超過閾值，Direct 注入成本變得不可接受。RAG（Retrieval-Augmented Generation）注入解決的正是這個問題：不再全量讀取，而是根據當前用戶輸入語義檢索最相關的 Top-K 條記憶注入。
VectorStoreIndexMEMORY.md 按每行一條記憶的格式天然適合按行分塊實時寫入追求速度，沒時間做全局掃描。隨時間累積會出現新的質量問題：同一事實被多次寫入、早期記憶已過時、部分記憶措辭混亂需要整理。sleep-time agent 在對話間隙的空閒期異步運行整理任務。
.bak 文件mini-OpenClaw 採用「手動調用為主」策略，不做全自動調度四個機制不是相互獨立的，它們共同構成一個自適應的長期記憶系統。把長期記憶的生命週期拆解為「寫入判斷 → 存儲選型 → 讀取策略 → 質量維護」四個環節，每個環節都有獨立可測試、可調優的機制。
當你發現 Agent「記錯了」或「忘記了」，可以精確定位是哪個環節出了問題：
這也為下一章節把短期記憶與長期記憶真正串聯成完整的 MemoryManager 打下了模組化基礎。
SessionManager（Ch 3）MemoryManager 統籌兩者把短期 SessionManager 與長期四環節串聯為單一抽象層。三原則、三階段主鏈路、去重升級與四個擴展方向。
把短期記憶與長期記憶兩個獨立模組串聯成有機整體，需要解決三個問題：調用方只和 MemoryManager 交互、最終輸出對 LLM 透明、底層異常不讓 Agent 崩潰。這三條原則決定了介面設計，而介面一旦確定，實現細節反而不重要。
| 原則 | 約束 |
|---|---|
| 單一入口 | Agent 主循環只調 MemoryManager，不直接操作 SessionManager 或 MEMORY.md |
| 對 LLM 透明 | 最終輸出是 messages 列表，LLM 不感知背後的記憶管理邏輯 |
| 可降級 | MEMORY.md 不存在、索引構建失敗、網絡超時——任何異常都不讓 Agent 崩潰 |
關鍵洞察：介面設計是工程紀律，介面一旦確定，實現細節反而不重要——這是良好架構設計的通用智慧。
MemoryManager 把三個公開方法串成完整的請求處理鏈路。load 加載短期與長期記憶；get_messages_for_llm 按固定順序組裝 LangChain Message 列表；update 追加本輪對話並觸發壓縮與長期寫入。三階段的調用順序不能亂。
# 階段一：加載
def load(session_id, user_query):
# 內部透過 _load_long_term() 自適應切換 Direct/RAG
return (session, long_term_context)
# 階段二：組裝
def get_messages_for_llm(session, lt, sys_base):
# System Prompt → 壓縮摘要 → 最近 N 條歷史
return [SystemMessage, ..., HumanMessage, ...]
# 階段三：更新
def update(session_id, session, user_input, asst_resp):
# 追加、判斷壓縮、判斷長期寫入（try/except）
# save_session()
system 角色注入_safe_append_memory 在寫入前先做去重檢查，新記憶與已有條目的關鍵詞重疊超過 60% 視為重複。但這個方案在中文場景下完全失效——中文無空格分詞，導致去重機制形同虛設。把判斷邏輯交還給 LLM 的語義理解能力，才能真正解決問題。
| 句子對 | 關鍵詞交集 |
|---|---|
| 你好 Python | 0（兩個 token） |
| 你好 Python | 0（兩個 token） |
| 結論：關鍵詞交集永遠 = 0，去重永遠失效 | |
worth=True場景一在同一 session 驗證短期記憶、場景二換到新 session 驗證長期記憶跨會話能力。至此雙層記憶系統功能完備，但工程實踐永遠沒有終點，課程提出四個延伸方向。
場景一 + 場景二 共同驗證了雙層記憶系統的端到端正確性
tags 字段實現不同 Agent 只能看到特定類別的記憶user_id / agent_id / run_id 三維命名空間形式重新出現課程代碼是教學簡化版，真實工程在文件組織、System Prompt 組裝、請求生命週期三個維度更精細。本章回答「課程中設計的記憶機制，在真實系統中是被怎麼對待的？」
真實工程在文件組織上更精細：graph/ 存放核心邏輯、sessions/ 存放短期記憶、workspace/ + memory/ 存放長期記憶。prompt_builder.py 的 build_system_prompt() 方法把 System Prompt 拆分為 6 個組件按固定順序拼接，每組件有 MAX_COMPONENT_LENGTH = 20000 字符上限。
| 目錄 | 核心文件 |
|---|---|
| graph/ | session_manager / memory_indexer / prompt_builder / agent |
| sessions/ | 短期記憶 JSON + archive/ 歸檔 |
| workspace/ + memory/ | SOUL / IDENTITY / USER / AGENTS 永久人格層 |
把所有組件串起來，一條用戶請求的完整處理鏈路：load → build_system_prompt → ReAct 循環 → write_file_tool 主動寫入 → save_session 持久化。這條鏈路與課程第六章 MemoryManager 的三階段設計高度對應。
| 課程第六章 | 真實工程 |
|---|---|
| load(session_id, query) | load_session_for_agent() |
| get_messages_for_llm() | build_system_prompt() + 構造歷史 |
| update() | write_file_tool + save_session() |
多了 Skills 掃描 + 六層 System Prompt 組裝 兩個額外環節
mini-OpenClaw 在教學場景表現出色，推向真實生產會依次撞上三個天花板。mem0 用 LLM 做記憶的裁判，自動決定什麼值得記住、什麼需要更新、什麼應該遺忘，而不是用硬編碼規則管理記憶。
mini-OpenClaw 在教學場景表現出色，推向真實生產——多用戶、高並發、長期運行——會依次撞上規模天花板、質量天花板、生態天花板。mem0 正是為了突破這三重天花板而生。
理解 mem0 之前必須先明確：mem0 替代的是哪些組件、哪些必須保留。短期記憶保留不動、長期記憶整體替代、System Prompt 第六層改造、前五層保留、Memory Write Guide 移除。錯誤地刪除 session_manager.py 會導致 Agent 在同一次會話內「失憶」。
| 組件 | 動作 | 理由 |
|---|---|---|
| session_manager.py | 保留不動 | mem0 不管理短期記憶 |
| MEMORY.md + indexer | 整體替代 | 存儲和檢索均由 mem0 接管 |
| prompt 第 6 層 | 改造 | 從讀文件改為接收 memory.search() |
| prompt 前 5 層 | 保留不動 | 與記憶無關的組件不受影響 |
| Memory Write Guide | 移除 | mem0 自動管理寫入 |
mem0 由 Taranjeet Singh 和 Deshraj Yadav 於 2023 年創立（前身 Embedchain），2025 年發表 arXiv:2504.19413，GitHub Stars 超 51.4K。核心創新是 LLM 裁判機制：提取階段過濾閒聊噪音、更新階段選擇 ADD/UPDATE/DELETE/NONE 四種操作。
每次 memory.add() 觸發 1-2 次 LLM 調用，延遲約 500-2000ms
| 操作 | 語義 | 觸發場景 |
|---|---|---|
| ADD | 新增 | 全新信息 |
| UPDATE | 合併更新 | 細微差異值得精煉 |
| DELETE | 刪除舊記憶 | 語義衝突 |
| NONE | 無操作 | 完全冗餘 |
與批處理式整理不同，mem0 的記憶是實時進化
history 表memory.history() 追蹤變更軌跡mem0 通過 user_id / agent_id / run_id 三個命名空間參數實現邏輯隔離——物理上共享同一個向量資料庫實例，這是需要特別澄清的常見誤區。向量存儲後端支援 12 種，默認 Qdrant 數據存於 /tmp/qdrant，容器重啟會被清空。
| 維度 | 生命週期 | 典型用途 |
|---|---|---|
| user_id | 永久（可手動刪除） | 用戶個人偏好 |
| agent_id | 與 Agent 生命週期綁定 | 不同 Agent 的專業知識域 |
| run_id | 會話結束可歸檔 | 單次對話的臨時上下文 |
三維任意組合，提供從粗粒度到細粒度的靈活隔離
| 類別 | 工具 |
|---|---|
| 零配置本地 | Qdrant（默認）/ FAISS |
| 自托管服務 | Chroma / Weaviate / Milvus |
| 全托管雲 | Pinecone / Zilliz Cloud |
| 圖資料庫（可選） | Neo4j / Memgraph |
生產陷阱：默認 Qdrant 存於 /tmp/qdrant，重啟後數據丟失——必須配置持久化路徑。
面對實際項目選型，需要清楚 mem0 在整個記憶框架生態中的位置。五框架橫向對比、已知局限與工程應對、LangChain Tool / AsyncMemory / 雙檢索三種集成模式、mini-OpenClaw 遷移 Before / After。
mem0（51.4K Stars）、Letta/MemGPT（21K）、Zep/Graphiti（24K）、Cognee（12K）、LangChain Checkpointer（會話狀態）。選型決策路徑：需要多用戶個性化+快速接入選 mem0；需要 OS 式內存管理選 Letta；需要時序推理選 Zep。
| 框架 | Stars | 定位 |
|---|---|---|
| mem0 | 51.4K | 個性化記憶層 |
| Letta/MemGPT | 21K | OS 式內存管理 |
| Zep/Graphiti | 24K | 時序知識圖譜 |
| Cognee | 12K | 深度知識圖譜 |
| LangChain Checkpointer | — | 會話狀態管理 |
客觀評估框架不僅要看優勢，更要看局限。add() 額外延遲、隱式連接弱、依賴 LLM 質量、圖模式需額外基礎設施、成本非零、開源版無原生 TTL——六局限都有對應的工程應對策略。
| 局限 | 工程應對 |
|---|---|
| add() 延遲 500-2000ms | asyncio.create_task() 異步化 |
| 隱式連接弱 | 深度跨輪場景結合全量上下文 |
| 依賴 LLM 質量 | 選 DeepSeek / gpt-4o-mini |
| 圖模式需 Neo4j | 僅在時序推理需求明確時啟用 |
| 成本非零 | 輕量模型提取 + 批次寫入 |
| 無原生 TTL | 定時清理任務或雲平台版 |
asyncio.create_task() 放入後台任務第一種模式用 @tool 裝飾器封裝為 Agent 工具；第二種模式用 asyncio.create_task() 不阻塞事件循環；第三種模式用 asyncio.gather() 並行執行 mem0 與 RAG——三種模式工程價值遞增。
| 模式 | 關鍵技術 | 典型場景 |
|---|---|---|
| LangChain Tool | @tool + create_agent() | PoC / 單 Agent |
| AsyncMemory | asyncio.create_task() | Web 服務不阻塞 |
| 雙檢索注入 | asyncio.gather() | 個 性 化 + 準 確 性 並 行 |
asyncio.gather() 並行執行，總耗時 = 較慢那個，而非兩者之和遷移前的數據流：MEMORY.md 模式需 LLM 主動標注容易遺漏；遷移後：memory.add() 對話後自動提取無需配合。變化只發生在兩個箭頭上——讀的來源和寫的去向，整體請求處理流程的結構完全不變。
| 階段 | Before | After |
|---|---|---|
| 讀的來源 | MEMORY.md / indexer.retrieve() | memory.search() |
| 寫的去向 | write_file 寫 MEMORY.md | memory.add() 入庫 |
整體請求處理流程的結構完全不變
| 維度 | MEMORY.md 模式 | mem0 模式 |
|---|---|---|
| 寫入方式 | LLM 主動標注易遺漏 20-30% | 對話後自動提取無需配合 |
| 衝突解決 | 離線批處理 / 事後整理 | 寫入時實時 UPDATE / 事中解決 |
| 檢索質量 | 全文注入有噪聲 | 條目級語義檢索精煉 |
| 可審計性 | 打開文件直接閱讀 | history() API 程序友好 |
第一輪「喜歡辣」觸發 ADD；第二輪「不能吃辣」執行 DELETE 舊的辣食偏好 + ADD 新的清淡偏好；第三輪「腸胃不好不能吃辣的」實際觸發 UPDATE 而非 NONE——LLM 裁判捕捉到「去掉最近」「了變的」的細微差異，視為有意義的精煉。
生產部署六要點 + Claude Code 五大記憶質量模式 + 三層升級路徑 + 四個進階方向。把前面九章的所有機制收束為可執行的工程紀律清單。
生產部署六要點速查清單：add() 異步化、/tmp 持久化、LLM 質量選型、圖模式條件啟用、成本控制、TTL 管理。在此基礎上借鑒 Claude Code 源碼驗證過的五個記憶質量模式，全部用 mem0 已有的 metadata/filters 機制落地。
| 序 | 要點 |
|---|---|
| 1 | add() 用 asyncio.create_task() 異步化 |
| 2 | /tmp/qdrant → 持久化路徑 |
| 3 | LLM 選 deepseek-chat / gpt-4o-mini |
| 4 | 圖模式僅在時序推理明確時啟用 |
| 5 | 成本控制：條件觸發 + 批次寫入 |
| 6 | TTL：開源版需手動清理任務 |
第一層升級：離線批處理 → 實時衝突解決；第二層升級：文件手動維護 → 框架自動管理；第三層升級：不需要更換框架，只需善用 mem0 已有的 metadata 機制。理解這張映射表，才能在選型時準確理解每個 API 背後在做什麼。
回顧整個學習旅程：課程開始時面對無狀態 LLM；完成短期記憶章節後擁有跨進程持久化、自動壓縮的短期記憶層；完成雙層記憶系統後擁有完整自研記憶系統；完成 mem0 章節後掌握了 LLM 裁判驅動的實時記憶演化。四個進階方向等著繼續探索。
agent_id 共享知識域，user_id 共享偏好history() API 構建面向終端用戶的「記憶管理面板」