wenjunduan Agent Teams Skill
何时激活
- P.A.C.E. 路由到 Path D
- 用户显式
vibe-dev --team - Lead Agent 判断任务可并行
架构
Lead Agent (你的主 Claude Code 会话)
├── 分析任务 + 拆分子任务
├── cunzhi [TEAM_PLAN] 确认分配方案
│
├── Teammate A (独立上下文窗口)
│ └── 子任务 + 限定 MCP + 限定文件范围
├── Teammate B (独立上下文窗口)
│ └── 子任务 + 限定 MCP + 限定文件范围
├── Teammate C (独立上下文窗口)
│ └── 子任务 + 限定 MCP + 限定文件范围
│
└── Lead 监控进度 → 合并结果 → cunzhi [TEAM_DONE]
Agent Teams vs Subagents
| 特性 | Subagents | Agent Teams |
|---|---|---|
| 通信 | 只向主 agent 汇报 | teammates 互相通信 |
| 上下文 | 共享主 agent 窗口 | 各自独立窗口 |
| 适用 | 快速聚焦子任务 | 需要协调的并行工作 |
| Token | 较低 | 显著更多 |
决策原则: 如果 teammates 不需要互相沟通，用 subagents。需要互相挑战和协调的，用 Agent Teams。
最佳场景
| 场景 | 团队结构 |
|---|---|
| 代码审查 | 3 个 reviewer 分别审查不同模块 |
| 新功能开发 | frontend / backend / tests 各一个 |
| Bug 竞争假设 | 3 个 agent 分别验证不同假设 |
| 跨层变更 | UI / API / DB 各一个 |
反模式 (不要用 Agent Teams)
- 顺序依赖的任务 (A 必须等 B 完成)
- 同一文件的修改 (merge 冲突)
- 简单任务 (overhead 不值得)
任务状态与 .ai_state 联动
Lead 创建团队:
→ .ai_state/doing.md 记录 "[TEAM] 任务名: N teammates"
Teammate 完成:
→ Lead 更新 doing.md 进度
全部完成:
→ Lead 合并 → doing.md → done.md
→ cunzhi [TEAM_DONE]
配置
// settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}
降级策略
Agent Teams 失败或不可用 → 自动降级到 Path C (单 agent 顺序执行)。
Lead Agent 记录降级原因到 .ai_state/decisions.md。