很多人說 AI Agent 需要「程式碼庫記憶」。 但這個詞太寬了。 有人想讓 Agent 記住專案規則。 有人想讓 Agent 找到函式呼叫鏈。 有人想讓 Agent 不要每次都重新掃描整個倉庫。 也有人想讓 Agent 自動執行固定的審查流程。
這四個問題聽起來相似，實際需要的工具完全不同。
Claude.md 和 AGENTS.md 更像專案規則文件。
code-review-graph 更像程式碼關係圖和審查輔助工具。
codebase-memory-mcp 更像跨工具共享的程式碼索引服務。
Codex Skills 更像可重用的工作流程說明書。
選錯之後，問題不是功能少一點，而是維護成本變高。 這篇文章不重複單一工具教學，而是做選型。
先說選型結論
小專案先用 AGENTS.md 或 Claude.md。
中型專案加 Codex Skills，把重複流程固定下來。
程式碼審查任務優先看 code-review-graph。
多工具共享程式碼索引時，再考慮 codebase-memory-mcp。
不要一開始就把四種都裝上。 更好的順序是：規則文件先行，流程沉澱第二，結構索引第三，MCP 服務最後。 如果你已經讀過 AI Agent 程式碼庫記憶工具對比，這篇可以作為更窄的實作選型表。
四類工具解決四類問題
| 工具 | 主要解決的問題 | 最適合場景 | 最大風險 |
|---|---|---|---|
Claude.md / AGENTS.md |
專案規則和長期約束 | 小團隊、單倉庫、固定規範 | 寫太長，污染上下文 |
Codex Skills |
重複任務流程 | 發布、翻譯、部署、SEO、審查 | 把沒跑順的流程固化 |
code-review-graph |
呼叫關係和變更影響 | PR 審查、架構影響分析 | 圖譜過期或排除目錄不準 |
codebase-memory-mcp |
跨工具共享程式碼索引 | 多 Agent、多 IDE、大倉庫 | 服務權限和索引維護成本 |
這張表的重點是「主要解決的問題」。 它們不是同一種工具的四個品牌，而是四層能力。 規則層告訴 Agent 怎麼做。 流程層告訴 Agent 重複做什麼。 結構層告訴 Agent 程式碼之間怎麼連。 服務層讓不同 Agent 透過統一接口查同一份索引。
先判斷你缺的是哪種記憶
選工具前先問四個問題：
- Agent 是忘了專案規範嗎？
- Agent 是找不到相關程式碼嗎？
- Agent 是每次都重複同一套步驟嗎？
- Agent 是多個工具之間上下文不同步嗎？
如果只是忘了規範，寫 AGENTS.md 就夠了。
如果只是重複同一套工作流程，寫 Skill 更直接。
如果經常漏掉呼叫鏈和影響範圍，用程式碼圖譜。
如果 Codex、Claude Code、Cursor 都要查同一份結構化索引，再接 MCP。
不要因為「記憶」這個詞，就把所有工具混在一起。
Claude.md 和 AGENTS.md：專案規則層
Claude.md 和 AGENTS.md 的價值在於短。
它們應該告訴 Agent 穩定規則，而不是保存專案百科。
適合寫進去的內容包括：
- 專案啟動命令。
- 測試命令。
- 程式碼風格。
- 禁止修改的目錄。
- 發布前檢查。
- 常見陷阱。
- 安全邊界。
- 語言和文案要求。
不適合寫進去的內容包括：
- 完整業務背景。
- 過期討論記錄。
- 每個模組的詳細說明。
- 長篇設計文件。
- 一次性任務日誌。
- 沒驗證過的個人偏好。
好的規則文件應該像路標。 它提醒 Agent 不要走錯路。 它不應該變成一本厚手冊。 如果你想專門優化規則文件，可以看 Claude.md 不是越長越好。
Codex Skills：工作流程記憶層
Skill 不是程式碼索引。 它記住的是「做事方式」。
例如這個站點的新文章流程：
- 判斷是不是新建文章。
- 找到下一個編號。
- 只建立
index.zh-cn.md。 - 設定 front matter。
- 控制發布日期。
- 檢查行數。
- 不生成其他語言。
這些步驟不適合每次都寫在提示詞裡。 它們適合沉澱成 Skill。
Skills 適合的任務
- 內容發布流程。
- 多語言翻譯流程。
- 部署流程。
- SEO 冷卻期檢查。
- 本地重寫流程。
- 安全檢查清單。
- 固定格式報告。
- 程式碼審查步驟。
Skills 不適合的任務
- 單次問題排查。
- 仍在摸索的流程。
- 需要大量臨場判斷的任務。
- 沒有穩定驗收標準的任務。
- 只為了讓回答更長的提示詞集合。
Skill 最好的形態是「少解釋，多約束」。 它應該減少 Agent 犯固定錯誤的概率。 如果你想從零寫，可以看 Codex Skills 怎麼寫自己的工作流。
code-review-graph：變更影響層
code-review-graph 的重點不是讓 Agent 記住聊天記錄。
它更關注程式碼結構。
它用圖譜思路幫你回答：
- 這個函式被誰呼叫？
- 這個路由影響哪些模組？
- 這個 PR 改了哪些呼叫鏈？
- 哪些測試可能需要補？
- 哪些文件應該一起審查？
這類問題靠普通提示詞很難穩定回答。 因為 Agent 如果只讀 diff，容易漏掉間接影響。 如果讓它全倉庫搜尋，又容易浪費上下文。
圖譜工具的價值就在這裡。 它把程式碼結構提前算好。 Agent 需要時再查。
code-review-graph 適合誰
- 經常做 PR 審查的人。
- 倉庫模組之間呼叫複雜的人。
- 想讓 Codex 或 Claude Code 審查變更影響的人。
- 不想每次都讓 Agent 掃全倉庫的人。
- 想把審查流程接入 GitHub Actions 的團隊。
code-review-graph 不適合誰
- 只有幾個文件的小腳本。
- 沒有 PR 或 diff 流程。
- 只想保存聊天記憶。
- 不願維護索引生成結果。
- 無法區分生成文件和源碼目錄。
如果你要上手，可以看 code-review-graph 怎麼用。 如果要接 CI，可以看 code-review-graph 接入 GitHub Actions。
codebase-memory-mcp：共享索引層
codebase-memory-mcp 更適合多工具環境。
如果你只用一個 Agent，未必需要它。
但如果你同時用 Codex、Claude Code、Cursor、Gemini CLI，問題會出現。 每個工具都有自己的上下文。 每個工具都可能重新掃描程式碼。 每個工具對專案結構的理解可能不一致。
這時 MCP 形式的程式碼索引就有價值。 它可以把程式碼庫結構作為服務暴露給不同 Agent。 Agent 不需要每次重新建立理解。
codebase-memory-mcp 適合的場景
- 大倉庫。
- 多語言倉庫。
- 多個 Agent 共享同一專案。
- 需要本地優先的程式碼索引。
- 需要透過 MCP 統一接入。
- 需要減少重複掃描成本。
使用前要想清楚
它是一個服務。 服務就有運行狀態。 服務就有端口、權限、索引目錄和升級問題。
如果團隊沒有人維護，這類工具很容易變成「裝過但沒人敢動」。 所以它適合已經有穩定 Agent 使用習慣的團隊。 不適合還在試用階段的人。 安裝教程可以看 codebase-memory-mcp 使用教程。
按倉庫規模選擇
倉庫規模會明顯影響選型。 一個腳本倉庫和大型單體倉庫，不應該用同一套記憶方案。
10 個文件以內
這類專案不需要複雜記憶。 建議只保留：
README.md。AGENTS.md。- 基礎測試命令。
- Git diff 審查。
如果 Agent 還找不到文件，問題通常不是工具少，而是任務描述太寬。
10 到 200 個文件
這類專案開始需要輕量結構說明。 建議增加：
- 模組目錄說明。
- 常用命令清單。
- 一個開發或發布 Skill。
- 必要時加
code-review-graph。
這時規則文件仍然要短。
不要把每個模組都寫進 AGENTS.md。
200 到 2000 個文件
這類專案開始出現影響範圍問題。 建議增加：
- 呼叫關係圖譜。
- 變更影響審查。
- CI 中的最窄測試策略。
- 團隊共享規則。
- 忽略生成目錄的索引配置。
code-review-graph 在這一層更有價值。
它幫助 Agent 少靠猜。
多語言大倉庫
這類專案需要共享索引和服務化能力。 建議增加：
codebase-memory-mcp。- 統一 MCP 配置。
- 索引更新策略。
- 權限白名單。
- 服務監控。
- 版本升級記錄。
這時工具本身已經是基礎設施。 不能只靠個人習慣維護。
按任務類型選擇
不同任務對記憶的要求也不同。
修 Bug
修 Bug 最需要復現步驟和相關文件。 優先級是：
- 錯誤日誌。
- 復現命令。
- 最近改動。
- 相關測試。
- 呼叫關係。
如果 Bug 很局部，不必上 MCP。 如果 Bug 跨模組，再用圖譜。
寫新功能
新功能最需要邊界。 優先級是：
- 需求範圍。
- 不改動範圍。
- 資料結構。
- API 契約。
- 測試入口。
規則文件能防止 Agent 亂改架構。 Skill 可以保存固定實作流程。
程式碼審查
程式碼審查最需要變更影響。 優先級是：
- diff。
- 呼叫方。
- 被呼叫方。
- 路由入口。
- 測試覆蓋。
- 安全邊界。
這裡 code-review-graph 比長提示詞更合適。
文件和發布
文件和發布最需要流程記憶。 優先級是：
- front matter。
- 文件命名。
- 構建規則。
- 多語言同步。
- 連結檢查。
- 發布檢查。
這類任務更適合 Skills。
資料更新策略
程式碼庫記憶如果不更新，很快就會誤導 Agent。 不同工具的更新方式不同。
規則文件靠人工維護。 Skills 隨流程變化更新。 code-review-graph 需要在程式碼變更後重建或增量更新。 codebase-memory-mcp 需要維護索引服務和資料目錄。
什麼時候必須更新
- 新增模組。
- 刪除目錄。
- 路由結構變化。
- 測試命令變化。
- 構建工具變化。
- 程式碼生成目錄變化。
- 團隊權限規則變化。
- CI 流程變化。
- Agent 工具升級。
- MCP 服務升級。
更新後的驗收
- Agent 能說明入口文件。
- Agent 能找到相關測試。
- Agent 不會掃描生成目錄。
- Agent 能解釋一次真實 diff。
- Agent 能遵守禁止修改範圍。
- Agent 能正確呼叫 Skill。
- MCP 查詢返回的是最新文件。
- 圖譜結果和實際程式碼一致。
失敗案例和修復
規則文件太長
表現是 Agent 每次都讀得慢，還會引用無關規則。 修復方法是刪。 保留穩定約束。 把流程移到 Skill。 把背景移到文檔。
Skill 寫得太泛
表現是每種任務都套同一個流程。 修復方法是拆。 一個 Skill 只服務一類工作。 例如發布、翻譯、部署、審查分別寫。
圖譜沒有排除生成目錄
表現是 Agent 關注構建產物，而不是源碼。
修復方法是更新 ignore 配置。
把 dist/、public/、node_modules/、緩存目錄排除。
MCP 權限過大
表現是 Agent 能訪問太多不相關資源。 修復方法是分級。 只讀工具先行。 寫入工具單獨審批。 生產工具默認關閉。
四種工具可以怎麼組合
個人小專案建議：AGENTS.md、少量專案文檔、Git diff、最窄測試命令。
中型 Web 專案建議：AGENTS.md、一個發布或測試 Skill、code-review-graph、PR 審查模板。
多 Agent 團隊專案建議：AGENTS.md、團隊級 Skills、code-review-graph、codebase-memory-mcp、CI 審查、權限邊界文檔。
內容站和自動化工作流建議：發布 Skill、翻譯 Skill、SEO 冷卻期規則、部署 Skill、少量站點目錄說明。
這類組合的關鍵不是工具多。 關鍵是每一層解決的問題不重疊。
選型決策樹
先問：Agent 是否經常違反專案規則？
是，就寫 AGENTS.md 或 Claude.md。
Agent 是否經常重複同一套步驟？ 是，就寫 Skill。
Agent 是否經常漏掉呼叫鏈或影響範圍？
是，就用 code-review-graph。
是否有多個 Agent 需要共享程式碼索引？
是，再考慮 codebase-memory-mcp。
否，先不要加工具。 這個順序能避免把簡單問題複雜化。
和已有文章怎麼串起來
這篇文章適合作為選型入口。 單工具安裝繼續交給已有文章。
code-review-graph 的具體命令看 7/99。
GitHub Actions 接入看 7/137。
codebase-memory-mcp 安裝看 6/113。
規則文件思想看 4/118。
通用記憶路線看 7/42。
這樣讀者不會在一篇文章裡被所有命令淹沒。 他們先選方向，再進入具體教程。
最終選擇建議
如果你只想讓 Agent 不犯固定錯誤，選 AGENTS.md 或 Claude.md。
如果你想讓 Agent 按固定流程辦事，選 Codex Skills。
如果你想讓 Agent 做變更影響分析，選 code-review-graph。
如果你想讓多個 Agent 共享程式碼結構，選 codebase-memory-mcp。
真正成熟的程式碼庫記憶，不是把所有東西都記住。 而是把規則、流程、結構和服務放到合適的位置。