現在的 AI 工具，多半記得我大概是誰、偏好什麼語氣。但一開新的對話視窗，它們往往不記得更實際的細節：這個專案為什麼選 pnpm、上次排除過什麼方案、某個規則是在什麼情況下訂下來的。

一個做法是把對話保存下來作為自己的知識筆記。完整脈絡留在自己手上，這件事很重要；但它主要解決了保存，還沒有解決搜尋。需要接續舊脈絡時，仍要靠人找出那份筆記，再手動貼進新的對話視窗。

這個方法已經很好用，只是我還想往前一步：能不能有一層更自動化的能力，讓 AI 在需要時自己查找跨 session 的長期記憶？於是我先從 GitHub 上的社群方案開始調查。

第一輪：GitHub 上的長期記憶方案

這是我當時拿來比較的候選清單，後來再加上 claude-mem。星數截至 2026-07-13；它只代表社群關注度，不是功能勝負。表格中的能力保留我當時的實際比較情境，產品之後可能已經更新。

方案本地雲端接到 AI 的方式寫入方式搜尋方式
OpenMemory / Mem0
60,718 ⭐		✅✅MCP / APIAI 依規則存取語意搜尋
OMEGA
184 ⭐		✅—MCP + hooks自動與主動皆可語意 + 關鍵字
Supermemory
28,347 ⭐		✅✅Plugin / MCP / API自動萃取Hybrid search
Zep / Graphiti
28,663 ⭐		✅✅MCP / SDK應用自行整合圖譜 + 語意
Letta
23,771 ⭐		✅✅SDK / AgentAgent 維護 stateAgent memory search
claude-mem
87,028 ⭐		✅—Plugin + hooksHooks 自動記錄關鍵字 + 語意

這一輪裡，OpenMemory 最接近我想要的樣子：資料可以自己部署、不同 LLM 能透過 MCP 或 API 共用，還有 UI 可以回頭檢查記憶。它不是只把對話記錄下來，而是先萃取出偏好、決策和限制，再讓 AI 用語意搜尋找回來。

claude-mem 是後來才加入的強勁候選。它不是單純的 keyword tool，而是用 hooks 自動記錄工具操作、壓縮成 observation，並結合 keyword 和向量檢索，在新 session 注入相關脈絡。

但我最後沒有選它，正是因為它像一台 AI 協作的行車記錄器：每次工具操作都自動錄下來，再替你壓縮。這對不想管理記憶的人很方便；對我來說，記憶應該是可以策展的。哪些偏好、決策和限制值得留下，哪些短暫嘗試不該變成長期背景，應該可以由自己的規則控制。

第二輪：給人看的筆記，還是給 AI 找的記憶？

選出 OpenMemory 之後，我才想到另一類關鍵產品：筆記工具。查資料時看到 Notion 3.0，也重新認識了被很多人當作「第二大腦」的 Obsidian。

它們解的不是同一件事。把三者放在一起後，「給人看」和「給 AI 找」的差別才變得很明顯。

NotionObsidianOpenMemory
內容格式結構化頁面、資料庫Markdown 原文與連結短記憶、metadata 與語意索引
主要維護者使用者與團隊使用者AI 協助萃取，使用者決定規則
搜尋方式頁面／資料庫搜尋與 AI 功能關鍵字、檔案與連結；可透過 MCP 交給 AI 讀取語意搜尋，可再搭配 metadata 篩選
資料位置雲端本地本地
主要給誰用人為主，AI 可讀人與 AI 都可讀AI 優先，人透過 UI 審查

Notion 適合共享的需求、spec 與團隊文件；資料在雲端，也需要人持續整理。Obsidian 是很單純的本機 Markdown 筆記工具，能透過 MCP 變成 AI 可讀的知識庫；沒有額外建立向量索引時，它的核心搜尋仍是關鍵字搜尋。

OpenMemory 則應該只放能替未來 AI 指路的記憶，例如「這個 repo 用 pnpm」或「這個決策已經比較過」。完整對話、設計理由和引用來源仍留在 Notion 或 Obsidian。它們沒有互相取代：筆記保存全文，memory layer 負責讓 AI 在恰當的時候找回線索。

向量搜尋是什麼？

可以把它想成一種比較會聽懂意思的搜尋。

如果你對電腦說：「我想找有輪子、會跑的東西！」它不會只去找剛好寫著「車車」的玩具。它會去找有輪子的角落，把小汽車、消防車和波力一起找出來。

同樣地，你說「想找會汪汪叫的朋友」，它不只看有沒有出現「汪汪」這兩個字，也知道你大概是在找「小狗」。

電腦實際怎麼做到？

向量搜尋不只比對一模一樣的字，而是把文字轉成一串代表意思的數字，這串數字叫做 embedding。你可以把它想成內容在一張巨大地圖上的座標：意思越接近，座標距離通常越近。

所以搜尋「腳踏車」時，傳統搜尋主要找出真的寫了「腳踏車」的文章；向量搜尋則可能連「單車」、「自行車」或 bicycle 都一起找回來。

放回這篇的情境也一樣。就算我記憶裡寫的是「這個 blog 使用 Astro 架設」，之後問 AI「我的 blog 套件叫什麼？」，它也有機會找回這條規則，並回答：「Astro」。

不過這不是魔法翻譯。結果仍會受 embedding model、資料品質與查詢方式影響；它找回的是「看起來意思接近」的內容，最後仍要由人或 AI 判斷是否真的適用。

這就是我想體驗的地方。OpenMemory 不只把一堆文字存起來，而是先做語意解析，再把適合留下來的記憶送進可查詢的索引。下一篇會把本地自架與 MCP 串接的過程拆開來寫。

最後為什麼是 OpenMemory

Mem0 有兩條路：想快速開始可以用 hosted 的 Platform；想自己掌握資料和部署，則可以走 Open Source / self-hosted。這篇選後者，因為我需要的是不同 AI 工具可以共用、也能自己審查的基礎設施。

OpenMemory 的 UI 是很實際的加分項。記憶寫進去之後，不會變成摸不到的黑盒子；我可以看到它留下了什麼，必要時刪掉或調整策略。部署在本機也不等於所有成本都消失：LLM 和 embedding 用哪個 provider、是否要出網、成本怎麼算，都還是部署者的選擇。

在我當時的需求裡，這是最好的平衡：它不像筆記工具一樣要求我每次手動餵背景，也不像行車記錄器一樣先把所有東西錄下來再說。它是一層能跨 session、跨 LLM 共用的記憶服務，而完整脈絡仍留在我看得懂、找得到的文件裡。

真正麻煩的從來不是 AI 忘了我的名字，而是它忘了我們一起做過的判斷。把這些判斷留成一層可查的 memory，下一次對話才比較像接著做，而不是再辦一次 onboarding。