考察点
「什么时候应该引入 Multi-Agent？为什么不要过早引入？」是这道题的题眼。面试官想确认你知道多 Agent 的成本（token 数倍、调试困难、通信冗余），以及中心化、流水线、民主讨论几种模式的适用边界。能讲出 Orchestrator-Worker 的难点是加分项。
参考答案
先泼冷水：默认别用多 Agent
Anthropic 在工程博客里写得很直接：多 Agent 系统的 token 消耗大约是单 Agent 聊天的 4 倍、单 Agent 带工具的 15 倍这个量级，而且调试时你要把多个 Agent 各自的轨迹按时间线对齐才能定位问题。我自己的经验也一致——大部分号称「多 Agent」的 demo，拆穿了一个强模型 + 好 prompt 的单 Agent 就能干，还更稳。
真正值得上多 Agent 的信号只有三个：
- 上下文装不下或互相污染：任务需要消化远超单个上下文窗口的信息，或者几个子任务的中间结果混在一起会干扰推理（比如同时分析 5 份竞品报告）。
- 天然并行：子任务彼此独立，并行能把端到端延迟砍掉一大半，收益大于协调成本。
- 需要完全不同的「人设」：比如「红队 Agent 攻击 + 蓝队 Agent 防守」，或者一个写代码一个挑刺，角色冲突放进同一个上下文会让模型精分。
三种协作模式
1. 中心化编排（Orchestrator-Worker / Supervisor）。一个主 Agent 负责拆任务、分派、汇总，若干 Worker Agent 各管一摊。LangGraph 的 supervisor、Anthropic 的多 Agent 研究系统都是这个结构。主 Agent 维护全局状态，Worker 之间不直接说话，通信是星型的，复杂度可控。难点在两个地方：一是拆任务的粒度——拆太粗失去并行意义，拆太细 Worker 反复要上下文；二是汇总——Worker 各自返回几千字，主 Agent 怎么融合成不丢信息又不超窗口的结论，通常需要强制 Worker 返回结构化摘要而不是原始过程。
2. 流水线（Pipeline / Sequential）。A 的产出是 B 的输入，像「检索 Agent → 分析 Agent → 写作 Agent → 校对 Agent」。本质上这更接近 Workflow 而不是自主协作，确定性最好，也最容易测，是我生产环境里的首选。每个环节可以独立替换模型和 prompt。
3. 对等讨论（Debate / 民主讨论）。多个 Agent 互相看对方的输出、辩论、投票收敛。AutoGen 的 GroupChat 就是这个路数。学术上有趣，生产上慎用：轮数不可控、token 消耗最凶，而且经常出现「讨论发散不收敛」的情况，必须设硬轮数上限。
两个必踩的坑
无限循环。A 把问题抛给 B，B 认为该 A 处理又抛回去。防御手段：消息计数器（单个任务总消息数上限）、路由规则（同一个 Agent 不能连续两轮被点名且无新信息）、以及 Supervisor 拥有强制终止权。
通信冗余。Agent 之间如果传递完整对话历史，token 会爆炸。工程做法是定义明确的消息契约：Agent 间只传结构化结果（结论 + 证据引用 + 置信度），过程轨迹各自留档不进消息体。Anthropic 的研究系统就是这么干的——子 Agent 只回传提炼过的发现。
真实落地的折中
我见过的生产系统大多是「一个 Supervisor + 2-4 个工具型子 Agent」的规模，不会更多。并且 Supervisor 的调度逻辑往往是半确定的：高风险路径写死规则（比如涉及写操作必须走审批 Agent），低风险路径才让模型自由调度。完全自主的 swarm 式协作目前还停留在 demo 阶段。
可能的追问
- 「Orchestrator-Worker 模式最大的难点在哪？」 任务分解粒度和结果汇总。拆分太细 Worker 缺上下文，太粗失去意义；汇总时多个 Worker 的长输出塞回主 Agent 会爆窗口，要靠结构化契约压缩。
- 「多 Agent 之间怎么共享记忆？」 优先共享「结果」而不是「过程」：公共的短内存（黑板模式）存结论，各自的详细轨迹私有；确实需要细节时用句柄引用，按需取。
- 「AutoGen、CrewAI、LangGraph 的多 Agent 怎么选？」 要确定性编排选 LangGraph（状态机显式），要快速验证对话式协作原型用 AutoGen/CrewAI，上生产前把不可控的自由对话收敛成显式状态转移。