Agentic RAG：Agent 自主决定检索策略的新范式——从固定管线到自适应管线

从固定管线到自适应管线：为什么 RAG 需要 Agent

Agentic RAG：Agent 自主决定检索策略的新范式

固定管线的三类失败

经典 RAG 管线是刚性的：查询进来，改写、检索、重排、生成，每一步固定执行一次。这条流水线在生产里跑得多了，失败模式收敛为三类：

第一类是「检索了但没看懂」。检索器返回的片段其实包含答案，但答案埋在次要位置，或者表述与查询的措辞差距过大，生成模型没能利用。正确的动作是把关键片段再捞一次、换个措辞检索，或者追问一个更精确的子问题——而固定管线没有「再来一次」的概念。

第二类是「一次检索根本不够」。多跳问题、对比问题、需要先查 A 再用 A 的结果查 B 的串联问题（多跳细节我们另一篇专门讲），一次检索注定失败。固定管线无论检索器多好，结构上就答不了。

第三类是「检索了但不该检索」。一些闲聊、常识题、系统能力询问，根本不需要检索，固定管线照样跑全套，白白增加延迟和成本；更糟的是检索回来一堆噪声片段，反而把模型带偏。

三类失败指向同一个根因：管线是死的，问题是活的。查询类型千变万化，最优策略因查询而异，没有一条固定管线能同时是最优解。Agentic RAG 的解法是把「策略」从代码里搬到模型手里——检索不再是一个固定步骤，而是 Agent 工具箱里的一件工具，什么时候用、用几次、用哪把，由 Agent 在运行中自主决定。

Agentic RAG 的核心：把检索变成工具

概念上这个转变很小，工程上却是范式转换。固定管线里，「检索」是代码逻辑；Agentic RAG 里，「检索」是一个带清晰输入输出契约的工具（tool），Agent 的循环是标准的「思考 → 选工具 → 观察结果 → 再思考」。模型拿到了流程的控制权，同时也拿到了失败重试、策略切换、提前终止的能力。

这个范式的理论根基可以追溯到 ReAct（Yao 等，ICLR 2023）：用交错式的「推理轨迹 + 环境观察」让模型边想边做。Self-RAG（Asai 等，2023）给出了 RAG 场景的雏形——模型通过特殊 token 自主决定何时检索、检回来的内容是否相关、要不要用；不过 Self-RAG 需要专门微调，而今天的 Agentic RAG 用提示词驱动通用模型就能跑通，工程门槛低了一个量级。

flowchart TD
    Q["用户查询"] --> P["Agent：分析问题"]
    P --> T1{"需要检索吗？"}
    T1 -- "不需要" --> A["直接回答"]
    T1 -- "需要" --> T2["调用检索工具"]
    T2 --> G{"评估检索结果"}
    G -- "质量差" --> R["改写查询/换策略/拆子问题"]
    R --> T2
    G -- "质量好" --> W["信息足够了吗"]
    W -- "不够，还有缺口" --> P
    W -- "足够" --> A

三种主流模式：ReAct、Corrective、规划式

ReAct 循环：最通用的骨架

ReAct 模式就是上图这个循环的朴素实现：把检索工具（有时加上搜索、SQL、计算器等）注册给 Agent，让它在循环里自由调用，直到它判断信息足够、输出最终答案。实现门槛最低，一个函数调用循环加工具 schema 就能跑。

它的优点是灵活，缺点是行为不可预测。同一个查询，这次检索一次就收工，下次可能检索五次换四种措辞。我们在压测中发现，不加约束的 ReAct 循环有大约一成的查询会陷入「换个说法再搜一次」的循环里，每多一轮就是一次 LLM 调用 + 一次检索的成本。所以裸 ReAct 只能当原型，上生产必须加预算控制（后面细讲）。

CRAG：检索结果的自我纠错

Corrective RAG（Shi 等，2024，简称 CRAG）聚焦一个具体环节：检索结果回来后，先评估再使用。它引入一个轻量的评估器（原论文用微调的 T5，工程上用一个提示词化的判断调用也行）给每个检索片段打三档标签：正确、错误、模糊。正确的直接用；错误的触发纠正动作——去外部搜索引擎兜底或者改写重查；模糊的走「精炼」分支，把片段里的关键知识条目提取出来再用。

CRAG 的价值在于它承认了一个行业里大家嘴上承认、系统里没人做的事：检索器的输出质量是需要验收的。固定管线默认检索结果可用，CRAG 把「验收」变成了显式步骤。我们的生产数据支持这个设计：检索质量评估器拦下的「错误」与「模糊」案例约占全部查询的两成，这批查询如果没有纠错环节，直接进生成就是幻觉高发区。

规划式：先拆解再检索

第三种模式是让 Agent 先产出检索计划，再执行。面对复合查询（「对比 A 和 B 两款产品在售后政策上的差异」），规划器把查询拆成子问题清单（A 的售后政策、B 的售后政策），逐个检索、汇总、对比。相比 ReAct 的「边走边看」，规划式先画地图再走路，行为更可审计——子问题清单本身就是一份执行日志，出了错可以定位是哪一步拆错了。

Adaptive-RAG（Jeong 等，2024）把三种模式统一成了一件事：它训练一个分类器按查询复杂度选择策略——简单查询走单次检索，中等复杂度走迭代检索，复杂复合查询走多步规划。这个思路对我们的启示很大：Agentic 不是要放弃固定管线，而是把固定管线降级为三种可选策略之一。多数查询仍然走最便宜的固定路径，只有模型判定需要的查询才升级到 Agent 循环。

工程实现：工具接口、预算与护栏

工具设计：给模型的检索接口要「可读」

给 Agent 的检索工具，接口设计原则和给人用的 API 不一样。几个实战要点：

返回结构化摘要而非原始 chunk。直接返回十个原始片段，上下文立刻爆炸。更好的做法是服务端先做重排和压缩，返回「片段摘要 + 来源编号 + 相关性评分」的列表，让模型能快速判断值不值得展开看某一片段的全文。展开动作本身可以做成第二个工具（get_chunk_fulltext）。
暴露多种检索策略作为不同工具。向量检索、关键词检索、按元数据过滤检索，不要做成一个带参数的大工具——模型对多工具的选择准确率显著高于对多参数组合的填写准确率。
工具描述里写清楚「什么时候该用我」。工具描述是给模型看的说明书，把适用场景、不适用场景写进去，比调 prompt 更有效。

tools = [
    {
        "name": "semantic_search",
        "description": "在知识库中做语义检索。适合概念性、描述性问题；"
                       "不适合精确术语匹配（请改用 keyword_search）。",
        "input_schema": {
            "type": "object",
            "properties": {
                "query": {"type": "string"},
                "top_k": {"type": "integer", "default": 8},
            },
            "required": ["query"],
        },
    },
    {
        "name": "keyword_search",
        "description": "精确关键词检索，适合型号、错误码、法规编号等术语。",
        "input_schema": { "...": "..." },
    },
]

预算与止损：Agent 的缰绳

Agentic RAG 生产化的第一原则：任何循环必须有硬预算。我们线上执行的是三层预算：单查询 LLM 调用次数上限（默认 6）、检索工具调用上限（默认 8）、总 token 消耗上限（按成本折算）。三层任何一层触顶，Agent 收到系统消息被强制收束：「预算耗尽，请基于当前已获取的信息作答，并明确说明信息不足的部分」。

止损消息的措辞很讲究。直接掐断循环会让模型输出一半的思考痕迹，观感很差；给一个「收束指令」，模型会老老实实输出「基于现有资料……关于 X 我们没有找到可靠信息」，把失控降级成一次诚实的拒答。

第二个缰绳是重复检测：给模型每次的检索措辞做嵌入，相似度超过阈值的重复检索直接拒绝并提示「你已经检索过类似措辞，请换策略或作答」。这一条干掉了我们观察到的绝大多数死循环。

失败模式与护栏

上线一年，我们踩过并被护栏按住的失败模式盘点：模型把检索结果里的旧版本文档当最新事实（护栏：检索元数据里强制带时间戳，系统提示里要求引用时注明日期）；模型对评估器形成依赖、评估器误杀时模型不敢用其实可用的片段（护栏：评估器只降权不删除，低分片段降序后置而非丢弃）；闲聊查询被 Agent 复杂化（护栏：入口分类器先跑一遍，明显不需要检索的直接短路）。

还有一条反直觉的经验：Agentic RAG 的延迟方差比均值更伤产品。固定管线的 P99 大约是均值的 1.5 倍，Agent 循环的 P99 可以到均值的 4 倍以上——个别查询循环五六轮。前端必须配合流式输出与「正在检索第 N 轮」的进度提示，否则用户在第三轮时就已经流失了。

什么时候值得上 Agentic

把选型判断压缩成一个决策清单：查询分布里多跳、对比、需要自我纠错的复杂查询占比超过三成，值得上；知识库质量参差、检索召回不稳定（评估器有活干），值得上 CRAG 那一层；查询大多是简单的点状事实问题，固定管线加个查询改写就够了，上 Agent 是给系统买延迟和不确定性。

另一个务实建议是从 CRAG 起步而不是从裸 ReAct 起步。CRAG 的行为空间小（评估 + 纠错两个动作），可控性和可调试性都好得多，收益却拿到了大半。等团队对检索质量评估、纠错动作的运营都有了手感，再逐步放开规划式和自由循环。Agentic RAG 的能力是按需解锁的，不是一步到位的。

最后提醒一句观测先行：在动架构之前，先把「每条查询实际检索了几次、检索质量评估器打了什么分、最终答案有没有被拒答」这三组数据记录下来跑两周。这三组数据会直接告诉你你的查询分布里有多少流量真正需要 Agent——用数据代替直觉做这个决策，是最便宜的选型方式。

小结

Agentic RAG 的本质是把检索策略的控制权从代码移交给模型：检索成为工具，Agent 在「思考—检索—评估—再行动」的循环里自主决定策略。三种主流模式各有分工——ReAct 提供最通用的循环骨架，CRAG 把「检索结果验收」变成显式环节，规划式用先拆解后执行换取可审计性，Adaptive-RAG 则示范了三者如何按查询复杂度统一调度。

工程上的生死线不在模型能力，而在缰绳：硬预算、重复检测、强制收束、入口分类，四件套缺一不可。选型的判断标准是查询复杂度分布——复杂查询占比足够高才值得上，而且永远保留最便宜的固定管线处理大多数简单查询。Agent 化是渐进解锁的过程，不是架构革命。