先这样答
编排模式我按三种基本形讲，真实系统多是它们的组合。
主从式（Orchestrator-Worker）：一个主 Agent 负责拆解任务、分派给子 Agent、汇总结果。子 Agent 之间不直接说话，全通过主 Agent 中转。这是最常用的形态：控制权集中，出问题好排查，子 Agent 也不用知道全局。复杂系统的主从还能嵌套：主 Agent 分派给中层 Agent，中层再带自己的小组。
流水线式（Pipeline）：任务按阶段接力，写作者 → 审校者 → 排版者，上一级的输出是下一级的输入。适合流程天然分段的场景，好处是每个环节可以独立评测和替换，坏处是链路长、延迟累加、上游错了下游全错，所以流水线的每个接口都要有质量闸门。
群聊式（Blackboard/Group Chat）：所有 Agent 共享一个消息板，各自看到消息后决定要不要发言、要不要认领任务。灵活，适合需要多视角碰撞的任务（方案评审、头脑风暴），但控制力弱，容易吵起来或集体沉默，通常要配一个主持人角色。
通信设计上的要点，比模式选择更值得讲。消息要结构化：任务描述、输入、期望产出、验收标准都写成明确的字段，不要靠「你看着办」。上下文要控制：给子 Agent 的消息里只放它需要的部分，不要把全局聊天记录全量广播，群聊式最常见的失败原因就是消息板爆炸。状态要落盘：任务状态、中间产物存到外部存储，Agent 崩了能从断点恢复，做到这一点才谈得上生产可用。
面试官会怎么追问
- 主 Agent 自己出错怎么办？ 主 Agent 的决策也留轨迹可回放；关键分派动作加校验（分派前检查子任务定义完整性）；系统设计上保证任何 Agent 都可以重启恢复，主 Agent 不持有独占状态。
- 两个子 Agent 结论冲突怎么仲裁？ 回到主 Agent 仲裁，主 Agent 拿两个结论 + 各自依据做裁决；裁决规则提前写进协议（比如「数据类结论以带数据来源的为准」），减少每次临时判断。
- 跨系统、跨团队的 Agent 怎么编排？ 到了组织边界就要上标准协议：A2A 这类 Agent 互操作协议做发现和委托，内部怎么编排是各家的自由。
回答的坑
- 报一堆框架名不讲模式。面试官要的是编排模式的工程权衡，不是产品清单。
- 通信全靠自然语言自由发挥。结构化消息和验收标准是协作不散架的前提，这点必须主动说。
—— 本题完 ——