作者：Lei阅读 --

Claude Code 和 Codex 还在用 RAG 吗？——代码检索为什么回到了 grep

拆解 Claude Code / Codex 的代码检索机制：为什么两家都放弃了向量索引式 RAG，改用 agentic search（grep + 模型闭环）；Fetch 工具到底是干什么的；以及 arXiv 论文链条给出的证据与边界。

AILLMCode AgentRAGAgentic SearchClaude CodeCodex论文学习

2026 年，世界上最先进的两个编码智能体——Claude Code 和 OpenAI Codex——检索代码库时用的核心手段，是 grep 家族的文本搜索。不是它们没试过 RAG：Claude Code 团队早期就内置了向量检索，实测之后删掉了。

这篇文章回答三个具体问题，然后给出一个可复用的判断模型：

  1. Claude Code / Codex 现在还用 RAG 吗？——对代码库检索，不用传统的”向量索引 + 相似度召回”式 RAG。
  2. 那它们怎么做检索？——Agentic search：把 grep/glob/read 这类朴素工具交给模型，让模型在”搜索 → 读结果 → 改进查询 → 再搜索”的闭环里自己找。
  3. Fetch 工具是干这个用的吗？——不是。WebFetch/WebSearch 面向的是网页内容，和代码库检索无关（但它内部倒藏着一个有趣的”微型 RAG”，后面细说）。

主线一句话：这场争论的本质不是”要不要检索”，而是检索的智能放在哪里——放在预先构建的索引里，还是放在模型的搜索循环里。

1. 两种检索的根本差异：开环 vs 闭环

先把”传统 RAG”说清楚。用在代码库上，典型管线是：

离线：代码 → 切块（chunking）→ embedding → 向量数据库
在线：用户问题 → embedding → 相似度 top-k 召回 → 塞进 prompt

这是一个开环系统：检索发生一次，质量由”切块策略 + embedding 模型 + 相似度度量”预先决定。召回错了，生成端只能将错就错。

Agentic search 则是一个闭环系统：

graph LR
    A[理解任务] --> B[发起搜索 grep/glob]
    B --> C[读结果 Read]
    C --> D{够不够?}
    D -- 不够/搜偏了 --> E[改写查询/换关键词/换目录]
    E --> B
    D -- 够了 --> F[开始改代码]

模型看到搜索结果后可以判断”搜偏了”，然后换关键词、缩小目录、顺着 import 链再搜。检索质量不再由索引一锤定音，而是由模型的多轮修正能力决定。

用一副跨 AI 全史都成立的原理望远镜看，这正是两条原理的对撞：

  • 表示决定成败：RAG 把代码库重新表示成向量空间；agentic search 拒绝二次表示，直接在原始文本上操作——因为代码天然自带精确结构（符号名、引用、目录树），把它压成向量反而丢信息。
  • 反馈闭环：agentic search 把”一次性的相似度匹配”换成了”行动 → 反馈 → 修正”的循环。而闭环系统随模型变强而免费变强——这是《苦涩的教训》在检索问题上的投影。

2. Claude Code：试过 RAG，然后删掉了

这不是设计者的美学偏好，而是一次被公开记录的实验结论。Claude Code 早期版本内置了 RAG + 本地向量库。团队用 agentic search 和它对比评测后，Anthropic 工程师在 Hacker News 上确认（转引自 Vadim 的分析文章）：

“In our testing we found that agentic search outperformed [RAG] by a lot, and this was surprising.”

于是今天的 Claude Code 完全不预索引你的代码库。它只有三件朴素工具：Glob（文件名模式匹配）、Grep（内容正则搜索）、Read（读文件），外加一个能跑 find/rg 的 Bash。据跟踪编码智能体搜索架构的分析，2026 年 4 月的 2.1.117 版本还把 macOS/Linux 原生构建里基于 ripgrep 的 Grep/Glob 换成了内嵌的 ugrep 和 bfs——换的只是引擎，“不建索引、按需文本搜索”的架构八年未变。

除了评测赢了，多方分析归纳的放弃理由还有四条，每条都值得单独记住：

  1. 新鲜度（staleness）。千人团队往 monorepo 里整天提交，任何索引在查询时刻都是几小时前的代码库快照——同事 40 分钟前改了函数名，索引还指着旧名字。而 agentic search 没有”过期”这个失败模式：代码库本身就是索引，grep 看到的永远是当下。
  2. 隐私与安全。向量化意味着代码要过一遍 embedding 服务、存进一个数据库，每个环节都是潜在泄露面。本地文本搜索让”数据不出机器”变成一句可以向企业客户交代的话。
  3. 架构简单性。RAG 需要 embedding 服务、向量库、索引维护守护进程、查询接口四件套；agentic search 只需要模型和几个 shell 工具。少一套基础设施，就少一套故障模式。
  4. 智能留在模型里。决定”搜什么、怎么改写、何时停”的能力放在模型里，模型每升级一代，检索能力免费提升；放在索引管线里，就要自己持续维护。

实践侧还有一个独立佐证：Augment 团队在构建 SWE-bench 智能体时得到了同样的结论——grep 式 agentic retrieval 打败了 embedding 检索，关键差异正是”智能体可以坚持尝试多种搜索策略、在首次失败后自我纠正”，而单发的向量召回没有第二次机会。

3. Codex：把 rg 写进系统提示词

OpenAI Codex 的答案更直白：ripgrep 被写进了核心提示词——指示模型优先用 rg / rg --files，因为它比 grep 快；rg 同时进了安全模块的自动批准白名单，OpenAI 官方的 Codex Prompting Guide 也把它列为默认工具。依赖之深，以至于系统里没装 rg 时代码导航会整体退化，甚至被误诊为”模型变笨了”（Codex Desktop 为此在应用包里直接捆绑了 rg 二进制）。

而语义索引在 Codex 里是什么状态？是一个至今开放的社区功能请求：有人提议加 codex index 命令、用 embedding + 本地 FAISS 建语义索引。官方没有接。也就是说，截至 2026 年，Codex 的代码检索主干没有任何向量成分。

两家独立得出同一结论，加上 GitHub Copilot CLI、OpenCode、Aider 等也都以 grep/rg 为主干，这已经不是巧合，而是行业收敛。

4. Fetch 工具到底是干什么的

回到问题三。Claude Code 里有两个容易被误会的工具，逆向分析（以及 Liran Yoffe 的补充）把它们的实现摸得很清楚：

  • WebSearch：走 Anthropic 服务端的搜索工具，返回网页标题和 URL——负责”找到该读哪个页面”。
  • WebFetch：在本地用 HTTP 客户端抓取指定 URL，把 HTML 转成 markdown 后交给一个二级 Haiku 对话按 prompt 提炼，只把答案返回主对话；带 15 分钟缓存；出于防数据外渗的考虑，模型不允许凭空拼 URL，只能抓用户给的或搜索结果里出现的链接。

所以答案是：Fetch 不是给代码库做 RAG 的，它面向的是训练数据之外的网络知识（最新文档、API 变更、报错帖子）。

但这里有个值得玩味的灰度观察：WebFetch 的结构——“抓取原文 → 小模型按需求压缩 → 只把相关内容注入主上下文”——本身就是一个即席的、无索引的 RAG。检索（fetch）、增强（Haiku 提炼）、生成（主对话使用），三段俱全，只是把”向量相似度召回”换成了”模型带着问题读原文”。换句话说，Claude Code 不是抛弃了”检索增强”这个思想，而是抛弃了”预建向量索引”这个实现。这个区分是全文的关键。

5. 学术界的证据链：从 BM25 baseline 到探索能力专项评测

上面都是工程实践，arXiv 上有一条完整的证据链可以对齐：

起点：RAG 作为 baseline 被建立，然后被超越。 SWE-bench 原始论文（Jimenez et al.）的标准做法就是 RAG：用 BM25 按 issue 文本召回最相关的文件，让模型一次性生成补丁。SWE-agent（NeurIPS 2024）证明给模型一个”智能体-计算机接口”（可以搜索、翻文件、迭代）就能大幅超越这个 RAG baseline——这是学术界对”闭环打败开环”的第一次系统确认。有意思的是，论文同时指出朴素 grep 的软肋：偶尔返回大量无关结果，作者猜想”更有信息量的搜索接口”能做得更好。这个猜想催生了第三条路线（见下）。

量化 RAG 在代码上的困难。 CodeRAG-Bench（“Can Retrieval Augment Code Generation?”）的大规模分析给出了机制层面的解释：当查询与目标代码词汇重叠弱时，相似度检索器难以召回有用上下文——而”根据 issue 描述找到该改的代码”恰恰是词汇重叠最弱的场景（用户描述症状，代码里写的是实现）。这正是向量 RAG 在代码检索上输掉的微观原因。

第三条路线：结构化索引，但不是向量。 LocAgent（ACL 2025）把代码库解析成异构有向图（实体 + 依赖关系），让智能体在图上做多跳推理定位代码，微调后的 Qwen-2.5-Coder-32B 达到最高 92.7% 的文件级定位准确率，成本比闭源 SOTA 低约 86%；RepoGraph（ICLR 2025）用仓库级代码图给现有智能体带来 SWE-bench 上 32.8% 的相对提升。注意这批工作的共性：它们也不用 embedding 相似度——索引的是符号和引用关系这种精确结构，检索方式依然是智能体主导的图遍历。它们反驳的不是”闭环”，而是”纯文本 grep 是否是最优接口”。

评测方法也在跟上。 SWE-Explore（2026）指出 SWE-bench 只看”修没修好”的二元结果、无法比较不同检索路线的优劣，于是把”仓库探索”单独拎出来评测：848 个 issue、10 种语言、203 个仓库，让经典检索器、搜索智能体、长上下文选择器在同一标尺下对比。检索路线之争正在从轶事走向可量化。

把这条链压缩成一句话：学术界先确认了闭环 > 开环（SWE-agent），再解释了为什么（CodeRAG-Bench 的词汇鸿沟），然后在闭环内部继续优化接口（图索引），最后为这场比较建立了专项标尺（SWE-Explore）。

6. RAG 没有死：边界在哪里

写到这里很容易滑向”RAG 已死”的错误二元对立。事实上有三个重要的反例和一个真实软肋：

Cursor 证明向量索引在代码上依然可行。 Cursor 用 tree-sitter 切块 + embedding（存 Turbopuffer），靠 Merkle 树做增量同步来对抗新鲜度问题。它换来的是 agentic search 给不了的东西——概念级搜索（“处理鉴权的代码在哪”这种没有精确关键词的查询）。而当 ripgrep 在超大 monorepo 上变慢时，Cursor 的优化路径也很说明问题：不是加码向量，而是建了一个 mmap 支撑的稀疏 n-gram 索引把正则查询做到毫秒级——为了速度建索引，而不是为了语义建索引。

Token 成本是 agentic search 的真实软肋。 Claude Code 的 GitHub issues 里一直有用户要求加索引，因为在大代码库上多轮 grep + read 会烧掉大量 token，最坏情况下探索成本失控。缓解手段（子智能体分片搜索、CLAUDE.md 当目录地图、LSP 做符号级过滤）都存在，但”开环便宜、闭环贵”这个结构性代价不会消失——你是在用推理算力换检索精度，这笔账在小任务上未必划算。

大文档场景 RAG 仍然占优。 MindStudio 的横向分析的结论是：编码智能体跳过 RAG，不代表 RAG 错了，而是它被用在了错误的岗位上——自然语言长文档没有符号名、没有引用图、没有精确 grep 目标，向量相似度依然是那里最好的工具。

Augment 的工程建议是三者最好的和解：别把 embedding 检索当管线，把它当工具——和 grep 并列，暴露给智能体，让模型自己决定什么时候按关键词搜、什么时候按语义搜。行业共识也正收敛到分层检索：grep 负责广覆盖低成本的初筛，LSP/图索引负责符号级精确确认，语义检索作为可选层处理弱词汇重叠的查询。

7. 带走的判断模型：三个问题决定你该用哪种检索

如果你在设计自己的智能体，别问”用不用 RAG”，问这三个问题：

  1. 语料自带精确结构吗？ 代码有符号名、引用链、目录树——精确匹配工具直接可用；纯自然语言文档没有，需要向量做语义桥接。
  2. 查询者能多轮迭代吗？ 智能体可以闭环修正，首搜失败不致命，朴素工具就够了；单发问答（一次检索定生死）则必须在开环召回质量上下重注。
  3. 上下文窗口装得下中间结果吗？ 装得下，模型可以自己读自己筛；装不下，才需要索引层预先压缩。

三问都偏向前者，就是 Claude Code / Codex 的答案：grep + 闭环。三问都偏向后者，传统 RAG 依然是对的。中间地带，就是 LocAgent/RepoGraph 那条路——建索引，但索引结构而非语义，检索权仍交给模型。

最后回到那条最硬的原理。RAG 管线把检索智能固化在 embedding 和切块策略里，模型升级它不动；agentic search 把智能留在模型里，GPT-4 时代它一般，Claude Opus 时代它很强，下一代模型它更强。《苦涩的教训》的检索版：与其教系统”什么和什么相似”，不如给它工具、让它自己学会找。 过去八年编码智能体的检索架构没怎么变，变的只是里面那个模型——这大概就是这个设计最深的自信。

参考来源

工程实践

arXiv 论文