AI 的記憶不是儲存，是該忘什麼 - 從 cognitive-ai-memory 看 RAG 的下一站

AI

你跟 AI 講過你不喝咖啡。下個 session 它又問你要不要來杯咖啡。

這不是 LLM 變笨，是它根本沒有「記憶」。每次對話都是冷啟動，重新從零認識你一次。業界主流的解法是把所有對話丟進向量資料庫，下次再召回。但這條路走了三年，越來越多團隊發現一件事：所有記憶平權、token 越疊越貴、召回反而越來越糟。

問題其實不是「AI 記不住」，是「AI 不會遺忘」。

為什麼向量資料庫不是 AI 記憶終局

向量資料庫沒有「重要性」這個概念。

你三個月前提了一次「早餐想吃酪梨吐司」，跟你每天在用的技術 stack「Next.js + Postgres + Vercel」，在向量空間裡是同一個等級的存在。召回時靠的是 cosine similarity，但**「相似」不等於「重要」**。

結果就是 context window 越塞越大、token 成本飆、agent 反而被無關記憶淹沒。問題不是腦容量不夠，是雜訊太多。

人類的 working memory 也只能記 7 ± 2 個東西，但我們不會卡住，因為大腦有一套遺忘機制：重要的留下、不重要的衰減、過期的清掉。這正是現在 AI 記憶層缺的那塊拼圖。

cognitive-ai-memory 在做的事

Cognitive-ai-memory把人類的艾賓浩斯遺忘曲線寫進 AI 記憶層。

每個記憶有一個 strength 值。三件事決定它衰減多快：

  1. 重要性（importance）：被標記為高重要性的記憶衰減慢
  2. 召回頻率（recall count）：常被叫出來的記憶衰減慢
  3. 時間（age）：放越久衰減越多

衰減公式長這樣：

effective_λ = base_λ × (1 - importance × 0.8)

一句話翻譯：重要的衰減慢，不重要的快速消失。當 strength 衰減到 0.05 以下，記憶會自動 prune 掉。

這不只是個漂亮的 idea，數字也站得住腳。在 LoCoMo-10 benchmark 上，cognitive-ai-memory 跑出 Recall@5 = 59%，同樣 benchmark 上 Zep Cloud 是 28%。

關鍵差別：它讓 AI 「忘掉該忘的」，而不是繼續比誰能「記住更多」。

從機制到 production：為什麼用 MCP

純 memory 演算法不等於可以 ship 的系統。一套記憶層要能進 production，至少要能做到三件事：

  • 讓 agent 自己判斷「這件事該記嗎」
  • 讓 agent 在對話中主動 recall 過去的記憶
  • 讓 agent 修正自己過去記錯的東西

cognitive-ai-memory 的做法是把這三件事暴露成三個 MCP tool：

Tool用途
store_memoryAgent 判斷某段對話值得記下來時主動呼叫
recall_memoryAgent 需要過去資訊時自己撈回來
update_memoryAgent 發現舊記憶錯了或過期，主動修正

為什麼用 MCP，不是 application-level API？因為 MCP 把「決定要不要用」的權力留給 model 自己。工程師不需要預先寫死「只要使用者提到工作就 store」這類規則，agent 看上下文自己判斷就好。

這跟 Anthropic 最近發的「Building agents that reach production systems with MCP」走的是同一條路：MCP 是 agent 接 production 系統的標準介面，記憶層當然也是其中之一。Memory 不是某個 framework 的內建模組，而是一個獨立的 production system，透過 MCP 暴露給任何 agent 用。

接進你的 Claude Code workflow

裝起來其實只要兩步。

Step 1 - 安裝 cognitive-ai-memory：

pip install cognitive-ai-memory

Step 2 - 加進 Claude Desktop 的 MCP config：

{
  "mcpServers": {
    "memory": {
      "command": "cognitive-memory-mcp",
      "env": {
        "MEMORY_DB_PATH": "~/.claude/memory.db"
      }
    }
  }
}

然後在你的 CLAUDE.md 加一段，告訴 Claude 三個 tool 怎麼用：

你有三個記憶工具：store_memory、recall_memory、update_memory。

- 使用者提到偏好、決策、長期事實時，主動 store_memory
- 開始新任務前，先 recall_memory 找相關脈絡
- 發現過去記錯時，主動 update_memory 修正

實際用起來會像這樣：你在某個 codebase 跟 Claude 講過命名 convention 是 camelCase，下次新 session 它會自己 recall 出來，不需要你重講。重要的東西它記得久，臨時雜訊它幾天就忘掉。

這條跟我前陣子寫的 給 MCP Server 加上 OAuth 剛好接得起來：OAuth 處理「agent 怎麼安全進到 production 系統」、memory 處理「agent 進去之後怎麼記住該記的」。兩個都是 MCP 在 production 上的基本元件，缺一個都不完整。

MCP + Memory 是 2026 的新分水嶺

LLM 賽道從「誰最強」轉成「誰最會 routing」。記憶層也一樣，從「誰能存最多」轉成「誰能忘最對」。

對正在做 AI 整合的團隊，三件事可以從這週開始：

  1. 不要再把所有對話無腦丟進 vector DB。先想清楚什麼該記、什麼是雜訊
  2. 把記憶設計成 first-class object。跟資料庫 schema 一樣 review，而不是順手塞進去的副作用
  3. 用 MCP 暴露記憶操作。讓 agent 自己決定 store / recall / update，不要寫死規則

LLM 這幾年在比參數量、比 context window 大小，但真正讓 AI 能做事的 missing piece，其實是有效率的遺忘。

如果你的團隊正在做 LLM 整合，歡迎找我聊聊。

#MCP #AI #RAG #Memory #LLM