这一篇和前面几篇不一样：前面讲「怎么把一件事做对」，这篇讲**「该不该做这件事」**。面试到 L3，考的是取舍判断力，而不是堆功能的能力。
一、导语：架构题考的是「减法」#
初级工程师听到「RAG 不够好」，反应是「再加一层」——加 reranker、加 query rewrite、加多路检索、加多 Agent。高级工程师听到同样的话，第一反应是归因：到底是哪一层不够好？能不能用更简单的方式解决？
这一篇要建立的判断力是：
每一个「更复杂的架构」，都必须回答一个问题——它换来了什么单 Agent 给不了的东西？换不来的，就是纯粹的复杂度负债。
我们用三个具体问题来练这个判断力：Agentic RAG 什么时候停、LLM Wiki 和 RAG 怎么选、Multi-Agent 什么时候才值得。
二、问题来源：复杂度是负债，不是资产#
先立一个基本盘：架构复杂度本身是成本。它带来：
- 通信损耗：Agent 之间传递信息，必然有信息丢失和格式转换。
- 状态不一致：多个执行体看到的世界可能不同步。
- 错误放大：一环出错，下游全错，且难定位。
- 成本倍增：每个 Agent 都有自己的上下文和模型调用。
- 调试地狱：一次失败要跨多个 Agent 的 trace 才能还原。
所以「拆」不是免费的。任何拆分方案要成立，它换来的收益必须显著超过这些负债。而绝大多数「看起来需要多 Agent」的场景，其实单 Agent 加一个好工具就够了。
面试里最怕的答案是「Multi-Agent 更强大 / 更接近人类组织」。这是把「拟人」当成了「工程论证」。下面我们逐个拆。
三、讲透 Q1：Agentic RAG——把检索从「预处理」变成「工具」#
3.1 普通 RAG vs Agentic RAG#
普通 RAG 的检索是一次性的、在生成之前的固定步骤：先检索，再生成。它的致命限制在第 10 期已经点破——多跳无力：答案分散在文档 1 和文档 3，一次检索只能返回「跟原始 query 最像的块」，它没法「先找 A、再拿 A 去查 B」。
Agentic RAG 的核心变化只有一句：
把「检索」注册成一个工具，让模型自己决定什么时候查、查什么、查几次。
模型不再是被动接收检索结果，而是像调用任何工具一样调用检索：先查「A 是什么」，看到结果后，再决定「我需要用 A 去查 B」，于是发起第二次检索。检索从「流水线的一道工序」变成了「Agent 循环里的一个动作」。
3.2 关键难点：什么时候停？#
把检索交给模型，立刻带来一个新问题：它可能一直查下去（每次都「再确认一下」），成本失控。所以 Agentic RAG 的工程核心不是「怎么让它查」，而是**「怎么让它停」**。
停止判据有两类，缺一不可：
- 软判据（信息收敛）：本轮检索带来的新增信息量趋零。如果这一轮召回的块跟上一轮高度重复、或与已掌握的上下文没有新信息，说明「再查也没用了」，该停。
- 硬兜底（max_rounds）：无论软判据怎么说，必须有一个
max_rounds硬上限。因为软判据本身依赖模型判断，模型可能误判「还有新信息」。硬兜底是最后的安全网。
面试加分点：能说出软判据 + 硬兜底必须同时存在。只有软判据 → 模型误判就无限循环；只有硬兜底 → 信息早就收敛了还在白烧钱。
3.3 代价#
Agentic RAG 不是白拿的：
- 延迟：多轮检索是串行的，每轮都要一次模型调用，延迟随轮数线性增长。
- 成本：每轮检索 + 每次决策都是 token 消耗。
- 不可预测：轮数不定，导致 P99 延迟和成本都不好估。
所以它的适用面很明确：需要多跳推理、且查询复杂度差异很大的场景。对于「简单事实问答」占绝大多数流量的系统，Agentic RAG 是过度设计——用一根固定流水线就够。
四、讲透 Q2：LLM Wiki vs 向量 RAG——两条知识路线#
4.1 本质区别：碎片检索 vs 预编译导航#
这是本期最有价值的对比。两者都在解决「让模型用上外部知识」，但路线完全相反：
| 维度 | 向量 RAG | LLM Wiki |
|---|---|---|
| 知识形态 | 碎片（chunk） | 预编译的结构化文档 |
| 组织方式 | 向量空间（隐式、无结构） | 显式目录 / 章节 / 交叉链接 |
| 检索方式 | 相似度召回 Top-K | 导航（先读目录，再定位章节） |
| 知识来源 | 原始文档切块 | 由 LLM 预先整理、归纳、去重、串联 |
| 更新成本 | 低（增量插入） | 高（要重新整理受影响的章节） |
| 适用知识 | 海量、异构、长尾 | 中等规模、高价值、需要整体理解 |
LLM Wiki 的核心思想：与其在查询时从碎片里「拼」答案，不如离线用 LLM 把知识整理成一份结构清晰、可导航的文档（像一个 Wiki）。查询时，先让模型读目录/摘要定位到相关章节，再读那一章。
这为什么有时更优？因为碎片检索丢掉了知识的结构关系。文档 A 说「X 依赖 Y」，文档 B 说「Y 依赖 Z」，向量检索可能只召回 A，模型就不知道 Z。而 Wiki 在离线整理时，已经把「X→Y→Z」这条链写进了同一段叙述里。结构是预编译进去的，不需要查询时现场拼。
4.2 成本结构：前移 vs 后移#
这是关键的工程差异：
- RAG 走「成本后移」：离线索引便宜（切块 + 编码），查询时才花力气（编码 + ANN + rerank）。随查询量线性增长。
- Wiki 走「成本前移」：离线整理贵（LLM 反复阅读、归纳、重写），查询时极便宜（读一份现成文档）。离线成本固定，与查询量无关。
于是存在一个盈亏平衡点：查询量少的系统，RAG 更划算（不用预先大投入）；查询量大的系统，Wiki 更划算（离线投入被摊薄）。
4.3 怎么选#
- 知识海量、异构、长尾、高频更新 → RAG（碎片检索的扩展性和增删便利无可替代）。
- 知识中等规模、高价值、需要整体理解、查询量巨大 → LLM Wiki（离线整理的结构化收益能覆盖成本）。
- 两者结合：用 Wiki 组织「核心概念与关系」，用 RAG 兜住「长尾细节」，查询时先导航 Wiki 再到 RAG 取细节——这也是很多知识密集型产品的真实形态。
五、讲透 Q3：Multi-Agent——唯一正当的理由是「隔离与收敛」#
5.1 先破题：错误理由 vs 正确理由#
面试官问「什么时候需要多 Agent」，最想听的是你能不能否掉那些错误理由：
| 错误理由 | 为什么错 |
|---|---|
| 「人多力量大 / 更接近人类组织」 | 拟人不是工程论证。组织成本在多 Agent 里被放大而非缩小 |
| 「任务复杂所以要拆」 | 复杂不等于要拆，单 Agent + 好工具常更优 |
| 「每个 Agent 专注自己的领域」 | 专注本身不产生收益，除非因此隔离了上下文或权限 |
| 「并行更快」 | 多数 Agent 任务是串行依赖的，并行只在真正独立时成立 |
唯一正当的理由，是拆分成多个 Agent 能带来单个 Agent 给不了的隔离 / 收敛：
- 上下文隔离：某个子任务的中间过程极度冗长（比如爬 50 个页面、跑一次大数据分析），如果塞进主 Agent 的上下文，会污染主上下文、挤占预算。把它隔离到一个子 Agent，只有它的最终结论回流主上下文，中间过程不外泄。这是最硬的收益。
- 权限隔离：不同子任务需要不同权限（一个只读检索、一个可写数据库）。从系统层面隔离执行体和权限，比在一个 Agent 里靠 prompt 约束可靠得多。
- 职责收敛：某个子任务的指令极其专门、会和主任务指令打架时，隔离成一个专职 Agent 能避免指令冲突（这与第 09 期「指令无强制力」相呼应——隔离是系统手段，不是 prompt 手段）。
5.2 五种拓扑#
| 拓扑 | 结构 | 适合 | 主要问题 |
|---|---|---|---|
| Supervisor | 一个主管 Agent 派活给多个执行 Agent | 任务可清晰切分、需统一调度 | 主管成为瓶颈与单点 |
| Sequential | Agent 串成流水线，前一个输出是后一个输入 | 有明确先后阶段 | 无回头路，前段错误放大 |
| Group Chat | 多 Agent 同处一个对话，轮流发言 | 需要多方讨论/辩论 | 极易失控、成本爆炸 |
| Blackboard | 共享一块「黑板」状态，各 Agent 读写 | 松耦合协作 | 状态一致性难保证 |
| Hierarchical | 多层 Supervisor 嵌套 | 超大规模任务 | 层级越深，损耗越大 |
生产里最常见、也最实用的是 Supervisor：一个主 Agent 负责规划和汇总，把「重且独立」的子任务外包给子 Agent，子 Agent 只回传结论。这恰好对应 5.1 的「上下文隔离」收益。
5.3 代价的量化意识#
Multi-Agent 的 token 消耗是单 Agent 的约 1.46 倍，为什么更贵？因为：
- 每个 Agent 都有自己的系统提示 + 上下文（重复开销）；
- Agent 之间传递结论本身要消耗 token（handoff relay）；
- Supervisor 要额外读所有子结论来汇总。
这正是回答「为什么不用一个强模型直接解决」的关键——很多人以为强模型能替代拆分，但强模型解决的是「单点智能上限」，解决不了「上下文污染」和「权限隔离」。哪怕你有一个无限聪明的模型，把 50 个页面的抓取过程塞进它的上下文，一样会污染、一样会烧钱、一样拿不到权限分级。所以：
Multi-Agent 的正当性来自「隔离」，而不是「智能」。想清楚要隔离什么，再决定拆不拆。
如果子上下文本来就小，拆分的重复开销可能压过隔离收益，这时多 Agent 反而可能更便宜——所以结论不是「多 Agent 一定更贵」，而是「要看被隔离的上下文有多大」。
六、深入讨论：子 Agent 结果校验#
拆出子 Agent 之后，一个新问题出现了：主 Agent 怎么信任子 Agent 回传的结论？
子 Agent 可能：跑偏了、幻觉了、输出格式不对了。如果主 Agent 无条件接受，错误会直接污染主任务。所以必须有结果校验：
- 格式校验：子 Agent 的返回必须符合约定 schema（结构化输出）。
- 合理性校验：主 Agent 要检查结论是否与已知事实矛盾、是否在合理范围内。
- 可追溯：子 Agent 的关键结论应附带证据（它读了哪些源、做了什么推导），便于主 Agent 或人工复核。
跨 Agent 的信任边界，本质和第 09 期「工具的信任边界」是同一件事——只要一个执行体的输出会成为另一个执行体的输入，就必须校验。
七、常见错误认识#
- 「复杂任务就该多 Agent」 —— 复杂 ≠ 该拆。单 Agent + 好工具常常更简单、更便宜、更好调。
- 「Multi-Agent 更强大」 —— 它增加的是隔离能力，不是智能上限；且默认更贵。
- 「Agent 越多越专业」 —— 每个 Agent 的重复上下文开销、handoff 损耗、错误放大都是实打实的成本。
- 「Agentic RAG 总是比普通 RAG 好」 —— 只在多跳场景好；简单事实问答用它等于给每次查询都加了不确定的轮数。
- 「让模型自己决定查几次就行」 —— 没有硬兜底，模型会「再确认一下」到天荒地老，成本失控。
- 「Wiki 只是另一种 RAG」 —— 路线相反：一个查询时拼碎片，一个离线预编译结构；成本一个后移一个前移。
- 「强模型能替代架构拆分」 —— 强模型解决单点智能上限，不解决上下文污染与权限隔离。
八、概念速查#
| 概念 | 一句话 |
|---|---|
| Agentic RAG | 把检索注册成工具，让模型自己决定查什么、查几次 |
| 软判据（信息收敛） | 本轮新增信息趋零则停 |
| 硬兜底（max_rounds） | 无论软判据如何都必须存在的轮数上限 |
| LLM Wiki | 离线用 LLM 把知识整理成可导航的结构化文档 |
| 成本前移 vs 后移 | Wiki 离线贵查询便宜；RAG 离线便宜查询贵 |
| 盈亏平衡点 | 查询量超过某阈值后，Wiki 的离线投入被摊薄而占优 |
| Multi-Agent | 多个独立执行体协作；正当性来自隔离与收敛 |
| 上下文隔离 | 子任务中间过程不外泄，只回传结论到主上下文 |
| 权限隔离 | 不同子任务分属不同执行体与权限，系统级而非 prompt 级 |
| Supervisor 拓扑 | 主管 Agent 派活 + 汇总，生产最常用 |
| handoff | Agent 之间传递结论的消耗 |
| 子 Agent 结果校验 | 对子 Agent 输出做格式/合理性/可追溯校验 |
| 错误放大 | 一环出错导致下游全错的链式效应 |
九、一句话总结#
Agentic RAG 的价值在多跳、代价是不确定性；LLM Wiki 用离线成本换查询效率，有盈亏平衡点；Multi-Agent 的唯一正当理由是上下文与权限隔离——解决不了这个，就别拆。
