多 Agent 有哪些编排模式？orchestrator-workers 适合什么场景？
谁在问：二面；平台组与做过多 Agent 系统的面试官会追到合成阶段与成本倍数
口语化问法
- 多 Agent 的编排模式你了解哪些？分别什么场景用？
- orchestrator-workers 这套，收益到底来自哪里？
- 你们为什么要拆成多个 Agent，一个不行吗？
考察意图
第三个问法是主线——面试官真正想知道的是你为什么要多。所以这题要同时答好两件事：模式清单（知识面）和选择理由（判断力）。他在验四层：
- 知不知道多 Agent 的收益主要来自上下文隔离和并行，而不是"专家更专业"。角色扮演式的分工在 2026 基本被证伪了。
- 能不能把 router 单独拎出来。 相当多号称"多 Agent"的系统，需要的其实只是一个分诊路由，成本差好几倍。
- 知不知道合成阶段是最容易丢信息的一环。 只讲分发不讲汇总的人，没做过完整链路。
- 算不算得清成本倍数。 多 Agent 通常贵数倍，说不出这条就是没上过线。
参考答案
60 分答案（及格线）
常见模式，按复杂度递增：
| 模式 | 结构 | 适合什么 |
|---|---|---|
| Router / 分诊 | 轻量分类器把请求分给专门 Agent | 输入类型差异大、各自需要不同工具集和提示词。最便宜、最常用 |
| 顺序管线 | Agent A 的输出交给 B | 阶段清晰、职责固定的流水线（本质接近 workflow） |
| Orchestrator-Workers | 主 Agent 拆任务，多个 worker 并行执行，再合成 | 任务可拆成互相独立的子任务、并行有价值、子任务上下文互不干扰 |
| 评审 / 辩论 | 一个生成、一个批评 | 有客观验证信号的产出（代码、数据） |
| 群聊 / 自由协作 | 多个 Agent 自由发言 | 灵活但极难控制，生产环境很少用 |
orchestrator-workers 的典型场景：多来源调研（每个 worker 查一个来源）、多模块改动（每个 worker 改一个模块）、批量比对（每个 worker 处理一批）。核心特征是：子任务之间不需要互相知道对方在干什么。
90 分答案（有生产经验的回答）
补四层。
1. 说清收益到底来自哪里——不是"专家"，是隔离与并行。
- 上下文隔离：每个 worker 只看自己那份材料，互不污染。单 Agent 串着做十个子任务，第十个的时候上下文里全是前九个的残渣，决策质量会掉（context rot）。这是 orchestrator-workers 最实在的收益。
- 并行：墙上时间从"求和"变成"取最慢"。
- 而"给每个 Agent 设一个专家人设，它就更专业"这件事，在 2026 的模型上收益已经很小了——同一个模型换个角色描述并不会真的更懂。截至 2026-08，模型上下文更长、能力更强，早期靠多 Agent 绕开的"窗口不够、角色混乱"问题，很多用单 Agent 加好工具集就解决了。所以默认应该是单 Agent，多 Agent 需要理由。
2. orchestrator-workers 的四个关键设计点。
- 分解粒度：子任务要足够独立。如果 worker 之间需要频繁交换中间结果，说明分解错了——通信成本会吃掉全部收益。
- 上下文契约：orchestrator 给每个 worker 的输入必须自足（任务目标、必要背景、输出格式），worker 不该反过来问。隔离过度也是常见故障：worker 缺关键背景，产出的东西没法用。
- 预算隔离：每个 worker 独立的 max_steps 和费用上限，加一个全局总预算；单个 worker 超时不能拖垮整体。
- 合成器：这是最容易丢信息的一环。worker 要返回结构化结果（含置信度、来源、未完成项），合成器按规则汇总而不是自由发挥。很多多 Agent 系统效果差，根因就在合成这一步把细节抹平了。
3. 三段式看 orchestrator-workers。
- 解决什么：上下文隔离、并行提速、子任务可独立重试。
- 代价是什么：token 消耗通常是单 Agent 的数倍（每个 worker 都有自己的系统提示、工具定义和上下文）；失败模式变多（分解错误会级联到所有 worker、worker 重复劳动、合成丢信息）；调试要跨多条轨迹；可复现性更差。
- 什么时候不该用：子任务强依赖彼此的中间结果；需要全局一致性的写操作（多个 worker 同时改一份状态是灾难）；任务本身很短（协调开销超过收益）；以及最常见的一种——其实只需要一个 router。
4. 判断顺序，我会这样问自己：能不能一个 Agent 加好工具解决？不能的话，是输入类型差异大（→ router）还是任务可并行拆分（→ orchestrator-workers）？有没有客观验证信号（→ 加一个 critic）？都不是就别拆。
追问链
五层全在问同一件事：你凭什么要多，多出来的钱买到了什么
orchestrator-workers最大的收益是什么？专家人设有用吗？期望最大收益是上下文隔离 + 并行——隔离让每个 worker 上下文干净、决策质量稳定，并行把墙上时间从求和变取最慢。专家人设在 2026 的模型上收益很有限；让「专业」落地的是不同的工具集、输出契约、评测标准，不是不同的身份。拆的正当理由是「需要不同的工具和上下文」信号明确否定人设收益、把「专业」归因到工具集与契约 → 跟上了 2026 的实践；答「多个专家协作所以更聪明」→ 停在早期叙事worker 之间需要互相通信吗？如果需要会怎样？
期望尽量不要：自由通信让沟通路径按平方增长，轨迹、成本、调试全失控。正确形态是星形——交互全经 orchestrator 中转，共享数据放外部存储、传句柄不传全文。worker 之间必须频繁交换中间结果，是分解粒度错了的信号，该把强耦合部分并进同一个 worker，而不是加通信机制信号给出「星形而非网状」「通信需求是分解错误的信号」→ 设计过；答「让它们互相讨论效果更好」→ 没面对过群聊模式的不可控合成阶段怎么做？workers 的结果互相冲突怎么办？
期望合成器要拿到元信息才可能做对：worker 返回结构化结果，含结论、置信度、来源、未完成项、失败原因；冲突消解要有明确规则（权威来源优先、多数一致、或回原始证据再判），不是让合成模型自由发挥。提防两类损失：细节抹平（丢关键数字与限定条件）和假一致（把分歧和成一段圆滑话）信号把合成器当成「信息瓶颈」并提出结构化返回 + 冲突规则 → 做过完整链路；只答「让主 Agent 总结一下」→ 正是效果差的那种做法多 Agent 通常贵几倍，你怎么判断值不值？
期望总成本 ≈ orchestrator + worker 的提示、工具定义与上下文，worker 一多，重复项就很可观。拿单 Agent 做 baseline 比成功率、P95时延、单位成本，覆盖不了倍数别上。省法：编排用强模型、worker 降档、共享前缀吃 prompt 缓存信号给得出「orchestrator 强、worker 降档」并强调 baseline 对照 → 算过账；只答「贵一些但效果好」→ 没量化过上了
orchestrator-workers，质量不如单 Agent、成本高 3 倍，查什么？怎么救？期望先止血：能切回单 Agent 就先切，没留开关是上线失误。分环节定位：① 分解——子任务独不独立（错了级联全体，最贵）；② worker 单跑都不行 = 契约给少了；③ 合成——原始结果比最终产出。第三环最常出问题，团队却先查第一环。救法：先修合成 → 再修契约 → 最后动分解。回收线：两周内追平单 Agent 成功率、成本 1.5 倍内，否则承认不该拆信号分环节定位、指出合成环最常出问题、给出回收线与「承认不该拆」的退路 → 真做过多 Agent 改造；只答「优化提示词」→ 没经历过沉没成本
高频题，但淘汰点不在模式清单：分水岭在第 3、4 层——认不认得出合成才是最丢信息的一环、算不算得清成本倍数；第 5 层再加一问：肯不肯说「这任务本来就不该拆」。
评分要点
- 列得出主要编排模式并说清各自适用场景
- 明确 router 是最便宜常用的一种，很多"多 Agent"需求其实只需要它
- 说清 orchestrator-workers 的收益是上下文隔离 + 并行
- 知道"专家人设"收益有限，专业性来自工具集与契约（截至 2026-08）
- 四个设计点：分解粒度、上下文契约自足、预算隔离、合成器
- 明确合成阶段是最容易丢信息的一环
- 说得出代价：成本数倍、失败模式增多、调试跨轨迹、可复现性更差
- 能说出什么时候不该用（强依赖、全局一致性写、短任务、其实只需 router）
- 加分：orchestrator 用强模型、worker 降档的成本结构
- 加分：worker 通信要星形中转，频繁通信是分解错误的信号
常见错误
「多个专家 Agent 协作，效果比单个好」——2026 已基本证伪的叙事，说不出隔离与并行这两个真收益。
把所有多 Agent 需求都做成 orchestrator-workers，想不到 router 这个更便宜的解。
只讲怎么分发，完全不讲怎么合成——最常见的漏项，也正是效果差的根因。
允许 worker 之间自由通信，说不出成本与可控性代价。
不知道多 Agent 的 token 成本是数倍量级，也没有单 Agent baseline 做对照。
多个 worker 并发写同一份状态，没有一致性方案。
改造上线不留回退开关，出问题只能硬撑。