rag vs agentic search

选型会上常吵成一团：有人说向量检索就够了，有人说必须让模型自己多轮搜，还有人提 MCP 一套就全解决。三个东西其实不在一个层面上，硬比很难有结论。这篇给一张对照表和一套先跑小样本再定方案的顺序，帮你在动手前把边界划清楚。

选型会上经常出现这种场面：做检索的同事说向量库已经跑得好好的，算法同学说必须让模型自己多轮搜才准，还有人拍桌子说接个 MCP 不就全解决了。三个东西被摆在同一张桌子上比高低，结论自然是吵不出结果。

问题出在它们根本不在一个层面上。RAG 是一种流程组织方式，agentic search 是一种决策权分配方式，MCP 是一种接入协议。硬比谁更好，就像问「螺丝刀和电钻哪个更厉害」。这篇不给立场，只给一张对照表、一套判断标准和一条先小样本验证再上线的顺序，帮你在动手写代码之前把边界划清楚。

先分清三层，再谈比较

把三者拆开看，其实各自解决的是不同层面的问题。判断要不要引入某一层，先问自己：现在卡住我的到底是「取不到资料」「不知道下一步该搜什么」还是「资料压根不在我库里」。卡点不一样，该加的层也不一样，加错了就是白折腾。

经典 RAG

固定流水线：切片、入库、召回、拼进上下文，每次问答走的路径完全一样

agentic search

把「搜什么、搜几次、要不要换关键词重搜」的决定权交给模型，路径不固定但可以设步数上限

MCP

工具接入协议，解决「模型怎么连上外部系统」，它本身不负责检索质量，也算不上检索方案

三层可以叠加，而且常见的落地形态就是叠加：RAG 当底座保证兜底召回，agentic search 在复杂问题上接管决策，MCP 把外部系统的实时数据接进来当工具。真正要防的是只有一层却硬撑所有场景。什么情况下这套框架不适用？如果你的全部资料塞得进一次上下文，或者用户问的压根跟你的资料无关，那任何检索层都是多余的一层。

按问题形态挑：四类场景对号入座

这张表只是第一道筛子，具体项目还得看数据更新频率和团队维护成本。举例来说，一个 5 人小团队做内部知识问答，语料就是几十份产品文档，这种情况经典 RAG 足够；但如果他们要同时查文档、查工单系统、查一份外部供应商接口，那就不是检索策略问题，而是接不上数据源的问题，该先解决 MCP 那一层。

• 先写清楚现在卡住的环节：取不到、不知道该搜什么、资料在外部系统，三选一，别一次全上
• 语料来源单一且更新慢，优先做经典 RAG，把切片和召回调稳比换模型有用
• 跨源比对、需要多轮追问才出答案，再考虑把搜索决策交给模型
• 外部系统要实时读写，先用 MCP 把通路打通，再回头谈检索质量
• 任何一层上线前都先留一条能退回上一版链路的开关，别把两套逻辑焊死

成本、延迟与可控性的取舍

agentic 链路最容易被低估的是波动：调用轮次不固定，单次问答的 token 消耗自然也是浮动的。上线前必须给每一步设上限——最多几轮检索、单轮超时多久、命中几条就停。这些数字不设，后面压预算时你会很被动。具体单价口径和各家的计费方式，到站内官方 API 资料和 token 价格计算工具里按当时的数字核一遍，别凭印象估。

经典 RAG 的瓶颈通常不在模型，而在召回质量和切片策略。同一份语料，切片粒度差一点、召回条数差两条，答案质量可能差出一个档。所以顺序上先调检索，再考虑换模型，通常更划算。

• 给 agentic 链路设死步数上限和单轮超时，超了就返回兜底答案而不是无限重试
• 限制单次问答注入的上下文长度，长文档场景尤其要压
• 把「检索轮次」和「召回条数」当成两个独立参数分别调，别一起动
• 延迟敏感的业务先量延迟基线再决定并发，别等上线才发现排队

上线前的验证顺序与记录字段

最省钱的做法是先跑一个小样本评测，而不是先搭全套架构。准备一批真实问题，人工标好「正确答案应该出现在哪份资料里」，然后拿这个标注去判断失败原因：是检索阶段就没拿到，还是拿到了但模型没用上。这两种失败对应完全不同的修法，混在一起调只会越调越乱。

1. 定小样本挑一批真实用户问题，覆盖常见问法和几个刁钻问法，人工标注答案出处；标注质量决定后面所有判断的可靠性
2. 量延迟基线用站内测速工具先在目标网络环境下量一遍基线延迟，拿到数字再定并发和超时策略，不要拍脑袋
3. 记关键字段每轮检索的关键词、命中的文档编号、注入的上下文长度、总耗时和 token 消耗全部落表，出问题才有得复盘
4. 定回滚线给 agentic 链路留一个开关，跑飞时能一键切回固定链路；两套逻辑要能独立存活，不要共享同一份状态

评测做完不要只留一份结论，把「哪类问题适合哪条链路」沉淀成一张表，后面新需求进来直接对号入座，比每次重新争论省事得多。