用途：在多智能体协作中，根据任务特征选择合适的多智能体编排模式。资料强调优先选最简单能解决问题的模式，只有当系统证明不足时才增加复杂度。
主要能力：提供快速决策框架，按问题逐步判断：每个智能体的任务是否独立（是→fan-out）；每步是否需要上一步输出（线性→pipeline，非线性→dag）；是否需要常驻且能自适应调整的协调者（单层→hub-spoke，多层→hierarchical）；是否为决策类任务（对抗→debate，协作投票→consensus）；专家是否在处理中动态出现（是→handoff）；是否所有智能体需自由协作（是→mesh）；成本是否首要（是→cascade）。同时给出 10 种模式的拓扑、智能体数量与适用范围对照表，并为每种模式附示例配置，如 fan-out 用于并行审查、pipeline 用于设计到测试的顺序阶段、hub-spoke 用于动态协调、consensus 用于架构决策、mesh 用于头脑风暴与协作调试、handoff 用于分流与专家路由、cascade 用于按置信度逐级升级以控成本、dag 用于带依赖的复杂项目、debate 用于严谨评估、hierarchical 用于大型团队与领域划分。
使用方式：按决策框架确定模式后，用对应的编排 API 定义智能体与任务，部分示例使用 cli: "claude" 等参数；也可用 YAML 定义任意模式以便移植，并通过 reflectionThreshold 开启反思（周期性综合以支持纠偏），如 reflectionThreshold: 10。DAG 模式支持保存与恢复状态，重启时用 --resume 跳过已完成节点。
适用场景：需要在多个智能体间协调任务，如代码审查、研究、测试、流水线开发、架构决策、故障排查、客户支持分流和生产负载成本优化。
限制与注意：资料列出常见错误，如对所有任务都用 mesh 会造成 O(n^2) 通信与调试困难；对独立工作用 pipeline 会造成串行瓶颈；对简单并行任务用 hub-spoke 增加不必要开销；对非决策任务用 consensus 浪费时间；handoff 未设 maxHandoffs 会导致无限路由循环；cascade 需处理置信度解析；少量智能体用 hierarchical 会增加管理开销；此外反思、YAML、状态恢复等能力的具体实现与是否收费、价格、平台支持范围等，资料未提供。