Subagent模式和Agent Team模式的区别

狒狒 2026-5-13 AI 5 次

拓扑差异

Subagent 模式（星形 / 主-工人）
                                    
        ┌──────────────┐            
        │  主 Claude   │ ← 唯一接你输入的人
        │  (session)   │            
        └──┬───┬───┬───┘            
           │   │   │  ← 派工 + 收摘要
       ┌───▼─┐ ▼ ┌─▼───┐
       │子A  │ ... │子N│  ← 独立上下文，干完就死
       └─────┘   └─────┘            
       子代理之间不通信，只能通过主 agent 中转


Agent Team 模式（网状 + 共享队列）

   ┌──────────────────────────────────┐
   │     共享任务列表 (~/.claude/      │ ← 看板
   │      tasks/<team>/)               │
   │   [todo] [in_progress] [done]    │
   └──────┬───────────┬──────────┬─────┘
          │           │          │
     ┌────▼───┐  ┌────▼───┐  ┌──▼─────┐
     │ Lead   │←→│ Worker │←→│ Worker │  ← 持久存活
     │ (你输入)│  │   A    │  │   B    │
     └────────┘  └────────┘  └────────┘
           ↑ SendMessage 工具，横向通信 ↑
           每个跑在独立 tmux pane / 独立 session

Subagent 详解

本质：一次性专家工人。主 Claude 通过 Task 工具派一个有限任务，工人在全新上下文窗口里跑完，把结果压缩后返回主线，工人进程结束。

特征：

只活一次任务的长度
工人之间完全不知道彼此存在
信息流：星形，所有沟通经过主 Claude
主 Claude 上下文随子任务结果累积膨胀
用 .claude/agents/*.md 预定义角色，也可临时派

典型场景：

大代码库探索（派 5 个工人各看一个模块，汇总）
代码审查（派 security/performance/style 三个审查员，主收单）
分而治之的纯并行任务（subagent 间无依赖）

致命缺点：主 agent 是信息瓶颈。如果工人 A 发现的东西工人 B 也需要，必须先回到主线再转发——经常被"摘要丢失"。

Agent Team 详解

本质：长期协作的真团队。多个 Claude Code 实例独立 session并行跑，通过共享任务列表协调，通过 SendMessage 工具直接互相对话。

特征：

Claude Code v2.1.32+ 实验功能，需要 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 开启
队友长期存活，跨多个任务积累领域知识
信息流：网状，可点对点也可广播
共享状态在文件系统 ~/.claude/tasks/<team-name>/
任务用 pending/in_progress/completed/blocked 状态机
文件锁防止并发冲突

架构图（看 Claude Code 实际实现）：

 Team Lead session（你说话的对象）
        │
        │ 1. 拆任务写入共享列表
        ▼
   ┌──────────────────┐
   │  shared task list │ ← 看板，所有人可读写
   └──┬──────────┬─────┘
      │          │
   2. 各自捞活做  │
      ▼          ▼
   Frontend     Backend     ← tmux pane 里独立 session
   teammate     teammate     ← 跨 panel 用 SendMessage 通信
      │          │
   3. 完成后写回结果，触发依赖任务

典型场景：

跨层修改：前端组件 + 后端 API + 数据库迁移 + 测试，四个领域并行推进
需要协商：A 发现的设计问题影响 B 的实现，A 直接发消息给 B
长开发周期：accumulated context 比反复 spawn 更高效

致命缺点：

token 消耗指数级（3 个队友 ≈ 3 倍并发计费）
协调开销大，简单任务用它就是过度工程化
实验性，会话恢复/关闭还有 bug

决策树

我有任务要做，单个 agent 不够……
│
├── 子任务之间需要互相对话吗？
│   │
│   ├── 不需要（独立或纯顺序）
│   │   └─→ Subagent（轻量、便宜、稳定）
│   │
│   └── 需要（互相依赖、需要协商）
│       │
│       ├── 短期一次性任务
│       │   └─→ 让 Subagent 把发现写回共享文件（伪 team）
│       │
│       └── 长期持续工作
│           └─→ Agent Team
│
└── 单文件改动 / 紧密耦合？
    └─→ 别拆，单 session 干（任何拆分都是亏的）

Anthropic 官方总结的五大模式

他们的多代理协调博客把整个空间整理成五种正交模式，前两种就是上面讲的——其他三种更通用：

1. Generator-Verifier（生成-验证） —— 最简单

Generator → 产出 → Verifier → ✓ accept / ✗ reject + feedback
                                              │
                                              └→ 回炉重造

代码：写代码 + 跑测试的回路就是这个。也叫 builder-validator chain。

2. Orchestrator-Subagent（编排-子代理） ← 上面讲过的 subagent 适合：任务可清晰拆解、子任务弱依赖

3. Agent Teams（持久工人 + 共享队列） ← 上面讲过的 team 适合：长期并行、需要协商

4. Message Bus（消息总线） —— 事件驱动

 Event Source → [Bus] → 多个 Listener 各做各的反应
                    ↑          ↓
                    └──── 新事件 ──┘

适合：CI/CD、监控告警、自动化管道。agent 可热插拔，加新 listener 不影响别人。Claude Code 的 hooks 就有这种味道。

5. Shared-State（共享状态） —— 协作建造

 Agent A ────┐
  Agent B ────┼──→ 大家都对 shared workspace 增改 ←
  Agent C ────┘     （文档、知识图谱、设计稿）

适合：共同构建知识资产。Agent Team 是这个的一种实例化。

实战选型

90% 的人只用 Subagent 就够。Agent Team 在以下场景才值得：

场景	该用
给大代码库做摸底分析	Subagent split-and-merge
PR 多维度审查（安全/性能/风格）	Subagent 扇出
TDD 红绿循环	Generator-Verifier
全栈功能开发（前端+后端+测试同时）	Agent Team
重构涉及跨层强依赖	Agent Team
简单一两文件修改	啥都别用，单 session
文档生成 / 翻译 / 批量改名	单 session 或单 Subagent

省钱小技巧：

bash

# 主线用 Opus 思考，subagent 切到 Sonnet/Haiku 干活 export CLAUDE_CODE_SUBAGENT_MODEL="claude-sonnet-4-5"

主线复杂决策用大模型，工人执行明确任务用小模型——质量几乎不降，成本大幅下降。Agent Team 因为队友独立配置，可以每个 teammate 用不同模型。

一句话总结

	Subagent	Agent Team
一句话	主 Claude 派的临时工	多个 Claude 组成的协作团队
通信	星形，通过主线	网状，横向 + 共享看板
寿命	一次任务	跨多任务存活
上下文	干完就丢	累积形成领域专长
代价	主线 context 膨胀	token 多倍 + 协调复杂
启用	默认就有	v2.1.32+ 实验，需开关
类比	派外包工	组建一支常驻团队