这个系列写到第9篇今天想聊一个被问得最多、也最容易被搞混的话题RAG和Agent到底什么关系做Agent架构这几年我最大的感触是市面上至少有一半号称“Agent”的系统本质上是披着Agent外衣的RAG反过来也有不少团队在只需要检索增强的场景里硬造一个Agent结果成本和延迟都炸了。检索增强与行动决策这两条技术路线到底怎么融合、边界划在哪就是这篇文章要解决的问题。如果你是刚接触Agent开发的工程师或者正在纠结团队的项目到底该上RAG还是Agent这篇文章应该能帮你把判断框架搭起来。1. 先搞清楚RAG的本质它是知识供应链不是问答工具箱1.1 RAG要解决的真问题事实锚定与知识外挂RAGRetrieval-Augmented Generation检索增强生成这几年被讲烂了但绝大多数团队对它的理解停留在“哎呀就是先从知识库里搜点相关内容然后拼进prompt里让模型回答”。这个理解不算错但忽略了一个根本问题——RAG的本质是给LLM搭一条知识供应链而不是简单地“搜一搜、拼一拼”。为什么这么说因为LLM有两个天生的毛病一是知识截止训练完之后世界还在变它不知道今天发生了什么二是幻觉凡是它没有把握的内容它倾向于一本正经地编。RAG的思路就是用外部知识库把模型的能力“锚定”在真实事实上让模型的每一个回答都有据可查。所以RAG的核心价值不只是“检索”这个动作本身更是“用检索结果约束生成过程”。中间任何一环出了问题——切分不合理、向量化失真、召回跑偏、排序漏检、拼装超限——最后生成的答案都会偏离事实。这也是为什么很多团队吐槽“我明明搭了RAG怎么还是胡说八道”大概率不是模型的问题而是供应链的某个环节断了。1.2 经典RAG链路每一步的取舍标准的RAG可以拆成两条链路索引链路即离线把文档加载、清洗、切分、向量化、存入向量库问答链路即在线把用户问题改写、召回、重排、拼装prompt、生成答案。里面最大的坑在切分chunking。切分粒度直接决定召回质量切大了一个chunk里塞了太多无关信息向量检索很容易跑偏切小了上下文语义被切断召回回来也是一堆碎片。我一般会按语义边界切分用标题、段落、空行做标记chunk控制在300到500个token之间同时保留20到50个token的overlap。这个参数没有绝对最优但它是一个起步经验值先用起来再按效果调。向量化同样别小看。用通用embedding模型比如bge-m3或者OpenAI的text-embedding-3跑一遍召回效果勉强能看但行业术语多的场景通用模型的表现会明显下降。我自己踩过的坑是在技术文档场景里通用embedding对“API、SDK、中间件”这类词的相似度判断经常出错后来在领域语料上做了微调hit rate检索命中率从58%涨到了79%这个提升立竿见影。问答链路还有一个容易被忽略的环节重排rerank。很多团队把“召回”当成终点其实召回出来的top 5到top 10里往往混着大量不相关片段直接全部塞给模型会稀释注意力。我的做法是召回之后加一道cross-encoder重排把候选集重新打分只保留真正和问题相关的3到5条进上下文。这一步对最终答案质量的提升往往比换一个更强的embedding模型还要明显。1.3 RAG的三个软肋检索不到、检索到但没用上、检索到也用错了聊完了链路我再泼点冷水。RAG有三类典型的失败模式几乎每个生产环境里的RAG系统都中过招。第一类检索不到。知识库里根本没有相关内容或者有但embedding距离太远召不回来。前者是知识覆盖率问题后者是检索质量问题的解法是补数据、优化切分、做查询改写。有一个技巧叫“多查询生成”multi-query让模型把原始问题改写成几个不同表述的子问题分头检索再合并结果能明显提升recall。第二类检索到了但模型没用上。这是最隐蔽的坑。很多case是上下文里明明有正确答案但模型还是凭自己的“记忆”回答。原因可能是给的上下文太多关键信息被淹没也可能是prompt里没强调“答案必须基于给定上下文”。我的做法是在prompt里加一条硬性约束“不允许使用外部知识只能依据提供的参考片段回答如果参考片段不足以回答问题直接说不知道。”第三类检索到了模型也用了但用错了。参考片段自相矛盾或者片段本身信息过时模型无法判断。这种问题要靠引用溯源来解决强制模型在输出中标注答案对应的来源段落再由下游校验环节检查答案和引用是否一致。这恰恰是GraphRAG、Ontology RAG这类方案想要在知识组织层面缓解的问题——光靠向量距离确实解决不了语义组织和时效判断。2. Agent的底牌行动决策的本质是闭环2.1 感知-决策-行动-观察Agent的最小循环Agent这个词被炒得很热但从架构师角度看Agent的本质只有一个闭环。一个真正的Agent系统必须包含感知Perception、决策Decision、行动Action、观察Observation四个环节并且这个循环是可重复的。拿一个最简单的例子说明让模型帮用户查“我现在适合穿什么”。RAG的做法是检索天气数据生成穿搭建议结束。Agent的做法是调用天气API拿到温度湿度判断是否需要补充紫外线指数再调用一个紫外线API综合分析给出建议。如果用户追问“那我晚上跑步要不要戴帽子”Agent要能感知到这个新意图再次行动。差别在哪差别在于Agent的每一步行动都在改变状态而状态的改变又会影响下一步决策。这是闭环和单次检索的本质区别。这也是吴恩达那套著名的Agent教程里反复强调的点workflow是编排好的固定流程Agent是模型自主决定流程。RAG本质上是一种workflow先检索、再生成路径是确定的。Agent则允许模型自己去选择“要不要检索、检索什么、检索完了干什么、要不要再检索一次”。2.2 ReAct与Plan-and-Execute两种主流的行动决策模式Agent的行动决策循环目前主流实现有两种。第一种是ReActReasoning Acting它把推理和行动交织在一起模型先思考再决定调用什么工具拿到工具结果后继续思考如此循环直到问题解决。这是最接近“人怎么干活”的模式适合开放性强、步骤不确定的任务。第二种是Plan-and-Execute模型先把整个任务拆成子任务清单然后按清单逐一执行执行过程中可以做局部调整。这种方式的好处是规划清晰、可观测性好、每一步的输入输出都能审计适合流程相对固定的场景比如“先查库存、再算价格、最后生成报价单”。我的经验是能上Plan-and-Execute就别急着上ReAct。ReAct虽然灵活但自由度越高跑偏的概率越大而且每多一轮循环就多一次大模型调用成本和时间都是指数级上升。中小型团队做Agent落地先固定流程、再逐步放开自主决策是性价比最高的路径。2.3 RAG和Agent的本质差异回答“是什么”与解决“怎么办”把RAG和Agent放在一张表里对比差异一下子就清楚了。维度RAGAgent输入问题目标输出答案文本一系列已执行的动作及结果核心动作检索 生成感知 决策 行动 观察评估标准答案准确性、引用忠实度任务完成率、工具调用成功率、路径效率流程确定性固定workflow模型自主决策失败模式答错、漏答、幻觉路径跑偏、执行中断、状态丢失还有一个更本质的差异RAG是被动的、一次性的信息请求Agent是主动的、多轮的行动主体。前者是“问路”你告诉我怎么走后者是“走路”你自己走到终点路上还要绕过堵车和死胡同。这里顺带说明一下“Agentic RAG”这个词。它指的就是把检索能力嵌入到Agent的行动循环里让模型自己决定什么时候去查知识库、查完能不能信、要不要换个词再查。检索不再是“给定的第一步”而是Agent的工具箱里的一件工具。这就是后面要讲的融合形态。3. 从RAG到Agent的三条进化路线3.1 路线一工具增强的RAG——给检索结果加“后手”第一条路线最保守也最容易落地在标准RAG后面挂上工具调用能力。典型形态是“先检索、生成如果生成的内容需要实时数据再调用API补充重新生成”。这种形态下检索仍然是被动触发的但生成过程多了一个“补数据”的动作。比如用户问“我们公司上个月的销售数据怎么样”RAG只能检索到销售制度文档无法拿到真实报表。这时候可以设计一个工具调用步骤模型识别出“需要查数据”的意图调用SQL查询工具拿真实数据再结合检索到的制度文档生成分析。我见过不少团队把这种形态直接叫“Agent”但从架构上看它只是RAG的增强版。核心判断标准是模型的决策空间里有没有“要不要调用工具、调用哪个工具、调完怎么办”的自由度。如果流程是预先写死的那它就是workflow不是Agent。workflow不可怕但叫错名字会让你对系统的预期和投入完全跑偏。3.2 路线二Agentic RAG——检索变成行动循环里的一个动作第二条路线是真正的质变Agentic RAG。在这种架构里检索模块不再是管线里固定的一环而是被封装成一个可以被LLM动态调用的工具。模型根据用户问题自行决定是先检索还是先问用户澄清是检索一次还是检索多次是直接回答还是检索完再调用别的工具。这里有几个典型的落地范式值得记住。一个是Self-RAG模型在生成过程中自我反思当前知识够不够需不需要再检索检索结果和已有上下文冲突吗另一个是Adaptive RAG先用一个分类器判断问题类型简单问题直接生成难问题走检索复杂多步问题走完整的Agent循环。还有一个是Corrective RAGCRAG它对检索结果做质量评估如果评测不过关就触发“重写查询再检索”或“用其他来源兜底”的逻辑。这些范式的共同点是“检索意图”的决策权从架构师手里移交给了模型。架构师不再写死“每次必查知识库”而是让模型根据实际情况决定。这个转变看着不大但对系统设计的影响是全方位的——检索频次、上下文管理、失败恢复机制都要重新设计。3.3 路线三GraphRAG与结构化检索——知识组织层面的升级第三条路线不是从“流程”上进化而是从“知识组织”上进化的。GraphRAG把文档里的实体和关系抽取出来构成知识图谱检索时先定位实体再沿着关系扩散最后把图谱子图喂给模型。Ontology RAG更进一步用本体定义领域概念和逻辑关系让检索结果天然具有结构性和一致性。我为什么在讲RAG到Agent进化时专门提GraphRAG因为当Agent的行动需要处理复杂多跳知识时纯向量检索根本不够用。举个例子Agent要回答“A部门的离职率上升对B项目的交付风险有什么影响”这个问题的答案散布在多份文档里涉及人事、项目、财务三类数据。向量检索召回的可能只是零散句子但GraphRAG可以把“部门-员工-项目-风险”这条关系链整段捞出来Agent拿到手就是一张可以直接推理的关系图。所以在真正的Agent系统里检索层往往不是单一的向量检索而是“向量检索 关键词检索 图谱检索 规则引擎”的混合体由决策层统一调度。这也是我建议做Agent架构师的同行别只会用向量库得对ES、Neo4j这类传统组件也有实操经验。知识层的功底决定了Agent行动的天花板。4. 融合的边界什么场景用RAG什么场景必须上Agent4.1 判断标准一任务是否可以用单个回答终结这是最直觉也最好用的判断标准——用户的问题是否可以通过“给定一段上下文生成一个答案”来终结。如果能那就是RAG的活。比如“报销流程是什么”“某某接口的返回字段有哪些”这类事实型问题一次检索一次生成就能解决上Agent纯属浪费。反过来如果用户的问题天然需要“多步操作”比如“帮我整理一份竞品分析报告并发送到邮箱”单靠RAG永远答不完整——因为它只能生成报告生成不了“发送邮箱”这个动作。这种任务的目标不是“生成一段答案”而是“达成一个状态改变”Agent是唯一的选择。我自己的经验法则是把任务描述写下来逐字检查动词。如果动词是“查询、解释、描述、列举”用RAG如果动词是“对比、计划、执行、修改、通知、监控”大概率需要Agent。4.2 判断标准二系统是否存在外部状态和环境RAG的世界里只有两个东西问题和答案。Agent的世界里至少有三个目标、工具和环境。外部环境的存在是Agent架构的硬门槛——如果这个系统不用碰数据库、不用调API、不用操作文件、不用发通知那它就没有“环境”可以交互Agent的行动闭环根本转不起来。拿客服机器人举例。如果它只能回答“物流多久能到”“退换货政策是什么”那是RAG如果它能查真实订单物流、能提交退换货工单、能根据用户历史订单推荐补偿方案那它就是Agent。判断的核心是你的系统里有没有“用户不可见但系统需要修改”的状态4.3 判断标准三结果是否可以被客观评估这个标准常常被忽略但它决定了系统能不能健康地演进。RAG的输出是“答案文本”可以用引用准确性、忠实度等指标来客观评估Agent的输出是“任务结果 过程轨迹”评估维度更多任务成功率、工具调用成功率、步数、成本、耗时。如果团队还没有建立Agent的评估体系我劝你不要贸然上Agent。因为Agent系统的最大风险不是“答错”而是“在你看不见的地方跑偏”——模型自己规划了一条路径执行了半天你的评估体系却看不出来哪里出了问题。RAG答错了看一眼输出就知道Agent悄悄把所有工具调了一遍然后返回一句“无法完成”你连失败原因都要翻半天trace。没有评估体系就上Agent等于在没有仪表盘的飞机上起飞。4.4 边界灰度区与误用代价现实里的需求往往落在灰度区。比如“用户问了一个开放性的技术问题需要结合多份文档推理出一条解决方案”单轮RAG回答不了但也未必需要完整Agent。我的建议是先用轻量策略过渡——查询改写、多轮对话历史上下文增强、检索结果的二次重排这些都能显著提升RAG的处理能力。只有确认任务真的需要“执行动作”或者“动态决策”时才升级到Agent。误用的代价是真金白银。某次项目里团队把本可以用RAG解决的文档问答硬做成了Agent每个问题平均要跑4到6轮LLM循环一次对话的成本是RAG方案的8到10倍响应时间从2秒飙升到15秒以上。更要命的是因为Agent每一步都可能出错链条越长出错概率越大整体成功率反而比RAG更低。所以我的结论一直很明确RAG能解决的问题不要用Agent解决Agent只解决那些“必须通过行动才能达成目标”的问题。这条边界虽然模糊但值得每一个架构师认真对待。5. 实战拆解一个“检索增强行动决策”的融合系统5.1 场景定义与目标光讲理论没有感觉我来拆一个自己做过并且验证过的系统设计。场景是某企业内部的数据运营助手。目标用户是运营、产品、管理层他们的问题是混合型的——既有事实查询“报销制度是什么”也有行动需求“把上周各渠道的转化率拉出来对比上个月分析变化原因生成一份报告并发送到指定邮箱”。这个场景是RAG和Agent融合的典型代表事实查询用RAG行动需求用Agent。我要把两者放进同一个系统并且让它们共用一套检索基础设施。听起来简单但真正的工程难点在于“接口设计和状态管理”。5.2 系统分层与数据流我把系统拆成四层。接入层负责意图识别和路由用一个轻量分类器或者让主模型自己判断当前请求走RAG直答还是Agent循环这是整个系统的分流阀。检索层统一封装成检索服务内部混用向量检索、BM25关键词检索和图谱检索任何上层模块想拿知识都调这个服务的同一个接口。决策行动层就是Agent的ReAct循环所有工具SQL执行器、报告生成器、邮件发送器、日历查询器都注册成标准化工具。校验与兜底层对Agent每步输出做格式校验和内容校验失败自动重试或降级。数据流是这样的用户请求进来接入层路由。如果是事实查询直接从检索层拿知识拼prompt生成答案如果是行动需求进入Agent循环Agent在循环中按需调用检索服务、SQL工具、报告工具等每完成一步就把结果写入会话状态最终生成报告并通过邮件工具发送。关键设计在于检索服务对于RAG路径和Agent路径是同一个服务但不同出口——RAG出口直接拼contextAgent出口作为工具返回值进入模型的下一次推理。这样既保证了知识的一致性又让Agent拥有检索的自主权。5.3 检索层与决策层的接口协议这个接口协议是我们踩了很多坑之后沉淀下来的。检索服务对外暴露的接口返回结果不能只是一堆文本片段而要有结构化字段{ query: 原始查询, rewritten_queries: [改写后的子查询1, 子查询2], results: [ { doc_id: doc_001, chunk_id: chunk_003, content: 片段文本, source: 文档标题/URL, score: 0.87, rerank_score: 0.92, metadata: {updated_at: 2025-03-01, author: 张三} } ], retrieval_strategy: hybridrerank, total_hits: 12 }为什么要结构化成这样因为Agent的决策需要看到的不只是“片段内容”还有评分、来源、时间戳。模型要判断“这个信息是不是过时了”就得看metadata里的更新时间要判断“要不要换一种方式再检索”就得看total_hits和score。RAG直答的时候只需要content但Agent路径必须把决策所需的全部元信息暴露给模型否则它就是在盲人摸象。还有一个细节接口要支持根据doc_id过滤和按时间范围过滤。Agent在检索后如果发现结果全是旧文档可以重新发起带时间过滤的检索这个能力在纯RAG里基本不会用到但在Agent里是刚需。5.4 记忆与工具的组织方式融合系统的记忆设计要比纯RAG复杂得多。纯RAG的记忆就是对话历史用于多轮上下文而Agent需要三种记忆会话记忆当前对话的短期状态、长期记忆用户偏好、历史任务结论、工作记忆当前任务循环中已经执行过的步骤和结果。我建议把工作记忆显式地做成一张“任务状态表”每一步Agent的行为——调用了什么工具、输入是什么、输出是什么、结论是什么——都写入状态表。这样做有三个好处一是模型在下一次推理时不需要把全部历史又输一遍只读状态表的关键字段即可二是排查问题非常方便打开状态表就能看到Agent从头到尾干了什么三是为“记忆压缩”打基础当状态表太长时提取摘要替代原始记录进入上下文。工具组织方面不要一股脑把所有工具都塞给模型。工具越多模型选错的概率越大。我通常会按场景分组数据分析组SQL执行、指标查询、内容生成组报告生成、摘要、通信组邮件发送、IM通知每次对话根据路由结果只加载相关组的工具描述。实测下来工具选择准确率能提升10到15个百分点。5.5 失败恢复与兜底策略融合系统最怕的是“执行到一半崩了”。我见过最典型的情况Agent在第三步调SQL工具时字段名写错了工具返回报错信息Agent尝试修正一次还是错结果就直接放弃返回一句“无法完成”。这对用户来说是灾难。我的兜底策略是三层防线。第一层工具调用重试让模型根据错误信息修正参数最多重试2次重试要带上下文告诉它上次错在哪。第二层任务降级如果SQL执行始终失败Agent可以退化为“只做能做的部分”——比如生成一份含查询语句草稿的报告标注“数据未获取以下为待执行查询”而不是直接放弃。第三层人工接管如果前两层都失败把当前状态表完整打包给人工客服或开发同学带着上下文接手而不是让用户重新描述一遍。这套兜底做下来Agent的有效完成率从67%提到了89%剩下的11%也都有可追踪的失败上下文不会变成黑盒。核心思路就一句话永远给Agent留一条“体面退出”的路别让它卡死在半路。6. 给Agent架构师的几条硬建议从0出发少走弯路6.1 先画数据流再画架构图这个系列写到第9篇我反复说的一句话就是画架构图之前先画数据流。很多同行上来就画“用户到网关到Agent到工具到数据库”这种拓扑图画完自我感觉良好一上线就发现数据流断了。RAG到Agent的融合系统尤其如此你要先回答清楚知识从哪来、检索结果流向哪、Agent每一步的状态写在哪、失败信息往哪传。数据流画清楚了拓扑图自然就出来了。我在做前面那个数据运营助手时第一版架构图画了三版都不满意后来换了个思路把每次请求的完整数据流写成一条时间线从用户输入、意图识别、检索、Agent行动、工具执行到输出每一步的数据形态都标注出来。这一下子发现了两个本来要上线才会暴露的问题一是SQL工具的结果没有格式化就传给模型二是检索服务在Agent循环中会被重复初始化。数据流提前帮我把这些坑填掉了。6.2 检索质量的三件套评测指标不管是纯RAG还是融合系统检索质量都是地基。我建议团队固定盯三个指标hit rate检索命中率指正确答案是否出现在召回结果中、MRR平均倒数排名衡量正确答案的排位、faithfulness生成答案对检索片段的忠实度。前两个衡量“检没检到”第三个衡量“用没用对”。我们的实践是每两周跑一次评测集回归评测集里放200到300条真实用户问题和对应的标准答案。每次改动检索策略——换embedding、调整chunk、加rerank——都拿评测集说话。没有评测集就调参等于闭眼开车。另外多说一句hit rate这个指标最近在RAG社区讨论很多它是比单看top1准确率更稳健的指标因为它只关心“正确答案有没有在候选集里”至于能不能被模型选中那是faithfulness和prompt的范畴。6.3 可观测性是融合系统的生命线Agent系统的可观测性比任何传统后端系统都重要。原因很简单Agent的每一条路径都可能不一样你没法靠“固定日志”去复现问题。我的做法是给每一步都打上结构化trace请求ID、路由决策RAG还是Agent、检索服务的查询和结果top5、Agent每一轮的ThoughtActionObservation、工具调用的输入输出、耗时、token消耗。有了这些trace线上出问题的时候我可以直接定位到“第4轮循环里模型选择了错误的工具”而不是像无头苍蝇一样翻日志。LangSmith和Langfuse这类工具对LLM应用的trace支持已经很成熟了自己搭一套也不是不行但成本高得多。我强烈建议任何上生产的融合系统第一步就是接trace而不是接监控告警。6.4 边界不是常量它是随能力演进的变量最后想提醒同行们RAG和Agent的边界不是一成不变的。随着模型能力的增强以前需要Agent多步规划才能解决的问题可能未来的单次推理就能完成以前检索不到的知识可能因为embedding模型升级而变得可以召回了。所以不要把自己的架构焊死在“这里是RAG、那里是Agent”的分界线上。我的做法是每季度做一次“边界复审”用最新的模型跑一遍评测集看看哪些原本走Agent的任务可以降级为RAG哪些原本走RAG的任务暴露出了需要行动能力的问题。架构设计永远是为当前能力服务的留好扩展点比追求一步到位重要得多。换句话说你画的RAG和Agent的分界线本质上是“当前模型能力曲线”的投影能力一变分界线就要跟着动。最后说点个人的体会。我最早做RAG的时候觉得检索就是一切后来做Agent又差点把一切问题都往Agent上套。折腾了两年现在的判断标准反倒朴素了先问用户到底要什么再问系统到底要动什么。RAG负责让模型知道Agent负责让系统做到两者从来不是竞争关系而是同一件事的两个阶段。如果这篇文章能给同行们一个参考系让你在评审会上能理直气壮地说出“这个需求其实用RAG就够了”或者“这个目标必须靠Agent闭环”那就没白写。下一篇文章我打算聊聊Agent的评估体系怎么从零搭建那是让整个闭环真正可信的前提。