MoA 混合智能体编排引擎 v2.1

将单模型变为多角色协同的"虚拟专家团队"，通过结构化分工与对抗产出超越单模型极限的高阶方案。

设计原理见 moa-system-guide.md 标签体系见 moa-tag-system.md 智能路由见 moa-routing-design.md 可用元 Prompt 模板见 moa-meta-prompt.md

When to Use

触发条件（满足任一即启动 MoA）：

• 任务涉及多个专业领域交叉，单一视角无法覆盖
• 高风险决策需要结构化对抗来抵御认知偏误和确认偏误
• 技术架构、产品设计或方案需要多角度充分审视
• 开放性问题存在显著不确定性，需要多路径推演权衡
• 用户明确要求多角度分析、专家团队讨论、深度审查或方案对比

触发关键词：多角度分析、专家团队、方案对比、深度审查、架构评审、多维推演、对抗论证

不触发场景：简单事实查询、单一领域常规任务、有明确单一答案的问题、闲聊对话

核心信条

1. 分工打破全栈盲区 -- 角色隔离，垂直极致审视
2. 对抗制造认知摩擦 -- 结构化攻击与防御，消灭逻辑死角
3. 熔铸实现逻辑跃迁 -- 最终产物是提纯再创造的"合金"
4. 协议优于参数 -- 智慧存在于连接与交互之中

任务类型与决策协议

任务类型	特征	决策协议	对抗轮次
知识密集型	事实判断、合规审查	共识优先 + 总管复核	1轮事实核查
推理决策型	方案选择、架构设计	辩论 + 加权投票	2轮+深度对抗
工具执行型	代码生成、自动化	总管调度执行	1轮质量批判

高风险标记：涉及隐私/金融/医疗/安全/合规时启用审计日志。

完整协议选择规则见 moa-system-guide.md 进阶设计一

四种核心角色

角色	职责
战略规划师	拆解任务树、判断任务类型、选择决策协议、动态指派专家与批判者
领域专家	在各自子任务内提供极致专业方案，明确能力边界，携带 domain 标签
无情批判者	基于事实、边界条件发起结构化攻击，可主动请求更多信息
熔铸决策者	审视全链路交锋，在最优解基础上高维重新组织与再创造

角色详细定义见 moa-system-guide.md 分工机制

标准执行流程

阶段0: 任务类型判断 → 选择决策协议 + 风险标记
阶段1: 战略规划     → 任务分解树 + 角色指派 + 循环依赖检测
阶段2: 并行深度推演 → 各专家产出方案 [v1] + 跨域感知 → 动态追加批判者
阶段3: 结构化对抗   → 批判者攻击 → 专家修正[v2]或反驳 → 直至无重大风险
阶段4: 逻辑熔铸     → 融合冲突 → 裁决（含反驳裁决）→ 最终方案

[IMMUTABLE] 不可变标记

核心不可变（标签级，RHI Patch 解释器拒绝触碰）：

• I1: <phase id="3"> 对抗阶段不可移除、跳过或重排序
• I2: <critic> 角色标签不可移除或降权
• I3: <attack> 批判标签不可移除，severity 值域不可收窄为空
• I4: <termination_signal> 必须显式产出，不可自动生成
• I5: <final_answer> "必须再创造"约束不可弱化为"可罗列"
• I6: <response> + <revision> 专家必须回应批判，不可省略

保护摩擦区（可微调不可质变）：P1 version 不可自动递增、P2 severity 值域可扩展不可收窄、P3 对抗轮次下限不可降低。

完整清单见 moa-tag-system.md [IMMUTABLE] 部分

使用示例

示例1: 技术架构评审

• 场景/输入: "评审我们的微服务架构是否存在单点故障风险"
• 预期执行:
  • Phase 0: 判断为推理决策型 → 辩论+加权投票协议，2轮深度对抗
  • Phase 1: 拆解为服务拆分合理性、数据一致性、故障隔离、监控告警等子任务
  • Phase 2: 分布式系统专家、数据一致性专家、SRE专家各自产出方案
  • Phase 3: 批判者攻击数据一致性方案的分区容忍性问题，专家修正v2
  • Phase 4: 熔铸决策者产出完整的架构评审报告
• 关键要点: 任务类型为推理决策型，需2轮对抗；涉及高风险，启用审计日志

示例2: 产品设计决策

• 场景/输入: "我们的SaaS产品是否应该引入AI助手功能"
• 预期执行:
  • Phase 0: 判断为推理决策型 → 辩论+加权投票协议
  • Phase 1: 拆解为用户价值分析、技术可行性、成本收益、竞品对比、风险评估
  • Phase 2: 产品策略专家、AI技术专家、财务分析师、竞品分析师各自产出
  • Phase 3: 批判者质疑ROI计算的乐观假设，财务分析师修正v2
  • Phase 4: 熔铸产出结构化的决策建议书
• 关键要点: 多领域交叉，需动态批判者指派覆盖合规领域

示例3: 代码安全审查

• 场景/输入: "审查这个支付模块的代码是否存在安全漏洞"
• 预期执行:
  • Phase 0: 判断为知识密集型+高风险 → 共识优先+总管复核，1轮事实核查
  • Phase 1: 拆解为输入验证、认证授权、数据加密、日志审计、依赖安全
  • Phase 2: 安全专家、密码学专家、合规专家各自产出
  • Phase 3: 批判者发现SQL注入风险，专家修正v2
  • Phase 4: 熔铸产出安全审查报告与修复建议
• 关键要点: 高风险任务，启用审计日志；知识密集型，1轮事实核查即可

参考文档导航

文件	何时读取
PROJECT_OVERVIEW.md	需要理解全局架构、MoA/RHI 价值定位、设计决策时
moa-meta-prompt.md	需要复制完整元 Prompt 模板、协议选择决策树时
moa-system-guide.md	需要理解设计原理、分工协同机制、三次认知跃迁时
moa-tag-system.md	需要完整标签定义、属性值域、可见性矩阵时
moa-routing-design.md	需要路由规则、动态批判者逻辑、执行状态管理时
moa-case-study.md	需要实战案例参考、失败模式、最佳实践时
moa-rhi-guide.md	需要了解 RHI 进化机制、Patch 规范时
moa-phase-transition.md	需要了解过渡闸门条件、评估框架时