相信很多开发者第一次听说 Claude Code 内部不使用 RAG检索增强生成时第一反应多半是震惊与不解。毕竟RAG 几乎已经是当下 AI 应用在外部知识检索上的标准范式。而 Claude Code 作为一款公认的顶流 AI 编程工具其创建者 Boris Cherny 却公开表示“Early versions of Claude Code used RAG a local vector db, but we found pretty quickly that agentic search generally works better.” 并进一步强调“Plain glob and grep, driven by the model, beat everything.”这听上去确实有些反直觉。一个依赖传统 grep 文本搜索的工具如何在大型代码仓库中实现快速、精准的语义查找它背后的机制以及它刻意“舍弃”RAG 的考量其实正指向一条截然不同的技术路线。第一幕主流的“字典”方案——RAG 的运作逻辑要理解 Claude Code 的选择需要先看清 RAG 在代码场景下的基本动作。如果把一个庞大的代码库比作一整座图书馆那么 RAG 的工作方式很像为每本书提前制作好“语义分类卡片”切片系统先把所有代码按函数、类或固定长度拆解成无数个小片段。向量化每个片段通过一个 Embedding 模型处理将其转化为一串高维空间的数字坐标也就是“语义指纹”。其核心思想是功能相似的代码其“指纹”在空间中的距离也会更近。建索引所有这些“语义指纹”被集中存放于一个向量数据库中。召回当用户提问时系统会先将问题也转化为“语义指纹”然后去数据库中寻找距离最近的 Top‑K 个代码片段拼凑成上下文喂给大模型。这套方案在静态文档或 FAQ 场景中效果拔群。Cursor 便是这条路线上的典型代表它内置了完善的代码库索引机制其创始人很早便分享了这一技术细节。第二幕Claude Code 的“侦探”逻辑——Agentic SearchClaude Code 走的却是另一条路它不建任何预先索引而是让 LLM 像人类侦探一样在现场实时搜索、推理和决策。这里的核心是一个被称为Agentic Search智能体搜索的循环机制。它并非一个预设好的、固定的搜索流程而是一个由 LLM 全权驾驶的实时决策环路。假设在探索源码时突然好奇“当 Claude Code 调用 GrepTool 做搜索时bridge 是如何追踪和记录这次工具调用的” 整个检索过程将会是这样展开的启动与决策LLM 拿到这个模糊的问题后首先在“脑海”中制定策略。要找到追踪记录的逻辑很可能需要先定位bridge相关的文件。于是它发出一项工具调用指令Glob(**/bridge**)。工具执行与反馈Claude Code 的执行层在获得指令和权限后在本地运行对应工具的代码。例如使用ripgrep快速地执行文本搜索然后将匹配的文件列表返回给 LLM。推理与迭代LLM 观察到bridge/目录下有多个文件。它需要收紧范围于是根据开发者常使用的词汇生成一个更精准的正则表达式比如Grep(track|trace|log, pathbridge/)开启新一轮搜索。深度阅读与综合几轮GrepGlob交替搜索后LLM 终于锁定了核心文件bridge/src/session/tracer.ts。此时它会发出Read指令仔细阅读相关函数的实现细节。给出答案最后LLM 综合所有在搜索过程中读取到的关键代码行梳理出完整的追踪逻辑并以自然语言形式呈现在用户眼前。整个过程中LLM 不仅是执行者更是大脑。它自行决定搜索关键词、使用哪种工具、如何解读搜索结果并决定何时继续深挖、何时可以结束任务。除了Grep和Glob这套闭环工具还包括文件读取、LSP语言服务器协议符号跳转如“转到定义”、可运行的 Bash 命令等共同构成了一个强大的“现场勘查箱”。第三幕用“暴力”换取“实时”与“精准”这个方案听起来颇为“原始”但它的有效性扎根于几个独特的优势。极致的时效性RAG 的向量索引在代码变更后需要重建存在维护成本和延迟。而 Agentic Search 每次都是进行实时搜索查到的永远是代码库的最新状态。对于高速迭代的开发场景这种“即时性”至关重要。精确匹配的优势开发者经常需要查找精确的函数名、类名或特定的字符串。这正是grep的天下。向量语义搜索有时会返回过于“发散”的结果而模型驱动的grep则能做到指哪打哪分毫不差。Boris Cherny 就曾分享过他发现许多工程师在 IDE 的“跳转到定义”功能失效时会本能地退回到手动grep搜索这给了他重要启发。深度整合与原子化操作Agentic Search 并非单一的grep它是多个原子化工具的有机组合。例如它可以先用grep发现线索再利用 LSP 协议的Go to Definition或Find References功能在函数调用链上灵活跳转深度理解代码的结构与关联这远超单纯文本匹配或语义向量召回的深度。突破性的上下文复用在执行复杂的多轮搜索时每次与 LLM 的交互都可能消耗大量上下文。Claude Code 在此展现出了高超的工程优化。有研究通过拦截其与 API 的通信发现在一次涉及 92 次 LLM 调用的复杂任务中其92% 的提示词前缀即历史对话与搜索轨迹都能被复用这极大降低了重复计算成本和延迟。终幕硬币的另一面——权衡与融合当然Agentic Search 也并非完美无瑕。它的核心问题在于多轮搜索会带来大量的 Token 消耗和等待时间。例如有用户反馈为了解决一个复杂的 BugClaude Code 反复进行了多次搜索和文件读取尽管最终定位到了问题所在的 10 行代码但过程中读取了大量无关代码耗费了 5 分钟之久。这正是 RAG 方案的支持者们主要诟病的地方。正因为存在这种短板一个名为MCP模型上下文协议的生态出现了。这可以理解为 AI 时代的“USB‑C 接口”为 Claude Code 这类工具连接外部能力提供了统一标准。开发者可以通过编写符合 MCP 规范的服务器为 Claude Code 无缝挂载向量数据库、知识图谱等能力以弥补其在语义理解上的不足实现优势互补。总结两种哲学各有所长最终这场路线之争折射出的是两种设计哲学的权衡RAG检索增强倾向于“准备充分有的放矢”用空间构建索引换取时间检索效率。Agentic Search智能体搜索则追求“无需准备现场破案”用智能模型推理换取灵活与精确。Claude Code 的选择并不是因为它做不了 RAG而是因为它选择将“智能”放在最核心的位置信任一个强大的 LLM 驱动的智能体能够在没有预先准备的情况下在庞大的代码宇宙中完成一次次精准的“现场勘查”。
Claude Code 代码检索技术深度解析
相信很多开发者第一次听说 Claude Code 内部不使用 RAG检索增强生成时第一反应多半是震惊与不解。毕竟RAG 几乎已经是当下 AI 应用在外部知识检索上的标准范式。而 Claude Code 作为一款公认的顶流 AI 编程工具其创建者 Boris Cherny 却公开表示“Early versions of Claude Code used RAG a local vector db, but we found pretty quickly that agentic search generally works better.” 并进一步强调“Plain glob and grep, driven by the model, beat everything.”这听上去确实有些反直觉。一个依赖传统 grep 文本搜索的工具如何在大型代码仓库中实现快速、精准的语义查找它背后的机制以及它刻意“舍弃”RAG 的考量其实正指向一条截然不同的技术路线。第一幕主流的“字典”方案——RAG 的运作逻辑要理解 Claude Code 的选择需要先看清 RAG 在代码场景下的基本动作。如果把一个庞大的代码库比作一整座图书馆那么 RAG 的工作方式很像为每本书提前制作好“语义分类卡片”切片系统先把所有代码按函数、类或固定长度拆解成无数个小片段。向量化每个片段通过一个 Embedding 模型处理将其转化为一串高维空间的数字坐标也就是“语义指纹”。其核心思想是功能相似的代码其“指纹”在空间中的距离也会更近。建索引所有这些“语义指纹”被集中存放于一个向量数据库中。召回当用户提问时系统会先将问题也转化为“语义指纹”然后去数据库中寻找距离最近的 Top‑K 个代码片段拼凑成上下文喂给大模型。这套方案在静态文档或 FAQ 场景中效果拔群。Cursor 便是这条路线上的典型代表它内置了完善的代码库索引机制其创始人很早便分享了这一技术细节。第二幕Claude Code 的“侦探”逻辑——Agentic SearchClaude Code 走的却是另一条路它不建任何预先索引而是让 LLM 像人类侦探一样在现场实时搜索、推理和决策。这里的核心是一个被称为Agentic Search智能体搜索的循环机制。它并非一个预设好的、固定的搜索流程而是一个由 LLM 全权驾驶的实时决策环路。假设在探索源码时突然好奇“当 Claude Code 调用 GrepTool 做搜索时bridge 是如何追踪和记录这次工具调用的” 整个检索过程将会是这样展开的启动与决策LLM 拿到这个模糊的问题后首先在“脑海”中制定策略。要找到追踪记录的逻辑很可能需要先定位bridge相关的文件。于是它发出一项工具调用指令Glob(**/bridge**)。工具执行与反馈Claude Code 的执行层在获得指令和权限后在本地运行对应工具的代码。例如使用ripgrep快速地执行文本搜索然后将匹配的文件列表返回给 LLM。推理与迭代LLM 观察到bridge/目录下有多个文件。它需要收紧范围于是根据开发者常使用的词汇生成一个更精准的正则表达式比如Grep(track|trace|log, pathbridge/)开启新一轮搜索。深度阅读与综合几轮GrepGlob交替搜索后LLM 终于锁定了核心文件bridge/src/session/tracer.ts。此时它会发出Read指令仔细阅读相关函数的实现细节。给出答案最后LLM 综合所有在搜索过程中读取到的关键代码行梳理出完整的追踪逻辑并以自然语言形式呈现在用户眼前。整个过程中LLM 不仅是执行者更是大脑。它自行决定搜索关键词、使用哪种工具、如何解读搜索结果并决定何时继续深挖、何时可以结束任务。除了Grep和Glob这套闭环工具还包括文件读取、LSP语言服务器协议符号跳转如“转到定义”、可运行的 Bash 命令等共同构成了一个强大的“现场勘查箱”。第三幕用“暴力”换取“实时”与“精准”这个方案听起来颇为“原始”但它的有效性扎根于几个独特的优势。极致的时效性RAG 的向量索引在代码变更后需要重建存在维护成本和延迟。而 Agentic Search 每次都是进行实时搜索查到的永远是代码库的最新状态。对于高速迭代的开发场景这种“即时性”至关重要。精确匹配的优势开发者经常需要查找精确的函数名、类名或特定的字符串。这正是grep的天下。向量语义搜索有时会返回过于“发散”的结果而模型驱动的grep则能做到指哪打哪分毫不差。Boris Cherny 就曾分享过他发现许多工程师在 IDE 的“跳转到定义”功能失效时会本能地退回到手动grep搜索这给了他重要启发。深度整合与原子化操作Agentic Search 并非单一的grep它是多个原子化工具的有机组合。例如它可以先用grep发现线索再利用 LSP 协议的Go to Definition或Find References功能在函数调用链上灵活跳转深度理解代码的结构与关联这远超单纯文本匹配或语义向量召回的深度。突破性的上下文复用在执行复杂的多轮搜索时每次与 LLM 的交互都可能消耗大量上下文。Claude Code 在此展现出了高超的工程优化。有研究通过拦截其与 API 的通信发现在一次涉及 92 次 LLM 调用的复杂任务中其92% 的提示词前缀即历史对话与搜索轨迹都能被复用这极大降低了重复计算成本和延迟。终幕硬币的另一面——权衡与融合当然Agentic Search 也并非完美无瑕。它的核心问题在于多轮搜索会带来大量的 Token 消耗和等待时间。例如有用户反馈为了解决一个复杂的 BugClaude Code 反复进行了多次搜索和文件读取尽管最终定位到了问题所在的 10 行代码但过程中读取了大量无关代码耗费了 5 分钟之久。这正是 RAG 方案的支持者们主要诟病的地方。正因为存在这种短板一个名为MCP模型上下文协议的生态出现了。这可以理解为 AI 时代的“USB‑C 接口”为 Claude Code 这类工具连接外部能力提供了统一标准。开发者可以通过编写符合 MCP 规范的服务器为 Claude Code 无缝挂载向量数据库、知识图谱等能力以弥补其在语义理解上的不足实现优势互补。总结两种哲学各有所长最终这场路线之争折射出的是两种设计哲学的权衡RAG检索增强倾向于“准备充分有的放矢”用空间构建索引换取时间检索效率。Agentic Search智能体搜索则追求“无需准备现场破案”用智能模型推理换取灵活与精确。Claude Code 的选择并不是因为它做不了 RAG而是因为它选择将“智能”放在最核心的位置信任一个强大的 LLM 驱动的智能体能够在没有预先准备的情况下在庞大的代码宇宙中完成一次次精准的“现场勘查”。
