去年我接了一个内部知识库改造项目，用传统RAG跑了两周，最离谱的一次是——文档里明明写着“系统仅支持Windows部署”，大模型硬是给用户回答成了“支持Mac端”，原因不过是检索时召回了另一篇提到Mac的文本，生成阶段压根没做冲突校验。那段时间我几乎天天跟幻觉搏斗，后来试着给RAG套上Agent能力，让模型自己决定“该查什么、去哪里查、查不到怎么办”，很多问题才有了转机。
如果你是刚接触大模型应用开发的小白，估计早看烂了“RAG = 检索增强生成”这句话，也知道它大概是“把文档切碎存起来，让大模型先查再答”。但很多人卡在同一个地方：文档切多大？向量库怎么选？为什么资料齐全，大模型还是答非所问？更进一步，当需求复杂到“帮我对比两个方案的差异，再给出建议”时，传统检索加生成根本接不住，你需要的是Agentic RAG。
这篇文章我会从传统RAG的完整实现讲起，把切分、嵌入、检索、提示词设计整个链路摊开，再讲为什么需要Agentic RAG，它的规划器、工具调用、记忆和反思怎么落地，最后给一个能跑通的最小示例和踩坑清单。内容偏实战，适合想快速上手大模型应用、并搞懂背后原理的初学者。
1. 先搞清楚：传统RAG到底哪里不够用，才催生了Agentic RAG
1.1 RAG解决了一个痛点，又带来了一堆新痛点
RAG是把大模型和私有知识连接起来最朴素的方式。它解决的问题很直接：大模型只训练到某个时间点，且没见过你专属的文档、表格和聊天记录。RAG的思路是“你答不上来，就先去资料库查一查再答”，相当于考试允许翻书。
传统RAG实现通常分成三段：文档加载和切分、文本嵌入与向量存储、检索拼接与模型生成。看起来简单直接，我第一版也是这么搭的，一周就跑通了Demo。但两周后我开始意识到，这个架构有一个很隐蔽的假设：提问是一次性的，需求是明确的，答案只需要一次检索。实际业务里，这三个假设会全部破产。
最明显的例子，用户问“我想在本机上跑一个大模型聊天助手，需要什么配置”，传统RAG会把“配置”当关键词去匹配文档，结果召回了显卡驱动安装教程、模型下载地址，还有一篇讲容器部署的。生成器拿到这些碎片只能硬拼，回答看起来流畅，重点却全错。RAG没有能力判断“这个用户当前最缺的是硬件配置清单，而不是驱动的安装步骤”。
这种重检索、轻推理的设计，面对多跳问题、条件判断、多源对比时基本失灵。后面出现的Agentic RAG，就是把检索变成Agent的一个动作，而不是流水线上的一道命令。模型自己规划怎么搜、搜几轮、搜完怎么处理，这个转变让很多原来调不通的RAG项目重新有了生气。
1.2 传统RAG最常见的四个翻车点
我把跟各种团队交流得到的案例归纳了一下，传统RAG普遍翻车在这四个地方。
第一个是召回不充分。文档切得不对，或者检索式选得不对，关键信息被拦腰切断，向量相似度算出来就是不高。资料明明在库里，但“找不到”，这是最冤枉的。
第二个是噪声淹没信号。召回十个片段，真正有用的只有一段，其余的都是同一主题但语境完全不同的内容。大模型分不清哪些该参考，经常被无关片段带偏，甚至幻觉更重。
第三个是没法多跳推理。比如“找出所有延迟超过100ms的接口，并告诉我调用次数最高的是哪个”，这需要先查接口列表，再拿接口名去查调用记录。传统RAG的一次检索根本没法定这种带中间步骤的问题。
第四个是没有反馈纠错。检索错了就错了，生成阶段不会重新查。模型宁可一本正经编出一个答案，也不会说“资料不够”。这四个翻车点，正是Agentic RAG的突破口。
不过也要泼盆冷水：如果业务问题就是“这个产品怎么下载”这种单轮问答，传统RAG又快又稳，没必要上Agent。学Agentic RAG之前先把基础RAG的底子打扎实，是我最想强调的一点。
2. RAG基础实操：切分、嵌入、检索、生成的正确姿势
2.1 一条完整的RAG链路长什么样
用一个实际场景：某公司有大量产品说明文档，员工提问“售后保修期是多久”。传统RAG链路是：
- 文档处理：把PDF或Word转成纯文本，清洗掉页眉页脚，按段落结构切块。
- 嵌入：把每个文本块通过嵌入模型转成向量。
- 建库：把向量写入向量数据库，同时存原文和元数据。
- 检索：把用户问题也转成向量，做相似度检索，取TopK。
- 生成：把检索片段塞进提示词，让大模型基于片段回答。
这个流程每一环都很关键，而且错误会一路累积，最后反应在答案上。很多时候你以为是模型不够聪明，其实是前面某一环已经把正确答案弄丢了。
2.2 文档切分：决定检索质量的第一道门槛
切分不是一个“按字数切”的机械动作。我最开始用固定长度500字符切，踩了个典型坑：一份文档里“非人为损坏保修一年”和“人为损坏不在保修范围内”被切到相邻两个块。提问“保修范围是什么”，检索只返回了前一块，模型直接回答“保修一年”，完全没看到后面的排除条款。
后来我总结出三条切分原则。
优先按结构切。文档标题能分章节就先按章节切，章节太大再按段落切，段落太长才找句子边界二次切分。简单说就是让每个文本块尽量语义完整。
块与块之间加重叠。比如前后各保留一到两句话，避免关键信息正好卡在边界。重叠量控制在整个块长度的一到两成，太多会浪费存储和检索资源。
元数据一起存下来。来源、章节号、标题、页码都要跟向量一起入库。这样检索结果才能知道“这段文字来自某文档第几章”，生成阶段也能显著降低串信息的概率。
还有一个很少有人注意的点：表格要转成文本再做向量化。表格直接整个向量化效果很差，我会先转成“字段名：值”的文本行，或者转成Markdown表格文本，再嵌入。
2.3 嵌入模型和向量数据库怎么选
嵌入模型的选型没有绝对答案，关键看三点：语言支持、输出维度、相似度计算的稳定性。中文场景下，优先选在中文本语料上训练过的模型，不然“保修”和“保养”的向量可能离得比想象中远。维度也并不是越高越好，高维度会推高内存占用和检索耗时，效果提升却不一定明显。
向量数据库这边我走过两个方向：原型阶段用轻量方案，服务端再用更完整的数据库。为了直观对比，我整理了一张表：
| 场景 | 推荐选择 | 主要理由 |
|---|---|---|
| 原型Demo，数据量小 | FAISS或本地向量索引 | 部署简单，内存级查询快 |
| 多人访问，数据量中等 | Qdrant | 自带过滤和接口，起步快 |
| 大规模，高可用需求 | Milvus | 分布式能力和生态更完善 |
检索方式也别忘了“关键词加向量”的融合。实际项目里，像“售后保修期”这种强实体问题，先拿关键词命中召回一批，再跟向量召回的结果做分数融合，往往比纯向量检索好用。纯向量在语义上很灵活，但词汇层面的精确匹配很容易丢失。
2.4 生成阶段：提示词里的隐形坑
生成阶段最常见的错误，是提示词只写一句“请根据以下资料回答”，然后把TopK结果全部塞进去，又没告诉模型“资料里没有的，就直说没有”。看起来只是少写了一句话，效果差很多。我后来固定用两个设定。
第一，给模型定义角色和输出边界：“你是客户支持助手，只能基于提供资料回答，资料不足时明确说资料不足。”第二，要求输出内容标注来源编号，比如“（来源1，某文档第2章）”。这个标注一开始觉得繁琐，排障时却特别好用，哪句话是编的，扫一眼来源就知道。
输出长度也要控制。RAG回答最常见的问题是“为了显得完整，把能沾边的都讲一遍”，这会稀释重点。我一般会限制输出在二到五段，先给明确结论，再列补充信息，比长篇大论强得多。生成长度看似细节，实际直接影响用户对回答质量的感知。
3. 从RAG到Agentic RAG：变化的不只是名字
3.1 什么是Agentic RAG，它到底在解决什么
Agentic RAG，简单说就是让Agent来编排检索、推理和生成的全过程。传统RAG的检索是流水线上的固定步骤，Agentic RAG的检索是Agent在思考过程中主动执行的一个动作。它不会盲目查一次就交差，而是根据任务拆解步骤：也许先查一轮发现不够，再查第二轮；也许需要根据中间结果改写搜索词；也许查完之后还要把多个来源拿来做对比。
我一直用的比喻是：传统RAG像自动售货机，投币后掉出固定商品，没货也只能干瞪眼。Agentic RAG更像你找了个资深店员。你说想买“适合下雨天穿的鞋”，他先问你是通勤还是登山，再回头翻库存，库存不够还能打电话问厂商，最后给你一个答案。店员做的事就是规划、调用工具、判断结果、再次调用。
3.2 Agentic RAG和传统RAG的核心区别
核心区别可以从四个层面看。
检索变成可循环动作。传统RAG只检索一次，Agentic RAG可以多次检索，每次检索之间还能改写查询条件。我做过一个测试，问“同一个需求在甲方系统、乙方系统里分别怎么实现”，首次检索只返回了乙方，Agent判断缺了甲方，自动把查询改写成“甲方系统需求实现”又补了一次，这才拼出完整对比。
规划器充当大脑。Agent会先理解用户意图，判断问题是简单还是复杂，随后决定直接回答、检索一次、还是拆成多个子任务。对应到工程上，很多人会把这个模块设计成一个路由器。
工具不再只有向量数据库。Agentic RAG可以把向量库、外部API、数据库查询、代码解释器都封装成工具，让Agent按需调用。传统的RAG只连接知识库，Agentic RAG能连接的是一切可调用的服务。
多了一个自省纠错环节。哪一轮检索质量不行，模型可以自己发现并重试；最终答案不合预期，也能再走一轮反思。这种能力传统RAG完全没有，也是幻觉治理最有效的手段之一。
3.3 演进路径：从增强检索到增强决策
放大了看，RAG到Agentic RAG的演进，本质是从增强检索能力进化到增强决策能力。老思路是“让模型答得更准”，新思路是“让模型知道该怎么答”。当任务涉及多步骤、多来源、条件分支时，拼命堆检索质量，效果永远有天花板，还不如让模型参与流程设计。这也是大模型应用从问答机器人走向数字助理的必经一步。
但还是要提醒一句：Agentic RAG不是银弹。它的复杂度、成本和延迟都明显更高。能用传统RAG解决的简单问题，强行上Agent只会给自己增加调试点。方案选型的标准，始终应该是业务问题本身的复杂度，而不是技术时髦度。
4. Agentic RAG关键模块拆解与实现细节
4.1 规划器：让模型先想清楚再做
规划器是Agentic RAG与传统RAG区别最大的地方。它接收用户问题，输出一组动作序列。最轻量的实现方式是让模型输出一段结构化的计划，比如：
[ {"action": "search", "query": "接口A的调用延迟"}, {"action": "search", "query": "接口A的调用次数"}, {"action": "compare", "target": "找出延迟最高且调用频繁的接口"} ]这里有一个特别容易被忽略的细节：规划器输出的query不能直接照抄用户原话。用户说“哪个接口又慢又频繁”，你直接拿“接口”当检索词去查，效果一定差。需要让模型先改写语义，扩出关键词，把隐含概念显式化。我实际做的时候会让规划器输出三个字段：任务类型、检索词、必要条件。比如任务类型是compare，检索词是“延迟”和“调用次数”，必要条件是“接口A”。
规划器的设计也分成两派。一派是调一次大模型，把所有计划一次性生成完；另一派是循环决策，每一步都重新观察、重新决策。前者实现简单但容易跑到偏，后者灵活但成本高。我的建议是先做一个两步决策版本：第一轮判断任务复杂度，简单任务直接走单次检索，复杂任务再进入多步循环。这个折中方案最容易调通，也最适合初学者练手。
4.2 工具封装：把检索器变成Agent能调用的函数
实现Agentic RAG时，检索器不要写死在代码流程里，要封装成工具。工具的名字、用途描述、输入参数和返回结构都要设计清楚。我见过不少项目，工具描述写得很随意，比如“search”，模型完全不知道这个工具是干什么的，调用自然频繁出错。一个合格的检索工具描述至少是这个样子：
TOOLS = [ { "name": "search_docs", "description": "在内部知识库中检索与用户问题最相关的文档片段", "parameters": ["query", "top_k", "source_filter"] } ]这里容易被忽略的是top_k这个参数。传统RAG里top_k是全局配置，但在Agentic RAG里，Agent应当有权力根据场景调整top_k。宏观问题多取一些，精确问题取少量。如果固定死top_k，又等于退化成传统RAG。
建议再封装两个额外工具。一个叫“重新检索”，一个叫“读取全文”。我踩过一个很典型的坑：检索只返回片段，Agent想确认中间上下文，但没有任何工具可用，只能去猜。后来加了一个read_section工具，输入文档ID和章节号，返回完整章节文本，大量误判直接消失。
4.3 记忆机制：短时记忆和长时记忆怎么设计
Agentic RAG会执行多步操作，每步结果如果不记住，下一步就断片。工程上需要在上下文里保留一份工作记忆，结构通常是：用户问题、已执行的计划、每一步的检索摘要、当前结论。然后把这份工作记忆作为新的提示词传给模型，让模型在已有结论基础上继续推导。
长时记忆适合存两个东西。一个是已经检索出来的答案，用来避免重复检索；另一个是用户的历史偏好，比如用户过去说过“只考虑Linux部署”，后续的检索就应该带上这个过滤条件。实现时可以用对话历史向量检索，也可以在规划器的提示词里附带用户画像。不需要引入复杂系统，先把上下文管理做好，效果就够了。
4.4 反思机制：最简单的自我纠错怎么做
反思听起来高深，最简单的实现就是“让模型再审一遍”。第一轮Agent给出候选答案后，把答案连同检索片段一起丢回去，让模型检查一遍：“哪些结论有资料依据，哪些没有依据，重写一份答案。”这一步能明显减少幻觉。
再进阶一点，可以加一个验证器：把候选答案拆成一条条断言，再去检索原文逐条验证，不成立的删除或重写。这个思路很像审稿，虽然成本高，但正确率提升明显。我实际项目里用了一个简化方案：只针对带数字和专有名词的断言做验证。比如“保修期12个月”“部署环境是Ubuntu”，这类断言如果出现，就必须带来源编号，否则强制重新检索。这套规则帮助我把关键答案的准确率拉起来不少。
5. 一个能跑通的最小Agentic RAG Demo
5.1 场景设定与架构选型
用一个具体场景串起全文：某公司想让内部助手回答“员工社保和商业保险的赔付先后顺序”，文档分散在薪酬制度、福利手册和保险合作方说明三份材料里。传统RAG做这种跨文档推理很吃力。用Agentic RAG的流程是：
- 规划器判断这是多文档对比任务，规划出三个检索动作。
- 分别检索社保制度、保险手册和合作方条款。
- 提取每份文档里的赔付顺序规则，汇总成对比表。
- 反思器检查答案是否覆盖三个来源，如果漏了就补充检索。
- 输出最终结论，并附上来源。
技术选型上，嵌入模型选一款中文支持较好的通用模型就够；向量库本地版即可；Agent流程直接用函数调用方式硬写，不依赖重量级框架。这里我特别想强调一点：初学者最好把流程手写一遍，不要一上来就套Agent框架。手写过一遍，你对数据怎么流转、提示词怎么生效才会有体感。
5.2 核心代码骨架
下面给一个能跑通的最小骨架，只保留关键逻辑。规划器和反思器都可以直接使用支持函数调用的模型来实现，不需要自己搞复杂状态机。
def agentic_rag(query, tools): # 第一步：让模型生成行动计划 plan = planner_llm(query, tools) # 第二步：初始化工作记忆 memories = {"query": query, "results": []} # 第三步：循环执行计划中的动作 for step in plan["steps"]: if step["type"] == "search": result = tools["search_docs"]( query=step["query"], top_k=step.get("top_k", 5) ) memories["results"].append({ "step": step["step_id"], "query": step["query"], "chunks": result }) elif step["type"] == "read": text = tools["read_section"]( doc_id=step["doc_id"], section=step["section"] ) memories["results"].append(text) # 第四步：基于工作记忆生成答案 answer = generate_with_memory(memories) # 第五步：反思检查并修正 checked = reflect_and_fix(answer, memories, tools) return checked这段代码看着短，真正的难点在提示词。规划器提示词里必须写清楚：可用工具有哪些、每个工具的输入输出是什么、检索结果不足时如何继续检索。反思器提示词里必须写清楚：不得修改有依据的结论、没有依据的结论必须删掉或标注。提示词质量直接决定整个流程的上限。
5.3 跑通Demo时踩过的三个坑
第一个坑是规划器经常一步到位，根本不分步。原因很简单，提示词里没有给例子。我补了两个few-shot示例进去，一个简单问题直接检索，一个复杂问题拆三步，模型立刻就变懂事了。
第二个坑是工具调用传参格式错误。函数调用返回的参数里，模型偶尔会把数字写成字符串，或者把字段名拼错。这种问题不能只靠提示词纠正，代码层要做参数校验和类型转换。比如对top_k直接做int强转，转不了就用默认值兜底。
第三个坑是反思器把正确答案改错了，越改越错。我后来给反思器加了一条规则：某个断言如果在两个独立来源里都被验证，就标为“不可修改”；只有无来源或来源冲突的断言允许改。加了这个规则之后，反思器才真正变得可靠。
6. 实操中的高频问题与排查思路
6.1 检索结果总是“沾边但不准”
遇到这个问题，排查顺序是：先看切分，再看检索方式，最后看评估方法。先用几个长句子做测试，如果长句子检索效果差，多半是块切得太碎，换成段落级再试。检索方式方面，纯向量容易“形近误判”，加关键词命中做分数融合，一般能有改善。另外建议建一个小型标注集，固定二十个问答对，每次改动后都跑一遍，用数据而不是感觉来判断好坏。
6.2 Agent不停循环，检索很多轮都不停
这是个成本杀手。常见原因是规划器提示词里没有“停止条件”。我一般这么解决：给循环加最大步数上限；规划器输出里增加一个completed字段，值为true就强制结束；每轮循环开始前，先让模型判断当前答案是否已经足够，足够就直接输出。光靠模型自觉不可靠，必须从流程上兜底。
6.3 上下文越来越长，成本爆炸
Agentic RAG天生会往上下文里塞很多中间结果，不控制的话成本上升很快。我的优化方案是摘要化：每轮检索完，让模型把结果压缩成一两句要点摘要，再存入上下文；原始片段只保留一个索引列表，需要验证时再按需取出。改完之后成本明显下降，测试效果差异也不大。
6.4 幻觉反而比传统RAG更严重
这种情况通常是因为Agent权力太大，模型为了完成流程会强行填补检索不到的内容。反思机制没兜住，幻觉就会被放大。对策还是回到提示词和验证器，尤其要强调“查不到就直说查不到”。我在反思阶段加了一条硬规则：关于事实数字的断言，没有来源就删除。这一条规则直接消掉了将近一半的幻觉。
6.5 我的调试经验小结
第一，每层组件先单独测试再连线。规划器拿固定问题测，检索器拿固定query测，反思器拿故意改错的答案测，最后再做端到端。第二，把所有中间过程打印出来。Agentic RAG的可解释性很重要，日志里必须能看到每次检索的query、召回片段和模型判断。看不到中间过程，排查问题全靠猜。第三，做提示词版本管理。规划器和反思器的提示词经常要调，我会把每个版本和对应的测试结果一起存进仓库，改坏了能回滚，也能慢慢沉淀出自己的调参经验。
这一路做下来，我的个人体会是：Agentic RAG的复杂度确实比普通RAG高了一个级别，它能解决真实问题，代价是你得接受它更“难伺候”。如果让我给新手一个建议，我会说先别急着追求复杂架构，把切分、检索、提示词这些基本功练扎实，再让模型学会思考。流程能跑通之后，再一步一步往上加记忆、反思、多工具。每一步都改一点、测一点，比一次性搭个大框架稳得多。
