不考虑 Token 消耗时，RAG 与让 Agent 用 grep 自行搜索文档或大代码仓库各有什么优劣？

核心回答

先约定比较对象：广义 RAG 是取外部证据辅助生成，Agent 用 grep 找资料后回答，也能属于检索增强。这里实际比较的是预建索引的检索流程与Agent 在运行时搜索、读文件、沿线索继续探索的流程，两者可以组合。

不计 Token 消耗，仍要比较证据覆盖、版本新鲜度、查询适配、探索能力、响应延迟和维护复杂度。预建索引适合大规模资料上的重复问答，语义检索有利于处理“问法与原文用词不同”；grep 适合精确符号、错误码和当前工作区内容，Agent 能读到新线索后继续追查，但会受关键词、搜索范围和停止判断影响。哪条路线都不自动保证找全证据。

沿任务要求比较

维度	预建索引的检索流程	Agent 自主搜索文件
自然语言问题	向量检索可找不同措辞的相关内容，也可加入关键词检索	grep 本身匹配字符串或正则；需要 Agent 找同义词、目录或真实术语
精确符号与编号	可以用关键词索引或精确字段；只用向量可能混入相似型号、符号	已知函数名、配置键、错误码时定位直接；命中后仍要读上下文
更新与覆盖	解析、切分、索引需要同步更新，也能增量维护；漏解析的内容无法被检索	读当前可见文件，免去该索引的刷新等待；但可能读的是旧分支、旧副本或不完整挂载
多跳证据	固定单轮召回容易漏掉后续线索；也可设计多轮检索或 Agentic RAG	可沿“配置→实现→调用处→测试”追查，灵活性取决于工具与规划能力
延迟与维护	前期处理可复用，固定链路便于观测；需维护索引、解析和版本	无须先建语义索引，但多轮搜索与阅读的耗时波动较大，需控制探索轮数

代码搜索还要区分“找到了文本”与“证明了调用关系”。同名函数、别名和动态分派不能只靠一次 grep 判定，必要时补充语言服务、静态分析或运行证据。扫描版 PDF、表格等也需要先解析，不能把原始二进制文件当成可直接搜索的正文。

一个可组合的处理过程

以“退款失败后在哪里重试”为例，用户未必知道代码里的名称。可以先通过语义或关键词索引定位支付模块，保留候选的文件路径、位置和版本；Agent 再读当前文件，找到具体错误码、重试任务名，继续搜索调用处、配置与测试。若第一批候选解释不了问题，应允许重新查询和扩大到其他相关目录。

若用户已经给出 RefundRetryJob，直接精确搜索通常就是很好的起点。若只有十篇短文档且任务要求整体比较，逐篇完整阅读也值得考虑；文件数量本身不足以决定是否需要索引。

两条路线都应返回可回查的证据位置，并检查结论是否覆盖必要条件。检索结果的相似度、工具调用轮数，都不能代替证据核对。

容易漏掉的范围与权限

ripgrep 在递归搜索时默认会跳过被忽略的路径、隐藏文件和二进制文件，也不跟随符号链接。没有命中时，应先核对目录、文件类型、忽略规则和工具是否截断输出；在授权范围内，按需使用 --hidden、--no-ignore 等选项，而非直接认定仓库中不存在相关实现。

权限必须由实际检索和读取接口执行：索引查询要限制当前身份可见的资料，读取原文、展开父段落和文件工具也要检查访问范围。.gitignore 是搜索与版本管理的过滤规则，不是权限边界。

追问

Claude Code 的做法是否说明代码仓库不需要 RAG？

Anthropic 的上下文工程文章展示了预加载 CLAUDE.md、再通过 glob、grep 按需探索的混合流程。这能说明一种有效的资料获取方式，不能据此断言所有版本永久不用索引，也不能把 RAG 限定为向量检索。

怎样验证选型，而不比较 Token？

用相同资料版本与任务集，覆盖精确符号、模糊问法、跨文件追踪和刚更新内容。比较任务正确率、关键证据覆盖、引用准确性、漏检原因、总延迟与维护负担；特别检查两个方案是否使用了相同权限和搜索范围。

对应教程

参考资料