1. 从能跑通到敢上线复杂架构选型的真实分水岭做检索增强生成RAG系统的人大概都经历过这样一个阶段Demo 跑通了效果看着还行于是信心满满地准备往生产环境推。结果一上线问题全来了——用户问一个需要跨文档推理的问题系统检索回来一堆碎片拼出来的答案驴唇不对马嘴或者用户追问一句那第二条呢整个对话上下文直接崩掉模型开始胡言乱语。这时候你才意识到单轮 RAG 的天花板比想象中低得多。我接触过不少团队在 RAG 这条路上踩的坑高度相似一开始用最朴素的向量检索 拼接 Prompt 一次生成方案处理简单事实型问答没问题但一旦遇到多跳推理、需要调用外部工具、或者要维护长对话状态这套架构就捉襟见肘了。于是大家开始寻找更复杂的方案这时候三个词会反复出现在视野里Agentic RAG、LLM Wiki、Multi-Agent。这三个方向听起来都很高级但它们的定位、适用场景和落地成本完全不同。很多人容易犯的错误是看到某个架构在论文里效果好就无脑往自己的项目里套结果复杂度飙升、调试成本爆炸、效果反而下降。我自己就在一个知识库问答项目里因为过早引入 Multi-Agent 编排导致整个系统的可观测性变得极差一个简单的检索失败要花半天才能定位到是哪个 Agent 的哪一步出了问题。所以这篇内容想聊的不是哪个架构最先进而是在什么条件下该选哪个、为什么这么选、以及选了之后会遇到什么。我会把这三个方向拆开讲清楚它们的核心机制、适用边界、实操中的取舍逻辑以及我自己踩过的那些坑。如果你正在纠结要不要从朴素 RAG 升级、或者已经在复杂架构里挣扎这篇应该能帮你少走一些弯路。需要先说明一点这三个方向并不是互斥的实际系统里经常是组合使用。但为了讲清楚各自的本质我会先分开拆解最后再讲它们怎么协同。2. Agentic RAG让检索本身变成一个会思考的过程2.1 朴素 RAG 到底卡在哪一步要理解 Agentic RAG 的价值得先看清楚朴素 RAG 的失效模式。朴素 RAG 的流程是固定的用户提问 → 向量化 → 检索 Top-K 文档 → 拼接进 Prompt → 生成答案。这个流程的问题在于它假设一次检索就能拿到所有需要的信息但现实往往不是这样。举个具体例子。用户问我们公司去年 Q3 推出的那款产品它的定价策略和竞品相比有什么优势这个问题至少包含三个子任务找到去年 Q3 推出的产品是哪个、获取它的定价策略、获取竞品定价并做对比。朴素 RAG 一次性检索很可能只召回了产品介绍文档但竞品信息散落在另一批市场分析报告里根本没被检索到。模型拿到不完整的信息只能硬编一个答案或者干脆说根据提供的信息无法回答。另一个典型失效场景是查询与文档的语义鸿沟。用户用口语提问文档用的是专业术语向量相似度匹配不上。比如用户问这个东西坏了怎么修文档标题是设备故障排查指南语义上相关但字面差异大检索质量就会打折扣。还有一个容易被忽视的问题检索回来的内容质量参差不齐。Top-K 里可能混入了大量无关或低质文档这些噪声会干扰模型生成甚至导致幻觉。朴素 RAG 没有机制去判断这批检索结果到底够不够用、要不要再检索一次。2.2 Agentic RAG 的核心把检索决策交给模型Agentic RAG 的本质是把检索从一个固定步骤变成一个由模型自主决策的循环过程。模型不再是被动接收检索结果而是可以主动判断当前信息够不够需不需要换个查询词再检索要不要调用其他工具这个循环可以迭代多轮直到模型认为信息充分为止。具体来说Agentic RAG 通常包含几个关键能力查询改写Query Rewriting模型根据原始问题生成更适合检索的查询语句。比如把口语化的这个东西坏了怎么修改写成设备故障排查 维修步骤提升召回率。检索充分性判断Retrieval Sufficiency Check模型评估当前检索结果是否足以回答问题如果不够决定下一步动作——是换查询词重检、还是扩大检索范围、还是调用其他数据源。多轮检索与信息聚合对于多跳问题模型可以拆解成子问题逐个检索最后聚合信息生成答案。工具调用除了向量检索模型还可以调用搜索引擎、数据库查询、API 等外部工具把 RAG 从文档问答扩展成通用信息获取。这套机制的核心价值在于自适应。简单问题一次检索就够复杂问题自动多轮迭代不会像朴素 RAG 那样一刀切。2.3 一个可落地的 Agentic RAG 循环设计理论讲完了说说实际怎么搭。我自己的做法是设计一个显式的状态机而不是让模型完全自由发挥。完全自由的 Agent 循环在生产环境里非常危险——它可能陷入死循环、可能调用不该调用的工具、可能消耗大量 token 却得不到结果。我的状态机大致是这样的状态INIT → REWRITE → RETRIEVE → EVALUATE → (GENERATE | REWRITE | TOOL_CALL) → END每个状态的具体逻辑INIT接收用户问题初始化上下文。REWRITE调用模型改写查询。这里有个经验——改写时要把对话历史一起传进去否则多轮对话里的指代那第二条呢无法正确解析。RETRIEVE执行检索拿到 Top-K 文档。EVALUATE这是最关键的一步。调用模型判断检索结果是否充分。我用的 Prompt 大致是让模型输出一个结构化结果{sufficient: true/false, reason: ..., next_action: generate/rewrite/tool}。GENERATE信息充分生成最终答案。REWRITE信息不足带着为什么不足的反馈重新改写查询回到 RETRIEVE。TOOL_CALL需要外部工具调用后把结果并入上下文再评估。这里有几个实操细节值得展开。循环次数必须设上限我一般设 3 次超过就强制生成并在答案里标注信息可能不完整。不设上限的话遇到模型判断不准的情况会无限循环token 成本直接失控。EVALUATE 的 Prompt 要写得非常具体不能只说判断信息是否充分要给出判断标准比如如果问题涉及多个实体对比必须确保每个实体的信息都被检索到。改写查询时要保留原始查询把改写后的查询和原始查询一起检索取并集这样能兼顾精确匹配和语义匹配。2.4 Agentic RAG 的代价延迟、成本和不可预测性Agentic RAG 不是免费的午餐。最直接的代价是延迟。朴素 RAG 一次检索一次生成端到端可能 1-2 秒Agentic RAG 多轮循环下来5-10 秒是常态复杂问题甚至更久。如果你的场景对响应速度敏感比如实时客服这个延迟可能不可接受。成本也是问题。每一轮循环都要调用模型做判断和改写token 消耗是朴素 RAG 的好几倍。我算过一笔账一个中等复杂度的查询Agentic RAG 的 token 消耗大约是朴素 RAG 的 4-6 倍。如果按量付费这个成本差异很可观。不可预测性是最让人头疼的。同样的输入模型可能这次判断信息充分直接生成下次判断不充分多循环一轮导致响应时间和结果都不稳定。这在需要严格 SLA 的生产环境里是个大问题。我的建议是Agentic RAG 适合那些准确性远比速度重要的场景比如法律文书检索、医疗知识问答、复杂技术文档查询。如果只是简单的 FAQ 问答朴素 RAG 加一个好的重排序Rerank模型效果可能就够了没必要上 Agentic。3. LLM Wiki把知识组织成模型能读懂的结构3.1 为什么文档切片 向量检索经常不够用LLM Wiki 这个方向解决的是另一个维度的问题知识的组织方式。朴素 RAG 把文档切成固定长度的 chunk每个 chunk 独立向量化检索时按相似度召回。这种方式的问题在于它破坏了文档的原有结构。一篇技术文档原本有章节、有层级、有交叉引用。切成 chunk 之后这些结构信息全丢了。检索回来的 chunk 可能只是某个章节中间的一段缺少上下文模型拿到之后很难理解它在整个文档中的位置和意义。更麻烦的是有些知识是跨 chunk 的——一个概念的定义在 A 段它的应用场景在 B 段限制条件在 C 段。固定切片很难保证这些相关信息被一起召回。还有一个问题是知识的更新和维护。文档更新了你得重新切片、重新向量化整个索引都要重建。如果知识库很大这个成本不低。而且切片策略一旦定了想改就很难因为改了要全量重建。3.2 LLM Wiki 的核心思路结构化知识 模型友好格式LLM Wiki 的思路是不要被动地等模型来检索而是主动把知识组织成模型容易理解和使用的结构。它借鉴了传统 Wiki 的理念——知识不是一堆孤立的文档而是一个相互链接、有层级、有元数据的网络。具体做法通常包括几个层面第一保留文档的层级结构。不是简单按字数切 chunk而是按文档的自然结构章节、小节、段落来切每个 chunk 带上它的层级路径信息。比如一个 chunk 的元数据里标注所属章节第 3 章 配置管理 3.2 环境变量配置这样模型拿到 chunk 时就知道它在文档中的位置。第二建立知识之间的链接。文档里提到的概念、术语、相关文档都建立显式的链接关系。检索到一个概念时可以顺着链接找到它的定义、示例、相关概念。这有点像知识图谱的思路但更轻量不需要复杂的图谱构建。第三用模型友好的格式组织。把知识组织成 Markdown、结构化 JSON 或者专门的 Wiki 格式让模型在生成时能直接引用。比如把某个概念的所有相关信息定义、参数、示例、注意事项组织成一个结构化的条目模型需要时直接取用而不是从多个 chunk 里拼凑。第四支持增量更新。知识条目是独立的更新某个条目不影响其他条目不需要全量重建索引。这对维护大型知识库非常重要。3.3 构建 LLM Wiki 的实操路径从零构建一个 LLM Wiki我的经验是分四步走第一步知识梳理与结构化。把现有文档过一遍识别出核心概念、实体、流程建立它们之间的关系。这一步最费时间但最关键。我一般会先做一个概念清单列出所有需要被检索的知识单元然后标注它们之间的关系属于、依赖、相关、对比等。第二步设计知识条目的 Schema。每个知识条目应该包含哪些字段我的常用 Schema 是{ id: concept-001, title: 环境变量配置, type: concept, content: 环境变量用于在不同部署环境间切换配置..., examples: [export DB_HOSTlocalhost, ...], related: [concept-002, concept-005], parent: chapter-003, metadata: {updated_at: 2024-01-15, version: 2.1} }这个 Schema 的好处是检索时不仅能拿到内容还能拿到示例、相关条目、所属章节模型生成时可以按需引用。第三步检索层设计。LLM Wiki 的检索不只是向量相似度还要结合结构信息。我的做法是混合检索向量检索负责语义匹配关键词检索负责精确匹配然后根据知识条目的层级和链接关系做扩展。比如检索到环境变量配置自动把它的相关条目配置文件格式部署流程也纳入候选。第四步生成层的引用机制。模型生成答案时要能引用具体的知识条目而不是笼统地说根据文档。我会在 Prompt 里要求模型标注引用来源比如根据 [concept-001] 环境变量配置...。这样既方便溯源也方便后续评估检索质量。3.4 LLM Wiki 与 RAG 的关系互补而非替代需要澄清一个常见误解LLM Wiki 不是要替代 RAG而是给 RAG 提供更好的知识底座。RAG 的检索机制仍然有用只是检索的对象从无结构的 chunk变成了结构化的知识条目。实际系统里我通常是这样组合的底层用 LLM Wiki 组织知识检索层用混合检索向量 关键词 结构扩展生成层用 Agentic RAG 的循环机制做充分性判断和多轮检索。这样既有结构化的知识组织又有自适应的检索决策。LLM Wiki 的代价主要是前期投入大。知识梳理和 Schema 设计需要领域专家参与不是纯技术活。而且一旦知识库规模大了维护成本也不低。但如果你的场景是领域知识密集、更新频繁、对准确性要求高这个投入是值得的。反过来如果是通用问答、知识更新不频繁朴素 RAG 可能更划算。4. Multi-Agent什么时候真的需要多个 Agent 协作4.1 单 Agent 的能力边界在哪里Multi-Agent 是这三个方向里最容易被滥用的。很多人一听到多智能体协作就觉得高级恨不得把所有功能都拆成 Agent。但实际上大部分场景单 Agent 就够了强行拆成 Multi-Agent 只会增加复杂度和调试难度。单 Agent 的边界在哪我的判断标准是如果一个任务的所有子步骤都可以用同一套工具、同一个上下文、同一个决策逻辑完成那就不需要 Multi-Agent。比如一个文档问答 Agent它需要检索、判断、生成这些步骤共享同一个知识库和同一套 Prompt 逻辑单 Agent 完全能搞定。真正需要 Multi-Agent 的场景通常是子任务之间差异极大需要不同的工具集、不同的专业知识、甚至不同的模型。比如一个系统既要处理代码生成又要处理数据分析还要处理自然语言问答这三类任务的 Prompt 设计、工具调用、输出格式完全不同硬塞进一个 Agent 会导致 Prompt 臃肿、决策混乱。4.2 Multi-Agent 的三种典型协作模式如果确实需要 Multi-Agent常见的协作模式有三种第一种路由模式Router。一个主 Agent 负责判断任务类型然后路由到对应的专业 Agent。比如用户提问主 Agent 判断这是代码问题还是数据问题分别交给代码 Agent 和数据 Agent。这种模式最简单Agent 之间不需要交互各自独立工作。第二种流水线模式Pipeline。多个 Agent 按顺序协作前一个的输出是后一个的输入。比如检索 Agent → 分析 Agent → 生成 Agent每个 Agent 专注一个环节。这种模式适合流程固定的任务但灵活性差中间环节出错会传导到后面。第三种协作模式Collaborative。多个 Agent 可以相互通信、协商、甚至辩论共同完成一个任务。比如一个 Agent 提出方案另一个 Agent 批判第三个 Agent 综合。这种模式最灵活但也最难控制容易出现无限讨论或者相互甩锅的情况。我的经验是生产环境优先用路由模式其次流水线协作模式慎用。协作模式在论文里看起来很美好但实际落地时Agent 之间的通信成本、状态同步、错误处理都是大坑。我见过一个项目用协作模式做方案评审结果两个 Agent 互相礼貌地推诿循环了十几轮都没结论最后只能人工介入。4.3 用 Multi-Agent 重构 RAG 的得与失把 Multi-Agent 用到 RAG 场景典型的重构方式是把 RAG 流程拆成几个 Agent查询理解 Agent、检索 Agent、结果评估 Agent、生成 Agent。每个 Agent 专注自己的环节通过消息传递协作。这么做的好处是职责清晰每个 Agent 的 Prompt 可以针对性优化调试时也容易定位问题。比如检索效果不好就去看检索 Agent 的日志不用在一大坨 Prompt 里找原因。但代价也很明显。首先是通信开销Agent 之间传递消息需要序列化和反序列化还要维护共享状态这些都会增加延迟。其次是错误累积如果查询理解 Agent 理解错了后面的检索和生成都会跟着错而且很难回溯。最后是调试复杂度单 Agent 的日志是一条线Multi-Agent 的日志是多条线交织排查问题时要来回对照。我自己的取舍是只有当单个 Agent 的 Prompt 复杂到难以维护或者子任务确实需要不同模型/工具时才拆成 Multi-Agent。否则用一个设计良好的单 Agent配合清晰的状态机往往更稳定、更好维护。4.4 一个务实的 Multi-Agent 落地检查清单如果你确实决定上 Multi-Agent我建议先过一遍这个检查清单检查项判断标准不满足的后果子任务是否真的异构不同子任务需要不同工具集或模型拆了等于没拆徒增复杂度是否有明确的终止条件每个 Agent 都有清晰的完成/失败判定无限循环成本失控状态如何共享有明确的共享状态管理机制Agent 之间信息不一致错误如何传播有错误隔离和降级策略一个环节出错全盘崩溃是否可观测每个 Agent 的输入输出都可追踪出问题无法定位延迟是否可接受端到端延迟在业务容忍范围内用户体验差可能被弃用这个清单里终止条件和可观测性是最容易被忽视的。我踩过的坑就是没设终止条件两个 Agent 互相等待对方先输出结果卡死。后来加了超时和最大轮次限制才解决。5. 三者如何协同一个分层架构的取舍逻辑5.1 分层设计知识层、检索层、编排层把 Agentic RAG、LLM Wiki、Multi-Agent 放在一起看它们其实对应系统的不同层次LLM Wiki 是知识层负责知识的组织、存储、更新。它决定了系统知道什么。Agentic RAG 是检索层负责从知识层获取信息、判断充分性、多轮迭代。它决定了系统怎么找到需要的信息。Multi-Agent 是编排层负责协调不同任务、不同工具、不同模型。它决定了系统怎么组织复杂的处理流程。这三层不是必须全上。最简单的系统可能只有知识层LLM Wiki 基础检索中等复杂度的加 Agentic RAG 做自适应检索只有任务确实异构、需要多专业协作时才上 Multi-Agent 编排层。5.2 按场景选型什么情况下上哪一层我整理了一个选型参考按场景复杂度递增场景特征推荐架构理由简单 FAQ知识稳定朴素 RAG Rerank成本低够用多跳推理需要多轮检索Agentic RAG自适应检索解决信息不完整领域知识密集更新频繁LLM Wiki Agentic RAG结构化知识提升检索质量任务异构需要多工具协作LLM Wiki Agentic RAG Multi-Agent编排层协调复杂流程关键原则是从简单开始按需升级。不要一上来就搭最复杂的架构。我见过太多项目一开始就上 Multi-Agent结果连基础的检索质量都没搞定复杂架构反而掩盖了核心问题。5.3 复杂度与收益的平衡点怎么找找平衡点的核心方法是量化评估。每引入一层复杂度都要能说清楚它带来了什么可量化的收益。比如引入 Agentic RAG 后多跳问题的回答准确率从 60% 提升到 85%但延迟从 1.5 秒增加到 6 秒。这个 trade-off 是否可接受取决于业务场景。引入 LLM Wiki 后检索召回率从 70% 提升到 90%但前期投入了 2 周做知识梳理。如果知识库会长期维护这个投入值得如果是一次性项目可能不划算。引入 Multi-Agent 后复杂任务的完成率提升了但调试时间增加了 3 倍。如果团队有足够的工程能力维护可以上否则慎重。我的经验是先做单层优化做到极致再考虑加层。很多时候把检索的 Rerank 模型换好一点、把 Prompt 调优一点、把 chunk 策略改合理一点效果提升就很明显根本不需要上复杂架构。6. 踩坑实录那些让我重新思考架构选择的瞬间6.1 Agent 循环失控一次 token 账单的教训前面提到过 Agentic RAG 的循环要设上限这个教训是用真金白银换来的。有一次测试环境没设循环上限一个用户问了个模糊问题模型判断信息不充分要重检改写后的查询还是模糊又判断不充分如此循环了二十多轮直到把上下文塞满才停。那一次查询消耗的 token 是正常查询的几十倍。后来我加了硬性限制最大循环 3 次超过强制生成并标注信息可能不完整。同时在 EVALUATE 环节加了如果连续两次改写后的查询相似度超过阈值直接判定为无法通过检索解决走降级路径。这个相似度判断很简单就是比较两次改写查询的编辑距离如果几乎一样说明改写没起作用再循环也是浪费。6.2 知识结构化的过度设计Schema 不是越细越好做 LLM Wiki 时我一开始把 Schema 设计得非常细每个知识条目有二十多个字段包括各种元数据、标签、关系。结果维护成本极高录入一条知识要填半天而且很多字段根本用不上。后来我砍到只剩六个核心字段id、title、content、examples、related、parent。够用了。Schema 的设计原则是最小可用先满足核心检索需求后续有需要再加字段。过度设计不仅增加维护成本还会让模型在生成时被无关字段干扰。6.3 Multi-Agent 的礼貌死锁终止条件比协作逻辑更重要前面提过的两个 Agent 互相推诿是我在协作模式里踩的最大的坑。当时设计的是方案 Agent和评审 Agent方案 Agent 出方案评审 Agent 提意见方案 Agent 根据意见修改循环直到评审通过。结果评审 Agent 总是能挑出毛病方案 Agent 总是能改但永远达不到完美循环停不下来。解决办法是给每个 Agent 设明确的终止条件评审 Agent 最多提 3 轮意见3 轮之后必须给出通过或不通过的明确结论方案 Agent 最多修改 3 次3 次之后如果还没通过就升级到人工处理。有了硬性终止条件死锁问题就解决了。6.4 检索质量才是地基别让复杂架构掩盖基础问题最后一个坑也是最根本的很多人上复杂架构是因为基础检索质量不行想用复杂架构来绕过这个问题。但这是本末倒置。如果检索回来的文档本身就是错的、不相关的再复杂的 Agent 循环、再好的知识结构、再多的 Agent 协作都救不回来。我的建议是在上任何复杂架构之前先把基础检索做到位chunk 策略是否合理、Embedding 模型是否适合你的领域、有没有加 Rerank、Top-K 设置是否合适。这些基础工作做到位可能 80% 的问题就解决了。剩下的 20% 才需要复杂架构来解决。7. 我个人的架构选型心得聊了这么多最后分享几点我自己的体会不算总结就是一些实际做项目时形成的判断习惯。第一永远从最简单的方案开始。新项目我默认用朴素 RAG Rerank跑一段时间收集 bad case看看到底是什么问题。是检索召回不够还是多跳推理不行还是知识组织混乱根据具体问题再决定加哪一层。上来就搭复杂架构往往是在解决想象中的问题。第二复杂度要有退出机制。每加一层复杂度都要想清楚如果这层没效果怎么退回去Agentic RAG 的循环能不能关掉降级成单轮Multi-Agent 能不能合并成单 Agent有退出机制才敢大胆尝试。第三可观测性比架构本身更重要。一个简单但日志清晰、每步可追踪的系统比一个复杂但黑盒的系统好维护得多。我在每个关键节点都加了结构化日志记录输入、输出、耗时、token 消耗。出问题时这些日志比任何架构图都有用。第四别被先进绑架。Agentic RAG、LLM Wiki、Multi-Agent 都是好方向但不是每个项目都需要。判断标准永远是这个复杂度能不能带来可量化的业务收益。不能就不加。第五留出人工兜底的口子。再好的架构也有搞不定的时候。我在系统里都留了转人工的路径当 Agent 循环超限、或者置信度低于阈值时自动转人工处理。这不是架构的失败而是对用户负责。这些心得没有什么高深的理论都是一个个项目磨出来的。架构选型这件事说到底不是技术问题是对业务场景的理解问题。理解得越深越知道该在哪里做减法。