什麼是 Codebase Memory MCP？ · Codebase Memory

一句話說清楚

Codebase Memory 是一個專門為 AI 開發代理 (Coding Agents) 設計的持久化程式碼記憶與知識圖譜 (Model Context Protocol, MCP) 服務。

它在開發者本地端，將專案中的所有程式碼檔案、類別、介面、函式、變數以及它們之間的依賴呼叫關係，透過 tree-sitter 語法解析器提煉成一個結構嚴密的「知識圖譜」。當 AI 需要理解、修改或除錯你的程式碼時，它不再需要盲目地 Grep 搜尋或重複讀取大量無關的原始檔案，而是可以直接「查詢圖譜」，在幾毫秒內理清複雜的程式碼依賴網路。

為什麼傳統的 Grep + Read 模式在 AI 時代失效了？

在傳統協作中，AI 助手（例如 Claude Code 或 Cursor）由於缺乏專案的全域架構心智圖，在面對數萬行以上的專案時，經常陷入以下困境：

「盲人摸象」式的局部理解：當你問 AI：「修改這個 PLC 通訊介面會影響哪些業務邏輯？」時，AI 只能利用 grep 搜尋字串。如果上游是透過多層抽象（如介面繼承、事件總線）間接呼叫的，字串比對會完全漏掉這些關係，導致 AI 做出破壞性的修改建議。
Context Token 瞬間耗盡：為了解答一個跨檔案的 Bug，AI 必須呼叫多次 read_file，把五、六個甚至十幾個檔案的完整代碼全部塞進 Context Window 中。這會導致 Token 數量呈指數級增長，開發成本飆升，並且會觸發 LLM 的「大海撈針（Needle in a Haystack）」注意力衰退，產生嚴重的幻覺。
跨對話記憶喪失：一旦你開啟一個新的 Chat Session，AI 之前對你專案架構的理解就會全部清空。它必須重新開始 Grep 與 Read 過程，效率極低。

傳統搜尋與 Codebase Memory 知識圖譜對比

項目	傳統 ripgrep / search	Codebase Memory 知識圖譜
檢索原理	純字串正則匹配 (Text match)	抽象語法樹 (AST) 語意節點與關係查詢
依賴識別	無法識別（需人工依據變數命名推敲）	自動解析 `CALLS`、`INHERITS`、`IMPLEMENTS` 等關係
跨檔案追蹤	需人工多次 grep / 查閱	單次 `trace_path` 呼叫即可回傳完整入站/出站呼叫鏈
Token 消耗	極大（AI 需要讀取多個檔案的全部代碼）	極小（僅傳輸結構化的節點關係與目標程式碼片段）
跨會話記憶	無（每個新 Session 都必須重新理解）	有（本地資料庫持久化儲存，隨時供 AI 快速載入）

知識圖譜的底層模型設計

Codebase Memory 在本地端的持久化圖譜資料庫中，將程式碼抽象為以下核心節點與關係模型；它不是需要另外部署 Neo4j 的服務：

       ┌──────────┐
       │   File   │
       └────┬─────┘
            │ DEFINES
            ▼
       ┌──────────┐
       │  Class   │
       └────┬─────┘
            │ IMPLEMENTS
            ▼
 ┌──────────────────────┐  CALLS  ┌──────────────────────┐
 │  Function (Connect)  ├────────▶│ Function (SendPacket)│
 └──────────────────────┘         └──────────────────────┘

1. 節點類型 (Node Types)

File：原始碼檔案（如 PlcConnection.cs），包含路徑、雜湊值。
Class / Interface：物件導向定義。
Function / Method：具體的行為區塊。
Variable / Field：變數與常數宣告。
HTTP Route：對應的 Web API 端點（如 /api/v1/status）。

2. 關係類型 (Relation Types)

DEFINES：檔案或類別內定義了成員（如 Class DEFINES Method）。
CALLS：方法 A 呼叫了方法 B（如 Connect() CALLS SendPacket()）。
IMPLEMENTS / INHERITS：介面實作與類別繼承。
DEPENDS_ON：模組或檔案級別的依賴關係。

核心技術：Tree-Sitter AST 語意分析

Codebase Memory 的高效率得益於底層整合了 Tree-Sitter 語法解析器。

與簡單的 Regex 正則掃描不同，Tree-Sitter 會將程式碼編譯成抽象語法樹（AST）。這意味著不論你是使用 C# 的 lock (_socketLock)，還是 JavaScript 的 await mutex.acquire()，Codebase Memory 都能準確理解這是「執行緒同步鎖定」或「非同步互斥鎖」的語意，進而將其標記為關鍵的控制流節點。

同時，最新發行版的解析機制涵蓋包括 C#、Java、Go、TypeScript、Rust 在內的 155 種程式語言，並且以本地索引為主；實際支援範圍與解析深度仍應以發行版文件為準。

120x 更少 Token 消耗的機制

為什麼 Codebase Memory 能號稱減少 120x 的 Token 消耗？

精準導航而非全文載入：
當 AI 需要查找 PLC 斷線問題時，它先呼叫 search_graph 定位 PlcConnection。此時圖譜僅返回該類別的節點元數據與直接關係列表（約 200 字元 / 50 Token），而非讀取整份數千行的檔案。
語意路徑剪枝：
透過 trace_path，AI 可以快速過濾掉那些與 Bug 無關的呼叫路徑，只針對處於關鍵呼叫鏈上的單個函式，調用 get_code_snippet 讀取該函式的 20 行實作。
消除無效 Context 雜訊：
這使得 LLM 接收到的 Context 內 100% 都是與當前問題強相關的精準程式碼，徹底避免了因載入整個目錄或多個大檔案而造成的 Token 浪費與注意力分散。

在下一章 [安裝與配置 Codebase Memory] 中，我們將帶你一步步在本地端安裝這套強大的 MCP 服務，並將其連接到你最常使用的 AI 工具中。