目录
[1. Agentic RAG 与 传统 RAG 的核心区别](#1. Agentic RAG 与 传统 RAG 的核心区别)
[2. Query Rewrite（查询重写）算不算 Agentic？](#2. Query Rewrite（查询重写）算不算 Agentic？)
[3. 多轮检索（Multi-turn Retrieval）如何设计？](#3. 多轮检索（Multi-turn Retrieval）如何设计？)
[4. 检索失败后 Agent 应该怎么调整策略？](#4. 检索失败后 Agent 应该怎么调整策略？)
[5. Agentic RAG 的成本和稳定性问题怎么控制？](#5. Agentic RAG 的成本和稳定性问题怎么控制？)
1. Agentic RAG 与 传统 RAG 的核心区别
两者的根本差异在于控制流（Control Flow）的主导权。
-
传统 RAG (流水线式): * 架构: 线性且静态（Query -> 检索 -> 组装Prompt -> LLM生成）。
- 特征: 无论问题多复杂，都只执行一次检索和一次生成。LLM 被动接收检索到的上下文，如果检索回来的内容是垃圾，LLM 产出的也是垃圾（Garbage in, garbage out）。
-
Agentic RAG (智能体式): * 架构: 动态且循环（基于 ReAct、Plan-and-Execute 等范式）。
- 特征: LLM 作为"大脑"主动参与流程。它会评估 用户问题、规划 需要哪些信息、调用 不同的检索工具、判断检索结果是否足够，并决定是直接回答还是继续补充检索。
2. Query Rewrite（查询重写）算不算 Agentic？
结论是：视其驱动方式而定。 * 不算 Agentic（属于高级 RAG 技巧）: 如果你的 Query Rewrite 只是一个固定的前置规则或单次 LLM 调用（例如：让 LLM 把用户的口语化提问改写为 3 个适合向量检索的关键词），这依然是流水线的一部分。
- 算作 Agentic 的情况: 如果 Query Rewrite 是基于自我反思（Self-Reflection）触发的。例如，Agent 进行了第一次检索，阅读结果后发现没有命中答案，自主决定调整搜索词并重写 Query 进行第二次检索。这种具备"观察 -> 判断 -> 动作调整"的重写，就是典型的 Agentic 行为。
3. 多轮检索（Multi-turn Retrieval）如何设计？
设计高鲁棒性的多轮检索，通常依赖以下几个核心模块的配合：
-
任务拆解 (Decomposition): 面对复杂问题（如"对比A公司和B公司2023年的营收增速"），Agent 首先将其拆解为子问题："A公司2023年营收"、"B公司2023年营收"。
-
ReAct 循环 (Reasoning + Acting): * Thought: 我需要先找出A公司的营收。
-
Action: 调用财务数据库检索 "A公司 2023 营收"。
-
Observation: 获取到具体数字。
-
Thought: 接下来我需要找B公司的...
-
-
记忆与状态管理 (State Management): 在多轮循环中，必须有一个统一的 Scratchpad（暂存区）记录"我已经知道了什么"和"我还需要查什么"，防止 Agent 像无头苍蝇一样重复检索相同的内容。
4. 检索失败后 Agent 应该怎么调整策略？
一个成熟的 Agentic RAG 面对检索失败（如：返回为空、相似度极低、或提取不出有效信息）时，应该有一套梯度的 Fallback（降级/回退）策略：
-
策略一：搜索词降维与泛化。 放弃精确匹配或长句匹配，提取核心实体。如果用户问"如何处理报错代码0x8000FFFF中的内存溢出"，系统找不到完整案例，可以回退检索"0x8000FFFF"。
-
策略二：切换检索路由（Router）。 向量检索（Dense Retrieval）找不到，可能因为需要的是精准匹配，Agent 应自主切换到 BM25/Elasticsearch 关键词检索；如果涉及实体关系，切换到知识图谱（Graph RAG）或 SQL 数据库查询。
-
策略三：引入外部知识（Web Search）。 当本地知识库确实缺失时，Agent 判断权限后，调用 Google/Bing Search API 去公网寻找答案。
-
策略四：反向澄清（Clarification）。 当系统发现用户的 Query 存在歧义或严重缺失条件导致无法检索时，Agent 应停止盲目尝试，主动向用户提问（"请问您指的A系统是v1.0还是v2.0版本？"）。
5. Agentic RAG 的成本和稳定性问题怎么控制？
这也是目前企业级落地最难跨越的门槛。Agentic RAG 的试错机制会导致 Token 消耗成倍增加，且容易陷入死循环。
成本控制 (Cost):
-
大小模型协同 (Model Routing): 不要所有节点都用 GPT-4o 或 Claude 3.5 Sonnet。意图识别、简单的 Query 改写、判断检索结果是否相关的打分任务，可以使用微调过的本地小模型（如 Llama-3-8B 或 Qwen-7B）处理。只有最终的规划和长文总结才使用昂贵的大模型。
-
语义缓存 (Semantic Cache): 对高频的相似多轮检索路径进行缓存，直接返回之前的推理结果，跳过 Agent 思考过程。
稳定性控制 (Stability):
-
设置绝对护栏 (Hard Limits): 必须在工程层面限制 Agent 的
max_iterations（最大循环次数）。超过限制（如 3 或 5 次）强制终止思考，使用现有信息尽力回答或宣告失败。 -
结构化输出约束: 强依赖 JSON 模式或函数调用（Function Calling）来限制 Agent 的输出格式，防止因为大模型胡言乱语导致下游代码解析崩溃。
-
人机协同介入 (Human-in-the-loop): 设定置信度阈值，当 Agent 评估自己找出的答案置信度低于 60% 时，将对话转交人工或高亮提示用户"该回答仅供参考"。