生产环境下复合检索Agent系统设计，跳出传统RAG的工程实践

大模型落地企业知识场景的过程里很多团队都会陷入一种看似简单的误区拿到RAG开源方案之后直接做简单封装把向量库接入业务知识库简单拼接检索片段交给大模型生成答案就宣告知识问答系统完成上线。但真正走到生产环境就会发现纸面效果和线上真实体验中间隔着巨大的鸿沟。召回文档看着很多但是大量无关噪声混入上下文回答经常出现事实幻觉部分关键信息片段缺失不同权限的用户拿到一模一样的答案网络波动或者页面刷新直接打断正在执行的Agent流程用户上传截图报错的场景无法处理。绝大多数轻量化RAG实现本质是单向流水线用户提问触发检索检索完成直接生成回复整个链路没有二次校验没有自我评估没有补充挖掘的能力。检索环节拿到什么材料大模型就只能基于这些材料输出内容一旦向量检索漏了关键信息或者召回大量语义相似但是逻辑无关的片段整套系统的回答质量就会直接崩盘。想要解决企业知识问答的准确率、时效性、权限隔离、生产稳定性一系列复杂问题单纯依靠向量检索加上重排序模型的组合远远不够我们需要一套真正具备自主决策能力的复合检索Agent架构把检索评估、补充挖掘、多层过滤、多源信息交叉验证完整交给Agent运行时去驱动而不是写死固定的业务流程。本文基于真实落地的企业知识问答项目实践拆解一套面向生产可用的复合检索Agent完整系统聊聊如何基于AgentScope 2.0 HarnessAgent运行时摆脱传统RAG流水线的束缚搭建能够自主思考自主行动的知识问答体系同时拆解多源并行检索、三层质量过滤流水线、多模态兼容、分布式SSE断点续传等工程模块的设计取舍以及踩过的各类线上坑点也会探讨这套架构后续的演进方向。重新审视企业知识问答的核心矛盾企业内部知识的形态远比公开互联网文本更加复杂。正式维护的产品手册、流程规范、FAQ知识库属于结构化权威知识团队内部沉淀的在线文档、会议录音转写记录、工作群聊天消息属于动态碎片化知识。权威知识库更新存在滞后很多最新的业务决策不会第一时间同步到正式文档只会散落在会议纪要和工作沟通记录之中。一个合格的企业知识回答首先要做到查得全不能遗漏关键信息其次要查得准过滤掉大量语义匹配但是实际无关的噪声还要做到理解得对能够读懂截图报错这类非文本输入最后必须做好权限隔离不同岗位不同权限的用户访问同一个问题系统返回的检索素材必须和用户身份匹配。上面这些能力不是简单堆叠工具就可以实现。很多团队做多源RAG只是依次调用不同数据源的检索接口把所有返回结果简单拼接在一起喂给大模型。这种实现方式有很明显的短板不管用户的问题偏向哪一类信息全部数据源都执行一遍检索带来不必要的接口开销同时大量来源混杂的片段堆砌在一起没有优先级区分信息冲突的时候也不会做校验最终输出的回答很容易前后矛盾。真正的复合检索核心要义不是调用更多数据源而是赋予Agent决策权。由Agent根据用户问题本身自主判断应该调用哪些工具需要构造什么样的检索查询是否需要对文档做全文精读现有信息是否足够支撑回答信息不足的时候该补充检索哪一类数据源多源信息出现冲突的时候以哪一份材料为准什么时候可以终止整个思考行动循环输出最终答案。整套流程不是硬编码固定顺序而是在推理行动观察的循环之中动态推演完成。想要承载这样的业务逻辑普通的ReAct简易实现很难扛住线上压力。简易ReAct更多偏向Demo场景缺少中间件扩展能力缺少工具并行调用支持缺少会话状态管理缺少沙箱隔离长期运行多轮对话很容易出现状态错乱。我们选择基于AgentScope 2.0的HarnessAgent架构作为底层运行时它本身就是面向生产环境设计的Agent实现内置大量工程化基础能力不需要我们从零开发Agent运行时我们只需要基于框架原生能力注入业务策略与质量管控逻辑。在项目落地过程中我们重点用到框架三项核心能力分别是ReAct循环机制Middleware中间件扩展并行工具调用能力。ReAct循环提供推理行动观察的闭环Agent不会一次性完成检索回答而是反复执行推理执行工具行动观察工具返回结果再次推理循环往复完整支撑搜索评估精读再搜索的复杂业务流程。Middleware中间件允许我们在Agent执行链路的关键节点插入自定义业务逻辑完全不侵入框架内部核心源代码。我们就在onActing钩子函数内部挂载整套检索结果质量过滤流水线整个过滤逻辑对Agent上层推理完全透明。并行工具调用能力则解决检索场景的性能痛点当Agent一轮推理判断需要执行多个工具调用框架可以自动并发执行而不是串行逐个等待返回结果。这就为多变体查询、多数据源同时检索打下基础大幅度降低多源检索场景的整体耗时。依托这几项底层能力我们搭建起完整的复合检索业务流程。Agent在每一轮ReAct循环内部完成搜索评估决策闭环多数据源并行发起检索拿到结果之后自主评估信息完备度信息不足就触发补充检索或者文档精读检索素材经过三层质量流水线过滤再做来源优先级排序与多源交叉校验最后整合全部有效信息生成回答。整套系统同时维护两套知识链路一套是企业统一维护的知识库存放产品文档、流程规范、业务FAQ按照业务部门、业务领域做划分管理员统一维护更新负责提供权威结构化知识底座。另一套是用户个人生态数据由用户自主授权开启Agent只会读取该用户身份能够查看的文档、会议记录、聊天消息负责补充最新动态的碎片化业务信息。两条链路可以在同一次对话同时生效同一个问题既可以拿到官方标准流程也可以拿到团队内部最新讨论和会议决策记录两者互相补充这也是这套系统区别普通RAG的核心价值。复合检索Agent架构把决策权交给Agent传统RAG属于单向流水线用户提问之后直接执行向量检索拿到片段拼接上下文交给大模型生成回复整个流程是一次性执行。检索环节输出什么大模型就消费什么系统没有能力判断检索到的信息够不够用相关性高不高信息冲突如何处理更不会主动发起二次检索。复合检索Agent架构彻底打破这套单向执行逻辑把检索这件事变成Agent内部可循环可决策的行为。整个架构分为多源并行检索模块Agent自主决策模块信息整合模块同时完整落地两层权限隔离机制。多源并行检索与权限的双重保障Agent可以调用的工具集合包含企业知识库以及多类个人生态数据源所有工具不会无条件全部启用会根据前端用户勾选配置结合当前登录用户的权限动态激活。Agent自主决定什么时候调用哪一个工具整个工具调用过程对用户完全不可感知。权限隔离分为两个层面第一层是知识库层面知识库按照业务领域、部门进行分组每个用户绑定一份自己可以访问的知识库列表用户只能触发有权限知识库的检索不会拿到无权限业务域的文档片段。第二层是个人生态数据源层面每一次工具调用都会注入当前用户身份标识下游API接口会基于这个身份做鉴权只返回该用户可见的数据。同一个问题不同权限的用户Agent拿到的检索素材完全不一样从根源避免越权泄露内部文档的风险。并行工具调用的底层实现依托框架提供的Toolkit.parallel(true)配置搭配Java21虚拟线程。检索场景绝大多数都是IO密集型任务大量HTTP请求访问知识平台与第三方生态接口虚拟线程在IO阻塞阶段可以释放平台底层线程不用为每一次IO请求占用操作系统重量级线程在并发会话数量上涨的时候系统线程资源不会快速耗尽。当Agent一轮推理产出多个工具调用指令框架就会并发执行全部调用不用等待上一个工具返回再执行下一个。比如一次同时发起三组不同查询变体的知识库检索同时发起文档和会议记录检索多个请求同步发出有效压缩整体检索耗时。Agent的自主决策评估与挖掘如何落地Agent拿到第一轮全部检索返回结果之后不会直接开始整理答案而是要完成一轮多维度信息评估评估的维度分为相关性完整性时效性。相关性判断用来分辨结果是字面词汇重合还是语义真正匹配用户的问题很多向量检索返回片段关键词高度重合但核心语义和用户诉求无关。完整性判断会检查回答该问题需要的关键要素是否齐全比如询问某个业务接入流程就要确认配置步骤申请渠道测试校验环节这些关键信息是否全部具备。时效性判断重点甄别文档版本区分废弃旧文档和最新版本避免使用已经失效的业务规则。一旦评估得出信息不足的结论Agent不会简单重复一遍相同查询盲目重试而是根据评估的缺陷选择对应的挖掘策略一共有三类挖掘手段。第一类是精读全文检索返回的大多只是文档片段向量检索只会返回相似度最高的部分切片完整配置参数完整步骤很可能存在同一文档其他段落。如果检索摘要显示这份文档价值很高但是片段信息残缺Agent就会调用文档读取工具拉取完整文档内容补齐缺失信息。第二类是补充检索当前数据源找不到足够信息Agent会改写查询语句切换其他数据源继续检索。正式知识库找不到最新变更就转向会议记录、团队沟通记录中寻找线索。第三类是交叉验证多数据源返回信息互相冲突的时候Agent按照预设来源优先级做取舍官方知识库优先级最高其次是团队文档最后是聊天记录和会议纪要并且在最终输出内容中标记信息冲突告诉用户优先采信哪一份来源。整套决策逻辑依靠两部分互相配合完成结构化提示词提供决策策略框架Middleware中间件完成结果质量兜底。我们编写的结构化Agent提示词并不是一条条零散指令而是一套完整的决策策略描述告诉Agent不同数据源的优缺点不同来源的优先级信息不足的时候应该如何行动出现冲突如何处理什么条件可以停止循环输出答案。提示词重点描述目标和背后原因而不是死板规定每一步要调用哪个工具。具体执行细节调用几次检索要不要精读切换什么查询全部交给LLM在策略框架之内自主做出选择。业务人员不需要手动指令Agent去检索某一类文档Agent自己就可以判断什么时候需要调用对应工具。光靠提示词不足以保障线上稳定性大模型偶尔会出现决策漂移所以我们搭配Middleware中间件做兜底。我们在HarnessAgent的onActing钩子挂载整套三阶段质量过滤流水线工具执行完成之后结果返回给大模型推理环节之前中间件拦截原始检索结果执行完整过滤再把清洗之后的素材交给Agent。上层Agent感知不到过滤逻辑的存在拿到的永远是过滤完成的高质量检索条目。这样的设计实现关注点分离结构化提示词定义业务策略Middleware负责结果质量保障ReAct循环负责完整执行流程三者各司其职互不侵入。我们没有修改框架内部ReAct循环源码全部业务逻辑通过提示词和中间件注入后续框架版本升级业务代码也可以低成本迁移。多源信息整合从片段拼接走向有判断的信息拼图多工具并行检索之后系统会拿到一批来自不同位置的文档片段信息整合不是简单把片段拼接在一起分为三层递进处理逻辑。第一层最大化多角度召回自动识别废弃文档与新版本文档如果知识库返回一份标记废弃的旧文档同时其他数据源拿到更新版本Agent会自动优先采信新版内容并且识别标注旧文档已经失效。第二层定向深挖关键文档不满足检索返回的简短切片识别高价值文档之后主动调用精读工具获取全文补齐切片丢失的上下文。向量切片往往会割裂完整业务流程只靠片段很容易漏掉关键约束条件。第三层多源交叉验证带判断力的信息融合。按照来源权威性排序权威知识库作为最高优先级会议纪要、聊天记录作为补充背景材料。系统内部实现SourceCollector组件跨工具调用做文档来源去重最终输出回答的时候关键信息带上来源标记用户可以追溯每一条结论出自哪一份文档。三层质量过滤流水线解决向量相似不等于语义相关RAG系统的两大核心指标是召回率与精准度。召回率代表相关文档有没有被找出来精准度代表返回的文档是不是真正和问题相关。召回能力依靠查询扩展来提升精准度就需要依靠多层过滤流水线。底层文档解析、切片分块、向量化、混合检索能力我们直接复用内部成熟知识管理平台没有重复造轮子。我们的工作是在现有知识平台之上搭建一层面向Agent的智能检索层。向量检索依靠Embedding向量余弦相似度做匹配这个机制本身存在固有缺陷它擅长找到字面看起来相似的内容但是没有办法区分词汇重合但是语义无关的噪声。高频公共词汇很容易带来大量干扰结果。举个例子用户询问业务退货流程向量检索返回五条结果其中只有两条真正和问题相关大部分内容只是包含重复关键词直接送入大模型噪声会挤占上下文窗口还会诱发幻觉问题。很多项目只做一次Reranker重排序很难覆盖全部场景。我们设计一套三阶段可开关的质量Pipeline每一层解决一类特定问题同时通过Middleware嵌入Agent执行链路。查询扩展放弃关键词提取使用自然语言变体做检索检索发起之前首先做查询扩展。我们没有选择提取关键词的方案而是让大模型生成多组语义等价的完整自然语言句子作为检索变体。Embedding模型都是在海量完整句子、段落文本之上训练而来完整主谓宾句式的语义编码效果远好于一堆孤立关键词。如果用户提出一个业务问题提取关键词会得到一堆零散词汇缺少语法约束向量匹配很容易跑偏。生成完整自然语言问句变体能够更好还原用户真实意图。同时Agent会一次性生成多组不同角度的查询变体并行发起检索一部分变体侧重业务流程描述一部分侧重政策条款一部分侧重操作入口多组变体互相补充覆盖用户意图的各个侧面提升整体召回。三阶段Pipeline实现逻辑整套流水线分为FastPass快速通道Reranker粗筛LLM Grading大模型精评三个阶段每一个阶段都支持配置开关可以按需启用关闭适配不同时延要求的业务场景。流水线全部挂载在AgentScope Middleware的onActing钩子之中拦截knowledge_search工具调用完整执行流程如下先放行工具拿到原始返回结果再对检索条目做过滤处理处理完成之后替换原始工具输出事件上层Agent完全无感知。核心伪代码如下// 实现MiddlewareBase接口在工具执行前后注入过滤逻辑 FluxAgentEvent onActing(Agent agent, ActingInput input, next){ if (!config.isEnabled()) return next.apply(input); // 识别本轮knowledge_search工具调用 var targetToolCalls input.toolCalls() .filter(tc - knowledge_search.equals(tc.name)); if (targetToolCalls.isEmpty()) return next.apply(input); // 执行原始工具调用收集事件后统一处理 var events next.apply(input).collectList(); return processEvents(events, targetToolCalls); } // 三层过滤主逻辑 ListRetrievedItem filter(String query, ListRetrievedItem items){ // Stage0 FastPass快速通道高置信度直接放行跳过过滤节省时延 if (items.size() 2 items.stream().allMatch(i - i.originalScore 0.7)) { return items; } // Stage1 Reranker粗筛过滤词像义不同的噪声 if (config.rerankerEnabled) { var scores rerankerService.rerank(query, items.stream().map(i-i.snippet).toList()); items items.stream() .filter(i - scores.get(i.index) 0.3) .sorted((a,b)-Double.compare(b.rerankerScore,a.rerankerScore)) .limit(8) .toList(); } // Stage2 LLM Grading大模型逐条精评打分 if (config.llmGradeEnabled !items.isEmpty()) { var graded llmScoringService.gradeInBatch(query, items); items graded.stream() .filter(g - g.score 0.5) .sorted((a,b)-Double.compare(b.relevanceScore,a.relevanceScore)) .toList(); } return items; }Stage0 FastPass是性能优化的关键如果返回结果数量小于等于2同时原始向量得分全部高于0.7说明检索结果置信度很高直接跳过后面两层过滤零额外延迟返回结果。线上大部分简单查询场景可以命中这个分支避免无谓的模型调用开销。Stage1 Reranker粗筛使用交叉编码器模型对检索片段重新打分过滤掉关键词重合但是语义无关的条目设置阈值过滤低分内容保留Top8条目进入下一环节。Stage2 LLM Grading精评交给大模型对每一条检索片段做0.1到1.0的相关性打分过滤主题沾边但是无法直接回答用户问题的条目。这一步会带来一定时延开销所以设计成可关闭选项对于强实时性场景可以直接关闭该环节只保留Reranker。过滤完成之后重新组装和原始工具输出格式完全一致的数据结构交给Agent。调整过滤阈值更换重排序模型开关任意过滤阶段都只需要修改中间件配置不需要改动Agent推理、工具调用相关业务代码做到业务逻辑和质量管控解耦。多模态能力把截图变成提问的一部分企业内部排查问题的时候用户最习惯的方式就是截图报错堆栈、异常界面、配置页面一张截图能够承载大量文字很难描述清楚的信息。如果知识问答系统只能接收纯文本用户需要手动把截图里的文字复制出来还要描述页面现象使用门槛很高。我们接入多模态能力实现截图即提问图片直接作为提问的组成部分。整套系统做了模型自动切换的校验逻辑。当消息上下文检测到图片系统自动处理模型选择策略。没有手动指定模型就自动切换到视觉语言模型用户已经指定视觉模型则正常执行如果用户强制指定纯文本大模型系统直接返回提示拒绝执行避免接口调用报错。这里有一个容易踩坑的细节校验不能只看当前轮次用户上传的图片还要遍历全部历史对话上下文。大模型多模态接口没有持久记忆每一轮请求都需要把对话历史中的图片重新携带进去。哪怕本轮用户没有上传新图片只要历史对话存在图片本轮就必须强制使用视觉模型否则会出现接口报错丢失图片上下文。图片从上传到渲染到回答完整走完一套生命周期。上传环节支持粘贴拖拽点击上传限制最大上传数量校验文件格式与大小。服务端接收到图片之后从内网对象存储读取字节转换Base64格式和文本消息组装成多模态消息结构送给大模型。会话回放阶段历史图片跟随消息聚合回放同时做用户归属过滤防止越权读取他人上传图片图片总体积做预算管控避免多轮对话携带过多图片造成请求体超限。Agent检索过程中如果命中带图片的文档资源也可以在回答内部嵌入图片文字和图片引用使用统一编号方便用户溯源查阅。生产环境可靠性设计分布式SSE断点续传知识Agent执行链路往往耗时很长多轮工具调用、文档精读、多层过滤完整链路执行几十秒属于常态。前端普遍依靠SSE流式推送拿到Agent中间思考过程和最终答案。线上环境SSE连接断开是非常高频的现象并不只有服务器宕机会造成断开。用户把页面切后台长时间挂起浏览器会自动断开SSE用户手动刷新页面重新加载关闭标签页再次打开移动端在WiFi和移动网络之间切换IP发生变化都会直接打断长连接。用户期望重新连接之后不需要重新提问就可以接着之前的对话继续接收流式输出看不到中断痕迹。很多开源Agent项目没有处理这类场景一旦SSE断开整个Agent会话直接销毁用户必须重新发送问题整套流程从头跑一遍生产环境完全不可接受。我们设计多实例SSE断点续传方案同时支持三种恢复路径系统自动判断选择最优路径。路径一是同实例恢复也是线上占比最高的场景页面刷新切后台网络短时抖动断开重连请求依旧落到原来处理会话的服务实例。Agent运行状态还保存在实例内存直接推送完整会话快照恢复全部历史继续推送后续事件几乎没有额外开销也不会读写Redis。路径二是跨实例转发负载均衡调度、网络切换重连请求被分发到另外一台服务实例。新实例读取Redis内部存储的会话路由表找到原始处理实例地址内部HTTP转发重连请求原始实例继续推送SSE事件新实例只做透传转发事件流依旧在原实例产生。路径三快照重建兜底原始服务实例彻底宕机无法访问。系统读取Redis持久化存储的完整会话快照在新实例重建Agent会话状态全部历史内容完整恢复继续输出回答用户完全感知不到故障。在方案选型阶段我们曾经考虑过Redis Pub/Sub事件广播的方案每一个实例产生事件写入Pub/Sub其他实例订阅消费。但是这套方案存在致命缺陷订阅动作存在延迟新的实例完成订阅的时候中间一部分事件已经发送完毕会造成事件丢失流式输出会出现内容缺失。所以我们最终方案Redis只存储会话路由信息与会话快照事件推送不走Redis依靠内部转发完成规避消息丢失风险。另外还有两个配套的可靠性细节。Agent执行工具调用阶段会长时间没有新业务事件推送浏览器会判定SSE连接已经断开我们每10秒发送SSE注释行心跳报文维持长连接活跃心跳报文不会影响前端业务渲染。用户短时间快速重复点击发送按钮会造成同一个会话同时触发两组Agent执行流程发生会话状态错乱。我们使用Redis SETNX原子操作实现分布式锁锁设置TTL过期时间防止服务异常之后锁无法释放保障同一个会话同一时间只会运行一套Agent实例。大模型服务本身也存在不稳定性服务限流、超时、5xx服务端错误都时有发生。系统实现模型容灾降级逻辑遇到可以重试的服务端异常自动切换备用模型继续执行用户侧无感知。4xx类客户端参数错误不执行降级直接返回错误给到前端交由用户修正输入。架构设计总结对比传统RAG的核心差异整套复合检索Agent系统和市面上简单套壳RAG方案相比有几点本质区别。第一点复合检索不等于多数据源简单拼接。普通多源RAG大多是固定逻辑遍历全部数据源拿到结果简单拼接。我们这套架构由Agent自主决策数据源组合搜索、精读交替循环执行多源信息交叉校验按照来源权重分层整合信息而不是把所有检索片段一股脑塞给大模型。第二点质量过滤不只是增加一个Reranker。很多项目上线只做一轮重排序我们搭建三级流水线FastPass优先保障简单查询性能Reranker处理粗粒度噪声LLM Grading做精细相关性校验不同层级各司其职全部模块支持开关配置适配不同业务时延需求。第三点SSE断点续传放弃Pub/Sub广播模式采用路由表加内部转发的实现。Redis只负责存储路由与会话快照不参与事件推送规避订阅延迟带来消息丢失的问题同时兼顾内存快照高性能恢复和宕机快照兜底两种场景。后续演进方向从知识问答走向个人知识助手当前整套系统已经落地完整能力多源复合检索三层检索质量过滤图片多模态输入分布式SSE断点续传已经可以支撑企业内部知识问答业务。后续演进可以分为短期精细化优化和长期愿景两个方向。短期的重点是针对不同数据源做差异化总结策略。不同类型的内部知识文本特征完全不一样不能使用同一套总结逻辑。结构化业务文档重点提取操作步骤配置参数聊天消息噪声很多需要过滤闲聊识别关键业务决策和时间线会议录音转写记录要区分会议类型提取结论、待办事项、责任人。针对每一类数据源定制化处理策略能够进一步提升输出质量。同时持续迭代评测体系覆盖更多边界case持续衡量检索召回、回答准确率各项指标。长期的目标是打造个人知识助手。现在每一轮对话都是互相独立后续可以激活框架内置的长期记忆、对话压缩、子Agent编排能力。系统记住用户岗位、工作偏好结合企业公共知识库用户个人私有数据叠加长期对话记忆做到跨会话信息关联不需要用户反复重复背景信息。整套底层框架能力已经预置不需要推倒重构后续可以逐步迭代上线。写在最后大模型企业知识落地很多团队把重心放在算法层面追逐新的检索算法新的重排序模型。但是真正走到生产环境就会发现制约系统体验的往往不是算法而是整套系统工程架构。怎么赋予Agent合理的自主决策权怎么做好检索结果质量管控怎么处理权限隔离怎么解决长会话流式稳定性怎么兼容截图这类真实业务输入这些工程问题才是决定产品能不能真正被业务方用起来的关键。复合检索Agent架构本质是把检索这件事从固定的流水线变成Agent可以自主思考行动的任务。不再是检索给什么大模型就只能回答什么Agent可以评估素材主动挖掘信息交叉校验冲突在策略约束之下完成完整知识获取流程。技术选型上优先复用成熟Agent运行时依靠提示词定义业务策略依靠中间件完成质量管控业务逻辑和框架核心解耦这样后续迭代维护成本更低也可以快速复用框架原生的各类生产级能力。