OpenMemory 記憶策略：裝好之後，真正難的是決定什麼值得被記住

OpenMemory 裝好之後，我原本以為接下來的事情會很自然。MCP 已經接上了，AI 應該會自己開始用 OpenMemory，該記的時候記，該查的時候查，然後慢慢變得越來越懂我。

但用著用著，我很快就發現事情不是這樣。有時候它會記，有時候又完全不記；有時候我以為它應該去查之前的脈絡，它卻直接回我。這種不穩定感讓我開始懷疑：它到底是怎麼判斷要不要用 OpenMemory 的？

我後來乾脆直接問 AI。我的問題很簡單：你什麼時候會用 OpenMemory 記憶？什麼時候會查詢？你的判斷規則是什麼？

結果它的回答大意是：它不會自動有這套規則。對它來說，MCP 只是工作區裡多了一個可以呼叫的工具，描述上寫著可以記憶、可以查詢；至於什麼時候要用、值不值得用，還是它自己根據目前拿到的指令和規則來決定。

我那時候真的嚇了一跳。原來「工具已經裝好」和「AI 真的知道怎麼用這個工具」，中間差的不是一點點設定，而是一整套判斷邏輯。

這篇是 OpenMemory 系列的第三篇。前兩篇分別講了為什麼需要一層本地 AI 記憶，以及怎麼把 OpenMemory 跑起來並接到 Claude Code。這篇比較像後半場：當工具已經能用，接下來要怎麼設計一套真的符合自己 workflow 的記憶規則。

我以為 MCP 裝了，AI 就會自己使用 OpenMemory

我一開始其實有個很直覺的預設：只要 MCP 裝好，AI 應該就會自己理解 OpenMemory 是拿來做什麼的。至少在我看來，它都已經看到工具名稱、看到工具描述了，那應該多少知道什麼情況要記、什麼情況要查。

後來一路拆下去才發現，它提供的是能力，不是判斷。對我來說，比較接近的理解是：OpenMemory MCP 給你五個 function，但它不附帶「什麼時候用哪一個」的規則。

MCP function	能力
`add_memories`	新增記憶
`search_memory`	用語意搜尋記憶
`list_memories`	列出目前記憶
`delete_all_memories`	清空所有記憶
`delete_memory`	刪除單筆記憶

真正有意思的地方反而是它少了什麼。這五個 function 裡沒有 update_memory。也就是說，OpenMemory 並沒有把「舊記憶怎麼改寫、衝突怎麼處理」單獨做成一個你可以明確呼叫的操作。你拿到的是儲存、搜尋、列出、刪除的能力，至於判斷時機和策略，還是得自己設計。

這個落差對我很重要，因為它把問題從「我還缺哪個功能」改成兩個更根本的問題：我要怎麼把記憶策略講清楚？以及，這套規則到底要寫在哪裡，AI 才真的會照著做？

記憶策略要寫進 System Prompt

我跟 AI 繼續往下討論時，真正卡住的其實不是策略內容本身，而是策略要放哪裡。

一開始我也想過，這種規則是不是可以寫成 Skill。但後來越看越覺得不對，因為 Skill 跟 MCP tool description 很像，本質上都比較像是「這裡有個能力可以用」。它們會幫 AI 知道工具存在、知道大概能做什麼，但不保證 AI 會穩定把這條規則當成每次都要遵守的底層判斷。

如果你要定義的是「這個 AI 平常什麼時候該查 OpenMemory、什麼時候該寫入、什麼時候該改去查公開來源」，那這已經不是任務技巧，而是 workflow 層級的規則。這種規則要放進 System Prompt，直接進到模型每次工作的基礎 context 裡。

在 Claude Code 或 Codex 來說，具體位置就是：

1
~/.claude/CLAUDE.md
2
~/.codex/AGENTS.md

簡單說，這三者的關係比較像：

MCP / Skill：告訴 AI「你有哪些工具可以用」
System Prompt：告訴 AI「你平常應該怎麼判斷要不要用」

這也是我後來真正收斂下來的地方。OpenMemory 不是裝上去就會自己發生作用，你得先把記憶策略寫進 AI 每次都會讀到的那層規則裡，它才會變成穩定行為，而不是偶爾想到才用一下。

第一版策略：每個對話的第一個問題都先查

我最早的反應很典型：既然怕 AI 忘記，那就每個 session 一開始先查 memory。這做法有一個很強的心理安定感，因為你知道自己沒有漏掉背景。

而且老實說，這個版本沒有不好用。對一個剛把 OpenMemory 接起來的人來說，它甚至是很好的起點，因為規則夠硬，AI 不太會漏掉。

如果把它寫進 System Prompt，第一版大概會長這樣：

1
## Memory Query Rule v1
2

3
When the user's first substantive question arrives in a new session,
4
always call `search_memory`.
5

6
- Use the topic of that first question as the query
7
- Show whether OpenMemory is connected

這種寫法的好處是，OpenMemory 真的會被用起來，不會只是裝著安心。它也很適合剛開始建立記憶習慣的階段，因為你不用先教 AI 太多判斷。

第二版策略：描述條件，把判斷權交回給 AI

但實際用一陣子後，我發現第一版有點太硬了。有些問題天生就不需要查記憶。

例如使用者是在問一個現在式的外部問題，像「某個套件最新版本是什麼」、「某個指令是什麼意思」、「某個服務今天的狀態怎樣」。這些問題需要的是正確的公開來源，有時候是官方文件，有時候是上網查證，而不是把 OpenMemory 先翻一遍。

真正比較適合查 OpenMemory 的，通常是那種帶有「過去式」性質的問題。也就是這個問題的答案，可能跟我過去的偏好、之前做過的決策、某個專案的既有慣例有關。這時候去查 memory 才有意義。

所以第二版我做的不是取消搜尋，而是把搜尋的決定權交給 AI，但只給它一個很簡單的語意判斷：

1
這個問題需要的是過去脈絡，還是外部現況？
2

3
如果需要過去脈絡，就查 OpenMemory。
4
如果需要外部現況，就去找公開來源。
5
如果只是當下即可回答的小事，就直接回答。

如果把這個版本寫進 System Prompt，大概會長這樣：

1
## Memory Query Rule v2
2

3
Before answering, judge whether the question depends on:
4

5
1. past context, preferences, prior decisions, or project conventions
6
2. current public facts or official documentation
7
3. no extra lookup at all
8

9
If it depends on past context, call `search_memory`.
10
If it depends on current public facts, use web verification.
11
If neither is needed, answer directly.

這個調整的好處不只是在第一個問題。因為你給的是判斷規則，不是單次指令，所以後續問題也可以套用同一套邏輯。AI 可以根據眼前問題自己決定要不要查 memory，而不是只有開場那一次有規則，後面就靠運氣。

記越多會越聰明嗎？

我後來慢慢發現，OpenMemory 不是一個塞越多越聰明的地方。

完整對話通常不適合直接丟進去。因為對話裡會有試錯、推翻、過渡版本、臨時猜測，全部保存下來只會讓之後的搜尋結果變得很混。AI 找回來的不是結論，而是一團還沒收斂完的思路。

一次性的操作結果也常常不值得進去。今天某個 command 成功、某次 build 失敗、某個測試暫時過不了，這些比較像當下狀態，不一定是長期記憶。它們有些適合放在 session summary，有些根本不用留。

敏感資料更不用說。方便不等於合理，API key、token、私人資訊這些東西不該因為「AI 之後可能會用到」就變成長期記憶的一部分。

有些資訊不適合進 OpenMemory

我後來比較確定的一件事是：寫在 System Prompt 的東西，跟放進 OpenMemory 的東西，不是同一類。

像長期偏好，或是專案慣例，例如回覆用繁體中文、技術詞保留英文、這個 blog 用 Astro、套件安裝用 pnpm，這些比較像固定規則，應該寫在 CLAUDE.md / AGENTS.md，不是丟進 OpenMemory 等它之後自己查。

到這裡我才比較說得清楚：設計記憶策略，不是在決定「哪些東西很有價值」，而是在決定「哪些東西值得被未來重複依賴」。這兩者差很多。

釐清什麼事情值得記，記什麼進 OpenMemory

查詢時機決定了 memory 什麼時候會被看見，寫入準則則決定裡面到底放了什麼。這部分我後來問自己的，不是「這件事重不重要」，而是另一句比較實際的話：

這件事未來會不會影響 AI 怎麼幫我做判斷？

如果答案是會，它就有機會值得進 memory。

真正適合進 OpenMemory 的，反而是那些你們已經花過時間討論、比較、查證，最後得出來的判斷片段。

比如 AI 一次給了你好幾個方向，你們一路討論後，發現選項 C 跟選項 D 其實都不錯，雖然當下還沒定案，但你知道之後還會回來談。這時候直接叫 AI 把這兩個候選方向記起來，之後就有機會在別的討論裡被查回來。

又比如架構跟架構的比較、repo 跟 repo 的比較、Skill 跟 Skill 的比較。這種東西通常很花時間，因為你不是只看名字，而是會一路沙盤推演：差異在哪裡、取捨是什麼、最後為什麼選這套而不是那套。像「為什麼今天選 OpenMemory」這種結論，本身就很值得記，因為它是高成本討論後留下來的判斷。

某些關鍵決定也是。比如今天這個 bug 為什麼先這樣改、為什麼判斷成 known issue、或者這次只是先用一個 hot fix 快速解掉。這些東西如果只留在筆記裡，之後往往很難查；但如果留成 OpenMemory 的記憶片段，之後同類問題再出現時，就有機會先查回當時的判斷，再回頭對 source code 或完整紀錄確認。

還有一種是那種當下像靈光一閃，但你直覺知道未來可能會有用的想法。它可能還不成熟，還不值得變成正式文件，可是先留在 OpenMemory 裡，之後遇到相關情境時如果被查回來，就會變成一個重新展開探索的契機。

所以我現在比較把 OpenMemory 當成一種「高成本判斷的可搜尋快照」。不是所有重要的東西都放進去，而是那些之後很可能還想查回來、而且重新從頭推一遍會很貴的判斷片段，特別值得留下來。

後來我把記憶拆成三層，而不是全押在一個地方

當我把查詢時機和寫入準則都收斂一輪後，還有一個問題會冒出來：那完整脈絡到底要放哪裡？

我現在比較穩定的做法，是把記憶拆成三層來看：

層	放什麼	作用
`AGENTS.md` / `CLAUDE.md`	穩定規則、固定偏好、專案約定	每次開場就注入，適合高確定性內容
OpenMemory	可搜尋的判斷線索、決策摘要、踩坑紀錄、summary 重點片段	像快取層，先命中線索，再決定要不要回頭讀完整脈絡
Session Summary / 文件	完整討論過程、上下文、試錯脈絡	之後回頭讀，適合保留細節

這樣分之後，我對 OpenMemory 的期待就正常很多。它不是最上層規則，也不是最底層全文保存，它卡在中間，負責讓 AI 有機會在需要時想起正確線索。

所以三層的分工就很明確了。Session Summary 負責把你和 AI 討論過的內容整理成可回頭閱讀的脈絡總結；OpenMemory 則負責把那些之後可能反覆用到的重點片段再往上提一層，變成可搜尋的記憶快取。

這樣 AI 後續搜尋時，可以先命中當初的重點摘要，再決定接下來用這個片段就夠，還是要沿著這個片段回去找到那篇完整的 session summary，整篇讀回來繼續討論。對我來說，這樣的分層很實用，因為它把「快速想起來」和「完整重建脈絡」拆成了兩個不同成本的動作。

如果把三層全塞成同一種東西，最後通常都不好用。固定規則寫太多，AGENTS.md 會膨脹；完整脈絡全塞進 OpenMemory，搜尋品質會下降；什麼都只留在 session summary，AI 每次又想不起來。

使用者最後還是得扮演 context curator

這篇寫到最後，我反而覺得最關鍵的不是某一條規則本身，而是你願不願意承認自己得做取捨。

AI 可以幫忙整理、搜尋、壓縮，但它不會天然知道什麼對未來真的重要。那個判斷，現在還是比較像使用者的工作。你得像整理書桌一樣，決定哪些東西要一直放在手邊，哪些只要留檔，哪些看完就可以丟掉。

所以套件安裝好之後，真正的起點反而是這個問題：你的 AI，到底需要記住什麼，才會更像是在延續合作，而不是每次都重新認識你一次。

寫這篇時我才發現，MCP 裝上去不代表 AI 就會正確使用 MCP。對我來說，真正新鮮的反而是後面這一段：你得跟 AI 一起把記憶策略討論出來，再用自然語言把它寫成一份 AI 看得懂的規則。很多安裝教學會教你怎麼接上工具，但比較少一路講到這裡。

這件事也比我原本想的難，因為它不是在寫程式，而是在寫給 AI 讀的語意規則。你不能只靠自己的感覺寫一句「重要的就記下來」，因為真正要解釋這句話、執行這句話的不是你。後來我反而覺得，最好是直接跟 AI 來回測。你可以問它這樣寫會不會誤會，也可以另外開一個全新的對話，把這份策略丟給另一個沒參與過討論的 AI，拿幾個例子測它到底會查 OpenMemory、查公開來源，還是直接回答。這種來回打磨的感覺很有趣，像是第一次比較認真地在設計一個 AI 真的會照著走的工作習慣。