考察点
RAG 和 Agent 的结合是 2026 年面试新热点（「RAG 和 Agent 能否结合」是面经原题）。面试官想看你是否理解从「固定流水线」到「自主决策」的范式变化，以及对工程代价是否清醒——把每个查询都跑成 Agent 循环是新手最容易犯的错误。追问常走「和传统 RAG 怎么共存」。
参考答案
本质区别：流水线 vs 决策循环
传统 RAG 是一条写死的流水线：改写 → 检索 → Rerank → 生成，每个查询走同样的路。问题在于真实查询的难度分布极不均匀：「营业时间几点」和「对比三款产品的售后政策并结合我的订单给建议」根本不该走同一条流水线。
Agentic RAG 把检索变成一个 Agent 的工具，由 LLM 自主决定：要不要检索、检索什么、检索几次、结果够不够、要不要换个姿势再来。检索从「必经环节」变成「可选动作」，决策循环替代固定管道。
四种典型模式
1. 路由（Routing）：Agent 先判断查询类型，分发到不同管道：FAQ 直查、商品库结构化查询、文档向量检索、直接闲聊不检索。这是性价比最高的模式，一次轻量分类（小模型即可，几十毫秒）就让每类查询走最优路径。
2. 检索后反思（Self-RAG / Corrective RAG）：生成前让模型评估检索结果的相关性——「这几段文档能回答这个问题吗？」不够就触发二次检索（换改写策略、换召回路），仍不够就坦承「知识库没有相关内容」。CRAG 这篇论文的实验显示纠正性重检能显著压低幻觉率。
3. 多步检索（迭代式）：复杂问题拆解后多轮检索：第一轮检索发现需要背景信息，Agent 自主发起第二轮补充检索，像研究员查资料一样逐步逼近答案。ReAct 循环的检索版。
4. 多工具组合：检索只是工具箱里的一件。Agent 同时能调计算器（价格核算）、订单接口（查物流）、SQL（销量统计），检索结果和工具结果汇总后作答。这是客服、运维场景的终态形态。
工程代价，必须算清
- 延迟：传统 RAG 一次 LLM 调用出答案，Agentic 版本可能 3-5 次调用加多轮检索，P99 延迟从 2 秒涨到 10 秒级。对延迟敏感的场景（实时客服）要限制最大迭代轮数（通常 2-3 轮）。
- 成本：token 消耗翻几倍，路由和反思环节用小模型压成本。
- 不可预测性：Agent 的自主决策意味着 Bad Case 不再可枚举，需要全链路 Trace（LangSmith、Langfuse）记录每步决策，否则线上问题根本无法归因。
落地节奏
别一步到位。我的项目演进路径：第一版纯流水线 RAG，跑起来收数据；第二版加路由层，把「不该检索的查询」分流出去（这一步就砍掉了 20% 的无谓检索）；第三版对复杂查询开反思重检，限制两轮；多步 Agent 只在明确有价值的场景（如产品对比）小流量灰度。每步都用评测集验证收益，Agentic 是按需长出来的，不是设计出来的。
判断标准也简单：如果 Bad Case 分析显示大量错误源于「流水线太死板」（该多查一次的没查、不该查的查了），就上 Agentic；如果错误都在检索质量本身，Agent 化只会把问题复杂化。
可能的追问
Q：Agentic RAG 和普通 ReAct Agent 什么关系？ Agentic RAG 是 ReAct 范式在检索场景的特化：检索是最核心的工具，反思和规划围绕「信息够不够」展开。区别在于它的动作空间收敛（检索、重写、作答），比通用 Agent 可控得多。
Q：怎么防止 Agent 陷入检索死循环？ 硬限制：最大迭代轮数（2-3）、总 token 预算、单 query 最大检索次数。软引导：Prompt 里明确「两轮检索仍无结果时必须基于已有信息作答或坦承不知道」。
Q：反思环节用什么模型？ 判断「文档是否相关」是个分类任务，小模型（7B 级）微调后准确率就能到 90%+。反思是高频调用，用旗舰模型会把成本打爆。