面经策

多 Agent 协作有哪些常见的编排模式？各自适合什么场景？ ​

  • 标签：AI、大模型、Agent

🏛 业务架构师 ​

多 Agent 协作的常见编排模式与适用场景：

1. 主从式（Orchestrator-Workers）：一个主 Agent 拆解任务、派发给多个子 Agent、聚合结果。适用：任务可清晰分解（多渠道调研、批量文档处理）。最可控，企业落地首选——权限、预算、审计都在主 Agent 收口。

2. 流水线式（Pipeline/Sequential）：Agent 按固定顺序接力（写作→审校→排版）。适用：流程成熟的场景，等于用 Agent 组成的自动化流水线；确定性高但灵活性低。

3. 辩论/评审式（Debate/Critic）：多个 Agent 互相质疑、评审产出（生成方案 vs 风险审查）。适用：质量敏感场景——方案评审、安全审计，成本高但能压幻觉率。

4. 网状协作（Peer-to-peer/自由通信）：Agent 间自由协商分工。适用：探索性任务、模拟社会（游戏 NPC、群体决策）。生产慎用——不可控，失败面大。

5. 分层组织式（Hierarchical）：多级 Agent 组织（主管→组长→组员），像企业架构。适用：大型复杂任务（代码库级开发、多部门流程）。

选型的业务逻辑：可控性优先选主从/流水线；质量优先加辩论评审；网状留给研究。我的实施经验：从"1 主 N 子"起步，子 Agent 互不通信，聚合逻辑显式写在主 Agent 里——出了问题责任链清晰。多 Agent 系统最大的成本不是 token，是调试——每个环节的 trace 和版本管理必须先行，否则上线即失明。

🏗 系统架构师 ​

多 Agent 编排模式我按拓扑结构归类，各自适用场景明确：

  • 编排者-执行者（Orchestrator-Worker）：中心 Agent 分解任务、分派、汇总结果。控制清晰、责任明确；中心是瓶颈。适合：任务可静态分解的并行场景（多源调研、批量文档处理）——MapReduce 式fan-out/fan-in；
  • 流水线（Pipeline/Sequential）：按阶段串行传递（需求→开发→测试→文档）。延迟可预估、每阶段可独立优化。适合：流程固定的生产链（CI/CD 自动化、内容生产）；
  • 层级式（Hierarchical）：多级管理——管理者 Agent 调度多个领域 Agent（各自再带子 Agent）。适合：大型任务、组织型分工（模拟团队：PM/开发/测试），OpenClaw/Manus 类系统的典型结构；
  • 辩论/评审式（Debate/Critic）：多 Agent 相互质疑与修正（生成者 vs 批评者、多方辩论投票）。适合：高正确性要求的推理判断（事实核查、方案评审）——用算力换准确率；
  • 黑板/共享状态式：Agent 通过共享任务板协作，按能力认领。适合：工作流型协作、任务动态到达（客服工单池）；
  • 对等市场式（A2A）：无中心，Agent 通过协议互相发现与委托。适合：跨组织、跨框架的开放生态。

选型维度：任务可分解性（静态→编排/流水线；动态→黑板）、正确性要求（高→辩论式）、组织边界（内→中心化；跨组织→A2A）。

我的经验：从编排者-执行者起步——控制流集中、易调试；上来就搞对等协作的团队，基本都死在可观测性上。中心化的性能瓶颈在 95% 的场景里不是真问题。

💻 全栈开发专家 ​

多 Agent 编排模式按协作拓扑分六种，各有适用场景：

  1. Orchestrator-Worker（中心编排）：一个 Planner 分解任务、分发 Worker、汇总结果。适合任务可并行拆解（多源调研、批量处理）。最常用的默认模式；要点：Worker 失败的重派和部分结果的容错汇总。

  2. 流水线（Sequential/Pipeline）：A 的输出是 B 的输入（写作→审校→排版）。适合流程固定、阶段分明的任务；要点：阶段间数据 schema 约定，防「传话失真」。

  3. 路由分发（Router）：入口按意图把请求分给领域 Agent（客服分流量/售后/技术）。适合领域边界清晰的业务；要点：路由准确率监控，兜底 Agent 必备。

  4. 辩论/评审（Debate/Critic）：生成者与评审者对抗（写代码+代码审查），多轮互搏提升质量。适合质量敏感、错误代价高的任务；要点：轮数限制（2~3 轮收敛），评审要有明确 rubric，否则变成礼貌互吹。

  5. 层级（Hierarchical）：管理者-中层-执行者多层委派。适合超大规模任务（模拟组织）；要点：深度限制（2 层内）、逐层目标对齐——层级越深目标漂移越严重。

  6. 黑板/共享状态：Agent 围绕共享工作区异步读写（一个写代码、一个跑测试、一个修 bug）。适合事件驱动的持续协作；要点：并发控制（锁/CRDT）、变更通知机制。

选型心法：能单 Agent 别多 Agent（协调成本真实存在）；先 Orchestrator-Worker 覆盖 80% 场景；质量要求高加 Critic；只有任务量级真的大才上层级。模式不是越花越好，是越可调试越好。