为什么 Claude Code 放弃 RAG，转向 Agentic Search
最近在技术社区中，一条观点引发了不少讨论：Claude Code 在代码理解场景中放弃了 RAG，转而采用 Agentic Search。
这一决策来自 Claude Code 创始人 Boris Cherny 的实践经验。他甚至用一句非常工程化的话总结了这种方法：
所谓 Agentic Search，其实只是 glob 和 grep 的高级说法。
乍一看这似乎有些反直觉。毕竟 RAG 一直被认为是当前 AI 应用中最主流的知识检索方案。那么为什么在代码场景里，复杂的 RAG 反而不如传统的 Unix 搜索工具？要理解这一点，需要先看清两种技术路线的底层原理。
一、RAG 的基本原理¶
RAG 的核心思想是：通过检索外部知识来增强大模型的回答能力。
在标准的 RAG 系统中，一般包含以下流程。
首先，系统会将知识库中的文档拆分成多个文本块。这一过程通常称为 chunking，每个文本块通常在几百到一千个 token 左右。
接着，每个文本块会被转换成向量表示：
这里 \(f(\cdot)\) 表示 embedding 模型，它会把文本映射到一个高维向量空间。
当用户提出问题时，系统同样会把问题转成向量：
然后通过相似度搜索找到最相关的文本块。常见的计算方式是余弦相似度：
最后，把检索到的文本块和用户问题一起输入大模型：
用户问题 + 检索到的上下文 → LLM
大模型再基于这些上下文生成答案。
这种架构在很多场景中非常有效，例如：
-
企业知识库问答
-
文档检索系统
-
客服机器人
-
FAQ 系统
这些场景的共同特点是：信息以自然语言为主，语义相似度是有效的检索方式。
二、为什么 RAG 在代码场景中效果不佳¶
当我们把 RAG 直接应用到代码仓库时，问题开始出现。原因并不是 RAG 技术本身不好，而是 代码的结构特性与自然语言完全不同。
在工程实践中，主要存在四个核心问题。
1 代码定位依赖符号，而不是语义¶
RAG 的检索逻辑基于语义相似度，但代码的定位方式通常依赖符号信息，例如：
-
函数名
-
类名
-
文件路径
-
import 关系
-
调用关系
例如一段代码：
def compute_slope_stability():
如果用户提问：
稳定性计算在哪里实现
embedding 检索未必能找到这个函数。
但如果直接执行：
grep compute_slope_stability
几乎可以瞬间定位。
这说明在代码场景中，精确符号匹配往往比语义匹配更有效。
2 代码理解依赖全局结构¶
自然语言文本通常是相对独立的段落，但代码并不是这样。
例如一个简单的调用链：
A.py 调用 B.py
B.py 调用 C.py
如果代码被 RAG 切分成多个 chunk：
chunk1: A.py
chunk2: B.py
chunk3: C.py
向量检索可能只返回其中一部分内容，而缺失关键调用关系。
但在实际工程中，理解代码往往需要完整的：
-
调用链
-
类型定义
-
模块依赖
-
import 关系
RAG 的 chunk 机制会破坏这些结构。
3 文本切块破坏代码层级¶
代码仓库本身具有清晰的结构：
repository
├─ folder
│ ├─ file
│ │ ├─ class
│ │ │ ├─ method
这种层级结构对于理解代码非常重要。
但在 RAG 系统中，所有内容都会被拆分成无结构的文本块：
chunk_102
chunk_103
chunk_104
文件路径、模块边界和上下文关系都会丢失。
4 代码库更新频繁¶
代码仓库的变化速度远高于普通文档。
典型的开发流程包括：
git commit
git branch
git merge
如果使用 RAG，每次更新代码库都需要：
-
重新切分文档
-
重新生成 embedding
-
更新向量数据库
在大型仓库中，这一成本非常高。
三、Agentic Search 的核心思路¶
Claude Code 团队采用了一种更接近工程师工作方式的方法：Agentic Search。
简单来说，就是让大模型像程序员一样使用工具来探索代码仓库。
核心工具包括：
-
glob：查找文件
-
grep / ripgrep：搜索文本
-
tree：查看目录结构
-
open：读取文件内容
Agentic Search 的基本流程¶
当模型需要理解代码仓库时，会进行一系列循环操作：
第一步，搜索文件结构。
glob("*.py")
第二步，搜索关键词。
grep compute_slope
或者
rg compute_slope
第三步，打开相关文件。
open slope_analysis.py
第四步，根据新信息继续搜索。
例如：
grep factor_of_safety
整个过程会不断循环：
搜索 → 阅读 → 推理 → 再搜索
这就是所谓的 Agentic（代理式）行为。
四、为什么 Agentic Search 更适合代码¶
在代码仓库场景下，Agentic Search 具有明显优势。
| 能力 | RAG | Agentic Search |
|---|---|---|
| 函数定位 | 较弱 | 非常强 |
| 调用链分析 | 困难 | 容易 |
| 结构信息 | 容易丢失 | 完整保留 |
| 实时更新 | 成本高 | 成本低 |
| 工程可控性 | 较差 | 较好 |
本质上，两者的差别可以总结为：
RAG 是语义检索
Agentic Search 是工程检索
代码仓库显然更适合后者。
五、一个实际例子¶
假设一个代码仓库包含 50 万行代码，用户提出问题：
边坡稳定性算法在哪里实现
如果使用 RAG，系统可能会检索到：
-
一些文档说明
-
不完整的代码片段
-
与问题语义相近但不相关的函数
结果往往不稳定。
但如果使用 Agentic Search，模型可能会执行：
grep slope
grep stability
grep factor_of_safety
然后逐步打开相关文件：
open slope_analysis.py
继续查找调用关系：
grep compute_factor_of_safety
最终定位到真正实现算法的函数。
整个过程和工程师调试代码几乎完全一致。
六、总结¶
Claude Code 放弃 RAG 的原因并不是 RAG 技术不好，而是因为 代码仓库具有完全不同的信息结构。
自然语言知识库适合语义检索，而代码仓库更适合符号搜索和结构分析。
因此在代码理解场景中：
-
RAG 更像是 语义搜索引擎
-
Agentic Search 更像是 AI 驱动的代码探索工具
Boris Cherny 的那句话其实揭示了一个工程事实：
很多看似复杂的 AI 系统，最终可能只是对经典工具的一种自动化封装。
而在代码世界里，几十年前诞生的 Unix 工具 —— glob 和 grep —— 依然是最可靠的基础设施。