多 Agent 场景边界与部署模式：串行 vs 层级分发（口播版）
面试高频问题：什么场景该上多 Agent？什么场景不该上？上了之后怎么部署？ 一句话答案：多 Agent 是组织复杂度的手段，不是提升智能的手段。适用长链路、多角色、可并行、可验收的场景；低延迟、逻辑确定、强状态耦合的场景一律禁用。部署就两种主模式：串行流水线（有依赖的工序流）和层级分发（可并行的子任务），落地主要治死循环和成本两件事。 适用面次：二面深度 / 三面综合 / 架构深挖 本版定位：口语应答脚本 —— 是 09 号 的正向补全篇：09 号讲"为什么不用"（取舍），本篇讲"什么时候用、用了怎么部署"。冲突治理细节见 19 号，本篇不重复。
【30 秒极简版】（面试官随口一问时用）
先摆正一个认知：多 Agent 解决的是组织复杂度，不是让模型变聪明。单 Agent 解决不了的问题，拆成十个 Agent 通常也解决不了。 该上的场景是四类：长链路多角色工作流、需要角色/权限隔离、子任务可并行、需要对抗式质量（生成者 vs 审查者）。 不该上的也是四类：低延迟、逻辑确定、强状态耦合、拆分后边界模糊难验收——该用代码就用代码，该用工作流引擎就用工作流引擎。 部署两种：串行流水线适合有依赖的工序流，难点是错误沿链放大；层级分发适合可并行的子任务，难点是协调者瓶颈和汇总时的语义漂移。 落地两大拦路虎：死循环靠跳数上限 + 请求去重 + 收敛判据；成本靠模型分级 + 上下文按角色裁剪 + 早停。
【2 分钟完整口播】（正式被问到时的主干回答）
我先立一个判断，这个判断本身就是答案的一半：多 Agent 解决的是组织复杂度，不是提升智能。如果单 Agent 搞不定，拆成十个通常也搞不定——多 Agent 的价值在于分工、并行、隔离、对抗，不在于更聪明。
所以该上的场景是四类。一是长链路多角色工作流，比如调研、写作、审阅、修订，每段的思维和工具都不一样，硬塞进一个 Agent 会让 prompt 打架。二是需要角色和权限隔离，不同 Agent 拿不同的工具权限，比如只读数据的不能写库。三是子任务可并行，能切开且互不冲突，这样才有并行收益。四是需要对抗式质量，一个生成、一个审查， critics 机制确实能把质量拉上来。
不该上的也是四类。第一，低延迟场景——每一跳都是一次大模型调用，延迟是线性叠加的，多 Agent 天然慢。第二，逻辑确定的流程——用代码或工作流引擎写死就行，更便宜更稳，让模型去猜流程是浪费。第三，强状态耦合、需要全局一致视图的任务——协调成本大于并行收益。第四，拆分后边界模糊、产出难验收的任务——这会变成摆烂的温床，每个 Agent 都以为别人做了。
如果要给一个判断公式，就看：并行收益加角色价值，是否大于协调成本加延迟成本加一致性风险。算不清就先不上。
部署模式主要两种。第一种串行流水线：A 出完给 B，B 出完给 C，前一节点输出就是后一节点输入，适合有依赖的工序流。它的难点是错误沿链放大——前面错了后面全错，所以每个节点必须配可判定的完成判据，中间结果schema 化，不达标不许往下传。
第二种层级分发：一个协调者拆任务、分发给多个子 Agent、再汇总。适合可并行的子任务。它的难点有两个：一是协调者成为瓶颈——任务越多它越忙，百级以上就撑不住了；二是汇总时的语义漂移——各子 Agent 的理解有细微偏差，汇总起来就跑偏了。
落地两个拦路虎。第一个死循环：Agent 之间互相踢皮球，或者反复请求同一个东西。解法是三件套——跳数上限（超过 N 跳强制中断）、请求去重（同一发起方加同一请求出现多次即判定循环）、收敛判据（看进度有没有实质推进，没有就中断升级人工）。这跟单 Agent 的进度熔断是一个思路。
第二个成本：token 消耗基本是Agent 数乘以轮次的乘积级增长，很容易失控。三招——模型分级，路由、摘要、格式整理这类机械活用小模型，只有真正需要推理的才上大模型；上下文按角色裁剪，子 Agent 只拿自己需要的那一片，不给全量；早停，达成判据就停，不做多余轮次。再加一条，每跳留痕，不然成本涨了你都不知道涨在哪。
一句话收尾：上多 Agent 之前先问一句：这个任务是"一个人干不过来"，还是"一个人干不明白"？前者才需要多 Agent。
一、先立判断（第一得分点）
开口说：
多 Agent 解决的是组织复杂度，不是提升智能。
得分句："如果单 Agent 干不明白，拆成十个通常也干不明白。"
二、场景边界（该上 vs 不该上）
✅ 该上（四类）
| 场景 | 为什么单 Agent 不行 |
|---|---|
| 长链路多角色工作流 | 调研 / 写作 / 审阅 / 修订，各段思维与工具不同，塞一起会 prompt 打架 |
| 需要角色 / 权限隔离 | 不同 Agent 拿不同工具权限（只读的不许写库），隔离即安全 |
| 子任务可并行 | 切开后互不冲突 → 有真实并行收益（详见 19 号） |
| 需要对抗式质量 | 生成者 + 审查者（critic），对抗确实能拉高质量 |
❌ 不该上（四类）
| 场景 | 硬伤 |
|---|---|
| 低延迟 | 每跳一次 LLM 调用，延迟线性叠加，多 Agent 天然慢 |
| 逻辑确定 | 用代码 / 工作流引擎写死就行，更便宜更稳（呼应 09 号） |
| 强状态耦合 | 需要全局一致视图，协调成本 > 并行收益 |
| 边界模糊难验收 | 拆完说不清谁负责什么 → 摆烂温床（呼应 20 号） |
判断公式（加分）
并行收益 × 角色价值 > 协调成本 + 延迟成本 + 一致性风险 —— 算不清就先不上。
三、两种部署模式
模式一：串行流水线（Pipeline）
| 项 | 内容 |
|---|---|
| 结构 | A → B → C，前一节点输出 = 后一节点输入 |
| 适用 | 有依赖的工序流（必须先查后写、先生成后审阅） |
| 难点 | ⚠️ 错误沿链放大——前错后全错 |
| 对策 | 每节点配可判定的 DoD；中间结果schema 化；不达标不许往下传 |
模式二：层级分发（Supervisor / Hierarchical）
| 项 | 内容 |
|---|---|
| 结构 | 协调者拆任务 → 分发子 Agent → 汇总结果 |
| 适用 | 可并行的子任务 |
| 难点一 | ⚠️ 协调者成为瓶颈（吞吐 / 单点，规模上限见 19 号） |
| 难点二 | ⚠️ 汇总时语义漂移（各子 Agent 理解有细微偏差，汇总即放大） |
补充：对等式辩论（debate）可视为层级分发的变体——协调者换成"辩论规则 + 裁判"。
四、落地难点一：死循环
速记：限跳数 · 去重复 · 看收敛
| 招 | 做法 |
|---|---|
| 跳数上限 | 超过 N 跳强制中断，升级人工 |
| 请求去重 | 同一 (发起方, 请求) 对出现 N 次 → 判定循环，立即中断 |
| 收敛判据 | 不看"有没有在动"，看进度有没有实质推进；无推进即熔断 |
呼应 10 号：与单 Agent 的进度熔断同源——判据是"是否收敛"，不是"是否忙碌"。
五、落地难点二：成本
速记：分级用模型 · 裁剪上下文 · 达成即停
| 招 | 做法 |
|---|---|
| 模型分级 | 路由 / 摘要 / 格式整理等机械活 → 小模型；真推理才上大模型 |
| 上下文按角色裁剪 | 子 Agent 只拿自己需要的分片，不给全量（呼应 20 号"引用代替复制"） |
| 早停 | 达成判据即停，不做多余轮次（不追求"再优化一轮"） |
| 每跳留痕 | 成本可归因，否则涨了不知道涨在哪（呼应 10 号过程合规） |
量级认知：成本 ≈ Agent 数 × 轮次的乘积级增长，不是线性。
六、避坑提醒
- ❌ "任务太难，多拆几个 Agent 就好了" → ✅ 多 Agent 不提升智能，只解决组织复杂度
- ❌ 什么场景都想上多 Agent → ✅ 先过判断公式，逻辑确定的用代码更优
- ❌ 串行链路不做中间校验 → ✅ 每节点 DoD + schema 化，防错误放大
- ❌ 只谈能力不谈成本 → ✅ 主动报成本三招，这是工程成熟度的标志
- ❌ 编数字（"成本降了 60%"）→ ✅ 说"以 trace 实测为准，具体值暂未带"
七、面试官在考什么
| 维度 | 你的证据 |
|---|---|
| 克制力 | 能主动说出不该上的场景——比"什么都能上多 Agent"高一个段位 |
| 架构认知 | 两种部署模式各自的适用条件 + 专属难点，不是只报名字 |
| 工程落地 | 死循环三件套、成本三招，都是可立即实施的机制 |
| 体系一致性 | 与 09（取舍）、19（冲突）、10/20（熔断与判据）形成闭环，不是散点 |
八、追问预案（Q&A 演练）
Q1：多 Agent 一定比单 Agent 好吗？
不一定。任务是"一个人干不过来"才需要多 Agent；如果是"一个人干不明白"，拆了也没用，应该换模型、换提示、换工具。而且多 Agent 会引入协调成本、延迟、一致性三类新风险。
Q2：协调者成为瓶颈怎么办？
按规模分级：小规模中心化够用（好排查）；中规模做协调者分片（按业务域拆多个协调者）；百级以上走去中心化——规划期提前分片避开冲突，执行期用 CRDT 做无冲突合并（详见 19 号）。
Q3：子 Agent 结果汇总时语义漂移怎么治？
三条：交接包schema 化（不许自由文本交接）、关键实体用 ID 不用描述、随包传术语表；终点再做一次与原始目标的一致性回检。详见 25 号。
Q4：串行和层级分发能混用吗？
能，而且生产里基本都是混的：主干用串行（保证工序顺序），主干内的可并行环节用层级分发（提速）。判断依据就是"这一步有没有依赖"。
Q5：怎么判断拆得够不够好？
看两个信号：子任务是否有独立可判定的 DoD（没有就说明边界模糊），以及子任务之间是否真的零冲突（有冲突就说明拆错了，该重拆而不是加锁）。
全篇串联（考前 10 秒扫这个）
先立判断：多 Agent 解决组织复杂度，不提升智能
→ 该上四类：长链路 · 权限隔离 · 可并行 · 对抗质量
→ 不该上四类：低延迟 · 逻辑确定 · 强耦合 · 边界模糊
→ 判断公式：并行收益+角色价值 > 协调+延迟+一致性风险
→ 部署：串行（防错误放大）· 层级分发（防协调者瓶颈+语义漂移）
→ 落地：死循环（限跳数·去重复·看收敛）· 成本（分级·裁剪·早停）关联笔记：09多Agent架构取舍-客服场景为什么不用多Agent（取舍视角：09 讲为什么不用，本篇讲什么时候用，是一对）、19多Agent协同冲突规避-任务分片仲裁与状态版本控制（冲突治理细节：分片仲裁、版本控制、中心化→去中心化演进，本篇不重复）、25Agent协作机制-服务发现能力对齐状态交接三层（协作机制：语义漂移的具体治法在那篇）、10Agent长任务失控治理-任务管控三层体系与执行闭环（熔断与收敛判据同源）、20Agent长任务不跑偏也不摆烂-目标铰链与反敷衍机制（DoD 判据与摆烂温床）、11Agent架构选型-七种架构与选型逻辑（更上层的架构选型框架）