1. 三种架构到底在解决什么问题先把这三个词拆开看别被缩写唬住。Agentic RAG、LLM Wiki、Multi-Agent本质上都是围绕同一个核心矛盾在做取舍当大模型自身知识不够用、或者任务复杂到单次推理搞不定时我们该怎么给它补上外部能力。区别只在于补的方式和补的层次不同。Agentic RAG 是传统 RAG 的进化版。传统 RAG 就是“检索一次、拼进上下文、生成答案”这条直线简单但脆弱——检索结果不好后面全崩。Agentic RAG 把“检索”这个动作交给模型自己决策要不要检索、检索几轮、用哪个数据源、检索结果够不够、要不要换个查询词再来一次。它把 RAG 从一条流水线变成了一个带反馈回路的循环。LLM Wiki 这个词没有严格学术定义但在工程圈里通常指一种结构化的知识沉淀层把领域知识、操作手册、历史决策、术语表这些东西用模型能高效消费的格式组织起来作为检索的底座或者直接作为上下文注入源。它和普通文档库的区别在于Wiki 是有层级、有交叉引用、有更新机制的不是一堆散落的 PDF。Multi-Agent 则是把一个大任务拆给多个角色化的模型实例每个实例有自己的系统提示、工具集和职责边界通过某种协作协议辩论、投票、流水线、主管调度来产出最终结果。它的价值不在于“多个模型一定比一个强”而在于职责隔离带来的可控性和可调试性。这三个东西经常被放在一起讨论是因为它们在实际项目里往往是叠加使用的用 LLM Wiki 做知识底座用 Agentic RAG 做检索策略用 Multi-Agent 做任务编排。但叠加不等于都要上取舍才是关键。2. 架构选型的核心判断维度2.1 任务复杂度与不确定性分布选架构之前先问自己一个问题我的任务里不确定性主要来自哪里。如果不确定性主要来自“知识不在模型脑子里”比如内部政策问答、产品参数查询那核心矛盾是检索质量Agentic RAG 是首选Multi-Agent 大概率是过度设计。如果不确定性来自“任务步骤多、每步都可能出错”比如自动排查线上故障、多步骤数据分析那核心矛盾是流程控制Multi-Agent 的职责隔离和检查点机制才有价值。如果不确定性来自“知识本身在频繁变化、且需要长期维护”那 LLM Wiki 的更新机制和结构设计比检索算法更重要。我见过不少项目一上来就堆 Multi-Agent结果发现 80% 的失败案例其实是检索没做好跟 Agent 数量没关系。这个坑很常见。2.2 延迟与成本的硬约束这三个架构的成本量级差异很大选型时必须先算账。架构方案典型延迟量级单次调用成本量级适用场景传统 RAG1x1x简单问答、知识查询Agentic RAG2-5x3-8x需要多轮检索的复杂查询LLM Wiki RAG1.5-3x2-5x知识密集型、需长期维护Multi-Agent5-20x10-50x多步骤任务、需职责隔离这张表是经验值具体数字取决于模型选型、检索后端和编排框架。但量级关系是稳的每加一层 Agent 循环成本和延迟都是乘法级增长。注意如果你的场景对延迟敏感比如面向用户的实时对话Agentic RAG 的循环次数要严格限制通常不超过 3 轮。Multi-Agent 基本不适合实时场景除非是异步任务。2.3 可观测性与调试难度这是最容易被低估的维度。传统 RAG 出问题你看检索结果和最终输出就能定位。Agentic RAG 出问题你要看每一轮的检索决策、查询改写、结果评估。Multi-Agent 出问题你要看每个 Agent 的输入输出、消息传递、状态同步。调试难度是随架构复杂度指数上升的。我的经验是如果一个团队没有成熟的链路追踪和日志体系不要上 Multi-Agent。你会在调试上花掉比开发更多的时间。3. Agentic RAG 的落地细节与实操要点3.1 检索决策的触发条件设计Agentic RAG 的核心是让模型自己决定要不要检索。但“让模型自己决定”不等于完全放手你需要设计触发条件。常见的触发策略有三种强制检索所有查询先检索一轮再让模型判断是否需要补充检索。适合知识密集型场景简单可靠。条件检索模型先判断查询是否属于知识库覆盖范围是则检索否则直接回答。适合混合场景但判断本身可能出错。自适应检索模型在生成过程中遇到不确定的地方主动发起检索。最灵活但实现复杂度最高。我实测下来条件检索 强制补充检索的组合最稳第一轮用条件判断决定是否检索如果检索了但模型评估结果不充分强制再检索一轮。这样既避免了无谓检索又保证了兜底。3.2 查询改写的具体做法Agentic RAG 比传统 RAG 强的地方很大程度在于查询改写。用户问“上个月那个新功能怎么用”传统 RAG 直接拿这句话去检索效果很差。Agentic RAG 会先把它改写成“XX功能 使用说明 操作步骤”再检索。查询改写的实现方式# 查询改写提示词模板示例 REWRITE_PROMPT 你是一个查询改写助手。用户原始问题如下 {original_query} 请将其改写为适合向量检索的查询语句要求 1. 补全指代词如那个、它的具体指代对象 2. 提取核心关键词去掉口语化表达 3. 如果问题包含多个子问题拆分为多个查询 4. 输出格式为 JSON 数组每个元素是一个查询字符串 只输出 JSON不要其他内容。 改写后的查询会并行检索然后合并结果。这里有个细节改写后的查询数量要限制通常 2-4 个太多会导致检索结果冗余反而干扰模型判断。3.3 检索结果充分性评估这是 Agentic RAG 最关键的环节也是最难做好的。模型需要判断“检索到的内容够不够回答问题”。评估维度通常包括相关性检索结果和问题的语义匹配度覆盖度是否覆盖了问题的所有子方面时效性对于时间敏感的问题结果是否足够新一致性多个检索结果之间是否矛盾实操中我建议用一个独立的评估提示词让模型输出结构化的评估结果EVAL_PROMPT 问题{query} 检索结果{retrieved_docs} 请评估这些检索结果是否足以回答问题。输出 JSON { sufficient: true/false, missing_aspects: [缺失的方面1, 缺失的方面2], suggested_query: 如果不足建议的补充查询 } 如果sufficient为 false就用suggested_query再检索一轮。循环上限建议设为 3 轮超过就强制生成并在答案中标注“信息可能不完整”。实操心得评估提示词里一定要加“如果检索结果为空或明显不相关直接判定为不足”否则模型容易过度乐观觉得“有总比没有好”。4. LLM Wiki 的结构设计与维护机制4.1 为什么需要 Wiki 而不是文档库普通文档库的问题在于文档之间没有关系检索是扁平的。用户问“A 功能的限制条件”检索可能只命中 A 功能的介绍文档但限制条件其实写在 B 文档的某个角落。LLM Wiki 的核心价值是结构化。它把知识组织成有层级、有交叉引用的网络层级结构领域 → 模块 → 功能 → 细节每层有摘要交叉引用相关条目之间显式链接检索时可以顺着链接扩展元数据每个条目有更新时间、负责人、适用范围、置信度版本历史知识变更可追溯避免新旧信息冲突这种结构让检索从“找相似文本”变成“找相关节点”精度和召回率都会提升。4.2 Wiki 条目的标准格式每个 Wiki 条目建议包含以下字段id: auth-token-refresh title: Token 刷新机制 domain: 认证授权 summary: 描述 Token 刷新的触发条件、流程和异常处理 content: | 详细内容... related: - auth-token-issue - auth-session-manage updated_at: 2024-01-15 owner: 某开发者 confidence: highsummary字段很关键它是检索时的第一层匹配目标。摘要写得好检索精度能提升一大截。我的经验是摘要控制在 50-80 字必须包含该条目的核心关键词和适用场景。4.3 更新机制的设计Wiki 最大的敌人是过期。知识不更新检索出来的就是错误信息比没有更糟。更新机制通常有三种触发方式人工触发负责人主动更新适合核心知识事件触发相关系统变更时自动标记待更新适合技术文档反馈触发用户对答案标记“不准确”时回溯到相关条目提醒更新我建议至少要有反馈触发机制。因为人工维护总有遗漏而用户反馈是最真实的质量信号。具体做法是在答案下方加“这个回答有帮助吗”的反馈按钮如果用户点“没帮助”就把这次查询、检索到的条目、最终答案一起记录下来定期 review。注意Wiki 更新后向量索引需要重建或增量更新。如果用的是全量重建要评估重建时间和成本如果是增量更新要确保旧向量被正确删除否则会出现新旧信息同时被检索到的情况。5. Multi-Agent 的协作模式与适用边界5.1 三种主流协作模式Multi-Agent 不是简单地把任务分给多个模型协作模式决定了它的效果。流水线模式Agent A 的输出是 Agent B 的输入依次传递。适合步骤明确的线性任务比如“检索 → 分析 → 撰写 → 审核”。优点是简单可控缺点是错误会累积传递。主管调度模式一个主管 Agent 负责拆解任务、分配给执行 Agent、汇总结果。适合任务结构不确定、需要动态调整的场景。优点是灵活缺点是主管 Agent 本身可能成为瓶颈。辩论模式多个 Agent 对同一问题给出答案然后互相批评、修正最终收敛。适合需要高准确率的判断类任务。优点是能发现单模型的盲点缺点是成本高、可能不收敛。我实际用下来流水线模式覆盖了 70% 的场景主管调度适合 20%辩论模式只在少数高价值判断场景才值得上。5.2 Agent 之间的消息协议Multi-Agent 系统里Agent 之间传什么、怎么传直接决定了系统的稳定性。消息协议要解决三个问题格式统一所有 Agent 的输出必须是结构化格式不能是自由文本状态传递每个 Agent 需要知道前序步骤做了什么、当前处于什么状态错误处理某个 Agent 失败时是重试、跳过还是终止整个流程一个实用的消息格式{ task_id: xxx, step: retrieval, status: success, input: {...}, output: {...}, confidence: 0.85, next_action: proceed, error: null }next_action字段让每个 Agent 可以建议下一步动作主管 Agent 据此决策。confidence字段用于判断是否需要人工介入或额外验证。5.3 什么时候不该用 Multi-Agent这是我最想强调的一点。Multi-Agent 的代价很高以下场景不建议用任务可以用单次推理完成加 Agent 只是增加成本和延迟任务步骤少于 3 步流水线还没建立起来就结束了对延迟敏感Multi-Agent 的串行调用延迟是累加的团队没有链路追踪能力出问题无法定位知识问题而非流程问题检索没做好加多少 Agent 都没用我见过一个项目用 5 个 Agent 做客服问答结果发现 90% 的问题单次 RAG 就能解决剩下 10% 是知识库没覆盖。最后砍到 1 个 Agent 更好的 Wiki效果反而更好。6. 三种架构的组合策略与取舍实例6.1 组合的层次关系这三种架构不是互斥的而是可以分层组合底层LLM Wiki 作为知识底座提供结构化、可维护的知识中层Agentic RAG 作为检索策略在 Wiki 上做多轮、自适应的检索上层Multi-Agent 作为任务编排把复杂任务拆给多个角色但组合不等于全上。每一层都要问这一层解决了我当前最大的痛点吗。6.2 一个实际的取舍过程假设你在做一个内部技术问答系统需求是回答开发者的技术问题。第一步先上传统 RAG 文档库。跑一周收集 bad case。第二步分析 bad case。如果发现主要是“检索不到”或“检索到但不相关”那核心矛盾在检索上 Agentic RAG 的查询改写和多轮检索。如果发现是“知识本身缺失或过期”那核心矛盾在知识维护上 LLM Wiki 的结构和更新机制。第三步如果发现有些问题需要多步推理比如“A 和 B 哪个更适合我的场景”单次 RAG 搞不定再考虑加一个分析 Agent形成简单的 Multi-Agent。这个顺序很重要从简单到复杂每加一层都要有明确的 bad case 支撑。不要一开始就设计一个三层架构那样你根本不知道问题出在哪一层。6.3 成本与效果的平衡点我的经验是大多数场景的平衡点在Agentic RAG 轻量 Wiki这个组合Wiki 提供结构化的知识底座保证检索质量Agentic RAG 提供查询改写和多轮检索保证复杂查询的覆盖不上 Multi-Agent用单 Agent 加工具调用覆盖大部分流程这个组合的成本大约是传统 RAG 的 3-5 倍但效果提升明显且调试难度可控。Multi-Agent 只在任务确实需要多角色协作时才上且要接受 10 倍以上的成本。7. 常见问题与排查技巧实录7.1 Agentic RAG 检索循环不收敛现象模型一直觉得检索结果不够反复检索超过循环上限。排查思路检查评估提示词是否过于严格把“完美覆盖”当成“充分”检查检索后端是否真的能返回相关结果可能是索引问题检查查询改写是否跑偏改写的查询和原问题语义偏离解决在评估提示词里加“如果检索结果已经覆盖问题的主要方面即使不完美也判定为充分”。同时设置硬性循环上限超过就强制生成。7.2 Wiki 条目冲突现象检索到两个条目内容矛盾模型不知道该信哪个。排查思路检查是否有重复条目不同人写了相似内容检查是否有过期条目没被清理检查confidence字段是否被正确使用解决建立条目去重机制定期 review 相似条目。检索时按confidence和updated_at排序高置信度、新更新的优先。如果仍然冲突在答案中显式说明“存在不同说法”并列出两个来源。7.3 Multi-Agent 消息丢失或格式错误现象某个 Agent 的输出格式不对导致下游 Agent 解析失败。排查思路检查该 Agent 的提示词是否明确要求了输出格式检查是否有异常输入导致模型输出跑偏检查消息传递层是否有序列化/反序列化问题解决在每个 Agent 的输出后加格式校验不符合格式就重试或走 fallback。提示词里用 few-shot 示例强化格式要求。消息传递层用强类型 schema不要用自由 JSON。7.4 常见问题速查表问题可能原因快速排查解决方向检索循环不收敛评估过严/索引问题/改写跑偏看每轮评估输出和改写查询放宽评估/重建索引/限制改写Wiki 条目冲突重复/过期/置信度未用查相似条目和更新时间去重/清理/按置信度排序Agent 消息格式错误提示词不明确/异常输入看失败 Agent 的输入输出加格式校验/重试/fallback延迟过高循环过多/Agent 过多统计每步耗时限制循环/砍 Agent/异步化成本超预算模型选型过大/检索过多统计 token 消耗换小模型/缓存/限制检索实操心得排查这类系统第一步永远是看日志。没有完整的链路日志所有排查都是猜。我建议在项目第一天就把日志体系搭好记录每次查询的完整链路输入、每轮检索的查询和结果、每个 Agent 的输入输出、最终答案、耗时、token 消耗。这个投入在后期排查时能省下大量时间。8. 我个人的一些取舍体会做了几个这类项目之后我最大的体会是架构复杂度应该由问题复杂度驱动而不是由技术新鲜感驱动。Agentic RAG 的查询改写和多轮检索确实能解决传统 RAG 解决不了的复杂查询但它的成本是传统 RAG 的 3-5 倍且调试难度上升一个量级。LLM Wiki 的结构化知识底座长期价值很高但前期投入大且需要持续的维护机制。Multi-Agent 的职责隔离在任务确实需要多角色协作时价值巨大但大多数任务其实不需要。我现在做新项目的默认路径是先上传统 RAG收集 bad case分析瓶颈在哪一层再决定加哪一层。这个顺序看起来慢但实际上比一上来就设计复杂架构要快得多因为你能清楚地知道每一层的收益和代价。还有一个细节缓存策略能大幅降低成本。Agentic RAG 的查询改写和多轮检索很多查询是重复的。在查询改写层加语义缓存相似查询直接复用改写结果和检索结果能省下 30%-50% 的成本。Multi-Agent 的中间结果也可以缓存特别是那些不依赖实时数据的步骤。最后分享一个小技巧在评估 Agentic RAG 效果时不要只看最终答案的准确率还要看检索轮次分布。如果大部分查询都在 1 轮就结束说明你的评估太宽松或者查询太简单如果大部分都在 3 轮上限说明检索质量有问题或者评估太严格。健康的分布应该是 1 轮占 60%2 轮占 30%3 轮占 10% 左右。这个指标能帮你快速判断系统是否处于合理状态。