让多个AI队友协同作战，突破单智能体的协作边界

前言

如果你已经熟悉 Claude Code 的子代理（Subagent）功能，应该了解这种模式：一个主对话将任务委派给子代理，子代理独立执行后将结果返回。这种「主 → 从」模式虽然高效，但存在明显的局限——子代理之间无法直接沟通，所有协调必须经过主对话中转，更谈不上智能体之间的相互校验或讨论。

Agent Teams 正是为了突破这一瓶颈而设计的。它不只是把任务并行化，而是引入了一种全新的协作范式：多个 AI 实例在同一个项目中协同工作，它们可以互相通信、共享任务进度，甚至通过对抗式讨论来验证彼此的判断。

本文将从核心概念、工作原理、配置方法、实战场景到注意事项，全面讲解 Agent Teams 的使用方法。

前置说明：Agent Teams 目前仍是实验性功能，需要手动启用。功能细节可能随版本更新发生变化。

1. 核心概念

1.1 什么是 Agent Teams

Agent Teams 是 Claude Code 中用于协调多个 Claude 实例在同一个项目中协同工作的机制。它的核心思路是：每个队友智能体都运行在各自独立的上下文中，并且可以点对点直接通信——通信不再仅限于「主智能体 → 子智能体」的单向模式。

在一个 Agent Teams 会话中，有一个智能体担任团队负责人（Team Lead），负责拆解任务、创建队友、协调进度和汇总结果。其余的队友智能体（Teammates）各自独立运行，彼此之间可以直接交换信息、质疑对方的结论，并在他人的工作基础上继续推进。

1.2 核心组件

┌─────────────────────────────────────────────────────┐
│                  Team Lead（团队负责人）             │
│        拆解任务 / 创建队友 / 协调进度 / 汇总结果      │
│                                                     │
│  ┌──────────┐     ┌───────────┐     ┌────────────┐  │
│  │  队友 A   │←──→│  队友 B    │←──→ │   队友 C   │  │
│  │ 独立上下文 │    │ 独立上下文 │     │ 独立上下文 │  │
│  └─────┬────┘     └──────┬─────┘     └─────┬─────┘  │
│        │                 │                 │        │
│        └─────────────────┼─────────────────┘        │
│                          ↓                          │
│              共享任务列表（Task List）               │
│         pending → in_progress → completed           │
└─────────────────────────────────────────────────────┘
                         ↑↓
                    Mailbox（消息系统）
              定向消息 / 广播消息 / 空闲通知

  • Team Lead（团队负责人）：团队的主会话，承担拆解任务、创建队友、监控进度、汇总结果的职责。

  • Teammates（队友智能体）：独立运行的 Claude 实例，每个队友拥有独立的上下文窗口，可以与其他队友直接通信。

  • Task List（共享任务列表）：所有智能体共享的任务看板，每个任务有三种状态：pending（待处理）、in_progress（进行中）、completed（已完成）。任务之间可以设置依赖关系。

  • Mailbox（消息系统）：智能体之间的通信通道，支持定向消息和广播消息，消息即时送达。

2. 工作原理

2.1 协作流程

一个典型的 Agent Teams 工作流程如下：

  1. 用户提出需求

  2. Team Lead 分析需求，拆解为多个子任务

  3. Team Lead 创建队友，分配初始任务

  4. 队友并行执行任务，可以互相通信、质疑、对齐；完成任务后自动从任务列表认领下一个任务

  5. 所有任务完成

  6. Team Lead 汇总结果，呈现给用户

用户提出需求
    ↓
Team Lead 分析需求，拆解为多个子任务
    ↓
Team Lead 创建队友，分配初始任务
    ↓
┌──────────────────────────────────────────┐
│  队友 A 执行任务 1                        │
│  队友 B 执行任务 2     ← 并行推进         │
│  队友 C 执行任务 3                        │
│                                          │
│  队友之间可以互相通信、质疑、对齐          │
│  完成任务后自动从任务列表认领下一个        │
└──────────────────────────────────────────┘
    ↓
所有任务完成
    ↓
Team Lead 汇总结果，呈现给用户

2.2 上下文与信息流

每个队友在创建时会加载以下上下文：

  • 项目级上下文：CLAUDE.md、MCP 服务配置、已启用的技能

  • Team Lead 提供的启动提示和任务描述

  • 共享任务列表的当前状态

需要注意：

  • CLAUDE.md 正常生效，队友会从各自的工作目录读取该文件。

  • Team Lead 的对话历史不会传递给队友，队友只能看到 Team Lead 明确传递的信息。

2.3 队友之间如何共享信息

  • 消息系统：定向消息或广播消息即时送达

  • 空闲通知：队友完成任务进入空闲状态时自动通知 Team Lead

  • 共享任务列表：所有智能体都能查看任务状态并认领任务

  • 文件系统：所有队友共享同一个项目文件系统，文件修改即时可见

2.4 数据存储

团队和任务的相关数据存储在本地：

  • 团队配置：~/.claude/teams/{team-name}/config.json

  • 任务列表：~/.claude/tasks/{team-name}/

3. 多智能体方案对比

Claude Code 提供了三种并行工作方案，适用场景各不相同。

选型建议：

维度 Subagents（子代理） Agent Teams（团队模式） Worktree（工作树）
拓扑结构 星型：主对话居中，子代理汇报 网状：队友之间直接通信 无拓扑：完全独立的会话
上下文 各自独立窗口，结果摘要返回主对话 各自独立窗口，完全自主运行 各自独立窗口，独立 Git 分支
通信方式 子代理只能向主对话汇报 队友之间可以直接互发消息 无自动通信，需手动协调
协调方式 主对话统一调度 共享任务列表 + 自主认领 完全手动
并发安全 单会话内安全 文件锁防冲突 Git 分支隔离
Token 成本 较低 较高（约 3–4 倍） 低（无协调通信开销）
学习曲线 低 中等 低
适用场景 专注型任务，只需要结果 复杂任务，需要讨论、协作和对抗验证 长期并行的独立功能开发选型建议：

选型建议：

  • 子任务独立、只需执行和返回结果 → Subagents

  • 任务复杂、需要多角度讨论和跨角色协作 → Agent Teams

  • 需要队友之间相互校验和挑战 → Agent Teams

  • 独立功能分支、长期并行开发 → Worktree

  • 控制成本优先 → Subagents

4. 快速配置指南

4.1 前置条件

  • 已安装 Claude Code 且版本不低于 2.1.33

  • 可以访问配置文件 ~/.claude/settings.json

  • （可选）如需分屏查看多个智能体，建议安装 tmux 或使用 iTerm2

如有需要，先更新 Claude Code：

claude update
claude --version

4.2 第1步：启用实验性功能

Agent Teams 默认关闭，需要手动启用。有两种方式：

方式一：编辑 settings.json（推荐，永久生效）
编辑 ~/.claude/settings.json：

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

保存后重启 Claude Code 使配置生效。

方式二：环境变量（临时生效，适合快速测试）

export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
claude

4.3 第2步：选择显示模式

Agent Teams 提供两种显示模式：

  • 进程内模式（In-Process）：所有队友运行在同一个终端中，一次只显示一个队友的输出，可通过快捷键切换。适用于任何终端环境。

  • 分屏模式（Split-Pane）：每个队友都有独立的终端窗格，可以同时看到所有队友的输出。需要 tmux 或 iTerm2。

默认模式为 auto：检测到 tmux 环境时自动使用分屏模式，否则使用进程内模式。

手动指定模式：

{
  "teammateMode": "in-process"
}

或在启动时：

claude --teammate-mode in-process
claude --teammate-mode tmux

4.4 第3步：安装 tmux（分屏模式需要）

# macOS
brew install tmux

# Ubuntu / Debian / WSL
sudo apt update && sudo apt install tmux

4.5 第4步：验证配置

重启 Claude Code 后，运行 /config 命令，确认 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS 已启用。

4.6 第5步：创建你的第一个团队

进入 Claude Code 后，直接用自然语言描述目标：

> 创建一个智能体团队来重构认证模块。
> 将工作分解为可以独立完成的并行任务。

Claude 会自动拆解任务、创建队友并开始协同推进。你也可以手动指定队友和职责：

> 创建一个包含 3 个队友的团队：
> - 队友 1：重构登录流程
> - 队友 2：重构注册流程
> - 队友 3：为两者编写和更新测试
>
> 每个队友使用 Sonnet 模型。
> 队友 3 在队友 1 和队友 2 完成后再开始。

5. 导航与交互

5.1 进程内模式快捷键

操作 快捷键
切换选中的队友 Shift+Up / Shift+Down
进入该队友的会话视图 Enter
返回 Team Lead 视图 Escape
打断队友正在执行的操作 Escape（查看队友时）
显示/隐藏任务列表 Ctrl+T
给选中的队友发消息 输入内容后按 Enter

5.2 分屏模式操作

  • 选择要交互的队友：点击对应的窗格

  • 向队友发送指令：在对应窗格中直接输入

  • 查看任务列表：在任意窗格中执行 /tasks

  • 切回 Team Lead：点击 Team Lead 所在的窗格

6. 高级控制

6.1 委托模式（Delegate Mode）

默认情况下，Team Lead 可能会自己动手写代码。如果你希望它只负责协调和调度，可以开启委托模式（Shift+Tab）。在委托模式下，Team Lead 只做协调工作，不会修改代码或执行命令。

6.2 计划审批（Plan Approval）

对于复杂或高风险的任务，可以要求队友在动手之前先提交执行计划，由 Team Lead 审批通过后再开始实施。在计划审批模式下，队友只能读取文件和调查信息，无法修改代码。

6.3 指定队友模型

默认队友使用与 Team Lead 相同的模型。你可以针对不同任务指定不同模型：

> 创建一个包含 4 个队友的团队：
> - 1 个使用 Haiku 的研究员，负责快速检索和信息收集
> - 1 个使用 Opus 的架构师，负责复杂的设计决策
> - 2 个使用 Sonnet 的实现者，负责代码编写和测试

6.4 预批准权限

队友执行文件操作或命令时会向 Team Lead 请求权限确认。在大型团队中，频繁的权限请求会成为瓶颈。可以在创建团队前使用 /permissions 命令预先批准常用操作。

6.5 关闭队友与清理团队

  • 关闭单个队友：告诉 Team Lead "关闭队友 xxx"

  • 清理整个团队：告诉 Team Lead "清理团队"（需先关闭所有活跃队友）

Team Lead 会移除共享的团队资源。执行清理前会检查是否仍有活跃队友——如果有正在运行的队友，清理会失败。因此请先关闭所有队友，再执行团队清理。

7. 通过 Hooks 把控质量

Hooks 可以作为质量关卡，在队友完成工作的关键节点进行自动化检查：

  • TeammateIdle：队友完成任务进入空闲状态时触发。如果检查脚本发现问题，返回 exit 2 并附上反馈信息，队友会收到反馈并继续工作。

  • TaskCompleted：任务即将标记为完成时触发。返回 exit 2 可以阻止任务完成，将修改意见返回给队友。

示例配置：

{
  "hooks": {
    "TaskCompleted": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "./scripts/verify-task-quality.sh"
          }
        ]
      }
    ]
  }
}

8. 实战应用场景

8.1 场景1：多视角并行代码审查

让多个队友从不同角度同时分析同一套代码：

> 创建一个智能体团队来审查 PR #142，包含三个审查员：
> - 安全专家：检查注入风险、认证缺陷、敏感信息暴露
> - 性能分析师：查找 N+1 查询、内存泄漏、不必要的循环
> - 测试验证者：检查边界情况覆盖和测试充分性
>
> 各自独立完成审查后，由 Team Lead 汇总为按优先级排序的问题清单。

8.2 场景2：对抗式调试

当问题的根本原因不明确时，让多个智能体同时验证不同假设：

> 用户报告结账接口出现间歇性 500 错误，约 5% 的请求会失败，无明显规律。
>
> 创建 5 个调查员分别验证以下假设：数据库连接池耗尽、库存竞态条件、第三方支付超时、内存 GC、网络抖动。
>
> 要求：每个调查员必须给出支持或否定其假设的具体证据；调查员之间互相挑战、质疑对方的结论。

8.3 场景3：跨层功能开发

将一个完整的功能拆分为互不干扰的层级：

> 创建一个智能体团队来开发通知系统，包含以下队友：
> - 队友 1（后端）：设计并实现通知 API
> - 队友 2（数据库）：设计表结构、编写迁移脚本
> - 队友 3（前端）：实现通知铃铛组件、通知列表页
> - 队友 4（实时）：WebSocket 集成，实现实时推送
> - 队友 5（测试）：编写端到端集成测试
>
> 任务依赖明确，每个队友只修改自己负责范围内的文件。

8.4 场景4：技术方案竞标评审

让不同队友分别论证不同方案：

> 我们需要为项目选择状态管理方案。创建一个评审团队：
> - 队友 A（Redux 方案）：论证使用 Redux Toolkit 的优势
> - 队友 B（Zustand 方案）：论证使用 Zustand 的优势
> - 队友 C（Pinia 方案）：论证使用 Pinia 的优势
>
> 每个队友必须给出基于当前项目的实际论证，并列出缺点和风险。
> 队友之间互相质疑对方方案的薄弱点，Team Lead 最终输出对比分析报告。

8.5 场景5：大规模代码迁移

当需要在大量文件中执行统一变更时：

> 项目需要将所有 API 请求从 axios 迁移到原生 fetch，涉及约 60 个文件。
> 创建一个迁移团队，按目录分工，队友 4 在所有迁移完成后更新测试文件。

9. 最佳实践

9.1 何时适合使用 Agent Teams

适合：

  • 任务可拆分为多个独立的工作单元并行推进

  • 需要多角度分析或审查（代码审查、方案评审、对抗式调试）

  • 跨层或跨模块的功能开发，各队友负责不同的文件范围

  • 大规模批量变更（迁移、重命名、格式统一等）

不适合：

  • 任务本身是严格顺序的，无法并行

  • 多个队友需要频繁修改同一个文件（易产生冲突）

  • 工作之间存在强耦合，队友之间需要频繁等待

  • 体量很小的日常任务——协调成本可能超过收益

9.2 给队友足够的上下文

创建队友时提供的启动提示（spawn prompt）至关重要。一个好的启动提示应包含：

  • 任务目标

  • 涉及的文件范围

  • 技术约束

  • 期望的产出物

9.3 任务拆分原则

  • 文件范围不重叠：每个队友操作不同的文件或目录

  • 粒度适中：任务应是自包含的工作单元

  • 依赖关系明确：在创建团队时显式声明

  • 产出可验证：每个任务应有明确的完成标准

  • 合理分配任务量：建议每个队友分配 5–6 个任务

9.4 Token 成本管理

  • 先用单会话评估复杂度，确认是否真的需要多智能体协作

  • 控制团队规模，通常 3–5 个队友即可覆盖大多数场景

  • 模型分层：研究任务用 Haiku，编码用 Sonnet，架构用 Opus

  • 及时关闭已完成任务的队友

  • 避免不必要的广播消息

10. 当前限制

限制 说明 应对方式
不支持会话恢复 /resume 和 /rewind 不会恢复进程内模式下的队友 在关键节点手动保存进展描述
任务状态偶尔不同步 队友有时不会及时将任务标记为 completed 通过 /tasks 手动检查并干预
关闭存在延迟 队友会在完成当前请求后才退出 预留等待时间，不要立即清理
单会话单团队 一个 Team Lead 同一时间只能管理一个团队 如需多个团队，使用多个终端会话
不支持嵌套团队 队友无法创建或管理子团队 通过 Team Lead 统一协调所有队友
分屏依赖外部工具 Split-pane 模式需要 tmux 或 iTerm2 使用进程内模式作为替代
文件冲突风险 多个队友修改同一文件可能产生冲突 严格划分文件范围，避免交叉操作
负责人角色固定 创建团队的会话在整个生命周期内担任 Team Lead 如需更换负责人，需清理当前团队并重新创建
权限在创建时继承 所有队友继承 Team Lead 的权限模式 创建后可单独调整队友的权限模式

11. 常见问题排查

问题 排查方法
团队创建后队友没有开始工作 检查实验性功能是否启用；版本是否满足；任务描述是否足够复杂
队友之间通信没有生效 确认队友处于活跃状态；检查是否使用了正确的队友名称
分屏模式没有生效 确认 tmux 已正确安装；确认是在 tmux 会话中启动 Claude Code
tmux 残留会话未清理 tmux ls 列出会话，tmux kill-session -t <session-name> 清理
队友遇到错误后停止工作 切换到该队友查看错误信息；发送补充指示引导其继续；或创建新队友接替
Team Lead 提前认为工作已完成 告诉 Team Lead "还有队友的任务未完成，请等待所有任务完成后再汇总"
权限请求过于频繁 使用 /permissions 预批准常用操作；或考虑跳过权限检查
Token 消耗异常高 检查是否有队友空转；减少广播消息；及时关闭空闲队友；考虑模型分层

12. 命令速查表

操作 命令 / 快捷键
启用 Agent Teams（settings.json） "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
启用 Agent Teams（环境变量） export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
强制进程内模式 claude --teammate-mode in-process
强制分屏模式 claude --teammate-mode tmux
切换选中的队友 Shift+Up / Shift+Down
进入队友会话 Enter
返回 Team Lead Escape
显示/隐藏任务列表 Ctrl+T
切换委托模式 Shift+Tab
关闭指定队友 告诉 Team Lead："关闭队友 xxx"
清理团队资源 告诉 Team Lead："清理团队"
列出 tmux 会话 tmux ls
清理残留 tmux 会话 tmux kill-session -t <session-name>

13. 总结

Agent Teams 代表了一种从「单智能体执行」到「多智能体协作」的范式升级。它与 Claude Code 生态深度结合，在保留子代理能力的基础上，引入了结构化的团队协作机制——共享任务列表、点对点通信、计划审批、委托模式。

它最适合的场景是：任务可拆分、角度可互补、讨论有价值。当你面对需要多视角分析的审查任务、原因不明的复杂 bug、跨层级的功能开发时，Agent Teams 能提供单智能体模式无法达到的效率和质量。

同时也要清醒认识到它的代价：更高的 Token 成本、实验性功能的不稳定性、以及多智能体协调本身的复杂度。对于简单直接的日常任务，单个会话或 Subagents 仍然是更经济的选择。

# windows
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

cover

基于SpringBoot+Vue的教学资源库管理系统设计与实现【Java+MySQL+MyBatis完整源码】

avatar AtomGit开源社区

基于粒子群优化算法的三方三层的主从博弈能源系统优化模型研究（Matlab代码实现）

针对传统能源系统优化中多主体利益失衡、可再生能源消纳不足、多储能形式协同性差等问题，本文构建了含风光可再生能源、电储能、热储能、电解制氢及氢储能的三方三层主从博弈能源系统优化模型，并采用粒子群优化算法求解博弈均衡解。首先，明确能源系统中能源供应商、储能运营商、终端用户三方主体的权责与利益诉求，搭建“上层主导-中层协同-下层响应”的三层主从博弈架构；

avatar AtomGit开源社区
cover

【毕业设计】SpringBoot+Vue+MySQL 服装生产管理设计与实现平台源码+数据库+论文+部署文档

avatar AtomGit开源社区