ENTRY 003
記憶與上下文機制：mokagi 現在怎麼記，跟 Supermemory 差在哪
一句話總結：mokagi 的記憶＝三套庫（ChromaDB 向量 2.8G ＋ SQLite 對話 1.1G ＋
soul/*.md 知識庫），
由 tools/memory.py 一個檔案統包。「回想」是自動的（每輪對話自動注入 top-N 記憶），
但「記住」是被動的（只有 /memory remember 或 LLM 主動呼叫才寫），
而且寫入沒有相似度檢查、沒有衰減、沒有遺忘——這正是對比 Supermemory 後最該補的四件事。
① 資料落地：三個庫、四種「記憶」
| 類型 | 存放位置 | 實作（檔案 → 行號） | 寫入時機 | 現況 |
|---|---|---|---|---|
| 長期記憶（facts） | ChromaDB {agent}_user_memory |
tools/memory.py remember／recall（_col() L353） |
手動：/memory remember、LLM 主動呼叫 |
⚠️ 無相似度檢查、無 TTL，多數 Agent 僅數十條 |
| 知識庫 KB | ChromaDB {agent}_room |
get_kb_collection() L328、rebuild_knowledge_base() L464 |
手動：/memory rebuild_kb |
✅ soul/*.md 依標題切 ≤500 字（chunk_markdown_by_headings() L405） |
| 對話全文 | ~/.mok/.memory/conversation_history.db（WAL）＋ chat_history.db |
core/history_manager.py |
每輪自動 | ✅ 目前 1.1 GB |
| 對話向量 | ChromaDB {agent}_conversation |
index_conversation() L632、semantic_search_conversation() L668 |
每輪自動（user＋assistant 成對寫入） | ⚠️ 只增不減，是 2.8 GB 的主要來源 |
Embedding 全部走本地 all-MiniLM-L6-v2（memory.py L319，SentenceTransformer），
不經任何外部 API；每個 Agent 一組 collection 做隔離，名稱先經 sanitize_name_for_chromadb() L249 清洗，
避免中文／特殊字元打爛 ChromaDB 的 collection 名。
② 一次對話的實際資料流
使用者輸入
└─ core/mokagi.py process_message()
├─ recall_memory(user_id, text, MOK_MEMORY_RECALL_COUNT=3, include_kb=True)
│ ← mokagi.py L3040（呼叫）、L2513（讀設定，預設 3 條）
├─ 取回的「長期記憶 + KB 片段」塞進 system context
├─ LLM 回覆
└─ index_conversation() 寫入對話向量 + SQLite ← memory.py L632
（另外：/dream 會讀 logs + soul 沉澱 EXP.md，屬「反思」層，需該 Agent 開 MOK_dream_EXP=1）
關鍵落差：「回想」是自動的，「記住」卻是被動的。使用者若沒說「記住」，
這輪講的重要事實就只進了對話向量，不會變成能精準命中的 facts。
這正是命中率與精準度會輸給「每輪自動抽取」架構的根因。
③ 跟 Supermemory 的逐項對照
| 維度 | Supermemory（雲端 SaaS 記憶引擎） | mokagi（現在） | 勝負 |
|---|---|---|---|
| 事實抽取 | 每輪自動抽取，無需使用者開口 | 被動：要 /memory remember 或 LLM 主動記 | ❌ 輸 |
| 衝突消解 | 新舊衝突自動以新版覆蓋 | 無：一律 add 新增，同一件事會累積多筆矛盾 | ❌ 輸 |
| 衰減／遺忘 | 有時效性自動遺忘 | 無：只增不減，向量庫只會愈養愈肥（現 2.8 GB） | ❌ 輸 |
| 使用者畫像 | profile 分 static／dynamic 自動維護 | soul/user.md 單段、靠人（或 Agent）手寫 | ❌ 輸 |
| 檢索 | 混合檢索（RAG ＋ memory，hybrid 模式） | 向量檢索 ＋ 關鍵詞／聯想詞擴充；KB 與記憶是兩條線 | △ 小輸 |
| 多模態 | PDF／圖片 OCR／影片轉寫／程式碼 AST 切分 | 無（只有純文字 .md 切塊） | ❌ 輸 |
| 外部連接器 | Drive／Gmail／Notion／OneDrive／GitHub ＋ webhook 即時同步 | 無；要吃資料得自己丟檔重建 KB | ❌ 輸 |
| 隔離設計 | containerTag 容器隔離 | 每 Agent 一組 collection（天然多租戶） | ✅ 平手略勝 |
| 部署／資料主權 | 雲端 SaaS，資料要上傳第三方、需聯網、可能有費用 | 全部本地：資料在自己機器、離線可用、零 API 成本 | ✅ 大勝 |
| 可改／可駭 | 閉源 SaaS，行為改不動（只能等官方） | 原始碼全開，memory.py 想改就改 | ✅ 大勝 |
| 與人設整合 | 無此概念 | 記憶 ↔ soul/*.md ↔ /dream 反思 ↔ /job 任務同一套生態 | ✅ 大勝 |
| Benchmark | 宣稱 LongMemEval 81.6% 第一、LoCoMo／ConvoMem 第一 | 未做標準化評測，無法直接對比（建議自行用 MemoryBench 跑一輪） | ❓ 未知 |
④ 結論
| 問題 | 答案 |
|---|---|
| 哪個「更好」？ | 看你要什麼。要「記憶自動化程度」＝Supermemory 明顯較強；要「資料主權、零成本、可自由改造、能綁人設與反思」＝mokagi 完勝。 |
| Supermemory 值不值得換？ | 不建議整套換。它的強項是四個機制（自動抽取／衝突消解／遺忘／畫像），把這四個機制抄進自己的 memory.py，比把資料搬到別人伺服器划算得多。 |
| mokagi 的殺手鐧 | /dream（EXP 反思沉澱）＋ soul/ 人設＋ /job 任務——Supermemory 完全沒有。這是「能長期養出人格」的關鍵。 |
| 最該先修的痛點 | 2.8 GB 裡有大量陳舊向量：對話向量只增不減，久了檢索會被老對話稀釋，成本也往上跑。 |
⑤ 五項升級藍圖（現況：⏳ 尚未實作）
| # | 項目 | 作法 | 下手點 | 風險 |
|---|---|---|---|---|
| 1 | 自動抽取 facts | 每輪對話結束後用小模型抽 1～3 條 facts，寫入 {agent}_user_memory，取代被動 remember | mokagi.py 回覆送出後（L3030 之後）＋ 新增 memory.extract_facts() | 中：多一次 LLM 呼叫（成本／延遲），要防幻覺寫入 |
| 2 | 衝突消解 | 寫入前先查相似記憶，相似度 > 0.85 就 update 而非 add | memory.py remember 分支（約 L1200～L1230）、相似查詢參考 recall_memory() L569 | 低：只動寫入路徑，可掛開關 MOK_MEM_DEDUP=1 |
| 3 | 衰減／遺忘 | 記憶加 last_access ＋ decay 分數；排程清理陳舊向量 | memory.py metadata 寫入處 ＋ 新增 sweep 腳本掛 /cron | 高：涉及刪除向量，務必先備份且預設只標記不刪 |
| 4 | profile 雙段化 | soul/user.md 拆成「static 長期事實／dynamic 近期動態」兩段自動維護 | soul/user.md ＋ get_system_context()（mokagi.py L248） | 中：改到 system context 組裝，需確認各入口載入清單 |
| 5 | 開啟 dream | 讓「mokagi說明」也能跑 EXP 反思（目前未啟用） | Agent 設定 MOK_dream_EXP=1 | 低：純設定；目前已啟用者＝凜、備、ig小編、yt女、主播樣等 |
⑥ 真要動手時的安全守則
- 先備份：
/backup run（含.memory/、.chroma_data/），改壞了才有回頭路。 - 用開關灰度：每項改造都掛一個 env 旗標（如
MOK_MEM_DEDUP），先在單一 Agent 開，觀察一週再全體開。 - 只標記、不直接刪：衰減／遺忘第一版只寫
decay_score與last_access，清理動作人工確認後再跑。
※ 本條目為 2026-09-22 對比分析之結論彙整（來源：Supermemory README.zh-CN.md 與 mokagi 現行程式碼實測）。
程式碼改造尚未執行；實作完成後請回來把⑤的狀態由 ⏳ 改為 ✅ 並補上實測數據。