编排模式选择

参考来源：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%）

质量自检

□ 是否每个阶段都明确了编排模式
□ 并发任务是否真的可以安全并发
□ 是否检查了共享资源冲突
□ 时间收益是否合理（混合编排应该更快）
□ 失败处理路径是否考虑（动态编排尤其要注意）

常见坑

1. 盲目并发——所有任务都并发，结果资源冲突
2. 忽略隐藏依赖——前后端并发但 API 契约还没定
3. 动态编排陷入循环——无限规划不执行
4. 交接编排路径过多——决策树深度 > 5 层就该重新设计
5. 混合编排没有清晰边界——哪些阶段顺序、哪些并发说不清

配套模板

• templates/orchestration-plan-template.md — 编排计划模板
• templates/parallel-safety-check-template.md — 并发安全检查清单

与其他 skill 的协作

上游：
  wbs-decomposition → 提供任务列表
  critical-path → 提供依赖关系和并行机会

下游：
  handoff-protocol → 定义工作流间交接细节
  progress-tracking → 按编排模式追踪进度