刚用RAG做完第一个知识库问答机器人时，我兴奋了很久——文档切块、向量化、检索、拼接Prompt、生成答案，一套流程跑通，仿佛已经摸到了大模型落地的门。直到用户问了一个问题：“帮我对比一下这两份合同里关于违约责任的条款差异。”我的RAG直接哑火，把两份合同中毫不相干的片段硬凑在一起，生成了一段两头不靠的内容。
那一刻我才意识到，传统RAG骨子里只是一个“一次检索、一次生成”的匹配器。它不会判断问题需不需要多步检索，不会把复杂问题拆成子问题，更不会在检索结果不够好时换个思路重新来一次。这恰恰是Agentic RAG要补上的能力：让RAG具备决策、规划、反思和工具调用的闭环。这篇文章就围绕从RAG到Agentic RAG的演进展开，面向那些已经跑通基础RAG、却总觉得效果差一口气的小白程序员，讲清楚Agentic RAG的核心原理、架构拆解、可运行的代码骨架，以及上线后才会遇到的各种坑。
1. 传统RAG的三板斧，以及“查到即答到”的隐藏问题
1.1 一次对话的三步流水线
传统RAG的工作流程说穿了就三步：索引、检索、生成。索引阶段把文档按固定长度切成若干块，对每一块做向量化，写入向量数据库；检索阶段把用户问题向量化，在库里做相似度搜索，取回最相近的top-k个文本块；生成阶段把这些文本块拼进Prompt，让大模型基于这些上下文生成答案。
这套设计最了不起的地方在于：它用低成本解决了“大模型不知道企业内部知识”的问题，不用微调，不用重训，挂一个向量库就能让模型开口聊业务。所以到今天，企业知识库问答、客服答疑、文档辅助阅读这些场景里，传统RAG依然是最常用的基线方案。
但“常用”不等于“够用”。我自己跑下来之后最大的感受是：传统RAG最适合的是“单点事实型问题”，比如“报销流程是什么”“服务器的IP地址是多少”。这类问题本身指向单一文档片段，检索一次就能命中，生成阶段只需复述。问题一复杂，它就漏出短板了。
1.2 三个反复出现的翻车现场
我自己归纳了三个典型场景，基本都是传统RAG翻车的重灾区。
第一个是跨文档综合问题。用户问“A合同和B合同的违约责任有什么不同”，理想的做法是把两段对应条款同时拿出来做对比。但传统RAG检索时，top-k结果可能全是A合同的片段，模型根本没有同时看到B合同的相关段落，生成的对比自然就偏了。就算两条都检索到了，模型也只是把各自原文各说一遍，没有真正做一个结构化对比。
第二个是分步推理问题。比如“如果今天下单，按仓库的发货规则最早什么时候能发出”。要回答这个问题，先要查“今天星期几、是不是节假日”，再查“发货规则对工作日怎么定义”，可能还要结合订单类型判断走哪个仓。这里面每一步都是独立的检索需求，而传统RAG只会做一次检索，拿到什么算什么。
第三个是外部工具联动问题。用户问“帮我查一下这个订单的库存，然后告诉我能不能下单”。这需要先调用数据库查询库存，再走检索拿商品描述，最后综合判断。传统RAG的流程里根本没有“调用工具”这个环节，它只能被动地从文档里找答案。
这三个场景的共同点是什么？它们都要求系统在回答之前先做判断、做规划：这个问题要不要拆？要不要换一种检索方式？要不要先调外部接口？而这些判断，传统RAG完全没有。它的逻辑链只有一条直线：查询出发，检索一次，生成结束。
1.3 为什么“再检一次”这种土办法治标不治本
刚开始我总是试图用工程手段补完这些场景：提前写一堆if-else，判断用户问题里有没有“对比”“哪一天”“查一下”这些关键词，然后手动触发多轮检索。可没过多久就发现，把决策逻辑写死在规则里，问题种类稍微多一点，规则就指数级膨胀。今天加“对比”，明天来“差异”，后天又来个“趋势变化”，维护成本高到让人想跑路。
正确的解法不是把“下一步做什么”写死在代码里，而是把它交给大模型去判断。这正是Agentic RAG的核心思想：把RAG从一条被动流水线，变成一个有决策能力的智能体工作流。
2. Agentic RAG到底多了什么：从“检索后生成”到“想好再检索”
2.1 给RAG装上“决策—行动—观察”闭环
Agentic RAG这个名字看上去唬人，内核其实不复杂。它就是给传统RAG套上了一层智能体循环：模型先观察用户问题，规划一个行动方案，调用检索或工具去执行，再观察执行结果，判断这些信息够不够回答用户，不够就继续规划下一轮行动，直到满意或达到上限。
这套“决策—行动—观察”闭环，其实就是GPT类模型和外部世界互动的标准姿势。放到RAG场景里，它具体长这样：
- 决策：判断用户问题是直接回答、单轮检索，还是需要拆成多个子问题。
- 行动：选择一个工具来执行，可能是向量检索、数据库查询、代码解释器或者普通搜索。
- 观察：检查工具返回的结果和当前已有的信息，看能不能回答用户。
- 再决策：如果信息不够，重新规划做二次检索，或者换一种查询表达；如果够了，进入生成环节。
拿前面“对比两份合同”的例子来说，Agentic RAG的第一步不是去谋略，而是先判断：“这是一个对比型问题，需要两份文档的相关条款。”然后它的行动是分别检索文档A和文档B的违约条款，而不是把所有目标都押在一次混合检索上。检完之后它还会自查：“我这边有没有拿到两份材料的关键条款？如果A的只拿到一条，B的拿到了三条，这种对比是没法做的。”于是会触发第二轮检索，把缺的那份补上。最后它才进入生成，输出一个真正结构化的对比。
这就是我理解的Agentic RAG本质：它将原来藏在工程规则里的流程控制，交给语言模型实时决定。用户问什么，模型看到什么，知识库里有什么，都会影响到下一步动作，系统不再是死流程，而是活流程。
2.2 四个新能力，逐个说清楚
拆开看，Agentic RAG相比传统RAG主要多了四样东西。
查询路由。系统不再假设所有问题都走“向量检索→生成”这一条路，而是先问一次大模型：“这个问题该走哪条处理链？”比如查天气、看库存这类问题，直接走外部API或数据库；问公司政策，走向量检索；纯闲聊，直接生成。路由本质上是给RAG装了一个分流阀。
查询改写。用户的问题常常是模糊的、口语化的，直接拿原话去检索效果很差。Agentic RAG里模型可以自己对问题做改写，把“这个系统权限设计怎么样”改写成“系统的权限模型是什么”“权限表结构怎么设计”“权限校验逻辑如何实现”等一组更精准的检索语句，然后再去搜。
结果校验与反思。这是传统RAG几乎没有的能力。Agentic RAG在拿到检索片段后，会先做一个自我检查：这些信息真的能回答用户吗？关键词对得上吗？有没有互相矛盾的证据？如果检查不通过，就回到“重新检索”这一环。这一下就把“生成幻觉”的概率压下去不少，因为它不再逼着模型硬着头皮编答案。
工具调用。Agent被允许主动调外部能力，比如执行SQL、跑一段代码、调用天气接口。这让RAG从“只能读文档”扩展到“能查数据、能算数、能联网”，覆盖的场景一下子宽了很多。
2.3 传统RAG与Agentic RAG的一次直观对比
为了不让名词空转，我整理了一张自己常用的对比表，小白可以拿着这张表去判断“我的场景到底需不需要上Agentic”：
| 对比维度 | 传统RAG | Agentic RAG |
|---|---|---|
| 流程控制 | 固定流水线，一次检索一次生成 | 模型动态决策，支持多轮循环 |
| 复杂问题处理 | 直接检索，容易丢信息 | 拆解、改写、多跳检索 |
| 工具调用 | 不支持 | 支持SQL、API、代码执行等工具 |
| 结果自检 | 无 | 有校验与反思机制 |
| 延迟 | 低，一般1秒内 | 高，平均多轮LLM调用 |
| 成本 | 低 | 较高，需要设计护栏 |
| 适用场景 | 单点知识点问答 | 对比分析、多步推理、跨数据源问题 |
这张表也暗示了一个重要观点：Agentic RAG不是来淘汰传统RAG的。如果你的场景大部分是“查政策”“找文档”，传统RAG又简单又便宜，根本没必要上Agent。Agent的价值在复杂场景里才真正凸显，所以做技术选型时，先想清楚问题复杂度，比追新概念重要得多。
3. Agentic RAG的主干架构：路由、重写、校验、终止条件
3.1 第一道闸门：查询路由
Agentic RAG的入口通常是一个路由节点，它的作用相当于总机接线员。路由节点接收用户问题，输出一个决策，比如：
- 直接回答：问题不需要外部知识，模型自己就能答。
- 单轮向量检索：问题指向文档库，一次检索就能搞定。
- 多跳检索：问题复杂，需要拆成多个子问题分别检索。
- 工具调用：问题需要查数据库、查库存、执行计算。
实现路由最简单的方式，是让大模型输出一段JSON指令，再用代码去解析和执行。我给一个小白能直接看懂的示意：
from pydantic import BaseModel class RouteDecision(BaseModel): action: str # "direct" / "vector" / "multi_hop" / "tool" reason: str def route_query(query: str) -> RouteDecision: prompt = f""" 你是一个问题路由助手。判断用户问题应该走哪条处理路径： - direct：可以直接回答，不需要外部资料 - vector：需要从知识库检索一次 - multi_hop：需要拆解成多个子问题分别检索 - tool：需要调用数据库、API或代码执行完成任务 用户问题：{query} 请输出JSON，包含action和reason。 """ resp = llm_chat(prompt, format="json") # 让模型按JSON格式输出 return RouteDecision.model_validate_json(resp)这个阶段唯一的门槛是：模型得有结构化输出能力。现在的商用API基本都支持JSON输出模式，直接开就行。路由的好处是把资源的分配从“一刀切”变成“按需供给”，简单的快，复杂的稳，整体成本也会降下来。
3.2 拆与改：复杂问题怎么一步步逼近
路由决定“要不要拆”，改写解决“怎么拆得准”。我跑通多跳检索后的体会是：这一步是整个Agentic RAG里信息增益最大的地方。
用户原话往往是这样的：“如果我今天下单，这个产品什么时候能收到？”这句话直接去向量库检索，匹配到的多半是产品介绍和物流政策页，内容很散。理想的做法是先把它改写成一组有序子问题：
- 这个产品的预计发货时效是多少。
- 下单时间是否影响发货安排。
- 物流配送的预计天数。
接着系统按顺序检索每个子问题，每步拿到的片段进入同一个“证据池”。等所有子问题都跑完，证据池里信息互相补充，模型再基于完整上下文生成最终答案。
这个动作的背后逻辑是：语言模型在做检索时，对“检索目标”的敏感度很高，关键词稍微偏一点，结果就天壤之别。把大问题拆成小问题，本质上是给检索提供更明确的靶子，让每次检索都更容易一击命中。
我在实操中还会给每个子问题打上“必要程度”标签，有些子问题如果首次检索命中率很低，就直接换表述重新搜，而不是默认推进。这个细节看似不起眼，却让多跳回复的准确率明显提升。
3.3 从“搜到就算”到“够不够回答”的自查机制
传统RAG在信息不足时，还是会生成一个看似流畅的答案——这是幻觉最猖獗的环节。Agentic RAG则多了一步校验，用一个独立的判断环节去检查“现有的证据能不能撑起这个回答”。
这步我通常是这么实现的：
def verify_sufficiency(evidence: list[str], query: str) -> bool: prompt = f""" 根据以下检索片段，判断它们是否足够回答用户问题。 用户问题：{query} 检索片段： {chr(10).join('- ' + e[:300] for e in evidence)} 请回答：SUFFICIENT（足够）或 INSUFFICIENT（不足）。 如果片段无法覆盖问题的时间、主体、条件、对比对象等信息，一律回答INSUFFICIENT。 """ verdict = llm_chat(prompt) return verdict.strip().upper() == "SUFFICIENT"这里有个很实用的技巧：把校验节点分开调用，不要和生成节点共用同一段Prompt。如果你让同一个模型“既判断证据够不够，又同时在不够的情况下生成”，它很容易为了完成回答任务而下意识地编造内容。分开之后，校验节点没有“必须给出答案”的压力，输出更诚实、更保守。
如果校验结果是INSUFFICIENT，系统有两种后续策略：一是重新检索，换关键词、换检索范围、换数据源；二是直接向用户承认“这个问题目前知识库里没有足够的信息”。不要小看第二种策略，在客服问答场景里，一次坦诚的“不知道”，比三次一本正经的胡编更不容易引发用户投诉。
3.4 别让Agent无限循环：终止条件设计
多轮循环是所有Agent系统的双刃剑。它带来了灵活，也带来了失控风险——一个校验节点判断不通过，Agent可能反复检索七八轮，延迟翻倍，token费用翻倍，最后还可能还是答不上来。
所以我强烈建议在架构设计阶段就定好硬终止条件，常见的有下面几种：
- 最大轮次上限：整个检索循环最多执行N轮（我常用3轮），超过就直接进入生成，或者直接拒答。
- 预算上限：每轮开始前累加token消耗，一旦超过某个阈值，强制切回单轮检索模式。
- 置信度阈值：校验节点的判断结果如果有数值化打分，可以设定一个最低通过线；连续两轮都没达到，就应该停。
- 结果收敛判断：如果新一轮检索出来的top-k文本，和上一轮的重合度极高，说明检索已经收敛，继续下去不会有新增信息，直接收尾。
这些护栏本质上是在给Agent立规矩。它的价值和灵活决策一样重要，甚至可以说：一个没有护栏的Agentic RAG，上线第一天就会因为超时和烧钱被叫停。我见过不止一次，项目组激情满满地把多轮检索跑起来，结果用户一个复杂问题下去，系统转了15秒花了上百token，从此再也没有上线过。
4. 最小可用代码骨架：一个不依赖任何框架的写法
4.1 为什么我先不让你上框架
现在市面上有不少Agent编排框架，画图、拖节点、可视化调试都做得很好。但我的建议是：小白第一版，先别急着上框架。用最朴素的Python函数把流程写出来，哪怕丑一点也没关系。原因特别简单：当你用框架时，你看到的是一个个“封装好的节点”，核心流程被藏得很深。一旦出问题，你连“下一步为什么这么走”都很难定位。
而用函数式手写，你被迫把决策、检索、校验、生成每一步都写成显式代码，整个数据流动一目了然。等你把这个骨架跑通透，再去用框架，你会发现框架里的每个概念你都认识——“啊，原来这个节点就是我的route_query函数，那个循环就是我的while。”
4.2 核心数据结构和状态管理
Agentic RAG最核心的其实是状态管理。每一轮循环结束，都要在同一个状态对象里更新证据、决策和步数。我用一个Python字典来管理这些信息，既直观，又方便调试时把整个状态打印出来看：
state = { "query": "", "sub_queries": [], "evidence": [], # 已收集的检索片段 "round": 0, "max_rounds": 3, "final_decision": None, }所有节点函数的输入输出都围绕这个state展开。这种设计方式会让你非常容易加日志、加断点，也方便后面迁移到正式框架。
4.3 主循环代码骨架
下面是我自己项目中精简出来的一个骨架，每一步都配了注释，照着跑就能理解Agentic RAG的运转方式：
def run_agentic_rag(query: str) -> str: state = new_state(query) while state["round"] < state["max_rounds"]: state["round"] += 1 # 1. 路由决策：这一步应该怎么走 decision = route_query(state["query"]) # 2. 根据决策执行动作 if decision.action == "direct": return llm_chat(f"直接回答用户问题：{query}") if decision.action == "vector": query_text = rewrite_query(state["query"]) # 先改写再检索 top_docs = vector_search(query_text, top_k=3) state["evidence"].extend(top_docs) elif decision.action == "multi_hop": sub_queries = decompose_query(state["query"]) for sq in sub_queries: docs = vector_search(sq, top_k=2) state["evidence"].extend(docs) elif decision.action == "tool": result = call_external_tool(state["query"]) # 可以是SQL查库存等 state["evidence"].append(result) # 3. 校验：现在的证据够不够回答？ if verify_sufficiency(state["evidence"], state["query"]): return generate_answer(state["evidence"], state["query"]) # 4. 不够就继续循环，但保留已有证据，下一次会在此基础上改进 # 5. 达到最大轮次，做兜底处理 if state["evidence"]: return generate_answer(state["evidence"], state["query"], force=True) return "抱歉，知识库中暂未找到足够信息来回答这个问题。"这个骨架不算长，但已经包含了一条完整的Agent循环：路由、改写、检索、工具调用、校验、重试、兜底。把它跑通后，你基本就掌握了Agentic RAG的绝大多数概念。
我建议你第一版只保留vector和direct两种决策，把链路跑通，再加multi_hop，最后再加tool。渐进式添加，上游流程出问题时能快速定位，也不会一上来就被多个组件的同时故障搞懵。
4.4 骨架跑通后，再去看框架
当你把上面的骨架在每个环节都打印日志、观察结果之后，再去选择业界成熟的Agent编排框架，心态会完全不一样。框架帮你做了状态持久化、节点可视化、重试机制、并行调度，这些都是工程上价值极高的能力，但你已经知道底层在发生什么，用它时就不只是一个“画图的”，而是真正在用“工具”。
选择框架时只看两点：一是你已有的技术栈是否匹配；二是社区活跃度是否够高，遇到问题能否搜到答案。不必纠结“谁是最强的框架”，因为你核心的业务逻辑应该掌握在自己手里，框架只是管编排的那层壳。
5. 上线前必须面对的四个现实问题：性能、幻觉、成本与评估
5.1 性能：Agentic RAG比传统RAG慢3到10倍，怎么兜底
传统RAG一次问答通常只调用一次大模型生成接口，加上一次向量检索，整体延迟能做到1秒以内。而Agentic RAG动辄两三轮循环，每轮都要调用一次路由模型、一次改写模型、一次校验模型，最理想情况也要三到四次大模型调用，延迟很容易飙到3到10倍。
我处理这个问题有三个经验。第一个是能并行就并行：多跳检索的子问题之间如果没有依赖关系，就用并发把多个向量检索同时发出去，而不是逐个串行。第二个是给小任务用小模型：路由、改写、校验这类简单判断，不需要用能力最强的模型，一个小模型足够识别“这是不是该走多跳”；只有在最后一个生成节点才动用大模型。第三个是给缓存留位置：同一个问题在测试期间会被问很多次，加一层query级别的缓存，命中就直接返回，线上压力和成本都能降一截。
还有一个比较隐蔽的点：不要把Agentic输出了解耦成“文本”，然后继续让后续节点去猜。正确的做法是让每个节点都输出结构化结果，比如JSON标明动作类型和参数，后续代码直接用字段判断，而不是再让模型解析一段自然语言，否则不但不稳定，还凭空多耗一轮token。
5.2 幻觉治理：硬性规定“证据不足就拒答”
Agentic RAG的反思和校验机制，本来是治理幻觉的利器，但如果校验节点设置得太宽松，它就和没有一样。比如你让校验节点只检查“有没有相关文本”，它每次都会说SUFFICIENT，因为随便一段文档片段多少都带点相关性——关键是信息量够不够回答用户。
所以我一般会把校验标准收紧，在提示词里明确加上两类规则：一是关键实体覆盖，用户问题里的核心对象、时间、条件，必须能在证据片段里找到对应词出现；二是结论可支持，生成答案里的每一条关键结论，都应该能在证据片段里找到原句支撑，找不到就不能写。
这些规则再往前推一步，就是在生成回答时要求模型标注证据引用编号，回答内容后附上对应片段索引。这既方便用户核实，也是后台排查幻觉来源的第一手材料。我遇到过不少上线后的“幻觉投诉”，最终靠的都是引用编号定位到问题，发现是某份文档本身信息过时，而不是模型乱编——这种区分对项目组来说是质的差别。
5.3 成本护栏：预算看得见，才能花得放心
Agent的多轮调用会把单次问答成本从几分钱级别抬到几毛钱甚至更高。如果线上用户量起来，又没有预算控制，每月账单出来时会非常心疼。
我的建议是把成本控制做成显式的三层护栏。第一层是轮数上限，这个前面已经说过，再补充一点：上限不是写死3就完事，要按场景区分，比如“简单知识问答上限2轮、复杂对比分析上限4轮”。第二层是总token预算，每轮开始时累加消耗量，一旦超过预算，后续节点自动切换到小模型，甚至直接降级为传统单轮RAG。第三层是高频问题定期缓存，每个月跑一次高频query统计，把Top 100问题的答案直接落到缓存表，命中就不经过Agent流程。
另外要实时记录每一轮Agent的动作日志。不只是为了排查，更是为了做成本复盘：哪类问题总在反复循环？是路由判断错了，还是改写出来的子问题质量太差？日志会告诉你答案，而这些答案会直接变成下一版优化的方向。很多人觉得Agent系统的运行像黑盒，其实只要日志打得够细，每个动作的来龙去脉都能拆得很清楚。
5.4 把Agentic RAG当成一个“可评测系统”来做
任何Agent系统最怕的一件事，就是“感觉变聪明了”但无法量化。模型升级、Prompt调整、重写逻辑变更，都可能改变线上表现，没有评测你根本不知道是改好了还是改坏了。
我跑Agentic RAG之后建立了一套最小可用的回归评测集，大概100条历史真实问答，覆盖直接回答、单轮检索、多跳对比、跨数据源四类问题。每次改动上线前，在评测集上跑一轮，重点看五个指标：
| 指标 | 说明 | 我的及格线 |
|---|---|---|
| 检索命中率 | 关键信息是否出现在检索片段中 | >= 85% |
| 答案准确率 | 生成答案是否与参考答案相符（用专家或更强模型打分） | >= 75% |
| 平均Agent轮次 | 完成一次回答平均消耗几轮循环 | <= 2.5 |
| 超时率 | 延迟超过10秒的请求占比 | <= 5% |
| 单次平均成本 | 单次问答的token/费用消耗 | 低于业务预算 |
这套评测的价值体现在两个地方。一是它把“好不好”量化了，你改Prompt、换模型时心里有底；二是它能拦住回归，很多改动当时看起来没问题，过几天发现准确率莫名其妙跌了，靠的就是这些指标帮你第一时间发现问题。
从我决定把Agentic RAG从“实验玩具”改成“线上功能”之后，几乎每一步改动都是先跑这条评测链路，再决定是上线还是回滚。这不仅是在保护线上体验，也是在保护和用户之间的信任。
我自己操盘完整个改造流程，最想说的一句话是：Agentic RAG解决的不是检索的单一问题，而是一个系统性的决策问题。它真正的价值点，不在于“是不是用了Agent这个热词”，而在于把“下一步怎么做”交给模型去判断，同时用工程护栏兜住模型的不确定性。小白上手时不要急着追新框架、新名词，把路由、改写、校验、终止条件这四个节点先放到自己的代码里跑通，你理解透了之后，再看任何Agent框架都会觉得特别通透。AI的下一次迭代可能很快，但工程的方法是相通的。
