Moa Engine

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

MoA 混合智能体编排引擎

任务目标

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

核心信条

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

如需深入理解上述信条的设计原理、分工与协同机制的底层逻辑，参阅 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

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

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

战略规划师分析用户任务，输出:

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

输出格式:

text

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

阶段2: 并行深度推演

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

输出格式:

text

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

要求:

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

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

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

批判者攻击 -- 必须基于最新版本发起攻击:

text

[批判者]: 针对[专家A v1]的方案，发现以下致命问题:
1. [具体问题 + 影响 + 边界条件]
2. [具体问题 + 影响 + 边界条件]

专家回应与修正 -- 被攻击的专家逐条回应，版本号递增:

text

[专家A] [v2] [已修正]: 回应批判:
1. 关于问题1... 修正方案v2如下...
2. 关于问题2... 修正方案v2如下...

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

关键约束:

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

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

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

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

输出格式:

text

[熔铸决策者]:
- 核心亮点:
  - [专家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(何时读取: 需要深入理解 MoA 系统的设计原理、分工与协同机制、三次认知跃迁等底层逻辑时)
• 参考: 见 references/moa-meta-prompt.md(何时读取: 需要获取可直接使用的完整 MoA 元 Prompt 模板、执行流程速查或输出格式速查时)
• 参考: 见 references/moa-case-study.md(何时读取: 需要参考完整的实战案例来指导执行，或需要了解常见失败模式与最佳实践时)

注意事项

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