我去年底接手了一个企业级知识库问答助手项目最初方案只用了RAG后来被用户需求一步步逼到了RAGAgent的组合上。回头复盘才发现这不仅是技术选型问题而是对大模型落地场景的一次重新理解。现在很多团队都在聊RAG、Agent、架构这些词但真正把两者组合好、能在生产环境稳定跑起来的并不多。这篇就围绕这个核心组合展开把设计思路、关键细节、实操过程和踩过的坑一起捋清楚适合正在做大模型应用落地、智能客服、流程自动化或Agent开发的工程师参考。1. 先搞清楚RAG和Agent各自补什么短板1.1 不是大模型不会是它“记不住”“动不了”抛开概念去看单个大模型本身有两个致命短板。第一是知识时效性问题模型训练完参数就冻结了你问它最近三个月的新政策、内部系统的API字段、某个私有文档里的报价逻辑它要么答不上来要么一本正经地胡编。第二是能力边界问题它可以写文案、总结代码、分析数据但你让它去查一下数据库订单状态、调用CRM系统建个工单、自动把结果发到钉钉群它做不到因为模型本身只是一个“文本生成器”不通网络、不连系统、不能执行动作。这两个短板恰好是RAG和Agent各自的主场。RAG解决“记不住”Agent解决“动不了”。把两者组合在一起等于给大模型装上了外挂知识库和手脚这也是为什么RAGAgent架构会变成大模型智能体落地的核心组合。1.2 RAG把外部知识变成可检索、可更新的记忆RAG的核心逻辑不复杂一句话就是“先检索再生成”。把企业文档、操作手册、FAQ等非结构化文本切分成小块用嵌入模型转成向量存进向量数据库用户提问时先把问题也转成向量去库里检索最相关的片段最后把这些片段连同问题一起交给大模型让它基于给定材料作答。以前纯粹靠模型死记硬背RAG相当于把答案来源从模型参数内部转移到了外部知识库。好处很明显知识可以随时更新不用反复重新训练模型回答可以被引用溯源用户点开能看到依据来源信任度完全不同企业私有数据不出内网合规上也安心很多。我随便拿一组数据来说明常规RAG检索Top5片段给模型做上下文很多业务问答的准确率能从纯模型的60%左右提升到85%以上前提是检索质量本身过关。1.3 Agent把语言能力变成执行能力Agent就更有意思了。它不满足于“答得好”而是追求“办得到”。一个典型的Agent工作循环包括感知、规划、调用工具、观察结果、再规划直到完成目标。比如用户说“帮我分析一下上个月的销售数据有问题就生成告警邮件发给相关负责人”。大模型单靠自身能力做不到但Agent可以分解成几个步骤检索知识库找到销售数据表的位置和字段说明调用SQL接口查数据让模型分析异常指标调用邮件API发信最后汇总结果反馈给用户。这个过程里每一步都对应一个工具调用大模型扮演的是“大脑”的角色负责规划决策外部系统充当“手脚”。Agent的价值在于把零散的工具串成一条按意图驱动的工作流。没有Agent的时候一个业务流程对应一段硬编码逻辑有了Agent业务流程变成了模型的动态规划系统的扩展性和适应性都上了一个台阶。2. RAG与Agent怎么组合架构长什么样2.1 为什么要把RAG嵌进Agent而不是并列我见过不少架构图把RAG和Agent画成两个并列的模块左边一个RAG服务右边一个Agent服务互不干涉。这种设计在演示Demo时问题不大做真实的复杂业务就会露馅。核心原因在于Agent本身也需要知识而且需要的知识种类远多于问答场景。Agent要规划任务得知道当前有哪些可用工具、每个工具入参出参是什么样的Agent要学会特定业务规则比如“退货金额超过一万元必须人工审批”这是模型参数里根本没有的内容Agent在执行中途遇到问题还要能查找解决方案。这些知识都放在同一个知识库里让Agent在不同环节随时检索才能让系统真正“懂事”。所以正确做法是RAG作为Agent能力链路上的一环嵌入到Agent的感知、规划、执行各个阶段形成所谓的Agentic RAG模式。RAG不再是被动等待外部调用的接口而是Agent主动使用的一个核心工具。2.2 一套可落地的整体架构我按生产环境标准给你一个我实际验证过的架构分层从上到下分别是接入层、智能体层、能力层和知识层。接入层负责对接多渠道比如企业微信、钉钉、Web页面统一把用户请求送进智能体网关。智能体层是核心里面运行着Agent主循环通常会用LangGraph之类的工作流引擎来管理Agent状态也可以基于LangChain的Harness架构做二次开发这类框架的好处是任务节点可编排、循环可控制、出错可以回溯。能力层挂载各类工具包括RAG检索、SQL查询、HTTP API、消息推送、OCR识别等。知识层则负责统一承接数据包括向量数据库、文档存储、结构化业务库以及知识更新管道。这个架构关键点在于每一层之间都通过标准接口通信。Agent不直接查数据库而是调用一个工具接口工具接口不直接实现业务逻辑而是转发给后端服务。每一层都可以单独扩容知识层性能不够就加检索节点能力层要接新系统就加一个工具不用动主框架代码。2.3 主流程感知—检索—推理—行动把整个流程走一遍。用户提了问题之后Agent进入规划阶段它可能先用意图识别工具判断用户是想问答、查数据还是操作业务流程。进入问答类任务时Agent触发RAG检索工具系统会做意图改写、生成多路查询词、在知识库中做混合检索把返回结果交给负责答案合成的子Agent。进入操作类任务时Agent需要先检索操作手册和工具说明确认执行方式和参数规范再调用对应工具。工具返回结果后Agent观察结果判断是否达到预期如果不够就重新调整方案继续直到任务完成或者达到最大迭代次数。这里插一句需要注意的地方规划不是越多越好幻觉型规划比不规划更可怕。如果你的Agent总在规划一些不存在的步骤或者调用一些并不存在的工具那多半是工具描述写得不够清楚或者系统提示词里没有限制“只能使用列表中的工具”。我见过一个Agent在知识库里乱翻文档硬生生把一条退款流程规划成了七个步骤然后挨个报错最后靠预设的熔断机制才算刹住。3. 关键环节的实操与踩坑记录3.1 知识库建设分块、嵌入、混合检索知识库是RAG的地基地基不牢上面全白搭。第一步文档解析就要讲究PDF要有OCR和版面分析能力表格要单独处理否则大量表格内容会在切分时被拦腰截断信息就丢了。我自己做过一次实验同一份产品参数表用普通文本切分和用版面分析后结构化切分同样问题回答准确率差出将近30个百分点。分块参数不能拍脑袋定需要根据实际文档做评测。一般推荐先定一个chunk_size区间从500字符到1500字符各跑一批测试问题看召回和生成质量选出最合适的值。纯中文场景我会配一个200字符左右的重叠量防止关键句被从中间切断。嵌入模型目前我个人比较推荐bge-m3这类中英双语模型效果和兼容性都在线。但向量检索不是万事大吉。向量检索擅长语义匹配但对精确关键词、编号、型号、人名这类实体词经常翻车比如用户搜“A3-120型传感器”向量库里可能返回一堆语义相近但型号完全不同的内容。所以混合检索是必选项BM25负责精确匹配向量检索负责语义召回两路结果用RRF或者加权方式进行融合效果会有明显提升。3.2 Re-ranking和上下文压缩这一步别省检索召回的Top结果里往往混着一些噪声片段直接塞给大模型它分不清主次回答就容易偏。Re-ranking的作用是对召回结果做精细打分排序把最相关内容顶上来。RAG系统加了bge-reranker这类模型之后整体答案准确率普遍能再提3到8个百分点。上下文压缩同样关键。一次检索可能召回6到10个片段加起来好几千字全塞给模型一是浪费Token二是会稀释关键信息。我的做法是先做相关性截断只保留得分靠前的片段再做信息压缩把每个片段里跟问题无关的废话删掉最后按时间顺序和逻辑关系重组这些片段构造成一个干净、紧凑的上下文。这样既省钱又提升效果。3.3 工具调用、MCP与Agent记忆Agent的能力强弱取决于工具多不多、工具描述写得好不好而不是模型本身多聪明。每个工具定义里必须把功能、入参、出参、适用场景、失败时可能返回什么错误写清楚。工具描述是给模型看的说明书写得太含糊模型就会猜一猜就容易用错。今年以来MCP把工具调用标准化又推了一步。这里要区分清楚MCP是模型上下文协议解决的是Agent如何统一发现、连接和调用外部工具的问题它是一个协议层RAG解决的则是知识检索问题是数据层。这俩不是替代关系而是配合关系MCP可以暴露一个RAG检索服务让Agent像调用其他工具一样调用它。简单的理解MCP统一了“连工具”的动作RAG统一了“找知识”的动作。Agent记忆也要区分内部记忆和外部记忆。短期记忆放在会话上下文里记录当前的对话轨迹和中间状态长期记忆用向量库存储沉淀历史决策、用户偏好、常见问题处理方式等。长期记忆积累到一定量之后Agent会越来越“懂你”它给你推荐方案时会把历史偏好带进来。这个体验非常关键用户会明显感觉到这个系统不是套壳聊天机器人。3.4 Agentic RAG几种常见的编排模式先别急着追求复杂编排从简单的模式开始逐步迭代才是正道。第一种是Router模式意图分类器决定走纯大模型回答、RAG检索回答还是工具调用通道。这种模式最简单适合任务边界清晰的场景。第二种是Corrective RAG模式检索结果先做质量打分评估不够格就自动改写查询词重新检索或者直接让模型调用Web搜索补充信息。这个模式适合知识库覆盖不全的场景能在一定程度上减少答非所问。第三种是Self-RAG模式模型先生成答案再针对答案自评几个维度是否忠实地基于文档回答是否覆盖了用户隐含需求是否需要进一步追问。如果自评不通过就重新走检索和生成流程。这个模式效果最好但Token消耗也最大。我自己的建议是第一版用Router模式跑通然后再升级成Self-RAG不要一上来就全量上复杂架构否则问题出了你都不知道是知识库的问题还是编排的问题。4. 从Demo到工程化安装、配置与扩展4.1 一个最小可运行版本怎么搭既然要落地就得有个能跑的骨架。我自己搭过得最快的一套RAGAgent最小版本是用LangChain加LangGraph向量库用的Milvus嵌入和重新排序模型用BGE系列大模型走OpenAI兼容接口整体可以跑在单机容器里。核心编排代码大致是这样from langgraph.graph import StateGraph, END from langchain_core.messages import HumanMessage, AIMessage def agent_node(state): # 规划判断是否需要检索 plan llm.invoke(f根据用户问题判断是否需要进行知识检索{state[question]}) if 需要检索 in plan.content: state[need_retrieval] True else: state[need_retrieval] False return state def retrieve_node(state): # 检索知识库 docs retriever.invoke(state[question]) state[context] format_docs(docs) return state def generate_node(state): # 基于检索结果生成回答 prompt f基于以下资料回答问题\n{state[context]}\n问题{state[question]} response llm.invoke(prompt) return {answer: response.content} graph StateGraph(AgentState) graph.add_node(agent, agent_node) graph.add_node(retrieve, retrieve_node) graph.add_node(generate, generate_node) graph.add_edge(agent, retrieve) graph.add_edge(retrieve, generate) graph.add_edge(generate, END)一个Alpaca风格的工作流就出来了。别小看这个骨架很多正式项目的业务逻辑版本跟这个差别不大区别只是每个节点内部塞入了更多的错误处理和状态管理。4.2 关键参数怎么调网络上到处是“照着配就行”但实际参数没调好系统照样难用。我给几个重要的默认基线你用的时候根据自己场景微调。temperature建议设0.1到0.3之间太高的随机性会让你连工具调用的参数都开始乱写。top_k建议20到50之间既保证召回量又控制噪声。最大迭代轮次必须限制初始阶段给5轮就足够超过就熔断并转人工兜底。超时设置也不能忘每个工具调用建议控制在15秒到30秒整轮Agent任务控制在60秒内没完成就返回中间结果不要让用户干等。这些参数不是拍脑袋背后逻辑是两个约束一是大模型本身响应延迟叠加工具调用会产生雪崩效应二是用户能接受的等待时间有限。控制好参数就是控制住用户体验的下限。4.3 从单机到分布式多路检索与多Agent协同业务规模一大单机服务肯定扛不住。分布式化通常从两个方向做。知识检索侧如果企业有多个部门、多套知识体系不要全部塞进一个向量集合而是按业务域拆分成多个Collection由路由层按问题意图分发到不同的检索单元再对各路结果做统一融合排序。这种方法能避免跨域检索互相污染也能让每个检索单元独立索引更新。Agent侧复杂任务可以拆给多个子Agent协作。一个主管Agent负责任务拆解和结果汇总几个子Agent分别负责知识问答、数据分析、工单处理。每个子Agent可以独立部署、独立扩容主管Agent则要保证全局状态同步。LangGraph里GraphState的设计就是服务于这类多Agent协作场景。5. 常见问题与排查技巧实录5.1 检索不准确、回答幻觉这个是最多人问的我通常会反问他三个问题。是不是只用了向量检索查一下知识库分块有没有对表格内容做破坏嵌入模型和业务语言匹不匹配解决方法顺着来就行加上BM25做混合检索把分块策略改成按版面元素切割再换一批领域句子去做嵌入模型的选型评测。如果幻觉还出现就在提示词里强制要求“没有检索到相关内容时直接说不清楚禁止编造”。5.2 Agent死循环或执行超时Agent卡死通常不是程序Bug而是规划路径里有个工具总在报错模型又不断尝试重试形成循环。我发现一个有用的排查方法打开LangGraph的完整轨迹回放把每一步的模型输入输出、工具调用参数、返回结果全部拉出来看大概率一眼就能找到是哪个环节出了问题。解决办法有两条腿。第一是给工具调用加重试开关和失败分支工具报错两次就停止重试转成人工提示第二是给整个执行流程增加兜底节点Agent循环超过N轮自动转人工接管。5.3 知识更新与评估闭环知识库不更新系统过两周就凉了。我做了三件事供你参考一是文档录入即触发向量增量更新不搞全库重建省时省力二是设置定时任务扫描源文档目录检测到文件变更自动重新解析更新对应分片三是每周抽一批真实用户问题跑一遍评估脚本监控召回率、答案准确率和忠实度三个指标指标低于阈值时自动告警。关于评估补充两点。答案准确率可以人工标注评估也可以让更强大的模型当评审员打分忠实度指的是回答内容是否严格基于检索材料这个指标防止模型套用内部知识编答案。5.4 常见问题速查表现象可能原因解决办法检索内容和目标完全无关分块主题混杂、嵌入模型不匹配按章节或版面切分重新评测嵌入模型问答准确率卡在70%上不去缺少Re-ranking或上下文压缩增加Reranker压缩上下文长度Agent总是调用错误的工具工具描述含糊重写工具描述增加适用场景说明Agent任务到一半就中断超时或迭代上限设置过紧调整超时时间和迭代轮次增加重试知识库更新后效果反而变差向量库里新旧版本数据冲突源文档删除同步删除旧分片保证一致性回答内容偏离检索材料模型幻觉或提示词约束不足强制明确“未检索到就说不清楚”5.5 小成本试错的心得最后说一个很实际的体会。不是每个团队都适合一开始就冲LangGraph加Milvus的大全套我自己在另一个轻量项目里单机版用FastAPI加Chroma加一个检索函数和一个生成函数没有完整Agent框架也撑住了几百个内部用户的使用。重点是先把知识库建好、把检索质量调好再考虑编排复杂度。把RAG和Agent组合做扎实关键不在于框架多先进而在于知识拆分得够不够细意图路由够不够准工具执行的反馈闭环够不够稳。工作流编排上去之后再陆续把多Agent协作和分布式检索加上去系统走到生产环境就没有那么慌了。这套组合目前在我们内部已经稳定跑了近一年的时间我最重要的收获就是技术选型永远服务于业务目标。RAGAgent架构的价值不是概念的炫技而是它真实地解决了一个问题——让大模型不只是会说话更能在企业业务里真正干成事。 RAG+Agent组合架构实战：从知识检索到智能体落地
我去年底接手了一个企业级知识库问答助手项目最初方案只用了RAG后来被用户需求一步步逼到了RAGAgent的组合上。回头复盘才发现这不仅是技术选型问题而是对大模型落地场景的一次重新理解。现在很多团队都在聊RAG、Agent、架构这些词但真正把两者组合好、能在生产环境稳定跑起来的并不多。这篇就围绕这个核心组合展开把设计思路、关键细节、实操过程和踩过的坑一起捋清楚适合正在做大模型应用落地、智能客服、流程自动化或Agent开发的工程师参考。1. 先搞清楚RAG和Agent各自补什么短板1.1 不是大模型不会是它“记不住”“动不了”抛开概念去看单个大模型本身有两个致命短板。第一是知识时效性问题模型训练完参数就冻结了你问它最近三个月的新政策、内部系统的API字段、某个私有文档里的报价逻辑它要么答不上来要么一本正经地胡编。第二是能力边界问题它可以写文案、总结代码、分析数据但你让它去查一下数据库订单状态、调用CRM系统建个工单、自动把结果发到钉钉群它做不到因为模型本身只是一个“文本生成器”不通网络、不连系统、不能执行动作。这两个短板恰好是RAG和Agent各自的主场。RAG解决“记不住”Agent解决“动不了”。把两者组合在一起等于给大模型装上了外挂知识库和手脚这也是为什么RAGAgent架构会变成大模型智能体落地的核心组合。1.2 RAG把外部知识变成可检索、可更新的记忆RAG的核心逻辑不复杂一句话就是“先检索再生成”。把企业文档、操作手册、FAQ等非结构化文本切分成小块用嵌入模型转成向量存进向量数据库用户提问时先把问题也转成向量去库里检索最相关的片段最后把这些片段连同问题一起交给大模型让它基于给定材料作答。以前纯粹靠模型死记硬背RAG相当于把答案来源从模型参数内部转移到了外部知识库。好处很明显知识可以随时更新不用反复重新训练模型回答可以被引用溯源用户点开能看到依据来源信任度完全不同企业私有数据不出内网合规上也安心很多。我随便拿一组数据来说明常规RAG检索Top5片段给模型做上下文很多业务问答的准确率能从纯模型的60%左右提升到85%以上前提是检索质量本身过关。1.3 Agent把语言能力变成执行能力Agent就更有意思了。它不满足于“答得好”而是追求“办得到”。一个典型的Agent工作循环包括感知、规划、调用工具、观察结果、再规划直到完成目标。比如用户说“帮我分析一下上个月的销售数据有问题就生成告警邮件发给相关负责人”。大模型单靠自身能力做不到但Agent可以分解成几个步骤检索知识库找到销售数据表的位置和字段说明调用SQL接口查数据让模型分析异常指标调用邮件API发信最后汇总结果反馈给用户。这个过程里每一步都对应一个工具调用大模型扮演的是“大脑”的角色负责规划决策外部系统充当“手脚”。Agent的价值在于把零散的工具串成一条按意图驱动的工作流。没有Agent的时候一个业务流程对应一段硬编码逻辑有了Agent业务流程变成了模型的动态规划系统的扩展性和适应性都上了一个台阶。2. RAG与Agent怎么组合架构长什么样2.1 为什么要把RAG嵌进Agent而不是并列我见过不少架构图把RAG和Agent画成两个并列的模块左边一个RAG服务右边一个Agent服务互不干涉。这种设计在演示Demo时问题不大做真实的复杂业务就会露馅。核心原因在于Agent本身也需要知识而且需要的知识种类远多于问答场景。Agent要规划任务得知道当前有哪些可用工具、每个工具入参出参是什么样的Agent要学会特定业务规则比如“退货金额超过一万元必须人工审批”这是模型参数里根本没有的内容Agent在执行中途遇到问题还要能查找解决方案。这些知识都放在同一个知识库里让Agent在不同环节随时检索才能让系统真正“懂事”。所以正确做法是RAG作为Agent能力链路上的一环嵌入到Agent的感知、规划、执行各个阶段形成所谓的Agentic RAG模式。RAG不再是被动等待外部调用的接口而是Agent主动使用的一个核心工具。2.2 一套可落地的整体架构我按生产环境标准给你一个我实际验证过的架构分层从上到下分别是接入层、智能体层、能力层和知识层。接入层负责对接多渠道比如企业微信、钉钉、Web页面统一把用户请求送进智能体网关。智能体层是核心里面运行着Agent主循环通常会用LangGraph之类的工作流引擎来管理Agent状态也可以基于LangChain的Harness架构做二次开发这类框架的好处是任务节点可编排、循环可控制、出错可以回溯。能力层挂载各类工具包括RAG检索、SQL查询、HTTP API、消息推送、OCR识别等。知识层则负责统一承接数据包括向量数据库、文档存储、结构化业务库以及知识更新管道。这个架构关键点在于每一层之间都通过标准接口通信。Agent不直接查数据库而是调用一个工具接口工具接口不直接实现业务逻辑而是转发给后端服务。每一层都可以单独扩容知识层性能不够就加检索节点能力层要接新系统就加一个工具不用动主框架代码。2.3 主流程感知—检索—推理—行动把整个流程走一遍。用户提了问题之后Agent进入规划阶段它可能先用意图识别工具判断用户是想问答、查数据还是操作业务流程。进入问答类任务时Agent触发RAG检索工具系统会做意图改写、生成多路查询词、在知识库中做混合检索把返回结果交给负责答案合成的子Agent。进入操作类任务时Agent需要先检索操作手册和工具说明确认执行方式和参数规范再调用对应工具。工具返回结果后Agent观察结果判断是否达到预期如果不够就重新调整方案继续直到任务完成或者达到最大迭代次数。这里插一句需要注意的地方规划不是越多越好幻觉型规划比不规划更可怕。如果你的Agent总在规划一些不存在的步骤或者调用一些并不存在的工具那多半是工具描述写得不够清楚或者系统提示词里没有限制“只能使用列表中的工具”。我见过一个Agent在知识库里乱翻文档硬生生把一条退款流程规划成了七个步骤然后挨个报错最后靠预设的熔断机制才算刹住。3. 关键环节的实操与踩坑记录3.1 知识库建设分块、嵌入、混合检索知识库是RAG的地基地基不牢上面全白搭。第一步文档解析就要讲究PDF要有OCR和版面分析能力表格要单独处理否则大量表格内容会在切分时被拦腰截断信息就丢了。我自己做过一次实验同一份产品参数表用普通文本切分和用版面分析后结构化切分同样问题回答准确率差出将近30个百分点。分块参数不能拍脑袋定需要根据实际文档做评测。一般推荐先定一个chunk_size区间从500字符到1500字符各跑一批测试问题看召回和生成质量选出最合适的值。纯中文场景我会配一个200字符左右的重叠量防止关键句被从中间切断。嵌入模型目前我个人比较推荐bge-m3这类中英双语模型效果和兼容性都在线。但向量检索不是万事大吉。向量检索擅长语义匹配但对精确关键词、编号、型号、人名这类实体词经常翻车比如用户搜“A3-120型传感器”向量库里可能返回一堆语义相近但型号完全不同的内容。所以混合检索是必选项BM25负责精确匹配向量检索负责语义召回两路结果用RRF或者加权方式进行融合效果会有明显提升。3.2 Re-ranking和上下文压缩这一步别省检索召回的Top结果里往往混着一些噪声片段直接塞给大模型它分不清主次回答就容易偏。Re-ranking的作用是对召回结果做精细打分排序把最相关内容顶上来。RAG系统加了bge-reranker这类模型之后整体答案准确率普遍能再提3到8个百分点。上下文压缩同样关键。一次检索可能召回6到10个片段加起来好几千字全塞给模型一是浪费Token二是会稀释关键信息。我的做法是先做相关性截断只保留得分靠前的片段再做信息压缩把每个片段里跟问题无关的废话删掉最后按时间顺序和逻辑关系重组这些片段构造成一个干净、紧凑的上下文。这样既省钱又提升效果。3.3 工具调用、MCP与Agent记忆Agent的能力强弱取决于工具多不多、工具描述写得好不好而不是模型本身多聪明。每个工具定义里必须把功能、入参、出参、适用场景、失败时可能返回什么错误写清楚。工具描述是给模型看的说明书写得太含糊模型就会猜一猜就容易用错。今年以来MCP把工具调用标准化又推了一步。这里要区分清楚MCP是模型上下文协议解决的是Agent如何统一发现、连接和调用外部工具的问题它是一个协议层RAG解决的则是知识检索问题是数据层。这俩不是替代关系而是配合关系MCP可以暴露一个RAG检索服务让Agent像调用其他工具一样调用它。简单的理解MCP统一了“连工具”的动作RAG统一了“找知识”的动作。Agent记忆也要区分内部记忆和外部记忆。短期记忆放在会话上下文里记录当前的对话轨迹和中间状态长期记忆用向量库存储沉淀历史决策、用户偏好、常见问题处理方式等。长期记忆积累到一定量之后Agent会越来越“懂你”它给你推荐方案时会把历史偏好带进来。这个体验非常关键用户会明显感觉到这个系统不是套壳聊天机器人。3.4 Agentic RAG几种常见的编排模式先别急着追求复杂编排从简单的模式开始逐步迭代才是正道。第一种是Router模式意图分类器决定走纯大模型回答、RAG检索回答还是工具调用通道。这种模式最简单适合任务边界清晰的场景。第二种是Corrective RAG模式检索结果先做质量打分评估不够格就自动改写查询词重新检索或者直接让模型调用Web搜索补充信息。这个模式适合知识库覆盖不全的场景能在一定程度上减少答非所问。第三种是Self-RAG模式模型先生成答案再针对答案自评几个维度是否忠实地基于文档回答是否覆盖了用户隐含需求是否需要进一步追问。如果自评不通过就重新走检索和生成流程。这个模式效果最好但Token消耗也最大。我自己的建议是第一版用Router模式跑通然后再升级成Self-RAG不要一上来就全量上复杂架构否则问题出了你都不知道是知识库的问题还是编排的问题。4. 从Demo到工程化安装、配置与扩展4.1 一个最小可运行版本怎么搭既然要落地就得有个能跑的骨架。我自己搭过得最快的一套RAGAgent最小版本是用LangChain加LangGraph向量库用的Milvus嵌入和重新排序模型用BGE系列大模型走OpenAI兼容接口整体可以跑在单机容器里。核心编排代码大致是这样from langgraph.graph import StateGraph, END from langchain_core.messages import HumanMessage, AIMessage def agent_node(state): # 规划判断是否需要检索 plan llm.invoke(f根据用户问题判断是否需要进行知识检索{state[question]}) if 需要检索 in plan.content: state[need_retrieval] True else: state[need_retrieval] False return state def retrieve_node(state): # 检索知识库 docs retriever.invoke(state[question]) state[context] format_docs(docs) return state def generate_node(state): # 基于检索结果生成回答 prompt f基于以下资料回答问题\n{state[context]}\n问题{state[question]} response llm.invoke(prompt) return {answer: response.content} graph StateGraph(AgentState) graph.add_node(agent, agent_node) graph.add_node(retrieve, retrieve_node) graph.add_node(generate, generate_node) graph.add_edge(agent, retrieve) graph.add_edge(retrieve, generate) graph.add_edge(generate, END)一个Alpaca风格的工作流就出来了。别小看这个骨架很多正式项目的业务逻辑版本跟这个差别不大区别只是每个节点内部塞入了更多的错误处理和状态管理。4.2 关键参数怎么调网络上到处是“照着配就行”但实际参数没调好系统照样难用。我给几个重要的默认基线你用的时候根据自己场景微调。temperature建议设0.1到0.3之间太高的随机性会让你连工具调用的参数都开始乱写。top_k建议20到50之间既保证召回量又控制噪声。最大迭代轮次必须限制初始阶段给5轮就足够超过就熔断并转人工兜底。超时设置也不能忘每个工具调用建议控制在15秒到30秒整轮Agent任务控制在60秒内没完成就返回中间结果不要让用户干等。这些参数不是拍脑袋背后逻辑是两个约束一是大模型本身响应延迟叠加工具调用会产生雪崩效应二是用户能接受的等待时间有限。控制好参数就是控制住用户体验的下限。4.3 从单机到分布式多路检索与多Agent协同业务规模一大单机服务肯定扛不住。分布式化通常从两个方向做。知识检索侧如果企业有多个部门、多套知识体系不要全部塞进一个向量集合而是按业务域拆分成多个Collection由路由层按问题意图分发到不同的检索单元再对各路结果做统一融合排序。这种方法能避免跨域检索互相污染也能让每个检索单元独立索引更新。Agent侧复杂任务可以拆给多个子Agent协作。一个主管Agent负责任务拆解和结果汇总几个子Agent分别负责知识问答、数据分析、工单处理。每个子Agent可以独立部署、独立扩容主管Agent则要保证全局状态同步。LangGraph里GraphState的设计就是服务于这类多Agent协作场景。5. 常见问题与排查技巧实录5.1 检索不准确、回答幻觉这个是最多人问的我通常会反问他三个问题。是不是只用了向量检索查一下知识库分块有没有对表格内容做破坏嵌入模型和业务语言匹不匹配解决方法顺着来就行加上BM25做混合检索把分块策略改成按版面元素切割再换一批领域句子去做嵌入模型的选型评测。如果幻觉还出现就在提示词里强制要求“没有检索到相关内容时直接说不清楚禁止编造”。5.2 Agent死循环或执行超时Agent卡死通常不是程序Bug而是规划路径里有个工具总在报错模型又不断尝试重试形成循环。我发现一个有用的排查方法打开LangGraph的完整轨迹回放把每一步的模型输入输出、工具调用参数、返回结果全部拉出来看大概率一眼就能找到是哪个环节出了问题。解决办法有两条腿。第一是给工具调用加重试开关和失败分支工具报错两次就停止重试转成人工提示第二是给整个执行流程增加兜底节点Agent循环超过N轮自动转人工接管。5.3 知识更新与评估闭环知识库不更新系统过两周就凉了。我做了三件事供你参考一是文档录入即触发向量增量更新不搞全库重建省时省力二是设置定时任务扫描源文档目录检测到文件变更自动重新解析更新对应分片三是每周抽一批真实用户问题跑一遍评估脚本监控召回率、答案准确率和忠实度三个指标指标低于阈值时自动告警。关于评估补充两点。答案准确率可以人工标注评估也可以让更强大的模型当评审员打分忠实度指的是回答内容是否严格基于检索材料这个指标防止模型套用内部知识编答案。5.4 常见问题速查表现象可能原因解决办法检索内容和目标完全无关分块主题混杂、嵌入模型不匹配按章节或版面切分重新评测嵌入模型问答准确率卡在70%上不去缺少Re-ranking或上下文压缩增加Reranker压缩上下文长度Agent总是调用错误的工具工具描述含糊重写工具描述增加适用场景说明Agent任务到一半就中断超时或迭代上限设置过紧调整超时时间和迭代轮次增加重试知识库更新后效果反而变差向量库里新旧版本数据冲突源文档删除同步删除旧分片保证一致性回答内容偏离检索材料模型幻觉或提示词约束不足强制明确“未检索到就说不清楚”5.5 小成本试错的心得最后说一个很实际的体会。不是每个团队都适合一开始就冲LangGraph加Milvus的大全套我自己在另一个轻量项目里单机版用FastAPI加Chroma加一个检索函数和一个生成函数没有完整Agent框架也撑住了几百个内部用户的使用。重点是先把知识库建好、把检索质量调好再考虑编排复杂度。把RAG和Agent组合做扎实关键不在于框架多先进而在于知识拆分得够不够细意图路由够不够准工具执行的反馈闭环够不够稳。工作流编排上去之后再陆续把多Agent协作和分布式检索加上去系统走到生产环境就没有那么慌了。这套组合目前在我们内部已经稳定跑了近一年的时间我最重要的收获就是技术选型永远服务于业务目标。RAGAgent架构的价值不是概念的炫技而是它真实地解决了一个问题——让大模型不只是会说话更能在企业业务里真正干成事。