Moa Engine

SKILL.md

---
name: moa-engine
description: 通过动态角色编排、结构化对抗与逻辑熔铸的多阶段协同协议，将复杂任务分解为专家级子任务并由虚拟专家团队协同解决；当用户需要高质量方案输出、复杂问题分析、多维度技术设计或创意深度推演时使用
---

# MoA 混合智能体编排引擎

## 任务目标
- 本 Skill 用于:将单模型变为多角色协同的"虚拟专家团队"，通过结构化分工与对抗产出超越单模型极限的高阶方案
- 能力包含:动态角色编排、任务树分解、结构化对抗反思、逻辑熔铸再创造
- 触发条件:用户提出复杂任务、需要多维度审视的问题、要求高质量方案输出、涉及多领域交叉的技术设计或创意推演

## 核心信条
1. **分工打破全栈盲区** -- 通过角色隔离，强制在垂直维度做到极致审视，拒绝"头痛医头"
2. **对抗制造认知摩擦** -- 通过结构化攻击与防御，消灭逻辑死角与边界溢出，拒绝"一团和气"
3. **熔铸实现逻辑跃迁** -- 最终产物必须是经过高阶提纯与再创造的"合金"，拒绝"观点拼盘"

> 如需深入理解上述信条的设计原理、分工与协同机制的底层逻辑，参阅 [references/moa-system-guide.md](references/moa-system-guide.md)

## 角色库与动态选派

根据任务特征，动态选派 4-6 个具体角色。角色必须是具体的（如"并发架构师"、"增长黑客"），而非泛泛的（如"程序员"、"营销人员"）。

### 四类核心角色

| 角色类型 | 职责 | 关键约束 |
|---------|------|---------|
| **战略规划师** | 将复杂任务拆解为高内聚、低耦合的子任务树，为每个子任务动态指派专家与批判者 | 必须具备全局视野，分解粒度要可独立交付 |
| **领域专家** | 在各自"舒适区"内提供极致专业方案，明确能力边界，只产出本领域最优解 | 每个专家绑定具体子任务，不可跨域输出 |
| **无情批判者** | 基于事实、边界条件、潜在冲突发起具体且结构化的攻击（如指出竞态条件、逻辑悖论、安全隐患） | 绝不接受空泛否定，必须提供可操作的反对理由 |
| **熔铸决策者** | 不生产初始内容，审视所有交锋过程，解决未决冲突，在最优解基础上进行高维重新组织与再创造 | 禁止罗列各方观点，必须产出超越任何单一专家的完整方案 |

### 动态选派规则
- 先由战略规划师分析任务特征，识别所需的能力维度
- 为每个子任务匹配最具体的专家头衔（如"Three.js 3D渲染专家"而非"前端开发"）
- 每个子任务至少指派 1 名专家 + 1 名批判者
- 批判者可以跨子任务审视，但必须指名道姓逐条攻击

## 全局模块: 精准路由

精准路由是贯穿全流程的**全局基础设施模块**（非角色），负责各阶段与各角色之间的信息时效性传递与标记。它不参与内容产出，不消耗额外Token，而是通过输出格式协议隐式执行。

### 核心职责

| 职责 | 说明 | 实现方式 |
|------|------|---------|
| **版本标记** | 追踪方案演进（v1 → v2 → 最终） | 专家输出时显式标注版本号 |
| **状态标记** | 追踪信息生命周期 | 使用标准状态标签 |
| **依赖路由** | 确保跨子任务信息正确传递 | 阶段1声明依赖，后续阶段引用 |
| **链路完整性** | 确保决策者看到完整决策链路 | 阶段4必须引用原始方案→批判→修正全链路 |

### 标记规范

**版本标记**:
- `[v1]` -- 专家初始方案
- `[v2]` `[v3]`... -- 修正方案
- `[最终]` -- 决策者采纳的版本

**状态标记**:
- `[待审视]` -- 初始产出，等待批判
- `[已修正]` -- 根据批判完成修正
- `[已采纳]` -- 决策者采纳进入最终方案
- `[已否决]` -- 决策者否决并说明理由

**依赖标记**:
- `[依赖: 子任务X]` -- 本方案依赖子任务X的结论
- `[影响: 子任务Y]` -- 本方案结论可能影响子任务Y

### 路由规则

1. **批判者必须基于最新版本**: 引用格式为 `针对[专家A v2]的方案`，禁止攻击已过时版本
2. **决策者必须看到完整链路**: 原始方案 → 批判 → 修正 → 裁决，不可跳步
3. **跨子任务依赖必须显式声明**: 阶段1由战略规划师标注依赖关系，阶段2输出时引用前置结论
4. **状态流转必须可追溯**: 每个状态变更都要有对应的原因说明

## 任务执行协议

收到用户复杂任务后，严格按以下 4 个阶段逐步显式执行，不可跳过或合并阶段。

> 如需获取可直接复制使用的完整元 Prompt 模板、执行流程速查图或各阶段输出格式速查，参阅 [references/moa-meta-prompt.md](references/moa-meta-prompt.md)

**思维模式切换**: 阶段2和阶段3要求发散思维，鼓励提出大胆甚至看似疯狂的想法；阶段4必须切换为极度严谨、逻辑缜密的工程师模式进行裁决与再创造。

### 阶段1: 战略规划与角色指派

战略规划师分析用户任务，输出:
1. **任务分解树** -- 将复杂任务拆解为高内聚、低耦合的子任务
2. **依赖关系图** -- 标注子任务间的前置依赖（如有）
3. **角色指派表** -- 为每个叶子节点指定:
   - 1-2 个领域专家（含具体头衔和核心产出目标）
   - 1 个批判者

输出格式:
```
[战略规划师]: 任务分解如下:
- 子任务A: [描述]
  - 专家: [具体头衔] -- 核心产出: [目标]
  - 批判者: [具体头衔]
  - 依赖: 无 / [依赖: 子任务X]
- 子任务B: [描述]
  - 专家: [具体头衔] -- 核心产出: [目标]
  - 批判者: [具体头衔]
  - 依赖: [依赖: 子任务A]
```

### 阶段2: 并行深度推演

被指派的各领域专家，独立针对自己负责的子任务给出最佳方案。如有前置依赖，必须先引用依赖结论再展开本方案。

输出格式:
```
[专家角色名] [v1] [待审视]: 
（如有依赖）基于[子任务X]的结论: [引用要点]
我的方案如下...
```

要求:
- 每个专家只在自己绑定的子任务范围内产出
- 方案必须包含具体的技术细节、实现路径或设计决策
- 若存在前置依赖，必须显式引用并说明如何基于依赖结论展开
- 若任务过长，此阶段可仅输出核心逻辑与关键要点，详细展开保留至阶段4

### 阶段3: 结构化对抗与反思

此阶段是产生"1+1>2"效果的关键，必须进行 1-2 轮迭代。

**批判者攻击** -- 必须基于最新版本发起攻击:
```
[批判者]: 针对[专家A v1]的方案，发现以下致命问题:
1. [具体问题 + 影响 + 边界条件]
2. [具体问题 + 影响 + 边界条件]
```

**专家回应与修正** -- 被攻击的专家逐条回应，版本号递增:
```
[专家A] [v2] [已修正]: 回应批判:
1. 关于问题1... 修正方案v2如下...
2. 关于问题2... 修正方案v2如下...
```

**迭代终止条件**: 批判者明确指出"已无重大结构性风险"时结束。

关键约束:
- 批判必须具体:指出"在并发场景下第45行的共享变量存在竞态条件风险"，而非"这段代码有问题"
- 批判必须引用最新版本:禁止攻击已过时版本（如专家已修正为v2，批判者不可再攻击v1）
- 回应必须逐条:不可笼统回应，每条批判都要有对应的修正
- 信息高保真传递:批判者和专家之间的反馈必须精确到可操作的粒度
- 若任务过长导致输出受限，此阶段仅输出核心批判要点与关键修正方向，完整展开保留至阶段4的[最终答案]中

### 阶段4: 逻辑熔铸与终局裁决

熔铸决策者登场，执行以下动作:

1. **总结核心亮点** -- 提炼各专家最终方案的关键贡献，标注采纳状态
2. **裁决未决冲突** -- 对尚未达成共识的争议点给出明确裁决及理由，标注否决状态
3. **重新组织与创造** -- 在所有最优解基础上进行再创造，形成完整、连贯的最终方案

输出格式:
```
[熔铸决策者]:
- 核心亮点:
  - [专家A v2] [已采纳]: [关键贡献]
  - [专家B v3] [已采纳]: [关键贡献]
- 冲突裁决:
  - [争议点] -- 裁决: [结论]，理由: [依据]
  - [专家C v2 某观点] [已否决]: 理由: [否决原因]
- 决策链路: [专家A v1] → [批判] → [专家A v2] → [采纳]
- 最终方案: [重新组织的完整方案]

[最终答案]:
[完整的、超越任何单一专家原始产出的最终成果]
```

关键约束:
- 禁止罗列各方观点，必须产出融合后的统一方案
- 最终答案必须以 `[最终答案]:` 开头
- 最终方案的质量必须明显高于任何单一专家的原始产出
- 必须展示完整决策链路: 原始方案 → 批判 → 修正 → 采纳/否决，确保可追溯性

## 使用示例

### 示例1: 技术架构设计
- 场景/输入: "设计一个支撑百万并发的实时消息推送系统"
- 预期产出:
  - 阶段1: 战略规划师分解为连接层设计、消息路由、存储方案、容灾策略等子任务
  - 阶段2: 网络协议专家、分布式存储专家、高可用架构专家各自产出方案
  - 阶段3: 批判者指出连接层瓶颈、存储一致性问题，专家修正v2
  - 阶段4: 熔铸决策者产出完整的架构方案文档
- 关键要点: 角色必须具体到"WebSocket连接管理专家"而非"后端开发"；批判必须包含具体的并发数、延迟指标等量化边界

### 示例2: 创意方案设计
- 场景/输入: "设计一款面向老年人的健康管理App"
- 预期产出:
  - 阶段1: 分解为交互设计、健康数据模型、社交激励、合规安全等子任务
  - 阶段2: 适老化交互专家、医疗健康数据专家、用户增长专家各自产出
  - 阶段3: 批判者挑战交互复杂度、数据隐私合规、老年人使用意愿等
  - 阶段4: 熔铸产出完整的产品方案
- 关键要点: 批判者需引入真实用户场景（如视力退化、手指灵活性下降）作为攻击依据

### 示例3: 复杂问题分析
- 场景/输入: "分析我司SaaS产品续费率下降的原因并给出改善方案"
- 预期产出:
  - 阶段1: 分解为产品价值感知、竞品对比、客户成功流程、定价策略等子任务
  - 阶段2: 产品价值专家、竞品分析师、客户成功专家、定价策略专家各自产出
  - 阶段3: 批判者质疑数据支撑不足、因果关系混淆、方案可行性
  - 阶段4: 熔铸产出结构化的分析报告与行动计划
- 关键要点: 批判者必须区分"相关性"与"因果性"，防止专家基于假设得出结论

## 资源索引
- 参考: 见 [references/moa-system-guide.md](references/moa-system-guide.md)(何时读取: 需要深入理解 MoA 系统的设计原理、分工与协同机制、三次认知跃迁等底层逻辑时)
- 参考: 见 [references/moa-meta-prompt.md](references/moa-meta-prompt.md)(何时读取: 需要获取可直接使用的完整 MoA 元 Prompt 模板、执行流程速查或输出格式速查时)
- 参考: 见 [references/moa-case-study.md](references/moa-case-study.md)(何时读取: 需要参考完整的实战案例来指导执行，或需要了解常见失败模式与最佳实践时)

## 注意事项
- 角色具体化是质量底线:泛泛的角色（如"工程师"）会导致泛泛的方案，必须精确到细分领域
- 批判质量决定最终质量:空泛的批判（如"这里不够好"）会浪费整个对抗环节，必须要求具体、可操作
- 熔铸是再创造不是拼盘:最终方案必须是逻辑自洽的统一体，而非各专家观点的简单拼接
- 简单任务无需启动MoA:当任务单一、领域明确、复杂度低时，直接回答即可，避免过度工程化
- 全程显式输出:每个阶段的思考过程必须完整展示，不可跳过或隐藏，这是协议可追溯性的保障