最近大半年我一直在折腾企业级知识库和复杂任务自动化相关的架构方案。从最初简单拼装一个 RAG 流程到后来被需求逼着不断重构成混合体中间经历了几个明显的阶段先是在纯 RAG 上做文章加了各种路由和改写然后因为知识之间的关联关系太复杂转向了结构化的 LLM Wiki 方案再后来任务粒度越来越细又引入了多个 Agent 分工协作。说实话这三个方向——Agentic RAG、LLM Wiki、Multi-Agent——很多人一听就觉得是“差不多”的东西反正都是让大模型干活的框架。但我实际做下来发现它们解决的根本不是同一个层面的问题而且选型一旦错了后期返工成本非常高。这篇文章就把我对这三种架构的理解、选型取舍、以及实际踩坑的经验一次说清楚。1. 为什么需要重新思考 RAG 架构1.1 传统 RAG 到底卡在哪里经典 RAG 的流程说白了就是“先检索后生成”把用户问题拿去向量库找相似片段把 TopK 结果拼进 Prompt扔给大模型生成答案。这个模式在 demo 阶段非常爽几行代码就能跑通。但一上真实业务场景问题就暴露了。我接过一个项目客户那边有一堆产品规格书、历史故障记录、维修手册总量大概几万页文档。用传统 RAG 搭出来的效果用户问一个问题经常出现三个毛病检索回来的片段跟问题沾边但不精准比如用户问“这台设备在高温环境下为什么会误报”召回的是设备参数表而不是故障分析章节需要多跳推理的问题彻底垮掉比如“如果现场湿度超过阈值同时散热风扇又报了转速偏低应该先查哪个”这种问题要把多个文档的知识串联起来单轮 TopK 检索根本做不到对否定和条件约束不敏感用户说“不要停机的方式有哪些”系统可能召回一堆停机检修流程。根本原因在于传统 RAG 把“检索”当成了一次性动作且不依赖大模型对问题的理解。嵌入模型把文本向量化之后这种语义匹配在复杂约束和多跳关系上天然表现不佳。所以业界的共识是单轮检索的 RAG 只适合知识密度低、问题模式简单、答案基本就在单个段落里的场景。1.2 Agentic RAG 的核心思路Agentic RAG 的思路其实很朴素把“检索决策”交给大模型。它不再是问题进来就查一次向量库而是让一个“检索智能体”去自主规划该不该检索、先查哪个数据源、要不要改写问题、查完发现不够要不要再查一次。我真正开始用 Agentic RAG是被一个场景逼的。用户的问题经常不是“一句话”而是“一段描述”里面有背景、有条件、有目标。比如运维人员会问“三号产线昨晚报警记录显示温控异常我怀疑是冷却液循环问题但也可能是传感器漂移帮我根据历史类似案例和当天的日志给个排查顺序。”这种问题直接嵌入检索效果很差因为整段话的向量会稀释关键实体和约束。而 Agentic RAG 的做法是让大模型先生成一个检索计划拆解实体、识别关键条件、确定需要查哪几个库存然后分步执行。这就相当于让一个聪明的检索研究员去查资料而不是甩个关键词给搜索引擎就完事。1.3 Agentic RAG 对检索策略的改变把检索从单轮变成多轮真正需要解决的难点不是“多调几次 API”而是三件事拆解问题、判断信息缺口、终止条件。拆解问题大模型要能把“复杂问题”分解成多个子查询。这一步不仅靠模型能力还要靠提示约束。我试过不给任何框架直接让模型“思考”它经常把原问题换个说法再查一次完全没有拆解效果。判断信息缺口检索回来的片段是否足够回答主问题这个判断不能靠向量相似度得靠大模型自己对内容的“审读”——从段落里提取因果关系、条件分支、时间顺序然后对比用户问题的完整度。这一个环节的Prompt设计最考验人。终止条件Agentic RAG 最容易跑飞的就是无限检索。模型觉得材料不够就一直加检索轮次不仅烧钱还容易把正确答案淹没在噪声里。我一般给模型设两轮硬性上限超过之后必须基于已有内容生成或者明确回复“资料不足”。2. 转向 LLM Wiki 架构的动因与设计2.1 什么是 LLM Wiki 架构LLM Wiki 这个名字我第一次听到也觉得陌生。它并不是让大模型去搞一个“维基百科网站”而是指一种知识组织的思路把零散文档的内容拆成一篇篇互相链接、结构清晰的“知识条目”每个条目内容独立、拥有唯一标识条目之间通过引用关系形成一张知识网络。检索时不是去向量库里找相似片段而是沿着知识节点的关系做有目的的游走。这跟传统 RAG 的底层逻辑差别很大。传统 RAG 把文档切块后每块之间是“独立”的最多带上原文档上下文信息。而 Wiki 模式把“知识”本身建成了关系网络节点之间是有明确的逻辑线索的比如“A现象由B原因导致”、“C方案适用于D条件”。我在做设备排查类知识库时发现这类领域知识天然是网状结构一台设备的故障现象可能关联到机械结构、电气参数、环境条件、历史维修记录多个方面。切片式的 RAG 表达不了“某个故障的完整诱因链”而 Wiki 结构刚好能承载这种复杂关系。2.2 LLM Wiki 的核心要素实体、关系与确定性搭建一个 LLM Wiki我总结下来需要三个核心要素节点知识条目每一条内容自成一篇有标题、有正文、有稳定的标识符。节点不像切片那样按字数切割而是按“知识完整性”划分。一个节点讲一个独立知识点比如“某型号泵的密封圈更换标准”就是一个节点即使它只有两百字。关系链接节点之间要有明确的关联类型。我当前实践里最常用的关系类型包括“导致”、“修复方案”、“先决条件”、“相关参考”。有了这些关系检索时可以做到从“现象”节点出发顺着“原因”链找到“处置方案”。确定性这是调用Wiki时的关键。Wiki模式不能像RAG那样把“最相似的两段”塞进去而是要按图或按条件去精确定位需要的节点。谁触发哪个链接、访问哪些节点、按什么顺序读这些路径要有确定性不是每次让大模型“猜”一遍。2.3 与向量知识库的协同分工我要特别强调一点LLM Wiki 不是要把向量检索替代掉两者是协同的。切身体会下来最佳实践是“向量负责起点定位Wiki 负责路径游走”。具体来说用户进入一个问题时先用 Agentic RAG 的思路做一次检索规划从向量库召回最可能的几个起始节点一旦锁定了起始节点之后就切换到 Wiki 的确定性路径沿着实体关系往下钻。这样做的最大好处是减少了模型自由发挥的空间答案的可解释性大幅提高。我做过一个对比实验同一批客户问询记录分别用纯 RAG、Agentic RAG、Wiki 混合方案处理。结果在“多跳问题正确率”上Wiki 混合方案比纯 RAG 提升了大约三成而在“单点事实问答”上三者差距不大。说明 Wiki 的优势确实集中在知识关联复杂的场景而不是全面碾压。2.4 LLM Wiki 建设的经验从文档到知识的转化流程从原始文档建 Wiki 节点的工作量容易被低估。我最早以为拿大模型批量跑几下就出来了实际上需要几步精细化处理文本预处理与结构识别原始文档有PDF、有表格、有扫描图文。要先准确识别其中的章节结构、术语定义、操作步骤。这一步建议先做版式分析再用LLM辅助抽取而不是直接整篇喂进去生成节点。节点粒度控制节点太粗退化成文档摘要节点太细关系爆炸维护成本极高。我控制的经验标准是一个节点应能独立支撑回答一个“单一知识问题”。比如“阀门的日常保养周期”可以是一个节点但“阀门的全部维修知识”就该拆开。关系抽取与校验建好节点后要跑一遍关系抽取让大模型从每个节点中抽取出与其它节点的关联。这个环节必须有一个人工抽检的环节因为模型会把“可能相关”都划成关系导致网络过于稠密、噪音大。3. Multi-Agent 架构的引入与工程实践3.1 从单 Agent 到多 Agent 的临界点单个 Agent 再强大也有两个绕不过去的局限。第一是上下文窗口有限塞不下太长的过程信息第二是角色职责模糊一个 Agent 既要做检索、又要做推理、又要做工具调用提示词会互相冲突。我在项目里最早是一个“全干型”Agent代码里一个 Agent 类上挂了一堆能力结果越调越乱。后来碰到一个任务要同时分析生产异常报告、查阅保养记录、比对各批次零部件规格最后给出维修建议。单 Agent 的做法是顺序处理上下文越拉越长前面的信息被稀释后面的决策质量明显下降。我这才意识到需要拆成多个专注的 Agent各管一段最后汇总结论。Multi-Agent 架构的价值边界其实很清楚任务具有模块化结构、子任务之间可以并行、单个子任务依赖不同专长。大量简单任务强行上多 Agent不仅性能劣化成本也成倍增加。3.2 Multi-Agent 的核心机制通信与编排多 Agent 系统设计得好不好关键看两个机制通信协议和编排策略。通信协议解决“Agent 之间怎么传话”。我实践下来最实用的是结构化的消息而不是纯自然语言对话。每个消息带上发送者、接收者、任务类型、内容摘要、引用上下文 ID。结构化的好处是后面做追踪和审计非常方便纯自然语言对话流后期根本没法排查是谁传错了信息。编排策略解决“谁先谁后、谁主导谁”。目前主流有三类拓扑中心化调度由一个主控 Agent 负责任务拆分派发流水线编排按流程阶段串行传递网状自治多个 Agent 互相协商。我在实际系统里偏向中心化调度加局部流水线灵活度适中又不会彻底失控。有一次我尝试了完全自治的网状架构让几个 Agent 自由协商任务分配结果在一个模糊任务上它们互相踢皮球以及重复劳动白白烧掉大量 token。后来改成“总控拆任务、专员执行、汇总复核”模式稳定性和效率都明显提升。3.3 Multi-Agent 的风险控制与成本考量Multi-Agent 最容易被低估的坑是成本。每个 Agent 都要有自己的上下文窗口再加上彼此通信的消息记录token 消耗和请求延迟都是指数级增长的。我记得一次压力测试里一个原本单 Agent 调用两次就能完成的任务多 Agent 化之后内部上下文超过原方案的数倍延迟翻了几番。所以我现在规划 Multi-Agent 一定会做成本预算每个 Agent 预期上下文窗口有多大、最多执行几轮工具调用、整体超时上限是多少。项目里我把成本和执行时间当成一等公民指标来度量不只盯着“正确率”。另一个必须控制的是 Agent 的“幻觉传染”。一个 Agent 给了错误信息另一个 Agent 完全信任并在此基础上再加工错误会层层放大。为了防这个我给执行类 Agent 设置了“证据引用”的强制要求输出必须带上引用的文档片段或数据记录 ID。一旦引不出证据那就默认它是在编不让它的输出进入下一层。3.4 实战示例某跨平台系统上线前的知识诊断系统之前我参与过一个模拟项目X上线前的全量知识诊断系统。目标是从几千页历史项目文档、客户反馈和代码变更记录里自动归纳出上线前的风险清单和必备动作。这个系统的架构就典型用到了三种模式。先由入口 Agent 做意图识别把问题拆成“文档知识检索”、“历史案例比对”、“变更影响分析”三个子任务。每个子任务分别由一个专员 Agent 执行第一个走 Wiki 路径遍历结构化知识第二个走 Agentic RAG 做多轮检索召回相似案例第三个调用版本库工具拉取变更点。最后汇总 Agent 负责交叉验证结论一致性列出风险清单和置信度。整个流程跑起来之后效果最突出的不是单点能力而是“各司其职带来的稳定性”每个 Agent 的 Prompt 可以写得很纯粹不会为了兼顾别的任务而变得四不像。这个体验说实话只靠一个大杂烩 Agent 很难做到。4. 架构选型的核心原则与决策流程4.1 先诊断任务特征而不是先选架构我在踩过一堆坑之后现在选架构的第一个动作不是“决定上不上多 Agent”而是先诊断任务特征。我给自己整理了几组判断问题组成了一个小型决策矩阵任务特征适合架构关键原因单点知识问答答案在一个段落内传统 RAG成本最低延迟最低问题复杂、需要多轮检索和条件判断Agentic RAG检索策略可自适应知识之间关系强、需要可解释的关联推理LLM Wiki节点关系确定路径可审计任务可拆分为多个独立子任务并行执行Multi-Agent专长隔离并行效率更高链路型任务每一步依赖上一步结果流水线型单 Agent 或多 Agent 管线顺序明确上下文按需传递每次上新项目我会先把真实的高频问题类型列出来跑几条样本看失败模式再决定架构投入的深度。千万不要为了技术炫技把系统搞复杂复杂是有代价的它的代价就是成本和可维护性。4.2 成本、延迟与正确率的综合权衡业界讨论复杂架构时经常只盯着准确率一个维度。但我们在真正做工程落地时成本和延迟是非常硬的红线。给客户出方案时通常先算一笔账架构每变复杂一档单次问答的 token 消耗可能涨数倍p95 延迟可能从 2 秒变成 8 秒。我之前在两个方案里做过一个比较传统 RAG 的方案单次请求成本低但错误率高人工复核成本高复杂度较高的混合方案单次请求成本高了数倍但准确率明显提升客户那边直接采纳的比率也高了。算总账时候发现混合方案即便 token 成本大但因为减少了返工率总体更划算。这个案例说明一个原则正确率的价值不能孤立看要结合业务场景的容错成本来评估。诊断类、风控类的项目一次错误意味着损失较大的代价那多花 token 就是值得的而内容摘要、素材整理之类的场景容错率高优先保证成本和速度。4.3 决策步骤从需求到技术栈的落地流程总结我这段时间的实操一个复杂架构选型可以按下面五步走第一步梳理用户问题类型和知识特征。画出高频问题列表标注每个问题属于“单点问答”还是“多跳推理”还是“任务执行型”。第二步评估现有数据的结构化程度。如果数据是大量的半结构化文档规划 Wiki 建设的成本和收益看看值不值得先做一轮节点抽取。第三步确定任务的依赖关系。是并行分支多还是严格串行链路这决定要不要上 Multi-Agent。第四步做成本预算。估算三种方案下的单次调用成本、延迟和人工维护成本对比差异。第五步从最小可用架构起步逐步叠加。我个人的经验是先把传统 RAG 做好再给它加 Agentic 决策层如果还满足不了再把知识库改成 Wiki 结构最后才考虑拆分 Agent。直接一步到位上大而全的架构常常是给自己挖坑。5. 复杂架构的运维与迭代节奏5.1 可观测性和日志追踪架构复杂之后有一个环节一定不能省可观测性。我见过不少团队把系统搭起来效果看着正常但内部发生了什么完全是黑盒出了问题无从下手。我给自己的系统加的排查工具包括完整事件日志记录每个 Agent 的决策输入输出检索记录记录每次向量召回的结果和得分链路追踪记录一次请求经过了哪些节点耗时多少答案溯源每条生成结论必须带引用来源。有了这些在线上遇到用户投诉时能快速定位是检索环节召回错了还是 Agent 决策时理解偏了还是最后汇总阶段丢信息了。5.2 持续迭代的节奏复杂架构不是搭完就结束它是一个持续演化的过程。我目前实践下来的迭代节奏是先跑通主链路记录所有失败样本每周做一次失败分析把错误样本聚类找出是检索问题、上下文问题还是关系缺失问题针对每一类错误做定向优化优化检索策略、补充 Wiki 节点或调整 Agent 提示词再回归测试防止修一个 bug 带崩另一条链路。这套节奏看起来简单坚持下来效果比任何“一次性大重构”都靠谱。系统质量是一点一点磨出来的不是靠某次“魔法改造”变好的。5.3 什么人适合这套体系最后聊一下适用边界。如果你的系统只是内部工具日请求量不大问题也比较固定那老老实实用 RAG 就好真的不用把三个架构都拉进来。复杂架构适合的场景是知识库规模大、关系复杂多跳推理需求多任务本身是多步骤的跨多个数据源对答案可解释性要求高需要审计和溯源团队有足够精力维护知识节点、Agent 提示词和监控体系。如果条件不满足复杂架构只会变成负担。记住一个原则架构是服务业务的不是业务服务架构。6. 我的经验总结与个人建议这次从 Agentic RAG 到 LLM Wiki 再到 Multi-Agent 的组合实践我最大的感受是架构之间不是“谁替代谁”的竞争关系而是不同维度上的协作配合。Agentic RAG 提升的是检索的智能性LLM Wiki 解决的是知识的组织形态Multi-Agent 处理的是任务的执行结构。三者真正合体才能扛住复杂业务场景的考验。实际落地过程中我踩过不少坑也总结了一些值得反复提醒自己的经验不做需求分析就上复杂架构一定会付出惨痛的代价。所有架构选型都应该从真实问题的失败模式出发。优先保证可维护性。节点结构、Agent 分工、链路追踪都需要清晰的文档和规范否则三个月后连自己都看不懂系统为什么这样设计。控制复杂度的成本预期多做小规模验证。在正式投钱研发之前用少量样本验证新架构是否真的能解决问题。注意安全风险管理。涉及真实业务数据的项目必须做好访问控制和日志审计越是自治化程度高的系统越要保留人工兜底和熔断机制。培养团队的工程素养。复杂架构不是某个“天才”单独能维护的需要整个团队都理解设计决策和权衡依据。后续我准备在这个基础上把 Wiki 的自动更新链路再做深一层让新增文档能自动识别与既有节点的关系并触发更新而不是靠统一批量重建。这条路要是走通了维护成本还能再降一个台阶。