Claude Code为何放弃RAG，选择Grep搜索代码

一个反直觉的技术选择

Claude Code 走红之后，不少开发者发现了一件颇为反直觉的事：这款主打 AI 编程的工具，在检索代码时用的并不是当下 AI 圈最火的 RAG（检索增强生成），而是回归到最传统的 Grep 命令，逐行翻找代码。

在向量检索被奉为主流方案的今天，Anthropic 团队为何选择了这样一条看似「落后」的路径？背后其实隐藏着对代码检索场景本质的深刻理解。搞懂这个取舍，能帮我们看清当下 AI 编程工具的一个共同演进方向。

RAG 是什么，为什么在代码场景会失灵

RAG（Retrieval-Augmented Generation，检索增强生成）的工作流程并不复杂：先把文档资料向量化存入向量数据库，用户提问时系统进行语义检索，找出相关内容片段，再把这些片段喂给大模型生成回答。

RAG 的核心依赖向量嵌入（Vector Embedding）技术——将文本转化为高维数值向量，使语义相近的内容在向量空间中距离更近。这一技术起源于2013年 Google 发布的 Word2Vec 模型，此后经过 BERT、Sentence-BERT 等模型持续演进，已成为 NLP 领域的基础设施。其核心思想是将离散的文本符号映射到连续的高维空间（通常512到4096维），赋予机器理解「近义词」「同义改写」的能力。

然而，向量嵌入在代码场景面临一个根本性挑战：代码的语义单元本质上是人为约定的符号系统，而非具有普遍语义共识的自然语言词汇。嵌入模型的训练语料主要来自自然语言文本——代码虽然也可以被嵌入，但代码的「意义」更多依赖于结构关系（调用链、继承关系、作用域）而非词义本身。getUserById(id) 这个函数名对嵌入模型而言确实「语义相近」于 fetchUserData(userId)，但两者在代码追踪场景中完全是两个不同的函数调用——向量空间捕捉不到这种结构层面的差异。

嵌入模型的模糊匹配特性，在自然语言场景是优势，在代码场景却成了噪音来源：语义相似但功能完全不同的代码片段会被错误地归为「相近」，而真正相关但命名风格迥异的代码又可能被忽视。

这套方案在企业知识库问答、文档检索等场景表现优秀，因为这类场景需要的恰恰是模糊语义理解能力。然而一旦搬到写代码的场景，问题就接踵而至。

代码检索的四个核心痛点

第一，精确匹配问题。 程序员要找一个函数定义在哪、一个变量在哪些地方被引用，这是有明确对错的问题，不是「差不多像就行」。RAG 依靠语义相似度匹配，这种模糊匹配放到需要精确定位的场景，反而容易找偏。

第二，实时性问题。 代码改动极其频繁，刚改完一行代码，向量索引还没来得及更新——这个延迟是硬伤。写代码是高频交互的过程，根本等不起索引重建。向量索引的更新通常需要经历「变更检测→重新嵌入→写入数据库」的完整流水线，在活跃开发场景下，一个文件可能每隔几分钟就被修改，索引的滞后性会持续累积，最终导致检索结果与实际代码状态严重脱节。

第三，成本问题。 维护一套向量数据库，无论计算资源还是存储都是持续性开销，规模一大这笔账并不划算。

第四，可解释性问题。 RAG 返回的结果很难说清为什么偏偏是这几条被匹配出来，出了问题排查起来格外费劲。

相比之下，Grep 是纯文本匹配，搜索逻辑透明，出错了一眼就能看明白。值得一提的是，Claude Code 底层用的其实是 RipGrep——这是由 Andrew Gallant 用 Rust 语言开发的现代化文本搜索工具，速度比原生 Grep 快得多。

RipGrep 的性能优势来自多个技术层面的协同优化：它采用了基于有限自动机（Finite Automaton）的正则引擎，并集成 SIMD（单指令多数据流）指令集，可在单个 CPU 周期内并行比较多个字节；Rust 语言的零成本抽象保证了极高吞吐量的同时避免不必要的内存分配；而其智能文件过滤机制会自动跳过二进制文件、默认递归搜索并自动尊重 .gitignore 规则，天然适配代码仓库结构——这一特性对 AI 编程工具尤为重要，因为它确保了搜索范围与代码仓库的实际有效内容完全同步，不会因索引失效而产生脏数据问题。在基准测试中，对百万行级代码库进行正则搜索，RipGrep 通常比 GNU Grep 快5到10倍，这使它成为 VS Code、Neovim 等主流编辑器内置搜索后端的事实标准。

被讲错的「混合策略」真相

关于 Claude Code 的实现方式，有一个特别容易讲错的地方需要重点澄清。

很多资料声称 Claude Code 采用的是「Grep 主力、RAG 辅助」的混合策略——这个说法并不准确。

真实情况是：Anthropic 团队早期确实尝试过配一套本地向量检索，但测试下来发现效果反而不如让 AI 自己去操作搜索工具。于是现在的做法变成了：让大模型完全依靠自身的推理能力，像人一样一步步探索代码库。

Agentic Search 的工作流程

Agentic Search 是更广泛的 AI Agent（智能体）范式在信息检索领域的具体应用。传统 RAG 是一种「被动检索」——由系统预先决定检索逻辑；而 Agentic Search 本质上是赋予大模型工具调用（Tool Use / Function Calling）能力，让模型自主决策何时搜索、搜什么、搜完后如何判断是否充分。

这一范式的理论基础可追溯到 ReAct（Reasoning + Acting）框架——由 Yao 等人于2022年在论文《ReAct: Synergizing Reasoning and Acting in Language Models》中正式提出。ReAct 的核心创新在于：它证明了让语言模型交替输出「Thought（思考）」、「Action（行动）」和「Observation（观察）」三种内容，不仅能显著提升复杂任务的完成质量，还能大幅降低模型产生幻觉的概率——因为每一步行动都有真实环境的反馈作为「锚点」，迫使模型将推理建立在可验证的观察之上，而非凭空延伸。

这一框架本质上是将强化学习中「感知-行动-反馈」循环移植到了语言模型推理过程中。在代码探索场景下，这意味着模型不是一次性决定「搜索什么」，而是可以在读取一个文件后重新评估搜索方向，甚至在发现预期内容不存在时主动切换策略——这种动态假设验证能力是静态 RAG 流水线无法具备的，它使得 AI 对代码库的理解过程更接近有经验工程师的真实认知模式。Anthropic 在构建 Claude 的工具调用能力时深度采用了这一思路，也使 Claude Code 的代码探索更具适应性。

这套流程大致是这样的：

1. AI 先分析需求，构造出搜索策略；
2. 用文件查找工具定位大概范围；
3. 用文本搜索工具精确定位内容；
4. 读取相关文件、获取上下文；
5. 读完后 AI 自行判断——是继续搜索还是已找到答案。

这个过程会反复迭代好几轮，直到问题解决为止。

本质区别就在这里：它不是靠向量相似度去猜语义，而是靠大模型的推理能力主动构造搜索策略。这一整套方案有个专门的名字，叫 Agentic Search（智能体驱动的搜索）。

Agentic Search 并非没有局限

客观来看，这套方案同样存在不足。

第一，Token 消耗问题。 让 AI 反复读文件、反复搜索，这个过程消耗的 Token 确实不少。有研究指出，大约三分之一的文件读取存在冗余。

这一问题需要从两个层面深入理解。Token 是大语言模型处理文本的基本单位（英文约4字符对应1个 Token，中文约1至2个汉字对应1个 Token），而上下文窗口（Context Window）定义了模型在单次推理中能「看到」的最大信息量。以 Claude 3.5 系列为例，其支持约20万 Token 的上下文，表面充裕，但实际存在两个深层约束：

其一是**「迷失在中间（Lost in the Middle）」现象**——斯坦福大学2023年的研究表明，当相关信息处于长上下文的中间位置时，模型的检索和利用能力会显著下降，信息位于首尾时的表现要明显优于居中时；其二是推理成本的线性增长——Token 数量与 API 调用费用及推理延迟直接正相关，上下文每翻倍，推理成本大致也随之倍增。

这两个约束合在一起意味着：Agentic Search 对底层模型的推理质量高度依赖。推理能力弱的模型不仅无法精准筛选关键信息、及时终止无效探索，反而会因为低效的多轮迭代加剧 Token 浪费，并将越来越多的冗余内容堆入上下文，进一步降低后续推理的准确性——形成负向循环。这也解释了为何 Agentic Search 在 Claude 这类推理能力较强的模型上效果显著，而在较弱的模型上可能适得其反。

第二，超大规模代码库场景。 如果代码库规模特别庞大（如数千万行级别的单体仓库），纯靠逐步探索的方式效率未必最优。向量检索在这种场景下是否仍有价值——例如作为粗粒度的「范围缩小」层，先用向量检索锁定大致模块，再由 Agentic Search 精细探索——业内仍有讨论空间，尚无定论。

你可能没注意到，这个思路并非 Claude Code 一家独有——现在很多主流 AI 编程工具都在往这个方向演进，可以说代表了这一代工具的共同趋势。

适用边界

• 中小规模、结构清晰的代码库：Agentic Search 表现更好；
• 超大规模、跨模块关系复杂的场景：目前尚无定论。

总结：不是 RAG 不好，而是场景不合适

核心原因可以概括为一句话：代码检索这个场景需要的是精确、实时、可解释——这三点恰好是 Grep 的强项，却是 RAG 的弱项。

技术路线的核心，是用 AI 的推理能力驱动传统搜索工具，让它自己多轮迭代探索代码库——这就是 Agentic Search。它脱胎于 ReAct 框架所倡导的「推理与行动交替」范式，将大模型从被动的内容生成者，升级为能主动规划、执行、验证的智能探索者。

这一演进路径的深层逻辑在于：相比于用更大的向量索引来弥补语义理解的先天局限，不如直接释放大模型本身的推理潜力——让模型像有经验的工程师一样，通过有目的的探索和假设验证来理解陌生代码库。ReAct 框架的实验数据已经证明，这种「在行动中思考」的方式在需要多步推理的任务上，比单纯的检索增强生成方法准确率高出15%至30%。代码探索恰好是多步推理任务的典型代表。

所以说到底，不是 RAG 不好，而是在代码检索这个特定场景下，Agentic Search 更合适。这个结论有明确的场景边界，绝非放之四海皆准的万能答案。

对于超大规模代码库，RAG 与 Agentic Search 究竟如何结合，或许才是下一代 AI 编程工具真正需要回答的问题。

核心要点

核心要点

核心要点