Claude code最后放弃了RAG? 还是选用了GREP
Claude CodeCC采用的 Agentic Search智能体搜索本质上是一个**“观察-思考-行动”的闭环迭代系统**。它不再试图一次性把“正确答案”找出来而是像人类程序员一样通过不断的线索追踪来缩小包围圈。这个工作流通常包含以下 4 个核心步骤第一步全局扫描与初步定位Glob Grep当用户提出一个需求比如“帮我找到处理用户登录鉴权的代码”时模型首先会进行全局的“泛搜索”Glob文件匹配根据文件命名规律先圈定范围。例如搜索*auth*.ts或*login*.py快速过滤掉无关的文件夹。Grep内容匹配在圈定的文件范围内使用关键词进行正则匹配。比如搜索function validateToken或if (user.isAuthenticated)。产出得到一个包含几十个甚至上百个“疑似目标”的文件路径和代码行号列表。第二步上下文读取与理解ReadGrep 只能给出零散的代码行模型无法理解全貌。因此智能体会调用Read工具读取完整文件将上一步匹配到的关键文件的完整源码加载到上下文中。跨文件追踪如果在 A 文件中看到了import { login } from ./authService智能体会自动把authService.ts也读进来建立文件间的调用关系。第三步自我评估与逻辑判断Think这是 Agentic Search 最核心的“大脑”环节。模型会阅读刚刚加载的源码并进行自我提问和评估线索是否充足“这个login函数只是前端的一个按钮点击事件并没有包含真正的鉴权逻辑这不是我要找的终点。”是否需要缩小范围“我发现所有鉴权都调用了AuthService类我应该把搜索关键词从login换成AuthService。”是否需要扩大范围“这个函数里用到了一个自定义的checkPermission但我不知道它在哪定义的我需要全局搜索这个新关键词。”第四步迭代深挖与最终锁定Loop根据第三步的判断智能体会进入下一个循环如果线索断了它会更换关键词重新发起Grep。如果找到了疑似的核心逻辑它会继续Read该逻辑调用的底层函数。如此反复Grep → Read → Think直到模型确信自己已经找到了包含完整业务逻辑、且没有遗漏依赖的最终代码片段。 为什么这个流程比 RAG 强具备“纠错能力”RAG 如果第一次向量检索偏了后面 LLM 总结得再好也是错的。而 Agentic Search 发现线索不对可以自己换词重新搜具备自我修正的韧性。保留“代码完整性”RAG 会把代码切成碎片Chunk破坏函数的完整性。Agentic Search 最终交给 LLM 的是完整的、未被切割的源文件LLM 写代码时绝对不会出现“括号对不上”或“变量未定义”的低级错误。节省 Token它不会把整个代码库的摘要都塞给 LLM而是只读取它认为必要的那几个文件极其精准地控制上下文窗口。这种工作流完美契合了人类程序员“全局搜一下 - 打开文件看看 - 发现不对再搜另一个词 - 最终定位”的真实排查直觉。