AI

为什么 Claude Code 放弃了RAG? Agentic Search 又是个啥？

Posted Cola🌀

转载：小红书 AI产品赵哥

前言🔖

最近看到有一些文章提出了 “RAG 已死” 的观点

引爆这事的，是 Boris Cherny——Claude Code 的开发负责人。他在一次播客里扔了个炸弹：Claude Code 早就彻底抛弃 RAG 了，转向了另一种叫 Agentic Search 的方案。

Claude Code 是什么？它是 Anthropic 做的代码智能体，业界公认最厉害的那种。一个顶尖团队放弃全行业都在追的技术路线，这背后肯定有故事。

Boris Cherny 自己解释了原因。他说，Claude Code 早期确实是 RAG 的忠实用户。流程很简单：对整个代码库做向量化索引，用户提问时检索相关片段，拼进模板，喂给大模型。

听起来很完美对吧？但问题是，这套东西在真实场景里根本不好用。具体说，有三个根本性问题：

🔹第一，效果有上限。

在各种 Benchmark 上跑分可能还不错，但实际用起来，大家普遍觉得它不够聪明。代码逻辑生硬，上下文理解经常跑偏。换用 Agentic Search 之后，模型表现明显更像一个真正在思考的开发者的状态。这种感觉很难量化，但用过的人都能明确感知到差异。

　　

🔹第二，时效性跟不上。

RAG 需要预先建索引。这套对静态知识（比如一本百科全书）很合适，但代码库不一样 —— 它是活的。一个敏捷团队每天可能有几十上百次提交，代码版本迭代速度极快。RAG 索引更新的速度根本追不上代码变化的速度。你检索出来的信息可能早就过时了，基于过时信息给出的方案，轻则无效，重则引入新 bug。为了保持时效性而频繁重建索引？计算成本和工程复杂度都是无底洞。

　　

🔹第三，安全风险。

代码是企业最核心的资产之一。做 RAG 就要把全部代码做成索引，这个索引本质上是一张详细的代码知识地图。一旦泄露，不只是源代码，连整个代码库的结构、依赖关系、潜在漏洞、商业逻辑都暴露了。这就好像告诉小偷：你家藏宝贝在这里，机关是这个 —— 还附上了破解教程。

这三点，是 Claude Code 最终放弃 RAG 的核心原因。那 Agentic Search 是什么？它凭什么能解决这些问题？

　　

一、什么是 Agentic Search🔖

Agentic Search，从字面翻译是 “智能体式搜索”。这个名字听起来颇具未来感，但其核心实现方式却异常的返璞归真，它是在模仿一个经验丰富的程序员最原始的工作方式。

Agentic Search 的本质，是授予 AI 模型（即智能体 Agent）一种自主能动性，让它不再被动地接收我们投喂的检索结果，而是主动地、有策略地去它认为需要的地方搜集信息。AI 不再是等着被投喂的秀才，而是知道去哪本书的哪个抽屉里翻答案的侦探。

具体怎么做到的呢？它靠的是两个最古老的命令行工具：

Glob：这个 Linux 下的命令用来按通配符匹配文件名和路径。比如 AI 想找项目里所有 Python 文件，执行 glob **/*.py 就能瞬间列出来。程序员找文件时用文件管理器按类型筛选，操作逻辑是一样的。
Grep：同样来自 Linux，在文本文件里按字符串或正则表达式做全文检索。比如 AI 怀疑某个函数有问题但不知道在哪定义，执行 grep -r "def process_payment" 就能在整个项目里找到包含这段内容的文件和行。这跟程序员在 IDE 里按 Ctrl+Shift+F 做全局搜索是一回事。

当我们在使用 Claude Code 的 Web 界面时，看到的那些 Read(run_simulation.py) 或 Search("class DataLoader") 的步骤，底层跑的就是这一套 Glob 加 Grep 的组合。

让我们来构建一个更具体的场景，感受一下 Agentic Search 的工作流程：

任务：“请修复在 main.py 文件中，调用 UserData 类时出现的 TypeError 错误。

一个基于 Agentic Search 的 AI 智能体大概是这样思考和行动的：

  1. 【初步分析 & 计划】 “好的，任务是修复 main.py 的 TypeError，和 UserData 类有关。我首先需要阅读 main.py 来理解当前的调用方式。”
  2. 【执行动作 1：读取文件】 底层执行 Read(main.py)。
  3. 【观察 & 更新计划】 AI 读取了文件内容，发现错误发生在 user = UserData(id) 这一行。它推断，问题很可能出在 UserData 类的构造函数 __init__ 上。但 UserData 类并不在 main.py 文件中。于是，它制定了新计划：“我需要找到 UserData 类的定义。”
  4. 【执行动作 2：全局搜索】 底层执行 grep -r "class UserData"。
  5. 【观察 & 更新计划】grep 命令返回结果，显示 UserData 类定义在 models/user.py 文件的第 15 行。AI 现在知道了定义的位置。它的新计划是：“阅读 models/user.py 文件，检查构造函数。”
  6. 【执行动作 3：读取文件】 底层执行 Read(models/user.py)。
  7. 【观察 & 最终方案】 AI 读取了 models/user.py，发现 UserData 的构造函数是 def __init__(self, id, name):，需要两个参数 id 和 name，而 main.py 中只传了一个 id。问题定位！AI 最终的解决方案是：修改 main.py 中的调用，或者为 name 参数在构造函数中提供一个默认值。

这个过程，你是不是挺熟悉？这不就是我们人类程序员解决问题的标准流程吗？Agentic Search 的精髓，就在于这种 “分析→计划→行动→观察→再计划→再行动” 的循环（ReAct 框架的体现），它将一个复杂的大任务，分解成了若干个由简单工具即可完成的子任务。这种方式赋予了 AI 极大的灵活性和强大的推理能力，因为它每一步的行动都是基于上一步观察结果的实时决策，而不是一次性地从一个可能已经过时的数据库里捞取信息。

　　

二、Coding Agent 的路线之争🔖

Claude Code 这次转向，撕开了代码智能体赛道的一道口子 —— 原来大家走的根本不是同一条路。这场竞赛早就不是比谁模型大、谁参数多了，而是回到了最根本的问题：怎么让 AI 真正搞懂代码、操作代码。

目前三股势力已经成型：

🔹第一组：彻底革命派（完全抛弃 RAG，拥抱实时搜索）

  • 代表玩家：Claude Code、Dev-GPT(Cline)
  • 核心理念：这派认为 RAG 在代码场景下从根上就错了。代码的动态性、上下文的复杂性、安全的高要求，哪个都不是打补丁能解决的。他们的主张就四个字：推倒重来。回到第一性原理，模拟人类开发者真实的工作方式。
  • 特点：彻底放弃预建索引，全程实时搜索。AI 每次获取信息都是主动行为。好处很明显 —— 信息永远是新的，也没有索引存储和泄露的风险。坏处也一样明显：每次查询耗时会更长，多轮搜索里消耗的 Token 更多。Boris Cherny 自己说了，这是以时间换智能的交易。

　　

🔹第二组：智能索引派（基于图结构，重新定义索引）

  • 代表玩家： Aider
  • 核心理念： 这派是温和改良派。他们不怪索引本身，而是觉得问题在于怎么索引。传统向量化索引把代码当无结构的文本处理，丢掉了最重要的语义。
  • 特点： Aider 的解法很巧妙，用 AST 解析代码，保留完整的语法结构，然后把整个代码库建成一张图。文件、类、函数都是节点，它们之间的调用、继承、依赖关系是边。检索时不是做模糊的向量相似度匹配，而是在这张关系图上推理游走。他们还自研了排序算法，能评估一个函数修改后最可能影响哪些其他函数。

比纯文本 RAG 更懂代码，比 Agentic Search 响应更快 —— 毕竟还是在索引的。但工程复杂度和语言适配成本也更高。

　　

🔹第三组：混合增强派（RAG 不死，用高阶技术武装它）

  • 代表玩家： Cursor、Windsurf
  • 核心理念： 这派最务实。他们觉得 RAG 的基本思路没错，只是现有技术还不够成熟。与其抛弃它，不如给它装上各种新武器。
  • 特点：
    • Cursor： Cursor 用了最先进的 Embedding 模型，搭配 TurboPuffer 这种专向量化搜索优化的库。更激进的是他们在实验 DSI —— 让索引本身变得可学习、可训练，用 AI 来优化 AI。云端分布式架构也为处理海量代码库提供了可能。DSI —— 让索引本身变得可学习、可训练，用 AI 来优化 AI。云端分布式架构也为处理海量代码库提供了可能。
    • Windsurf: Windsurf 面向企业级部署，改造更系统。M-Query 技术让 AI 针对一个问题自动生成多个角度的查询，多路出击拿更全的上下文。本地加远程混合索引，兼顾性能和隐私。Cascade 代理系统说明整个架构可以调度多种工具，RAG 只是其中之一。

三条路没有绝对的优劣。实时性、智能度、工程成本，三个维度各有取舍。这场争论到最后，又把我们带回了那个最根本的问题：RAG 到底是什么，它适合什么场景。

　　

三、RAG 的本质：空间换时间🔖

要理解 RAG 在代码场景下为什么不好用，得先搞清它的底层逻辑。

RAG 本质上是 “以空间换时间“。这套思路在计算机领域非常常见。

  • 比如 MySQL。你为了加速查询，会给常用字段建 B+ 树索引。这索引占用额外硬盘空间，每次 INSERT 或 UPDATE 都要维护，拖慢写入。但换来的是查询速度从全表扫描级别提升到毫秒级。
  • 再比如 Elasticsearch。它做全文搜索前，会先把所有文档分词，建一张倒排索引表，记录每个词出现在哪些文档里。搜索 “苹果” 时，不用遍历所有文档，直接查表就知道文档 1、2、3 包含这个词。倒排索引可能比原始文档还大，但换来了闪电般的检索速度。
词项（Term）出现在哪些文档中（Doc IDs）
我[1]
喜欢[1]
吃[1]
苹果[1, 2, 3]

　　

这个索引表记录了每个词项出现在了哪些文档中。当你搜索 “苹果” 时，ES 不必遍历所有文档，只需直接查找这个表，瞬间就知道文档 1、2、3 包含了这个词。这个倒排索引本身，可能比原始文档还要大，但它换来的是闪电般的检索速度。

RAG 干的也是这事。它提前把代码和文档算成向量存起来，这就是它的 “索引”。过程耗时间耗空间，但请求来的时候，一次向量运算就能迅速召回相关内容。

问题是，这套逻辑在代码场景下暴露了几个软肋：

  1. 第一，依赖预建资料库。 没有被索引的东西，RAG 查不到。
  2. 第二，占用额外存储空间。 数据量大的时候，这笔开销不小。
  3. 第三，最要命的 —— 不适合高频变更的场景。 每次代码变动，索引就得更新，否则数据就不一致了。一旦变更频率高到某个程度，维护索引的成本和延迟就成了无底洞。

偏偏高频动态变更，就是代码库的常态。

　　

四、场景为王🔖

所以，RAG 真的死了吗？

没有。更准确的说法是，神化 RAG 的时代已经结束，我们进入了一个需要根据场景，审慎选择技术架构的理性时代。RAG 和 Agentic Search 不是非此即彼的关系。它们各有所长，适合不同的需求。

  • 对于静态知识、问答类场景，RAG 依然是王道。比如，一个基于公司规章制度的问答机器人，或者一个基于产品说明书的技术支持助手。在这些场景下，知识主体长期固化不变，用户的核心需求是 “快” 和 “准”。RAG “预计算” 的优势能被最大化发挥，为用户提供低延迟、高质量的回答。
  • 对于高频动态、需要探索和推理的场景，Agentic Search 则展现出巨大的潜力。代码编辑与分析、实时市场情报分析、科学研究中的文献关联发现…… 在这些领域，信息的实时性和任务的开放性是第一位的。Agentic Search “即时探索” 的模式，虽然牺牲了部分响应速度，但换来了更高的智能上限和对动态环境的完美适应。
  • 静态知识、问答类的场景，RAG 还是首选。 公司规章制度问答、产品说明书技术支持。在这些场景下，知识主体长期固化不变，用户要的就是快和准。这种场景下 RAG 预计算的优势能最大化发挥。
  • 高频动态、需要探索推理的场景，Agentic Search 更合适。 代码编辑分析、实时市场情报、科研文献关联发现，信息实时性和任务开放性是第一位的。响应速度可能慢一点，但换来了更高的智能上限和对动态环境的适应能力。

我们可以用一张表格来清晰地对比二者的特性：

特征RAG (检索增强生成)Agentic Search (智能体式搜索)
核心架构检索 + 生成推理 + 多轮搜索
智能水平相对较弱，依赖检索质量潜力更强，AI 可主动规划和探索
成本前期索引成本高，单次查询成本低前期无成本，单次查询（尤其多轮）成本高（Token 消耗、耗时）
实时性弱，依赖索引更新周期强，所有信息均为实时获取
可控性强，检索范围和内容相对确定弱，AI 的探索路径有一定不可预测性
最佳用途静态知识问答，如客服、文档查询动态探索与分析任务，如代码编程、研究

　　

更有趣的是，在一个完整的 AI 智能体架构里，RAG 和 Agentic Search 完全可以共存。一个复杂智能体的记忆系统可以分为不同层次：

  1. 内置记忆：模型本身的权重，通过预训练学到的世界知识。
  2. 短期记忆：有限的上下文窗口，记录了当前的对话历史。
  3. 中长记忆：利用草稿纸或外部数据库，记录和总结历史会话的关键信息。
  4. 外部记忆：庞大的、可供查询的外部知识源。

智能体在执行任务时，自己判断该用哪个工具：

  • 静态的、结构化的信息：就查 RAG；
  • 动态的、需要深挖的信息：就用 Glob、Grep 这套 Agentic Search。