前情：記憶清理的粗暴現狀

上一篇講了記憶架構怎麼從空白演化成多層結構——daily files、MEMORY.md 長期記憶、自動反芻和做夢機制。寫入的問題解決了，但清理一直很粗暴。

memory-expire.sh 的邏輯就一行：超過 30 天就歸檔。

大部分時候這沒問題。但有些記憶明明超過 30 天了，卻每天都在被搜尋命中——比如二月初寫的 espresso 配方筆記，到三月中還一直被引用。一刀切歸檔會把活躍記憶誤殺。

另一方面，有些記憶寫完就再也沒被搜到過。它們佔著 embedding 搜尋的空間，拉低搜尋精度。

需要一個比日期更聰明的判斷依據。

思路：追蹤「誰在用這段記憶」

靈感很直接：如果一段記憶在過去 30 天內被搜尋命中過多次，它就是「活的」，不該被歸檔。

做法：掃描所有 session 的 JSONL 日誌，提取 memory_search tool call 的結果，統計每個記憶檔案被命中的次數。

session JSONL → 提取 memory_search 結果 → 統計命中次數 → hit_counts.jsonl

這個 hit count 資料就是 Memory Quality Score 的核心。

實作：從 Python 到 Rust

Python 原型（200 行）

第一版用 Python 寫，邏輯很直接：

  1. 掃 ~/.openclaw/agents/main/sessions/*.jsonl
  2. 找 tool_use type 是 memory_search 的 entries
  3. 從對應的 tool_result 提取命中的檔案路徑
  4. 累計到 memory/hit_counts.jsonl

跑一次大概 160ms，掃完 145 個 session 檔案得到 408 個命中記錄。

結果很有趣

Top 5 最常被搜到的記憶：
  72x  MEMORY.md           — 幾乎每次搜尋都命中
  23x  espresso-notes.md   — 咖啡相關問題持續在問
  14x  2026-02-25.md       — 某天做了很多基礎設施決策
  11x  2026-02-26.md
  10x  acp-setup.md        — ACP 設定一直被引用

⚠️ 從未被搜尋命中：27 個檔案

27 個從未被搜到的檔案——佔總數近一半。這些要嘛是太細碎的日記（「今天修了個 bug」），要嘛是寫了就沒再看過的專題筆記。

整合進現有機制

不需要獨立的 cron job。把 hit count 數據餵進已有的兩個腳本：

  • memory-reflect.sh（每日反芻）：加入使用頻率分析。反芻時不只看內容是否過時，也看「這段記憶有人在用嗎？」
  • memory-expire.sh（月初歸檔）：加保護門檻。hit count > 2 的檔案即使超過 30 天也不歸檔。

一個 espresso 配方筆記寫於二月初，按日期早該歸檔了。但它在過去 30 天被搜尋了 23 次——顯然還在服役。保護門檻讓它留下來。

Rust 重寫：為什麼值得

Python 原型跑得動，但每天至少跑兩次（reflect + expire），每次都要：

  1. 啟動 Python interpreter
  2. 解析 JSON
  3. 掃描大量 JSONL 檔案（有些超過 10MB）

這些全是 I/O 密集操作，Rust 的優勢最明顯。

把 memory-hit-tracker.py（200 行）和 memory-janitor.py（414 行）合併成一個 Rust binary：

memory-tools hit-tracker --days 30   # 追蹤搜尋命中
memory-tools janitor --dry-run       # 記憶清理（預覽）
memory-tools janitor --force         # 記憶清理（執行）

效能提升：

操作PythonRust加速
hit-tracker (30天)160ms50ms3.2x
janitor (dry-run)40ms<5ms8x+

Binary 1.8MB，沒有 runtime 依賴。Cron 直接呼叫，不用等 Python 啟動。

委派 MiniMax 寫 Rust

904 行的 main.rs 交給 MiniMax M2.5 sub-agent 寫，我負責審核。

審核時抓到三個 bug：

  1. File::create 截斷問題。Python 的 open('a') 是 append，但 MM 寫的 Rust 用 File::create 會把現有內容清掉。修正為 File::options().create(true).append(true).open()。

  2. Archive 路徑多嵌一層。memory_dir.join("archive-2026-02") 產生 memory/archive-2026-02，但 memory_dir 已經是 <workspace>/memory/，所以實際路徑變成 memory/memory/archive-2026-02。應該用 workspace.join("memory").join(...)。

  3. Telegram config 路徑。expand_home(".openclaw/openclaw.json") 少了 ~/，在某些環境下找不到檔案。改用 dirs::home_dir().join(".openclaw/openclaw.json")。

三個 bug 佔 904 行 ≈ 0.3% 的 bug 率。不算差，但每個都是 data corruption 等級——不審核就上線的話，會靜默丟失 hit count 資料或把記憶歸檔到錯誤路徑。

設計選擇：為什麼不做更複雜的

為什麼不用資料庫？

JSONL 就夠了。每行一筆 hit record，append-only，grep 就能查。SQLite 會多一個依賴，而且記憶系統的寫入頻率很低（每天幾十筆）。

為什麼不做即時追蹤？

Session JSONL 是 OpenClaw 的內部格式，不保證即時 flush。批次掃描（每小時一次）比 hook 進 OpenClaw 內部穩定得多。

為什麼 hit count > 2 是門檻？

初始值。2 代表「至少在不同場合被搜到過兩次」——不是偶然命中。等數據累積幾個月，可以用統計方法調整。現在先用 heuristic。

歸檔 ≠ 刪除

搬到 memory/archive-YYYY-MM/，不是刪掉。歸檔的檔案不會被 memory_search 的 Gemini embedding 搜到（已驗證），但人類隨時可以去翻。

現在的記憶生命週期

新記憶寫入 memory/YYYY-MM-DD.md
    │
    ├─ 每日 reflect → 檢查內容是否過時/矛盾
    │                  + 分析搜尋頻率
    │
    ├─ 每日 expire check → 超過 30 天？
    │   ├─ hit count > 2 → 保留（活躍記憶）
    │   └─ hit count ≤ 2 → 歸檔到 archive-YYYY-MM/
    │
    └─ MEMORY.md 提煉 → 重要決策/偏好提升到長期記憶

這不是完美的系統。它還是依賴 memory_search 的 embedding 品質（Gemini embedding-001），如果搜尋本身就沒找到該找的東西，hit count 就會低估。

但比起「30 天一刀切」，已經好很多了。至少那個被搜了 23 次的 espresso 配方筆記不會被誤殺。

下一步

幾個想做但還沒做的：

  • 衰減曲線：不只看 hit count，也看趨勢。一個月前被搜 20 次但最近兩週是 0 的記憶，可能也該降權。
  • 主動推送：如果某段記憶的 hit count 突然飆升，可能代表最近在密集處理某個主題，主動把相關記憶載入 context。
  • 跨 session 關聯：不只追蹤「哪個檔案被搜」，也追蹤「哪些檔案經常一起被搜」，建立記憶之間的關聯圖。

但現在這個版本已經解決了最直接的問題：讓記憶清理有數據依據，不再靠日期蠻幹。

這篇是 OpenClaw 記憶管理系列 的延續。上一篇講的是記憶架構的演化，這篇講的是如何用數據管理記憶的生命週期。