AgentTeams 与 Subagents：多智能体系统的最佳实践

原创技术文章，首发于掘金作者：Asher | 阅读时间：10 分钟 | 难度：中级

前言

随着大语言模型（LLM）技术的快速发展，AI Agent 正在从单一智能体向多智能体协作系统演进。在实际应用中，我们经常面临这样的问题：

什么时候应该用多个 Agent 协作？什么时候用单个 Agent 就够了？
AgentTeams 和 Subagents 有什么本质区别？如何正确选择？
如何设计高效的多智能体系统？有哪些最佳实践？

本文基于 BMAD（Build, Monitor, Analyze, Deploy）框架的实战经验，深入解析 AgentTeams 和 Subagents 的核心差异、使用方法和应用场景，并提供一套完整的设计决策框架。

一、核心概念：什么是 AgentTeams 和 Subagents？

1.1 AgentTeams：协作型智能体团队

AgentTeams（智能体团队） 是由多个具有独立人格、专业领域和沟通风格的 Agent 组成的协作系统。它们通过一个**协调器（Orchestrator）**来管理对话流程，实现自然的多智能体讨论。

核心特征：

复制代码

🎭 独立人格  每个 Agent 有独特的个性、说话方式和专业视角
🎯 专业分工  不同 Agent 负责不同领域（分析师、架构师、设计师等）
🔄 对话协作  Agent 之间可以相互对话、辩论、补充
🧠 集体智慧  通过多视角碰撞产生超越单 Agent 的洞见

架构示意：

markdown 复制代码

用户请求
    ↓
┌─────────────────────────────┐
│   Orchestrator (协调器)    │
│  - 理解用户意图             │
│  - 选择相关 Agent            │
│  - 管理对话流程             │
└───────────┬─────────────────┘
            │
    ┌───────┼───────────┐
    ↓       ↓           ↓
┌─────┐ ┌─────┐   ┌─────┐
│分析 │ │架构 │   │设计 │
│ Agent│ │Agent│   │Agent│
└──┬──┘ └──┬──┘   └──┬──┘
   │        │          │
   └────────┼──────────┘
            ↓
    协同讨论/辩论
            ↓
        综合输出

实际案例：BMAD 的 Party Mode

BMAD 框架中的 Party Mode 是 AgentTeams 的典型实现：

yaml 复制代码

# _bmad/core/workflows/party-mode/workflow.md
**Goal:** Orchestrates group discussions between all installed BMAD agents,
enabling natural multi-agent conversations

**Agent Selection Intelligence:**
- Analyze user's message for domain and expertise requirements
- Select 2-3 most relevant agents for balanced perspective
- Enable natural cross-talk and agent-to-agent interactions

当用户发起 Party Mode 时，所有专业 Agent（分析师、架构师、设计师、开发人员、QA 等）会聚在一起，针对用户的问题进行多视角讨论。

1.2 Subagents：任务型子智能体

Subagents（子智能体） 是从主 Agent 派生出来的、用于隔离特定任务的功能模块。它们通常没有独立人格，而是作为主 Agent 的"工具"来执行具体任务。

核心特征：

复制代码

🔧 功能导向  专注于特定任务，不具备独立人格
🧩 模块化设计  作为功能模块被主 Agent 调用
📦 上下文隔离  每个子 Agent 有独立的上下文空间
⚡ 任务专一  处理完后返回结果，不参与持久对话

架构示意：

css 复制代码

主 Agent (Context Window)
├── 任务 A
│   └── 调用 Subagent A (独立上下文)
│       └── 返回结果 A
├── 任务 B
│   └── 调用 Subagent B (独立上下文)
│       └── 返回结果 B
└── 综合结果 A + B

实际案例：BMAD 的 PRD 创建流程

在创建产品需求文档（PRD）时，主 Agent 会将不同章节的处理委托给 Subagents：

yaml 复制代码

# _bmad/bmm/workflows/2-plan-workflows/create-prd/steps-e/step-e-01b-legacy-conversion.md

**Try to use Task tool with sub-agent:**

当处理复杂章节时，主 Agent 会：
1. 识别需要深度处理的章节
2. 创建 Subagent 专门处理该章节
3. Subagent 拥有独立的上下文和知识库
4. 处理完成后返回结果给主 Agent
5. 主 Agent 整合所有 Subagent 的输出

这种方式的优势是防止上下文雪球（context snowball），避免单一 Agent 的上下文被过多信息污染。

二、核心差异对比表

维度	AgentTeams	Subagents
定义	多个独立人格的 Agent 协作	单一 Agent 的功能模块
人格	✅ 每个有独立人格和沟通风格	❌ 无独立人格，作为工具存在
关系	平等协作，相互对话	主从关系，主 Agent 调用
上下文	共享对话历史	独立上下文空间
交互方式	自然对话、辩论、补充	函数调用、任务委托
生命周期	持续存在，随时可唤醒	按需创建，用完即销
输出形式	多视角的综合结论	任务执行结果
适用规模	3-10 个 Agent（最佳实践）	不限，按需创建

三、使用场景深度解析

3.1 AgentTeams 适用场景

✅ 场景 1：需要多专业视角的复杂决策

案例：技术方案评审

arduino 复制代码

用户："我们正在设计一个分布式缓存系统，需要技术方案建议"

Party Mode 激活：
┌─────────────────────────────────────────────────┐
| 🔷 Winston (Architect)                  |
| "从系统架构角度，我建议用一致性哈希..."    │
└─────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────┐
| 📊 Mary (Business Analyst)                |
| "但成本如何？是否能满足业务 SLA？"           │
└─────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────┐
| 💻 Dev (Developer)                       |
| "实现复杂度如何？团队有没有相关经验？"        │
└─────────────────────────────────────────────────┘
         ↓
┌─────────────────────────────────────────────────┐
| ✅ QA (Quality Assurance)                 |
| "我需要考虑可测试性和监控..."              │
└─────────────────────────────────────────────────┘

为什么适合：

需要架构、业务、开发、测试多个视角
Agent 之间可以相互质疑和补充
最终结论是集体智慧的综合

✅ 场景 2：创意头脑风暴

案例：新产品功能设计

vbnet 复制代码

用户："我们想设计一个智能日程推荐功能"

Mary (BA): "用户痛点是什么？现有方案有什么不足？"
Zara (UX): "UI/UX 应该怎么设计？交互流程？"
Winston (Architect): "技术上如何实现？推荐算法？"
Dev: "工程可行性如何？需要哪些 API？"

为什么适合：

创意需要碰撞
不同角色贡献不同维度的想法
自然对话更容易激发灵感

✅ 场景 3：争议性问题讨论

案例：技术选型决策

vbnet 复制代码

Winston: "从架构角度，我选方案 A..."
Dev: "但方案 A 的性能有问题，我建议方案 B..."
QA: "两个方案的可测试性都不太理想..."
Mary: "成本和收益呢？时间成本如何？"

为什么适合：

Agent 之间可以辩论
避免"一言堂"
最终决策更全面

3.2 Subagents 适用场景

✅ 场景 1：深度文档分析

案例：分析大型 PRD 文档

python 复制代码

# 主 Agent 上下文（空间有限）
主 Agent 需要分析 5000 行的 PRD 文档

❌ 如果直接全部加载：
    → 上下文爆炸
    → 关键信息被淹没
    → 难以聚焦

✅ 使用 Subagents:
    for chapter in prd.chapters:
        subagent = create_subagent(chapter)
        result = subagent.analyze()
        results.append(result)

    主 Agent 整合 results，提取关键信息

为什么适合：

避免上下文雪球
每个 Subagent 专注分析特定章节
提高分析深度和准确性

✅ 场景 2：并行处理独立任务

案例：代码审查的多维度分析

python 复制代码

# 同时调用多个 Subagents 并行处理
results = parallel_execute([
    create_subagent("security_check", code),
    create_subagent("performance_check", code),
    create_subagent("style_check", code),
    create_subagent("test_coverage_check", code)
])

# 主 Agent 综合结果
final_report = consolidate(results)

为什么适合：

任务之间相互独立
可以并行执行，提高效率
结果标准化，易于整合

✅ 场景 3：工具封装和复用

案例：数据库查询工具

python 复制代码

# 主 Agent 定义一个 Subagent 作为工具
@subagent
def query_database(query):
    # 执行数据库查询
    # 返回结果
    pass

# 主 Agent 在需要时调用
主 Agent: "查询过去 30 天的销售额"
    ↓
调用 query_database Subagent
    ↓
返回数据
    ↓
主 Agent 进行分析和展示

为什么适合：

将复杂操作封装为 Subagent
主 Agent 不需要知道实现细节
提高代码复用性

四、设计决策框架

4.1 选择流程图

scss 复制代码

开始
    ↓
任务是否需要**多个专业视角**？
    ├─ 是 → AgentTeams
    │   └─ Agent 之间需要**相互对话/辩论**？
    │       ├─ 是 → 🎯 **AgentTeams** (Party Mode)
    │       └─ 否 → 考虑是否应该用单一 Agent
    │
    └─ 否 → 单一 Agent 足够
        └─ 任务是否会导致**上下文爆炸**？
            ├─ 是 → 🧩 **Subagents** (任务拆分 + 上下文隔离)
            └─ 否 → 单一 Agent 直接处理

4.2 检查清单

AgentTeams 检查清单

需要 2 个以上专业角色的输入
Agent 之间需要相互对话或辩论
输出需要多视角综合
Agent 数量在 3-10 个之间（最佳实践）
有明确的协调器（Orchestrator）
Agent 之间有互补性（而非重复）

Subagents 检查清单

五、最佳实践与陷阱

5.1 AgentTeams 最佳实践

✅ 实践 1：合理控制团队规模

反模式：

markdown 复制代码

❌ 创建 20 个 Agent 的超大团队
    → 对话混乱，难以协调
    → 响应时间长
    → 信息过载

最佳实践：

markdown 复制代码

✅ 3-5 个核心 Agent，按需扩展
    - 核心团队：分析师 + 架构师 + 开发
    - 按需补充：QA、设计师、PM
    - 避免冗余角色

✅ 实践 2：设计明确的协调逻辑

BMAD Party Mode 的协调规则：

yaml 复制代码

# Agent Selection Intelligence
- 分析用户消息的领域和专长需求
- 根据角色、能力和原则选择 2-3 个最相关的 Agent
- 考虑对话上下文和之前 Agent 的贡献
- 确保视角的平衡性

# Priority Handling
- 如果用户点名某个 Agent，优先该 Agent + 1-2 个互补 Agent
- 轮换 Agent 选择，确保多元参与
- 启用自然的跨对话和 Agent 间互动

✅ 实践 3：保持 Agent 个性一致性

示例：BMAD Agent 个性定义

yaml 复制代码

# Winston (Architect)
role: System Architect + Technical Design Leader
communication_style: "Speaks in calm, pragmatic tones,
                    balancing 'what could be' with 'what should be'"
principles:
  - "Embrace boring technology for stability"
  - "Design simple solutions that scale when needed"

# Mary (Business Analyst)
communication_style: "Speaks with the excitement of a treasure hunter
                      - thrilled by every clue"
principles:
  - "Ground findings in verifiable evidence"
  - "Every business challenge has root causes waiting to be discovered"

为什么重要：

让用户产生信任感和代入感
不同视角的碰撞更有价值
避免"千人一面"

5.2 Subagents 最佳实践

✅ 实践 1：任务拆分要合理

反模式：

markdown 复制代码

❌ 过度拆分
    主 Agent 调用 50 个 Subagents
    → 调度开销过大
    → 通信成本高
    → 难以调试

最佳实践：

markdown 复制代码

✅ 合理拆分（3-7 个 Subagents）
    - 按功能模块拆分
    - 按数据维度拆分
    - 确保每个 Subagent 有明确价值

✅ 实践 2：标准化输出格式

BMAD 的 Subagent 输出模板：

yaml 复制代码

# 每个 Subagent 返回结构化结果
subagent_output:
  summary: "简要总结"
  details: "详细信息"
  findings:
    - "发现 1"
    - "发现 2"
  recommendations:
    - "建议 1"
  confidence: 0.85  # 置信度

为什么重要：

主 Agent 容易整合结果
可以自动化处理
便于质量评估

✅ 实践 3：合理利用并行能力

python 复制代码

# 并行调用多个 Subagents
async def parallel_analysis(code):
    results = await asyncio.gather(
        security_check(code),
        performance_check(code),
        style_check(code),
        test_coverage_check(code)
    )
    return consolidate(results)

性能提升：

串行执行：4 个任务 × 10 秒 = 40 秒
并行执行：max(10, 10, 10, 10) = 10 秒
提升 4 倍！

5.3 常见陷阱

⚠️ 陷阱 1：混淆 AgentTeams 和 Subagents

错误理解：

arduino 复制代码

❌ "我用 10 个 Subagents，这就是 AgentTeams 吧？"
    → 错！Subagents 没有独立人格，不能对话

正确理解：

ini 复制代码

✅ AgentTeams = 多个有独立人格的 Agent 协作
✅ Subagents = 单一 Agent 的功能模块

⚠️ 陷阱 2：过度使用 AgentTeams

反模式：

erlang 复制代码

❌ 简单任务也用 Party Mode
    用户："怎么用 Git 提交代码？"
    → 调用 5 个 Agent 讨论...
    → 浪费资源，响应慢

正确做法：

复制代码

✅ 简单问题用单一 Agent
✅ 复杂问题才用 AgentTeams

⚠️ 陷阱 3：忽视上下文管理

反模式：

markdown 复制代码

❌ Subagents 共享上下文
    → 信息泄露
    → 污染主 Agent 的上下文

正确做法：

复制代码

✅ 每个 Subagent 有独立上下文
✅ 只返回关键结果给主 Agent
✅ 及时清理无用上下文

六、实战案例：BMAD 框架的应用

6.1 BMAD AgentTeams：Party Mode 实现

架构图：

scss 复制代码

Party Mode Orchestrator
         ↓
    ┌────┴────┬─────┬────┬─────┐
    ↓         ↓     ↓    ↓     ↓
 📊Mary    🏗️Winston  💻Dev  ✅QA  🎨Zara
 Analyst   Architect  Dev    QA   Designer
 (BA)       (Arch)          (Test)  (UX)

6.2 BMAD Subagents：PRD 创建流程

流程图：

scss 复制代码

主 Agent (Create PRD Workflow)
         ↓
    ┌────┴────────┬────────────┬──────────┐
    ↓            ↓            ↓          ↓
Subagent 1   Subagent 2   Subagent 3   ...
(分析需求)   (编写功能)   (评审质量)
    ↓            ↓            ↓
    └────────────┴────────────┘
              ↓
       整合所有结果
              ↓
        生成最终 PRD

七、总结与展望

7.1 核心要点回顾

维度	AgentTeams	Subagents
核心价值	集体智慧、多视角碰撞	模块化、上下文隔离
适用场景	复杂决策、头脑风暴、争议讨论	深度分析、并行处理、工具封装
关键特征	独立人格、相互对话、协调器	功能导向、按需调用、独立上下文
设计原则	控制规模（3-10 个）、明确协调、保持个性	合理拆分、标准化输出、利用并行

7.2 选择决策矩阵

markdown 复制代码

                    任务复杂度
                      ↗      ↘
                   简单          复杂
                    ↓            ↓
             单一 Agent      AgentTeams
                    ↓
            是否需要上下文隔离？
                 ↓
           是 → Subagents
           否 → 单一 Agent

7.3 未来展望

趋势 1：更智能的协调算法

基于强化学习的 Agent 选择
动态调整团队规模
个性化协作模式

趋势 2：跨 Agent 的知识共享

Agent 之间的经验积累
共享知识图谱
集体学习机制

趋势 3：混合模式

AgentTeams 内部使用 Subagents
灵活切换协作模式
更高效的资源利用

结语

AgentTeams 和 Subagents 是多智能体系统中的两种核心模式，它们各有侧重、互补性强。AgentTeams 适合需要集体智慧的场景，Subagents 适合需要模块化隔离的场景。

正确理解并应用这两种模式，可以显著提升 AI Agent 系统的能力上限和开发效率。希望本文能帮助你在实际项目中做出更好的技术决策！

如果这篇文章对你有帮助，欢迎点赞、收藏、评论！有任何问题，欢迎在评论区讨论～

全文完！

Happy Coding! 🚀