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

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

每个状态的具体逻辑：

1. INIT：接收用户问题，初始化上下文。
2. REWRITE：调用模型改写查询。这里有个经验——改写时要把对话历史一起传进去，否则多轮对话里的指代（"那第二条呢"）无法正确解析。
3. RETRIEVE：执行检索，拿到 Top-K 文档。
4. EVALUATE：这是最关键的一步。调用模型判断检索结果是否充分。我用的 Prompt 大致是让模型输出一个结构化结果：{"sufficient": true/false, "reason": "...", "next_action": "generate/rewrite/tool"}。
5. GENERATE：信息充分，生成最终答案。
6. REWRITE：信息不足，带着"为什么不足"的反馈重新改写查询，回到 RETRIEVE。
7. 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_HOST=localhost", "..."], "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 互相等待对方先输出，结果卡死。后来加了超时和最大轮次限制才解决。

5. 三者如何协同：一个分层架构的取舍逻辑

5.1 分层设计：知识层、检索层、编排层

把 Agentic RAG、LLM Wiki、Multi-Agent 放在一起看，它们其实对应系统的不同层次：

• LLM Wiki 是知识层：负责知识的组织、存储、更新。它决定了"系统知道什么"。
• Agentic RAG 是检索层：负责从知识层获取信息、判断充分性、多轮迭代。它决定了"系统怎么找到需要的信息"。
• Multi-Agent 是编排层：负责协调不同任务、不同工具、不同模型。它决定了"系统怎么组织复杂的处理流程"。

这三层不是必须全上。最简单的系统可能只有知识层（LLM Wiki）+ 基础检索；中等复杂度的加 Agentic RAG 做自适应检索；只有任务确实异构、需要多专业协作时，才上 Multi-Agent 编排层。

5.2 按场景选型：什么情况下上哪一层

我整理了一个选型参考，按场景复杂度递增：

关键原则是：从简单开始，按需升级。不要一上来就搭最复杂的架构。我见过太多项目，一开始就上 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 循环超限、或者置信度低于阈值时，自动转人工处理。这不是架构的失败，而是对用户负责。

这些心得没有什么高深的理论，都是一个个项目磨出来的。架构选型这件事，说到底不是技术问题，是对业务场景的理解问题。理解得越深，越知道该在哪里做减法。