代码库记忆层升温：图谱记忆MCP 正在变成编码 Agent 的基础设施

山行AI

发布于 2026-07-21 08:40:44

210

前言

过去我们让编码 Agent 看代码，最常见的办法很粗：先 grep，再读文件，再凭上下文窗口临时拼出一张脑内地图。问题也在这里。上下文窗口一清空，地图就没了；换一个 Agent，又要重新翻一遍。

现在这件事正在变。越来越多项目开始把代码库解析成持久图谱，再通过 MCP 暴露给 Agent。Agent 不必每次从零扫文件，而是可以先问图：谁调用谁？这次 diff 会影响哪些路径？哪些测试应该读？跨仓服务之间有没有真实关系？

这篇文章看三个项目：codebase-memory-mcp、code-review-graph 和 Graphify。它们都在做“代码库记忆层”，但性格不一样：一个追求高性能 MCP 后端，一个把代码审查做成最小上下文过滤器，一个把代码、文档和多媒体放进同一张项目知识图谱。

截至 2026-07-19，三个项目的 GitHub 数据如下：

•DeusData/codebase-memory-mcp：32,764 stars，主语言 C，定位是高性能代码智能 MCP server。

•tirth8205/code-review-graph：20,295 stars，主语言 Python，定位是本地优先的代码审查图谱。

•Graphify-Labs/graphify：91,099 stars，主语言 Python，定位是面向 AI 编码助手的跨模态知识图谱 skill。

一、codebase-memory-mcp：把代码库结构做成 MCP 后端

codebase-memory-mcp 的目标很明确：给 AI 编码 Agent 一个本地、持久、可查询的代码知识图谱。

它不是一个内置 LLM 的代码助手，而是结构分析后端。它负责把仓库解析成图，MCP 客户端负责把自然语言问题翻译成工具调用。这个分工挺关键：你继续和 Claude Code、Codex、Cursor、Gemini CLI 之类的 Agent 对话，图谱引擎只负责给它可靠的结构证据。

内置 3D 图谱可视化，用来查看代码库里的节点、边和模块聚类。

它的核心能力可以拆成几层。

第一层是索引。项目用 Tree-sitter AST 分析 158 种语言，并在 Python、TypeScript、JavaScript、JSX、TSX、PHP、C#、Go、C、C++、Java、Kotlin、Rust、Perl 等语言上加入 Hybrid LSP 风格的语义类型解析。最终落到图里的不是普通文本块，而是函数、类、接口、路由、调用链、跨服务 HTTP 关系、数据流、近似克隆关系和语义相关边。

第二层是存储。它采用 SQLite，本地持久化到缓存目录。索引管线强调 RAM-first：LZ4 压缩、内存 SQLite、最后一次 dump，索引结束后释放内存。README 中给的性能数字很夸张：Linux kernel 28M LOC、75K 文件，完整索引约 3 分钟；结构查询通常低于 1ms。

第三层是 MCP 工具。它提供 15 个工具，包括 index_repository、search_graph、trace_path、detect_changes、query_graph、get_architecture、search_code、manage_adr、ingest_traces 等。对 Agent 来说，这些工具比“打开一堆文件慢慢看”更像一张地图。

第四层是团队共享。它支持把图压缩为 .codebase-memory/graph.db.zst，放在仓库旁边。新人 clone 后，工具先导入这个压缩图，再做增量索引。这个设计很实用：代码库记忆不只服务当前对话，也可以变成团队资产。

它还把安装和分发做得很工程化：单静态二进制，macOS、Linux、Windows 都支持；无 Docker，无 API key；可通过 npm、PyPI、Homebrew、Scoop、Winget、Chocolatey、AUR 等方式安装。安装命令会检测本机 Agent，并把 MCP 配置、持久说明、skill、hook 或 agent profile 写到合适的位置。

我看这个项目时，最强的感受是：它不像“又一个代码问答工具”，更像本地代码图谱基础设施。它的价值不在于回答一句“这个函数做什么”，而在于让 Agent 以后每次进仓库，都不再从一片黑暗开始。

二、code-review-graph：把 PR 审查变成最小上下文问题

如果说 codebase-memory-mcp 更像基础设施层，那么 code-review-graph 更像代码审查层。

它盯住一个非常具体的问题：AI coding tools 在 review 任务里经常重复读取大量文件，token 烧得多，结论还不一定更准。code-review-graph 的做法是先用 Tree-sitter 把仓库解析成结构图，再在 review 时给 Agent 精确上下文：变更影响哪些函数、哪些调用链、哪些测试，哪些文件才值得读。

核心问题很直白：不要把全仓都塞给模型，要给它目标上下文。

安装方式也很直接：

class="language-bash">pip install code-review-graph
code-review-graph install
code-review-graph build

install 会自动检测 Codex、Claude Code、Cursor、Gemini CLI、Windsurf、Zed、Continue、OpenCode、Antigravity、Kiro、GitHub Copilot 等平台，并写入对应 MCP 配置和规则。用户也可以指定平台安装，比如 --platform codex 或 --platform claude-code。

一次安装，自动适配多种 AI 编码工具。

它的工作流大致是：

1用 Tree-sitter 解析仓库，提取函数、类、import、call site、继承关系和测试关系。

2把节点和边写入本地 SQLite 图。

3当用户发起 review 或检测变更时，图谱计算影响半径和风险分数。

4Agent 只读取相关文件，而不是扫完整代码库。

用户请求审查，Agent 查询 MCP 工具，图谱返回影响半径和风险信息。

从仓库到 Tree-sitter，再到 SQLite 图、影响半径和最小审查集。

它最有代表性的能力是 blast-radius analysis，也就是影响半径分析。一个 login() 变更，不只看这个函数本身，还会沿着调用者、依赖项和测试继续追踪，给出可能受影响的区域。

一个变更如何传导到调用者、依赖项和测试。

为了让图谱保持新鲜，它支持 hook、watch mode 和 daemon。保存文件或提交代码后，只重解析变动文件和相关依赖。README 中举的例子是一个 2,900 文件项目，增量更新低于 2 秒。

只重解析少量变更文件，跳过大部分无关文件。

在大仓和 monorepo 场景里，这种过滤尤其有用。项目给出的示意是：从 20 万级源码 token 收敛到几千 token 的图响应，Agent 不再被全仓噪声拖着走。

从大仓库里筛出真正需要读的上下文。

语言支持也覆盖得很宽：Python、JavaScript、TypeScript、Go、Rust、Java、C/C++、C#、Ruby、Kotlin、Swift、PHP、Scala、Solidity、Dart、R、Perl、Lua、Objective-C、Shell、Elixir、Zig、PowerShell、Julia、Nix、SQL、Terraform/OpenTofu、Ansible、Vue、Svelte、Astro、Jupyter/Databricks notebooks 等。它还允许用户通过 .code-review-graph/languages.toml 添加自定义语言映射，不需要 fork。

语言和 notebook 支持范围很广，重点是结构提取。

它还把同一套分析带进 CI：GitHub Action 可以在 PR 上发 sticky comment，列出风险函数、受影响执行流和测试缺口，也可以用 fail-on-risk 做合并门槛。

基准部分值得稍微冷静看。README 里强调 median per-question token reduction 约 82x，范围 38x 到 528x；528x 是单个最佳 case，不是典型值。影响分析的 recall 1.0 也被作者自己标成 graph-derived upper bound，不应解读成真实世界永远 100% 召回。这种自我限定反而增加了可信度。

项目给出的基准看板：token 节省明显，但作者也说明了评测边界。

三、Graphify：把项目资料做成一张可查询的知识图谱

Graphify 的野心更大。它不只处理代码，还想把代码、SQL schema、R 脚本、Shell 脚本、文档、论文、图片、视频都放进同一张可查询图谱里。

用户在 AI 编码助手里输入 /graphify .，它会生成三个核心产物：

class="language-text">graphify-out/
├── graph.html
├── GRAPH_REPORT.md
└── graph.json

graph.html 是可点击、可搜索、可过滤的交互图；GRAPH_REPORT.md 是项目亮点、关键概念、异常连接和推荐问题；graph.json 是完整图谱，之后可以被 CLI 或 MCP server 查询。

FastAPI 代码库被映射成知识图谱，节点颜色代表检测到的社区。

Graphify 最鲜明的点有三个。

第一，它强调“不是 vector index”。代码部分通过 Tree-sitter AST 本地解析，不依赖 LLM，也不需要把代码发出去。它生成的是可以遍历的图，而不是相似度向量堆。

第二，它给边打可信度标签。每条关系会标注 EXTRACTED、INFERRED 或 AMBIGUOUS。这对 Agent 很重要，因为“找到关系”和“猜到关系”不是一回事。没有这个标签，图谱很容易变成另一种黑箱。

第三，它支持路径查询。比如用户问 FastAPI 和 ModelField 如何连接，Graphify 可以返回一条最短路径，而不是把一堆文件丢给 Agent 让它自己猜。

路径查询把两个概念之间的连接一步步亮出来。

Graphify 的输入范围比另外两个项目更宽。代码部分覆盖 36 个 Tree-sitter grammar，还能处理 Salesforce Apex、Terraform/HCL、MCP configs、package manifests、Markdown/HTML/RST/YAML 文档、Office 文件、Google Workspace 快捷方式、PDF、图片、音视频和 YouTube URL。代码是本地 AST 提取；文档、PDF、图片和视频的语义提取会使用 AI assistant 的模型或用户配置的 API。

它也很重视团队共享。graphify-out/ 被设计成可以提交进 git。团队里一个人跑完 /graphify . 并提交图谱，其他人 pull 后，Agent 就可以直接读已有图，而不是每个人都从零建立上下文。它还支持 git hook，在提交后自动重建 AST 部分，并通过 merge driver 避免 graph.json 冲突。

在 MCP 侧，它可以把 graph.json 作为 stdio 或 HTTP server 暴露出去，提供 query_graph、get_node、get_neighbors、shortest_path、list_prs、get_pr_impact、triage_prs 等工具。HTTP 模式可以让团队共用一个图谱服务，但 README 也提醒：暴露到非 localhost 时要配 API key。

Graphify 给我的感觉是：它不是只想回答“代码里谁调用谁”，而是想做项目级知识记忆。代码、文档、PR、论文、视频说明、设计理由都能成为节点。这个方向更接近“团队知识底座”，代价是系统边界也更复杂，尤其是当多媒体和文档语义提取开始调用模型时，隐私和成本就需要单独看。

四、三者对比：同叫记忆层，落点不一样

这三个项目可以放在同一张谱系里看，但不要混成一个东西。

codebase-memory-mcp 最像基础设施层。它关心速度、语言覆盖、MCP 工具面、二进制分发和多 Agent 接入。适合希望给各种编码 Agent 提供统一结构查询后端的场景。

code-review-graph 最像代码审查层。它关心变更影响、最小上下文、风险打分、增量更新和 CI 评论。适合 PR review、pre-merge check、大仓变更定位，以及“不要让 Agent 乱读全仓”的团队。

Graphify 最像项目知识层。它关心跨文件、跨文档、跨媒体的概念连接，也关心图谱 HTML、报告、JSON 和团队共享。适合 onboarding、架构理解、知识沉淀和跨资料检索。

从技术模式看，也有明显差异：

•codebase-memory-mcp：Tree-sitter + Hybrid LSP + SQLite + MCP 工具，偏结构查询后端。

•code-review-graph：Tree-sitter + SQLite + diff/blast radius + watch/hook/CI，偏审查和变更分析。

•Graphify：Tree-sitter + 多类型提取 + graph.json/graph.html + skill/MCP server，偏项目知识图谱。

从隐私和运行方式看，三者都强调 local-first，但边界不同。codebase-memory-mcp 说处理 100% 本地；code-review-graph 的核心图存储在本地 .code-review-graph/，云 embedding 是可选项；Graphify 的代码解析本地完成，但文档、PDF、图片和视频的语义提取可能使用用户配置的模型后端。