Agent Orchestration：五种协作架构
比较 Sequential、Concurrent、Group Chat、Handoff 与 Magentic 五种多 Agent 编排：谁决定下一步、状态存在哪个节点、结果怎样收敛、一个 Agent 出错波及多远，以及每种架构的故障与恢复。
多 Agent 的核心设计问题不是“需要几个角色”，而是谁决定下一步、状态存在哪里、结果怎样收敛，以及一个 Agent 失败会影响哪些工作。先回答这四个问题，再谈用什么框架。
想亲手走一遍四种拓扑、注入故障再恢复，打开互动 Lab：/system-design-lab/agent-orchestration-architectures。
有约束的设计问题
一家电信公司的客服系统要用几个专长不同的 Agent 处理请求：有的请求是固定流程的资料整理，有的要同时听取技术、账务、合规三个视角，有的聊几句才知道该找哪位专家，还有的是没有预定步骤的故障处置，执行者手里的工具会改动生产系统。每一类该用哪种协作方式？
先说一条前提：一个带多个工具的 Agent，或者一条确定性的工作流能做完的事，不要加 Agent。 多一个 Agent 就多一次模型调用、一段延迟、一个追踪面和一条不可预测的路径。
五种 topology signature
| 架构 | 控制路径 | 谁决定下一步 | State owner | 适合 | 主要代价 |
|---|---|---|---|---|---|
| Sequential | 请求 → A → B → C → 结果 | 工作流定义，Agent 没有选择权 | 逐段写入的 workflow state | 有先后依赖的逐步加工（起草 → 审阅 → 润色） | 前序错误一路传播；不能并行、不能回头 |
| Concurrent | 请求 → dispatcher → A / B / C 并行 → reducer → 结果 | dispatcher（固定一组或动态挑选） | 中间结果 + 合并策略 | 同一输入的多个独立视角；等不起串行 | 结果矛盾要有裁决策略；并行调用打满配额 |
| Group Chat | manager ↔ 共享对话线程 ↔ agents | chat manager 决定谁下一个发言 | 累积的对话线程 | 多轮审议、头脑风暴、maker-checker | 容易循环；Agent 越多越难控制 |
| Handoff | 请求 → 当前 Agent → 转交 → 下一位专家 → … → 结果 | 当前活跃的 Agent | 交接信封（handoff envelope） | 专长在处理过程中才显现 | 无限转交；路由不可预测；上下文逐跳变长 |
| Magentic | 目标 → manager → task ledger → worker → 进度 → 重新规划 → 结果 | manager 从账本判断 | 持久化的 task ledger | 没有预定解法的开放任务 | 收敛慢；目标含糊会停滞；执行者会改动真实系统 |
互动 Lab 只画了 Sequential、Concurrent、Handoff、Magentic 四种，因为 Microsoft 自己把 Magentic 定义为 Group Chat 的扩展：都是「一个管理者加一份共享状态」，区别在于管理者会不会建计划、Agent 有没有改动外部系统的工具。Group Chat 在下面单独讲。
1. Sequential：顺序写死，Agent 不做选择
每个 Agent 只处理上一个 Agent 的输出，下一个是谁由工作流决定。别名 pipeline、prompt chaining、linear delegation，本质是把 Pipes and Filters 里的 filter 换成 Agent。
- 用在阶段依赖清楚、逐步打磨的工作，并且你了解每个 Agent 的可用性，能容忍某一段慢。
- 不要用在阶段可以并行、需要回头迭代、或者要按中间结果动态路由的场景。
- 最常见的故障是前序错误传播：A 选错模板，B 和 C 在错误模板上认真审阅润色，最终结果看起来很完整。解法是每一段交出结果前先校验（格式、跑题、置信度），不合格就重试或停下，并把错误暴露出来而不是藏起来。
- 每段结果写进 workflow state，某段超时就从那一段续做，不整条重跑。
2. Concurrent：并行分析，合并器必须画出来
分发器把同一任务同时交给几个 Agent，各自独立给出结果，Agent 之间不互传。别名 parallel、fan-out/fan-in、scatter-gather、map-reduce。
- 合并策略要在设计时定死：分类用投票，评分用加权合并，叙述用模型写摘要。没有 reducer 的扇出只是在并行制造互相矛盾的答案。
- 不要用在 Agent 需要建立在彼此工作之上、要求确定的执行顺序、模型配额撑不住并行、或者没有冲突裁决策略的场景。
- 两个典型故障：结果互相矛盾（两个说买入一个说卖出，没有策略就只能随便挑）和并行调用打满共享端点的配额（一个功能的高峰拖垮所有走同一端点的功能）。前者靠策略加分歧展示，后者靠限制并行度、排队、退避重试和端点隔离。
- 并行 Agent 只能各写各的中间结果，不能同时改同一份共享状态。
3. Group Chat：共享线程里讨论
多个 Agent 在一个累积的对话线程里发言，chat manager 决定谁下一个说。Agent 通常是只读的，不用会改动系统的工具，所以适合人参与旁听或直接当 manager。
- Maker-checker loop 是它的轮流版：maker 出稿，checker 按明确标准评判，不过就带反馈退回，直到通过或达到迭代上限。上限到了要有兜底：升级给人，或带质量警告输出最好的一版。
- Microsoft 建议把 Group Chat 限制在三个或更少的 Agent，并且 manager 必须有客观的完成判据，否则讨论停不下来。
4. Handoff：一次只有一个 Agent 在干活
当前 Agent 判断自己处理不了，就把整个任务转给更合适的专家。控制权整个转移，同一时刻只有一个 Agent 面对任务。别名 routing、triage、transfer、dispatch、delegation。
- 在 OpenAI Agents SDK 里，转交对模型来说就是一个名为
transfer_to_<agent>的工具；接手的 Agent 默认能看到之前的整段对话，除非用 input filter 裁掉一部分。转交只发生在同一次 run 内；输入护栏只作用于第一个 Agent，输出护栏只作用于产出最终结果的 Agent。 - 每次转交至少带上：task id、到目前为止的证据、下一个 Agent 允许用的工具、剩余预算、完成条件。这份「交接信封」是这个架构的 state owner，写错或丢了，下一位专家就从零开始。
- 不要用在从初始输入就能判断该找谁（用确定性路由）、任务要并行处理、或路由本来就是规则驱动的场景。
- 两个典型故障：两个专家把任务来回踢（解法：信封里放跳数上限和预算，每跳扣减，到上限升级给人工并附上信封）和分诊转错专家（解法：能从输入判断的用规则或只做分类的分发器；允许专家带原因转回一次，并用记录改进分诊）。
5. Magentic：管理者边做边规划，账本是唯一真相
管理者 Agent 把事实、猜测和计划写进 task ledger，每次派一个子任务给带工具的执行者，执行者把进度写回账本，管理者重读账本判断有没有停滞、要不要重新规划。别名 dynamic orchestration、task-ledger-based orchestration、adaptive planning。
- Magentic-One 的实现是两层循环：外层 task ledger（facts、guesses、plan），内层 progress ledger（当前进度、任务分配）；每一步后自省进展并检查是否完成，连续多步没有进展就更新 task ledger、重新规划。
- 执行者的工具会改动外部系统，所以计划可以在执行前或执行后交给人审。敏感操作设成必经的审批闸，低风险的读操作自动放行。
- 不要用在解法确定、不需要账本、任务简单、或对时间敏感的场景；它优化的是「把计划做对」，不是速度。
- 三个典型故障：停滞不收敛（账本里数停滞次数，超上限先重新规划一次，仍无进展就带账本升级给人）、执行者在审批前改动了生产系统（审批闸 + 沙箱 + 执行前展示计划）、计划只在管理者的对话里，重启就丢（账本持久化到外部存储，管理者每一步从账本读）。
故障与恢复
| 架构 | 故障 | 用户看到什么 | 恢复 |
|---|---|---|---|
| Sequential | 前序错误一路传播 | 完整但从第一段就偏了的结果 | 每段交出前校验；重试或停下；暴露错误 |
| Sequential | 中间一段超时 | 一直等不到结果 | 超时 + 重试；带已完成阶段降级返回；从失败段续做 |
| Concurrent | 三份结果互相矛盾 | 靠运气挑出来的答案 | 设计时定死合并策略；把分歧和置信度一起展示 |
| Concurrent | 并行调用打满配额 | 无关功能一起变慢 | 限并行度；排队；退避重试；端点隔离 |
| Handoff | 两个专家来回转交 | 一直等不到回复 | 信封里的跳数上限和预算；到上限升级给人 |
| Handoff | 分诊转错专家 | 被带着做了一段无关排查 | 能判断的走规则路由；允许带原因转回一次 |
| Magentic | 管理者停滞不收敛 | 一直等不到结果 | 数停滞；重新规划一次；带账本升级给人 |
| Magentic | 审批前改动了生产系统 | 一个没人看过的计划动了生产 | 敏感工具调用设审批闸；沙箱先跑；执行前展示计划 |
贯穿五种架构的几条原则：每个 Agent 的输出在传给下一个之前先校验；Agent 之间要有超时、重试、降级和熔断；每次交接决定下一个 Agent 需要全量上下文、压缩摘要还是只要一条新指令；长任务的共享状态持久化到外部；用户身份跨 Agent 传递，每个 Agent 都做权限裁剪；在用户输入、工具调用、工具返回和最终输出四处都放内容护栏。
怎么选
- 阶段有先后依赖、逐步打磨：Sequential，校验放在每次交接前。
- 同一输入要几个独立视角、等不起串行、而且已经定好裁决策略：Concurrent，先把 reducer 画出来。
- 要多轮审议或 maker-checker，人要旁听或参与：Group Chat，三个 Agent 以内，定好完成判据和迭代上限。
- 一开始不知道需要哪位专家、同一时刻只该一个 Agent 面对用户：Handoff，信封带证据和预算，设跳数上限和人工兜底。
- 没有预定解法、执行者要改动真实系统、值得先出一份人能审的计划：Magentic，账本是唯一真相，改动前过审批闸。
- 一个工作流的不同阶段特征不同时，可以组合：前段用 Sequential 做数据准备，中段用 Concurrent 做并行分析。
回到开头的客服系统：资料整理走 Sequential；三视角评估走 Concurrent，合并策略写成加权；聊几句才知道找谁的请求走 Handoff，信封里放跳数上限；故障处置走 Magentic，回滚这类操作过人工审批。
面试时这样回答
- 先复述约束：任务有没有先后依赖、视角是否独立、专家是否事先可知、有没有预定解法。
- 说控制路径：点名图上的边，例如「A 的输出交给 B」「同一任务扇出再由 reducer 扇入」「transfer_to_A 从信封出发」「进度写回账本再重读」。
- 说状态存在哪：workflow state、中间结果、交接信封，还是 task ledger。
- 说代价与一个故障：例如转交可能无限循环，信封里放跳数上限，到上限升级给人。