用途：让多个专业子智能体协作制定计划，而非各自独立规划。它们能看到彼此的工作，并通过结构化讨论轮次改进方案。
主要能力：编排者负责协调轮次、派发子智能体、管理等待、综合结果，自身不撰写计划。流程为草稿→评审→改进→共识判定→主计划。所有子智能体并行起草，随后并行交叉评审，再依据评审改进；每轮改进后检查共识，未达成且轮次未达上限则重复评审与改进，最多 5 轮，最后生成 master-plan.md。
使用方式：先给出待规划主题与所需专家（如架构、安全、前端、后端、DevOps），编排者创建 .plans/session-[id]/ 目录，内含 context.md、status.yaml，以及 draft-[spec].md、review-[spec].md、refined-[spec]-r[N].md、master-plan.md。子智能体通过文件轮询等待依赖，例如： while [ $(ls draft-*.md 2>/dev/null | wc -l) -lt 3 ]; do sleep 5 done 检查之间必须 sleep，禁止忙等。status.yaml 记录阶段、当前轮次、最大轮次与各专家状态。
共识判定：无负面信号且每位专家至少 2 个正面信号为完全共识；负面信号不超过 2 个且趋于一致为部分共识，触发下一轮；否则在轮次未达上限时继续，达到上限则记录分歧并进入主计划。
主计划要求：每个阶段须含类型（顺序/并行）、具体可执行需求、输入输出文件、验证标准、依赖、门禁命令（类型检查、构建）；并行阶段需有阶段级验证。阶段须能放入单个智能体上下文（约 15 个文件、约 500 行代码以内），过大须拆分子阶段。主计划须自包含，可直接作为 subagent-orchestration 的输入。
适用场景：需要多领域视角、交叉评审与共识的综合规划任务，如架构、安全、前后端、DevOps 协同方案。
限制：专家数量建议简单 2-3 个、标准 3-5 个、复杂 5-7 个；最多 5 轮；未提供具体收费、平台与效果数据。