Agentic RAG、LLM Wiki与Multi-Agent架构选型与落地实践

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 延迟与成本的硬约束

这三个架构的成本量级差异很大，选型时必须先算账。

这张表是经验值，具体数字取决于模型选型、检索后端和编排框架。但量级关系是稳的：每加一层 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: "high"

summary字段很关键，它是检索时的第一层匹配目标。摘要写得好，检索精度能提升一大截。我的经验是：摘要控制在 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 常见问题速查表

实操心得：排查这类系统，第一步永远是看日志。没有完整的链路日志，所有排查都是猜。我建议在项目第一天就把日志体系搭好，记录每次查询的完整链路：输入、每轮检索的查询和结果、每个 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% 左右。这个指标能帮你快速判断系统是否处于合理状态。