1. 从一条热搜说起：为什么“抛弃 RAG”这件事值得聊
Claude Code 把 RAG 从主链路里拿掉，换成 agentic search，这个动作在圈子里炸出来的水花比想象中大。很多人第一反应是“RAG 效果不行了”，但真正在一线搭过知识库、调过召回率、半夜被索引重建告警叫醒的人，看到这个决定的第一反应往往是另一句话：终于有人把这件事挑明了。
我自己做过好几个 RAG 项目，从最早的 LangChain 拼装式 demo，到后来上 Chroma、上 pgvector、上 Milvus，再到给客户做私有化知识库。踩过的坑包括但不限于：文档切分粒度调了十几版、embedding 模型换了四五轮、rerank 加了又删、召回率从 60% 磨到 85% 之后再也上不去。最后发现真正拖垮项目的不是模型效果，而是那套索引体系本身的运维成本。
这篇东西不打算写成一篇“RAG 已死”的爽文，那种标题看着解气，但对实际干活没帮助。我想做的是把 Claude Code 这个决策背后的工程逻辑拆开，讲清楚三件事：RAG 的运维负担到底重在哪、agentic search 是怎么绕开这些负担的、以及如果你手上正有一个 RAG 项目，该怎么判断自己该不该跟这个方向。
适合读这篇的人：正在做或准备做 RAG 知识库的工程师、被向量数据库运维折磨过的后端、想搞清楚 agentic search 和传统 RAG 区别的技术负责人，以及那些看到“Claude Code 抛弃 RAG”这个标题但没搞明白到底发生了什么的同学。全文会涉及向量数据库、索引、agentic search、召回率这些关键词，但我会尽量用大白话讲，不堆术语。
先说结论，免得有人看到一半才发现方向不对：Claude Code 不是认为 RAG 没价值，而是认为在“代码搜索”这个具体场景下，维护一套向量索引的收益，抵不过它带来的工程复杂度和运维风险。这是一个场景化的取舍，不是普适的技术判决。
2. RAG 的真实运维账本：效果之外的隐形成本
2.1 索引不是建一次就完事的东西
很多人对 RAG 的想象是这样的：把文档丢进去、切块、embedding、存进向量库，然后查询的时候算相似度、召回、塞给模型。听起来是一条干净的流水线。但真实项目里，这条流水线是一条需要持续供血的活体系统。
索引会过期。代码库每天在变，文档每周在更新，知识库里的内容每个月都在增删。每一次变更都意味着：重新切分、重新 embedding、重新写入向量库、重建索引。如果用的是 HNSW 这类近似最近邻索引，插入和删除还会影响图结构，时间长了召回质量会漂移，你得定期做全量重建。全量重建意味着什么？意味着你要把整个语料重新过一遍 embedding 模型，这可能是几小时到几十小时的计算，还要考虑重建期间查询怎么办、新旧索引怎么切换、切换失败怎么回滚。
我做过一个中等规模的知识库，大概 50 万条 chunk，用某云厂商的 embedding API，一次全量重建的成本是几千块人民币加六个小时。这还只是钱和时间，真正要命的是你得为这个重建过程写一套调度、监控、回滚的工程代码。这套代码的复杂度，往往超过 RAG 本身的核心逻辑。
2.2 向量数据库是一个需要专人伺候的组件
选向量库这件事本身就是一道送命题。Chroma 上手快，但生产环境的稳定性、并发能力、持久化都让人心里没底。pgvector 好处是能复用现有的 Postgres 运维体系，但索引类型、参数调优、内存占用都是新的知识负担。Milvus、Qdrant、Weaviate 这些专业向量库功能强，但你得为它单独部署、单独监控、单独扩容、单独做备份恢复。
这里有个很现实的对比：一个 MySQL 实例，团队里随便抓个人都能维护，慢查询有 explain、索引有 show index、备份有 mysqldump，整套工具链成熟到不能再成熟。但一个向量数据库，出问题的时候你连“为什么这条查询召回不到”都很难排查。相似度分数是一个黑盒数字，你没法像看 B+ 树索引那样直观地理解它为什么命中、为什么没命中。
提示：如果你正在选向量库，先问自己一个问题——团队里有没有人能独立处理这个库的故障？如果没有，选型时就要把“运维可承接性”放在“功能强大”前面。
2.3 召回率的天花板与调参的无底洞
RAG 的效果瓶颈，做过的人都知道，卡在召回。你切分粒度大了，一个 chunk 里混了好几个主题，embedding 表达不纯；切分粒度小了，上下文丢失，模型拿到碎片拼不出完整语义。你调 top-k，调大了噪声多，调小了漏召回。你加 rerank，效果好一点，但延迟上去了，成本也上去了。
更麻烦的是，召回率这个指标本身很难量化。你没有一个像单元测试那样的东西能告诉你“这次改动让召回变好了还是变坏了”。你只能靠人工标注一批 query-doc 对，然后跑评估。这批标注数据本身就要花人力维护，而且随着语料变化会逐渐失效。
我见过太多团队在这个循环里耗掉几个月：调切分、换模型、加 rerank、改 prompt，召回率从 70% 磨到 82%，然后卡住。剩下的 18% 不是靠调参能解决的，它需要的是对查询意图的更深理解，而传统 RAG 的单轮检索范式给不了这个。
2.4 一个被忽视的成本：索引与业务逻辑的耦合
还有一层成本很少被拿出来说，就是索引结构和业务逻辑的耦合。比如你给代码库做 RAG，代码有函数、类、模块的层级结构，但向量检索是扁平的，它不知道“这个函数属于哪个类”这种结构信息。你要么在 chunk 里塞元数据，要么在检索后做二次过滤，要么上 GraphRAG 那种图结构。每一种方案都增加复杂度。
热词里有个“双向索引”“sql 复合索引”“主键索引”，这些传统数据库索引概念之所以反复被提起，恰恰说明大家在用向量库的时候，潜意识里在拿它和成熟的关系型索引做对比。而对比的结果往往是：向量索引在“可解释性”和“可控性”上，差了传统索引一个量级。
3. Agentic Search 到底换掉了什么
3.1 从“一次检索”到“多轮探索”
传统 RAG 的检索是一次性的：query 进来，算相似度，取 top-k，结束。Agentic search 换了一个思路：把检索变成一个 agent 可以反复调用的工具，agent 根据当前掌握的信息决定下一步查什么、怎么查、查到什么程度算够。
这个区别听起来抽象，举个例子就清楚了。假设你问“这个项目的鉴权逻辑在哪”。传统 RAG 会把这句话 embedding，然后去向量库里找语义最接近的 chunk。它可能召回一堆提到“auth”“token”“permission”的代码片段，但未必能定位到真正的入口。Agentic search 的做法是：agent 先搜“auth”，看到几个文件名，判断哪个最相关，然后打开那个文件读内容，发现里面调用了另一个模块，再顺着去搜那个模块，一层层追下去，直到找到真正的鉴权入口。
这本质上是用“多轮工具调用”替代了“单轮向量召回”。它不依赖 embedding 把语义压缩成一个向量，而是依赖 agent 的推理能力在真实语料里导航。
3.2 为什么这个方案在代码场景特别成立
代码搜索有一个天然优势：代码本身是高度结构化的，而且有精确的字符串可以匹配。函数名、变量名、import 路径，这些都是精确 token，用 grep 就能找到，根本不需要 embedding 去猜语义相似度。
传统 RAG 在代码场景的尴尬在于：它把精确匹配问题当成了语义相似度问题。你搜getUserById，embedding 可能给你召回fetchUser、findUser、queryUser一堆语义相近但名字不同的函数，反而把真正精确匹配的那个淹没了。而 agentic search 可以直接用 grep 精确匹配，再用 agent 的推理去判断上下文。
这就是为什么 Claude Code 敢抛弃 RAG：在代码这个场景里，精确检索加 agent 推理的组合，比向量召回更准、更可控，而且不需要维护索引。
3.3 运维负担的消失是结构性的
Agentic search 最狠的地方不是效果，而是它把整个索引层干掉了。没有 embedding 模型要部署，没有向量库要维护，没有索引要重建，没有召回率要调。Agent 直接在原始语料上操作，用文件系统、grep、read 这些最基础的工具。
这意味着什么？意味着系统的状态空间小了一个量级。传统 RAG 系统里，索引是一个独立的状态，它和原始语料之间可能不一致，需要同步机制。Agentic search 里，语料就是唯一的状态，agent 每次读的都是最新的。没有同步问题，没有一致性问题，没有索引漂移问题。
从运维角度看，这是降维打击。你不需要为检索单独准备一套基础设施，不需要为它写监控告警，不需要为它做容量规划。检索变成了 agent 的一个普通工具调用，和读文件、执行命令没有本质区别。
3.4 代价是什么：延迟与成本
当然，agentic search 不是没有代价。多轮工具调用意味着更多的模型调用次数，延迟比单次向量检索高。传统 RAG 一次检索可能几百毫秒，agentic search 可能要几秒甚至几十秒，因为它要读文件、要推理、要决定下一步。
成本也更高。每次工具调用都是一次模型推理，token 消耗比单次检索大。但这个账要这么算：传统 RAG 省下的推理成本，是不是被索引运维成本吃掉了？如果索引运维需要专人、需要额外基础设施、需要持续调参，那省下的推理成本可能还不够付运维的工资。
Claude Code 的判断显然是：在代码场景下，agentic search 多花的推理成本，小于 RAG 省下的推理成本减去索引运维成本。这个不等式成不成立，取决于场景，不取决于技术优劣。
4. 如果你手上有个 RAG 项目，该怎么判断跟不跟
4.1 先看你的语料是不是“精确可搜”
判断标准很简单：你的语料里，用户查询的目标是不是能用精确字符串或结构化条件定位？如果是代码、日志、配置文件、结构化文档，那 agentic search 的精确匹配优势很大。如果是散文、论文、客服对话这种语义模糊、没有精确 token 的语料，向量召回的价值就还在。
我自己的经验是：代码和结构化数据，agentic search 明显更优；自然语言长文本，RAG 仍然有优势，因为 agent 很难靠 grep 在散文里找到语义相关段落。
4.2 再看你的团队能不能扛住索引运维
这个问题很现实。如果你的团队有专门的搜索/检索工程师，有成熟的向量库运维经验，那 RAG 的运维成本是可控的。但如果你的团队是几个后端兼职做知识库，那索引运维会变成一个持续消耗精力的黑洞。
我见过一个团队，三个人维护一个 RAG 知识库，其中一个人 60% 的时间花在索引重建和召回调优上。这种投入产出比，在业务压力大的时候是很难持续的。
4.3 混合方案：不是非此即彼
抛弃 RAG 不等于完全不用向量检索。更务实的做法是混合：agentic search 作为主链路，向量检索作为补充工具。Agent 在需要语义模糊匹配的时候调用向量检索，在需要精确匹配的时候用 grep。这样既保留了向量检索的能力，又不用把它作为唯一依赖。
热词里有个“agentic rag”，说的就是这个方向。RAG 从主链路降级为 agent 的一个工具，而不是整个系统的架构核心。这个降级本身，就大幅降低了运维负担，因为向量库不再是关键路径，它挂了系统还能跑，只是某些查询效果差一点。
4.4 一个可操作的迁移路径
如果你决定往 agentic search 方向走，我建议的路径是：
- 先保留现有 RAG 系统不动，在旁边搭一个 agentic search 的原型，用同一批 query 做对比测试。
- 重点对比精确匹配类查询的命中率，这类查询是 agentic search 的主场。
- 如果精确匹配类查询占比高，逐步把主链路切到 agentic search，向量检索降级为 fallback。
- 观察一段时间，如果向量检索的调用频率很低，就可以考虑下线向量库，彻底去掉索引运维。
这个路径的好处是风险可控，不会一上来就把现有系统推翻。
5. 实操中容易踩的坑与排查经验
5.1 Agent 工具调用的死循环
Agentic search 最常见的问题是 agent 在工具调用里绕圈。它搜一个词，没找到，换个词再搜，还没找到，再换，最后陷入死循环或者反复读同一个文件。这个问题的根源通常是 agent 没有明确的“停止条件”和“进展判断”。
我的做法是给 agent 设一个工具调用预算，比如最多 15 次调用，超过就强制它基于现有信息给答案。同时在 prompt 里明确告诉它：如果连续两次搜索没有获得新信息，就换策略或者直接回答。实测下来，这个约束能挡掉大部分死循环。
5.2 精确匹配的边界问题
Grep 精确匹配听起来简单，但边界情况很多。比如搜user，会匹配到username、user_id、superuser一堆。搜函数名的时候，如果语言有命名空间或类前缀，精确匹配可能漏掉。这些都需要在工具层面做处理，比如支持正则、支持词边界、支持大小写敏感选项。
注意：不要指望 agent 自己处理好这些边界。工具本身的匹配能力决定了 agent 的上限，工具做得糙，agent 再聪明也白搭。
5.3 大文件读取的 token 爆炸
Agent 读文件的时候，如果文件很大，一次读进来会消耗大量 token。我踩过的坑是 agent 读了一个几千行的文件，直接把上下文撑爆，后面的推理质量断崖式下跌。解决办法是给读文件工具加行数限制，或者让 agent 先看文件结构再决定读哪一段。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 处理建议 |
|---|---|---|---|
| Agent 反复搜同一个词 | 停止条件缺失 | 看工具调用日志 | 加调用预算和进展判断 |
| 精确匹配漏召回 | 匹配规则太严 | 检查匹配模式 | 支持正则和词边界 |
| 上下文被撑爆 | 大文件整读 | 看单次读取 token 量 | 加行数限制或分段读 |
| 多轮调用延迟高 | 调用次数过多 | 统计平均调用轮数 | 优化 prompt 减少无效调用 |
| 结果不稳定 | 工具返回格式不一致 | 检查工具输出结构 | 统一工具返回格式 |
5.5 一个容易被忽略的点：工具描述的质量
Agent 能不能用好工具，很大程度上取决于工具描述写得好不好。工具描述就是 agent 的“使用说明书”，写得含糊，agent 就会乱用。我见过一个团队的工具描述只写了一句“搜索文件”，结果 agent 完全不知道该传什么参数、什么时候该用。后来把描述改成“在代码库中按关键词搜索文件内容，返回匹配的文件路径和行号，适合定位具体函数或变量”，agent 的使用准确率明显提升。
6. 我个人的一些判断和体会
Claude Code 这个决策，我认为最有价值的地方不是它证明了 agentic search 比 RAG 好，而是它把一个长期被回避的问题摆到了台面上：技术选型不能只看效果上限，还要看运维下限。RAG 的效果上限可能更高，但它的运维下限也更低，低到很多团队根本撑不住。
我自己现在的做法是：新项目默认从 agentic search 起步，只有在明确需要语义模糊匹配的场景才引入向量检索，而且一定把它放在非关键路径上。这个策略让我少维护了一套索引体系，省下来的精力放在 agent 的推理质量和工具设计上，整体效果反而更好。
最后分享一个实操小技巧：如果你在评估 agentic search 和 RAG 的取舍，不要只看平均效果，要看“最差情况”。RAG 的最差情况往往是召回完全失败，返回一堆无关内容，而且你很难解释为什么。Agentic search 的最差情况通常是多绕几轮然后给出一个不完美的答案，但至少过程是可追溯的。在需要可解释性和可调试性的场景里，这个差异比平均效果更重要。
