代码仓库正在变成 Agent 的长期记忆：从代码评审图谱到 MCP 索引

山行AI

发布于 2026-07-23 13:58:51

910

前言

Agent 写代码时，补一个函数并不难。麻烦的是，它常常每次都像第一次见到这个仓库。

它会反复读同一批文件，在一堆相似命名里找入口，改了登录逻辑却漏掉测试链路，解释架构时又把昨天刚看过的上下文重新扫一遍。模型越强，这个问题越刺眼：推理能力上来了，仓库记忆没跟上。

所以，下一轮编码 Agent 的竞争点，可能不在“谁更会写一段代码”，而在“谁能更快找到该读的那几页”。代码图谱、MCP 索引和本地 Web 证据工具正在补这一块。它们并不想再造一个 IDE。它们想给 Agent 一层可查询、可持久、能收窄上下文的记忆层。

这篇看三个项目：

•code-review-graph[1]：把代码评审变成影响面图谱问题。

•codebase-memory-mcp[2]：用 C 写一个高性能 MCP 代码库记忆服务。

•wigolo[3]：给 Agent 补一层本地优先的网页搜索、抓取、研究证据层。

截至目前：codebase-memory-mcp 约 33,842 stars，code-review-graph 约 24,855 stars，wigolo 约 3,290 stars。热度只是表象，更值得看的，是它们把“记忆”拆成了三种工程问题：代码关系、查询接口、外部证据。

三类项目在 Agent 工具链中的位置：代码评审图谱、仓库 MCP 记忆服务、网页证据层。

1. code-review-graph：让 Agent 少读无关文件

一句话看它：它把代码评审前置成一次图查询，先圈出影响面，再让模型开口。

code-review-graph 的出发点很直接：AI 编码工具在做评审、解释和变更影响分析时，经常把大量代码重新塞进上下文。它用 Tree-sitter 解析仓库，抽取函数、类、导入、调用、继承、测试等结构，再把这些关系存进本地 SQLite 图谱。Agent 通过 MCP 或 CLI 查询图谱，只读与当前问题有关的文件。

项目给出的对比图：同一类问题下，图查询能显著减少上下文读取量。

它的工作流可以概括为四步：

1解析仓库，建立函数、类、文件、调用边和测试边。

2当代码发生变化时，增量更新图谱，而不是全量重建。

3在评审或问答时，先查图谱找到影响面。

4让 Agent 只读取这些路径，再生成审查建议或架构解释。

AI 助手通过 MCP 先问图谱，再读取最小相关上下文。

它最适合的场景是 Pull Request 评审和大仓库影响面分析。比如登录函数变了，传统 Agent 可能先搜 login，再打开一堆文件；code-review-graph 会沿调用边、依赖边、测试边向外追踪，把可能受影响的函数、文件和测试列出来。

安装器会识别多种编码 Agent 和编辑器，并写入相应 MCP 配置。

代码从仓库进入 Tree-sitter 解析，再进入本地图谱和影响面分析。

变更影响面分析：从一个函数向调用者、依赖者和测试传播。

增量更新是它的另一个抓手。保存文件或触发 hook 后，系统通过 hash 检查找到变化文件，只重解析必要部分。项目文档中提到，约 2,900 个文件的项目可以在 2 秒内完成增量更新。

增量更新只处理变化文件和必要依赖，避免每次从头扫描。

对 monorepo 来说，这种收敛很有价值。大仓库里“可读文件数量”和“真正该读的文件数量”差距巨大，图谱的作用就是把问题先缩小。

大仓库上下文被漏斗式压缩，Agent 读取的范围更接近真实任务。

项目覆盖 Python、JavaScript、TypeScript、Go、Rust、Java、C/C++、C#、Ruby、Kotlin、Swift、PHP、Scala、Solidity、Dart、R、Shell、Elixir、Zig、SQL、Terraform、Vue、Svelte、Astro、Jupyter Notebook 等多种语言和文件形态。对于自定义语言，也可以通过 .code-review-graph/languages.toml 映射扩展名、Tree-sitter grammar 和节点类型。

项目支持的语言和文件类型覆盖面。

项目自己的 benchmark 比较克制。它给出的中位数是约 82x 的单问题上下文减少，528x 是 best case，不被当成常态宣传。影响面召回里的 1.0 recall 也明确说明是 graph-derived upper bound，不能当成真实世界“百分百召回”。这点我很喜欢，因为代码评审工具最怕把营销指标写成工程事实。

benchmark 图中展示了不同仓库上的 token reduction、影响面 F1 和查询延迟。

2. codebase-memory-mcp：把代码库索引做成常驻 MCP 服务

一句话看它：它把仓库事实做成常驻服务，Agent 随时来查，不必每次重新翻箱倒柜。

如果说 code-review-graph 更像“评审场景里的图谱助手”，codebase-memory-mcp 则更像一个常驻的代码库记忆服务器。

它用 C 编写，发布为 macOS、Linux、Windows 可用的静态二进制。默认不依赖外部数据库和云服务，索引数据写入 ~/.cache/codebase-memory-mcp/ 下的 SQLite，WAL 模式持久保存。Agent 连接后，可以通过 MCP 工具索引项目、查询图谱、追踪调用路径、读取代码片段、分析架构、检测变更影响。

可选 UI 版本提供本地 3D 图谱视图，用来浏览代码库知识图谱。

它的定位很硬：速度、覆盖面、MCP 工具面。项目介绍中写到，平均仓库可以在毫秒级完成索引，Linux kernel 这类 28M LOC、75K 文件规模的仓库在 3 分钟内完成全量索引。它支持 158 种语言，Tree-sitter grammar 被 vendored 并编进二进制，安装后无需再为每个语言配 parser。

它的工具面比一般“代码搜索 MCP”宽很多，主要包括：

•index_repository：把仓库索引进图谱，后续可自动同步。

•list_projects / delete_project / index_status：管理已索引项目。

•search_graph：按 label、名称、文件模式、degree 等条件查节点。

•trace_path：做 BFS 调用追踪，查看谁调用了某函数、它又调用了谁。

•detect_changes：把 git diff 映射到受影响符号和风险分类。

•query_graph：运行只读 openCypher 子集。

•get_graph_schema：查看节点、边、属性和关系模式。

•get_code_snippet：按 qualified name 读取函数源码。

•get_architecture：输出语言、包、路由、热点、聚类和 ADR 概览。

•search_code：在已索引项目里做 grep-like 搜索。

•manage_adr：管理 Architecture Decision Records。

•ingest_traces：导入运行时 trace，用来校验 HTTP 调用边。

它的图数据模型也更像一个可查询的代码知识库：节点包括 Project、Package、Folder、File、Module、Class、Function、Method、Interface、Enum、Type、Route、Resource；边包括 DEFINES、IMPORTS、CALLS、HTTP_CALLS、IMPLEMENTS、TESTS、USES_TYPE、FILE_CHANGES_WITH 等。

我认为这个项目最有意思的是 Hybrid LSP。Tree-sitter 很快，也能抽结构，但它不擅长跨文件类型解析。比如 user.profile.display_name() 到底解析到哪里，涉及导入、继承、泛型、标准库类型和框架约定。codebase-memory-mcp 在 Tree-sitter 之上加了一层轻量类型解析，覆盖 Python、TypeScript/JavaScript、PHP、C#、Go、C/C++、Java、Kotlin、Rust、Perl 等语言，用来细化 CALLS、USAGE、RESOLVED_CALLS 边。

这让它更接近 IDE 的“Go to Definition”体验。不同之处在于，它没有启动一堆语言服务器，而是把算法做进二进制里。换句话说，它在 Agent 侧提供“可重复查询的仓库事实”，不再只是一段一次性的文本片段。

它还有一个很实际的安装策略：支持 43 个自动或条件配置的 Agent/IDE 表面，包括 Claude Code、Codex CLI、Gemini CLI、VS Code、Cursor、Windsurf、OpenCode、Kiro、Qwen Code、GitHub Copilot CLI、OpenClaw 等。对于不同客户端，它会根据能力写入 MCP 配置、AGENTS 指令、skill、hook 或 parent-handoff 代理定义。它没有把不稳定的客户端能力硬凑进去，这对这类工具很重要。

适合它的场景：

•想给多个 Agent 共享同一份代码库索引。

•仓库很大，普通 grep/read 循环消耗太多上下文。

•希望在 MCP 里直接做图查询、调用追踪、架构概览和变更影响分析。

•需要本地运行、无云依赖、容易审计的代码记忆层。

3. wigolo：给 Agent 补上网页证据层

一句话看它：代码之外的事实也要有记忆，尤其是文档、网页、产品页和社区资料。

前两个项目处理的是代码仓库。wigolo 处理的是另一个痛点：Agent 经常需要查公开网页、抓文档、读产品页、做多来源研究，但宿主工具要么是付费 API，要么没有缓存，要么返回结果缺少可追溯证据。

wigolo 把 search、fetch、crawl、extract、cache、find_similar、research、agent 等能力放在一个本地优先的工具面里。它可以作为 MCP server 跑在编码 Agent 旁边，也可以用 REST、SDK 或框架集成方式嵌入自托管 Agent。

wigolo 的定位：给 Agent 提供本地优先的 Web intelligence。

演示首帧：编码 Agent 通过 wigolo 回答实时网页问题。

它的基础工具不需要 API key：search、fetch、crawl、extract、cache、find-similar 可以直接跑。research、agent 和 search format=answer 需要 LLM 来合成带引用的答案，但也可以接 Gemini、Anthropic、OpenAI、Groq、Ollama 或 OpenAI-compatible 后端。

wigolo 返回结果时很强调“证据形状”。一个搜索结果不只包含标题和摘要，还会带 citation_id、url、byte-offset source_span、evidence_score、freshness_signal。弱结果会被标记，过期缓存会被标记，读取受阻时也会说明是挑战页、薄内容还是后端降级。Agent 至少知道自己站在什么证据上。

一个搜索结果的拆解：分数、来源片段、失败引擎和弱结果都会显式暴露。

在工具层，wigolo 提供十类常用能力：

•search：18 个直接搜索适配器，多引擎 rank fusion，ML rerank，可解释评分。

•fetch：按信号从 HTTP 升级到浏览器抓取，处理 SPA、PDF、section、登录态和页面动作。

•crawl：BFS、DFS、sitemap、map-only，带 robots.txt 和 per-domain rate limit。

•extract：抽表格、metadata、JSON-LD、Article/Recipe/Product 等 schema，或按自定义 JSON Schema 抽取。

•cache：查询已访问内容，支持 keyword 或 hybrid semantic。

•find_similar：按 URL 或概念查相似页面。

•research：拆问题、发散子查询、抓来源、生成带引用报告或 evidence brief。

•agent：自主收集循环，包含 plan、search、fetch、extract、synthesize 和 step log。

•diff / watch：追踪网页变化并通知 webhook。

对比演示首帧：wigolo 与内置 WebSearch、Tavily、Exa 在同一查询上的结果展示。

它和 Firecrawl、Exa、Tavily 的差异不在“能不能抓网页”，而在本地缓存、证据片段、可解释评分、无账号/无 per-query 计费这几个点。对于编码 Agent 来说，这意味着反复查同一批文档时不会每次都付费，也不会每次都丢掉已经见过的证据。

项目用计费表隐喻本地工具和按量云 API 的差异。

架构上，它是一个 Node 进程：对外提供 MCP、REST、SDK，内部有 fetch router、browser pool、cache、on-device embedding 和 reranker。确定性的工作尽量由代码完成，比如 canonicalization、rank fusion、dedup、schema matching；LLM 只在合成答案时按需使用。