| name | orchestration |
| description | 选择多工作流编排模式时使用。适用于跨工作流协同任务、决定任务串行/并行/动态规划。优先使用 Microsoft Azure 的四种 Agent 编排模式（顺序/并发/交接/动态）。 |
编排模式选择
参考来源：Microsoft Azure AI Agent Patterns、Multi-Agent Orchestration Patterns
适用场景
- 多工作流协同任务的编排决策
- 决定任务串行还是并行
- 处理动态变化的任务计划
- 工作流之间的协调模式选择
四种基本编排模式
1. 顺序编排（Sequential / Pipeline）
A → B → C → D
工作流按预定义顺序串行执行
每个工作流处理上一个的输出
适用：
- 有明确线性依赖的阶段
- 需求 → 设计 → 开发 → 测试 → 部署
- 内容生产流水线
不适用：
- 任务可并行的场景
- 需要快速迭代的场景
优点：
- 简单清晰
- 易于追踪
- 失败定位容易
缺点：
- 慢（无法并行）
- 早期错误传播到后期
2. 并发编排（Concurrent / Fan-out/Fan-in）
┌→ B ┐
A → ───┼→ C ┼→ E
└→ D ┘
多个工作流同时处理同一输入或独立子任务
最后聚合结果
适用：
- 前端和后端并行开发
- 多个安全检查同时跑
- 多个独立模块的开发
- 时间紧迫的任务
不适用：
- 任务有严格先后依赖
- 资源不足以并行
优点：
- 速度快
- 充分利用并行能力
缺点：
- 需要冲突解决机制
- 资源消耗大
- 协调成本高
3. 交接编排（Handoff / Routing）
A → 决策 → B 或 C 或 D
一个工作流完成后动态决定下一个接手的工作流
适用：
- Bug 修复（按类型路由到前端/后端/数据库）
- 客服工单（按问题类型分流）
- 错误处理（按错误类型选择策略）
不适用：
- 路径完全可预测的场景
优点：
- 灵活适应不同情况
- 资源利用合理
缺点：
- 路径不可预测，难以估算
- 决策点容易出错
4. 动态编排（Magentic / Adaptive）
A → 评估 → 重新规划 → 执行 → 评估 → ...
项目经理动态构建和调整任务计划
根据中间结果重新排序
适用：
- 开放性问题（线上故障排查、探索性原型）
- 不确定性高的项目
- 需要不断学习和调整的任务
不适用：
- 明确路径的标准项目
- 时间紧迫的硬性交付
优点：
- 最灵活
- 能处理未知情况
缺点：
- 难以预测进度
- 容易陷入无限循环
模式选择决策树
任务之间有严格先后依赖？
→ 是：顺序编排
→ 否：继续判断
多个任务可以独立并行？
→ 是：并发编排
→ 否：继续判断
下一步取决于当前步骤的结果？
→ 是：交接编排
→ 否：继续判断
问题开放、方案未知、需要边做边调整？
→ 是：动态编排
混合编排（实际项目最常见）
典型混合模式：
产品经理 → API设计 + 数据库设计（顺序→并发）
↓
后端 + 前端（并发）
↓
联调 → QA + 安全（顺序→并发）
↓
DevOps → 文档（顺序）
即：阶段间顺序，阶段内并发
并发安全规则
并发执行时必须确保：
1. 不会同时修改同一个文件（文件锁/分区）
2. 有明确的合并策略（谁的输出优先）
3. 有冲突检测机制（两个工作流产出矛盾时如何处理）
4. 共享状态有单一数据源（API 契约、数据库 schema）
可以安全并发的组合：
✓ 前端 + 后端（前提：API 契约已确定）
✓ QA 用例设计 + 开发（前提：PRD 已确定）
✓ 安全检查 + QA 测试（独立执行，不互相依赖）
✓ 多个独立模块的开发
不能并发的组合：
✗ API 设计 + 后端开发（后端依赖 API 契约）
✗ 数据库设计 + 后端开发（后端依赖表结构）
✗ 开发 + 部署（部署依赖开发完成）
工作流程
1. 读取 WBS 任务清单和关键路径
↓
2. 对每个阶段，应用决策树选择编排模式
↓
3. 标注每个阶段的编排模式
↓
4. 检查并发任务是否安全（用并发安全规则）
↓
5. 输出编排计划（含模式标注）
↓
6. 转交 handoff-protocol 定义交接细节
输出格式
## 编排计划
### 整体模式：混合编排（阶段间顺序，阶段内并发）
### 各阶段编排模式
| 阶段 | 任务 | 编排模式 | 备注 |
|------|------|---------|------|
| 需求 | T1 | 顺序 | 单工作流 |
| 设计 | T2, T3 | 并发 | 互不依赖 |
| 开发 | T4, T5 | 并发 | 前提：API 契约确定 |
| 联调 | T6 | 顺序 | 等待开发完成 |
| 验证 | T7, T8 | 并发 | QA 和安全互不依赖 |
| 上线 | T9, T10 | 顺序 | 部署 → 文档 |
### 并发安全检查
- T2/T3 并发：✅ 各自产物独立
- T4/T5 并发：⚠️ 必须等 T2 完成（API 契约）
- T7/T8 并发：✅ 各自测试独立
### 时间收益
串行总耗时：220min
混合编排耗时：160min
节省：60min（27%）
质量自检
□ 是否每个阶段都明确了编排模式
□ 并发任务是否真的可以安全并发
□ 是否检查了共享资源冲突
□ 时间收益是否合理（混合编排应该更快）
□ 失败处理路径是否考虑（动态编排尤其要注意）
常见坑
- 盲目并发——所有任务都并发，结果资源冲突
- 忽略隐藏依赖——前后端并发但 API 契约还没定
- 动态编排陷入循环——无限规划不执行
- 交接编排路径过多——决策树深度 > 5 层就该重新设计
- 混合编排没有清晰边界——哪些阶段顺序、哪些并发说不清
配套模板
templates/orchestration-plan-template.md — 编排计划模板templates/parallel-safety-check-template.md — 并发安全检查清单
与其他 skill 的协作
上游：
wbs-decomposition → 提供任务列表
critical-path → 提供依赖关系和并行机会
下游：
handoff-protocol → 定义工作流间交接细节
progress-tracking → 按编排模式追踪进度
