1. 为什么RAG和Agent组合才是大模型智能体落地的完全体过去两年我见过太多项目把大模型接上API就开始喊“智能体”结果一上线就露馅问点业务细节模型一本正经地编答案让Agent连续执行几步操作中间一卡就彻底跑偏。直到把RAGAgent的架构组合放进系统里这些“看着聪明、用着失控”的问题才真正被解决。所以这篇文章不聊概念只聊大模型知识问答、业务分析、自动执行这些场景下RAG和Agent到底怎么搭在一起才能成为稳定落地的大模型智能体。先给一个我自己的观察结论RAG负责让大模型“知道该说什么”Agent负责让大模型“知道该干什么”。前者解决幻觉和知识陈旧后者解决复杂任务拆解和工具执行。两者不是竞争关系而是同一个智能体的左右手。很多团队把RAG做成了一个“检索后直接回答”的管道又把Agent做成了一堆工具函数的调度器结果两边的能力都没发挥出来。1.1 单独RAG的边界在哪里答案仍然“一次性生成”RAG的全称是检索增强生成标准流程大家都熟把文档切块、向量化存入知识库用户提问后做向量检索再把命中的片段拼进Prompt交给大模型生成答案。这个模式应付“给出一段资料回答一个问题”足够用但它的结构性问题很明显检索次数固定为一轮。用户的问题表述模糊时向量检索很难一次命中问题需要跨多个文档对照时单次检索根本拼不出完整答案如果知识库里没有答案RAG不会主动去查实时接口只会硬着头皮说“根据资料……”。这就像一个资料员只被允许翻一次书就回答翻不到就算编也得把答案说出来。更隐蔽的问题是RAG没有任何“自我检查”机制。模型生成完答案不会回头验证“我引用的这段和用户问的到底匹不匹配”。一旦检索阶段捞回一个语义相似但不相关的片段RAG的整个回答就会被带偏。所以我一直对想直接拿一个裸RAG管道做智能体的朋友说不是RAG没用是它天然缺了“决策”这一层。1.2 Agent补齐了决策能力RAG补齐了事实来源Agent的核心是把一个大目标拆成小步骤循环地决定“下一步调什么工具、观察什么结果”。有了Agent这层检索就不再是被动的一次性动作而成为智能体工具箱里的一个可调用能力查到不够就再查一次结果不对就改写查询词文档不够还可以调外部数据库或API。但Agent单独跑问题同样尖锐它擅长“调动工具”却不擅长“拥有知识”。如果工具返回的是一堆原始数据或者Agent要基于内部规章制度做判断它仍然依赖模型参数里那点训练时记忆。大模型智能体落地最难的一环就是如何让模型在真实业务数据上做推理而不是在训练数据里做“回忆”。把RAG和Agent放在一起等于给智能体装了两套系统一套是事实核查系统一套是任务执行系统。一套主内一套主外。后续所有架构设计本质上都是在回答一个问题这两个系统之间怎么做接口、怎么传状态、怎么避免冲突。2. RAG这一半从知识库到上下文难点不在“存”而在“取”如果把RAGAgent架构比作一个工厂RAG就是原料供应链。供应链出问题后面全线停摆。我做过的几个RAG项目里真正拖后腿的从来不是大模型参数不够大而是检索召回的质量不够高。而检索质量的第一道关卡就是知识切片。2.1 切片不是字数问题是语义完整性问题很多人做知识库切片习惯按固定字数切512字一块、512字一块简单省事。但这样切出来的片段经常把一句话切掉一半把一个表格拆成两截或者把一个业务规则从“前提”和“结论”之间硬生生断开。向量检索到的片段看似相关实际语义支离破碎。我现在的经验是宁可让规则复杂一点也要先保语义完整性。常见做法包括按Markdown标题层级切分比如#、##、### 作为边界按表格、代码块、引用块等富文本结构切分先按段落切再结合embedding模型的最大输入长度做二次合并设置小幅重叠overlap让相邻片段保留上下文过渡。这里有一个经常被忽略的点切片长度直接决定检索精度的天花板。段落越小召回时命中的语义越聚焦但上下文丢失的风险也越大段落越大语义完整了但一个片段里往往塞了多个主题向量表示被“平均化”检索精度反而下降。所以我在实际项目里通常维护两套索引一套用小分段做精准召回一套用大分段做上下文理解检索时混合使用。2.2 检索质量的三道关卡召回、重排、上下文压缩从索引到最终放进Prompt我一般至少经过三道关卡而不是“向量检索一把梭”。第一关是召回。纯向量召回的问题在于它只捕捉语义相似不擅长精确匹配。业务系统里经常出现“订单编号SN20230712”“设备型号M88Pro”这种字符串向量检索大概率分不清相近编号之间的细微差别。所以生产环境里我强烈推荐混合检索向量召回加上BM25关键词召回再把两者结果合并去重。这样既能理解“帮我看看最近哪批设备故障率高”这样的自然语言也能精确匹配“请把PRD-1024这个工单的状态查出来”这样的硬性条件。第二关是重排。混合召回拿回来的候选集可能有20~50条但真正能被Prompt容纳的只有3~5条。直接用向量相似度排序并不理想因为向量相似度和“问答相关性”不是一回事。更可靠的是用一个专门的cross-encoder重排模型把用户问题和每个候选片段拼在一起算一个更精细的相关性分数再按这个分数截断列表。Rerank模型延迟会比普通向量检索高一些但为了最终回答质量这几十毫秒完全值得。第三关是上下文压缩。重排之后拿到的片段仍然可能有冗余直接塞进Prompt既浪费Token又干扰生成。压缩可以做两层第一层做规则过滤比如长度过滤、重复内容过滤、与问题关键词匹配度过低的过滤第二层可以用小模型对片段做摘要或者只截取和问题相关的句子。我一般只在片段质量明显偏低的时候才启用LLM压缩否则它会引入额外延迟。这三道关卡对应的质量指标也很简单召回看Recall重排看Precision最终看Answer Faithfulness。下面这张表是我在项目里常用的检查表阶段核心指标常见问题切片切片完整性、密度切断语义、主题混杂召回RecallK、Hit Rate关键词漏召回、语义偏差重排PrecisionK相似但不相关片段排前面上下文压缩Token节省率、信息保留率摘要丢失关键数字生成Faithfulness、相关性模型不依据上下文作答3. Agent这一半不只是调工具而是用“计划记忆工具”解问题Agent和“调接口”之间有一条明显的分界线调接口是固定流程Agent是由大模型动态决定流程。但动态不等于任意。如果把Agent写成“循环调用大模型直到用户满意”它会在真实系统里制造大量不可控开销。所以做一个能用的Agent至少要设计好三样东西循环方式、工具清单、状态管理。3.1 ReAct循环让模型“边想边查边做”ReAct模式是目前最经典、也最容易实现的Agent决策方式全称是Reason Act。它的核心是让大模型交替输出两样东西推理过程解释为什么接下来要这么做工具调用选择哪个工具、传入什么参数。比如用户问“帮我看看华东区域最近的销售情况并分析环比下降的原因。”Agent在一次循环里会先思考“需要找到华东区域销售数据”然后调用销售数据查询工具拿到数据后继续思考“环比下降需要对比上月数据”再调用对比分析工具最后才会生成结论。整个过程的关键是每一步都建立在前一步的观察结果上。工程上实现ReAct并不难一个简化版的伪代码大概长这样for step in range(max_steps): response llm.act( sys_prompt memory tool_context ) if response.is_final_answer: return response.final_answer tool_result run_tool(response.tool_name, response.tool_args) memory.append(tool_result)看起来简单但这里藏着两个工程重点。第一tool_context必须给得足够结构化让模型清楚知道“有哪些工具、每个工具是干嘛的、参数怎么填”。我见过大量Agent乱调工具原因不是模型笨而是工具描述写得含糊。第二max_steps必须设置上限否则遇到坏分支就是无限死循环。生产环境一般控制在5~8步再多基本说明规划质量出了问题。3.2 工具编排与状态管理LangGraph里真正要设计的东西市面上的Agent框架很多LangChain、LangGraph、LlamaIndex、自研调度器各有各的偏好。但如果你准备做一个有真实业务约束的智能体我建议核心流程不要交给那种“自动迭代到天荒地老”的老式Agent框架而是用好图结构的状态机。这也是LangGraph这类工具的价值所在它把Agent流程显式定义成一张图节点是动作边是条件跳转。举个例子一个“查资料回答问题”的智能体可以设置这样的节点意图识别节点判断问题是简单问答、多跳分析还是需要实时信息RAG检索节点调用知识库检索工具外部工具节点调用数据库、API、业务系统答案生成节点汇总所有上下文生成最终答案验证节点检查生成内容是否基于检索结果。这种图式编排最大的好处是可观测每一步都记录在案出了问题可以直接回放。实时状态里要存什么至少要存用户原始问题、当前目标列表、历史工具调用记录、每步检索回来的上下文、中间推理过程。这些东西合在一起就是Agent的“工作记忆”。没有工作记忆的Agent等于让一个人每次说话都忘掉上一句说过什么。4. Agentic RAG从“检索一次就问”到“检索决策一体化”“Agentic RAG”是最近高频出现的一个词直译是“智能体式RAG”。很多人的第一反应是我是不是已经在前面的架构里完成它了其实没有。Agentic RAG的核心不是“RAG作为Agent的工具”而是检索过程本身也由Agent来驱动和验证。传统RAG里用户问题长什么样检索就用原话去查。但真实世界里用户问题往往是含糊的、口语化的、包含大量指代。Agentic RAG会做更聪明的事改写查询、拆解子问题、判断检索结果是否够用、检索后自我打分。这也正是目前大模型智能体落地最重要的分水岭它是用检索结果辅助生成还是用检索结果参与决策。4.1 智能体如何决定“要不要查、查什么、查几次”第一步是判断“要不要查”。我见过不少系统一上来就检索用户说“你好”也去库里捞一遍纯属浪费。更好的方式是先用一个小分类器或强模型判断这个问题是否需要外部知识如果需要是否有足够上下文直接回答第二步是“查什么”。这个过程通常包含查询改写。用户说“它最近怎么样”“它”指代谁要从对话历史里捞出来“最近”指哪个时间段要转换成可检索的关键词。这部分如果直接用原句检索召回精度惨不忍睹。一个实用的做法是让Agent生成多个检索查询词技术术语用专业名、业务说法用口语名、缩写配全称然后做多查询并行召回。第三步是“查几次”。并不是查一次就能收工。Agentic RAG允许迭代第一次检索结果质量分低就改写再查结果里引用了某个报告编号就再查一次该编号对应的详情多个子问题都检索完成后再汇总成最终答案。这里的核心是设置一个结果质量判断器。早期项目我直接让大模型判断“这些检索结果是否足以回答用户问题”但这样不稳定后来我加了一个规则打分结果与问题的关键词覆盖率、结果数量、重排分数阈值三者结合比单一模型判断可靠得多。4.2 多路召回与问题分解让复杂问题被拆着解决多数企业的知识不止一份文档而是散落在规范手册、工单系统、数据库、产品源码里。Agentic RAG在接这些资料时会把检索入口做成分支工具向量知识库适合非结构化文档、规章制度、产品说明关系型数据库适合订单、库存、用户信息这类结构化事实搜索引擎/内部Wiki适合比较新的、频繁更新的内容融合检索入口同时查多个来源再合并结果。多路召回解决的是“资料在哪”的问题问题分解解决的是“复杂问题怎么查”的问题。拿一个典型场景举例“对比去年和今年新品发布后首月的用户投诉找出事故率上升的主要原因。”这个问题没法一次检索完成Agent会把目标分解成三个子问题去年发布的新品有哪些上市首月投诉量是多少今年发布的新品有哪些上市首月投诉量是多少投诉量上升对应的品类和故障模式是什么。每个子问题各自走一次检索或工具调用然后把结果拼起来做归因。这个过程像极了一个资深分析师的实际工作不急着给结论先拆问题、找数据、交叉验证。而Agentic RAG的架构目标就是把这种行为模式固化到系统里。5. 架构选型与组件搭配一份可以直接抄的落地清单聊完原理到落地阶段大家最头疼的还是选型。我在技术方案评审会上被问得最多的一句话是“我这场景到底要不要上Agent”我的答案经常让人意外能不上就先别上除非传统RAG确实兜不住。5.1 明确要用传统RAG还是Agentic RAG延迟、成本、稳定性这三项是架构决策的底座。Agent每多一轮决策就多一次大模型调用延迟和成本同步上涨。所以在设计初始先给业务需求分层。业务场景推荐架构理由“这个文件里有没有相关规定”传统RAG单轮检索即可Agent纯属浪费“帮我查一下合同编号对应的关键条款并解释”传统RAG 结构化解析一次检索加一个工具调用足够“对比多个文档中的价格、参数和责任条款差异”Agentic RAG需要多跳检索和交叉验证“根据用户投诉日志分析故障趋势并定位根因”Agentic RAG 多工具需要查库、聚合、归因多步骤“自动发起一个审批流程并填单”Agent 外部工具RAG不是重点重点是流程正确性这个表是我在多次项目里总结出的判断框架。核心标准只有一条问题能否在“一次检索一次生成”内解决。不能再引入Agent。很多团队把Agent做成全场标配最后发现80%的请求根本没用到推理决策只让延迟白白涨了几倍。5.2 技术栈选型向量库、框架、模型的匹配逻辑如果确定要做Agentic RAG技术栈怎么搭我按层来拆向量存储知识规模小就选轻量方案比如pgvector规模上千万条、对查询性能敏感再考虑Milvus或Qdrant如果团队已经重度使用Elasticsearch直接走ES的kNNBM25混合检索也足够没必要额外维护一套向量库。RAG流程框架LangChain生态最成熟但历史包袱重只用它做数据处理和工具调用没问题如果流程复杂度高我推荐LangGraph这类按图编排的方案因为它把可观测性做进了状态管理里。工具接入标准现在越来越多人谈MCP它本质上是一个让智能体调用外部工具的统一协议。如果你有多个业务系统需要接入AgentMCP能省掉大量“一个系统写一套适配器”的重复工作。它是RAG之外的另一根管道解决的是工具生态互通问题。模型组合问答生成用大参数模型查询改写、意图分类可以用较小但速度快的模型重排单独用cross-encoder。不用所有环节都堆最强的模型成本经不起这么烧。我对自研框架的态度是除非你们团队的场景非常特殊、现有框架无法表达否则不要从零写调度器。LangGraph这类框架已经把状态持久化、条件跳转、人工干预这些能力封装好了直接在上面约束业务规则比自研一套稳定得多。6. 落地过程中的性能、成本与可靠性治理架构设计得再漂亮进了生产环境都会原形毕露。RAGAgent系统的最大矛盾是Agent能力的上限越高中间过程的不可控性就越高。所以治理层必须从第一天就设计进去而不是等出现了上百万Token消耗才发现。6.1 延迟优化不是所有查询都要走完整智能体循环Agentic RAG的完整流程确实贵一步意图识别、两步查询改写、几次检索、若干次工具调用、一轮生成验证总耗时奔着10秒去很正常。但真实用户没有那么大的耐心。我常用的降延迟手段是快速通道先做一次轻量意图分类把明显是简单问答的请求引导到传统RAG管道不走Agent在路由上加规则问题长度小于一定阈值、没有“对比”“分析”“为什么”这类词默认走快速通道对热点问题加缓存命中缓存的直接返回历史答案连检索都省了。快速通道之外还要控制Agent内部循环的步数。我建议把max_iterations设成硬上限并在Prompt里写清楚“如果第N轮还没有解决问题就基于已有上下文给出一个带明确前提的回答。”这样做不是降低质量而是避免让用户面对一个无限转圈又什么都答不出来的智能体。6.2 成本控制与评测ROI和数据指标缺一不可Token成本和业务价值之间必须用评测数据来对齐。做RAGAgent项目我至少要维护三类数据集检索评测集标注每个问题应该召回哪几个文档片段生成评测集标注标准答案评测答案相关性、忠实度Agent流程测试集记录每一步工具调用是否合理、最终是否成功完成任务。有了这三类数据集才可能在一次Agent版本升级时说出“检索召回率提高了5个点但最终答案忠实度降了2个点问题出在上下文压缩那一步”。没有评测数据支撑的Agent优化基本就是调Prompt玄学。成本治理的核心是给Agent的每一步调用建账。我习惯在日志系统里记录每次请求消耗了多少Token、调了几次模型、几次向量检索、几次外部API。最后用一张简单的成本分布表来定位瓶颈是意图分类调用太多还是重排太频繁还是Agent反复检索失败。大多数情况下成本都能靠减少无效检索来回收而不是一味换便宜模型。7. 实践中的坑我踩过的几个具体问题与解决思路前面说的都是框架层面最后聊几个真实项目里让我印象深刻的坑。这些细节在技术文档里基本不会写但每一个我都花过不止一个通宵去解决。7.1 检索到的无关片段比不检索更伤输出早期做一个企业内部知识问答系统时我发现一个诡异现象给模型提供两个不相关但语义沾边的片段模型往往不会说“资料不足”而是会自信地把两个片段强行关联起来生成一个看似完整、实则虚构的答案。对比实验里不提供上下文时模型反而会坦诚说不知道。后来我总结出一套处理方案第一检索后必须经过重排和阈值过滤分数低于阈值的片段宁可舍弃也不要塞进Prompt第二Prompt里明确加一句“如果提供的资料与问题不相关请直接说明无法回答”第三在生成阶段要求模型输出引用来源编号并让验证节点检查引用的片段是否真的支持结论。这一步在Agent架构里尤其重要因为Agent比裸RAG更容易把“背景资料”误当成“答案依据”。7.2 工具权限过大导致智能体乱飞有一次做自动化运维助手给Agent暴露了一个“执行SOP脚本”的工具。测试时原意是让它读脚本、解释脚本结果模型在一次推理中判断“需要实际运行一遍来验证结果”然后真的把脚本执行了。幸好是在沙箱环境没有造成线上影响但这件事让我彻底意识到Agent的工具调用能力必须最小化授权。现在的做法是给工具加两层防护第一层工具权限按角色区分只读工具直接可调写操作和外部动作必须走人工审批节点第二层在工具定义的描述里写清楚使用边界例如“该工具只能用于查询状态不能执行任何变更操作”。此外还会在Agent循环里加一个独立的“安全校验节点”在模型调用敏感工具前自动拦截。7.3 知识更新不是“重训模型”而是索引与缓存的联动做RAGAgent之后业务方最爱问的问题是“我们改了制度文档模型什么时候能学会”答案是模型不用重新训练但你的索引和缓存必须一起更新。RAG这一步就是这么设计的删除旧文档对应的向量切片写入新文档的向量切片旧答案缓存立即失效让下一次查询强制走新索引。我建议在这个环节做版本管理给每条知识打上生效时间区间检索时把时效条件作为过滤项。Agent在做RAG检索时也应该把“当前知识版本”放到上下文里防止模型引用已经下线的旧规定。曾经有个团队上线新制度后忘了清缓存用户提问时模型还念着三个月前的老版本原因就是缓存里的Prompt旧样本没失效。这类问题听起来低级但真的就藏在上线流程里。如果让我给RAGAgent架构定一条最重要的经验我会说架构本身不是目的让智能体在真实业务里稳定地“知道该说什么、该干什么”才是目的。RAG保证它有据可依Agent保证它有章可循。把这条主线想清楚了剩下的选型、调优、踩坑都不过是这条主线上的具体修补而已。
