Reference Sources:Microsoft Azure AI Agent Patterns、Multi-Agent Orchestration Patterns
Applicable Scenarios
- Orchestration decisions for multi-workflow collaborative tasks
- Deciding whether tasks are serial or parallel
- Handling dynamically changing task plans
- Selecting coordination patterns between workflows
Four Basic Orchestration Patterns
1. Sequential Orchestration (Sequential / Pipeline)
A → B → C → D
Workflows execute serially in a predefined order Each workflow processes the output of the previous one
Applicable:
- Stages with clear linear dependencies
- Requirements → Design → Development → Testing → Deployment
- Content production pipeline
Not applicable:
- Scenarios where tasks can be parallelized
- Scenarios requiring rapid iteration
Advantages:
- Simple and clear
- Easy to track
- Easy failure localization
Disadvantages:
- Slow (cannot parallelize)
- Early errors propagate to later stages
### 2. 并发编排（Concurrent / Fan-out/Fan-in）
```text
┌→ B ┐
A → ───┼→ C ┼→ E
└→ D ┘
多个工作流同时处理同一输入或独立子任务
最后聚合结果
适用：
- 前端和后端并行开发
- 多个安全检查同时跑
- 多个独立模块的开发
- 时间紧迫的任务
不适用：
- 任务有严格先后依赖
- 资源不足以并行
优点：
- 速度快
- 充分利用并行能力
缺点：
- 需要冲突解决机制
- 资源消耗大
- 协调成本高
3. Handoff / Routing Orchestration
A → 决策 → B 或 C 或 D
一个工作流完成后动态决定下一个接手的工作流
适用：
- Bug 修复（按类型路由到前端/后端/数据库）
- 客服工单（按问题类型分流）
- 错误处理（按错误类型选择策略）
不适用：
- 路径完全可预测的场景
优点：
- 灵活适应不同情况
- 资源利用合理
缺点：
- 路径不可预测，难以估算
- 决策点容易出错
4. Dynamic Orchestration (Magentic / Adaptive)
A → 评估 → 重新规划 → 执行 → 评估 → ...
项目经理动态构建和调整任务计划
根据中间结果重新排序
适用：
- 开放性问题（线上故障排查、探索性原型）
- 不确定性高的项目
- 需要不断学习和调整的任务
不适用：
- 明确路径的标准项目
- 时间紧迫的硬性交付
优点：
- 最灵活
- 能处理未知情况
缺点：
- 难以预测进度
- 容易陷入无限循环
Pattern Selection Decision Tree
任务之间有严格先后依赖？
→ 是：顺序编排
→ 否：继续判断
多个任务可以独立并行？
→ 是：并发编排
→ 否：继续判断
下一步取决于当前步骤的结果？
→ 是：交接编排
→ 否：继续判断
问题开放、方案未知、需要边做边调整？
→ 是：动态编排
Hybrid Orchestration (Most Common in Real Projects)
典型混合模式：
产品经理 → API设计 + 数据库设计（顺序→并发）
↓
后端 + 前端（并发）
↓
联调 → QA + 安全（顺序→并发）
↓
DevOps → 文档（顺序）
即：阶段间顺序，阶段内并发
Concurrency Safety Rules
并发执行时必须确保：
1. 不会同时修改同一个文件（文件锁/分区）
2. 有明确的合并策略（谁的输出优先）
3. 有冲突检测机制（两个工作流产出矛盾时如何处理）
4. 共享状态有单一数据源（API 契约、数据库 schema）
可以安全并发的组合：
✓ 前端 + 后端（前提：API 契约已确定）
✓ QA 用例设计 + 开发（前提：PRD 已确定）
✓ 安全检查 + QA 测试（独立执行，不互相依赖）
✓ 多个独立模块的开发
不能并发的组合：
✗ API 设计 + 后端开发（后端依赖 API 契约）
✗ 数据库设计 + 后端开发（后端依赖表结构）
✗ 开发 + 部署（部署依赖开发完成）
Workflow
1. 读取 WBS 任务清单和关键路径
↓
2. 对每个阶段，应用决策树选择编排模式
↓
3. 标注每个阶段的编排模式
↓
4. 检查并发任务是否安全（用并发安全规则）
↓
5. 输出编排计划（含模式标注）
↓
6. 转交 handoff-protocol 定义交接细节
Output Format
## 编排计划
### 整体模式：混合编排（阶段间顺序，阶段内并发）
### 各阶段编排模式
| 阶段 | 任务 | 编排模式 | 备注 |
|------|------|---------|------|
| 需求 | T1 | 顺序 | 单工作流 |
| 设计 | T2, T3 | 并发 | 互不依赖 |
| 开发 | T4, T5 | 并发 | 前提：API 契约确定 |
| 联调 | T6 | 顺序 | 等待开发完成 |
| 验证 | T7, T8 | 并发 | QA 和安全互不依赖 |
| 上线 | T9, T10 | 顺序 | 部署 → 文档 |
### 并发安全检查
- T2/T3 并发：✅ 各自产物独立
- T4/T5 并发：⚠️ 必须等 T2 完成（API 契约）
- T7/T8 并发：✅ 各自测试独立
### 时间收益
串行总耗时：220min
混合编排耗时：160min
节省：60min（27%）
Quality Self-Check
□ 是否每个阶段都明确了编排模式
□ 并发任务是否真的可以安全并发
□ 是否检查了共享资源冲突
□ 时间收益是否合理（混合编排应该更快）
□ 失败处理路径是否考虑（动态编排尤其要注意）
Common Pitfalls
- Blind Concurrency——All tasks are run concurrently, resulting in resource conflicts
- Ignoring Hidden Dependencies——Frontend and backend run concurrently, but the API contract has not yet been defined
- Dynamic Orchestration Falling into Loops——Infinite planning without execution
- Too Many Handoff Orchestration Paths——If the decision tree depth is > 5 levels, it should be redesigned
- Hybrid Orchestration Without Clear Boundaries——It is unclear which stages are sequential and which are concurrent
Supporting Templates
templates/orchestration-plan-template.md— Orchestration Plan Templatetemplates/parallel-safety-check-template.md— Concurrency Safety Checklist
Collaboration with Other Skills
上游：
wbs-decomposition → 提供任务列表
critical-path → 提供依赖关系和并行机会
下游：
handoff-protocol → 定义工作流间交接细节
progress-tracking → 按编排模式追踪进度