引言最近看到有一些文章提出了“RAG已死”的观点。 核心论据是 Claude Code 开发负责人 Boris Cherny 在一档播客节目[1]中，披露现在的 Claude Code已不再使用RAG，而改用 Agentic Search。 他的主要观点如下： 起初采用RAG路线，将整个代码库索引一遍，然后用 Voyage 这类检索器上，让模型用提示去查找信息，用的是标准模板。 但到最后，团队放弃了结构化检索，转而选择了最简单粗暴的办法：Agentic Search。
主要有以下三个原因：
第一，它比RAG强，不是说跑了什么标准测试，是纯“体感”，内部测了一圈，每个人一致觉得更聪明更顺滑；
第二，RAG要建索引，代码一变就过时，一天几次推送，索引没法实时更新；
第三，安全问题。索引如果被泄露，会出现安全性问题。
什么是 Agentic SearchClaude Code 用的 Agentic Search 指的是让AI自主去搜集相关信息。 主要方式很简单，用的就是Glob和Grep这样的传统工具，在源码文件中全文搜索匹配[2]： - Glob：查文件路径：匹配符合通配符模式的文件名或路径
Claude Code 在使用时，会有一些Read的步骤就在做此操作。 Coding 领域的路线之争在 Coding Agent领域，其实存在以下三种技术路线[3]： 第一组：完全抛弃RAG的实时搜索派
Cline 和 Claude Code
相似点：都完全放弃了传统的RAG方法，采用实时动态搜索 第二组：基于图结构的智能索引派
Aider
使用AST+图结构，将代码文件作为节点，依赖关系作为边，通过自定义排名算法（不是PageRank）优化代码映射 第三组：混合RAG+高级技术派
Cursor 和 Windsurf
相似点：都使用embeddings向量化+RAG，但加入了很多高级技术
区别： - Cursor：使用OpenAI的embedding模型+TurboPuffer向量数据库，实验DSI技术，支持云端分布式架构
- Windsurf：使用”M-Query技术”+本地/远程混合索引，专注企业级部署，有Cascade代理系统
Agentic Search 在目前的效果上优于 RAG，但代价就是需要花更长的时间进行检索，以及花更多的Token。 RAG本质RAG本质是空间换时间，知识库和数据库有点异曲同工，比如在 MySQL中，会通过构建B+树索引的方式，去加速查询。 所谓索引，就像给一本书加一个目录，需要用额外的纸张去记录，但提升了查询效率。 再比如一些检索库，ES会采用倒排索引，就是花额外的时间去构建一个倒排表，统计哪些词出现在哪些文档之中： RAG的局限是必须花额外的空间进行存储，并且需要提前把材料准备好，但对于一些高频修改的场景，如代码库，会存在时效性问题。 总结总而言之，到底采用 RAG 还是 Agentic Search 需要分场景讨论： - 如果是问答类应用场景，知识基本固化，采用 RAG 的方式更好，不会让用户等待特别长的时间
- 对于高频动态的场景，比如代码编辑的场景中，信息更迭加快，用 Agentic Search 反而能取得更好的效果
这两者是可以有机结合的，参照[4]一些复杂Agent的理论，记忆层分成以下四种类型，而RAG可以作为外部记忆，让Agent像调用工具一样进行获取。 | 
