1. 三种架构到底在解决什么问题1.1 从一个真实困境说起去年下半年我接手了一个内部知识库问答系统的重构。老系统是最朴素的 RAG：用户提问，向量检索 top-k 文档片段，拼进 prompt，交给大模型生成答案。上线头两个月效果还行，到了第三个月，问题开始集中爆发——用户问"上季度的报销政策调整对海外差旅有什么影响"，系统检索回来的全是零散的报销条目，模型硬生生拼出一段看似合理但完全错误的答案。更麻烦的是，有些问题需要先查政策文档、再查具体案例、最后做对比分析，单轮检索根本覆盖不了这种多跳推理。那段时间我几乎把市面上能看到的架构方案都试了一遍，从最基础的 RAG 一路踩到 Agentic RAG、LLM Wiki、Multi-Agent。踩完之后最大的感受是：这三种架构不是递进关系，不是"新的比旧的好"，而是各自在解决不同维度的问题。选错了，不是效果差一点，而是整个系统的维护成本会失控。这篇文章我想把这三个架构的取舍逻辑讲透。核心关键词就三个：Agentic RAG、LLM Wiki、Multi-Agent。如果你正在做知识密集型应用、智能助手或者复杂任务编排，不管你是刚入门还是在做架构选型，这篇应该都能帮你少走点弯路。我不会只讲概念，会把每个架构的适用边界、实现细节、踩坑经验都摊开说。1.2 三种架构的本质差异先把三者的定位说清楚，不然后面容易混。Agentic RAG本质上是"带决策能力的检索"。传统 RAG 是"检索一次→生成一次"的固定流水线，Agentic RAG 把检索变成了一个可以循环、可以判断、可以自我修正的过程。模型会自己决定要不要检索、检索什么、检索结果够不够、要不要再检索一轮。它解决的是"单轮检索覆盖不了复杂问题"的痛点。LLM Wiki本质上是"结构化的知识沉淀层"。它不是让模型每次现查现答，而是把领域知识预先整理成一套模型能高效读取的结构化文档体系——有点像给模型建了一个它自己能维护的维基百科。它解决的是"知识碎片化、检索命中率低、答案不一致"的问题。Multi-Agent本质上是"任务分解与协作"。把一个复杂任务拆给多个各有专长的 Agent，每个 Agent 负责一块，通过消息传递协作完成。它解决的是"单一模型上下文有限、单一 prompt 难以兼顾多种能力"的问题。这三者的关系，我习惯用一个类比：Agentic RAG 是"会自己找资料的实习生"，LLM Wiki 是"团队共同维护的知识手册"，Multi-Agent 是"一个分工明确的项目组"。你可以只用其中一个，也可以组合使用，但组合的代价是复杂度指数级上升。2. Agentic RAG：让检索学会"自己拿主意"2.1 传统 RAG 的天花板在哪传统 RAG 的流程固定得像一条流水线：embedding 查询→向量库检索→重排序→拼 prompt→生成。这条流水线在"问题简单、答案集中在少数文档"的场景下非常好用，成本低、延迟低、可控性强。但它有三个硬伤。第一，检索时机是死的。不管问题需不需要外部知识，它都会去检索，浪费算力还可能引入噪声。第二，检索轮次是死的。一次检索不够就是不够，模型没有机会说"我再查一下"。第三，无法处理多跳问题。像"某产品的退货政策在最近一次修订中改了什么，这个改动对跨境订单有什么影响"这种问题，需要先定位政策文档、再定位修订记录、再做影响分析，单轮检索拿不到完整证据链。我实测过一个数据：在单跳事实型问题上，传统 RAG 和 Agentic RAG 的准确率差距不到 5%；但在多跳推理问题上，差距能拉到 30% 以上。这就是 Agentic RAG 的价值区间。2.2 Agentic RAG 的核心循环设计Agentic RAG 的关键在于把"检索"从一个步骤变成一个可控循环。我常用的循环结构是这样的：意图判断：模型先判断这个问题需不需要外部知识。有些问题靠自身知识就能答，硬检索反而添乱。查询改写：把用户的口语化问题改写成适合检索的查询。这一步很关键，用户问"那个新政策咋样了"，直接拿去检索基本废掉。检索执行：调用检索工具，拿到候选片段。充分性评估：模型判断检索结果是否足以回答问题。不够就回到第 2 步，换个查询再检。生成与引用：基于充分证据生成答案，并标注来源。这个循环的退出条件要设计好，否则容易死循环。我的做法是设一个最大轮次（通常 3 轮），同时设一个"边际收益"判断——如果新一轮检索没有带来新的有效信息，就强制退出。# 简化的 Agentic RAG 循环骨架（伪代码） def agentic_rag(query, max_rounds=3): context = [] for round in range(max_rounds): rewritten = rewrite_query(query, context) docs = retrieve(rewritten) new_docs = filter_new(docs, context) if not new_docs and round > 0: break # 边际收益为零，退出 context.extend(new_docs) if is_sufficient(query, context): break return generate(query, context)2.3 查询改写与充分性评估的实操细节这两个环节是 Agentic RAG 的成败关键，也是最容易被做砸的地方。查询改写我踩过的坑是：让模型自由改写，结果它把简单问题改得越来越复杂，检索反而跑偏。后来我改成"受约束改写"——给模型明确的改写策略，比如"如果问题包含指代词，先消解指代""如果问题涉及时间，补全时间范围""如果问题涉及对比，拆成两个子查询"。约束之后，检索命中率明显稳定。充分性评估更微妙。早期我用的是让模型直接回答"够不够"，结果模型倾向于说"够了"，因为它有生成答案的冲动。后来我改成让模型做证据映射：把问题的每个子需求列出来，逐一标注"有证据/无证据/证据矛盾"。这样评估就客观多了，模型不容易糊弄自己。实操心得：充分性评估的 prompt 里一定要加一句"如果证据不足，明确说不足，不要勉强回答"。这句话能显著降低幻觉率，我实测下来幻觉率从 12% 降到了 4% 左右。2.4 Agentic RAG 的成本与延迟权衡Agentic RAG 不是免费的。多轮检索意味着多次 embedding 调用、多次向量库查询、多次 LLM 调用。我做过一个粗略统计：一个平均 2.3 轮的 Agentic RAG 查询，token 消耗是传统 RAG 的 3 到 5 倍，延迟是 2 到 4 倍。所以我的建议是分级处理：先用一个轻量分类器判断问题复杂度，简单问题走传统 RAG，复杂问题才走 Agentic RAG。这个分类器不需要很准，哪怕只有 70% 的准确率，也能省下大量成本。我用的分类器就是一个小的微调模型，判断"单跳/多跳"，推理成本几乎可以忽略。3. LLM Wiki：把知识沉淀成模型能读的"手册"3.1 为什么检索总是命中不了做 RAG 的人都有一个共同的痛：明明知识库里就有答案，检索就是命中不了。原因通常有三个。第一，知识碎片化。同一个主题的信息散落在几十个文档里，检索只能拿到零碎片段。第二，表述不一致。用户问"退款"，文档里写的是"退货返款"，embedding 相似度不够。第三，缺乏上下文。一个片段单独拿出来看，根本不知道它在说什么。LLM Wiki 的思路是：与其每次现查现拼，不如预先把这些知识整理成结构化的、自洽的文档体系。这个体系不是给人看的传统 wiki，而是专门为 LLM 读取优化的——每个条目自包含、有明确的层级、有交叉引用、有统一的术语表。3.2 LLM Wiki 的结构设计原则我设计 LLM Wiki 时遵循四条原则，都是踩坑踩出来的。第一条：条目自包含。每个条目要能独立回答一类问题，不依赖读者（也就是模型）去翻别的条目才能理解。这意味着要适度冗余，同一个概念在不同条目里可以重复出现，只要保证每个条目读起来是完整的。第二条：层级不超过三层。层级太深，模型在检索和阅读时容易迷路。我一般用"领域→主题→条目"三层，再深就拆成独立文档。第三条：术语统一。建一个术语表，所有条目里的表述都对齐到术语表。用户问"退款"，条目里就统一写"退款"，不要一会儿"退货返款"一会儿"资金退回"。第四条：显式交叉引用。条目之间用明确的引用标记连接，比如"参见[条目ID]"。这样模型在检索到一个条目后，能顺着引用找到相关条目，形成知识网络。3.3 从原始文档到 LLM Wiki 的构建流程构建 LLM Wiki 不是简单地把文档切块，而是一个知识重构的过程。我的流程分四步：知识抽取：从原始文档里抽取实体、关系、属性。这一步可以用 LLM 辅助，但一定要人工审核，因为 LLM 抽取容易漏掉隐含信息。主题聚类：把抽取出的知识按主题聚类，形成条目的雏形。聚类粒度要适中，太粗条目太大，太细条目太多。条目撰写：为每个条目撰写自包含的内容。这一步我建议让领域专家参与，因为 LLM 写出来的条目往往"正确但不到位"，缺少实操细节。一致性校验：全量检查术语一致性、交叉引用有效性、层级合理性。这一步最枯燥但最不能省。# 条目示例：退款政策 ## 适用范围 适用于所有线上订单，不含线下门店交易。 ## 核心规则 - 签收后 7 天内可申请无理由退款 - 定制类商品不支持无理由退款 - 退款到账时间为 3-5 个工作日 ## 关联条目 - 参见 [退货流程] - 参见 [跨境订单特殊规则]3.4 LLM Wiki 与 RAG 的配合方式LLM Wiki 不是要取代 RAG，而是给 RAG 提供更好的检索底座。我的做法是：把 LLM Wiki 的条目作为检索单元，每个条目单独 embedding。因为条目是自包含的，检索命中一个条目就等于拿到了一段完整知识，不需要再拼接碎片。实测下来，同样的知识库，整理成 LLM Wiki 后，检索命中率从 61% 提升到了 84%，答案一致性也明显改善。代价是前期构建成本高——我那个知识库大概花了三周时间做重构，但后续维护成本反而降低了，因为知识结构清晰了，更新时知道该改哪里。注意事项：LLM Wiki 不适合知识更新极快的场景。如果你的领域知识每周都在变，维护 wiki 的成本会超过收益，这时候老老实实用传统 RAG 加增量索引更划算。4. Multi-Agent：把复杂任务拆给专业分工的"项目组"4.1 单 Agent 的能力边界单 Agent 的问题不是能力不够，而是上下文和注意力有限。一个 prompt 里塞太多职责——既要理解用户意图，又要检索，又要推理，又要格式化输出——模型很容易顾此失彼。我做过测试，让单 Agent 同时处理"意图识别+检索+计算+格式化"，准确率比拆成多个专职 Agent 低了将近 20%。Multi-Agent 的核心思想就是关注点分离。每个 Agent 只干一件事，prompt 可以写得非常聚焦，工具也可以配得非常精准。Agent 之间通过消息传递协作，整体完成一个复杂任务。4.2 常见的 Multi-Agent 拓扑结构我实际用过的拓扑有三种，各有适用场景。第一种：流水线式。Agent 按顺序执行，前一个的输出是后一个的输入。适合流程固定的任务，比如"抽取→校验→格式化"。优点是可控，缺点是缺乏灵活性。第二种：主管-下属式。一个主管 Agent 负责分解任务和调度，多个下属 Agent 负责执行。适合任务可以预先分解的场景，比如"写报告"可以拆成"查资料""写初稿""审校"。优点是分工清晰，缺点是主管 Agent 容易成为瓶颈。第三种：辩论式。多个 Agent 对同一问题给出不同答案，通过多轮辩论收敛。适合需要高可靠性的决策场景。优点是能发现单 Agent 的盲点，缺点是成本高、延迟大。拓扑结构适用场景优点缺点流水线式流程固定可控、易调试缺乏灵活性主管-下属式可预分解任务分工清晰主管易成瓶颈辩论式高可靠性决策能发现盲点成本高、延迟大4.3 Agent 间通信协议的设计Multi-Agent 最容易出问题的地方就是通信。我踩过的坑包括：消息格式不统一导致解析失败、Agent 之间互相等待造成死锁、消息丢失导致任务卡住。我的解决方案是定义一个统一的消息信封，包含发送者、接收者、消息类型、载荷、超时时间、重试次数。所有 Agent 都按这个格式收发消息。消息类型我一般分四类：任务分配、结果返回、状态查询、错误上报。{ "from": "supervisor", "to": "retriever", "type": "task_assign", "payload": {"query": "..."}, "timeout": 30, "retry": 2 }另外一定要设全局超时和熔断机制。任何一个 Agent 卡住超过阈值，整个任务要能优雅降级，而不是无限等待。我见过太多 Multi-Agent 系统因为一个 Agent 挂起导致整个流程僵死。4.4 Multi-Agent 的调试与可观测性Multi-Agent 系统的调试难度是单 Agent 的好几倍，因为问题可能出在任何一个 Agent 或任何一次消息传递上。我的经验是从一开始就把可观测性做进去，不要等出问题再补。具体做法：每个 Agent 的每次输入输出都打日志，消息传递全链路追踪，关键决策点记录推理过程。我还会做一个回放工具，能把一次完整任务的执行过程重放出来，逐帧看每个 Agent 在干什么。这个工具在排查"为什么这个任务失败了"时简直是救命稻草。实操心得：Multi-Agent 系统上线前一定要做混沌测试——故意让某个 Agent 超时、返回错误、返回格式错误，看整个系统能不能正确处理。我做过一轮混沌测试，发现了 7 个隐藏的容错缺陷，这些在正常测试里根本暴露不出来。5. 三者如何取舍与组合5.1 按问题复杂度选架构选架构的第一步是搞清楚你的问题复杂度在哪个量级。我一般用三个维度判断：知识依赖度、推理跳数、任务可分解性。如果问题主要是"知识依赖度高、推理跳数低"，比如"某政策的具体条款是什么"，那 LLM Wiki 加简单 RAG 就够了，上 Agentic RAG 是浪费。如果问题是"知识依赖度高、推理跳数高"，比如"某政策调整对某业务的影响分析"，那 Agentic RAG 是必需的，LLM Wiki 作为知识底座能大幅提升效果。如果问题是"任务可分解性强、需要多种能力"，比如"生成一份包含数据分析、图表、文字说明的报告"，那 Multi-Agent 更合适。5.2 组合使用的代价与收益三者可以组合，但组合的复杂度不是相加而是相乘。我见过一个项目同时上了 Agentic RAG 加 Multi-Agent 加 LLM Wiki，结果光是调试就花了两个月，上线后维护成本高得吓人。我的建议是从简到繁，按需叠加。先上 LLM Wiki 把知识底座打好，这是收益最确定、风险最低的一步。然后根据问题复杂度决定要不要上 Agentic RAG。最后才考虑 Multi-Agent，而且只在任务确实需要多能力协作时才上。架构组合适用场景复杂度我的推荐度仅 LLM Wiki知识查询为主低强烈推荐LLM Wiki + RAG知识查询+简单推理中低推荐LLM Wiki + Agentic RAG复杂知识推理中高按需推荐三者全上复杂任务编排极高谨慎评估5.3 一个渐进式演进的实战路径我最后落地的方案是渐进式的。第一阶段只做 LLM Wiki 加传统 RAG，把知识底座打牢，上线跑了两个月，收集真实问题分布。第二阶段发现多跳问题占比达到 35%，于是引入 Agentic RAG，只对多跳问题启用。第三阶段发现报告生成类任务需要多能力协作，才引入 Multi-Agent，而且只用于这一类任务。这个路径的好处是每一步都有真实数据支撑，不是拍脑袋上架构。而且每一步的复杂度增量都是可控的，出问题容易定位。我见过太多团队一上来就上最复杂的架构，结果连基础问题都没解决好。6. 常见问题与排查技巧实录6.1 Agentic RAG 检索跑偏怎么办最常见的症状是：模型改写的查询越来越离谱，检索结果和原问题越来越远。排查思路是先看改写日志，判断是改写策略问题还是模型能力问题。如果是改写策略问题，收紧约束，给模型更明确的改写规则。如果是模型能力问题，换一个更强的模型做改写，或者干脆用规则做改写。我实测下来，对于结构化程度高的领域，规则改写往往比模型改写更稳。还有一个隐蔽的原因是检索器本身的问题。如果 embedding 模型和领域不匹配，再好的查询改写也救不回来。这时候要考虑换 embedding 模型或者做领域微调。6.2 LLM Wiki 维护成本失控怎么办症状是：知识更新频繁，wiki 条目改不过来，慢慢就没人维护了。这时候要反思是不是wiki 粒度太细。粒度太细，一个知识变更要改十几个条目，当然维护不过来。我的做法是按变更频率分层。变更频繁的知识用粗粒度条目，变更少的知识用细粒度条目。另外建一个变更影响分析机制，改一个条目时自动列出所有受影响的关联条目，避免漏改。6.3 Multi-Agent 死锁与超时怎么破死锁通常发生在 Agent 互相等待的场景。比如 A 等 B 的结果，B 等 A 的确认。排查方法是画一张消息依赖图，看有没有环。破环的方法有两个：一是引入超时，任何等待超过阈值就强制继续；二是打破循环依赖，重新设计消息流，让依赖关系变成有向无环图。我一般优先用第二种，因为超时只是兜底，不能解决根本问题。6.4 三者组合后延迟过高怎么优化组合架构的延迟是累加的，优化要从关键路径入手。先做全链路追踪，找出延迟最大的环节。常见的大头是 LLM 调用，优化手段包括：用小模型做简单判断、并行化无依赖的调用、缓存高频查询结果。我做过一个优化，把 Multi-Agent 里三个可以并行的 Agent 改成并行执行，整体延迟从 18 秒降到了 9 秒。并行化是性价比最高的优化手段，前提是依赖关系理清楚。常见问题典型症状排查方向解决手段检索跑偏改写查询越来越远改写日志收紧约束或换规则改写Wiki 维护失控更新改不过来条目粒度按变更频率分层Agent 死锁任务卡住不动消息依赖图破环或加超时延迟过高响应慢全链路追踪并行化+缓存7. 我踩过的几个大坑第一个坑是过早引入 Multi-Agent。项目初期任务还没理清楚，就上了 Multi-Agent，结果 Agent 之间的职责边界一直在变，改到最后面目全非。后来退回到单 Agent，把任务理清楚了再拆，才顺利起来。教训是：任务没理清之前，不要上 Multi-Agent。第二个坑是LLM Wiki 做成传统 wiki。一开始我按给人看的思路做 wiki，条目写得很学术，结果模型读起来效果很差。后来改成"为模型而写"，条目自包含、表述直白、交叉引用显式，效果立刻上来了。教训是：LLM Wiki 的读者是模型，不是人。第三个坑是Agentic RAG 没有退出条件。早期版本没有设最大轮次，遇到难问题模型会一直检索下去，有一次跑了 11 轮才停，成本爆炸。后来加了最大轮次和边际收益判断，才控制住。教训是：任何循环都要有明确的退出条件。第四个坑是忽视可观测性。Multi-Agent 上线后出问题，因为没有日志，排查了两天才定位到是一个 Agent 的消息格式错了。后来补上全链路日志和回放工具，排查效率提升了十倍不止。教训是：可观测性要从第一天就做。这几个坑的共同点是：都是复杂度管理的问题。架构越复杂，越要在简单的时候把基础打好，越要控制复杂度增长的速度。我现在做架构选型，第一原则永远是"能用简单的就不用复杂的"，复杂架构是最后的手段，不是第一选择。最后分享一个我一直在用的小技巧：每次引入新架构之前，先问自己三个问题——现有架构到底哪里不够用？新架构能解决这个问题吗？引入新架构的维护成本我扛得住吗？这三个问题答不清楚，就先别动。我靠这三个问题，至少避免了三次不必要的架构升级。
1. 三种架构到底在解决什么问题1.1 从一个真实困境说起去年下半年我接手了一个内部知识库问答系统的重构。老系统是最朴素的 RAG：用户提问，向量检索 top-k 文档片段，拼进 prompt，交给大模型生成答案。上线头两个月效果还行，到了第三个月，问题开始集中爆发——用户问"上季度的报销政策调整对海外差旅有什么影响"，系统检索回来的全是零散的报销条目，模型硬生生拼出一段看似合理但完全错误的答案。更麻烦的是，有些问题需要先查政策文档、再查具体案例、最后做对比分析，单轮检索根本覆盖不了这种多跳推理。那段时间我几乎把市面上能看到的架构方案都试了一遍，从最基础的 RAG 一路踩到 Agentic RAG、LLM Wiki、Multi-Agent。踩完之后最大的感受是：这三种架构不是递进关系，不是"新的比旧的好"，而是各自在解决不同维度的问题。选错了，不是效果差一点，而是整个系统的维护成本会失控。这篇文章我想把这三个架构的取舍逻辑讲透。核心关键词就三个：Agentic RAG、LLM Wiki、Multi-Agent。如果你正在做知识密集型应用、智能助手或者复杂任务编排，不管你是刚入门还是在做架构选型，这篇应该都能帮你少走点弯路。我不会只讲概念，会把每个架构的适用边界、实现细节、踩坑经验都摊开说。1.2 三种架构的本质差异先把三者的定位说清楚，不然后面容易混。Agentic RAG本质上是"带决策能力的检索"。传统 RAG 是"检索一次→生成一次"的固定流水线，Agentic RAG 把检索变成了一个可以循环、可以判断、可以自我修正的过程。模型会自己决定要不要检索、检索什么、检索结果够不够、要不要再检索一轮。它解决的是"单轮检索覆盖不了复杂问题"的痛点。LLM Wiki本质上是"结构化的知识沉淀层"。它不是让模型每次现查现答，而是把领域知识预先整理成一套模型能高效读取的结构化文档体系——有点像给模型建了一个它自己能维护的维基百科。它解决的是"知识碎片化、检索命中率低、答案不一致"的问题。Multi-Agent本质上是"任务分解与协作"。把一个复杂任务拆给多个各有专长的 Agent，每个 Agent 负责一块，通过消息传递协作完成。它解决的是"单一模型上下文有限、单一 prompt 难以兼顾多种能力"的问题。这三者的关系，我习惯用一个类比：Agentic RAG 是"会自己找资料的实习生"，LLM Wiki 是"团队共同维护的知识手册"，Multi-Agent 是"一个分工明确的项目组"。你可以只用其中一个，也可以组合使用，但组合的代价是复杂度指数级上升。2. Agentic RAG：让检索学会"自己拿主意"2.1 传统 RAG 的天花板在哪传统 RAG 的流程固定得像一条流水线：embedding 查询→向量库检索→重排序→拼 prompt→生成。这条流水线在"问题简单、答案集中在少数文档"的场景下非常好用，成本低、延迟低、可控性强。但它有三个硬伤。第一，检索时机是死的。不管问题需不需要外部知识，它都会去检索，浪费算力还可能引入噪声。第二，检索轮次是死的。一次检索不够就是不够，模型没有机会说"我再查一下"。第三，无法处理多跳问题。像"某产品的退货政策在最近一次修订中改了什么，这个改动对跨境订单有什么影响"这种问题，需要先定位政策文档、再定位修订记录、再做影响分析，单轮检索拿不到完整证据链。我实测过一个数据：在单跳事实型问题上，传统 RAG 和 Agentic RAG 的准确率差距不到 5%；但在多跳推理问题上，差距能拉到 30% 以上。这就是 Agentic RAG 的价值区间。2.2 Agentic RAG 的核心循环设计Agentic RAG 的关键在于把"检索"从一个步骤变成一个可控循环。我常用的循环结构是这样的：意图判断：模型先判断这个问题需不需要外部知识。有些问题靠自身知识就能答，硬检索反而添乱。查询改写：把用户的口语化问题改写成适合检索的查询。这一步很关键，用户问"那个新政策咋样了"，直接拿去检索基本废掉。检索执行：调用检索工具，拿到候选片段。充分性评估：模型判断检索结果是否足以回答问题。不够就回到第 2 步，换个查询再检。生成与引用：基于充分证据生成答案，并标注来源。这个循环的退出条件要设计好，否则容易死循环。我的做法是设一个最大轮次（通常 3 轮），同时设一个"边际收益"判断——如果新一轮检索没有带来新的有效信息，就强制退出。# 简化的 Agentic RAG 循环骨架（伪代码） def agentic_rag(query, max_rounds=3): context = [] for round in range(max_rounds): rewritten = rewrite_query(query, context) docs = retrieve(rewritten) new_docs = filter_new(docs, context) if not new_docs and round > 0: break # 边际收益为零，退出 context.extend(new_docs) if is_sufficient(query, context): break return generate(query, context)2.3 查询改写与充分性评估的实操细节这两个环节是 Agentic RAG 的成败关键，也是最容易被做砸的地方。查询改写我踩过的坑是：让模型自由改写，结果它把简单问题改得越来越复杂，检索反而跑偏。后来我改成"受约束改写"——给模型明确的改写策略，比如"如果问题包含指代词，先消解指代""如果问题涉及时间，补全时间范围""如果问题涉及对比，拆成两个子查询"。约束之后，检索命中率明显稳定。充分性评估更微妙。早期我用的是让模型直接回答"够不够"，结果模型倾向于说"够了"，因为它有生成答案的冲动。后来我改成让模型做证据映射：把问题的每个子需求列出来，逐一标注"有证据/无证据/证据矛盾"。这样评估就客观多了，模型不容易糊弄自己。实操心得：充分性评估的 prompt 里一定要加一句"如果证据不足，明确说不足，不要勉强回答"。这句话能显著降低幻觉率，我实测下来幻觉率从 12% 降到了 4% 左右。2.4 Agentic RAG 的成本与延迟权衡Agentic RAG 不是免费的。多轮检索意味着多次 embedding 调用、多次向量库查询、多次 LLM 调用。我做过一个粗略统计：一个平均 2.3 轮的 Agentic RAG 查询，token 消耗是传统 RAG 的 3 到 5 倍，延迟是 2 到 4 倍。所以我的建议是分级处理：先用一个轻量分类器判断问题复杂度，简单问题走传统 RAG，复杂问题才走 Agentic RAG。这个分类器不需要很准，哪怕只有 70% 的准确率，也能省下大量成本。我用的分类器就是一个小的微调模型，判断"单跳/多跳"，推理成本几乎可以忽略。3. LLM Wiki：把知识沉淀成模型能读的"手册"3.1 为什么检索总是命中不了做 RAG 的人都有一个共同的痛：明明知识库里就有答案，检索就是命中不了。原因通常有三个。第一，知识碎片化。同一个主题的信息散落在几十个文档里，检索只能拿到零碎片段。第二，表述不一致。用户问"退款"，文档里写的是"退货返款"，embedding 相似度不够。第三，缺乏上下文。一个片段单独拿出来看，根本不知道它在说什么。LLM Wiki 的思路是：与其每次现查现拼，不如预先把这些知识整理成结构化的、自洽的文档体系。这个体系不是给人看的传统 wiki，而是专门为 LLM 读取优化的——每个条目自包含、有明确的层级、有交叉引用、有统一的术语表。3.2 LLM Wiki 的结构设计原则我设计 LLM Wiki 时遵循四条原则，都是踩坑踩出来的。第一条：条目自包含。每个条目要能独立回答一类问题，不依赖读者（也就是模型）去翻别的条目才能理解。这意味着要适度冗余，同一个概念在不同条目里可以重复出现，只要保证每个条目读起来是完整的。第二条：层级不超过三层。层级太深，模型在检索和阅读时容易迷路。我一般用"领域→主题→条目"三层，再深就拆成独立文档。第三条：术语统一。建一个术语表，所有条目里的表述都对齐到术语表。用户问"退款"，条目里就统一写"退款"，不要一会儿"退货返款"一会儿"资金退回"。第四条：显式交叉引用。条目之间用明确的引用标记连接，比如"参见[条目ID]"。这样模型在检索到一个条目后，能顺着引用找到相关条目，形成知识网络。3.3 从原始文档到 LLM Wiki 的构建流程构建 LLM Wiki 不是简单地把文档切块，而是一个知识重构的过程。我的流程分四步：知识抽取：从原始文档里抽取实体、关系、属性。这一步可以用 LLM 辅助，但一定要人工审核，因为 LLM 抽取容易漏掉隐含信息。主题聚类：把抽取出的知识按主题聚类，形成条目的雏形。聚类粒度要适中，太粗条目太大，太细条目太多。条目撰写：为每个条目撰写自包含的内容。这一步我建议让领域专家参与，因为 LLM 写出来的条目往往"正确但不到位"，缺少实操细节。一致性校验：全量检查术语一致性、交叉引用有效性、层级合理性。这一步最枯燥但最不能省。# 条目示例：退款政策 ## 适用范围 适用于所有线上订单，不含线下门店交易。 ## 核心规则 - 签收后 7 天内可申请无理由退款 - 定制类商品不支持无理由退款 - 退款到账时间为 3-5 个工作日 ## 关联条目 - 参见 [退货流程] - 参见 [跨境订单特殊规则]3.4 LLM Wiki 与 RAG 的配合方式LLM Wiki 不是要取代 RAG，而是给 RAG 提供更好的检索底座。我的做法是：把 LLM Wiki 的条目作为检索单元，每个条目单独 embedding。因为条目是自包含的，检索命中一个条目就等于拿到了一段完整知识，不需要再拼接碎片。实测下来，同样的知识库，整理成 LLM Wiki 后，检索命中率从 61% 提升到了 84%，答案一致性也明显改善。代价是前期构建成本高——我那个知识库大概花了三周时间做重构，但后续维护成本反而降低了，因为知识结构清晰了，更新时知道该改哪里。注意事项：LLM Wiki 不适合知识更新极快的场景。如果你的领域知识每周都在变，维护 wiki 的成本会超过收益，这时候老老实实用传统 RAG 加增量索引更划算。4. Multi-Agent：把复杂任务拆给专业分工的"项目组"4.1 单 Agent 的能力边界单 Agent 的问题不是能力不够，而是上下文和注意力有限。一个 prompt 里塞太多职责——既要理解用户意图，又要检索，又要推理，又要格式化输出——模型很容易顾此失彼。我做过测试，让单 Agent 同时处理"意图识别+检索+计算+格式化"，准确率比拆成多个专职 Agent 低了将近 20%。Multi-Agent 的核心思想就是关注点分离。每个 Agent 只干一件事，prompt 可以写得非常聚焦，工具也可以配得非常精准。Agent 之间通过消息传递协作，整体完成一个复杂任务。4.2 常见的 Multi-Agent 拓扑结构我实际用过的拓扑有三种，各有适用场景。第一种：流水线式。Agent 按顺序执行，前一个的输出是后一个的输入。适合流程固定的任务，比如"抽取→校验→格式化"。优点是可控，缺点是缺乏灵活性。第二种：主管-下属式。一个主管 Agent 负责分解任务和调度，多个下属 Agent 负责执行。适合任务可以预先分解的场景，比如"写报告"可以拆成"查资料""写初稿""审校"。优点是分工清晰，缺点是主管 Agent 容易成为瓶颈。第三种：辩论式。多个 Agent 对同一问题给出不同答案，通过多轮辩论收敛。适合需要高可靠性的决策场景。优点是能发现单 Agent 的盲点，缺点是成本高、延迟大。拓扑结构适用场景优点缺点流水线式流程固定可控、易调试缺乏灵活性主管-下属式可预分解任务分工清晰主管易成瓶颈辩论式高可靠性决策能发现盲点成本高、延迟大4.3 Agent 间通信协议的设计Multi-Agent 最容易出问题的地方就是通信。我踩过的坑包括：消息格式不统一导致解析失败、Agent 之间互相等待造成死锁、消息丢失导致任务卡住。我的解决方案是定义一个统一的消息信封，包含发送者、接收者、消息类型、载荷、超时时间、重试次数。所有 Agent 都按这个格式收发消息。消息类型我一般分四类：任务分配、结果返回、状态查询、错误上报。{ "from": "supervisor", "to": "retriever", "type": "task_assign", "payload": {"query": "..."}, "timeout": 30, "retry": 2 }另外一定要设全局超时和熔断机制。任何一个 Agent 卡住超过阈值，整个任务要能优雅降级，而不是无限等待。我见过太多 Multi-Agent 系统因为一个 Agent 挂起导致整个流程僵死。4.4 Multi-Agent 的调试与可观测性Multi-Agent 系统的调试难度是单 Agent 的好几倍，因为问题可能出在任何一个 Agent 或任何一次消息传递上。我的经验是从一开始就把可观测性做进去，不要等出问题再补。具体做法：每个 Agent 的每次输入输出都打日志，消息传递全链路追踪，关键决策点记录推理过程。我还会做一个回放工具，能把一次完整任务的执行过程重放出来，逐帧看每个 Agent 在干什么。这个工具在排查"为什么这个任务失败了"时简直是救命稻草。实操心得：Multi-Agent 系统上线前一定要做混沌测试——故意让某个 Agent 超时、返回错误、返回格式错误，看整个系统能不能正确处理。我做过一轮混沌测试，发现了 7 个隐藏的容错缺陷，这些在正常测试里根本暴露不出来。5. 三者如何取舍与组合5.1 按问题复杂度选架构选架构的第一步是搞清楚你的问题复杂度在哪个量级。我一般用三个维度判断：知识依赖度、推理跳数、任务可分解性。如果问题主要是"知识依赖度高、推理跳数低"，比如"某政策的具体条款是什么"，那 LLM Wiki 加简单 RAG 就够了，上 Agentic RAG 是浪费。如果问题是"知识依赖度高、推理跳数高"，比如"某政策调整对某业务的影响分析"，那 Agentic RAG 是必需的，LLM Wiki 作为知识底座能大幅提升效果。如果问题是"任务可分解性强、需要多种能力"，比如"生成一份包含数据分析、图表、文字说明的报告"，那 Multi-Agent 更合适。5.2 组合使用的代价与收益三者可以组合，但组合的复杂度不是相加而是相乘。我见过一个项目同时上了 Agentic RAG 加 Multi-Agent 加 LLM Wiki，结果光是调试就花了两个月，上线后维护成本高得吓人。我的建议是从简到繁，按需叠加。先上 LLM Wiki 把知识底座打好，这是收益最确定、风险最低的一步。然后根据问题复杂度决定要不要上 Agentic RAG。最后才考虑 Multi-Agent，而且只在任务确实需要多能力协作时才上。架构组合适用场景复杂度我的推荐度仅 LLM Wiki知识查询为主低强烈推荐LLM Wiki + RAG知识查询+简单推理中低推荐LLM Wiki + Agentic RAG复杂知识推理中高按需推荐三者全上复杂任务编排极高谨慎评估5.3 一个渐进式演进的实战路径我最后落地的方案是渐进式的。第一阶段只做 LLM Wiki 加传统 RAG，把知识底座打牢，上线跑了两个月，收集真实问题分布。第二阶段发现多跳问题占比达到 35%，于是引入 Agentic RAG，只对多跳问题启用。第三阶段发现报告生成类任务需要多能力协作，才引入 Multi-Agent，而且只用于这一类任务。这个路径的好处是每一步都有真实数据支撑，不是拍脑袋上架构。而且每一步的复杂度增量都是可控的，出问题容易定位。我见过太多团队一上来就上最复杂的架构，结果连基础问题都没解决好。6. 常见问题与排查技巧实录6.1 Agentic RAG 检索跑偏怎么办最常见的症状是：模型改写的查询越来越离谱，检索结果和原问题越来越远。排查思路是先看改写日志，判断是改写策略问题还是模型能力问题。如果是改写策略问题，收紧约束，给模型更明确的改写规则。如果是模型能力问题，换一个更强的模型做改写，或者干脆用规则做改写。我实测下来，对于结构化程度高的领域，规则改写往往比模型改写更稳。还有一个隐蔽的原因是检索器本身的问题。如果 embedding 模型和领域不匹配，再好的查询改写也救不回来。这时候要考虑换 embedding 模型或者做领域微调。6.2 LLM Wiki 维护成本失控怎么办症状是：知识更新频繁，wiki 条目改不过来，慢慢就没人维护了。这时候要反思是不是wiki 粒度太细。粒度太细，一个知识变更要改十几个条目，当然维护不过来。我的做法是按变更频率分层。变更频繁的知识用粗粒度条目，变更少的知识用细粒度条目。另外建一个变更影响分析机制，改一个条目时自动列出所有受影响的关联条目，避免漏改。6.3 Multi-Agent 死锁与超时怎么破死锁通常发生在 Agent 互相等待的场景。比如 A 等 B 的结果，B 等 A 的确认。排查方法是画一张消息依赖图，看有没有环。破环的方法有两个：一是引入超时，任何等待超过阈值就强制继续；二是打破循环依赖，重新设计消息流，让依赖关系变成有向无环图。我一般优先用第二种，因为超时只是兜底，不能解决根本问题。6.4 三者组合后延迟过高怎么优化组合架构的延迟是累加的，优化要从关键路径入手。先做全链路追踪，找出延迟最大的环节。常见的大头是 LLM 调用，优化手段包括：用小模型做简单判断、并行化无依赖的调用、缓存高频查询结果。我做过一个优化，把 Multi-Agent 里三个可以并行的 Agent 改成并行执行，整体延迟从 18 秒降到了 9 秒。并行化是性价比最高的优化手段，前提是依赖关系理清楚。常见问题典型症状排查方向解决手段检索跑偏改写查询越来越远改写日志收紧约束或换规则改写Wiki 维护失控更新改不过来条目粒度按变更频率分层Agent 死锁任务卡住不动消息依赖图破环或加超时延迟过高响应慢全链路追踪并行化+缓存7. 我踩过的几个大坑第一个坑是过早引入 Multi-Agent。项目初期任务还没理清楚，就上了 Multi-Agent，结果 Agent 之间的职责边界一直在变，改到最后面目全非。后来退回到单 Agent，把任务理清楚了再拆，才顺利起来。教训是：任务没理清之前，不要上 Multi-Agent。第二个坑是LLM Wiki 做成传统 wiki。一开始我按给人看的思路做 wiki，条目写得很学术，结果模型读起来效果很差。后来改成"为模型而写"，条目自包含、表述直白、交叉引用显式，效果立刻上来了。教训是：LLM Wiki 的读者是模型，不是人。第三个坑是Agentic RAG 没有退出条件。早期版本没有设最大轮次，遇到难问题模型会一直检索下去，有一次跑了 11 轮才停，成本爆炸。后来加了最大轮次和边际收益判断，才控制住。教训是：任何循环都要有明确的退出条件。第四个坑是忽视可观测性。Multi-Agent 上线后出问题，因为没有日志，排查了两天才定位到是一个 Agent 的消息格式错了。后来补上全链路日志和回放工具，排查效率提升了十倍不止。教训是：可观测性要从第一天就做。这几个坑的共同点是：都是复杂度管理的问题。架构越复杂，越要在简单的时候把基础打好，越要控制复杂度增长的速度。我现在做架构选型，第一原则永远是"能用简单的就不用复杂的"，复杂架构是最后的手段，不是第一选择。最后分享一个我一直在用的小技巧：每次引入新架构之前，先问自己三个问题——现有架构到底哪里不够用？新架构能解决这个问题吗？引入新架构的维护成本我扛得住吗？这三个问题答不清楚，就先别动。我靠这三个问题，至少避免了三次不必要的架构升级。