RAG 遇上 Agent，不只是"给 LLM 接个搜索框"
很多人第一次接触 RAG，都是这个用法：用户问一个问题 → 检索知识库 → 把结果塞进 Prompt → LLM 生成回答。
这个模式叫Pipeline RAG。它有效，但有个根本问题——它不思考。
Pipeline RAG 对每一个问题都执行检索，不管这个问题是问"WonderBot 订阅多少钱"（确实需要查知识库），还是问"Python 列表怎么求平均值"（LLM 自己就知道）。它像一个只会一招的工人：不管手头的活是什么，都先去仓库跑一趟。
Agentic RAG解决的是这个问题：让 Agent 自己判断何时检索、检索什么、检索完是否够用。
本篇聚焦三个核心能力：
- 检索决策：这个问题需要查知识库吗？
- 多知识库路由：需要查，但查哪一个？
- 质量门控 + Fallback：查完了，够用吗？不够怎么办？
Pipeline RAG vs Agentic RAG：架构层面的本质区别
先看两种架构的对比：
Pipeline RAG（每次必检索）： 用户问题 ↓ 向量检索（无论问题类型） ↓ 结果注入 Prompt ↓ LLM 生成 Agentic RAG（智能决策）： 用户问题 ↓ [决策节点] 这个问题需要检索吗？ ├─ 不需要 → LLM 直接回答（常识/数学/通用编程） └─ 需要 → 查哪个知识库？ ├─ product_kb（产品功能/价格） ├─ ops_kb（部署/运维/监控） └─ faq_kb（账号/退款/发票） ↓ 检索质量够用吗？ ├─ 够 → LLM 生成 └─ 不够 → 重写查询 → 重试（最多 2 次）→ LLM 生成关键差别：LLM 是控制中心，不是下游的文本生成器。
Demo 1: Pipeline RAG vs Agentic RAG 核心差异
用 5 个问题对比两种模式：3 个需要查知识库，2 个不需要（通用常识、数学计算）。
Pipeline RAG 实现
defpipeline_rag(question:str)->dict:"""Pipeline RAG：检索→注入→生成，永远不跳过检索步骤"""docs=unified_retriever.invoke(question)context="\n".join(d.page_contentfordindocs)answer=_ask(f"根据以下参考资料回答问题，若资料无关请基于资料内容作答。\n参考：{context}",question,)return{"answer":answer,"retrieved":True,"docs":len(docs)}注意那个若资料无关请基于资料内容作答——当知识库内容和问题完全不相关时，这个 Prompt 会让 LLM 产生奇怪的行为：要么强行把不相关内容和答案混在一起，要么输出"根据参考资料，无法回答您的问题"。
Agentic RAG 实现
defagentic_rag(question:str)->dict:"""Agentic RAG：先决策，再（选择性）检索"""# Step 1：Agent 决定是否需要检索decision=_ask("判断以下问题是否需要查询知识库才能回答。\n""需要检索的场景：产品定价/功能、运维操作、用户服务政策\n""不需要检索的场景：常识问题、数学计算、通用编程知识\n""只输出 yes 或 no",f"问题：{question}",).strip().lower()if"yes"
