Claude Code、Codex 为什么都选了 Grep 而不是 RAG

当人们讨论 Claude Code 这类 AI 编程助手时，往往会下意识地认为其背后必然依赖一套复杂的 RAG（检索增强生成）系统：建立索引、计算向量、进行语义检索，最后才生成答案。这种设想听起来很合理。

然而，事实恰恰相反。Claude Code 不仅没有使用 RAG，反而彻底放弃了这套方案。

这并非个例。从 OpenAI 的 Codex CLI、Cognition 的 Devin，到 Aider、Sourcegraph Cody，几乎所有主流的 AI 编程工具都做出了相同的技术选择：使用 Grep 进行代码搜索，而非 RAG。这绝非巧合，也并非团队偷懒。实践反复证明，在代码搜索这一特定场景中，Grep 比基于向量的检索更快、更准，同时省去了构建复杂基础设施的麻烦。

今天，我们就深入剖析这背后的核心逻辑与工程考量。

RAG 和 Grep 的核心概念解析

如果你已经熟悉这两个概念，可以快速浏览此部分。

RAG，全称检索增强生成，听起来技术含量很高。简单来说，其流程是：先构建一个“知识库”，将文档切分成块，利用嵌入模型将每一块转换为数学向量，并存入向量数据库。当用户提问时，将问题也向量化，在数据库中查找语义最相似的若干文本块，最后将这些内容连同原始问题一并输入大模型以生成答案。其核心在于“语义相似性”匹配，即使措辞不同，只要意思相近就能被检索到。

Grep 则简单直接得多。它本质上是一个强大的文本搜索工具，用户输入一个关键词或正则表达式，它便在文件中逐行扫描，找出所有匹配的行。如今广泛使用的 ripgrep 是其现代增强版，速度提升十倍以上，并能自动跳过 .gitignore 中指定的目录。Claude Code 内部使用的正是 ripgrep。

表面看来，两者差距悬殊：RAG 代表“智能”的语义匹配，Grep 则是“笨拙”的关键词匹配。但在代码搜索这个战场上，“笨”方法却取得了胜利。

Anthropic 官方的解释与验证

最权威的解释来自 Claude Code 的创造者之一、首席工程师 Boris Cherny。2025 年 5 月，他在 Latent Space 播客中公开分享了这段研发经历。

团队确实尝试过 RAG，也评估过其他搜索方案。最终发现，智能体搜索（Agentic Search）才是更优解。他用两个词形容测试结果：“outperformed everything, by a lot”——即性能全面超越，且优势显著。这个结果连他们自己都感到惊讶。

关于放弃 RAG 的原因，他给出了几点具体理由：RAG 需要完整的索引构建步骤，这本身就引入了复杂性。代码库是动态变化的，索引很快就会与实际代码脱节。此外，索引文件的存储也涉及代码隐私等安全问题。

在 HackerNews 上，也有 Anthropic 的工程师直接确认了这一点。原话是：“Claude Code doesn‘t use RAG currently. In our testing we found that agentic search out-performed RAG for the kinds of things people use Code for.” 意思很明确，测试数据表明，对于代码助手的使用场景，智能体搜索表现更佳。

更有趣的验证发生在 2026 年 3 月。Claude Code 约 51 万行的 TypeScript 源码意外通过 npm source maps 泄露。社区分析代码库后发现，其中完全不存在 RAG 流水线、没有向量数据库集成、也没有嵌入计算代码。其搜索架构仅仅是对 Grep、Glob、Read 等工具调用的封装。源码不会说谎。

代码搜索与文档搜索的本质区别

要理解 Grep 为何在代码搜索中胜出，必须首先认清代码与自然语言文档的本质差异。

开发者使用 AI 编程工具时，提出的典型问题是：“AuthService 这个类定义在哪里”、“哪些文件调用了 processPayment 函数”、“这个变量在何处被修改”。这些问题并非语义模糊的问题，而是精确的定位问题。“AuthService 在哪里定义”的答案，不是“与认证概念语义最接近的文件”，而是“字面上包含 `class AuthService` 这几个字符的精确文件”。

向量嵌入为模糊匹配优化，擅长“即使措辞不同也能找到意思相近的内容”。但代码导航几乎不需要这种模糊性，它追求的是精确性。`grep “class AuthService”` 可以直接定位，而向量搜索可能将 AuthService、LoginService、SessionManager 等文件混杂返回。

此外，RAG 难以妥善处理代码的依赖与调用关系。

理解一段代码通常需要追踪一条跨越多个文件的调用链。例如，一个支付功能可能从 controller 层开始，经过 service 层，再到 repository 层，最后抵达 database migration。RAG 的相似度搜索可能检索到 controller 层代码，但几乎不可能自动沿着调用链一路追踪到底层的 migration 文件。继承关系亦然，若要理解 PaymentProcessor，需要同时查看其父类 BaseProcessor 和接口 ITransactionHandler。RAG 缺乏将这三个关联文件组织在一起的机制。

分块（Chunking）策略也是一大难题。2025 年一项 NAACL 同行评审研究发现，分块策略对 RAG 性能的影响，等于甚至大于嵌入模型本身的选择。对代码进行分块尤其棘手：若将函数与其所属的类分开，继承信息便丢失；将方法与调用它的代码分开，使用模式便无法看清；将 import 语句与其使用代码分开，依赖关系便断裂。研究数据很能说明问题：尊重代码结构的自适应分块准确率可达 87%，而固定大小的分块准确率仅有 13%。

索引新鲜度同样是挑战。开发者每次编辑文件，该文件的向量嵌入便已过时。要保持向量索引实时更新，就需要持续重新计算嵌入，成本高昂且容易产生延迟。而基于文件系统的读取永远是实时的，任何修改都能在下次查询中立即反映。

智能体搜索（Agentic Search）的工作机制

读到这里，你可能会想：仅靠原始的 Grep 就够了吗？

确实，Claude Code 使用的不仅是简单的 Grep。它采用的是一种称为“智能体搜索”的方式。其核心区别在于，搜索过程本身包含了模型的推理。

举例来说。你想了解“认证 token 是如何被验证的”。

如果是语义搜索（RAG），会将“auth token validation”这个查询转换为向量，返回10个最相似的代码块。正确的文件可能在其中，但也可能返回一堆测试夹具、废弃的处理器或 README 中关于认证的段落。

如果是纯 Grep，会匹配 `validateToken` 这个关键词，返回每一个出现的位置：包括函数定义、15个调用点、4个测试 mock 和一条 changelog 记录。信息虽然全面，但噪音过多。

如果是智能体搜索，它会先执行 Grep 搜索 `validateToken`，在 `auth/middleware.ts` 中找到函数定义；读取该文件后，发现它调用了 `lib/crypto` 中的 `decodeJWT`；然后跟随这个 import 语句追踪过去，找到真正的验证逻辑。最终，它可能只返回两个精确相关的文件位置。

核心区别就在于这个“跟随追踪”的动作。模型不仅仅是匹配模式，它会对代码可能的位置形成假设，利用工具调用验证这些假设，并跨文件追踪因果链。搜索变成一个循环：搜索 -> 读取结果 -> 思考 -> 再次搜索。通常经过三四轮迭代便能定位目标。

此外，模型可以并行发起多个 Grep 调用，针对不同的模式、目录或文件类型同时搜索。8个并行的 Grep 调用延迟与1个相差无几，却能探索8倍大的代码库范围。

Anthropic 的研究还发现一个关键数据：当无关内容在模型上下文中积累时，其性能会下降30%以上。这也是为什么智能体搜索需要配合子上下文（sub-context）隔离使用。搜索在独立的上下文窗口中运行，死胡同路径被直接丢弃，只有真正相关的文件范围被返回给主上下文。这并非子上下文更聪明，而是保证了主上下文的洁净与高效。

Claude Code 的搜索工具箱详解

Claude Code 为模型配备了五个核心工具。

1. Grep：基于 ripgrep，用于搜索文件内容中的特定模式。 2. Glob：进行快速的文件模式匹配，例如找出 src 目录下所有的 TypeScript 文件。 3. Read：读取指定文件的内容。 4. Bash：可以执行任意 shell 命令（需用户许可）。 5. LSP：2025年12月加入的可选语言服务器协议增强。

模型的搜索过程完全自主驱动。它可能先进行广泛搜索，用 Glob 找到相关文件类型；然后用 Grep 搜索特定的函数名、导入语句或模式；看到有希望的文件就读取其内容；读取后发现引用了其他内容，则继续用 Grep 跟踪下去，直到收集到足够的上下文为止。

为何选择 ripgrep 而非传统 grep？原因非常实际。ripgrep 默认递归搜索、自动遵守 .gitignore 规则、支持智能大小写匹配、文件类型过滤语法更简洁。在 Linux 内核代码库的基准测试中，ripgrep 耗时约0.06秒，而 grep 约0.67秒，相差十倍。在智能体工作流中，每个搜索结果都会作为文本送入模型的上下文窗口，无关结果会消耗 Token、污染上下文、分散模型注意力。ripgrep 能自动跳过 node_modules 等目录，确保模型只看到真正相关的代码。

LSP 被定位为可选的精度增强层，而非搜索骨干。Grep 用于形成假设和广泛探索，LSP 则用于验证假设和执行精确操作（如跳转到定义）。Claude Code 的设计理念是：能在 shell 中执行并产生文本输出的工具，比需要持久连接的有状态协议更原生、更简单。

行业趋势：并非 Claude Code 一家的选择

如前所述，几乎所有主流 AI 编程工具都独立做出了相同的选择，这并非事先商议的结果。

OpenAI 的 Codex CLI 在其核心提示词中直接指定使用 ripgrep，不使用任何向量检索。Devin 背后的 Cognition 团队甚至专门用强化学习训练了一个 SWE-grep 模型来优化 Grep 搜索策略。Aider 使用 tree-sitter 进行 AST 分析，并结合 PageRank 算法构建代码地图，走的也是纯结构化分析路线。Sourcegraph Cody 采用三元组索引加 LSP，延续了代码搜索引擎的思路。

当然，也有使用 RAG 的案例。Cursor 是唯一一个确实集成了 RAG 的主流工具，它有一个5步的 RAG 管线作为语义搜索的补充层。但即使在 Cursor 内部，ripgrep 仍然是其智能体搜索的主要工具。当 ripgrep 在大型单体仓库中变慢时，Cursor 的优化路径并非转向向量搜索，而是为正则搜索本身构建了一个本地 n-gram 索引。这很能说明问题：他们需要的仍然是精确匹配，只是希望它更快。

这种行业趋同现象并非偶然。各个团队在独立测试后都得出了相同结论：在代码搜索这个特定场景中，Grep 结合模型推理的组合，其综合表现优于 RAG。

大上下文窗口带来的范式转变

还有一个重要的背景因素：模型上下文窗口的急剧扩大。在2022到2023年，模型上下文窗口通常只有4k到32k token，RAG 几乎是必需品，因为你无法将整个代码库塞进上下文。但到了2025到2026年，前沿模型提供了高达100万 token 的上下文，情况完全不同了。

技术瓶颈发生了转移。2023年的瓶颈在于检索——模型的“读取器”小、慢、贵，因此必须精心挑选喂给它什么内容。2026年的瓶颈变成了对混乱上下文的推理——模型的“读取器”变得大、快、便宜。因此策略也随之改变：让检索器变得“笨拙但高召回”，把筛选和理解的重任交给模型。ripgrep 负责把所有可能相关的内容都捞出来，模型则负责从中进行筛选、关联和深度理解。

Anthropic 官方的说法是 “Just-in-time context, not pre-inference RAG”——即即时上下文，而非推理前的 RAG。维护轻量级的标识符索引，在运行时通过工具动态加载所需数据，而不是提前建好沉重的向量索引等待查询。

这也呼应了 Boris Cherny 提到的“苦涩的教训”（Bitter Lesson）哲学：随着模型能力变得足够强大，它会吸纳并替代许多复杂的工程组件。与其投入大量精力构建复杂的检索工程，不如押注于模型本身能力的持续提升。

工程与成本差距显而易见

从工程实现和成本角度对比，差距更为直观。

一套经典的 RAG 管线需要经历以下步骤：文档分块、嵌入计算、存入向量数据库、查询向量化、相似度搜索、检索分块、结果拼装与生成。这涉及4到5个服务组件，每个环节都可能成为故障点。

而 Grep 加长大上下文的方案仅需四步：接收查询、ripgrep 搜索、将结果加载到上下文、模型生成。无需新增任何外部基础设施。

延迟对比明显。ripgrep 的典型延迟在10到50毫秒，而完整的 RAG 管线通常超过500毫秒。智能体搜索由于包含多轮搜索，延迟可能在2到8秒左右，但换来的是精确度高得多的搜索结果。

工程成本差异巨大。搭建并维护一套稳定的 RAG 管线，保守估计需要40到80人/小时的工作量。同样的投入，在 Sonnet 4.6 模型配合提示词缓存的情况下，足以运行三万次以上、每次20万 token 的查询，足够使用数月。

维护负担方面，RAG 管线需要处理嵌入 API 成本、监控告警、schema 变更、文档更新队列、嵌入失败重试等。而 ripgrep 方案中，文件一旦修改，下一次查询自动看到新内容，几乎没有额外的维护负担。

RAG 的适用场景探讨

尽管列举了 Grep 的诸多优势，我们必须公允地指出，RAG 在特定场景下仍然是更优的选择。

当语料库规模达到500GB以上的原始文本时，ripgrep 也会力不从心。当用户的查询用词与文档中的专业术语差异极大时（例如用户说“wifi断了”，而文档写的是“物理层连接丢失”），向量嵌入能捕捉这种语义关联，而词法搜索则无能为力。跨模态检索，例如以图搜图、以音频搜音频，嵌入技术是必需的。在要求极低延迟（如100毫秒内响应）的场景中，RAG 的预索引优势得以体现。对于需要合规审计、证明特定查询确实参考了特定文档的场景，RAG 的可追溯性更有价值。此外，在需要跨代码、文档、Jira、Slack 等异构数据源进行统一搜索时，基于结构化解析的方法可能失效，而向量方法则更为灵活。

因此，结论并非“RAG 已死”，而是在代码搜索这个高度结构化、追求精确性的特定领域，RAG 并非最优的技术路径。

总结与启示

梳理完上述信息，一个清晰的结论浮现出来：AI 编程工具的技术选择背后，反映的是一种务实的工程哲学取舍。

RAG 看起来更“先进”，拥有向量数据库、嵌入模型、语义理解，整个技术栈听起来颇具吸引力。但先进不等于适合。代码搜索的核心需求是精确匹配和结构追踪，这两点恰好是 RAG 的短板。而 Grep 看起来“原始”，但它所做的事情与代码搜索的需求完美契合：找到包含特定文本字符串的行，不猜测、不模糊、不遗漏。

真正让这个“原始”方案大放异彩的，是模型能力的飞跃。两年前，模型上下文窗口小、推理能力弱，必须依靠精心设计的检索管线来“喂食”数据。如今，模型足够强大，给它一堆 Grep 搜索结果，它自己能完成理解、筛选和追踪。因此，技术瓶颈从“如何高效检索”转移到了“如何让模型更好地推理”。

Boris Cherny 所说的 “Everything is the model”（一切皆模型）是这一决策的核心思想。与其花费大量时间构建复杂的检索工程，不如相信模型能力会持续进化。目前看来，这个赌注是正确的。

Claude Code 不使用 RAG，并非技术上的无能，而是经过充分测试后的理性选择。智能体搜索在代码搜索任务上全面超越了 RAG，并且实现了零索引开销、零额外基础设施、零复杂维护负担。Codex、Devin、Aider 等工具独立验证了同一结论。

这并非 RAG 技术的失败，而是技术选型的胜利。它再次印证了那个永恒的工程原则：选择最适合场景的工具，而非看起来最炫酷的工具。