文章拆解为什么 2026 年的 AI Agent 搜索栈正在逐步抛弃传统向量检索，转向更动态的 agentic search 工作流。

2025 年 5 月，Anthropic 做了一件本应引起更大关注的事：他们把 Claude Code 里的向量搜索移除了。嵌入流水线、本地向量数据库、分块启发式规则，全都没了；取而代之的是grep。据 Claude Code 的作者 Boris Cherny 介绍，结果是：“效果超过了其他所有方案，而且优势很大。”一年之后，问题已经不再是 AI agent 是否需要向量数据库，而是当初为什么会有人认为它们是必需的。

Cursor 把推动这一决策的工程师招了过去；Windsurf、Cline、Devin 和 Sourcegraph Amp 也都放弃了向量检索，转向基于工具驱动的搜索。Anthropic 自家的多 agent 研究系统也建立在同样的思路上，在内部评测中相较单个 Claude Opus 4 提升了 90.2%。Amazon Science 在 AAAI 2026 发表的一篇论文显示，agentic keyword search 在完全不使用向量库的情况下，达到了94.5% 的 RAG faithfulness。Search-R1 则通过强化学习训练检索策略，在表现上相对 RAG 提升了 24%。向量数据库并没有消失，但它已经从默认选项降级成了兜底方案。

Agent 搜索栈正在替代 RAG

在 2025 年 5 月的 Latent Space 播客中，Claude Code 的作者 Boris Cherny 说了一段后来悄然动摇 RAG 共识的话[1]：

“Claude Code 的早期版本使用的是 RAG + 本地向量数据库，但我们很快发现，agentic search 通常效果更好。而且它更简单，也不会遇到同样的安全、隐私、数据陈旧和可靠性问题。”

在同一次对话里，他后来又补充说：

“它超过了其他所有方案。优势非常明显，这一点当时也让我们很意外。”

如果放在 2024 年，这样的表述可能只会是个脚注；但到了 2026 年，它已经成了一个标志性案例：前沿代码 AI 行业几乎整体复制了这次架构转向，而 Anthropic 也随后把这种做法正式总结为一种命名模式。

在 2025 年 9 月发布的工程文章“Effective context engineering for AI agents,”[2] 中，Anthropic 给这套方法起了名字：just-in-time context loading。核心思想是：“与其预处理所有相关数据，不如让 agent 维护轻量级标识符（文件路径、保存的查询、网页链接等），并在运行时通过工具根据这些引用动态把数据加载进上下文。” 也就是说，不再依赖预先构建好的 embeddings，而是由 agent 按需检索；这更像人类阅读代码库的方式，而不是搜索引擎建立索引的方式。

到了 2026 年，这种模式已经无处不在。Claude Code、Cursor、Windsurf（以及 Cognition 收购后纳入的 Devin）、Cline、Sourcegraph Amp，以及越来越多的 agentic 系统，都不再把目标语料预先索引进向量数据库。相反，它们把检索暴露为一组工具，由 LLM 自行决定调用什么、何时调用、调用多少次。如今，这种模式已经有了多个名称：agent-as-retriever、agentic search、vectorless RAG、just-in-time context loading，或者更直白地说，tool-use retrieval。

这并不是一种“凭感觉流行起来”的趋势，它是可以量化验证的：

• Anthropic 的官方指导现在明确建议开发者：“先从 agentic search 开始，只有在确实需要时再加入 semantic search” [2] [3]。
• Anthropic 自家的多 agent 研究系统（Opus 4 负责主控，Sonnet 4 作为 subagents，全部使用 agentic search）在内部研究评测中，相比单 agent 的 Claude Opus 4 提升了 90.2%；在复杂查询上，研究时间最多可缩短 90%，代价约是 token 消耗增加 15× [4]。
• Amazon Science 发表了论文 “Keyword search is all you need”（AAAI 2026，arXiv:2602.23368），结果表明仅使用rga和pdfgrep的 tool-use agents，就能达到 RAG 的 94.5% faithfulness、88.0% context recall，以及 91.5% answer correctness [5]。
• Search-R1（arXiv:2503.09516）直接用强化学习训练检索策略本身，在 7 个数据集平均结果上（Qwen2.5–7B）相对 RAG 提升了 24% [6]。
• 2025 年 7 月，Cursor 直接从 Anthropic 挖走了 Boris Cherny 和 Cat Wu——他们正是 Claude Code agentic search 的核心负责人 [7]。
• Windsurf 推出了 SWE-grep，这是一种专用检索模型，在上下文检索速度上比通用 agentic search 快 10× [8]。
• Chroma 发布了 Context-1，这是一个 20B 的 agentic-search 模型；在检索任务上，它的推理速度约快 10×，成本约比前沿模型低 25× [9]。

本文将拆解 2026 年的 agent-as-retriever 模式：包括 just-in-time loading 范式、相关架构实现（Claude Code、Cline、Probe、Search-R1）、支撑这些架构的基准结果，以及如何把这种模式与向量、图结构和长上下文结合，纳入一套真实可用的技术栈中。

2. 背景：为什么 Vector RAG 先在代码场景失效，随后又扩展到更多领域

要理解这场转变，先看最初的基线。作为真实 GitHub issue 经典基准的 SWE-bench，于 2023 年 10 月发布时采用了一个非常简单的 RAG baseline：将代码库切块、做 embedding、检索 top-k，然后生成补丁。它的得分只有1.96%[10]。第一个 agent 系统 SWE-agent 用工具（open_file、scroll_down、edit_lines）替代检索后，成绩跃升到 12.47%。到了 2026 年，SWE-bench Verified 排行榜已基本被80%以上的 agentic 系统占据，而排名靠前的条目中，没有任何一个依赖对目标仓库做向量检索。

为什么 vector RAG 在代码场景下会失效得如此严重？

• 语义相似性不等于相关性。对“最相似 embedding”的追求，并不能很好地替代“改了这一行后，究竟哪个函数会出问题”的判断。代码拥有明确的结构关系，例如 imports、类型定义、调用图等，而扁平化的 embedding 会把这些关系抹平。
• 标识符本身就是搜索入口。当你问“processPayment定义在哪里？”时，你需要的是精确匹配。向量搜索却会引入误报（如handlePayment），也会造成漏报（真正的定义反而排在一段看起来相似的注释之后）。
• 索引永远落后于现实。代码是持续漂移的，每一次 commit 都会让索引的一部分失效。持续重建索引成本高昂，而且始终追不上代码变化，这和 GraphRAG 在 LazyGraphRAG 出现前面临的是同一类问题。
• 索引本身就是一种风险。专有代码的向量索引，本质上就是这份代码的一个副本，存放在另一套基础设施上，而且访问控制往往还不如源代码仓库严格。
• 单次检索非常脆弱。top-k 只有一次机会；只要错过正确文件一次，模型就可能信心十足地生成错误代码。

Amazon Science 的论文将这一问题推广到了代码之外，在包括FinanceBench、BlockchainSolana、Llama2Paper和HistoryOfAlexnet在内的六个数据集上进行了测试。在 FinanceBench 上，agentic 的关键词搜索方法在答案正确性上实际上比传统 RAG高出 6 个百分点（30.40% vs 24.24%）[5]。这说明，“切块 + embedding”的失效模式并不是代码独有的问题，而具有普遍性。

3. Anthropic 的选择：用 grep 替代 RAG 的四个原因

Cherny 和 Cat Wu 对他们为何从 Claude Code 中移除向量搜索，给出了少见的直白解释。结合播客[1]和后续采访，理由可以归结为四点：

3.1 准确性（最出人意料的一点）

团队原本预计 agentic search 会比 RAG更差，并且已经准备好为了运维上的简化而接受一定的质量损失。结果恰恰相反：它表现更好。Cherny 的原话是：“It outperformed everything. By a lot, and this was surprising.”其机制在于：由 LLM 驱动的grep可以迭代式地细化查询、查看相邻文件、跟踪 imports，并自行纠错；而一次性的 embedding lookup 做不到这些。

3.2 时效性

直接读取文件系统的 agent 反映的是仓库的当前状态，不存在“索引延迟”。你改完一个文件，100ms 后再问 Claude Code，它读到的就是新的字节内容。向量索引则会一直陈旧，直到下一轮重新 embedding 完成。

3.3 安全与隐私

Cherny 的说法是：“There’s this whole indexing step that you have to do for RAG… there’s security issues because this index has to live somewhere… it’s just a lot of liability for a company to do that.”尤其是企业客户，并不希望自己的专有代码以另一份 embedding 副本的形式，存放在别人的基础设施中。

3.4 可靠性

组件越少，故障点越少。基于 grep 的 retriever 不会遇到 embedding model 漂移、vector DB 宕机、re-indexing pipeline 滞后，也不需要反复调 chunking 策略。ripgrep就是能用，find也是，cat也是。

Cat Wu 这样概括部署层面的收益：“Claude is really good at agentic search. You can get to the same accuracy level with agentic search and it’s just a much cleaner deployment story.”

4. Just-in-Time 上下文加载范式

Anthropic 的“Effective context engineering for AI agents”[2] 清晰地区分了两种检索哲学：

• 推理前检索（Pre-inference retrieval）。这是传统 RAG 的做法：预先为所有内容生成 embedding、存储向量、在查询时检索，再把 top-k 塞进 prompt。模型可能需要的内容，都必须提前预测并建立索引。
• Just-in-time 加载。Agent“维护轻量级标识符（如文件路径、保存的查询、网页链接等），并在运行时通过工具利用这些引用将数据动态加载进上下文。” 也就是说，不预先加载任何内容；agent 只在需要的时候获取需要的数据。

Anthropic 在文中明确指出，Claude Code 就是这一模式的典型例子：“CLAUDE.md files are naively dropped into context up front, while primitives like glob and grep allow it to navigate its environment and retrieve files just-in-time.”

更深一层的关键在于，它改变了上下文窗口的形状。在推理前的 RAG 中，你要先为那些你猜测可能相关的文本分块消耗 token；而在 just-in-time loading 中，token 只花在 agent判断为相关的内容上，其余一律跳过。Anthropic 对这一原则的表述是：“finding the smallest set of high-signal tokens that maximize the likelihood of desired outcomes.”

这也解释了为什么这种模式不只是扛住了“token 成本过高”的质疑，反而把这个批评倒转了过来。朴素的 agent 循环确实会比向量 RAG 消耗更多 token；但 just-in-time loading 一旦与 subagent 的上下文隔离结合（下文会展开），就有可能因为彻底避开低信号文本块，而比 RAG 消耗更少的 token。一个经常被引用的 Anthropic 内部数据是：Claude Code 的工具惰性加载机制——也就是只有在真正需要时才加载工具定义——能够将上下文占用降低约 95%[11]。

5. Agent-as-Retriever 架构详解

这种模式实际长什么样？在 Claude Code（以及更广义的 Claude Agent SDK）中，检索能力被暴露为一组规模很小、而且刻意设计得“朴素无奇”的工具[3][12]：

• Glob：文件路径模式匹配，token 成本几乎为零。
• Grep：基于ripgrep的正则内容搜索（从 v2.1.117，也就是 2026 年 4 月开始，在 macOS/Linux 原生构建中还会通过 Bash 调用内嵌的ugrep+bfs[13]）。
• Read：将文件全部或部分内容读入上下文。
• Bash：兜底 shell，用于覆盖长尾需求（tail、head、jq、git log、带谓词的find等）。
• Exploresubagent：一个派发出去的只读 agent（默认使用 Haiku 4.5），拥有独立的上下文窗口，用于并行探索代码库。

一项针对 Claude Code TypeScript 源码的逆向研究（arXiv:2604.14228[1]）记录了更完整的系统图景：内置工具共 54 个（其中 19 个始终启用，35 个按功能开关控制），而真正属于 AI 决策逻辑的代码只占整个代码库的 1.6%；其余 98.4% 都是运行基础设施、上下文管理、权限控制、工具分发与压缩整理[14]。决策层很小，检索与上下文管理层却极其庞大。

5.1 五层压缩管线

因为 just-in-time loading 最终仍然会把上下文窗口填满，所以当接近 200K token 上限时，Claude Code 会启动一条五层压缩管线[14]：

1. Budget reduction：优先丢弃相关性最低的内容。
2. Snip：删除冗余的工具调用输出。
3. Microcompact：对单条超长消息做摘要压缩。
4. Context collapse：把更早的多轮交互折叠为更短的回顾摘要。
5. Auto-compact：当再也塞不下时，执行最后一轮整体摘要压缩。

这是 just-in-time loading 必不可少的配套机制：当你已经做到“只加载真正需要的内容”之后，还必须能够优雅地忘掉“已经不再需要的内容”。Anthropic 将compaction描述为长时程上下文工程的第一杠杆：“taking a conversation nearing the context window limit, summarizing its contents, and reinitiating a new context window with the summary”[2]。

5.2 控制循环

plan -> glob/grep -> read candidates -> refine query -> repeat (or spawn subagent) -> compact -> answer

它的整体形态与 agentic RAG（Self-RAG、CRAG、A-RAG）是一样的，但有一个关键区别：agent 与底层字节数据之间不存在预先构建好的索引。这里的 “retriever”，就是 agent 当下选择调用的那个 shell 工具。

6. 证据：“Keyword Search Is All You Need”（Amazon，AAAI 2026）

在公开基准中，对 agent-as-retriever 与向量 RAG 做得最严格的一次对比，是 Subramanian 等人在 AAAI 2026 发表的“Keyword search is all you need: Achieving RAG-Level Performance Without Vector Databases Using Agentic Tool Use”[5]。实验使用完全相同的 LLM（Claude 3 Sonnet、200K context、temperature 0.001）、相同的 6 个数据集、相同的评测框架。

唯一的变量只有检索器：一边是使用 Titan Text Embeddings V2 的 Amazon Bedrock Knowledge Base，另一边则是一个 ReAct agent，调用pdfmetadata、rga和pdfgrep来完成检索。

所有数据集汇总后的核心结果如下：

• Faithfulness：agent 0.81，RAG 0.86 → 达成率 94.52%
• Context Recall：agent 0.68，RAG 0.77 → 达成率 88.05%
• Answer Correctness：agent 0.59，RAG 0.65 → 达成率 91.48%

而那些“异常点”反而揭示了更深层的规律。FinanceBench这类篇幅很长、表格密集的金融申报文件中，结果发生了反转：关键词搜索 agent 的answer correctness 达到 30.40%，反而高于 RAG 的24.24%。而BlockchainSolana这类对精确术语匹配要求极高的技术文档，达成率则冲到了99.97%。

论文的核心结论是：“Vector databases are not essential for high-quality retrieval performance. Agentic approaches using simple keyword search tools are a viable alternative for many applications.”

7. Search-R1：当检索策略不是靠提示词驱动，而是训练出来的

Amazon 的这篇论文表明：即便只是一个通过prompt驱动的 agent，只用关键词工具，也能达到与 RAG 相当的效果。Search-R1（Jin et al., arXiv:2503.09516）[6] 又向前迈了一步：直接用强化学习训练检索策略本身，结果不再只是“追平” RAG，而是超越了它。

其基本设定是：在一个 R1 风格的推理模型中，加入在推理过程中插入<search>query</search>调用的能力。模型通过基于结果的 RL（使用 veRL + RAGEN）学习三件事：什么时候该搜、该搜什么、以及什么时候信息已经足够。检索过程中的 token masking 则用于保持训练稳定。

在 7 个问答数据集（NQ、TriviaQA、PopQA、HotpotQA、2WikiMultiHopQA、Musique、Bamboogle）上，使用 Qwen2.5–7B-Base 得到的结果如下：

• Search-R1 平均 EM：0.431
• RAG 基线平均 EM：0.304
• SFT 平均：0.207 · 不带检索的 R1：0.276 · Rejection sampling：0.348
• 各数据集上的 Search-R1 分数：NQ 0.480、TriviaQA 0.638、PopQA 0.457、HotpotQA 0.433、2WikiMultiHopQA 0.382、Musique 0.196、Bamboogle 0.432

这意味着，对 Qwen2.5–7B 而言，Search-R1 相比 RAG 的平均相对提升达到 24%；对 3B 模型，提升则是 20%。此后，CoSearch 和 Agentic-RAG-R1 又把这些数字继续推高了（CoSearch 用 7B agent 达到平均 F1 0.568，相比 Search-R1 再提升 6.6%）[15]。

比基准成绩更重要的是它揭示出的架构意义：一旦检索被做成 tool call，它就变成了一种可学习的策略。也就是说，你可以用训练推理模型的同一套 RL 机制，把 agent 微调成更强的检索器；而对一个冻结的 embedding 模型，你做不到这一点。

8. 全景图：2026 年的 Agent-as-Retriever 五种形态

到了 2026 年，这一模式已经分化出至少五种清晰不同的架构路线，而且每一种都有自己的代表性产品。

8.1 Pure Agentic（Claude Code、Devin）

没有持久化索引。直接使用Glob、Grep、Read、Bash、Explore subagent。Devin（Cognition）走的也是同一条路。其核心判断是：面对一个每次 commit 都在变化的代码库，由 LLM 驱动、循环调用ripgrep的方式，会优于任何冻结的 embedding 模型。

8.2 Hybrid Lexical + Semantic（Cursor、Sourcegraph Amp）

Cursor 的文档明确并列描述了这两种模式[16]：精确符号查找用Instant Grep，概念性查询用 semantic search，再由 agent 根据查询类型决定选哪一种。Cursor 引用的内部研究结果是：将 semantic search 与 grep 结合，可带来 +12.5% 的准确率提升。Sourcegraph 的Amp（Cody 在 2025–2026 年间演进出的 agentic 版本）则是在 Sourcegraph 长期积累的代码图之上叠加了一个类似的 agent[17]。对于大多数企业级工具来说，混合路线正逐渐成为收敛方向。

8.3 Structural / AST-Aware（Cline、Probe、ast-grep）

纯 grep 是词法层面的。纯 embeddings 是语义层面的。除此之外，还有第三条路径：结构化搜索。像 ast-grep[2] 和 Probe[3] 这样的工具，会借助 tree-sitter 解析代码，让 agent 搜索的是语法模式，而不是字符串。

Cline 的开源方案[18] 是目前最清晰的生产级示例：一个三层检索栈。

• 第 1 层：基于 ripgrep 的内容搜索，并限制输出上限
• 第 2 层：通过 fzf 做文件/目录模糊搜索，并使用自定义评分
• 第 3 层：利用 tree-sitter 进行多语言 AST 提取，用于发现定义位置

agent 通过 plan-and-act 循环来编排这三层，并对当前已打开的文件赋予更高权重。Cline 论文报告称，该系统在保持结构化代码感知能力的同时，将每轮检索的 token 占用控制在约 17.5%，显著低于纯 agentic 基线。

Probe 也基于同样的思路，但将其封装成一个单独的二进制工具：“One Probe call captures what takes other tools 10+ agentic loops, deeper, cleaner, and far less noise.”[19] 它返回的是完整的函数、类或结构体，而不是那种在函数中途截断的文本块。更关键的是，它提出了一个很强的观点：embeddings 的存在，本质上是为了解决词汇不匹配问题，而这个问题已经可以由 LLM 驱动的 agent 自行处理。agent 会把用户意图转换成精确的布尔查询（AND、OR、+required、-excluded、"exact phrases"、ext:rs、lang:python），然后 Probe 在毫秒级返回完整的 AST 代码块。无需 embedding 模型，无需索引，也无需额外配置。

8.4 Specialized Retrieval Models（Windsurf SWE-grep、Chroma Context-1）

训练一个专门做检索代理的小模型。Windsurf 在 2026 年初发布的 Wave 13 中推出了SWE-grep和SWE-grep-mini，用于在 Cascade 内快速收集上下文[8]。它们的运行方式是：每一轮并行发起 8 次工具调用，连续执行 4 轮，因此在检索速度上达到比通用 Agent 搜索快 10×。Chroma 于 2026 年 3 月发布的Context-1是一个 20B 的 agentic-search 模型[9]，在相同的多跳任务上，其推理速度约为通用前沿模型的 10×，成本则降低约 25×。

8.5 通过 RL 训练的检索策略（Search-R1、CoSearch、Agentic-RAG-R1）

见上文第 7 节。Agent 通过强化学习学会“何时检索、检索什么”，在表现上相较基于 prompt 的 Agent 基线实现了两位数优势。这也是“Agent 作为检索器”为什么长期更优的最直接理论依据：它是一个可学习系统，而不是固定不变的流水线。

这五种形态共享同一个架构前提：由 Agent 接管检索。它们的差别只在于 Agent 所调用工具的后端是什么，以及这些工具是如何构建出来的。

9. 多 Agent 的乘数效应：Anthropic 自己给出的证明

最清晰、且不局限于编程场景的验证，来自 Anthropic 自家的工程团队。在他们的文章“How we built our multi-agent research system”[4] 中，团队介绍了 claude.ai 的 Research 功能所采用的 orchestrator-worker 架构：

• 一个 Lead Researcher（Claude Opus 4）负责分析查询、制定计划，并派生出 3–5 个子 Agent。
• 每个子 Agent（Claude Sonnet 4）都会并行运行各自的 agentic search 循环，并在每一轮调用 3 个以上工具。
• 子 Agent 只返回压缩后的发现结果；完整的工具调用轨迹会被隔离，不直接暴露。
• Lead 负责综合这些结果，并可视情况再发起新一轮子任务。
• Lead 会把计划持久化到 Memory 中，以便在 200K token 上下文限制下继续保留任务上下文。

最关键的结果是：在 Anthropic 内部研究评测中，这套多 Agent 系统比单 Agent 的 Claude Opus 4 高出 90.2%。并行工具调用在复杂查询上可将“研究时间最多缩短 90%”。代价是：token 消耗约为标准聊天的 15×。Anthropic 还明确指出，在大量依赖浏览的评测中，仅 token 用量这一项就能解释大约80% 的性能方差；也就是说，只要任务价值足以覆盖成本，向问题投入更多 agentic-search token，往往几乎能线性换来更好的答案。

同一篇文章也给出了一个重要限制：多 Agent 更适合广度优先任务（如研究型任务，或“从大量来源中找全某类信息”），而对于编程这类高度相互依赖的任务，效果则没那么理想，因为其核心瓶颈往往来自串行依赖。

10. 工具设计原则：这一切为何成立

“Agent 作为检索器”能否成立，很大程度上取决于工具设计。Anthropic 关于 context engineering 的文章[2]把原则说得很直接：

• 工具应当“自包含、具备错误鲁棒性，并且对其预期用途有极其清晰的界定”。
• 输入参数必须“描述性强、没有歧义，并能发挥模型的天然优势”。
• 避免臃肿且功能重叠的工具集。每个工具都应该只有一个清晰明确的用途。
• 最终检验标准是：“如果一个人类工程师都无法明确判断在某种情境下该用哪个工具，那就不能指望 AI Agent 做得更好。”

这也是为什么 Claude Code 的工具面如此精简。Glob 只做一件事，Grep 只做一件事，Read 只做一件事。其余操作都交给 Bash，并通过显式权限门控来约束。模型不需要在find_file_by_name、search_file_by_path和locate_file之间纠结该选哪一个。对于每一种问题形态，系统只提供一个对应工具。

11. MCP：标准化层

如果说“Agent 作为检索器”是一种模式，那么Model Context Protocol (MCP)就是把这种模式从 Claude Code 的特例，变成整个生态默认机制的协议层[20]。

MCP 由 Anthropic 于 2024 年 11 月推出，并在 2025–2026 年间被 IDE 和各类 AI 应用广泛采用。它本质上是一个 JSON-RPC 2.0 协议，使任何由 LLM 驱动的宿主（如 Claude Code、Cursor、VS Code、Claude Desktop）都能够连接到任意一个 “MCP server”——也就是向宿主暴露tools、resources和prompts的程序。

官方的 MCP filesystem server[4] 是“agent-as-retriever”在生产环境中的一个最清晰示例。它在明确的目录 allowlist 约束下，提供了一组经过筛选的工具接口：read_file、write_file、list_directory、search_files、get_file_info。至于具体调用哪个工具，由 agent 决定，而不是由协议决定。

这意味着：只要某种数据源在形态上“像文件系统”，任何支持 MCP 的 host 都可以把它当成一个 agent-as-retriever 系统来使用。Sentry 可以暴露 incidents，Postgres 可以暴露 tables，filesystem server 可以暴露代码仓库。对 agent 来说，它们的处理方式是一样的：发现、搜索、读取、细化。

一旦 retrieval 变成一次工具调用，那么任何数据源都可能成为 retriever，而不再需要有人专门为它构建向量索引。

12. 反方观点：什么时候 Agent-as-Retriever 并不是对的工具

这种模式并不是没有代价。下面这些批评都非常现实，也值得认真对待：

12.1 Token 成本

Anthropic 自己公布的数据就很坦率：他们的多 agent 研究系统消耗的 token 量是普通聊天的 15×[4]。Milvus 团队还专门发表了一篇尖锐评论，题为“Why I’m Against Claude Code’s Grep-Only Retrieval”，核心观点是：相比预先计算好的查找方式，迭代式 grep 循环的单次查询成本要高得多[21]。行业里的常见估算是：每个任务的 token 消耗通常是聊天机器人的 5–30×；复杂 agent 循环的成本大约在每次查询 0.02–0.10 美元，而传统 RAG 往往只要零点几美分。Prompt caching 和工具懒加载可以显著缩小差距，但无法完全抹平。

12.2 延迟

每次查询要走 5–10 次工具调用，耗时往往是“几秒”而不是“几毫秒”。对于交互式编程，这通常可以接受；但对于面向用户、要求亚秒级响应的聊天场景，就不行了。SWE-grep 和 Context-1 的出现，正是为了把这类延迟压下去。

12.3 超大规模语料

在一个拥有 1000 万个文件的 monorepo 上跑 grep，本身就不是零成本。ripgrep和并行遍历确实有帮助，Explore subagent 模式也可以把搜索扇出到多个分支，但一旦规模上升到 PB 级，预先构建好的索引仍然更有优势。更现实的混合方案是：先用索引在大语料中圈定较小范围，再在这个由 agent 选出的子集内部做 agentic search。

12.4 真正偏语义的查询

像“这个代码库里是怎么定义 retry policy 的？”这类问题，grep 就不如 embeddings 擅长。因为答案可能散落在多个文件里，而且这些文件根本不会出现retry这个词，取而代之的可能是backoff、requeue、circuit_breaker。Agent-as-retriever 的应对方式，是发起多轮查询再做综合。Probe 和具备 AST 感知能力的工具，则通过理解代码结构来解决这个问题。混合方案（如 Cursor）通常会保留一层轻量级语义能力，用来处理这类同义词问题。

12.5 高度相互依赖的任务

Anthropic 自己也提醒过：多 agent research 对“广度优先”的问题有帮助，但对像编程这样高度串行、强依赖上下文推进的任务，反而可能有害[4]。任务本身的结构，会直接影响这种架构是否合适。

12.6 确定性与缓存

向量检索是确定性的，也很容易做缓存；agent 循环不是。随着评测体系逐步完善，生产团队正在收敛到RAGAS、BenchmarkQED和SWE-bench Verified这类评估框架，但相比静态 retriever，agent 系统在评估、回归测试和 SLA 约束上仍然更难做。

13. 架构对比

按具体属性逐项比较：Vector RAG、Agentic RAG、Agent-as-Retriever、Hybrid（Cursor-style）以及 Structural（Cline/Probe）。

• 适用场景。Vector RAG：面向文本的稳定 FAQ。Agentic RAG：适合多跳问答。Agent-as-Retriever：适合代码、持续演化的语料，以及精确匹配型查询。Hybrid：适合查询类型混杂的大型代码库。Structural：适合要求高精度、能理解结构的代码查询。
• 是否需要预构建索引？Vector：需要（向量索引）。Agentic RAG：需要。Agent-as-Retriever：不需要。Hybrid：需要一个较小的索引层。Structural：不需要（按需解析 AST）。
• 新鲜度。Vector：重新 embedding 之前都会逐渐过时。Agentic RAG：同样如此。Agent-as-Retriever：实时。Hybrid：两者兼有。Structural：实时。
• 安全面。Vector：索引需要存放在某处。Agentic RAG：同样如此。Agent-as-Retriever：只依赖文件系统 ACL。Hybrid：暴露面更小。Structural：只依赖文件系统 ACL。
• 单次查询成本。Vector：约 0.001 美元。Agentic RAG：0.02–0.10 美元。Agent-as-Retriever：0.01–0.05 美元。Hybrid：居中。Structural：低（一次结构化调用可替代多次grep）。
• 延迟。Vector：约100ms。Agentic RAG：2–10s。Agent-as-Retriever：1–10s。Hybrid：1–5s。Structural：100ms-1s。
• 代码场景准确率（SWE-bench class）。Vector：基线仅1.96%。Agentic RAG：约12–30%。Agent-as-Retriever：50–80%+。Hybrid：相近或更高。Structural：高（直接返回完整结构单元）。
• 对漂移的鲁棒性。Vector：差。Agentic RAG：差。Agent-as-Retriever：极强。Hybrid：较好。Structural：极强。
• 语义同义词处理。Vector：好。Agentic RAG：好。Agent-as-Retriever：较弱（可通过迭代缓解）。Hybrid：好。Structural：较弱，除非 agent 具备推理能力。
• 规模上限。Vector：可扩展到数十亿文档。Agentic RAG：相同。Agent-as-Retriever：可轻松处理数百万文件。Hybrid：兼得两边优势。Structural：适合数十万级文件规模。
• 是否可训练？Vector：只能训练 embedding 模型。Agentic RAG：可以训练 agent（如 Self-RAG、A-RAG）。Agent-as-Retriever：可以（如 Search-R1、CoSearch）。Hybrid：可以。Structural：依赖查询 DSL，而非学习得到。

14. 如何选型（2026 决策框架）

2026 年，真正上线到生产环境的团队大致这样选：

• 私有代码仓上的代码问答 → Agent-as-Retriever（纯方案或混合方案）。Claude Code、Devin、Cursor 基本都收敛到了这一路线。
• 大型企业 monorepo，且存在跨服务查询 → Hybrid（如 Cursor、Sourcegraph Amp）或 Structural（如 Probe）。
• 持续演化的语料（日志、仪表盘、CRM、工单系统）→ 通过 MCP server 使用 Agent-as-Retriever。这里“新鲜度”比峰值召回率更重要。
• 稳定的事实型知识库（产品文档、FAQ、术语表）→ 使用带 reranker 的 Vector RAG。不要过度设计。
• 篇幅长、版式复杂的 PDF（财报、科研论文、合同）→ ColPali / ColQwen2（视觉检索），或结合pdfgrep的 Agent-as-Retriever，两种都可行。
• 询问“整个语料中的全局主题” → LazyGraphRAG。因为当答案无法通过单个查询浮现时，Agent-as-Retriever 往往会吃力。
• 多跳推理 + 动态搜索 → 采用类似 Search-R1 的 RL 训练检索策略，或使用 Agentic RAG 框架。
• 对延迟极其敏感的聊天场景 → 专用检索模型（如 SWE-grep、Context-1），或使用带向量兜底层的 Hybrid。
• 广度优先的研究任务 → Multi-agent + agentic search。效果提升90.2%，但 token 消耗增加15×。这里的账很好算：当任务价值高于 token 成本时，多 agent 就值得。
• 强串行任务（例如端到端完成单个功能开发）→ 单 agent，加上强上下文工程。不要为 multi-agent 额外开销买单。
• 严格的数据驻留 / 合规环境 → Agent-as-Retriever 在结构上更容易获批：没有外部索引，也没有 embeddings 离开主机。

15. 接下来会怎样：这一模式的演进方向

从 2026 年后半段到 2027 年，值得重点关注这些变化：

• 经过 RL 训练的检索会成为标准配置。Search-R1 看起来更像第一代产品。可以预期，2026 年几乎所有前沿推理模型都会原生提供基于 RL 训练的搜索 / 工具调用能力。
• 专用检索模型会快速增多。除了 SWE-grep、Context-1，未来 12 个月还会出现更多同类模型。1–3B参数规模的 “retrieval-LLM” 正在形成一个新类别。
• MCP 会无处不在。到 2026 年底，“通过 MCP 暴露你的数据”会比“构建一个向量索引”更常见地成为架构决策。
• Structural search 会与 agentic 路线融合。类似 Probe 的 AST 工具会成为一等 MCP server；agent 不再把grep + read串起来，而是直接调用这些工具。
• Hybrid 会成为默认选择。“纯 agentic” 和 “纯 vector” 的争论，会输给 “小型向量层 + 大量工具” 这条 Cursor 式路径。Hybrid 的表达能力严格更强。
• Agent-as-Retriever 会用于 agent 自身的记忆系统。Letta、MemGPT、Mem0 已经把 memory 当作可检索目标；有了 MCP，agent 的历史记录也会变成另一个 MCP server。
• 缓存会继续改进。prompt caching 已经显著缩小了 token 成本差距。接下来，预计跨 agent 多轮交互的 KV-cache 复用会进一步拉大这个优势。
• 评测体系会逐步跟上。RAGAS、BenchmarkQED、GraphRAG-Bench、SWE-bench Verified 都在推进中。2026 年将是团队不再争论哪种检索方式“更好”，而是开始基于自有数据实测决策的一年。

16. 结论

三年来，RAG 领域的主流假设一直是：检索是位于 LLM上游的一个系统——先做 chunks、embeddings、top-k，再把结果放进 prompt。agent-as-retriever这种模式，以及它被进一步形式化为 just-in-time context loading 的做法，则把这个关系彻底反转了：检索不再是 LLM 之外的前置系统，而是 LLM 通过工具调用表现出来的一种行为。Agent 会自行决定该找什么、何时再次查找、何时停止，以及如何组合找到的信息。至于“retriever”具体是什么，则取决于场景：可能是某个 shell command、MCP server、AST query，或是经过 RL 训练的搜索策略。

证据并非停留在推测层面。Claude Code 已经把这套方式产品化，并观察到它的效果优于 RAG。Anthropic 自家的多 Agent 研究系统也采用了同样的模式，相比单个 Opus 4 带来了90.2%的提升。Cursor 的回应则是直接招募了打造这套方案的人。Amazon 的测量结果显示：在完全不使用向量数据库的情况下，也能达到 RAG 忠实度的 94.5%。Search-R1 进一步用 RL 训练搜索策略，并取得了相对24%的领先。Windsurf 和 Chroma 则训练了专门的检索模型。到现在，这一模式已经被广泛复制、基准测试、产品化，通过 MCP 标准化，并且实现了端到端训练。

这并不意味着 vector search 已经过时，而是说，它不再是默认选项。到了 2026 年，默认思路会变成：给 agent 配好工具，认真设计这些工具，让它按需进行 just-in-time 检索。只有在工作负载确实需要 embeddings 的时候——例如需要语义泛化、面对超大且相对稳定的语料，或要求亚秒级聊天响应——再把 embeddings 加进来。否则，就跳过它们。

率先真正理解并吸收这一转变的团队，会拥有更精简的技术栈、更清晰的部署方式，以及迭代更快的产品。没有跟上这一变化的团队，则会在 2026 年继续为那些其实根本不需要向量索引的问题维护 vector indexes。

学AI大模型的正确顺序，千万不要搞错了

🤔2026年AI风口已来！各行各业的AI渗透肉眼可见，超多公司要么转型做AI相关产品，要么高薪挖AI技术人才，机遇直接摆在眼前！

有往AI方向发展，或者本身有后端编程基础的朋友，直接冲AI大模型应用开发转岗超合适！

就算暂时不打算转岗，了解大模型、RAG、Prompt、Agent这些热门概念，能上手做简单项目，也绝对是求职加分王🔋

📝给大家整理了超全最新的AI大模型应用开发学习清单和资料，手把手帮你快速入门！👇👇

学习路线:

✅大模型基础认知—大模型核心原理、发展历程、主流模型（GPT、文心一言等）特点解析
✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑
✅开发基础能力—Python进阶、API接口调用、大模型开发框架（LangChain等）实操
✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用
✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代
✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经

以上6大模块，看似清晰好上手，实则每个部分都有扎实的核心内容需要吃透！

我把大模型的学习全流程已经整理📚好了！抓住AI时代风口，轻松解锁职业新可能，希望大家都能把握机遇，实现薪资/职业跃迁～

这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】