RAGAgent这套组合过去一年里几乎是每场大模型技术分享必聊的话题。我自己的体会是单看RAG它解决的是“模型怎么知道私有知识和最新信息”的问题单看Agent它解决的是“模型怎么把一个复杂任务拆成几步、调工具去执行”的问题。但当这两件事拼在一起产生的效果远远不是11而是真正把大模型从“聊天工具”变成了“能干活的工作流引擎”。这篇文章想聊的不是概念科普而是我在实际项目中把RAG和Agent做结合时踩过的坑、总结的套路以及不同组合方案之间的取舍。不管你是正准备从零搭一套知识库问答系统还是已经在做Agent相关的应用这轮拆解应该都能给你省几天查资料的功夫。1. RAG和Agent为什么非要绑在一起1.1 各自解决什么问题又各自卡在哪先快速对齐一下概念。RAGRetrieval-Augmented Generation检索增强生成的核心做法是在模型生成回答之前先从外部知识库里检索出相关片段把检索结果拼进上下文再让模型基于这些材料作答。它解决的是模型知识过时、训练数据里没有私有业务数据、以及大模型一本正经胡说八道这三个老大难问题。Agent智能体则是把大模型当作“大脑”让它自己理解任务、拆解步骤、选择工具、执行动作并且根据执行结果不断调整下一步。它解决的是多轮决策问题比如“帮我把这几个Excel合并成一张表再做去重和汇总然后发给对应的人”这种需要多个动作完成的指令。但我做了几个项目之后发现光用RAG有一个明显天花板它默认用户的需求是“一问一答”。用户说“帮我写一份关于XX产品竞品分析的周报”你检索几次给出一篇报告任务就结束了。可如果用户继续说“重点分析一下他们最近的定价策略顺便找找出海市场的关键动作”纯RAG就得重新检索、重新生成整个过程没有“记忆”没有“策略”也没有“判断当前结果是否够用”的能力。而单独的Agent也有个大问题它在做决策时需要事实依据可它本身没有获取外部知识的管道。你可以让Agent调工具去检索但如果你没有给它配一个靠谱的检索后端它调出来的内容质量直接决定了下游所有步骤的质量。这就像让一个聪明人闭着眼睛干活——规划能力再强输入是脏的输出也是脏的。1.2 交互范式变了用户不再满足于“回答一个问题”更深一层看RAGAgent的组合之所以成为主流是因为实际的业务场景正在从“QA问答”升级为“任务执行”。传统的知识库问答产品用户问一句系统答一句看上去很智能但本质上还是一个搜索引擎的变体。而真正让客户愿意买单的场景往往是带着明确任务的写材料、做分析、审查合同、生成周报、处理工单。这些任务有一个共同特征需要多个环节每个环节都需要不同知识支撑而且中间环节的结果会影响后续步骤。这就不是一次检索能搞定的也不是写死一个Prompt流程能搞定的需要系统自己判断“下一步该干什么”“去哪个知识源找什么材料”。Agent负责这个判断RAG负责给判断提供弹药。所以我的观点是RAG和Agent不是竞争关系也不是二选一而是分工协作。RAG的价值是“让模型的回答有根有据”Agent的价值是“让模型的行动有章有法”。当用户要的不只是一个答案而是一个结果时两者就必须组合起来。2. RAG链路的核心环节拆解2.1 知识库构建切分、向量化与索引RAG的地基是知识库而知识库最容易被低估的就是文档切分。我见过不少团队把PDF导进去、调几句代码embedding入库就开始跑结果检索出来的内容驴唇不对马嘴。问题多半出在chunk文档切片策略上。切分过大比如整个章节切成一块几千字embedding向量会被大多数无关内容稀释检索时召回结果不够精准而且直接烧token切分过小比如按一句话切又会导致语义断裂模型拿到的片段缺乏上下文回答起来前后矛盾。我用的经验参数是通用文档按500到800个中文字符切分同时设置80到120字符的overlap重叠。为什么要这个重叠因为关键信息往往跨切分边界分布比如第300到450个字符的信息恰好落在上一片尾部、下一片开头重叠能保证这部分信息至少在一个chunk里是完整的。再配合标题、段落结构做结构化切分效果会好很多。embedding模型的选择也是个关键点。目前中文场景我试下来bge系列比如bge-m3、bge-large-zh表现不错对中文长文本的理解比通用embedding模型稳如果业务场景以英文为主OpenAI的text-embedding-3系列或者开源的E5模型都够用。向量化之后需要一个存储和检索的组件这里没有绝对最优解Milvus性能强适合海量向量检索Qdrant胜在轻量好部署Elasticsearch如果之前就在用可以加向量检索能力省一套运维。中小规模项目选Qdrant就行别一上来就上重方案。2.2 检索与重排为什么不能只靠向量相似度很多团队会把“向量检索”和“RAG检索”画等号这是新手的常见误区。向量检索的核心思路是计算query和chunk的语义相似度它擅长处理“换个说法但意思相近”的情况但有两个明显软肋第一它搞不定精确匹配类需求比如查订单号、合同号、编号规则这类信息往往是字符级别的不是语义级别的第二query和答案之间的语义距离可能很远比如用户问“公司今年招聘情况如何”知识库里相关报道是“校招规模扩大、社招缩减”这种分散的段落单独每一段和query的向量相似度都不高。所以我现在几乎不用纯向量检索而是用混合检索BM25做关键词匹配向量检索做语义匹配最后用RRFReciprocal Rank Fusion倒数排名融合把两路结果合并。RRF的思路很简单粗暴对一个文档把它在两路结果里的排名的倒数相加排名越靠前得分越高。这个算法二十行代码就能实现不需要复杂调参效果却很扎实。检索完之后还需要一道重排Rerank。为什么因为向量检索和BM25的目标都是“尽量别漏掉相关文档”所以召回范围往往偏宽会带进来不少干扰项。重排模型的任务是站在“用户到底在问什么”的角度把召回结果重新精排一遍。我现在常用的方案是bge-reranker-large这类开销比embedding高但只在高分的20到50条结果上跑一次成本完全可控。重排之后取top 3到5条作为上下文给模型效果和直接给15条未重排结果相比答案准确率高一个档次。2.3 查询改写与多轮追问实际项目里还有一个没人提但你一定会撞到的坑用户不会老老实实一次把问题问完。他会说“帮我看看上个月的销售数据”然后追问“那华南区呢”这里的“那华南区呢”如果不做处理直接拿去检索你得到的向量结果会和“上月的全国销售数据”在语义上有偏差检索质量肉眼可见地下降。解决办法是在RAG之前加一层query改写模块把多轮对话的历史信息融合进当前query。具体做法轻量方案可以直接用大模型重写给它当前问题、最近几轮对话、当前知识库上下文让它输出一个能独立理解的问题更省事的方案是用规则把历史上的实体和限定词拼接到当前问题后面。我个人的实践体会是query改写做得越轻越好不要试图让模型一顿分析你只需要把“指代消解”和“缺失信息补全”这两件事做好就够了。改写之后做个简单判定——如果改写后的query和原query差异很大两边都拿去检索再在重排步骤里合并结果这招能明显提升多轮场景的召回率。3. Agent的核心机制与工程落地3.1 ReAct循环推理-行动-观察Agent的底层运行逻辑绝大多数现代框架都绕不开ReAct这个模式。ReAct是一种提示策略全称是Reason Act它的核心是让大模型按照“思考→行动→观察结果→再思考”的循环来运作。简单类比就像你做饭时先想一下冰箱里有什么思考然后去开冰箱门行动看到里面的食材后决定做一个番茄炒蛋观察再决定下一步行动。这个循环和大模型直接给答案的区别在于它把“思考”和“执行”分开了。模型在每一轮都明确输出自己准备干什么、调用什么工具、参数是什么、期望拿到什么结果然后系统拿到真实执行结果再喂回给模型。这一步非常关键因为它让模型有机会在错误路径上“回头”。如果第一步工具调用失败或者结果不符合预期模型能看到真实反馈及时修正计划而不是一条道走到黑。工程实现上ReAct循环需要一个外层控制代码负责解析模型的意图、执行工具、收集结果、拼装下一轮上下文。不管是LangGraph的StateGraph还是自研简单的while循环核心就三个要素模型输出解析、工具注册与执行、上下文状态维护。其中最容易出错的是模型输出解析——大模型偶尔会不按照你要求的JSON格式输出或者工具名写错。我现在的做法是解析失败时给模型反馈“输出格式不符合要求请重新生成”并附带一个格式示例循环最多重试两次不惯毛病。3.2 工具定义与规划策略Agent能不能干活很大程度取决于你给它注册了什么工具以及工具定义写得清不清楚。这个道理有点像招人你不可能要求一个程序员啥都会但你得告诉他要完成什么任务、输入是什么、输出是什么、有什么约束。工具定义我习惯用OpenAPI风格的JSON Schema包含工具名称、描述、输入参数的属性和必填项。这里有个经验描述一定要写清楚“什么时候用这个工具”和“别用这个工具的场景”。比如你有一个“查天气”的工具描述里就应该写“查询指定城市当天的天气情况适用于用户询问天气的场合”如果你有另一个“查航班”的工具最好在天气工具描述里加一句“航班延误相关请使用查航班工具不要用此工具回答”。这个“反例说明”能有效降低模型工具误调用的概率实测效果很明显。规划策略上简单任务用ReAct就够了模型每一步做决策灵活但没有长远计划复杂任务建议用Plan-and-Execute模式——让模型先分解出一个任务清单然后逐个执行每执行完一项允许它根据当前结果微调后续计划。这两种策略的取舍我后面在第四部分展开说这里先记住一条任务越复杂越需要先规划再执行不然Agent容易在细节里绕晕。3.3 记忆与上下文管理Agent系统里“记忆”分两种短期记忆和长期记忆。短期记忆就是当前任务中对话历史、中间结果、工具调用记录长期记忆则是跨会话沉淀下来的用户偏好、项目背景、历史结论。RAG本身就是一种长期记忆的实现方式但它的颗粒度是“知识片段”不是“用户和任务的上下文”。我做记忆管理时有一个很实在的建议别把所有历史对话都塞进上下文。大模型对超长上下文的注意力会稀释早期信息经常被遗忘而且token成本直线上升。可行的方案是保留最近3到5轮完整对话更早的内容做一次摘要压缩每轮摘要控制在100字以内如果任务中间产生了很长的工具返回结果先把结果做清洗和截断比如只保留前2000字符再接进下一轮上下文。这里我想特别提一个我在LangChain里反复踩过的坑Agent在执行过程中如果工具返回一个超长文本框架默认会把整个文本塞回上下文模型里。不要让它这么干一定要在工具函数外层包一层后处理把大段代码或日志做重点提取后再返回。否则你的上下文会快速爆炸而且模型会被噪音干扰后续决策质量直线下降。4. RAG和Agent的三种组合套路4.1 套路一把RAG封装成一个工具交给Agent调用这是最轻量、最容易上手的组合方式。实现非常简单把“检索知识库”封装成一个自定义工具定义清楚它的描述比如“检索内部知识库返回与问题相关的文档片段适用于公司政策、产品文档、制度流程类问题”然后注册到Agent的工具箱里。当Agent收到用户的任务后它会根据问题内容判断是否需要调用这个检索工具。如果需要就生成检索query调用工具拿到结果后作为证据写入上下文再继续分析或生成。这个方案的好处是结构清晰、灵活度高Agent不依赖RAG也能处理那些纯推理类问题坏处是“什么时候检索”完全交给模型自己判断碰到模型偷懒不检索、直接瞎编的情况你没有任何兜底。为了减少这种问题我一般会在系统提示词里明确写一句“回答以下问题前必须先检索知识库引用检索结果中的原文作为依据如果检索结果无法支撑回答需要明确说明信息不足不得自行编造。”这句提示词对于约束模型行为的效果非常明显能让模型在绝大多数情况主动走检索路径。4.2 套路二Agentic RAG让Agent自己决定“检索什么、检索几次”Agentic RAG有时也叫Agentic Retrieval是今年讨论度很高的进阶方案。它的核心思想是不再由你预先规划好“每轮对话检索一次”而是让Agent像一个熟练的资料员一样自己判断“这个问题值不值得检索”“第一次检索结果够不够”“要不要换个关键词再查一次”。一个典型的Agentic RAG流程长这样Agent收到问题后先评估自己是否具备足够知识回答如果信心不足它规划检索策略可能是多个检索query同时发出去拿到结果后它会对结果做一个自评——比如“第一个query的结果覆盖了这个问题的背景但缺少具体数据需要再检索一次”于是再生成新的query去检直至它认为信息足够然后综合所有检索结果给出答案。这个模式我用下来的最大感受是检索的质量真的更高。因为检索query是模型根据当前上下文动态生成的而不是用户原样提问的句子所以往往更精准同时它允许在一条完整回答里进行多次迭代检索非常适合“需要从多个来源对比分析”的任务比如写竞品分析、做市场调研、梳理政策演变这类。代价呢多轮检索意味着更多的模型调用次数、更高的延迟和token开销而且流程控制复杂度明显上升。我用LangGraph实现过一版状态管理、条件分支、循环出口任何一个环节没想清楚都容易出bug所以强烈建议先把方案架构图画明白再动手。4.3 套路三全流程编排RAG在任务的不同阶段多次发挥作用第三种模式不再局限于“一次任务一次问答”的范畴而是在一个较大的任务闭环里让RAG在多个环节扮演不同角色。举例用户要让Agent写一份“智能仓储解决方案”的售前文档。这个任务里Agent先在方案规划阶段从知识库检索公司现有的成功案例和技术白皮书写技术架构章节时又从知识库检索具体产品参数写报价章节时再从价格库检索成本数据。同一任务中多次、不同目的的检索每一个检索结果都服务于当前阶段。这种模式本质上是“Agent做流程编排 RAG做内容供给”适合处理那种长链条的内容生产或分析任务。我把它称为“工程化组合”因为它对系统架构的要求最高——你需要一个能够稳定编排多步骤任务的Agent框架还要保证每个步骤的检索结果能准确传递到下一步。一个务实的做法是每个步骤结束后把该步骤的检索来源、结论、与最终目标的关系记录下来这样最后生成的文档不仅内容丰富还能附上引用出处客户体验和可信度都会好很多。三种组合怎么选我直接放一张对比表组合方式实现复杂度延迟成本适用场景RAG封装为工具低低内部知识库问答、条款查询、政策解读Agentic RAG中高中高多源信息对比、深度调研、开放域问答全流程编排高高长篇报告生成、复杂项目分析、内容生产流水线我的建议始终是先从第一种开始跑通业务闭环后再考虑升级。直接上手Agentic RAG或全流程编排对团队的工程能力和模型稳定性都是很大的考验。5. 实操从零搭一个RAGAgent的最小闭环5.1 选型搭配与架构布局实操环节我分享一下自己项目里验证过的选型方案。技术栈怎么搭配没有标准答案但目标应该是“轻量、可控、易排查”而不是“功能多、学习曲线陡、黑盒多”。我自己最常用的一套组合是LangGraph做Agent的流程编排Qdrant做向量库bge-m3做embeddingbge-reranker-large做重排底膜用Qwen系列或GLM系列的开源版本部署在内网如果对部署成本和性能敏感也可以直接用API。这里多说一句选型原因LangGraph的StateGraph对每一步状态的控制非常精细排查问题时能清楚看到每一步的输入输出Qdrant单机就能跑还自带restful API运维心智负担很小。整体流程可以拆成这样用户query进来先经过query改写改写后的query进混合检索BM25向量拿回top 50结果重排模型精排取top 5把top 5作为上下文连同任务指令一起交给AgentAgent内部根据任务复杂性决定直接回答还是调用其他工具比如查数据库、调API补全信息最后模型基于所有材料生成回答并且每个论点标注来源出处。5.2 关键代码链路Agent里怎么挂RAG下面给出一个最小编排示例的伪代码框架省略了细节和敏感配置我会在注释里说明设计原因。# 步骤1定义检索工具供Agent调用 def search_knowledge_base(query: str) - list[str]: # 1. query改写已在外部完成这里直接使用传入的query # 2. 混合检索BM25 向量检索 bm25_results search_bm25(query, top_k50) vector_results search_vector(query, top_k50) # 3. 合并并使用RRF做初步排序 merged rrf_merge(bm25_results, vector_results) # 4. 取前30条做重排 reranked rerank(query, merged[:30]) # 5. 取前5条作为最终上下文 return reranked[:5] # 步骤2在Agent的工具列表中注册检索工具 tools [ { name: search_knowledge_base, description: 检索内部知识库返回相关文档片段。用于回答公司制度、产品文档、技术方案等内部知识问题。, parameters: { type: object, properties: { query: {type: string, description: 检索关键词或问题应当是完整句子} }, required: [query], }, }, # ... 其他工具 ] # 步骤3Agent主循环ReAct for step in range(max_steps): response llm_call(system_prompt, state, tools) if response.type output: return response.answer elif response.type tool_call: result execute_tool(response.tool_name, response.arguments) # 关键点对工具返回结果做截断或摘要防止上下文爆炸 state.append({role: tool_result, content: truncate(result, 2000)}) # 步骤4超时保护 return 任务步骤较多建议拆分为子任务继续处理。这段代码里最重要的不是具体函数怎么实现而是几个设计决策混合检索而不是单路检索回归RRF合并而不是暴力拼接重排放在最前面而不是最后面GC式的工具返回截断放在tool层而不是靠prompt约束。这四个决策就是刚才两章所有坑的结论。5.3 效果评测与调优的经验数据搭建完成后最容易被忽略的是评测环节。很多团队跑通了demo就直接放上线结果用户反馈“答得不对”却说不清楚哪里不对。我的做法是把评测拆成三个层次第一层是检索质量直接测“给一个query看top 5结果里有没有真正相关的片段”这不需要模型参与跑几组评测集就知道检索链路行不行第二层是答案质量用一套固定的50到100道FAQ问模型人工打分看准确率第三层是任务成功率比如Agent能不能在10步以内完成、有没有死循环、有没有幻觉。三个层面里检索质量是最值得优先调优的因为它出错代价最大。我常用的定位方式是先不看大模型生成的答案只打印检索返回的片段人工判断片段和query是否相关。是片段相关但回答错误问题在生成端片段本身就不相关问题在检索端需要去调chunk大小、embedding模型、混合检索权重、重排阈值。一步步隔离不要一次动三个变量不然出了问题根本不知道是谁的锅。调优参数上给一组经验值chunk大小500至800字符时信息完整度最高混合检索的权重向量和关键词各占50%一般比较稳遇到专有名词多的领域关键词权重可以上调到60%重排后取top 5是“上下文充足和噪音控制”的平衡点top 10以上会开始引入大量无关内容。这组数值不是银弹但可以作为初始基线再微调。6. 常见问题与排查技巧实录6.1 检索结果不相关如何快速定位是哪个环节的锅这是RAG项目里出现频率最高的问题。排查时我严格遵循“链路逐段验证”的思路。第一步直接把用户问题拿去做检索打印出top 5的质量看和用户问题语义是否一致如果质量和用户预期不符去检查切分后的chunk——很多情况下是因为原始文档中的表格被强行切成碎块或者图片里的文字根本没被提取出来。第二步检查embedding模型是不是选错了中文内容用英文为主的模型会导致向量表达能力弱。第三步检查rerank模型的阈值有时候分高的片段不是真相关。6.2 Agent陷入死循环或不停地调同一个工具如何打断Agent在复杂任务中“绕圈”是常见现象。我先做防御性设计给ReAct循环设最大迭代次数通常8到15步以内要求输出超时直接终止并提示用户换一个更聚焦的问题。但这只是兜底更深层的原因是模型对当前目标产生了错误理解。我的一个处理技巧是在系统提示词中加入“目标确认”环节要求Agent在任何循环中每执行完三步就停下来用一句话复述当前已完成任务和目标之间的差距。这个做法一开始还要靠人看它是否照做但几次下来模型会形成一种自我监控死循环概率明显下降。如果模型还是卡在某类问题上可能是该问题的工具集设计有问题比如有两个工具功能高度重合模型拿不准该用哪个就在两者之间反复试探。这类工具合并掉就行。6.3 仍有幻觉不是RAG没用而是约束条件不够硬有些团队上了RAG之后发现模型还是会编内容于是责怪RAG没用。我通常检查两处知识库里是不是真存在回答该问题的依据。如果知识库本身没有答案模型再怎么检索也无法凭空变出正确答案此时需要在prompt里声明“如果知识库中没有相关信息直接回答无法获取依据”反之如果知识库有信息但模型还是乱编说明系统提示词对“必须引用原文”的约束不够强制。我常用的做法是一套组合拳prompt里写明“你的回答必须基于所提供的检索内容禁止使用你自身的知识作为补充引用观点时需标注来源编号”同时在输出环节加一个“后置校验”——让一个轻量模型检查生成文本中事实性断言是否有检索内容支撑无支撑的句子标出来要求模型重写或删除。这一层校验虽然增加一次模型调用但对于面向客户的输出场景价值大于成本。6.4 token成本与延迟开销RAGAgent烧钱怎么办RAGAgent确实比纯调API贵不少。每多一次工具调用就多一次模型往返每多一轮Agent循环就多多次调用。我控制成本的办法有三板斧第一板斧是分流简单问答直接走RAG链路只有复杂任务才启用Agent判断条件是“用户意图中包含多个动作或需要多轮决策”第二板斧是上下文瘦身历史对话摘要保留、工具结果截断、检索结果只保留相关段落而不是完整chunk第三板斧是模型分级重排用轻量模型问答用中等模型只有最终生成报告这类高质量输出才用大模型。这套搭配下来成本能压掉三成左右效果没有明显下降。在实际操作中还有一个细节容易被忽略Agent的每轮循环都会把系统提示词和全部历史累积喂给模型累积到一定轮数后token量会非常夸张。我的习惯是在每轮循环后对stat做一次整理只保留“上一步工具返回给模型之后产生的结论”而不是把工具原文原封不动带回下一步。一点个人经验收尾讲了这么多最后再说一个我自己体会最深的方向。RAG和Agent的组合看起来是技术选型的题目本质上是对业务问题的拆解能力的考验。技术方案再花哨如果你说不清“这个任务需要哪些知识、哪些步骤、哪些判断点”最后落地效果一定很勉强。我个人目前的习惯是接到一个新项目先不碰代码先把任务流程图手绘一遍用户请求从哪里进来、中间需要哪几次知识获取、每次获取的信息喂给哪个环节、哪些环节需要模型自主决策、哪些需要用规则兜底。画完之后再决定采用第一种还是第二种组合方式。正是这个前置动作让我在后面写代码时很少返工也让最终交付的系统可控、可优化、可解释。如果你正准备做类似的事情建议也从最小闭环开始先让RAG能检索出靠谱的结果再让Agent能稳定地调用这个检索工具最后再加复杂度。千万别一上来就照着最复杂的架构图抄作业——先把每一步的输入输出搞清楚比什么都重要。