Agent 大仓库代码搜索方案调研

摘要

「让 AI agent 高效读大仓库」在 2026 年长成了一个完整的技术栈。我们记录五个事实：

1. (1) 检索方案分四层，是互补不是替代：① 文本检索（ripgrep）· ② 符号/结构检索（serena、ast-grep）· ③ 代码知识图谱（graphify、codegraph 等）· ④ 索引协议与基础设施（SCIP、zoekt、tgrep）。[E18]
2. (2) ripgrep 仍是底座：2016 年发布、68.7k star，本机实测 15.1.0；2026 年主流 coding agent 的 Grep 工具底层都是 rg 或同型实现——零索引、零幻觉、零建图成本。[E01]
3. (3) 「代码知识图谱」赛道爆发但泥沙俱下：graphify（122.6k）、codegraph（72.4k）、codebase-memory-mcp（45.5k）、code-review-graph（31.9k）四个 2026 年 1–4 月创建的仓库，star 增速超过 GitHub 史上几乎所有自然增长仓库——引用其性能声明前必须独立验证。[E04,E05,E06,E07]
4. (4) 精确检索的尽头是编译器：SCIP 协议 + scip-clang 提供零歧义的符号索引（编译期解析），代价是必须能构建；agent 场景里它是「贵但准」的极端选项。[E10]
5. (5) tgrep 的出现标志预索引 grep 独立成层：Microsoft 2026-04 发布 trigram 索引 grep（client/server），在「无索引的 rg」与「重图谱」之间补上了中间档；同名工具歧义见 5.2 节。[E09]

Top 10 逐个对比见第 2 章；增速异常的完整证据链见第 3 章；四层组合建议见第 4 章。

1 四层格局：agent 怎么读一个大仓库

agent 面对百万行仓库时的检索需求其实是四种不同的问题，对应四个技术层次：

为什么 ③ 层在 2026 年爆发：机制的解释是「上下文窗口经济学」——整文件阅读浪费 token，agent 平台的计费与速度都按 token 走，「先建图、按需查」在账面上能把上下文缩减一个数量级。加上 Claude Code 的 Skill/MCP 生态给了现成分发渠道（graphify 直接做成 /graphify skill），新项目可以极低成本触达用户。[E04]替代解释是「AI 编码工具的繁荣让低质量项目也能借关键词刷榜」——两个解释都成立，第 3 章的证据支持后者至少部分为真。

2 Top 10 全景

综合用户点名与检索补充，按四层选出 10 个方案。所有 star 为 2026-09-29/30 GitHub API 统一读数；4 个增速异常项目单独成图，不与可信项目并排比较。

2.1 重点项目

2.2 其余方案速览

star 为 2026-09-29/30 GitHub API 实测读数 [E01–E10]；创建时间为仓库创建年月。⚠️ 标记的含义见第 3 章。

3 增速异常警告：四个图谱项目的 star 不能当采用度证据

调研中发现的最重要的「负面事实」：用户点名项目里的 graphify、CodeGraph、code-review-graph，加上检索补充的 codebase-memory-mcp，四个代码知识图谱项目的 star 增速不合理。

读数为 2026-09-29/30 GitHub API 实测 [E04–E07]；「创建 → 读数」时间差按月取整。

我们的判断：这 4 个仓库的 star 数不能当作采用度证据使用。可能但无法排除的解释包括星标互刷、空转 fork、营销投放；作为对照，ripgrep 用了约 4 年到 30k star，ast-grep 用了 3 年到 16k——「代码智能」类工具的自然增长从未有过这个速度。技术本身（tree-sitter 建图、MCP 分发）不因增速造假而失效，但 README 里的性能数字（71.5x token 缩减等）在独立复现出现之前应视为未验证声明。

对选型的含义：第 2 章的技术定位分析对 4 个可疑项目依然成立（它们的机制描述与 README 代码结构可以核对），但选型时建议优先选增速正常、社区可查的同类（CodeGraphContext、code-graph-rag），或以 serena + ast-grep 的组合替代「建图」需求。[E05,E06]

4 怎么选怎么配：四层叠加，不是四选一

四层不是四选一，是分层叠加。一个给 agent 配检索栈的决策路径：

两条工程纪律。其一，索引新鲜度是所有 ③④ 层方案的共同命门——代码改了图没更新，agent 拿到的是过期地图；选型时把「改代码到索引更新」的延迟当作第一指标（codegraph 主打自动同步、code-review-graph 主打增量索引，均为 README 声明，未独立验证）。其二，检索栈要可降级：图谱服务挂掉时，agent 应能自动退回 ripgrep/serena 继续干活——把 ① 层当作永远在线的保底。[E18]

5 方法、数据来源与局限性

5.1 方法

选样。用户提供 6 个名字：graphify、CodeGraph、code-review-graph、scip-clang、tgrep、ripgrep。逐一核实后补充 4 个以凑齐四层代表：serena、ast-grep、zoekt、SCIP 协议（与 scip-clang 合并计为一项）。纳入标准：GitHub 可检索、与「agent 大仓库检索」直接相关、四层各有代表。

事实采集。star 数与创建日期以 2026-09-29/30 GitHub API 统一读数为准；ripgrep 在本机实测（15.1.0）。仓库描述与机制说明以 README 为准逐条核对。同一仓库的两次 API 查询曾返回不一致结果（详见 5.3），所有写入本报告的读数均为最终一轮统一查询的返回值。

四层归属与象限定位。Figure 2.3 的象限与第 1 章的分层是定性判断（依据 README 机制描述），用于看格局。

5.2 tgrep 消歧

「tgrep」存在多个同名物：Text REtrieval Conference 的 tgrep2（语料库树查询工具，非代码搜索）、若干零星同名小仓库，以及 Microsoft 2026-04 发布的 trigram 索引 grep。在「agent 大仓库检索」语境下，本报告采用 microsoft/tgrep 为指代；若读者另有所指，结论不适用。[E09]

5.3 局限性与替代解释

数据源可靠性问题（本报告自己的）。调研期间 GitHub 搜索与 API 的返回结果出现过不稳定：同一仓库两次查询的 star 数不一致、个别查询返回了与查询词高度耦合的可疑仓库列表。本报告的处理：所有 star/日期以最终一轮 API 读数为准并在速查表标注读数时间；无法稳定复核的条目不入样。读者引用任何 GitHub star 数前都应意识到它随时可变且可被操纵。

「增速异常」判断的边界。第 3 章的判断依据是增速对比（同赛道自然项目的历史曲线）与 README 营销特征，属于「红旗提示」而非「造假实锤」——不存在公开证据证明任何刷星行为。被点名的 4 个项目可能通过合法投放获得星标；本报告只主张「其 star 数不能作为采用度与技术有效性的证据」。[E04–E07]

性能声明未独立验证。graphify 的「71.5x token 缩减」、code-review-graph 的评审基准等数字均来自项目 README，本报告未复现。第 4 章的成本对比（Figure 4.1）是定性估计，基于机制描述而非基准测试。

样本偏差。偏 GitHub 开源与英文社区；Sourcegraph、GitHub 内部的代码搜索平台等闭源实现只在机制层面提及。第 ③ 层新项目极多，本报告仅纳入检索补充中出现且有完整 README 的代表，不构成该层全景。

时效。该赛道月度变化显著（4 个异常项目全部创建于本报告前 8 个月内）。数据截至 2026-09-30。

数据速查表

10 个方案关键属性一页汇总。

star 为 2026-09-29/30 GitHub API 实测 [E01–E10]；⚠️ 条目见第 3 章。