传统 grep 已死，Claude Code、Codex 都用 ripgrep 了

今天同事和我聊天，说 RAG 已死，就连 grep 也死了，现在是 ripgrep 当道。

当然，这个死是打引号的，就是说它们都有缺陷，现在已经有其它更优的方式或工具替代它们。

就拿现在的 AI 来说，大模型 Agent 已经能自己写代码、跑测试、修 Bug 了。但如果你扒开 Claude Code、OpenAI Codex、Gemini CLI 这些明星产品的底层，会发现它们检索代码的方式，朴素得令人意外。不是向量数据库，不是语义检索，而是一把诞生于 2016 年的命令行搜索工具 ripgrep。

国内的一些编程工具，有些没有开源出来，但我觉得它们的代码搜索应该和 Claude Code、Codex 等是一样的，都离不开 ripgrep。所以，接下来我们就一起来聊聊这个后起之秀 ripgrep。

rg

grep 是什么？

要聊 ripgrep，不得不提或绕不过去的是 grep。

grep 是 Unix/Linux 世界里最经典的文本搜索命令，名字来自 g/re/p（在全局范围内用正则表达式打印匹配行）。它的血统古老到可以追溯到 1973 年，Ken Thompson 在 Unix 上写下了第一个版本，而后 GNU 项目重写了我们今天最常用的 GNU grep。

几十年来，我们大多数程序员排查日志、定位代码，几乎都靠它。但 GNU grep 毕竟是上个时代的产物，在 AI 时代它的缺陷也比较明显。

• 递归搜索要显式加 -r；
• 不认识 .gitignore，搜出来的结果里全是 node_modules、build 目录的噪音；
• 默认单线程，面对现代动辄几万文件的项目仓库力不从心；
• 开启 Unicode 支持后性能大幅下降。

因此，时代变了，工具也该换换了。

ripgrep 是什么？

ripgrep

ripgrep（命令行里叫 rg）是一个用 Rust 编写的行式搜索工具，2016 年由 Andrew Gallant（网名 BurntSushi）创建。它的自我介绍只有一句话。

递归搜索当前目录中的正则表达式模式，同时默认尊重 .gitignore，自动跳过隐藏文件和二进制文件。

用起来的体验是这样的：

# 递归搜索，自动跳过 .gitignore 里的文件，自带文件名、行号、高亮rg "TODO" .# 只搜 Python 文件rg -tpy "def main"# 多行上下文rg -C 3 "database_url"

它的其中一个好处是，把“开发者搜代码时真正想要的默认行为”做成了出厂设置。递归、过滤噪音、多线程、输出清晰等等默认都支持。VS Code 的全局搜索功能底层就是它，如果你用 Mac 电脑，那么你的 Mac 上很可能已经躺着一个 rg 二进制，只是你没发现它。

rg 极速搜索

ripgrep 的诞生

2016 年的代码搜索工具市场，是一个“鱼和熊掌不可兼得”的局面。

• GNU grep：快，但默认行为不符合开发者的直觉，配置繁琐；
• ack / The Silver Searcher (ag)：好用，尊重忽略规则，但速度不够极致。

Andrew Gallant 想要的是“ ag 的易用性 + grep 的极致速度”，而当时没有这样的工具，于是他决定自己造一个。为此他先花了一年多时间打磨 Rust 的正则表达式引擎，这本身就是 ripgrep 的技术地基。然后在 2016 年 9 月发布了那篇著名的技术博客《ripgrep is faster than {grep, ag, git grep, ucg, pt, sift}》，用大量基准测试把当时所有主流搜索工具都“锤”了一遍。文章至今仍是研究高性能文本搜索的经典读物。

这个项目还有个小趣闻，因为名字叫 ripgrep，不少新用户以为它是 “R.I.P. grep”（安息吧，grep）的缩写，而作者本人并没有这个意思，但这个误读某种程度上成了预言。

ripgrep 为什么这么快？

ripgrep 高亮

官方 README 给过一个著名基准，在完整的 Linux 内核源码树上搜索单词 [A-Z]+_SUSPEND，ripgrep 用时 0.082 秒，是 git grep 的 3 倍快、The Silver Searcher 的 5 倍快、开启 Unicode 的 GNU grep 的 32 倍快。支撑这个速度的，是一整套精心设计的组合拳。

1. 字面量先行：正则引擎会先从模式里提取纯文本片段（比如 \w+foo\d+ 里的 foo），用 SIMD 指令一次比对 16 个字节，快速锁定候选位置，再交给完整的正则引擎确认；
2. Teddy 多模式算法：多关键字并行匹配时使用向量化算法，扫描速度逼近内存带宽极限；
3. 稀有字节策略：扫描时优先匹配模式中出现概率最低的字节，最大限度减少误报；
4. 惰性 DFA：不预先编译完整的自动机，而是边搜索边构建，只为实际走过的状态买单；
5. Unicode 内建：UTF-8 解码直接内置在自动机里，全量 Unicode 支持几乎不影响速度；
6. 无锁并行遍历：基于 crossbeam 和 ignore 库的无锁并行递归目录迭代器，多核 CPU 自动打满；
7. 智能 I/O：大文件用内存映射（mmap，约 25% 提速），海量小文件用缓冲 I/O，自动选择。

用一句话总结来说，在别人还在“逐字节做事”的地方，ripgrep 已经“向量化 + 并行化”了，它能不快嘛。

为什么都选 ripgrep？

为什么 Claude Code、Codex 都选 ripgrep？要知道快只是其中之一。

2026 年 3 月，一篇分析文章《Why Coding Agents Still Use grep as Their Search Backbone》引起了广泛关注，其中披露了一个关键细节，Claude Code 的核心工程师 Boris Cherny 在接受采访时亲口说过。

Claude Code's agentic search is really just glob and grep, and it outperformed RAG.

翻译过来就是，Claude Code 的“智能体搜索”其实就是 glob（按文件名找）加 grep（按内容找），而这个朴素方案“在内部实验中击败了 RAG”（检索增强生成）。Anthropic 团队试过本地向量数据库、递归式模型索引等一堆时髦方案，最后赢的居然是最土的那条路。Boris 还举了个很形象的旁证，Meta/Instagram 的工程师在 IDE 的“点击跳转定义”失效时，第一反应也是退回文本搜索。

扒开源码看，证据更直接，Claude Code 的 GrepTool 源码里明晃晃写着 import { ripGrep } from '../../utils/ripgrep.js'，真正干活的根本不是系统自带的 grep，而是 ripgrep。OpenAI 的 Codex CLI 同样如此，它的 npm 安装包里“直接内置了一个 rg 二进制”，2026 年 7 月发布的 Codex CLI 0.145.0 更新日志里还专门提了一句“将随附的 ripgrep 升级到 15.2.0”。Google 的 Gemini CLI 捆绑了 ripgrep；VS Code 系的 Cline 插件更是把 ripgrep + fzf + tree-sitter 做成了三层检索。2026 年一篇对 11 个主流编码智能体的源码研究论文也印证了这一点，几乎所有系统都在用 ripgrep 做关键词检索，而“没有一个”依赖 Embedding 向量检索来理解代码库。

这是为什么呢？有老外总结了五个原因。

• 确定性胜过概率性。对 Agent 来说，“搜索”是后续一切推理的地基。ripgrep 是确定性的，同一个模式，搜出来的结果就是那几行，可复现、可验证、可解释。而向量检索是概率性的，Embedding 相似度可能把“登录”和“注销”的代码混为一谈，Agent 一旦在地基上犯错，后面全是幻觉。
• 延迟低到可以忽略。社区实测显示，在一个几万文件的中型仓库里跑一次全文搜索，ripgrep 大约只需 200 毫秒。对比 RAG 的链路，调 Embedding 模型生成向量（一次网络往返）→ 向量库 KNN 搜索（又一次往返）→ 可能还要 Rerank（又一次模型调用），整套下来七八个步骤、四五个服务。对分秒必争的 Agent 循环来说，胜负已分。
• 零依赖，开箱即用。ripgrep 是一个静态编译的单一二进制，不依赖 GPU、不依赖模型、不依赖网络，装在用户的机器上就能跑。AI 工具天然要在五花八门的本地环境里运行，这个特性太珍贵了。
• 输出格式天生为 Agent 设计。ripgrep 的结果自带文件名、行号、上下文，还是合法的 JSON（--json），这正是 LLM 最容易解析、最省 token 的格式。想找“某个函数在哪定义”，Agent 拿到 file:line 后直接定点读取，而不用把几十个文件整块塞进上下文烧钱。
• 噪音过滤符合直觉。默认跳过 .gitignore 和隐藏文件，意味着 node_modules、构建产物、.git 目录这些“垃圾场”自动被排除。Agent 的上下文窗口寸土寸金，干净的检索结果直接等于更少的 token 消耗和更高的信噪比。

还有一个更深层的启示是不少团队曾以为“AI 时代需要更 AI 的检索”，但实践反复证明，在代码这个结构化、关键词密度极高的领域，暴力扫一遍往往比精心建索引更便宜、更准、更可控。LSP 精准跳转是“精度层”的好补充（Claude Code 后来也加了 LSP 支持），但遇到“搜 TODO、搜配置项、搜报错文案”这类任务，grep 依然是第一选择。

star 数与稳定更新

接下来看 ripgrep 的江湖地位，截至 2026 年，ripgrep 在 GitHub 上收获约 6.8 万颗 Star，拥有 400 多位贡献者，长期位居 Rust 命令行工具头部阵营，也是 Claude Code、Codex、Gemini CLI、VS Code 等一线工具的底层依赖。

再看动态。这个项目保持着一年约 2-3 个版本的稳定节奏。最近一年的三个版本如下所示。

• 15.0.0（2025 年 10 月）：大版本，修复了一批 .gitignore 匹配的历史遗留 bug（包括父目录规则不生效的老问题）；新增对 Jujutsu（jj）版本控制仓库的识别；glob 模式支持嵌套花括号；二进制全面启用 LTO 编译优化。
• 15.1.0（2025 年 10 月）：小版本，修复 --line-buffered 回归（这个 bug 会影响和 tail -f 的配合），并新增 Cursor 编辑器的超链接别名。
• 15.2.0（2026 年 7 月 15 日，最新版）：聚焦 gitignore 匹配 bug 修复和目录遍历性能。值得关注的一个新特性是开始尊重 GIT_CONFIG_GLOBAL 和 GIT_CONFIG_SYSTEM 环境变量——在容器和 CI 环境里，你可以不改动全局 gitconfig 就注入自定义排除规则；此外还有面向超大代码库的目录遍历提速（PERF #3293）、新增 aarch64-unknown-linux-musl 官方二进制，以及跨多目录搜索时 gitignore 匹配的若干修复。

值得一提的是，OpenAI Codex 在 15.2.0 发布一周内就把内置的 ripgrep 升级到了这个版本——主流 AI 工具对它的跟进速度，足以说明它在 Agent 基础设施里的分量。

最后

回看 ripgrep 的十年，是一个很朴素的工程师故事，没有融资，没有发布会，一个人用两年时间打磨正则引擎，用一篇硬核博客立威，然后安静地被全世界的基础设施“吸进去”。到了 AI 时代，当所有人以为代码检索必然是向量数据库的天下时，它又用一个 200 毫秒的系统调用，给“过度工程化”上了一课。

回想起那些经典的工具或系统，Linux、Git、ffmpeg、ripgrep 等等依旧伟大！