多智能体与主管模式 Multi-Agent & Supervisor Pattern

所属：01-fundamentals / 04-agent-architecture
面试权重：★★★
来源：通用领域知识（B站「AI Agent 八股」合集高频）；未做一手考证
相关项目：Writing Copilot —— LangGraph 多智能体写作（web_agent / news_agent / writing_agent）；Race Bot —— 编排式工作流 → 见 02-interview/projects/writing-copilot.md、02-interview/projects/race-bot-hkjc.md

一句话#

多智能体是把任务按职责与上下文需求切给不同的 agent，用 supervisor / router / pipeline 等拓扑协作；它的核心收益是上下文隔离，核心代价是错误复合与成本上升 —— 所以它是一把有明确适用边界的工具，不是「更高级的架构」。

为什么重要（面试角度）#

这是最能体现架构判断力的一题。面试官想看的不是你会不会说「supervisor 负责分派任务」，而是：

• 你能不能说出多智能体什么时候有害（这题答不上来，说明你只做过 demo）
• 你知不知道收益的具体机制是上下文隔离，而不是「多个 agent 更聪明」
• 你理解错误复合在多 agent 里的放大效应
• 你讲得清 LangGraph 的图 + 共享状态模型，以及 handoff 里上下文怎么传
• 你能解释 Writing Copilot 为什么拆三个 agent —— 这是你的一手经验

核心内容#

拓扑形态#

Race Bot 用的是 router 型编排（意图识别后分流到 KB / 搜索 / Text2SQL，各走各的，不回头），Writing Copilot 用的是更像 supervisor + pipeline 的混合（有个编排层按需调用 web_agent / news_agent，最后由 writing_agent 成文）。

收益：先判「值不值得做」，再谈「怎么实现」#

⚠️ 这里有两个不同层级的问题，混为一谈是最常见的错答方式。 本文此前只讲了下面那一层，补充上面那层：

面试官问「多智能体到底强在哪」，问的是判据层；只答「上下文更聚焦、工具集隔离」答的是效率，不是能力上限。两层都要答。

判据层：只认「新信息」#

核心判据只有一条：协作过程是否引入了单个 Agent 在生成时无法获得的新信息？

几条可直接引用的证据：

• 自我审查不可靠：GPT-4 在没有外部反馈时自审，把对的改错的次数多于把错的改对的（Huang et al., ICLR 2024）。TACL 2024 的综述也得出同样结论。
• 有外部反馈就有效：CRITIC（ICLR 2024）用外部工具验证即显著提升，移除工具验证后提升大部分消失；RLEF（2025）证实执行反馈优于独立多次采样；WebGen-Agent（2025）靠多层级视觉反馈把 Claude 3.5 Sonnet 从 26.4% 提到 51.9%。
• 它解释了一个看似矛盾的现象：学术研究说「多 Agent 不提升能力上限」，工程实践说「多 Agent 确实更好」—— 因为学术比的多是「多个 Agent 看同一段上下文互相讨论」（无新信息），工程有效的多 Agent 都含外部反馈环（有新信息）。
• 一个漂亮的规模案例：45 个 Agent 通过共享论坛协调、互相审查、独立 Agent 仲裁，用 2700 万 token 找到 266 个漏洞；而独立 Agent 并行方案用 650 万 token 只找到 21 个。开放搜索空间里，通信带来的是搜索重点的动态转移与分工，用更高预算换更广覆盖。

一句能立住的话：多 Agent 的收益不来自「多个脑子」，来自「多个信息源」。 让两个 Agent 看同一段文本互相审，是在花两倍的钱买同一份信息。

⚠️ 一条反直觉但重要的补充：增加步数预算不保证提升。标准 Agent 缺乏「预算意识」—— 即使给 300 步，它仍倾向浅层搜索后很快「饱和」（Google 2025《Budget-Aware Tool-Use》）。落地指导：Manager 应动态分配步数预算（简单子任务少给、复杂子任务充足），并引导子 Agent 先规划、再实现、再测试，而不是一头扎进去。

机制层：上下文隔离#

单 agent 做「检索 + 写作」时，检索回来的大量网页内容会占满上下文：既稀释了写作指令（指令被埋在大段文本里），又挤掉了本来能放进去的其他信息。拆成两个 agent 后：

web_agent 的上下文：搜索工具描述 + 检索结果 + 清洗逻辑（几百 KB 的中间过程）
        ↓ 只传出：结构化摘要 / 提炼后的事实
writing_agent 的上下文：写作指令 + 格式约束 + 摘要（干净、专注）

收益来自三处：

1. 每个 agent 的上下文更聚焦 —— 工具描述只带自己需要的，噪声少，指令不被稀释
2. 工具集被隔离 —— web_agent 有 30 个检索工具，writing_agent 只有 2 个，工具选择准确率显著提升（见 tool-use.md）
3. 可独立评测与替换 —— 检索质量差就只改 web_agent，不必动 writing_agent

必须同时说出代价：上下文隔离意味着信息传递是有损的。子 agent 把结果压缩成摘要交给上层，被丢掉的细节可能恰恰是下游需要的。所以「隔离」和「信息完整性」是一对必须权衡的东西 —— 隔离得越彻底，跨 agent 传递的损失越大。

代价：错误复合与成本#

错误复合：n 个 agent 串联，各自准确率 p，端到端约为 p^n。更糟的是多 agent 的错误不只是串联：

• supervisor 的判断错了 → 选错了子 agent → 子 agent 再正确也没用
• 子 agent 的摘要丢了关键信息 → 下游 agent 在缺失信息下工作，但它不知道自己缺信息（这比报错更危险）
• agent 之间来回 handoff 时上下文被反复重述，每次重述都可能引入漂移

成本：每个 agent 都有自己的系统提示 + 工具定义 + 历史，这些都是重复的常驻开销。一个 3 agent 的系统，仅固定开销就可能是单 agent 的若干倍，再加上 supervisor 要额外读所有子结果。业界普遍观察到多智能体的 token 消耗比单次调用高一个数量级甚至更多，延迟也随串联层数线性上升。

⚠️ 关于「要不要给数字」的正确口径（本文此前写的是「不要抛精确数字」，太宽了，会把有出处的证据一起禁掉）：不要抛的是「无出处的印象倍数」，不是「有实验条件的已发表数字」。

可引用的有出处例子：LongHorizon-Harness 的 Manage–Execute–Audit 把 WeaveBench 从 51.8% 提到 80.7%、OSWorld 2.0 从 2.8% 到 8.3%、Terminal-Bench 2.1 从 69.7% 到 77.2%，代价是总 token 2.3 倍、输出 token 3.6 倍；而 Terminal-Bench 上 token 减少 24%（说明代价随任务类型差异极大）。Anthropic 漏洞挖掘是 2700 万 token / 266 漏洞 vs 650 万 / 21 漏洞。

「有一篇 2026 年的实验报道 2.3 倍总 token，且代价随任务类型差很多」远强于「大概一个数量级」—— 前者显示你读过一手材料，后者显示你在猜。

调试成本：单 agent 的轨迹是一条线；多 agent 的轨迹是一棵树，失败点可能在任意节点，且「哪个 agent 的错」往往不直观。可观测性（链路追踪到每一步的输入输出）从「加分项」变成「必需品」。

多智能体特有的六种失败模式#

这一节是全篇最值钱的部分之一 —— 它回答「多智能体的代价长什么样」。上面的「错误复合」只是其中一种。六种各有名字，都能当场讲。

两条框架级的补充：

• 失败模式有系统研究支撑：2025 年《Why Do Multi-Agent LLM Systems Fail?》覆盖 7 个主流框架（MetaGPT / ChatDev / AG2 / Magentic-One 等）、约 150 条轨迹人工标注，归纳出 14 种失败模式 / 3 大类（系统设计缺陷、Agent 间对齐失败、任务验证缺失），标注一致性 Cohen's kappa = 0.88（说明这些模式是可复现识别的，不是事后编故事）。关键结论：简单修补效果有限（ChatDev 只提升 15.6%） → 这些是根本性设计缺陷，不是工程 bug。
• 用分布式容错的词汇看它：崩溃故障（停摆）vs 拜占庭故障（继续工作、但给出错误信息）。Agent 的故障天生是拜占庭式的 —— 它很少径直停止，而是继续给出看似可信的错误结论，且错误不会主动声明自己是错误。这解释了为什么交叉验证与多数表决这类拜占庭容错的经典手段在这里同样必要：你没法靠「等它报错」发现问题。

什么时候多智能体有益#

⚠️ 下面这一列是「机制层」的条件（什么时候隔离有收益），不是「判据层」的答案。 回答「该不该上多 Agent」时，先过判据层那一关（协作有没有引入新信息），再看下面这些隔离条件成不成立。只答下面这串，会被反问「那让两个 Agent 看同一份材料互审，也符合你的条件吗？」—— 按判据层，那不算收益。

另外注意：「子任务可并行」是延迟收益，「可独立评测替换」是维护性收益，两者都不是能力增益。 说清楚是哪一类收益，比笼统说「有收益」更可信。

• 工具集不重叠且都很大 —— 隔离是刚需（最常见的正当理由）
• 上下文需求冲突 —— 一个 agent 要大量检索噪声，另一个要干净的长文写作
• 子任务可独立评测、独立替换
• 子任务可并行 —— 并行检索、并行调研，延迟收益真实
• 需要不同模型档位 —— 便宜的 agent 做抽取，贵的 agent 做判断
• 需要不同权限 —— 一个 agent 有写权限，另一个只有读权限（安全边界隔离）

什么时候多智能体有害#

• 任务本身就是线性的、短的 —— 加 agent 只是加了延迟和失败点
• agent 之间需要频繁共享大量上下文 —— 那等于没隔离，只是把单 agent 拆碎并付了通信成本
• 正确性要求高、失败代价大 —— 错误复合在这里最不可接受
• 还在探索阶段、需求未定 —— 先让单 agent 跑通，知道瓶颈在哪再拆
• 团队没有可观测性基础设施 —— 多 agent 出错你根本查不出来

判据：先做单 agent，只在遇到具体瓶颈（工具太多选不准、上下文被污染、需要并行）时才拆。 不要先设计多 agent 架构再找理由。

LangGraph 的图 + 共享状态模型#

LangGraph 用图来描述 agent 系统：

节点（node） = 一个函数或一个 agent（一次计算）
边（edge）   = 控制流
条件边        = 根据当前状态决定走哪条边（这就是路由 / 分派）
共享状态      = 贯穿全图的单一可信数据结构，节点读它、写它

几个关键设计点（概念层面，具体 API 以你实际使用的版本为准）：

• 共享状态是单一事实来源：不靠消息在 agent 之间传来传去，而是每个节点从同一个 state 读写。好处是可控、可序列化、可恢复；风险是状态会膨胀（所有东西都往里塞），且容易出现「谁改了这个字段」的隐式耦合。所以 state 的 schema 设计是这类系统的核心工作 —— 要明确区分「对话历史」「工具产物」「任务中间结果」。
• 持久化（checkpoint）：状态可以按步持久化，于是支持中断恢复、时间旅行回放、以及人在环中的暂停（见 human-in-the-loop.md）。这是「图 + 状态」相对「自由循环」的主要工程收益。
• 条件边做路由：supervisor 在实现上往往就是一个「读 state → 决定下一个节点 → 写 state」的节点，并不神秘。去掉包装，supervisor 就是一个分类器 + 一段调度代码。
• 循环：图可以带环，这正是 agent 循环（重试、反思）的实现方式，因此循环必须配终止条件。

为什么用图而不是「让模型自己决定」：因为图把控制流显式化了。显式的边可枚举、可测试、可画出来给同事看；而「模型自己决定调用哪个 agent」的控制流只存在于运行时。Race Bot 里「每一步可独立替换和评测」的收益，来源就是这个显式化。

Handoff：移交什么#

handoff 是「控制权 + 上下文」一起移交。工程上要显式定义三件事：

1. 交什么：是完整历史、还是摘要、还是只有任务描述？（这是隔离程度的选择）
2. 怎么交：通过共享 state 的字段（结构化，推荐）还是通过自然语言转述（灵活但会漂移）
3. 交回什么：子 agent 完成后，向上一级返回什么结构（结论 + 依据 + 置信度 + 失败原因）

最常见的错误：让子 agent 用自然语言写一段总结交给下一个 agent。信息损失不可控、格式不稳定、下游还要再解析。推荐做法是让 handoff 走结构化字段 —— 有明确的 schema，可校验、可评测。

常见面试问法#

Q：为什么用多智能体而不是一个大 agent？ A：核心收益是上下文隔离，具体体现在三点：每个 agent 的工具集更小所以选择更准；每个 agent 的上下文更聚焦，检索噪声不会污染写作指令；每个 agent 可独立评测和替换。用 Writing Copilot 举例：web_agent 和 news_agent 会产生大量中间内容，如果和 writing_agent 共用一个上下文，写作指令会被稀释、工具数也会膨胀。

Q：多智能体有什么代价？ A：三块。① 错误复合：supervisor 选错子 agent、子 agent 摘要丢信息，都会让下游在错误前提下工作，且下游往往不知道自己缺信息；② 成本与延迟：每个 agent 都有重复的常驻开销（系统提示 + 工具定义 + 历史），加 supervisor 还要读所有子结果，链路也变长；③ 调试与评测复杂度：轨迹从一条线变成一棵树，失败点难定位，所以可观测性从加分项变成必需品。

Q：supervisor 模式怎么实现的？ A：概念上 supervisor 就是「读当前状态 → 决定下一个该谁做 → 写状态/分派」的节点，本质是一个分类器加一段调度代码。在 LangGraph 里就是一个节点加条件边。所以它不神秘，但它也是单点：它的上下文会累积所有子 agent 的结果，任务一复杂就会成为瓶颈，这也是分层主管出现的动机。

Q：LangGraph 的共享状态模型是什么？ A：图由节点、边、条件边和共享状态组成。状态是贯穿全图的单一可信数据结构，节点从它读、往它写，控制流由条件边根据状态决定。好处是控制流显式、状态可序列化因而支持持久化与中断恢复；风险是状态膨胀和隐式耦合，所以 state schema 的设计（严格区分对话历史、工具产物、任务中间结果）是关键工作。

Q：你的 Writing Copilot 为什么拆成三个 agent？ A：三个角色的工具集和上下文需求完全不同：web_agent 要搜索与爬取、news_agent 要新闻源与时间过滤、writing_agent 要长上下文与格式约束。塞进一个 agent 会导致工具描述冗长、选择错误率上升，且检索结果会把写作质量挤掉。拆开之后每个 agent 的上下文是隔离的，这也是多智能体的核心收益。同时我也接受它的代价：agent 之间传递会有信息损失，所以关键结论走结构化字段而不是自然语言转述。

易错点#

• ❌ 认为「多 agent = 更聪明 / 效果更好」。收益来自上下文隔离，不是因为数量多。
• ❌ 把 pipeline 叫多智能体 —— 固定顺序的链就是 workflow，不需要 agent 包装。
• ❌ 只讲收益不讲代价，尤其是错误复合和多一层成本。
• ❌ 让 handoff 走自然语言总结（信息损失不可控、格式漂移）。
• ❌ 忽略 supervisor 是单点：它的上下文会累积所有子结果。
• ❌ 在没有可观测性的情况下上多 agent，出错后无法定位。
• ❌ 一开始就设计多 agent 架构，而不是从单 agent 出发按瓶颈拆。
• ❌ 给出「多 agent 成本是单 agent 的 N 倍」这类精确数字 —— 依实现而变，说方向。

自测#

1. 多智能体的核心收益是什么？请从「上下文」的角度解释，而不是从「多个 agent 分工」的角度。

2. 一个 4 个 agent 串联的系统，每个 agent 的准确率都是 95%。端到端大概是多少？除了这个数字之外，还有什么更隐蔽的风险？

3. 什么时候你会明确拒绝使用多智能体？给出至少三个场景。

4. LangGraph 里「共享状态」的设计为什么是关键工作？说清它的收益和风险。

5. handoff 时你会传递什么？为什么不用自然语言总结？