RAG 已死？不，是 Grep 回归了！

📌 一句话摘要

本文基于 Claude Code 泄露源码，深入拆解其放弃 RAG 和向量检索、采用 LLM 驱动 Grep 的多轮循环搜索机制，并与 Cursor、Codex 对比，论证在代码搜索场景下零索引方案的可行性与设计哲学。

📝 详细摘要

本文围绕「RAG 已死」这一行业热议话题，以 Claude Code 的源码拆解为核心，系统分析了 AI Agent 时代代码搜索架构的演进。文章首先指出 Claude Code 和 Codex 等前沿产品已放弃传统 RAG（预索引 + embedding + 向量库），转而采用 LLM 驱动的 Grep 多轮循环搜索。作者基于泄露的 Claude Code 源码，详细拆解了其搜索循环机制，包括 GrepTool、GlobTool、FileReadTool、AgentTool 等核心工具的设计，以及 GrepTool 的三种输出模式（files_with_matches、content、count）如何控制信息量。文章通过一个实战案例（追踪 bridge 系统的工具调用记录）完整展示了多轮搜索的迭代过程。在性能分析部分，文章解释了 ripgrep 的五层过滤、SIMD 加速、Boyer-Moore 跳跃等原理，并用实测数据证明在开发者本地项目规模下暴力搜索足够快。行业对比部分，文章将 Claude Code 的零索引方案与 Cursor 的双索引架构（语义索引 + trigram 索引）进行对比，指出规模决定架构选择。文章还回应了 Milvus 对 Grep 方案 token 成本的批评，分析了 prompt cache、auto-compaction、子 agent 隔离等三层成本控制机制。最后，文章引用 GrepRAG 论文的实证数据，论证代码搜索场景下 Grep 优于 embedding 的原因——代码标识符本身就是高精度语义锚点。文章结论是：死的不是 RAG 范式本身，而是「代码搜索必须靠 embedding 预索引」这个默认假设。

💡 主要观点

1. Claude Code 和 Codex 已放弃传统 RAG，采用 LLM 驱动的 Grep 多轮循环搜索。 基于泄露源码，Claude Code 不使用 embedding、向量库或索引，核心搜索机制是 LLM 自主决定搜索关键词和工具，通过多轮迭代直到信息充分。
2. Grep 在代码搜索场景下优于 embedding 检索，因为代码标识符本身就是高精度语义锚点。 GrepRAG 论文实证表明，单轮 Grep 检索在代码补全任务上超过 embedding RAG 基线。代码中 95% 的搜索关键词是类名、方法名、变量名，精确匹配恰好是最直接的检索方式。
3. 零索引方案在开发者本地项目规模上可行，因为 ripgrep 的暴力扫描足够快。 ripgrep 通过五层过滤、SIMD 向量化、Boyer-Moore 跳跃、多线程并行等优化，在 4500 文件的项目上搜索仅需 0.1 秒，无需预建索引。
4. Grep 方案通过 prompt cache、auto-compaction、子 agent 隔离三层机制控制 token 成本。 相邻轮次 92% 的 prompt 前缀相同，缓存可降低约 81% 成本；对话历史接近上限时自动压缩；子 agent 将搜索中间结果隔离在独立 context 中。
5. Cursor 的双索引架构与 Claude Code 的零索引方案是场景选择，非技术优劣。 Cursor 面向大型代码库需要索引，Claude Code 面向本地项目零索引更简洁。但 Cursor 的 system prompt 仍将 grep_search 标为主要探索工具，说明精确匹配比语义搜索更高频。

💬 文章金句

• Plain glob and grep， driven by the model， beat everything.
• Early versions of Claude Code used RAG + a local vector db， but we found pretty quickly that agentic search generally works better.
• 死的不是检索增强生成这个范式，而是代码搜索一定要靠 embedding 预索引这个默认假设。
• 代码里的函数名、类名是程序员亲手埋的精确锚点，Grep 几乎总能命中；自然语言里的一个概念可以有十几种表达。
• 技术的选择由数据的特性和规模决定，不应该是信仰问题。

📊 文章信息

阅读完整文章