在多 agent 系统中，协调者坐在中心。每条信息、每次委派、每个结果都经过它。子代理之间永远不直接对话。这不是官僚主义——这是让错误处理、冲突解决和质量控制成为可能的架构。
模式
协调者承担五个职责：
- 任务分解 — 分析请求，拆成子任务
- 委派 — 把子任务分配给合适的专家 agent
- 结果聚合 — 收集所有 agent 的输出
- 冲突解决 — 当 agent 之间意见不一致时进行调和
- 综合 — 产出统一的最终输出
子代理只和协调者通信。代码分析 agent 不会直接调用测试生成 agent。账单 agent 不会直接重试物流 agent。所有 agent 间通信都路由经过协调者。
为什么不用网状架构？
网状架构（agent 直接调用 agent）消除了协调者这个”瓶颈”，但引入了分布式复杂性。当 NLP agent 在网状流水线中途失败时，谁来重试？谁跟踪整体进度？谁保证输出一致性？在 hub-and-spoke 中，答案永远是协调者。在网状架构中，这些职责散落在本来不是为此设计的各个 agent 身上。
“做什么”vs”怎么做”的边界
协调者定义每个 agent 应该达成什么（目标、范围、质量标准）。Agent 决定怎么达成（具体技术、分析深度）。安全 agent 最清楚该检查哪些漏洞模式——协调者确保它用结构化格式报告发现。这给了协调者可见性（结构化报告），同时保留了 agent 的自主权（领域专长）。
智能委派
一个对每个请求都委派所有 agent 的协调者是固定流水线，不是智能编排者。数据显示 70% 的客服工单只需要一个专家 agent。每张工单都委派三个 agent 意味着 70% 的委派是浪费。
协调者应该分析每个请求，只委派需要的 agent。简单的订单状态查询 → 只用物流 agent。退款 + 地址变更 → 账单 + 账户 agent。这就是智能协调者和广播式分发器的区别。
部分失败处理
当一个 agent 失败时（超时、错误），协调者保留成功的结果，独立处理失败。账单 agent 的结果不会因为物流 agent 超时而被丢弃。协调者呈现可用的结果，承认失败，并采取恢复动作（重试、升级或带注释地跳过）。
协调者作为瓶颈
协调者可能成为瓶颈——在某个系统中，它占了总查询时间的 80%。解决办法不是去掉它（那会重新引入它解决的所有问题）。解决办法是优化它：让协调者各阶段流水线化，在 agent 还在运行时就开始聚合，用流式处理来处理早期结果，让协调者的工作和 agent 执行重叠。
一句话总结： 所有 agent 间通信都经过协调者——它分解任务、智能委派（只委派需要的 agent）、解决冲突、处理部分失败、综合结果。优化协调者，不要去掉它。