如果你最近在做大模型应用“RAG”和“Agent”这两个词多半已经听得耳朵起茧了。行业里一会儿说RAG是解决幻觉的标配一会儿说Agent才是大模型落地的终极形态还有人在吵“Agentic RAG”听得人晕头转向。真正动手搭过一遍之后你会发现这二者的关系根本不是二选一而是RAG给Agent喂知识、Agent给RAG定策略——只有把它们当成一套组合架构来设计才能让大模型智能体在真实业务里站得住脚。这篇内容就是奔着实操去的。我尽量从工程视角拆清楚RAG的检索增强到底在解决什么问题Agent的规划决策能力边界在哪里两者怎么分工、怎么衔接、怎么配置参数、怎么避开我实际踩过的坑。适合正在做智能客服、知识库问答、行业助手这类项目的同学也适合想从“demo能跑”进阶到“上线能扛”的团队参考。1. 先搞清楚RAG、Agent各自解决什么问题1.1 RAG不是“词向量匹配”而是知识管线我在不少项目评审会上见过同一个误区以为RAG就是把文档切碎、转向量、塞进向量库然后用cosine算个相似度召回几段文本拼进提示词。这个描述顶多算“embedding搜索”真正的RAG是一条完整的知识处理管线它包含文档解析、结构识别、语义切块、向量化、索引构建、召回策略、重排序、上下文压缩等多个环节。它的核心目标就一个让大模型在回答时能拿到与其问题真正相关的私有知识片段。单说召回这一步就有纯向量检索、稠密检索、稀疏检索BM25、混合检索、父子分块召回、基于图结构的召回等不同流派。大多数生产级系统最终选的都不是单一向量召回而是结合关键词和向量的混合方案再用一个重排模型把两条路径的结果重新排序。只靠向量相似度在很多垂直领域里会栽在“语义相近但答案不同”的场景上比如法律条文和产品手册写的是同一件事的不同侧面向量距离很近语义却是两码事。所以判断RAG做得好不好看的不是向量库选得有多高级而是整条链路在召回率、准确率、延迟这三个维度上能不能同时满足业务要求。这也是后面所有参数调整的出发点。1.2 Agent的核心是循环决策不是“一个按钮”再看Agent。有段时间网上流行把任何带工具调用的接口都叫“Agent”这不准确。我理解Agent的本质是一个能够感知环境、做出决策、执行动作、观察结果再修正策略的循环系统。大模型在Agent里不只是一个文本生成器而是充当了一个“推理核心”它读当前状态判断下一步该做什么调用某个工具拿到结果后评估是否达到目标没达到就继续拆解新的动作。这个循环在工程上通常是ReAct模式或者Plan-and-Execute模式。ReAct把“想一步做一步”串起来适合交互性强的任务Plan-and-Execute先让模型输出一份计划再逐步执行适合任务边界比较清晰、执行步骤较长的场景。Agent单独用起来最大的问题在于知识来源不可控。你让模型调工具、查数据库、做运算它都可以胜任但一旦面对开放域问题——比如“我们公司这个季度的退款政策是什么”——它没有稳定可靠的知识来源就只能凭记忆生成。大模型的记忆是参数化的、模糊的、会过时的这在很多业务场景里是不可接受的。于是Agent需要一个外挂的知识底座这就是RAG在组合架构里的第一价值。2. 为什么必须组合单用RAG和单用Agent都走不远2.1 RAG单飞时遇到的三个坎RAG单独做知识问答能解决不少问题但做到深入阶段会碰到几个很麻烦的坎。第一个坎是问题意图不确定。用户提问往往是模糊的“这个功能怎么收费”——这句话没说是哪个产品线、哪个套餐、在什么时间范围内。你要召回知识先得搞清楚用户指什么。传统RAG的做法是硬匹配召回一堆类型混杂的段落回答质量完全看运气。第二个坎是多跳问题处理不了。“我想比较A产品企业版和B产品旗舰版在数据导出方面的差异”——这个问题没法用一段文本直接回答必须先定位两个产品的对应章节分别取出关键信息再做比较。单纯的一次性“检索-生成”流程做不了这件事它天然需要多次检索、多次判断、按需归并。第三个坎是格式生成受限。业务场景经常要求答案不是一段话而是表格、JSON、对比清单、操作流程。RAG的生成环节通常只是把召回内容填进Prompt它没有能力去设计和执行多步骤输出方案。这几个坎的本质是RAG解决了“模型不知道”的问题但没解决“不知道该怎么一步步解决问题”的问题。而这一步恰恰是Agent的强项。2.2 组合架构的本质记忆系统 决策系统把RAG和Agent组合起来我看到的最合理框架是分层设计RAG是模型的长期记忆系统Agent是模型的决策与运动系统。长期记忆系统负责回答“事实是什么”。它对用户的知识库、私有文档、业务数据进行切片和索引每次模型需要事实依据时就从这个外部存储器里把相关信息捞出来喂给模型。Agent把RAG封装成“可调用的知识工具”当对话中出现不确定、需要事实支撑的问题时Agent会自动决定是否调用检索工具。决策系统负责回答“下一步做什么”。比如用户问“给我写一份周报并总结本周KPI变化”Agent会先规划第一步生成周报框架第二步检索KPI系统中的数据第三步查团队文档里本周重点事项第四步聚合输出。RAG不是这个过程的全部而是其中一个或几个步骤背后的数据来源。还有个细节值得单独说网上经常把RAG和MCP放在一起比这其实不是一个维度的东西。MCP模型上下文协议解决的是Agent怎么连接外部工具、怎么标准化调用接口的问题RAG解决的是怎么把知识以可检索的形式喂给模型的问题。它们可以在同一个系统里共存MCP负责工具调用协议RAG负责知识检索服务Agent在上层按需协调。把记忆和决策分开设计工程上有个显著的好处两边可以独立优化和迭代。知识文档变了只动RAG配置任务流程变了只动Agent编排不会牵一发而动全身。3. 落地四步走检索配置、Agent编排、评测、上线3.1 第一步切块参数别照搬模板我见过太多团队第一步就“抄作业”看到教程里说chunk_size500, overlap50就直接套进去结果文档全是表格和代码片段切出来要么把代码腰斩要么把表格拆得没法看。切块的本质是找到“语义完整性的最小单位”。一段文本被切开后每一块仍然应该能在脱离上下文的情况下独立表达一个相对完整的意思。所以参数选择必须要看你的文档特性纯文本段落、新闻报道类chunk_size可以设为400-600个tokenoverlap设在60-100边界用自然段落分隔符。代码文档、技术手册建议优先按代码块边界切而不是硬按token数切否则一行import和一个函数体可能被拆成两块。表格密集的财务类内容最好先做表格识别把每个表格单独作为一块再在块内保留表头信息否则一句话引用一个单元格时模型根本不知道这个数字指的是哪个维度。我在项目里通常用RecursiveCharacterTextSplitter做初切自定义分隔符优先级[\n\n, \n, 。, , , ]再打开句号、分号这个级别的分隔。这个顺序是经过验证的先按照章节分再按照段落分最后才按句子分能最大程度保留语义边界。overlap的作用很多人理解不到位。它不是用来增加回报量的而是防止两个连续段落之间共享的关键上下文被切开。我见过一个案例文档里先写“该方案不适用于以下场景”紧接着列出三条规则——这条“不适用”本来是对下面三条规则的否定前提切块时如果不带overlap三条规则被单独检索出来后模型会把“不适用”的内容当成“适用方案”来回答直接翻车。3.2 第二步混合检索与重排让召回结果更稳纯向量检索在中文垂直领域里经常表现不稳原因在于中文的近似语义表达太多用户说“工资发少了”文档里写的是“薪资核算差异”向量虽然能建立一定关联但不如“工资”、“薪资”这种字面匹配直接。所以生产级RAG我强烈建议做混合检索向量检索负责语义兜底把意思相近但字面不同的表述捞出来。BM25负责精确猎取把包含业务关键词、型号名、日期、编号的文档卡准。两条结果最后合并时常见做法是用RRFReciprocal Rank Fusion归一化排序。RRF的原理不复杂对两个排序结果按位置倒数的累加值重排位置越靠前权重越高。好处是它不需要调权重参数对工程人员特别友好实测稳定程度高于线性加权。重排环节也建议不要省。向量召回通常取top-20或top-30但真实喂给模型的可能只有top-4或top-5中间这层过滤就是重排模型的工作。我在中文场景里常用bge-reranker-v2-m3它对“检索结果是否真正回答用户问题”的判断力实测明显强于单纯按相似度截断。重排之后给模型的段落数量我通常设在3-5条太少会漏关键信息太多会让模型注意力被无关内容稀释。3.3 第三步给Agent注册“检索工具”的正确姿势Agent要调用RAG不是直接把检索结果塞进对话就行。工程实践上要做三个准备。第一是注册成标准工具。你得给Agent一个清晰的工具说明让它在合适的时机决定是否调用。工具描述不是写给机器看的是写给模型“看”的所以要说清楚“当你需要回答关于产品费用、套餐政策、合同条款的问题时调用该工具查询最新知识库如果用户只是闲聊不要调用。”描述越具体Agent的调用决策越准。第二是结果要“加工”后再给Agent。很多同学把RAG返回的原文直接拼进上下文结果Agent看到一大段没提炼过的文字还要自己再筛一遍。更规范的做法是在检索后面接一个压缩器Contextual Compressor把检索到的几条结果提炼成“要点来源引用”的结构化格式再进入Agent上下文。这既降低了Token开销也让Agent处理起来轻快不少。第三是给Agent设定检索失败预案。如果RAG召回的相似度分数普遍很低说明知识库里根本没有相关答案。这时候最好的响应是坦诚告知“根据当前知识库我无法找到该问题的答案”而不是让模型自由发挥“编一个合理的回答”。这个兜底逻辑要在Prompt里反复强调最好做成系统级约束而不能只靠模型自觉。3.4 第四步基线评测与上线前后对比任何RAGAgent项目在上线前必须建立自己的评测基线不然你根本无法判断改动是在变好还是在变坏。我第一次做这类项目时也犯过懒手工翻了十来条测试问答觉得“看起来靠谱”就上线了。结果业务方随手问一个稍微拐弯的问题系统就答非所问。后来老老实实做了评测集才明白问题出在哪。评测集至少应该包含三类样本知识问答型问题在知识库里有明确对应答案测的是检索召回准不准。多跳推理型需要结合多个知识片段才能回答测的是Agent编排能力。边界挑战型知识库里没有答案、甚至问题本身超出业务范围测的是系统的拒答能力和抗幻觉能力。建议每类准备30条以上来源直接从真实用户会话日志里挑再人工标注标准答案。每次改动切块参数、重排模型或Agent Prompt都把评测集完整跑一遍记录三项指标召回命中率、答案正确率、平均响应时间。只有这套流程跑顺了你才能有底气说“这个改动真的有效”。4. 工程实践里最常踩的5个坑4.1 检索链路延迟拖垮Agent体验RAG单独做问答时单次检索一两百毫秒用户没感觉但接进Agent后问题就来了Agent可能在一次回答过程中调用多次检索工具每次检索又是上百毫秒的耗时再加上大模型多次推理整体响应时间很容易飙到十秒开外。用户等不起。这种场景我建议做两层优化。第一链路里能并行的就并行如果Agent确定需要同时查多个主题那就并行发起检索而不是串行等待。第二给Agent设置工具调用上限例如最多5次工具调用超时或超次数必须强制收敛输出。否则模型可能在一个简单问题上反复检索、反复思考Token烧了一大堆答案还没出来。我踩过的一次事故就是Agent拿到用户问题后先检索了知识库A发现不满意又检索知识库B再对比两者然后决定再检索知识库A确认细节——一轮对话做了5次检索响应耗时27秒业务方当场摇头。后来把所有相关索引合并成一个统一检索入口加了一层路由速度立刻降到4秒以内。4.2 上下文塞得太满模型越答越糊涂Agent的上下文窗口不是越大越好。有些选手喜欢把检索到的5条结果原封不动拼进上下文再叠加历史对话、系统Prompt、工具返回结果整个上下文动辄两三万token。结果模型读是读得完但注意力严重分散对真正重要的信息“视而不见”。上下文工程的一条核心原则是只给模型当前步骤需要的信息不要给全部信息。你可以把RAG返回的每条内容压缩成“一段摘要一个链接来源”必要时才展开全文。这相当于给模型划重点它不知道哪些信息重要时你替它筛掉干扰项。有次我把一条用户问题丢给一个超长上下文的智能体它准确判断出了需要检索公司报销制度但从召回结果看制度文档里贴了三年前的旧版本内容模型没有注意到版本日期直接按旧规则回答导致客服被投诉。后来我强制在压缩器里输出“生效日期摘要”这种由版本造成的低级错误才根除。4.3 Agent循环空转烧掉预算还没结果Agent的循环机制在复杂任务上表现优秀但也会带来一个副作用模型在工具调用过程中反复尝试错误路径甚至陷入“检索-不满意-再检索”的死循环。这个问题在纯RAG里不存在在Agent架构里特别常见。解决思路有三层。第一设定最大循环次数超过了强制让模型基于当前已有信息输出最终答案。第二工具内部做防抖处理如果同一轮对话里Agent已经检索过同一个Query的相似变体直接返回上次结果不再重复检索。第三Prompt里明确告诉模型“不要在同一个问题上尝试超过两次检索如果两次都找不到说明知识库中没有答案请直接告知用户”。实际跑下来第二层优化通常能节省20%-30%的工具调用量因为模型非常容易把同一个问题换个说法再问一次。4.4 重排后仍混入“相关但错误”的信息我遇到一个典型的案例用户问“企业版是否包含专属部署”检索系统召回了两段内容一段讲“企业版提供专属部署”另一段讲的是“旗舰版专属部署方案调整公告”。两段文本向量上很接近重排模型也没能把它们分开Agent在回答时把两个版本的信息混在一起生成了错误结论。这类问题的解药在于元数据过滤。切块时保留文档级别、产品线、适用版本、生效日期等结构化信息检索和重排完成后再叠一层规则过滤。比如用户问企业版就把旗舰版的段落直接过滤掉。规则过滤的优先级可以高于重排模型因为它是不容置疑的硬边界。经验是先硬过滤再重排最后进上下文。顺序不能反。4.5 评测集没跟上业务变化一改全乱上线跑了三个月的知识库系统最常见的问题不是技术崩了而是评测集还是三个月前那批题。业务方改了政策、新增了产品线、旧文档换成了新版本你的评测集却没有同步更新。结果就是你调了半天模型参数评测分数上升了线上用户体验却在下降。更稳妥的做法是让评测集和业务版本一起演进。每次知识库发生重大变更时你至少要补充10-20条跟新变更直接相关的测试用例。最好再安排一个人周期性抽检线上会话日志把新出现的用户问法回填进评测集。5. 工具选型对照别被框架绕花眼5.1 框架与编排层怎么选最近大模型中间件领域非常热闹选择多了反而容易犯选择困难症。我的观点是工具服务于场景不要用最火的要用最合适的。框架定位适合场景上手难度LangChain通用型框架组件全快速做原型验证传统RAG链路中LlamaIndex文档索引与检索专项知识库规模大、结构复杂的RAG场景中低LangGraphAgent状态机编排复杂多步骤Agent任务需要对流程有控制力中高Dify低代码应用平台非技术团队快速搭知识库助手低AgentScope多Agent协作与消息路由多智能体协同场景中我自己的选型策略很简单如果是PoC项目直接用LangChain或者Dify最快时间跑通整个链路如果是要长期迭代的生产项目优先考虑用LangGraph这一类状态机框架把Agent流程显式画出来每个环节都可观测、可回滚。这里说一句题外话我身边不少离开了LangChain的团队不是因为它不好用而是因为改动频繁时框架升级带来的维护成本比业务代码还高所以“自主研发为主、框架为辅”反而是长期更省心的路线。5.2 向量库与Embedding怎么配向量库的选择取决于你的数据规模与部署环境单机小规模百万级向量以内FAISS够用内存够快运维成本几乎为零。中等规模千万级Milvus或Qdrant更适合因为它们提供了更方便的过滤、持久化和分布式能力。系统里已经有PostgreSQL直接用pgvector顺手且免引入新组件只是性能上限相对有限。Embedding模型的选型中文场景我首选开源系列比如BAAI的bge系列效果好、开源可商用、同尺寸下性价比高。调用第三方Embedding接口也要看业务需求如果知识库是纯英文、预算充足选择OpenAI等商业接口没毛病如果知识库涉及敏感私有数据本地部署开源Embedding模型是唯一放心选项。注意Embedding模型和Reranker模型是两码事前者负责把文本转成向量后者负责对召回的候选结果精排两者可以来自不同的模型系列不用拘泥于同一厂商。我遇到过一个挺有意思的情况某团队在Embedding选型时用了最新的大尺寸模型向量效果好是好但单条文本向量化耗时翻了四五倍批量处理几天没跑完。后来换了一个稍小但专门针对中文优化的模型召回分数略微下降整体处理时间却缩短了80%。在这种环节吞吐量和效果要一起权衡不能只看精度一项指标。6. 一些落地实操建议6.1 先精一条链路再铺多个Agent开始做RAGAgent项目时很容易陷入“先搭一个万能平台”的陷阱。有过好几次团队上来就设计“客服Agent运营Agent数据分析Agent”的大平台结果每个Agent都在半成品状态。我的建议是反过来先挑选一个业务价值最高、知识库最完整的场景把一条链路打磨到“上线可用”的水平再横向复制到其他场景。这条链路至少要包含稳定的检索召回90%以上问题能命中、可控的Agent规划不会陷入死循环、清晰的兜底策略不知道就是不知道、完整的日志观测每个环节出错都能切片分析。这四件事做到位了比堆砌十个半成品Agent有用十倍。6.2 日志要设计成“可复盘”的很多Agent项目上线时功能看着没问题一遇到线上异常就抓瞎因为日志里只有一句“调用了工具返回失败”没有把完整的决策链条记录下来。我建议每个Agent请求至少要记录原始输入、Agent内部规划的步骤列表、每次工具调用的输入与输出、检索到的文档ID与相似度分数、最终生成结果、以及每一步的耗时。这套日志的价值在平时看不见一旦线上出了错你能像看回放一样还原智能体当时为什么做了这个决策问题定位速度会快好几倍。顺带一个实用小技巧把线上日志里“用户问题最终回答”批量沉淀下来按周做一次聚类分析。你会发现很多用户提问模式是重复的把它们整理成评测集就能让系统越用越顺手而不是永远原地踏步。最后再分享一点我的个人体会RAGAgent这套组合架构真正难的地方不是技术本身而是你想清楚“让大模型什么时候该信自己什么时候该去查资料什么时候该承认不知道”。我自己踩过不少坑后才意识到架构设计得再精巧不如把知识管线和决策边界理清楚来得实在。如果你正在做类似的项目建议先把切块和检索评测做扎实再接Agent编排——前面的地基稳了后面加多少层都不会虚。