企业官网建设流程全解析

大模型落地企业知识场景的过程里，很多团队都会陷入一种看似简单的误区，拿到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接口，在工具执行前后注入过滤逻辑 Flux<AgentEvent> 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); } // 三层过滤主逻辑 List<RetrievedItem> filter(String query, List<RetrievedItem> 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运行时，依靠提示词定义业务策略，依靠中间件完成质量管控，业务逻辑和框架核心解耦，这样后续迭代维护成本更低，也可以快速复用框架原生的各类生产级能力。