Coding Agent 代码检索技术全景：从 GREP 到知识图谱

Coding Agent 的核心能力之一是在陌生代码库中快速定位相关代码。无论是修复一个 bug、实现一个新功能，还是回答一个架构问题，Agent 的第一步几乎总是：找到相关的代码在哪里。

这个看似简单的问题，实际上是整个 Agentic Coding 领域最基础也最棘手的挑战。不同的 Coding Agent 给出了截然不同的答案——Claude Code 坚持用 grep，Cursor 构建了基于 Merkle 树的向量索引，Aider 用 PageRank 算法生成 RepoMap，Graphify 则把代码库变成了一张知识图谱。

这些方案之间是什么关系？是同一层次的竞争方案，还是不同层次的互补技术？各家的取舍逻辑是什么？未来的发展方向又在哪里？

本文从技术原理出发，逐层拆解当前主流的代码检索方案，分析它们的设计哲学与工程取舍，最终给出一个统一的分层理解框架。

全景导图

%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#e3f2fd','primaryTextColor':'#1565c0','primaryBorderColor':'#1976d2','lineColor':'#42a5f5','secondaryColor':'#fff3e0','tertiaryColor':'#f3e5f5','fontSize':'14px'}}}%%
mindmap
  root((代码检索技术栈))
    底层解析
      AST / Tree-sitter
      LSP / LSIF
    检索原语
      文本检索 GREP
      语义检索 RAG
    增强层
      知识图谱 / 代码图
      分层摘要
    编排层
      Agentic Retrieval
      混合检索策略

模式总览

#	模式名称	一句话口诀	覆盖场景
1	精确匹配	知道名字就直接找	GREP / ripgrep 文本搜索
2	语义召回	不知道名字但知道意图	RAG / 向量检索
3	结构导航	顺着代码结构走	AST 解析 / LSP 跳转
4	关系推理	顺着调用链和依赖图走	知识图谱 / 代码图
5	自主编排	Agent 自己决定用哪种	Agentic Retrieval

第一层：文本检索——GREP 与正则表达式

工作原理

文本检索是最朴素的代码检索方式：给定一个字符串或正则表达式，在文件系统中逐行扫描匹配。现代实现以 ripgrep（rg）为代表，通过 Rust 实现的高性能正则引擎、自动跳过 .gitignore 文件、并行文件扫描等优化，在百万行级代码库上实现毫秒级响应。

在 Coding Agent 的上下文中，GREP 通常被封装为一个工具（tool），Agent 通过自然语言理解用户意图后，自主构造搜索关键词调用该工具。典型的工具定义如下：

1 2	`Grep(pattern, include_pattern, case_sensitive) → 返回匹配行及其所在文件路径和行号`

谁在用

Claude Code 是 GREP 路线最坚定的实践者。Anthropic 的设计哲学是极简主义——不维护任何持久化索引，每次搜索都是实时的全文扫描。Claude Code 的工具箱中，Grep 和 Glob 是最核心的代码检索手段，配合 Read 工具读取文件内容，构成了完整的代码理解链路。

这种设计的取舍逻辑非常清晰：

优势	代价
零索引成本：无需预处理，即开即用	Token 消耗高：每次搜索都要扫描，结果可能很长
永远新鲜：不存在索引过期问题	无语义理解：搜"认证逻辑"找不到 `AuthService`
架构简洁：无外部依赖，无状态管理	依赖 Agent 智慧：搜索质量完全取决于 Agent 构造的关键词
确定性：相同输入必然相同输出	无法处理模糊意图：必须知道精确的标识符或字符串

社区对 Claude Code 的一个常见批评是"burns too many tokens"——Agent 在搜索过程中消耗大量 token 翻阅文件，有时 80% 的 token 花在了 Glob 和 Grep 上，最终给出的答案却似是而非。

模式提炼：精确匹配

模式公式：GREP {pattern} --include={file_type} → 匹配行 + 位置

场景	pattern	file_type	说明
查找函数定义	`def calculate_total`	`*.py`	精确定位函数
查找类引用	`AuthService`	`*.java`	追踪类的使用位置
查找配置项	`max_retry_count`	`*.yml`	定位配置来源
查找错误信息	`"Connection refused"`	`*`	从日志反查代码

核心洞察：当已知目标的精确名称（函数名、类名、变量名、错误信息）时，GREP 是最快、最可靠的检索方式。它的价值不在于"智能"，而在于确定性——相同的查询永远返回相同的结果，不受 embedding 模型版本、向量数据库状态的影响。

第二层：语义检索——RAG 与向量嵌入

工作原理

RAG（Retrieval-Augmented Generation）的核心思路是：将代码库中的代码片段转换为向量表示（embedding），存入向量数据库；当 Agent 需要检索时，将查询意图也转换为向量，通过向量相似度匹配找到语义最相关的代码片段。

在代码场景中，RAG 的 pipeline 通常包含以下步骤：

1
2
3

代码库 → 切分（Chunking）→ 向量化（Embedding）→ 存储（Vector DB）
                                                          ↓
用户查询 → 向量化 → 相似度匹配 → Top-K 结果 → 注入 LLM 上下文

其中，切分策略是代码 RAG 区别于文本 RAG 的关键难点。文本 RAG 可以按段落或固定长度切分，但代码有严格的结构边界——在函数中间切断会丢失语义完整性。主流的切分策略包括：

切分策略	优势	劣势
按文件	实现简单	大文件浪费 token，小文件信息不足
按函数/类	语义完整	需要 AST 解析支持
按 AST 节点	结构精确	实现复杂，跨节点关系丢失
滑动窗口	灵活	可能切断语义单元

谁在用

Cursor 是 RAG 路线工程化程度最高的实践者。根据 Cursor 官方博客（Secure Codebase Indexing），其索引系统的核心架构包含以下关键设计：

Merkle 树变更检测：用 SHA-256 哈希构建文件树的 Merkle 树，仅对变更文件重新生成 embedding，避免全量重算。这将大型仓库的索引时间从小时级降至秒级（99 百分位从 4.03 小时降至 21 秒）。
Tree-sitter AST 切分：使用 tree-sitter 将代码按语义单元（函数、类、方法）切分，而非简单的文本分块，确保每个 chunk 的语义完整性。
跨用户索引复用：通过 simhash 计算仓库相似度，92% 以上相似度的仓库可直接复用已有索引，避免重复计算。
访问控制：通过 Merkle 树的内容证明（content proof）机制，确保用户只能访问自己有权限的文件的索引结果。

GitHub Copilot 在 2025 年推出了专用的代码 embedding 模型，相比通用模型，检索质量提升 37.6%，吞吐量翻倍，索引体积缩小 8 倍。即时语义索引时间从 5 分钟降至几秒。

Windsurf（Codeium） 采用 RAG + 自研 M-Query 技术，支持本地代码库索引和远程仓库索引（企业版），并提供上下文固定（Context Pinning）功能，允许用户手动锁定关键文件始终在上下文中。

RAG 的已知挑战

代码 RAG 面临几个结构性难题：

跨文件关系丢失：向量检索本质上是单点匹配——找到与查询最相似的代码片段，但无法捕捉代码片段之间的调用关系、继承关系、数据流关系。"函数 A 调用了函数 B"这类信息在向量空间中是不可见的。
Embedding 模型的代码理解局限：通用 embedding 模型对代码语义的理解有限。calculateTotal 和 computeSum 语义相近但写法不同，close 在文件操作和 UI 操作中含义完全不同——这些细微差异对向量模型是巨大挑战。
索引维护成本：代码库频繁变更，索引需要持续更新。Cursor 通过 Merkle 树解决了增量更新问题，但这本身就是一个复杂的工程系统。
长上下文窗口的冲击：随着 Gemini 等模型支持百万级 token 上下文窗口，一个自然的问题是：还需要 RAG 吗？直接把整个代码库塞进上下文不就行了？实践表明，长上下文并不能完全替代 RAG——注意力机制在超长文本中的信息提取效率会下降（"lost in the middle"问题），且 token 成本线性增长。但长上下文确实降低了 RAG 的必要性阈值：对于中小型项目，直接加载可能比维护索引更划算。

模式提炼：语义召回

模式公式：EMBED(query) → SIMILARITY_SEARCH(vector_db, top_k) → 相关代码片段

场景	查询	GREP 能否解决	RAG 优势
“认证逻辑在哪里”	自然语言意图	不能（不知道搜什么词）	语义匹配到 `AuthService`
“处理支付超时的代码”	模糊描述	困难（关键词不确定）	匹配到 `PaymentTimeoutHandler`
“数据库连接池配置”	概念性查询	部分（可搜 `pool`）	匹配到 `HikariConfig`

核心洞察：RAG 解决的是"知道意图但不知道名字"的检索场景。它与 GREP 不是替代关系，而是互补关系——GREP 处理精确匹配，RAG 处理模糊意图。最佳实践是混合使用：先尝试 GREP（快速、确定），GREP 无结果时回退到 RAG（语义、模糊）。

第三层：结构化解析——AST 与 LSP

AST：抽象语法树

AST（Abstract Syntax Tree）解析是代码理解的基础设施。与 GREP 的"把代码当文本"和 RAG 的"把代码当向量"不同，AST 解析把代码当代码——理解其语法结构、符号定义、作用域关系。

在 Coding Agent 领域，tree-sitter 是事实上的标准 AST 解析器。它的核心优势是：

增量解析：代码变更时只重新解析变更部分，而非整个文件
多语言支持：通过语法定义文件支持 100+ 种编程语言
容错解析：即使代码有语法错误也能生成部分 AST
高性能：C 语言实现，解析速度极快

Aider 的 RepoMap 是 AST 在 Coding Agent 中最经典的应用。其工作原理如下（Aider RepoMap 文档）：

使用 tree-sitter 提取代码库中所有符号（类、函数、方法、变量）的定义和引用
构建文件依赖图：节点是文件，边是依赖关系（文件 A 引用了文件 B 中定义的符号）
用 PageRank 算法计算每个符号的重要性——被引用越多的符号越重要
根据 token 预算（默认 1024 tokens）动态选择最重要的符号，生成一份精简的"仓库地图"发送给 LLM

这种设计的精妙之处在于：用经典的图算法（PageRank）在极小的 token 预算内最大化信息密度。Aider 在 SWE-Bench 上排名第二，证明了这种轻量级方案的有效性。

LSP：语言服务协议

LSP（Language Server Protocol）提供了比 AST 更高层次的代码理解能力。AST 解析的是单个文件的语法结构，而 LSP 提供跨文件的语义理解：

LSP 能力	作用	对 Agent 的价值
Go to Definition	跳转到符号定义	追踪函数/类的实现位置
Find References	查找所有引用	评估修改的影响范围
Hover Info	获取类型信息	理解变量/参数的类型
Call Hierarchy	调用层次	理解函数的上下游关系
Workspace Symbols	工作区符号搜索	按名称模糊搜索符号

LSP 的核心价值在于类型感知和跨文件导航。GREP 搜索 calculateTotal 会返回所有包含这个字符串的行（包括注释、字符串字面量、不同类中的同名方法），而 LSP 的 Find References 只返回真正引用了特定 calculateTotal 方法的位置，且能区分不同类中的同名方法。

LSP 的局限性在于：

启动成本高：语言服务器需要加载整个项目的类型信息，启动时间可能达到数十秒
语言绑定：每种语言需要独立的语言服务器实现，质量参差不齐
IDE 依赖：LSP 设计上是为 IDE 服务的，在终端环境（如 Claude Code）中集成成本较高
动态语言支持弱：对 Python、JavaScript 等动态类型语言，类型推断能力有限

模式提炼：结构导航

模式公式：PARSE(code) → STRUCTURE(symbols, relations) → NAVIGATE(query) → 精确定位

场景	AST 能力	LSP 能力	GREP/RAG 能力
“这个函数定义在哪”	提取定义位置	Go to Definition	文本搜索（可能有误匹配）
“谁调用了这个方法”	提取引用关系	Find References	文本搜索（包含误匹配）
“这个变量是什么类型”	无（需类型推断）	Hover Info	无法获取
“修改这个类会影响哪些文件”	构建依赖图	Call Hierarchy	无法精确评估

核心洞察：AST 和 LSP 不是检索工具，而是解析基础设施。它们为 GREP、RAG、知识图谱提供结构化的输入——tree-sitter 的 AST 解析被 Cursor 用于 RAG 的 chunking，被 Aider 用于 RepoMap 的符号提取，被 Graphify 用于知识图谱的节点构建。LSP 则提供了 AST 之上的跨文件语义层。

第四层：知识图谱与代码图

工作原理

知识图谱方案的核心思路是：将代码库建模为一张图（Graph），节点代表代码实体（文件、类、函数、变量、概念），边代表实体间的关系（调用、继承、导入、依赖、语义相似）。检索时通过图遍历而非向量匹配来定位相关代码。

与 RAG 的关键区别在于：

维度	RAG（向量检索）	知识图谱（图检索）
数据模型	独立的文本块 + 向量	节点 + 边的图结构
检索方式	向量相似度匹配	图遍历 + 子图提取
关系保持	丢失（每个 chunk 独立）	显式建模（边）
多跳推理	不支持	支持（沿边遍历）
可解释性	低（向量空间黑箱）	高（可追溯每条边）
构建成本	中（embedding 计算）	高（AST 解析 + LLM 提取 + 图构建）

代表方案

Graphify（GitHub）是当前最活跃的开源代码知识图谱工具，其 pipeline 为：

1	`detect() → extract() → build_graph() → cluster() → analyze() → report() → export()`

关键技术选择：

确定性 AST 提取：代码文件通过 tree-sitter 解析，不消耗 LLM token
LLM 语义提取：文档、论文、图片通过 LLM 提取概念和关系
Leiden 社区发现：基于图拓扑（而非 embedding）进行聚类，可解释性强
71.5 倍 token 压缩率：在 Karpathy 混合语料库上实测，因为只返回相关子图而非全文

（关于 Graphify 的详细技术分析，参见 Graphify 深度解析：用知识图谱重新定义 AI 编码助手的代码理解能力）

codemap（Graham Brooks，Rust 实现）采用 tree-sitter + SQLite + MCP 协议的架构，提供 17 个 MCP 工具（codemap-search、codemap-callers、codemap-callees、codemap-impact 等），支持增量索引（SHA-256 哈希）和影响分析（变更传播路径计算）。

Sourcegraph Cody 结合 LSIF（Language Server Index Format）构建精确的跨仓库代码关系图，是企业级代码图方案的代表。

HCGS（Hierarchical Code Graph Summarization，arXiv 2504.08975，2025 年 4 月）是学术界的前沿方案，采用自底向上的分层摘要策略：先为每个函数生成摘要，再为每个类生成摘要，最后为每个模块生成摘要。在 libsignal 数据集上，top-1 检索精度提升 82%。

模式提炼：关系推理

模式公式：BUILD_GRAPH(codebase) → QUERY(subgraph, hops) → 相关实体 + 关系路径

场景	向量检索能力	图检索能力
“函数 A 如何最终调用数据库”	无法回答（多跳）	沿调用链遍历
“修改这个接口会影响哪些服务”	无法精确评估	影响分析（传播路径）
“这个模块的核心概念有哪些”	返回相似文本块	返回社区子图 + 关系
“这两个类之间是什么关系”	无法回答	返回最短路径 + 关系类型

核心洞察：知识图谱解决的是"关系"问题——代码实体之间的调用、依赖、继承、组合关系。向量检索擅长"找到相似的东西"，图检索擅长"找到相关的东西"。"相似"和"相关"是两个不同的概念：AuthService 和 UserService 在向量空间中可能不相似，但在调用图中高度相关。

第五层：Agentic Retrieval——Agent 自主编排

从固定 Pipeline 到自主决策

前四层技术（GREP、RAG、AST/LSP、知识图谱）都是检索原语——它们各自解决特定类型的检索问题。真正的挑战在于：面对一个具体的编码任务，Agent 应该使用哪种检索方式？

传统方案是预定义 pipeline：先 GREP，再 RAG，最后 LSP。但这种固定流程无法适应任务的多样性——有些任务只需要一次精确的 GREP，有些任务需要多轮语义搜索，有些任务需要沿着调用链追踪。

Agentic Retrieval 的核心思想是：让 Agent 自主决定使用哪种检索工具、何时使用、使用多少次。Agent 不再是检索 pipeline 的执行者，而是检索策略的规划者。

Claude Code 的"Agent Search"模式是这一趋势的典型代表：LLM 自主决定何时 grep、何时读文件、何时扩大搜索范围、何时停止搜索。搜索策略不是预定义的，而是根据任务动态生成的。

混合检索的实践

最前沿的方案正在走向混合检索——在同一个系统中集成多种检索原语，由 Agent 或编排层动态选择：

用户查询
    ↓
┌─────────────────────────┐
│   Agentic Orchestrator  │  ← Agent 自主决定策略
│   (LLM 规划 + 反馈)      │
├─────────┬───────────────┤
│ 精确匹配 │  语义匹配      │  ← 检索原语（并行/串行）
│ (GREP)  │  (RAG/BM25)   │
├─────────┴───────────────┤
│    结构化解析 (AST/LSP)   │  ← 解析基础设施
├─────────────────────────┤
│    知识图谱 (Graph)       │  ← 关系增强
└─────────────────────────┘

具体的混合策略包括：

Keyword + Semantic：BM25（关键词匹配）和向量检索的加权融合，兼顾精确性和语义理解
ColBERT 晚期交互：ColGrep 等方案将 ColBERT 的 token 级交互直接应用于本地文件，实现"更强的 grep"
GraphRAG：Neo4j 等图数据库提供的混合方案，结合 Cypher 图查询和向量搜索
分层 RAG：低层做实体级检索（函数、类），高层做社区级摘要检索（模块、子系统）

各家 Coding Agent 的技术选型对比

Agent	核心方案	关键技术	设计哲学	目标场景
Claude Code	纯 GREP（无状态）	ripgrep + glob + Agent Search	极简主义：牺牲 token 换架构简洁	中小项目、偏好简洁的开发者
Cursor	Merkle 树 + 向量嵌入	SHA-256 变更检测 + tree-sitter 切分 + simhash 索引复用	工程化极致：解决大规模索引的性能瓶颈	大型团队、企业级项目
GitHub Copilot	专用 Embedding 模型	代码专用 embedding + 多层搜索策略	准确性优先：投入模型研发提升检索质量	企业级、大规模代码库
Windsurf (Codeium)	RAG + M-Query	本地/远程双索引 + 上下文固定	灵活性优先：平衡本地速度与远程协作	混合开发环境
Aider	RepoMap（PageRank）	tree-sitter 符号提取 + PageRank 排序	Token 效率优先：经典算法最大化信息密度	终端用户、轻量级配对编程
Graphify	知识图谱	tree-sitter + LLM + Leiden 聚类	结构优先：用图拓扑替代向量空间	架构理解、大型代码库导航

这张对比表揭示了一个重要事实：没有"最好"的代码检索方案，只有最适合特定场景的方案。各家的技术选型反映了它们对目标用户和使用场景的不同判断：

Claude Code 赌的是 LLM 的推理能力足够强，能通过自主搜索弥补索引的缺失
Cursor 赌的是工程化的索引系统能提供更好的开发体验
Aider 赌的是经典算法在 token 受限场景下的效率优势
Graphify 赌的是结构化的代码理解比扁平的文本/向量检索更有价值

分层理解框架：互补而非竞争

综合以上分析，代码检索技术栈可以用一个四层互补架构来理解：

┌─────────────────────────────────────────────┐
│          Layer 4: Agentic Orchestration      │
│    Agent 自主决定检索策略（最高层）              │
│    Claude Code Agent Search / LangGraph      │
├──────────────────┬──────────────────────────┤
│   Layer 3a:      │   Layer 3b:              │
│   Text Search    │   Semantic Search        │
│   GREP (精确匹配) │   RAG (语义召回)          │
│                  │                          │
│   ← 检索原语，同一层，互补 →                   │
├──────────────────┴──────────────────────────┤
│          Layer 2: Knowledge Graph           │
│    代码图 / 知识图谱（关系增强层）               │
│    Graphify / codemap / Sourcegraph         │
├─────────────────────────────────────────────┤
│          Layer 1: Structural Parsing        │
│    AST (tree-sitter) / LSP / LSIF          │
│    确定性结构解析（底层基础设施）                │
└─────────────────────────────────────────────┘

层次关系说明：

Layer 1（结构解析） 是所有上层技术的基础。tree-sitter 的 AST 解析被 Cursor 用于 RAG chunking，被 Aider 用于 RepoMap 构建，被 Graphify 用于图节点提取。LSP 在 AST 之上提供跨文件语义。
Layer 2（知识图谱） 是 Layer 1 的增强。它利用 AST/LSP 提供的结构信息构建代码实体间的关系图，支持多跳推理和影响分析——这是 Layer 3 的检索原语无法独立完成的。
Layer 3（检索原语） 是直接面向查询的检索层。GREP 和 RAG 是同一层次的互补技术：GREP 处理精确匹配，RAG 处理模糊意图。两者都可以利用 Layer 1/2 的结构信息来提升检索质量。
Layer 4（Agentic 编排） 是最高层的策略层。Agent 根据任务特征动态选择使用哪些检索原语、以什么顺序使用、使用多少次。这一层的质量直接取决于 LLM 的推理能力。

关键结论：这些方案不是同一层次的竞争关系。AST/LSP 是底层解析技术，GREP 和 RAG 是检索原语，知识图谱是关系增强层，Agentic Retrieval 是编排层。它们解决的是不同层次的问题，最佳实践是分层组合使用。

发展趋势

趋势一：混合检索成为标准配置

单一检索方式的局限性已经被充分认识。未来的 Coding Agent 将标配混合检索能力：精确匹配（GREP/BM25）+ 语义匹配（向量检索）+ 结构导航（AST/LSP）+ 关系推理（知识图谱），由 Agent 根据任务动态编排。

趋势二：MCP 成为检索工具的标准接口

MCP（Model Context Protocol）正在成为 AI 工具集成的标准协议。codemap 通过 MCP 暴露 17 个代码图查询工具，Graphify 通过 MCP 提供图谱查询能力。这意味着任何兼容 MCP 的 Coding Agent 都可以即插即用地获得知识图谱能力，而无需深度集成。

趋势三：Token 经济性驱动方案选择

Token 成本正在成为方案选择的核心指标。Graphify 的 71.5 倍压缩率、Aider 的 1K token 预算 RepoMap、Cursor 的增量索引——这些设计的共同目标都是在有限的 token 预算内最大化信息密度。随着 Agent 任务的复杂度增加（多轮对话、多文件修改），token 效率的重要性只会进一步上升。

趋势四：长上下文窗口重新定义 RAG 的边界

百万级 token 上下文窗口的出现，正在重新定义 RAG 的适用边界。对于中小型项目（< 10 万行代码），直接将代码库加载到上下文中可能比维护 RAG 索引更简单、更可靠。RAG 的核心价值将聚焦于大型代码库和需要持久化索引的企业场景。

趋势五：从"检索"到"理解"

最终的发展方向不是更好的检索，而是更深的理解。知识图谱、分层摘要、社区发现等技术的目标，不仅仅是"找到相关代码"，而是"理解代码库的架构、模式和设计意图"。当 Agent 能够真正理解代码库的全局结构时，检索将不再是瓶颈——Agent 会像经验丰富的开发者一样，直觉性地知道该去哪里找。

模式速查表

听到的需求关键词	对应模式	推荐方案	口诀
“这个函数在哪定义的”	精确匹配	GREP / LSP Go to Definition	知道名字就直接找
“认证逻辑在哪里”	语义召回	RAG 向量检索	不知道名字但知道意图
“谁调用了这个方法”	结构导航	LSP Find References / AST	顺着代码结构走
“修改这个接口的影响范围”	关系推理	知识图谱影响分析	顺着调用链和依赖图走
“这个模块的整体架构”	关系推理	知识图谱社区子图	看地图而非逐条街走
“帮我找到并修复这个 bug”	自主编排	Agentic Retrieval	Agent 自己决定用哪种

%%{init: {'theme':'base', 'themeVariables': {'primaryColor':'#e3f2fd','primaryTextColor':'#1565c0','primaryBorderColor':'#1976d2','lineColor':'#42a5f5','secondaryColor':'#fff3e0','tertiaryColor':'#f3e5f5','fontSize':'14px'}}}%%
flowchart LR
    A[编码任务] --> B{已知精确名称?}
    B -->|是| C[GREP 精确匹配]
    B -->|否| D{已知模糊意图?}
    D -->|是| E[RAG 语义召回]
    D -->|否| F{需要关系推理?}
    F -->|是| G[知识图谱遍历]
    F -->|否| H[AST/LSP 结构导航]
    
    C --> I[Agent 综合判断]
    E --> I
    G --> I
    H --> I
    I --> J[生成回答/执行操作]

参考资料

Cursor Blog: Secure Codebase Indexing — Cursor 的 Merkle 树索引架构详解

Aider: Repository Map — Aider 的 tree-sitter + PageRank RepoMap 机制

Graphify GitHub — 开源代码知识图谱工具

Graham Brooks: Building a Code Knowledge Graph for AI Agents — codemap 的 MCP 代码图方案

HCGS: Hierarchical Code Graph Summarization (arXiv 2504.08975) — 分层代码图摘要，2025 年 4 月

Sourcegraph: How Cody Understands Your Codebase — Sourcegraph 的代码图理解方案

Anthropic 2026 Agentic Coding Trends Report — Agentic Coding 趋势报告