AI

Recall：讓 Claude Code 不再每次都從零開始的離線記憶工具

Monday

每次打開 Claude Code，你都得重新跟 AI 介紹一遍：「這個專案在做什麼、上次討論到哪、現在想繼續的是哪個功能…」這種「冷啟動」的摩擦幾乎是所有 Claude Code 重度使用者的日常痛點。raiyanyahya/recall 用一個非常有趣的工程思路解決了這個問題：不依賴任何外部 API，完全在本地用古典 NLP 算法把你的會話自動壓縮成可攜式摘要。

1. 專案背景與定位

作者：Raiyaan Yahya（個人開發者）
誕生時間：2026 年 6 月 19 日（本文撰寫時剛滿 3 天）
授權：MIT
語言：Python

Claude Code 本身有幾種記憶機制，但各有盲點：

  • CLAUDE.md：需要手動維護，記錄的是「怎麼做」的規則，而不是「做了什麼」的歷史
  • --continue / --resume：重新載入完整對話紀錄，Token 消耗大，且綁定單一機器
  • Context Compaction：只在當次會話內壓縮，不跨 session 持久化

Recall 定位在這些方案的空白地帶：自動捕捉每次會話的實際發生內容，並用本地算法無損壓縮成一份下次可直接讀取的摘要。整個過程零 API 呼叫、零額外費用。

2. 技術架構與核心設計

Recall 的技術選擇非常克制，卻非常精準。

2.1 Hooks 整合

Recall 利用 Claude Code 的生命週期 Hook 機制掛載兩個關鍵點：

Hook 時機 行為
SessionEnd / Stop 將本次對話新增的 turns（prompts、Claude 回覆、觸碰的檔案、執行的指令）增量追加到 .recall/history.md
SessionStart 讀取 context.md，請 Claude 確認是否從上次摘要繼續，並決定本次是否繼續記錄

這個設計非常聰明：捕捉是增量的（只寫入新 turns），避免重複寫入造成雜訊；恢復是輕量的（只讀 context.md，約 1–2K tokens）。

2.2 本地摘要算法：TF-IDF + TextRank

scripts/summarizer.py 是整個專案的技術核心，完全 vendored（不依賴外部套件）：

  1. TF-IDF 向量化：將 history.md 中的每個句子轉為詞頻-逆文件頻率向量
  2. Cosine Similarity 圖：計算所有句子對之間的相似度，建立加權圖
  3. TextRank（PageRank 迭代）：對這張圖跑 PageRank，評分最高的句子即為「最有代表性」的核心句
  4. Top-N 保序輸出：取評分最高的 N 個句子，按原始順序排列，確保可讀性

輸出的 context.md 除了 TextRank 摘要外，還附加從 transcript 和 Git 直接抽取的確定性資訊：目標（第一個 prompt）、觸碰的檔案、執行的指令、git diff --stat、以及「上次停在哪裡」。

效能設計：如果環境中有 numpy，自動用矩陣運算加速；沒有則退回純 Python 實現。結果完全相同，numpy 只是加速器而非硬依賴。

2.3 資安設計

redact: true（預設開啟）會對 history.md 和 context.md 進行最佳努力的機密抹除，過濾常見的 API key、token、.env 賦值等模式。任何時候都不會有資料離開本機，這是 Recall 與大多數「AI 記憶」工具最根本的區別。

3. 社群熱度與生態採用

指標 數值（2026-06-22）
Stars 103
Forks 3
誕生天數 3 天
授權 MIT

3 天 103 stars 的增速在 Claude Code 外掛生態中算相當亮眼。README 定位清晰、對照表完整（與 CLAUDE.md、--continue、Context Compaction 的比較一目瞭然），這種「教育型 README」對社群傳播有明顯加乘效果。

目前沒有看到大型組織的公開採用案例，但其 MIT 授權和純本地設計對企業合規環境來說是加分項——不需要審核資料流向，直接可在內網使用。

4. 局限性與潛在風險

4.1 摘要品質上限

TextRank 是抽取式摘要（extractive）：從原文挑句子，不改寫、不推理。對話記錄往往包含大量上下文依賴的短句（「好，繼續」、「這樣試試看」），這類句子 TF-IDF 權重低，可能被過濾，但有時候它們後面跟著的動作才是最重要的。

與生成式摘要（如 Claude 本身）相比，TextRank 無法做跨句歸納或抽象化，摘要品質在對話主題跳躍頻繁時會明顯下降。

4.2 redact 的覆蓋邊界

正規表達式抹除是「盡力而為」，不保證 100% 覆蓋。特殊格式的 token（例如某些廠商用不含常見前綴的 UUID 格式作為 API key）可能不在抹除規則內。對於敏感度極高的專案，建議在 output_dir 層級另加存取控制。

4.3 單一機器綁定問題尚未解決

history.md 和 context.md 存在專案本地目錄，如果你在多台機器上交替使用 Claude Code，需要自行透過 Git 同步這些檔案（.recall/ 預設不在 .gitignore，需手動決定是否 commit）。

4.4 大型 session 的 max_input_chars 截斷

預設 max_input_chars 為 200,000 字符，超過部分從最舊的記錄截斷。長期重度使用後，遠古的決策記錄可能靜默消失，建議定期備份 history.md。

5. 應用價值與適用場景

最適合的團隊

  • 訂閱制 Claude Code 使用者：零額外 API 費用，用本地算法換記憶
  • 注重資料隱私的企業：程式碼、架構決策、對話記錄一律不出本機
  • 長期迭代型專案：橫跨數週甚至數月的開發，最能體會冷啟動的痛苦
  • 離線或內網環境：不需要任何網路連線，符合隔離網路的合規需求

具體使用流程

安裝後（無需 pip install），工作中會自動記錄。結束前執行 /recall:save 讓本地跑 TextRank 產出 context.md；下次開啟新 session 時執行 /recall:show 看上次留下的摘要，即可精準接續工作。

與其他工具的比較

工具 記憶方式 費用 隱私
Recall 本地 TextRank 免費 完全本地
mem0 外部向量資料庫 有 API 費用 資料上雲
MemGPT LLM 輔助記憶管理 有 API 費用 資料上雲
Claude Code --resume 重播完整對話 消耗大量 tokens 本地

Monday 的觀點與架構建議

最值得學習的設計決策

Recall 最聰明的地方在於「用對的工具做對的事」：記憶的捕捉與壓縮不需要 LLM，古典 NLP 的 TextRank 已經夠用，且是可預期的確定性輸出。把 LLM 留給真正需要推理的地方（下次 session 的工作本身），而不是用昂貴的 API 呼叫來做可以本地化的事。這種「能不用 AI 就不用 AI」的克制哲學，是目前 AI 工具生態中非常稀缺的工程素養。

生產環境採用時的架構注意事項

  1. .recall/ 的 Git 策略要提前決定：如果 history.md 包含程式碼片段，commit 進 repo 會影響 git blame 的可讀性；建議把 .recall/ 加入 .gitignore，另開一個 private 分支或獨立 repo 同步
  2. 多人協作場景慎用：Recall 設計是單人、單機使用，多人共用同一個 .recall/ 目錄會產生記錄混亂
  3. redact: true 必開：即使你「認為」沒有機密，習慣性開啟是好的防禦姿態
  4. 搭配 CLAUDE.md 使用效果最佳：CLAUDE.md 管理「工作規則」，Recall 管理「工作歷史」，兩者互補而非替代

對 AI 應用開發方向的意義

Recall 代表了一個值得關注的趨勢：AI 工具的記憶層不一定要是 AI。當 LLM API 費用仍是大多數開發者的顯著成本時，用古典算法在本地處理「不需要理解的任務」（記錄、壓縮、去重），把 LLM 的 context window 留給真正需要推理的輸入，是一種兼顧成本與隱私的務實架構選擇。

隨著 Claude Code 外掛生態逐漸成熟，這類「本地優先、AI 輔助」的工具會越來越多。Recall 是其中設計最簡潔、最符合 Unix 哲學的早期代表。

參考來源