聊起大模型的检索方案，很多人的第一反应都是一套标准的RAG流程：文本切块、向量嵌入、存入向量库、查询时召回Top-K、再经过重排序喂给模型。这套组合拳在知识库问答、文档检索场景里屡试不爽，以至于不少人形成了思维定式：只要是检索问题，上RAG就对了。

但有意思的是，作为当下编程Agent领域的标杆产品，Claude Code的核心代码检索路径，并没有押注传统RAG方案，反而把grep、glob这种诞生了几十年的朴素命令行工具，做成了代码探索的核心能力。

很多人第一反应是“这也太土了”，甚至觉得是技术倒退。但恰恰是这个看似“复古”的选择，藏着对代码检索本质的深刻理解。这从来不是grep和RAG谁更先进的技术比拼，而是一场围绕场景的工程选型——代码检索，从根上就和普通文档检索不是一回事。

一、别把代码当成普通文本

对RAG的执念，往往来自一个默认前提：代码也是文本，所以文档检索的方案平移过来就能用。但这恰恰是最根本的认知误区。

一篇产品文档，哪怕句子被拆成两段、段落缺了开头，大概率也能读懂大概意思。但代码是强结构化的逻辑实体，一个if分支缺了条件、一个函数缺了参数定义、一个类缺了依赖的接口，逻辑就完全不成立。你召回半段函数给模型，它根本没法判断这段逻辑的完整上下文，写出来的代码自然充满幻觉。

更关键的是，代码检索的目标和文档检索完全不同。文档检索追求的是找到语义相关的内容，用户的问题模糊，答案可以由多个片段拼接而成。但代码检索的需求，往往指向非常明确：

• 找符号：精确找到某个函数、类、变量的定义，差一个字母都不行；

• 找入口：从模糊的业务描述出发，定位到对应的文件和逻辑起点；

• 找关系：沿着调用链追踪数据从入口到入库的完整路径；

• 找变化：基于最新修改的代码排查问题，一秒前的改动都要立刻生效。

这些需求的核心从来不是“找相似”，而是找准确——在一个持续迭代、结构严谨的工程里，快速定位到当前任务需要的最小有效上下文。多给无关内容，不是补充信息，而是制造噪声。

二、传统RAG落地代码场景的四个硬伤

当然不是说RAG完全不能用于代码检索，而是传统文档RAG的设计思路，和代码场景的核心需求天然错位，直接套用会遇到非常多结构性硬伤。

2.1 切块天生破坏代码结构

RAG的第一步就是切块，而代码切块几乎是无解的两难问题。

按固定行数切，必然会切碎函数、类和条件分支；按函数切，会丢失类定义、导入依赖、全局配置这些上下文；按文件切，大文件又会远超单块的长度限制。哪怕引入AST做结构化切块，多语言适配、语法兼容、异常处理的工程成本会指数级上升，很难做到通用。

更麻烦的是，代码的意义从来不只在片段本身。一个函数的参数类型、返回值定义、上游的调用方、下游的依赖函数、对应的配置项和数据库表结构，共同构成了完整的逻辑上下文。传统RAG召回的单个代码片段，看着和问题高度相关，实则是残缺的逻辑碎片，模型基于碎片做修改，很容易越改越错。

2.2 向量相似不等于代码正确

向量检索的优势是语义匹配，但代码场景里，精确匹配才是底线。

你要找validateToken这个函数，向量库可能给你返回一堆verifyToken、decodeToken、refreshToken，每一个语义上都高度相关，但没有一个是你真正要修改的目标。

对于文档问答，相似内容可以辅助回答；但对于代码修改，找错了目标就是完全的错误。语义相似是加分项，但精确命中是及格线。丢掉及格线去追求加分项，本质是本末倒置。

2.3 索引滞后与实时开发的矛盾

知识库的内容相对稳定，每天更新一次索引完全够用。但代码是高频动态变更的——开发者改完一行代码，下一秒就要读它验证逻辑、排查bug。

如果用RAG方案，就必须面对索引更新的一致性难题：修改后的文件什么时候重算向量？函数签名变了，所有调用它的文件对应的chunk要不要同步更新？跨文件的引用关系怎么同步失效？这些问题不是不能解决，而是要付出极高的工程代价，还要承担索引不及时带来的线上错误风险。

而grep和文件读取是直接读磁盘，文件是什么样，读到的就是什么样，天然不存在缓存一致性问题。对于实时编码场景，这份确定性比什么都重要。

2.4 一次性召回适配不了动态探索

传统RAG的核心逻辑是一次性下注：用户提出问题，系统一次性召回Top-K个片段，模型基于这些内容给出答案。如果召回阶段选错了内容，后面的整个流程都会跑偏。

但真实的代码探索是动态闭环决策链：先搜一个关键词，结果太多就缩小目录范围，没搜到就换同义词，看到一个函数调用就顺着链路往下追，发现分支逻辑就补充读取上下文。这是一个“搜索-判断-再搜索”的循环过程，而不是一次召回就能解决的问题。

RAG像把所有参考资料一次性发给你，而写代码更像现场探案，需要根据线索不断调整侦查方向。

三、核心关键：朴素工具+Agent多轮循环

很多人以为Claude Code只是给grep套了层壳，其实远不止于此。它真正厉害的地方，是把Glob、Grep、Read这三个朴素的工具，放进了Agent多轮决策循环里，让模型像真正的程序员一样去探索代码。

这三件套各司其职，共同构建了完整的代码探索链路：

• Glob：解决文件入口问题。当你不知道具体的代码关键词，只知道工程的命名规范时，比如找所有路由文件、测试文件、配置文件，用文件名模式匹配比向量检索高效得多。项目越规范，Glob的命中率就越高。

• Grep：解决精确内容定位。函数名、类名、配置键、错误码这些字面符号，用关键词和正则搜索的准确率远高于向量检索，而且结果完全可解释——哪一行命中、命中了多少次，清清楚楚。

• Read：解决上下文边界问题。不是整文件一股脑塞给模型，而是先通过Grep定位到命中行，再按需读取前后几十行代码；顺着调用链跳转时，再读取对应文件的对应片段，永远只提供当前需要的最小信息。

这三个工具单独拿出来都很普通，但当它们运行在Agent的多轮循环里，就发生了质变。

模型不会一次性把所有相关内容都拉回来，而是走一步判断一步：先搜关键词，根据命中数量决定要不要缩小目录；读到一个函数调用，就决定要不要跟进它的实现；发现逻辑分支，就决定要不要补充读取更多上下文。每一次工具返回的结果，都不是最终答案，而是下一轮决策的证据。

这才是这套方案的本质：它不是一个搜索工具，而是一个会自主调整搜索策略的代码侦查流程。grep本身很老，但grep + Agent Loop的组合，一点都不老。

至于为什么不直接开放Bash让模型自由敲命令，这恰恰是成熟工程化的考量。专用工具有清晰的读写权限边界：Grep和Read是只读工具，Edit和Write是可写工具，安全风险可控；工具的输出是结构化的，文件路径、行号、匹配内容都有稳定格式，模型不用处理杂乱的终端输出；甚至工具的定义本身就会进入提示词，引导模型在合适的场景用合适的工具，从底层规范Agent的行为。

四、子Agent机制：隔离探索噪声，解决上下文污染

有人会提出疑问：一直搜一直读，上下文窗口不会被撑爆吗？中间产生的大量搜索结果，不会干扰后续的代码生成吗？

这就要说到Claude Code的子Agent机制（Task工具），也是其代码检索高效的核心细节之一。

当需要做大规模的代码探索，比如梳理一整条支付链路、调研整个项目的鉴权方案，中间会产生大量的中间搜索结果和文件片段。这些内容对探索过程是必要的，但对最终写代码来说，大部分都是噪声。如果所有中间结果都塞进主Agent的上下文，后续真正修改代码时，模型的注意力会被大量无关的探索过程分散，也就是上下文污染。

子Agent的核心价值，就是把探索过程和代码执行过程彻底隔离。主Agent只需要下达一个明确的任务指令，子Agent就在自己独立的上下文窗口里完成所有的搜索、阅读、梳理工作，最后只把压缩后的核心结论返回给主Agent。主Agent不需要记住所有搜索过程和中间片段，只需要拿到关键文件、核心逻辑、修改点和注意事项，就可以开始动手修改。

同时子Agent还可以做权限隔离：探索型子Agent只开放Glob、Grep、Read这些只读工具，不允许修改文件，从架构层面规避误操作风险。这不是简单的“多Agent并行干活”，而是通过上下文隔离，实现了探索和执行的解耦。

五、技术无银弹：RAG依旧有专属应用场景

说到这里，千万不要走入另一个极端，觉得RAG在代码场景已经毫无价值。技术选型从来不是非黑即白的站队，grep方案适合Claude Code的主战场——单仓实时开发、精确代码修改、多轮探索排查，但在很多场景里，RAG依然是不可或缺的方案。

5.1 超大规模跨仓库检索

当企业有几十个甚至上百个代码仓库、几亿行代码时，全量grep的时间成本会非常高，这时候就需要混合检索架构：关键词倒排索引、符号索引、AST索引、调用图索引再加上向量索引，各司其职，共同完成高效检索。

5.2 模糊语义需求探索

当用户提出无明确关键词的模糊需求，比如“梳理项目权限收敛逻辑”“查找限流熔断相关实现”，纯grep无从下手。此时可依托向量检索的语义优势挖掘潜在相关代码，再通过语义检索做发现，grep做确认，大幅提升探索效率。

5.3 代码+文档综合知识问答

很多架构决策背景、历史踩坑记录、业务规则由来，都沉淀在设计文档、Wiki、故障复盘报告中，而非代码本身。这类团队知识问答场景，正是RAG的核心优势领域，能够弥补grep仅能检索代码文件的短板。

5.4 团队长期知识沉淀

针对代码规范、工程最佳实践、常见故障解决方案等需要长期积累、复用的团队知识，RAG可实现长效记忆和智能检索，是grep动态检索无法替代的能力。

六、总结：工程选型的核心是适配场景

说到底，Claude Code选择用grep+Agent循环，而非传统RAG作为代码检索的主路径，本质上是一场非常务实的工程取舍。

实时开发的核心诉求是精确、实时、可解释，那就用最简单的工具把核心体验做到极致；跨仓语义探索、团队知识沉淀有需求，那就用RAG作为补充。没有万能的架构，只有适配场景的选型。

技术圈很容易陷入“唯先进论”的误区，觉得越复杂、越前沿的方案就越厉害。但真正的工程能力，恰恰是能穿透技术名词的表象，看清问题的本质，用最朴素的方案解决最核心的矛盾。

不迷信主流方案，不堆砌复杂技术，把简单工具用到极致，反而能做出最扎实、最可靠的设计。这也是这场经典技术选型，带给所有开发者的核心启发。

---

互动话题：做代码智能检索时，你更看好 grep 这类精准检索还是 RAG 语义检索？平时开发排查代码你习惯用哪种方式？欢迎在评论区聊聊你的项目实操感受吧！我是阿宇，欢迎道友互动交流^^