Agent 搜索栈正在替代 RAG

文章拆解为什么 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 2026arXiv:2602.23368结果表明仅使用rga和pdfgrep的 tool-use agents就能达到 RAG 的 94.5% faithfulness、88.0% context recall以及 91.5% answer correctness [5]。Search-R1arXiv: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、支撑这些架构的基准结果以及如何把这种模式与向量、图结构和长上下文结合纳入一套真实可用的技术栈中。背景为什么 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”的失效模式并不是代码独有的问题而具有普遍性。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.”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]。Agent-as-Retriever 架构详解这种模式实际长什么样在 Claude Code以及更广义的 Claude Agent SDK中检索能力被暴露为一组规模很小、而且刻意设计得“朴素无奇”的工具[3][12]Glob文件路径模式匹配token 成本几乎为零。Grep基于ripgrep的正则内容搜索从 v2.1.117也就是 2026 年 4 月开始在 macOS/Linux 原生构建中还会通过 Bash 调用内嵌的ugrepbfs[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]Budget reduction优先丢弃相关性最低的内容。Snip删除冗余的工具调用输出。Microcompact对单条超长消息做摘要压缩。Context collapse把更早的多轮交互折叠为更短的回顾摘要。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 RAGSelf-RAG、CRAG、A-RAG是一样的但有一个关键区别agent 与底层字节数据之间不存在预先构建好的索引。这里的 “retriever”就是 agent 当下选择调用的那个 shell 工具。证据“Keyword Search Is All You Need”AmazonAAAI 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]。实验使用完全相同的 LLMClaude 3 Sonnet、200K context、temperature 0.001、相同的 6 个数据集、相同的评测框架。唯一的变量只有检索器一边是使用 Titan Text Embeddings V2 的 Amazon Bedrock Knowledge Base另一边则是一个 ReAct agent调用pdfmetadata、rga和pdfgrep来完成检索。所有数据集汇总后的核心结果如下Faithfulnessagent 0.81RAG 0.86 → 达成率 94.52%Context Recallagent 0.68RAG 0.77 → 达成率 88.05%Answer Correctnessagent 0.59RAG 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.”Search-R1当检索策略不是靠提示词驱动而是训练出来的Amazon 的这篇论文表明即便只是一个通过prompt驱动的 agent只用关键词工具也能达到与 RAG 相当的效果。Search-R1Jin et al., arXiv:2503.09516[6] 又向前迈了一步直接用强化学习训练检索策略本身结果不再只是“追平” RAG而是超越了它。其基本设定是在一个 R1 风格的推理模型中加入在推理过程中插入searchquery/search调用的能力。模型通过基于结果的 RL使用 veRL RAGEN学习三件事什么时候该搜、该搜什么、以及什么时候信息已经足够。检索过程中的 token masking 则用于保持训练稳定。在 7 个问答数据集NQ、TriviaQA、PopQA、HotpotQA、2WikiMultiHopQA、Musique、Bamboogle上使用 Qwen2.5–7B-Base 得到的结果如下Search-R1 平均 EM0.431RAG 基线平均 EM0.304SFT 平均0.207 · 不带检索的 R10.276 · Rejection sampling0.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 模型你做不到这一点。全景图2026 年的 Agent-as-Retriever 五种形态到了 2026 年这一模式已经分化出至少五种清晰不同的架构路线而且每一种都有自己的代表性产品。8.1 Pure AgenticClaude Code、Devin没有持久化索引。直接使用Glob、Grep、Read、Bash、Explore subagent。DevinCognition走的也是同一条路。其核心判断是面对一个每次 commit 都在变化的代码库由 LLM 驱动、循环调用ripgrep的方式会优于任何冻结的 embedding 模型。8.2 Hybrid Lexical SemanticCursor、Sourcegraph AmpCursor 的文档明确并列描述了这两种模式[16]精确符号查找用Instant Grep概念性查询用 semantic search再由 agent 根据查询类型决定选哪一种。Cursor 引用的内部研究结果是将 semantic search 与 grep 结合可带来 12.5% 的准确率提升。Sourcegraph 的AmpCody 在 2025–2026 年间演进出的 agentic 版本则是在 Sourcegraph 长期积累的代码图之上叠加了一个类似的 agent[17]。对于大多数企业级工具来说混合路线正逐渐成为收敛方向。8.3 Structural / AST-AwareCline、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 ModelsWindsurf 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 所调用工具的后端是什么以及这些工具是如何构建出来的。多 Agent 的乘数效应Anthropic 自己给出的证明最清晰、且不局限于编程场景的验证来自 Anthropic 自家的工程团队。在他们的文章“How we built our multi-agent research system”[4] 中团队介绍了 claude.ai 的 Research 功能所采用的 orchestrator-worker 架构一个 Lead ResearcherClaude Opus 4负责分析查询、制定计划并派生出 3–5 个子 Agent。每个子 AgentClaude 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 更适合广度优先任务如研究型任务或“从大量来源中找全某类信息”而对于编程这类高度相互依赖的任务效果则没那么理想因为其核心瓶颈往往来自串行依赖。工具设计原则这一切为何成立“Agent 作为检索器”能否成立很大程度上取决于工具设计。Anthropic 关于 context engineering 的文章[2]把原则说得很直接工具应当“自包含、具备错误鲁棒性并且对其预期用途有极其清晰的界定”。输入参数必须“描述性强、没有歧义并能发挥模型的天然优势”。避免臃肿且功能重叠的工具集。每个工具都应该只有一个清晰明确的用途。最终检验标准是“如果一个人类工程师都无法明确判断在某种情境下该用哪个工具那就不能指望 AI Agent 做得更好。”这也是为什么 Claude Code 的工具面如此精简。Glob 只做一件事Grep 只做一件事Read 只做一件事。其余操作都交给 Bash并通过显式权限门控来约束。模型不需要在find_file_by_name、search_file_by_path和locate_file之间纠结该选哪一个。对于每一种问题形态系统只提供一个对应工具。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 可以暴露 incidentsPostgres 可以暴露 tablesfilesystem server 可以暴露代码仓库。对 agent 来说它们的处理方式是一样的发现、搜索、读取、细化。一旦 retrieval 变成一次工具调用那么任何数据源都可能成为 retriever而不再需要有人专门为它构建向量索引。反方观点什么时候 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这类评估框架但相比静态 retrieveragent 系统在评估、回归测试和 SLA 约束上仍然更难做。架构对比按具体属性逐项比较Vector RAG、Agentic RAG、Agent-as-Retriever、HybridCursor-style以及 StructuralCline/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 RAG0.02–0.10 美元。Agent-as-Retriever0.01–0.05 美元。Hybrid居中。Structural低一次结构化调用可替代多次grep。延迟。Vector约100ms。Agentic RAG2–10s。Agent-as-Retriever1–10s。Hybrid1–5s。Structural100ms-1s。代码场景准确率SWE-bench class。Vector基线仅1.96%。Agentic RAG约12–30%。Agent-as-Retriever50–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而非学习得到。如何选型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 离开主机。接下来会怎样这一模式的演进方向从 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 serveragent 不再把grep read串起来而是直接调用这些工具。Hybrid 会成为默认选择。“纯 agentic” 和 “纯 vector” 的争论会输给 “小型向量层 大量工具” 这条 Cursor 式路径。Hybrid 的表达能力严格更强。Agent-as-Retriever 会用于 agent 自身的记忆系统。Letta、MemGPT、Mem0 已经把 memory 当作可检索目标有了 MCPagent 的历史记录也会变成另一个 MCP server。缓存会继续改进。prompt caching 已经显著缩小了 token 成本差距。接下来预计跨 agent 多轮交互的 KV-cache 复用会进一步拉大这个优势。评测体系会逐步跟上。RAGAS、BenchmarkQED、GraphRAG-Bench、SWE-bench Verified 都在推进中。2026 年将是团队不再争论哪种检索方式“更好”而是开始基于自有数据实测决策的一年。结论三年来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%免费】