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

过去一年，“RAG已死”的论调甚嚣尘上。随着长上下文窗口的普及和Agent技术的崛起，业界开始重新审视检索增强生成在新型应用场景中的适用性。以Claude Code、Codex为代表的新一代Agent CLI工具更是用脚投票——它们放弃了传统的embedding+向量库方案，转而采用LLM驱动的Grep搜索。这一技术决策的背后究竟隐藏着怎样的考量？RAG在Agent时代是否真的失去了价值？

LLM驱动的多轮搜索机制

Claude Code的创建者Boris Cherny曾在多个公开场合透露：一个让很多人意外的事实是——Claude Code不用RAG，不用embedding，不建索引，核心搜索完全依靠LLM驱动的Grep。他在社交媒体上坦言：“早期版本的Claude Code使用了RAG加上本地向量数据库，但我们很快发现，智能体式的搜索通常效果更好。”Anthropic官方的Context Engineering博客也确认了这一架构选择。

性能原理：暴力搜索为何足够快

Claude Code的代码搜索机制可以概括为：LLM自主决定搜索什么、使用什么工具、是否继续搜索——整个过程没有预设的搜索流程，一切由LLM在运行时动态决策。 搜索循环的核心是一个持续运转的机制：将用户输入和可用工具列表传给LLM，LLM返回文本或工具调用请求。如果是工具调用，执行后将结果追加到对话历史，然后带着更新后的完整历史再次调用LLM。这个循环会持续到LLM认为信息充分、可以直接生成回答为止。 与代码搜索相关的核心工具包括：GrepTool（正则搜索）、GlobTool（文件名模式匹配）、FileReadTool（文件读取）、AgentTool（启动子agent做多步探索）。其中AgentTool特别值得关注——它启动一个独立的子agent在自己的context window里完成搜索任务，最后只返回结论给主对话。这种设计实现了context隔离，避免了主对话被大量中间结果撑满。 GrepTool还提供了三种输出模式来控制信息量：files_with_matches（默认，只返回文件路径）、content（返回匹配行及其上下文）、count（只返回匹配数量）

行业对比与设计哲学

ripgrep是Claude Code底层使用的搜索工具，由Andrew Gallant用Rust重写，为大型代码库的快速搜索场景专门设计。它在真正搜索内容之前，有多层过滤逐步缩小范围：.gitignore目录级剪枝、path参数路径限制、glob文件类型过滤、二进制文件检测、内容正则匹配。这五层过滤是乘法叠加的——例如在4,471个文件的源码上，通过path限制bridge/目录后直接降到32个文件。 在内容匹配层面，ripgrep同样有多项优化：SIMD向量化匹配利用CPU指令并行比较字节，Boyer-Moore跳跃算法在固定字符串搜索时直接跳过多个字符，操作系统Page Cache让常用代码文件常驻内存，mmap零拷贝技术避免数据复制，多线程并行处理不同文件。实测数据显示，在4,500个文件、95万行代码的规模上，ripgrep搜索耗时约0.1秒，而GNU grep需要2-3秒，差距达25-33倍。

Grep的有效性边界

Claude Code选择零索引方案，但业界并非所有人都持相同观点。Cursor采用了经典的双索引架构——语义索引用tree-sitter切分代码块、通过embedding模型生成向量存入Turbopuffer；精确搜索索引使用trigram倒排索引加速grep。但有趣的是，Cursor在2025年泄露的Agent system prompt里，grep_search被明确标注为主要探索工具，LLM被要求先用一组宽泛关键词进行Grep，语义搜索只在“概念性查询”时作为补充。 OpenAI的Codex CLI与Claude Code做出了几乎相同的选择——同样不建索引、不用embedding。但两者实现路径有所不同：Claude Code为搜索操作封装了专用工具（GrepTool、Glob、Read），有结构化参数；而Codex让模型直接通过shell工具执行rg、find、cat等Unix命令。两个竞争对手独立做出了相似的架构决策，这不太可能是巧合——说明在当前LLM能力水平和开发者本地项目规模下，零索引+Grep已经是一个被反复验证的有效方案。 关于token成本问题，C

如有侵权，请联系删除。