mcp 驱动的 agentic rag

很多人把 RAG 从「一次检索再回答」升级成 Agentic RAG 时，卡住的不是概念，而是怎么让模型自己决定检索几次、调哪个数据源、失败怎么退。MCP 正好把这件事标准化：检索不再写死在主流程里，而是当成一个可挂载、可替换、可观测的工具。这篇讲工程做法——怎么切分工具粒度、怎么设超时和重试、怎么降级、日志记什么、上线前怎么测，以及什么场景下别硬上 Agentic。

很多人把 RAG 从「先检索一次再回答」升级成 Agentic RAG，卡住的不是概念，而是怎么让模型自己决定检索几次、调哪个数据源、失败怎么退。真实项目里最常见的翻车不是模型不够聪明，是检索还写死在主流程里，模型想再查一次只能靠硬编码分支。MCP 的价值就在这：它把检索变成一个可挂载、可替换、可观测的工具，模型按需调用，主流程不再关心底下接的是哪套索引。

但工具化不等于放开手。粒度切太粗，模型只会挑顺手那个；切太细，它又不知道该用哪个。再加上超时、并发、重试、降级、日志和评测这六件事没配齐，Agentic RAG 从 demo 到线上之间差的往往不是模型能力，而是这些工程细节。下面按判断标准到落地清单拆开讲，最后给一条排查顺序。

什么时候该把 RAG 升级成 Agentic RAG

先别急着上。判断依据是三条同时成立才值得：单轮召回经常漏答、问题需要多跳或跨库拼证据、用户问题口径不固定。只满足一条的话，多半是召回或排序本身没调好，加一层 Agent 循环只是把问题藏起来。

不适用的情况要说清楚：语料规模小且固定、问题模板化、延迟敏感的首屏场景，单轮检索加一层排序通常更稳。别为了架构好看硬上。定方向之前，先去 /tools/speed-test 量出当前检索链路的延迟，再对比加一轮工具调用后的额外开销，用数字说话而不是拍脑袋。

用 MCP 把检索包装成工具：粒度怎么切

第一条原则：别把一个「万能检索」工具丢给模型。按数据源或按动作切，比如关键词召回、向量召回、按 ID 取原文、按条件列目录。工具数量控制在四到六个，再多模型选择就开始飘，参数也容易填错。

• 入参写死必填项，把可选项收敛。参数越多，模型填错的概率越高，排查思路可参考站内关于工具调用参数报错的整理
• 工具描述里写清三件事：什么情况该用它、返回什么、拿不到怎么办。这段描述本身就是提示词的一部分，值得像写文档一样打磨
• 返回值做裁剪，只回片段加来源标识，别把整篇文档塞进上下文，否则上下文很快就满了
• 给每个工具配一个极简示例调用，模型照着抄比读一大段说明更准
• 如果两个工具职责重叠，合并或者明确划边界，否则模型会在两者之间反复横跳

工具粒度

一个工具对应一类明确动作，不是一整个数据源

入参收敛

必填项写死，可选项越少越稳

返回裁剪

片段加来源标识，不塞全文

工具描述

写清适用场景、返回结构、失败表现

调用循环的控制：超时、步数、重试

工具化之后，模型能自己决定检索几次，这既是优势也是风险。不给预算，它会一直查下去。给整个循环设两道闸：步数上限和墙钟时间上限，到点就带着已有证据收口。这个上限怎么定，取决于你对最坏延迟的容忍度，可以先按经验值起，再上线后调。

1. 设总预算步数上限加墙钟时间上限，两个都到就开始收口。验证方式：构造一个刁钻问题，看它是否在预算内停下并给出带证据的回答
2. 拆开超时层级单次检索超时和整体超时分开设，检索服务的连接超时和读取超时不是一个量级。连接超时给短，读取超时按索引响应分位数给
3. 重试只对抖动做幂等且明确是网络抖动才重试，指数退避加抖动。参数类错误重试没有意义，直接把这个工具标成不可用
4. 并行但要排队同一轮里的多个检索可以并行发，但要按你自己的并发额度排队，别把上游限流打成 429。验证方式：压测时观察 429 比例

降级、日志与上线前评测

降级要有顺序，不能见错就慌。主检索挂掉先切备用索引或关键词兜底，再不行就直接回答并标注「未检索到资料」，别静默编。用户能接受「没查到」，不能接受「编了一条」。降级路径每次触发都要记日志，不然你不知道它到底多频繁。

评测别只看最终答案，拆成三段看：该不该检索、检索到了对不对、答案有没有用证据。每段准备一小批用例，分开跑。上线前做一次对比，同批问题下单轮 RAG 和 Agentic RAG 的准确率、平均延迟、平均调用次数放在一起看。具体基线数值建议到 /rankings 核对当时的公开对比，再决定要不要留。

如果评测下来 Agentic 只在少数复杂问题上赢，其余场景延迟翻倍，那就把 Agentic 当成可选路径，按问题类型分流，而不是全量替换。这个判断没有绝对标准，取决于你的业务对延迟和准确率各自能忍到什么程度。