cognee 和 codebase-memory-mcp 是競爭對手嗎？

不是。cognee 是通用 AI agent 記憶引擎（記對話、使用者偏好、文件知識），codebase-memory-mcp 是專為 AI coding agent 設計的程式碼結構記憶（函數呼叫、依賴關係、架構分析）。兩個工具解決不同問題，可以同時使用。

codebase-memory-mcp 會把我的程式碼上傳到外部服務嗎？

不會。工具完全本地執行，README 明確承諾零遙測，代碼、查詢、環境資訊都不離開本機，且有 SLSA Level 3 供應鏈安全認證。

cognee 和 Mem0 哪個比較好入手？

Mem0 社群更大（48k+ stars vs cognee 26k），遇到問題的資源更多，入門門檻相對較低。cognee 的優勢是圖功能全 tier 開放（Mem0 的圖功能需 $249/月 Pro），且投資背景（OpenAI co-founder 參投）代表更強的生產可信度。

codebase-memory-mcp 的 99% token 節省是真實的嗎？

在「高頻結構查詢、多次使用索引」的場景下成立（Rex 實測也驗證了同數量級）。但首次安裝有 256 MB binary + 9 秒索引成本，一次性腳本或少量查詢 session 回本率是負的。arXiv 論文數字是 83% answer quality（非 100%），複雜語意推理仍需 fallback。

同時裝 cognee 和 codebase-memory-mcp 會衝突嗎？

不會。兩個工具分別作為獨立 MCP server 運行，Claude Code/Cursor 的 MCP config 可以同時列出兩個。角色不重疊：codebase-memory-mcp 負責程式碼結構層，cognee 負責知識記憶層。

AI Agent 記憶工具怎麼選？cognee vs codebase-memory-mcp 決策指南（2026）

你開始用 Claude Code 或 Cursor 寫程式，agent 一個 session 過後就「失憶」了。你試著擴大 context window，但大型 codebase 一開口就是幾十萬 token，成本爆炸、速度拖慢，而且 AI 的答案品質反而下滑。

問題不是 context 不夠大，而是你缺少一個結構化記憶層，讓 agent 只取它真正需要的那塊資訊。

這篇指南比較目前最受關注的兩個記憶工具：codebase-memory-mcp（程式碼結構記憶）和 cognee（通用知識圖記憶）。重點不是「哪個更好」，而是：你的需求是什麼形狀，哪個工具才對得上。

TL;DR

cognee：通用 AI agent 長期記憶引擎，Knowledge Graph + 向量架構，26.4k stars，$7.5M seed（OpenAI co-founder 背書），Apache 2.0。
codebase-memory-mcp：AI coding agent 的程式碼結構記憶，Tree-Sitter AST + LSP type resolution，23.9k stars，MIT，完全本地執行零遙測。
核心差異：一個記「知識」，一個記「程式碼結構」。不是競爭，是不同問題的不同解法。
決策快速版：只用 Claude Code/Cursor 寫程式，選 codebase-memory-mcp；建自己的 agent 系統，選 cognee；兩種場景都有，可以同時用。

AI Agent 的記憶危機：為什麼 context window 解決不了問題

大多數人遇到 AI agent「忘東西」時，第一個反應是「塞更多 context」。這個直覺在小規模時有效，但它掩蓋了一個根本性的架構問題。

context window 是工作記憶，不是長期記憶。 人類的工作記憶有限，我們依靠大腦的其他機制（海馬迴、長期記憶）來補足。AI agent 也需要類似架構。

問題有幾層：

量的問題：中型 codebase（3,000 個檔案）完整放進 context，輕鬆超過 100 萬 token。GPT-4o 每次呼叫成本直線上升，回應速度也下降。

質的問題：長 context 的 AI 注意力分散，容易忽略放在中間的資訊（lost-in-the-middle 現象）。你塞越多，答案品質不一定越好。

跨 session 的問題：context window 不持久，每次新對話都從零開始。昨天建立的理解，今天完全不見。

這兩個工具解決的，是後兩個問題（質的問題 + 跨 session 持久化），但用的是完全不同的方法，面向的也是完全不同的使用者。

codebase-memory-mcp：給 AI Coding Agent 的程式碼結構記憶

codebase-memory-mcp（v0.8.1，MIT）是一個 MCP server，讓 AI coding agent 可以查詢預先建好的程式碼結構索引，而不是每次都重新掃描整個 codebase。

技術核心：AST + LSP，不只是 grep

工具核心是 Tree-Sitter AST（語法樹解析）加上 Language Server Protocol（LSP）語意分析。它支援 158 種程式語言，其中 11 種有完整的 Hybrid LSP 語意分析（包括 TypeScript、Python、Go、Rust 等主流語言）。

索引建完後，agent 可以查詢：

哪個函數呼叫哪個函數
某個型別在哪些地方被使用
哪兩個檔案經常一起變動（git co-change coupling）
語意相關的程式碼區塊

這些是 grep 做不到的「結構性理解」。

我們在 shareuhack repo 的實測數據

我們用 shareuhack repo 測試了 codebase-memory-mcp 的實際表現：

安裝時間：npm install 33 秒，binary 256 MB（Mach-O x86_64）
索引速度：2,776 個檔案，9.4 秒 wall time（CPU 時間 50.6 秒，充分利用多核）
索引規模：72,647 個 nodes + 78,775 條 edges
Token 節省：search_graph 回傳 1,427 bytes vs 直接 grep+cat 354 KB，實測節省 99.6%

arXiv 論文（2603.27277）的跨 31 個 repo 平均數字是 token 節省 90%；shareuhack repo 的 99.6% 來自單次結構查詢場景，兩者測量方法不同。高數字反映「精準查詢 vs 全域展開」的對比，並非完整 agent session 的 token 消耗。

Edge 類型中特別值得注意的是 FILE_CHANGES_WITH（639 條，記錄 git co-change coupling）和 SEMANTICALLY_RELATED（128 條），這兩種邊讓 agent 可以做傳統靜態分析做不到的耦合查詢。

查詢去重效果也很明顯：同一查詢的 total_grep_matches 106 筆，total_results 只剩 29 筆，dedup ratio 3.7x。agent 拿到的是精煉過的結果，不是噪音。

代表性說明：以上數字基於 Next.js 內容平台型 codebase（大量 markdown 配置、相對少的業務邏輯密度）。後端重邏輯 monorepo 或純函式型 Python 專案的圖密度和 token 節省比例可能不同，建議在自己的 repo 實測後再評估。

支援的 Coding Agent 生態

官方支援清單包括：Claude Code、Codex CLI、Gemini CLI、Zed、OpenCode、Antigravity、Aider、KiloCode、Kiro。基本上主流 AI coding agent 都在支援範圍內。

cognee：給 Agent 系統的通用知識圖記憶層

cognee（v1.2.2，Apache 2.0）解決的是不同問題：如何讓 AI agent 跨 session 記住對話歷史、使用者偏好、文件知識，並在需要時精準召回。

三層架構：Graph + Vector + Relational

cognee 的儲存架構分三層：

Kuzu（圖資料庫）：記錄知識節點之間的關係
LanceDB（向量資料庫）：做語意相似度搜尋
SQLite（關係型資料庫）：記錄元資料和結構化資訊

三層同時運作讓它可以回答「A 和 B 有什麼關聯？」（圖查詢）和「有什麼和 X 相似的知識？」（向量搜尋）這兩類問題。

四步流程

cognee 的使用流程相對清楚：

add：把資料來源加進來（文件、對話、PDF、Slack 消息等）
cognify：建立知識圖（提取概念、關係、實體）
memify：建立使用者記憶層（跨 session 持久化）
search：召回相關知識

MCP 工具包括 remember、recall、forget 共 14 個 MCP tools。

生產級背景

cognee 在 2026 年 2 月完成 $7.5M seed 輪，投資方 Pebblebed 包含 OpenAI co-founder Pamela Vagata 和 Facebook AI Research founder Keith Adams。已在 70+ 生產環境部署，BEAM benchmark 拿到 0.79（此前最佳 0.735）。

它也支援完全本地的 standalone 模式（不需要雲端），以及雲端 API 模式。

cognee vs Mem0：另一個常見競爭者

如果你評估過 Mem0，值得知道幾個差異：Mem0 社群規模更大（48k+ stars，約為 cognee 的 1.8 倍），資源更豐富，入門更容易。但 Mem0 的圖功能需要 $249/月的 Pro 方案；cognee 的圖功能在所有 tier 都開放。

受眾匹配梯：你的記憶需求是什麼形狀？

這是本文最核心的認知翻轉：這兩個工具不是功能競爭，它們解決的是形狀不同的需求。

你需要先問自己一個問題：你的 agent 需要記住的是「程式碼結構」還是「知識與偏好」？

梯級一：只用 AI Coding Agent（Claude Code、Cursor）

你的主要場景是寫程式，agent 需要理解你的 codebase，偶爾換 session 後不想重新說明架構。

選 codebase-memory-mcp。它讓 agent 精準查到「這個函數在哪裡呼叫」「這個型別怎麼傳遞」，節省你解釋 codebase 結構的時間。

梯級二：正在建自己的 AI Agent 系統

你在用 Python SDK 或其他框架建 agent，需要 agent 跨 session 記住使用者資訊、累積知識、對話歷史持久化。

選 cognee。它的知識圖設計正是為這個場景打造，MCP 介面讓你的 agent 可以呼叫 remember 和 recall。

梯級三：同時有兩個需求

你在建自己的 coding assistant agent，同時也需要讓它記住使用者的偏好和知識庫。

兩個工具可以同時用。它們作為獨立 MCP server 運行，在 Claude Code 或 Cursor 的 MCP config 裡同時列出即可，角色不重疊，不會互相干擾。

快速決策表

場景	工具
用 Claude Code/Cursor 寫程式，想降低 token	codebase-memory-mcp
已有 Cursor 原生 codebase 索引，想要更細的語意查詢	可疊加 codebase-memory-mcp，查詢場景簡單則現有方案已足夠
建 agent 系統，需要長期記憶	cognee
需要 PDF/Slack/多模態知識攝入	cognee
看重完全本地、零遙測、供應鏈安全	codebase-memory-mcp（SLSA Level 3）
Python 生態系，需要知識圖	cognee
兩種場景都有	兩者並用

安裝前必知：codebase-memory-mcp 的 hotspots 功能輸出會被 console.log/console.error 等函數名稱淹沒，不適合用來快速了解業務架構。query_graph DSL 目前缺乏完整文件，需要用 search_graph 作為 fallback。這兩個限制不影響核心的函數查詢和依賴追蹤，但值得在安裝前知道。

技術深潛：認知翻轉點與邊界條件

在做選型決策之前，有幾個認知翻轉點值得提前了解，避免踩坑。

codebase-memory-mcp 的邊界

99% token 節省有前提條件。 arXiv 論文（2603.27277）的數字是：answer quality 83%（非 100%），token 使用節省 90%，tool call 減少 58%。我們的 shareuhack 實測 token 節省達到 99.6%，但前提是你反覆查詢同一個已索引的 codebase。一次性腳本或查詢次數極少的 session，256 MB binary + 9 秒索引成本根本回不了本。

hotspots 有雜訊。 我們測試中，top-5 hotspot 全是 console.log 和 console.error，不是有意義的業務邏輯。這個問題需要自己過濾或調整查詢策略。

DSL 文件不完整。 query_graph 提供了強大的 DSL 查詢，但目前缺乏完整文件，需要透過 trial and error 摸清楚語法。

CLI 參數命名不一致。 部分 CLI 參數命名在不同命令之間有命名風格不統一的問題，使用時需要留意。

預設排除特定目錄。 .claude/、content/insights 等類知識庫目錄被預設排除在索引之外，如果你需要索引這些，要在設定中明確加回來。

重新索引需手動觸發。 codebase 有大量新增或結構性變動時，需重新跑 codebase-memory-mcp index，v0.8.1 不支援增量更新。日常小規模修改可繼續使用現有索引，但大改動後建議安排一次重索引。

cognee 的邊界

Python 為主要 SDK。 cognee 的主要 SDK 是 Python，如果你的 agent 系統是 Node.js 或其他語言，整合複雜度會上升。

建圖需要 LLM 呼叫。 cognify 步驟需要呼叫 LLM 來提取概念和關係，意味著大量文件的初始化有 API 成本。費用取決於文件量和所選模型，建議先用 10 個小文件試跑，確認效果和成本後再批量處理。cognify 首次執行通常需要 1-2 分鐘（10-20 個小文件），終端機會有進度輸出，若等待超過 5 分鐘無回應才需要排查。

社群規模相對 Mem0 小。 26.4k stars 對比 Mem0 的 48k+ stars，遇到問題時社群資源少一些。

實戰設定：兩個工具的快速上手

codebase-memory-mcp 安裝

# 安裝
npm install -g codebase-memory-mcp

# 索引你的 codebase（在專案根目錄執行）
codebase-memory-mcp index

將以下設定加入 Claude Code 的 MCP config：

全域設定（適用所有專案）：~/.claude/claude_mcp_config.json
專案設定（僅限當前 repo）：.claude/mcp.json

{
  "mcpServers": {
    "codebase-memory": {
      "command": "codebase-memory-mcp",
      "args": ["serve"]
    }
  }
}

索引完成後，Claude Code 就可以透過 search_graph 等工具查詢程式碼結構，不再需要對整個 codebase 做 grep。

cognee 安裝

# 安裝
pip install cognee

# 基本使用範例
import cognee

# 加入知識
await cognee.add("你的文件或知識", dataset_name="my-knowledge")

# 建立知識圖（首次執行需 1-2 分鐘，依文件量和 LLM 速度而定）
await cognee.cognify()

# 搜尋
results = await cognee.search("你的查詢")

MCP 模式下，先安裝 pip install cognee-mcp 並啟動 server，再將以下設定加入 Claude Code 的 MCP config：

{
  "mcpServers": {
    "cognee": {
      "command": "cognee-mcp",
      "args": []
    }
  }
}

啟動後即可透過 remember、recall、forget 三個核心工具操作 cognee 記憶層。

風險揭露

兩個工具都處於活躍開發階段，API 穩定性需要關注版本更新。codebase-memory-mcp 的 query_graph DSL 尚未有完整文件，大型專案的索引維護（特別是頻繁變動的 codebase）需要自行建立重新索引的流程。cognee 的 cognify 步驟涉及 LLM API 呼叫，大規模知識庫的初始化成本需要提前估算。

結論：記憶形狀決定工具選擇

多數人在評估這兩個工具時，會陷入「哪個更好」的比較框架。但這個問題問錯了。

正確的問題是：你的 agent 需要記什麼？

記程式碼結構，選 codebase-memory-mcp。記知識、對話、偏好，選 cognee。兩種都需要，就兩個都裝。它們的功能邊界清晰，不會互搶地盤。

如果你用 Claude Code 寫程式，想驗證 codebase-memory-mcp 的實際效果，最快的方式是在你自己的 repo 跑一次索引，看看 72,647 個 nodes 的結構圖長什麼樣，然後問 agent 一個你通常需要手動查的問題，感受一下 token 數量和答案品質的差異。

如果你在建自己的 agent 系統，cognee 的 BEAM benchmark 0.79 和 70+ 生產環境部署是它最有說服力的背書，快速起步可以從 standalone 本地模式開始，不需要任何雲端依賴。