Claude Code 放弃 RAG，真的是因为 RAG 不行了吗？

一座每天都在改书的图书馆，为什么不一定适合提前做索引？

假设你来到一座巨大的图书馆，想找一个问题的答案。

图书馆可以用两种方式帮你。

第一种方式，是提前把所有书读一遍，拆成很多小段，再给每一段制作“内容卡片”。以后你提问时，系统先从卡片中找出最相关的几段，再交给 AI 回答。

这很像我们经常听到的 RAG。

第二种方式，是请一位经验丰富的图书管理员现场调查。他会先看目录，再搜索关键词，找到一本书后翻到相关章节，然后顺着引用继续查另一本书。发现方向不对，他还会立刻换关键词、换目录、换路线。

这很像 Agentic Search，也就是代理式搜索。

Claude Code 早期尝试过第一种方式，后来改用第二种方式。

于是网上出现了一个很吸引眼球的说法：

Claude Code 放弃了 RAG，所以 RAG 已经不适合代码开发了。

这个结论听起来很有道理，但它只说对了一半。

---

一、先说结论：Claude Code 放弃的不是“所有 RAG”

2026 年 3 月，Claude Code 负责人 Boris Cherny 公开表示：

Claude Code 早期使用过 RAG，后来将它从产品中移除了。

他提到的原因包括：

• 隐私；
• 安全；
• 可靠性；
• 索引陈旧。

2026 年 5 月，Anthropic 在介绍 Claude Code 如何处理大型代码库时，又进一步说明：

Claude Code 会直接遍历开发者机器上的文件系统，读取文件，使用 grep 搜索内容，再顺着代码引用继续查找。它不要求开发者先为整个代码库建立并上传一个集中式索引。

官方文章中有一句非常关键的话：

There’s no embedding pipeline or centralized index to maintain.

简单来说就是：

Claude Code 不需要维护一套集中式的代码向量索引。

但这不等于：

• RAG 已经无效；
• 向量检索不适合代码；
• 代码只需要 grep；
• 所有代码助手都应该取消索引。

更准确的说法是：

Claude Code 放弃的是“把预先建立的代码向量索引作为默认导航方式”的方案。

这句话虽然没有“RAG 已死”那么刺激，却更接近事实。

---

二、RAG 到底是什么？

很多人一听到 RAG，就会立刻想到：

• 把文档切成小块；
• 给每块生成向量；
• 存入向量数据库；
• 根据相似度找出几段内容；
• 交给大模型生成答案。

这确实是最常见的 RAG，但它不是 RAG 的全部。

RAG 的全称是 Retrieval-Augmented Generation，中文通常叫“检索增强生成”。

如果不用专业术语，可以把它理解成：

先帮 AI 查资料，再让 AI 根据查到的资料回答。

它本质上是一场“开卷考试”。

至于资料怎么查，可以有很多方式：

• 搜索关键词；
• 查询数据库；
• 使用传统全文搜索；
• 使用 BM25；
• 使用向量搜索；
• 查询知识图谱；
• 调用代码符号工具；
• 混合使用多种搜索方式。

因此，RAG 不等于向量数据库，向量搜索只是 RAG 的一种常见实现。

不过，在 Claude Code 团队讨论“放弃 RAG”时，他们主要指的是一种更具体的方案：

提前拆分整个代码库，生成 embedding，建立向量索引，然后在提问时召回相关代码。

为了避免混淆，我们不妨把它叫作：

索引式向量 RAG。

Claude Code 放弃的主要是这一条默认路线。

---

三、为什么代码库像一座“每天都在改书的图书馆”？

普通文档通常比较稳定。

一本产品手册今天写完，下周可能还是原来的内容。提前为它建立索引，往往很划算。

但代码库不同。

程序员可能刚刚完成以下操作：

• 把一个函数改名；
• 删除一个旧模块；
• 新建一个文件；
• 切换到另一个 Git 分支；
• 修改了代码，但还没有提交；
• 临时回滚了一部分改动。

也就是说，代码库不是一座安静的图书馆，而是一座所有人都在同时改书的图书馆。

如果索引没有及时更新，就可能发生这样的事情：

1. 昨天，系统为函数 loginUser 建立了索引；
2. 今天，程序员把它改名为 authenticateUser；
3. AI 查询的还是昨天的索引；
4. 索引返回了已经过时的 loginUser；
5. AI 根据旧代码给出修改建议。

问题不一定出在 AI“不会写代码”，而可能是它拿到的资料已经过期。

Claude Code 选择的办法更直接：

不先询问另一份代码索引，而是尽量直接查看开发者当前磁盘上的工作副本。

这样做最大的好处，就是新鲜。

文件刚改完，下一次搜索就可以看到新内容，不必等待另一套索引同步完成。

当然，这也不是绝对实时。

例如：

• 编辑器里的内容还没有保存；
• 某些目录被忽略规则排除了；
• 依赖代码在远程服务器上；
• LSP 或其他工具还没有完成刷新。

因此，更准确的表述是：

直接搜索当前工作区，通常比查询独立索引更接近开发者此刻看到的代码。

---

四、Agentic Search 到底是怎么工作的？

Agentic Search 并不是“用 grep 搜一下就结束”。

它真正重要的地方，是 AI 可以根据中间结果决定下一步做什么。

例如，你对 Claude Code 说：

帮我查一下，用户登录失败后为什么没有自动重试。

它可能会这样调查：

1. 先搜索“登录失败”对应的错误信息；
2. 找到几个可能相关的文件；
3. 打开登录模块；
4. 搜索 retry、backoff 或重试次数；
5. 沿着函数调用找到真正发送请求的地方；
6. 查找谁调用了这个函数；
7. 查看配置文件里是否关闭了重试；
8. 修改代码后运行测试；
9. 如果测试失败，再根据错误继续调查。

这和普通搜索最大的不同是：

普通搜索只负责返回结果，代理还会判断结果是否有用，并决定下一步查什么。

它不是一次搜索，而是一个循环：

搜索 → 阅读 → 判断 → 改写问题 → 再搜索 → 验证。

这就是 Agentic Search 的核心。

---

五、既然实时搜索这么好，为什么其他产品还在做语义索引？

因为不同问题，需要不同的搜索工具。

情况一：你知道准确名字

例如：

• UserService 在哪里？
• 错误码 ERR_4017 是谁抛出的？
• 哪些地方使用了 MAX_RETRY_COUNT？

这种问题最适合文本搜索。

因为名字已经知道了，直接找就行。grep、ripgrep 一类工具通常又快又准。

情况二：你知道意思，但不知道名字

例如：

• 用户权限检查在哪里？
• 哪段代码负责订单超时？
• 系统在哪里处理重复提交？
• 哪个模块会在请求失败后自动重试？

这时你并不知道开发者给它起了什么名字。

它可能叫：

• checkPermission；
• authorize；
• verifyAccess；
• ensureAllowed；
• 甚至是一个完全看不出用途的内部缩写。

单纯搜索“权限检查”未必找得到。

这正是语义检索擅长的场景：

即使文字不一样，只要意思接近，也尽量把相关代码找出来。

情况三：你要找程序关系

例如：

• 这个函数真正定义在哪里？
• 哪些地方调用了它？
• 这两个同名函数是不是同一个？
• 一个接口有哪些实现？
• 修改这个类会影响哪些模块？

这种问题更适合 LSP、AST 或代码图。

LSP 可以理解成编辑器里“跳转到定义”“查找所有引用”的能力。

grep 看到的是字符串，LSP 看到的是程序中的符号关系。

比如两个不同文件里都有 save 函数。grep 只能告诉你它们都叫 save，而 LSP 更有机会判断当前这次调用究竟指向哪一个。

所以，正确的判断不是“谁取代谁”，而是：

• 知道名字，使用文本搜索；
• 不知道名字，使用语义搜索；
• 要找程序关系，使用 LSP；
• 问题比较复杂，让代理组合多种工具。

---

六、GitHub Copilot 和 Cursor 为什么没有跟着完全取消索引？

因为它们选择了不同的工程路线。

GitHub Copilot 公开使用语义代码索引。它的代理在不知道准确名称和模式时，可以使用语义搜索寻找相关代码；知道名字时，又可以使用文本搜索、文件搜索和符号工具。

Cursor 也会为代码生成 embedding，并通过 Merkle Tree 判断哪些文件发生了变化。文件没有变化，就尽量复用原来的结果；文件发生了变化，再更新相应部分。

这说明索引不是只能“全部重建”。

现代系统可以进行：

• 增量更新；
• 后台更新；
• 缓存未变化的代码块；
• 只处理发生变化的文件。

所以，“索引一定无法实时更新”是错误的。

更准确的说法是：

索引可以做得很快，但它仍然多了一套需要同步、维护和管理的系统。

Claude Code 选择尽量不依赖这套系统；GitHub Copilot 和 Cursor 则认为，语义索引带来的概念搜索能力值得保留。

它们不是一方先进、一方落后，而是在做不同取舍。

---

七、Agentic Search 一定更便宜吗？

不一定。

索引式 RAG 的成本主要发生在前面：

• 拆分代码；
• 生成 embedding；
• 建立索引；
• 同步变化；
• 管理权限；
• 存储和更新数据。

但索引建立后，可以重复使用。

如果一家公司有几千名开发者，每天都在查询同一个巨大代码库，提前建立索引可能很划算。

Agentic Search 不需要先完成这些准备工作，但每次执行任务时，可能需要：

• 多轮搜索；
• 打开很多文件；
• 读取大量代码；
• 多次调用模型；
• 消耗更多 Token；
• 等待更多工具执行。

它把一部分成本从“提前建索引”转移到了“每次现场调查”。

因此：

• 查询少、代码变化快，实时搜索可能更合适；
• 查询多、仓库巨大、重复问题多，索引可能更划算；
• 很多情况下，混合使用两种方式效果最好。

不存在一个对所有项目都最便宜的答案。

---

八、不建立索引，就一定更安全吗？

也不一定。

Claude Code 不维护集中式代码索引，确实减少了一类风险：

• 少了一份长期保存的代码副本；
• 少了一套索引访问权限；
• 少了索引与仓库权限不同步的问题；
• 少了删除代码后还要清理索引的责任。

但“本地搜索”只说明搜索动作发生在本地。

搜索到的代码仍可能：

• 进入模型上下文；
• 被发送到远程推理服务；
• 出现在日志中；
• 被第三方 MCP 工具读取；
• 因权限设置不当而访问到不该访问的目录；
• 因提示注入诱导代理读取敏感文件。

反过来，语义索引也不一定意味着“第三方永久保存全部明文代码”。

有些系统可能：

• 本地建立索引；
• 企业自托管；
• 对数据加密；
• 只保存必要的 embedding 和元数据；
• 设置明确的保留期和删除机制。

所以，判断一个代码助手是否安全，不能只问：

它用不用 RAG？

真正应该问的是：

1. 哪些文件会被读取？
2. 哪些内容会离开电脑？
3. 数据以什么形式保存？
4. 保存多长时间？
5. 谁可以访问？
6. 是否遵守仓库权限？
7. 第三方插件能看到什么？
8. 能不能删除和审计？

安全不是一个技术名词决定的，而是整条数据链路决定的。

---

九、这件事对普通开发者有什么实际意义？

如果你只是使用 AI 编程工具，不需要站队。

你真正需要学会的是：什么问题该用什么方法。

1. 提问时尽量提供起点

不要只说：

帮我看看这个项目为什么有问题。

更好的说法是：

支付模块在处理超时订单时没有释放库存，错误出现在 services/order 附近，请先追踪订单取消和库存回滚的调用关系。

起点越明确，代理越不需要在整个代码库里盲目搜索。

2. 不要把“找到相关代码”当成“找到正确答案”

搜索结果排在第一，只说明它看起来相关，不代表它一定正确。

AI 找到的代码可能是：

• 已废弃实现；
• 测试样例；
• 历史兼容代码；
• 另一个团队的相似模块；
• 本身就存在 Bug 的旧实现。

因此，任何修改都应该继续经过：

• 类型检查；
• 静态分析；
• 编译；
• 单元测试；
• 集成测试；
• 人工审查。

检索负责找线索，测试才负责验答案。

3. 敏感项目不要只相信宣传语

“本地运行”“不建索引”“隐私模式”“企业安全”都不等于代码绝不离开设备。

处理公司核心代码时，要查看产品的：

• 数据传输说明；
• 数据保留政策；
• 模型训练政策；
• 企业权限控制；
• 第三方插件权限；
• 日志和删除机制。

不要根据“RAG”或“Agentic”两个词判断安全。

4. 团队可以采用混合路线

一个现实的团队方案可能是：

• grep 负责精确文字搜索；
• LSP 负责定义和引用；
• 语义索引负责自然语言找代码；
• Agent 负责决定何时调用哪种工具；
• 编译器和测试负责验证结果。

这往往比强迫所有问题只使用一种搜索技术更合理。

---

十、记住这个简单口诀

如果前面的概念有点多，只需要记住下面五句话：

知道名字，用文本搜索。
不知道名字，用语义搜索。
要找关系，用 LSP。
问题复杂，让 Agent 组合工具。
代码对不对，最终还得靠测试。

---

结语：不是 RAG 已死，而是工具开始各司其职

Claude Code 的选择有很现实的理由。

直接查看当前工作区，可以减少索引陈旧和额外副本带来的问题，也免去了搭建、同步和维护集中式代码索引的成本。

但它也有代价：

• 需要更多搜索轮次；
• 可能消耗更多 Token；
• 面对巨大代码库时容易产生大量结果；
• 依赖良好的目录结构和起始上下文；
• 不知道准确名称时，文本搜索可能力不从心。

语义索引也一样。

它能帮助 AI 根据“意思”寻找代码，却需要处理索引更新、权限同步、存储、成本和隐私问题。

所以，真正成熟的结论不是：

Agentic Search 打败了 RAG。

而是：

Claude Code 不再把预建向量索引作为默认代码库导航层，而是优先让代理直接使用实时工具探索当前工作区。

整个行业真正走向的，也不是某一种搜索方式统治一切，而是：

文本搜索负责精确，语义搜索负责发现，符号工具负责关系，Agent 负责规划，测试负责验证。

这才是 Claude Code 放弃早期 RAG 方案之后，最值得普通开发者理解的事情。

---

主要参考资料

1. Anthropic：How Claude Code works in large codebases，2026-05-14
2. Boris Cherny 关于 Claude Code 下线早期 RAG 的公开说明，2026-03-21
3. Anthropic：Introducing Contextual Retrieval，2024-09-19
4. GitHub：Instant semantic code search indexing，2025-03-12
5. GitHub Docs：Indexing repositories for GitHub Copilot
6. Cursor：Securely indexing large codebases，2026-01-27
7. RepoCoder：Repository-Level Code Completion Through Iterative Retrieval and Generation，EMNLP 2023