---
name: mas-architecture-selection
version: 2.0
framework: 智能体管理学 · 模块三 · 框架F19
type: 决策型
description: >
  多智能体架构阶梯选型（MAS Architecture Ladder）。当需要选择Agent架构层级、
  评估是否需要多Agent、或设计多Agent协作方案时触发。关键词：MAS、多智能体、
  架构选型、L1-L5、监督者编排、Swarm、成本增幅、架构决策树。
governance_nerves: [意图管理, 边界与升级, 智能体主权]
upstream_frameworks: [F15-上下文设计, F17-VERITAS评估, F18-CATER治理]
downstream_frameworks: [F20-工程方法, F23-企业架构]
chains: "独立专家"
---

# F19 多智能体架构阶梯选型（MAS Architecture Ladder）

## SKILL定位

**核心命题**：架构层级越高不等于越成熟，越复杂不等于越好。L3（监督者编排型）是当前生产环境的最佳实践中心点。选择L4（Swarm）之前，必须能回答「L3无法满足的具体需求是什么」。

**颠覆对象**：「多Agent一定比单Agent好」的假设。多Agent引入了通信开销、协调成本、调试难度和一致性风险。从L2到L4，成本增幅可达8-15倍，但能力提升可能只有20-30%。

**五层架构阶梯**：

| 层级 | 名称 | 描述 | 适用场景 | 相对成本 |
|------|------|------|----------|----------|
| L1 | 单Agent | 一个Agent处理所有任务 | 简单、单一职责场景 | 1x |
| L2 | 链式管道 | 多个Agent按固定顺序串行处理 | 流程明确、步骤固定的场景 | 2-3x |
| L3 | 监督者编排 | 一个监督者Agent动态调度多个专业Agent | 复杂、多技能、需动态路由的场景 | 3-5x |
| L4 | Swarm群体 | 多个Agent自主协作、无中央监督 | 探索性、需涌现行为的场景 | 8-15x |
| L5 | 自组织群体 | Agent自主形成组织结构、自适应任务分配 | 研究前沿、尚未生产化 | 15x+ |

---

## 信息采集（INPUT模板）

```yaml
# === MAS架构选型输入 ===
product_name: ""
agent_type: ""
current_architecture: ""            # 当前架构层级

# 任务特征
task_characteristics:
  task_complexity: ""                # 简单/中等/复杂
  skill_diversity: ""                # 需要多少种不同技能
  workflow_flexibility: ""           # 流程是否固定
  parallelism_potential: ""          # 是否有并行处理空间
  interdependence: ""                # 子任务间依赖程度

# 资源约束
resource_constraints:
  budget: ""                         # 预算范围
  latency_requirement: ""            # 延迟要求
  team_capability: ""                # 团队工程能力

# 质量要求
quality_requirements:
  reliability_need: ""               # 可靠性要求
  observability_need: ""             # 可观测性要求
  debuggability_need: ""             # 可调试性要求

# 治理要求
governance_requirements:
  risk_level: ""                     # 风险等级
  auditability_need: ""              # 审计要求
  human_oversight_need: ""           # 人工监督要求
```

---

## 执行分析引擎（S1-S4）

### S1：需求-架构匹配分析（Requirement-Architecture Mapping）

**目标**：基于任务特征和约束条件，判断最适合的架构层级。

**架构决策树**：

```
任务是否需要多种不同技能？
├── 否 → L1 单Agent
└── 是 → 流程是否固定且可预见？
    ├── 是 → 子任务是否可串行？
    │   ├── 是 → L2 链式管道
    │   └── 否 → L3 监督者编排
    └── 否 → 是否有明确的调度规则？
        ├── 是 → L3 监督者编排
        └── 否 → 是否必须依赖涌现行为？
            ├── 是 → L4 Swarm（需强理由）
            └── 否 → L3 监督者编排
```

**评分锚点**：
- 5分：决策树路径清晰，选择有明确依据，无模糊地带
- 3分：路径基本清晰但存在1-2个需进一步验证的判断点
- 1分：决策路径不清晰，缺乏选择依据

**输出模板**：
```yaml
requirement_mapping:
  skill_diversity: ""                # 高/中/低
  workflow_flexibility: ""           # 固定/半灵活/完全灵活
  dispatch_clarity: ""               # 规则明确/需动态决策/需涌现
  recommended_level: ""              # L1-L5
  decision_path: ""                  # 决策树路径
  confidence: ""                     # 高/中/低
```

### S2：成本-收益分析（Cost-Benefit Analysis）

**目标**：量化不同架构层级的成本和预期收益。

**成本维度**：

| 成本类型 | L1 | L2 | L3 | L4 | L5 |
|----------|----|----|----|----|----|
| Token消耗 | 1x | 2-3x | 3-5x | 8-15x | 15x+ |
| 工程复杂度 | 低 | 中 | 高 | 很高 | 极高 |
| 调试难度 | 低 | 中 | 高 | 很高 | 极高 |
| 延迟 | 低 | 中 | 中高 | 高 | 很高 |
| 一致性风险 | 低 | 中 | 中高 | 高 | 很高 |

**收益维度**：
1. **能力提升**：处理复杂任务的能力提升幅度
2. **覆盖范围**：能处理的任务类型范围扩展
3. **质量上限**：在最佳情况下的输出质量上限
4. **可扩展性**：新增技能/任务的扩展成本

**评分锚点**：
- 5分：成本-收益比清晰，选择层级有明确的ROI支撑
- 3分：成本估算合理但收益量化不充分
- 1分：成本-收益分析缺失

**输出模板**：
```yaml
cost_benefit:
  recommended_level: ""
  cost_estimate:
    token_multiplier: ""
    engineering_complexity: ""
    latency_impact: ""
  benefit_estimate:
    capability_gain: ""
    coverage_expansion: ""
    quality_ceiling: ""
  roi_assessment: ""
  key_tradeoff: ""                   # 最关键的权衡点
```

### S3：L3作为中心点的验证（L3 as Center Point Validation）

**目标**：如果考虑L4，必须验证L3确实无法满足需求。

**L3无法满足的四个证据**：
1. **调度规则不可预先定义**：任务路由需要基于上下文动态判断，无法用规则引擎覆盖
2. **需要涌现行为**：问题解决方案需要Agent间自主协商产生，而非预设流程
3. **实时性要求极高**：集中式调度的延迟无法满足，需要去中心化处理
4. **单点故障不可接受**：监督者Agent的故障会导致整个系统不可用

**验证检查清单**：
- [ ] 是否已尝试在L3中实现所需功能？
- [ ] L3的具体瓶颈是什么？（不是「感觉L3不够用」）
- [ ] L4的涌现行为是否真的能解决这个瓶颈？
- [ ] 是否准备好承担8-15倍的成本增幅？
- [ ] 团队是否有驾驭L4的工程能力？

**评分锚点**：
- 5分：四个证据中至少3个成立，且已做过L3验证
- 3分：1-2个证据成立，但未充分验证L3的极限
- 1分：选择L4的理由不充分，L3可能就够了

**输出模板**：
```yaml
l3_validation:
  evidence:
    - evidence: ""
      status: ""                    # 成立/不成立/待验证
      details: ""
  l3_attempted: ""                  # 是/否
  l3_specific_bottleneck: ""
  l4_will_solve: ""                 # 是/否/不确定
  team_ready: ""                    # 是/否
  conclusion: ""                    # 升级到L4/留在L3
```

### S4：架构实施方案（Architecture Implementation Plan）

**目标**：为选定的架构层级制定实施方案。

**执行步骤**：
1. **架构设计**：定义Agent角色、通信协议、状态管理
2. **监控设计**：定义可观测性方案（日志、指标、追踪）
3. **降级策略**：定义架构故障时的降级方案
4. **迭代路径**：定义从当前架构到目标架构的渐进路径

**评分锚点**：
- 5分：架构设计完整，有监控和降级策略，迭代路径清晰
- 3分：架构设计基本完整但缺少降级策略
- 1分：架构设计不完整

**输出模板**：
```yaml
implementation_plan:
  architecture_design:
    agents:
      - name: ""
        role: ""
        skills: []
    communication_protocol: ""
    state_management: ""
  monitoring:
    logging: ""
    metrics: ""
    tracing: ""
  degradation_strategy: ""
  iteration_path:
    phase_1: ""
    phase_2: ""
    phase_3: ""
```

---

## 输出格式

### MAS架构选型报告

```markdown
# MAS架构选型报告 — [产品名称]

## 1. 选型摘要
- 当前架构：[L1-L5]
- 推荐架构：[L1-L5]
- 决策依据：[一句话]
- 预期成本增幅：[X]倍

## 2. 需求-架构匹配
[决策树路径及分析]

## 3. 成本-收益分析
[各维度量化对比]

## 4. L3验证（如适用）
[L3无法满足的证据]

## 5. 架构设计概要
[Agent角色、通信协议、状态管理]

## 6. 实施路径
[分阶段实施计划]

## 7. 风险与缓解
[架构风险、降级策略]
```

---

## 治理神经检查

- **意图管理**：多Agent架构中，谁负责理解用户的真实意图？是入口Agent还是各专业Agent？
- **边界与升级**：当某个Agent超出能力边界时，升级路径是什么？监督者Agent是否能正确路由？
- **智能体主权**：Agent间的责任边界是否清晰？Agent A调用Agent B出错，谁负责？

---

## 质量自检

- [ ] 架构选择有决策树支撑
- [ ] 成本-收益分析已完成
- [ ] 如选择L4，L3验证已完成
- [ ] 架构设计包含监控和降级策略
- [ ] 实施路径是渐进式的
- [ ] 治理要求已在架构中体现

---

## 典型误区

1. **「L4比L3更先进」**：错。L4更复杂，但不等于更好。L3是当前生产环境的最佳实践中心点。选择L4需要非常强的理由
2. **「多Agent一定更强大」**：错。多Agent引入了通信开销和协调成本。如果任务可以用L1完成，用L3是浪费
3. **「先上L4再优化」**：危险。L4的调试难度远高于L3。应该从L3开始，有明确证据后再考虑L4
4. **「架构选型是技术决策」**：不完全是。架构选型涉及成本、治理、团队能力，是产品+技术+治理的综合决策
5. **「Swarm很酷所以要用」**：Swarm的核心问题不是技术不可行，而是工程难驾驭。在生产环境中，可控性比酷炫更重要

---

## 框架衔接

- **上游 → F15**：上下文设计在多Agent场景中更复杂——Agent间的上下文传递是MAS设计的核心挑战
- **上游 → F17/F18**：每增加一层架构复杂度，VERITAS和CATER的要求都提升一级
- **下游 → F20**：工程方法需要适配架构层级——L3需要编排引擎，L4需要通信中间件
- **下游 → F23**：企业架构需要考虑MAS与现有系统的集成
- **横向 → F08**：组织设计需要匹配架构——L3需要「监督者」角色，L4需要更扁平的协作模式

---

## 体系编排接线（CEO内核 P3/P4 阶段读取）

**编排内核**：本Skill由智能体CEO总编排内核统一调度（https://qiuyiwu.com/ams/skills/CEO.md）；独立使用不受影响，按上文标准流程执行即可。

**所属作战链**：不固定属于八条预设链——作为独立专家由内核按需调用，或在定制链中出场。

**常用搭配**：
- **F23 企业智能体六层架构**：先用 F19 判断多Agent成熟度阶段，再用 F23 落地对应架构