Claude Code Agent Teams 将单线程的 Claude Code 体验转变为协调式多智能体系统，多个独立的 Claude 实例可以相互通信、共享任务，并在你的代码库上并行工作。作为 2026 年 2 月发布的实验性功能，Agent Teams 代表了开发者与 AI 编码助手交互方式的根本性转变——从一次一个对话，转向编排整个开发团队。本指南将引导你了解构建高效 Agent Teams 所需的一切，从初始设置到生产就绪的架构模式。
要点速览
Agent Teams 让你可以生成多个协同工作的 Claude Code 会话。一个会话充当团队负责人(Lead)来协调工作，而队友(Teammates)在各自的上下文窗口中独立执行任务。与 Subagents（在单个会话内运行，只能向父级报告）不同，Teammates 可以直接相互发送消息、在任务进行中共享发现，并且无需 Lead 充当中间人即可协调工作。通过在环境变量或 settings.json 中设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true 即可启用此功能，同时需要 Claude Code v2.1.32 或更高版本。Anthropic 通过使用 16 个并行智能体构建了一个 100,000 行的 C 编译器（能够编译 Linux 内核），展示了这种方法的强大之处——在约 2,000 个会话中总计花费约 $20,000（记录于 Anthropic 工程博客，2026 年 2 月）。
Claude Code Agent Teams 是什么？（与 Subagents 有何不同）
在 Agent Teams 出现之前，Claude Code 提供 Subagents 作为并行化工作的主要方式。Subagents 在单个会话的上下文中运行，执行一个有范围限制的任务，然后将结果返回给父级 Agent。它们对于将探索性工作与主对话分离很有用——例如，在主 Agent 继续推理架构问题的同时搜索代码库中的某个模式。但 Subagents 有一个根本性的局限：它们无法互相对话。如果 Agent A 发现了与 Agent B 工作相关的信息，该信息必须通过父级 Agent 路由，这就造成了一个瓶颈，限制了可能的协调方式。
Agent Teams 通过赋予每个 Teammate 自己的完整 Claude Code 会话来解决这个问题——每个 Teammate 都拥有独立的上下文、工具访问权限，以及向任何其他 Teammate 或 Lead 发送消息的能力。这种架构差异解锁了 Subagents 不可能实现的模式：前端 Agent 可以直接告知后端 Agent 某个 API 接口的变更，测试 Agent 可以在不等待 Lead 转发消息的情况下提醒代码编写者某个测试失败了，多个 Agent 可以通过直接讨论来就某个问题达成共识。
下表说明了何时使用哪种方法，因为选择错误的方法要么会导致不必要的复杂性（用 Agent Teams 做简单搜索），要么会产生协调瓶颈（用 Subagents 处理跨领域变更）：
| 维度 | Subagents | Agent Teams |
|---|---|---|
| 会话 | 在父级会话内运行 | 每个获得独立的完整会话 |
| 通信 | 单向：子级 → 父级 | 双向：任意 → 任意 |
| 上下文 | 共享父级的上下文窗口 | 独立的上下文窗口 |
| 协调方式 | 父级作为中间人 | 直接的点对点消息传递 |
| 适用场景 | 专注的、隔离的任务 | 复杂的多部分项目 |
| 配置 | 内置，无需配置 | 需要实验性标志 |
| 成本 | 较低（单会话开销） | 较高（多会话开销） |
可以将 Subagents 想象为聘请了一位向你汇报的专家顾问，而 Agent Teams 则像是组建了一个每个人都可以互相交流的项目小组。如果你已经熟悉 Claude Code 的功能，想了解 Agent Teams 在整体工具体系中的定位，可以参考我们的 Claude Code 安装指南。
Agent Teams 的底层工作原理
Agent Teams 的架构由三个核心组件构成：一个 Lead 会话、一个或多个 Teammate 会话，以及基于任务文件和智能体间消息传递构建的共享协调层。
团队负责人(Lead)是你的主要 Claude Code 会话——也就是你输入初始 prompt 描述团队要完成什么任务的那个会话。当 Claude 判断该任务适合并行工作时，它会使用 Teammate 工具来生成额外的 Claude Code 进程。每个生成的进程作为独立的 Claude Code 会话运行，拥有自己的上下文窗口、工具权限和对话历史。Lead 为每个 Teammate 分配初始任务，并通过共享任务系统监控进度。
队友(Teammates)是完全自治的 Claude Code 实例，从 Lead 接收初始 prompt 后独立工作。它们可以读写文件、执行命令、搜索代码库，使用所有标准的 Claude Code 工具。至关重要的是，它们还可以使用 SendMessage 工具向 Lead 和其他 Teammates 发送消息，这使得 Agent Teams 区别于简单的并行执行，实现了真正的实时协调。
协调层由两种机制协同工作。第一，存储在磁盘上的共享任务列表，所有团队成员都可以读取和更新。任务具有状态（pending、in_progress、completed），可以阻塞其他任务，并包含关于谁在做什么的元数据。当一个 Teammate 完成任务时，被阻塞的下游任务会自动变为可用状态，供其他 Teammates 认领。第二，SendMessage API 为需要比任务状态变更更多细微沟通的场景提供直接的智能体间通信——比如共享发现、请求澄清或提议方法变更。
这种架构意味着 Agent Teams 在生成时会产生一波并行活动，随着任务完成和 Teammates 交流发现而逐渐收敛，最终回归到 Lead 会话中，由 Lead 综合结果并呈现给你。整个过程在终端中可见：你可以观察智能体之间的消息流动，看到任务状态更新，如果团队偏离方向可以及时干预。
理解 Agent Team 会话的生命周期有助于你预估成本和时间。在生成阶段(通常 10-30 秒)，Lead 创建 Teammate 会话并分配初始任务。在并行执行阶段(会话的主体部分，从几分钟到几小时不等)，Teammates 独立工作，偶尔进行智能体间的消息交流。收敛阶段在第一批 Teammates 完成任务时开始，它们开始协助剩余工作或审查他人的输出。最后，综合阶段中 Lead 收集所有结果、解决冲突并呈现统一的响应。每个阶段的 token 消耗特征不同——生成阶段成本很低，并行执行阶段最为昂贵，综合阶段取决于 Lead 需要进行多少协调工作。
值得注意的是，每个 Teammate 会话继承了 Lead 会话的权限和工具访问权限，但不会继承对话历史。Teammates 以一个干净的上下文开始，仅包含分配的任务描述和 Lead 提供的初始上下文。这意味着 Teammates 不知道在团队创建之前你与 Lead 讨论了什么，这实际上是一个优势——它迫使 Lead 提供明确、自包含的指令，而不是依赖对话中更早期的隐式上下文。如果 Teammate 需要对话历史中的信息，Lead 必须将其包含在任务描述中或通过消息发送。
设置你的第一个 Agent Team（分步指南）
启用 Agent Teams 需要开启实验性功能标志，并理解几个影响团队行为的配置选项。设置过程不到五分钟，但你在此处做出的配置选择会影响团队的运行效率。
**第 1 步：验证 Claude Code 版本。**Agent Teams 需要 v2.1.32 或更高版本。在终端运行 claude --version 检查版本。如果需要更新，运行 npm install -g @anthropic-ai/claude-code@latest 或使用适合你安装方式的包管理器。
**第 2 步：启用实验性标志。**你有三种方式启用 Agent Teams，选择取决于你想全局还是按项目启用：
json// 方式 A：项目级别设置（.claude/settings.json） { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true" } } // 方式 B：用户级别设置（~/.claude/settings.json） { "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "true" } } // 方式 C：环境变量（会话级别） // export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=true
推荐使用项目级别设置，因为它确保在同一仓库工作的所有人都启用了 Agent Teams，无需修改个人配置。该设置会持久化跨会话保存，并与项目一起提交到版本控制。
**第 3 步：启动 Claude Code 并描述团队任务。**在项目目录中启动 Claude Code，给出一个自然暗示并行工作的 prompt。关键是描述你想要的结果和所涉及的不同工作流，而不是微管理 Claude 应该如何构建团队。例如，不要说"创建三个 Agent"，而是说："审查这个 Pull Request 的安全问题、性能问题和测试覆盖率缺口。每个领域应独立检查，发现汇总成一份报告。"
Claude 会分析你的 prompt，确定需要多少 Teammates 才有效，为它们分配专注的指令，并设置任务协调结构。你会在终端中看到 Teammates 被创建和开始工作的消息。
**第 4 步：监控进度。**团队工作时，你可以在终端输出中观察共享任务列表和智能体间消息。Lead Agent 会定期检查 Teammates 的状态，如果某个 Teammate 提前完成或遇到阻碍，可能会重新分配任务。如果你需要引导团队方向，可以向 Lead Agent 发送消息，它会将相关指令转发给受影响的 Teammates。
**第 5 步：收集和审查结果。**当所有任务完成后，Lead Agent 综合所有 Teammates 的发现并呈现统一的响应。Teammates 通过 SendMessage 关闭协议自动关闭：Lead 发送 shutdown_request，每个 Teammate 确认 shutdown_response，会话清理关闭。
如果在设置过程中遇到问题，最常见的原因是版本不兼容（更新 Claude Code）、缺少功能标志（检查所有三个可能的设置位置）以及权限错误（确保你的 API 密钥或订阅有足够的配额支持多个并发会话）。对于 API 用户，要注意每个 Teammate 会消耗自己的 token 配额，这会显著加速速率限制消耗。
另一个实际考虑是系统资源。每个 Teammate 作为独立的 Node.js 进程运行，在内存有限的机器上生成大型团队可能导致性能问题。对于大多数开发机器，3 到 5 个同时运行的 Teammates 可以舒适工作。如果需要更大的团队（10 个或更多），建议使用至少 16GB RAM 的机器并监控进程内存使用。网络带宽很少成为瓶颈，因为 Teammates 之间的通信通过本地文件系统操作和 API 调用进行，但到 Anthropic API 的延迟可能影响 Teammates 响应消息的速度。
对于使用 Claude Code 免费版的团队，Agent Teams 功能可以使用，但有限的使用配额在多个并发会话下会被更快消耗。在依赖 Agent Teams 进行实质性工作之前，建议升级到 Pro 或 Max，或使用有足够配额的 API 访问，以避免在团队会话进行中出现令人沮丧的中断。
实际项目中的团队架构模式
高效的 Agent Team 和混乱的并行 Claude 会话之间的差异，归结为你如何构建团队的职责划分和通信模式。通过社区经验和 Anthropic 自身的测试，四种架构模式被证明在不同类型的工作中始终有效。
模式 1：审查小组(Review Squad)。这种模式将同一个工件分配给多个审查者，每个人从不同的角度进行审查。典型配置生成三个 Teammates——一个专注于安全漏洞，一个关注性能瓶颈，一个检查代码风格和可维护性。Lead 收集所有审查意见并生成按严重程度排序的统一报告。这种模式非常适合 Pull Request 审查、架构评估和文档审计，因为审查者之间无需协调——他们独立检查相同的内容，Lead 负责综合。Token 成本相对较低，因为每个审查者读取相同的文件而不生成大量代码更改。
模式 2：功能构建器(Feature Builder)。当构建一个跨越多个技术层的新功能时，功能构建器模式为每一层分配一个 Teammate：前端、后端、数据库和测试。Lead 预先定义各层之间的接口（API 契约、数据模式），然后让每个 Teammate 独立实现各自的部分。这是智能体间消息传递变得至关重要的地方——当后端 Teammate 发现 API 契约需要调整时，它直接向前端 Teammate 发送消息，而不是通过 Lead 路由。功能构建器模式在功能边界清晰、组件间接口可以在工作开始前定义的情况下最为有效。
模式 3：调试蜂群(Debug Swarm)。调试复杂问题通常受益于同时探索多个假设。调试蜂群生成多个 Teammates，每个追踪关于根本原因的不同理论。一个可能调查最近的代码变更，另一个检查日志模式，第三个审查不同环境之间的配置差异。随着 Teammates 排除假设或发现支持性证据，它们会相互分享发现。当证据积累到位时，蜂群自然收敛，Lead 在清晰的画面出现后综合诊断结果。这种模式在处理间歇性故障、竞态条件或跨多个服务的问题时特别有价值。
模式 4：跨层协调(Cross-Layer Coordination)。最复杂的模式处理一个区域的变更会级联到多个其他区域的任务——例如重命名一个核心数据模型，该模型出现在 API 层、数据库迁移、前端组件和测试 fixtures 中。Lead 规划变更顺序，将每一层分配给一个 Teammate，Teammates 通过直接消息协调具体的变更。这种模式需要最多的智能体间通信，并受益于清晰的任务依赖关系：数据库迁移必须在 API 变更之前完成，API 变更又必须在前端更新之前完成。
一个真实案例说明了这些模式在实践中的运作方式。在一个记录的案例中，开发者向 Claude 发出 prompt："使用一个 Agent 团队对我在 localhost:4321 上的博客进行 QA 测试。"Lead 生成了五个基于 Sonnet 的 Teammates，每个负责不同的 QA 视角：核心页面响应、博客文章渲染、导航和链接、RSS/sitemap/SEO 以及可访问性。Teammates 独立工作——页面响应 Agent 检查了 16 个页面的 HTTP 200 状态码，链接检查器验证了 146 个内部 URL，可访问性 Agent 发现了诸如 HTML class 属性中的字符串化布尔值和主题切换按钮缺少 ARIA 标签等问题。Lead 将所有发现综合成一份按优先级排序的报告，包含 10 个问题（4 个重大、2 个中等、4 个轻微）——如果由单个 Agent 按顺序完成，这些工作会花费更长的时间。
一个强大但经常被忽视的功能是计划审批门控(Plan Approval Gate)。在生成 Teammate 时，你可以要求它在进行任何更改之前提交实施计划以获得审批。Teammate 在只读计划模式下工作——它可以读取文件和分析代码库，但在 Lead（或你）批准其计划之前不能修改任何内容。如果计划被拒绝，Teammate 会收到反馈并修改方案。这对于你希望在修改代码之前设置人工检查点的高风险变更非常宝贵，同时仍然受益于 Agent Teams 提供的并行分析能力。
选择模式取决于两个因素：工作流之间的交互程度（低交互倾向审查小组，高交互倾向跨层协调），以及你是在创建新代码还是修改现有代码（新代码倾向功能构建器，现有代码倾向调试蜂群或跨层协调）。对于大多数项目，建议先从审查小组模式开始熟悉 Agent Teams，然后再尝试协调要求更高的模式。
通信与任务管理深入解析
Agent Teams 的效力在很大程度上取决于 Teammates 之间的通信质量和任务结构设计。理解 Teammates 可用的通信原语有助于你设计能产生更好协调模式的 prompt。
SendMessage 是主要的通信工具。它支持几种消息类型，服务于不同的协调目的。标准消息将文本从一个 Agent 发送给另一个——发送者指定接收者（通过名称或团队角色）和消息内容。广播消息同时发送给所有 Teammates，在 Lead 需要宣布方向变更或分享与所有人相关的发现时很有用。关闭请求和响应构成了一个优雅的终止协议，确保没有 Teammate 在任务进行中被打断。
Anthropic 做出的一个重要设计选择是，SendMessage 是唯一的直接通信渠道。没有共享内存，没有共享剪贴板，一个 Teammate 也无法读取另一个 Teammate 的对话历史。这个约束是有意为之的——它迫使通信必须是明确和结构化的，防止那种会使团队行为不可预测的隐式耦合。当 Teammate A 需要 Teammate B 的信息时，它必须通过消息请求，Teammate B 必须以相关上下文回复。这使得信息流可以被审计和调试。
任务管理为协调提供了结构性骨架。任务通过 TaskCreate 创建，通过 TaskUpdate 更新，通过 TaskList 和 TaskGet 查询。每个任务有主题、描述、状态、负责人和可选的依赖链接。依赖系统特别强大：你可以指定任务 B 被任务 A 阻塞，当任务 A 完成时，任务 B 自动变为可用状态，供 Teammate 认领。
以下是 Lead 如何为功能构建器团队构建任务的示例：
pythonTaskCreate(subject="定义用户资料 API 契约", description="...") TaskCreate(subject="实现后端 API 端点", description="...", addBlockedBy=["task-1"]) # 在 API 契约定义前被阻塞 TaskCreate(subject="构建前端资料组件", description="...", addBlockedBy=["task-1"]) # 同样在 API 契约定义前被阻塞 TaskCreate(subject="编写集成测试", description="...", addBlockedBy=["task-2", "task-3"]) # 在两个实现完成前被阻塞
这种依赖结构确保没有 Teammate 在契约定义之前就开始实现，测试只在前端和后端都完成之后才开始。Teammates 在完成当前任务后会自行认领下一个可用的未阻塞任务，这意味着团队自动实现负载均衡，无需 Lead 干预。
一个常见错误是过度复杂化任务依赖图。依赖关系应该反映真正的顺序要求——任务 B 确实无法在任务 A 完成之前开始——而不是表达执行顺序的偏好。过度指定依赖会降低并行度，因为 Teammates 花更多时间等待被阻塞的任务解除。相反，依赖指定不足会导致两个 Teammates 同时修改重叠代码时产生冲突。最佳实践是仅在存在数据或文件级依赖时创建依赖关系，并使用范围定义广泛的任务，给予 Teammates 清晰的文件所有权。
对于处理大型代码库的团队，监控智能体之间的通信量提供了一个有用的健康信号。如果智能体每个任务发送超过几条消息，通常表明任务分解粒度太细，智能体在协调上花费了过多的 token 而不是产出成果。理想的模式是在生成后有一小波消息（智能体确认理解各自的任务），执行期间偶尔有消息（分享发现或请求澄清），以及综合期间最后一轮消息。对于使用 Claude Code API 构建应用的开发者，MCP 集成指南介绍了如何通过 Model Context Protocol 为 Agent Teams 扩展自定义工具。
成本分析——Agent Teams 实际花费多少？
理解 Agent Team 的成本对于做出明智决策至关重要——什么时候并行执行值得投入，什么时候单个 Claude Code 会话就够用了。Agent Teams 的成本模型理论上很直接，但有一些显著影响实际支出的细微之处。
基本公式是：总成本 = Teammates 数量 x 每个 Teammate 的平均 token 数 x 每 token 价格。每个 Teammate 是一个独立的会话，读取文件、思考、生成输出和与其他 Teammates 通信都会消耗 token。Lead 会话也会消耗用于协调开销的 token。与订阅制使用方式（你有固定的月度预算）不同，基于 API 的 Agent Teams 严格按 token 计费，使成本直接与执行的工作量成正比。
Anthropic 的 C 编译器实验提供了目前最具体的成本基准。使用 16 个并行 Opus 4.6 智能体，跨越约 2,000 个 Claude Code 会话，团队生成了一个 100,000 行的基于 Rust 的 C 编译器，能够在 x86、ARM 和 RISC-V 架构上编译 Linux 内核。总成本约为 $20,000 的 API 使用费（来源于 Anthropic 工程博客，2026 年 2 月验证）。换算下来大约每行代码 $0.20，或平均每个会话 $10。这是一个使用最昂贵模型（Opus）执行极其复杂任务的高端场景——大多数开发者的工作流程成本会显著更低。
**模型选择对成本影响巨大。**使用 Sonnet 4.6 而非 Opus 4.6 可将每 token 成本降低 40%（Sonnet 为 $3/$15 每百万 token，Opus 为 $5/$25，来源于 claude.com/pricing，2026 年 3 月验证）。对于许多 Agent Team 任务——代码审查、文档生成、测试编写——Sonnet 提供与 Opus 相当的质量，同时大幅降低成本。一个实用策略是为 Lead Agent 使用 Opus（需要最强的推理能力来协调），为 Teammates 使用 Sonnet（执行更专注、定义更明确的任务）。
成本优化策略可以在不牺牲质量的情况下降低 Agent Team 支出，包括将团队规模限制在能有效并行化工作的最小 Teammates 数量（3 到 5 个通常最优），为每个 Teammate 设定清晰的范围边界以防止冗余探索，使用任务依赖避免在被阻塞的工作上浪费 token 消耗，以及通过 Claude Console 的实时仪表板监控 token 使用情况。
对于经常运行 Agent Teams 并希望进一步降低成本的开发者，laozhang.ai 等第三方 API 中转服务提供按 token 付费的 Claude 模型访问，与直接向 Anthropic 管理 API 层级相比，可能具有更低的开销。这种方式对于使用模式不稳定的团队特别划算——某些周大量使用 Agent Teams，其他周很少使用——因为你避免了为未使用的订阅容量付费。
另一个经常被忽视的成本因素是 Prompt Caching。当多个 Teammates 读取相同的大文件时（这在审查小组模式中很常见），Prompt Caching 显著降低了有效 token 成本。Anthropic 的缓存感知 ITPM 系统意味着缓存的输入 token 不计入速率限制，并且以基础输入价格的 10% 计费。对于共享公共代码库上下文的 Agent Teams，有效的缓存可以将输入 token 成本降低 50-80%。关键优化是构建 Teammate prompt，使共享上下文（如系统指令和公共参考文件）出现在每次请求的开头，最大化 Teammates 之间的缓存命中率。关于缓存如何与速率限制交互的更深入理解，请参阅我们的 Claude Code 速率限制指南。
| 场景 | 智能体数 | 模型 | 预估 Token 数 | 预估成本 |
|---|---|---|---|---|
| PR 审查（3 个视角） | 3 | Sonnet 4.6 | ~50 万总计 | ~$2-5 |
| 新功能（3 层） | 4 | 混合 Opus+Sonnet | ~200 万总计 | ~$15-30 |
| 调试蜂群（4 个假设） | 4 | Sonnet 4.6 | ~100 万总计 | ~$5-12 |
| 大型重构（跨层） | 5 | 混合 | ~300 万总计 | ~$25-50 |
| C 编译器（Anthropic 案例） | 16 | Opus 4.6 | ~数十亿 | ~$20,000 |
从 Anthropic C 编译器实验中学到的经验
关于 Agent Teams 大规模应用的最具指导性的案例来自 Anthropic 自己的工程团队，他们使用 16 个 Opus 4.6 智能体从零开始用 Rust 构建了一个 C 编译器。这个实验记录在 Anthropic 2026 年 2 月的工程博客上，揭示了多智能体开发的巨大潜力和实际局限性。这些关键经验直接适用于开发者应该如何构建自己的 Agent Teams。
**经验 1：并行化在天然可分解的问题上效果最好。**C 编译器项目之所以成功，是因为编译本身具有模块化特性——解析、类型检查、代码生成和优化可以在某种程度上独立开发和测试。团队发现，当存在许多不同的失败测试时，并行度最高，因为每个智能体可以选择不同的失败测试来修复，无需协调。当测试套件达到 99% 的通过率且剩余的失败是相互关联的时候，并行度自然下降，因为智能体需要更小心地协调。对开发者的启示是，在生成团队之前先识别项目中天然的并行边界，而不是希望 Claude 自行找出分解方式。
**经验 2：一个 Oracle 让一切变得更简单。**对于 Linux 内核编译挑战，团队使用 GCC 作为已知正确的编译器 Oracle。他们构建了一个测试工具，随机使用 GCC 编译大部分内核文件，仅使用新编译器编译少量文件，让每个智能体可以同时专注于修复不同文件中的不同 bug。这种模式——将你的输出与可信参考进行对比——可以推广到编译器之外。如果你在重构 API，让旧实现与新实现同时运行，让智能体验证行为等价性。如果你在迁移数据库，比较新旧 schema 之间的查询结果。Oracle 模式将一个开放式的质量问题转化为智能体可以独立执行的闭环验证循环。
**经验 3：通信开销是真实存在的，但可以管理。**有了 16 个智能体，通信混乱的可能性很大。Anthropic 团队发现，结构化的任务依赖减少了不必要的智能体间闲聊：智能体不需要不断互相发消息说自己在做什么，任务系统提供了谁在做什么的可见性。直接消息被保留给真正的发现或冲突——比如两个智能体试图修改同一个文件。对于你自己的团队，要抵制鼓励过度通信的诱惑。大多数 Agent Team 任务受益于"分而治之加检查点"的方法，而不是持续讨论。
经验 4：Token 成本随探索而非仅输出而增长。$20,000 产出 100,000 行代码看起来成本很高，但它反映了构建能处理真实 C 代码全部复杂性的编译器所需的大量探索和调试工作。每个智能体不只是写代码——它读取现有代码、形成关于 bug 的假设、测试修复、回退失败的尝试并迭代。这些探索性工作的 token 成本远超最终输出的成本。从事更直接任务（例如有明确规格的功能实现）的团队将看到低得多的成本产出比。
**经验 5：在关键决策点的人工干预能成倍提升团队效率。**虽然 C 编译器在很大程度上是自主构建的，但 Anthropic 团队发现，在架构决策点——例如在代码生成的竞争方案之间做选择——偶尔的人工指导，可以防止智能体在次优路径上花费数千个 token 进行探索。最有效的工作流不是完全自主的，而是半自主的：智能体在定义明确的子任务上独立工作，人类做出那些框定子任务的高层战略决策。这种混合方式尊重了双方的优势——智能体擅长并行执行定义明确的任务，而人类擅长战略判断和长期规划。
**经验 6：Agent Teams 的价值随项目复杂度递增。**对于简单的功能添加，单个 Claude Code 会话通常比生成一个团队更快更便宜。盈亏平衡点——Agent Teams 每美元产出比顺序工作更好的结果——出现在任务涉及真正的并行工作流（不同文件、不同关注点）或任务受益于多角度审视（代码审查、架构评估）时。C 编译器项目远远超过了盈亏平衡点，因为它涉及数千个可以并行调试的独立测试用例。对于大多数开发者的工作流，盈亏平衡点大约在 3 到 5 个真正独立的子任务——少于这个数量，团队协调的开销就超过了并行化带来的收益。
常见问题解答
一个典型项目应该使用多少个 Teammates？
对于大多数任务，建议从 3 到 5 个 Teammates 开始。审查小组模式适合 3 个专业审查者，而功能构建器模式通常需要 4 个（每层一个加上测试）。超过 5 个 Teammates 很少能提升吞吐量，因为协调开销开始超过并行化的收益。例外是像 Anthropic 编译器实验这样高度可分解的任务，16 个智能体之所以有效，是因为每个都在做真正独立的测试用例，几乎不需要协调。
Agent Teams 可以使用 Pro 或 Max 订阅，还是必须使用 API 访问？
Agent Teams 可以与订阅计划和直接 API 访问配合使用。使用订阅（Pro $20/月或 Max $100-200/月）时，每个 Teammate 从你的共享订阅配额中消耗 token，这意味着你会比使用单个会话更快地达到使用限制。API 访问提供对每个 Teammate token 预算的更精细控制，并避免订阅配额上限，使其更适合大量使用 Agent Teams 的场景。无论使用哪种方式，都要确保你有足够的配额支持计划运行的并发会话数量。
如果两个 Teammates 同时尝试编辑同一个文件会怎样？
Claude Code 通过标准的文件锁定和冲突解决机制处理并发文件访问。在实践中，设计良好的任务依赖可以通过确保同一时间只有一个 Teammate 处理某个文件来防止大多数冲突。如果确实发生冲突，Lead Agent 通常在综合阶段检测到并通过优先采用某个 Teammate 的更改来解决。你可以通过围绕文件所有权构建任务——为每个 Teammate 分配不同的文件或目录而非重叠区域——来最小化冲突。
有没有办法保存和复用团队配置？
目前，Agent Teams 没有内置的模板或配置文件用于预定义团队结构。不过，你可以通过创建描述首选团队模式的 CLAUDE.md 指令，或编写编码特定团队架构的自定义 skills 来实现可复用配置。社区也开发了通过 GitHub gists 和仓库共享的配置模式。随着该功能从实验状态成熟，预计会有更多结构化的配置选项。
Agent Teams 如何与 git 分支和版本控制交互？
每个 Teammate 操作与 Lead 相同的工作目录和 git 状态。这意味着所有 Teammates 看到相同的分支、未提交的更改和文件状态。对于复杂任务，Lead 可以指示 Teammates 使用 git worktrees 在隔离模式下工作，这给每个 Teammate 一个仓库的独立副本。这可以防止并行工作期间的合并冲突，但在结束时需要一个协调步骤。对于 Teammates 修改不同文件的简单任务，直接并发访问主工作目录效果很好。
Agent Teams 是否足够稳定用于生产工作流？
Agent Teams 目前标记为实验性功能，这意味着 Anthropic 可能在不通知的情况下更改 API、行为或可用性。对于生产工作流，这种实验性状态存在风险——Claude Code 更新可能改变团队协调方式或引入对 SendMessage 协议的破坏性更改。也就是说，许多开发者在日常工作流中成功使用 Agent Teams 进行代码审查、功能开发和调试。建议将其用于部分失败可接受且人工干预可行的任务，而不是可靠性至关重要的全自动 CI/CD 管道。当前的显著限制包括：不支持会话恢复（/resume 命令不会恢复 Teammates）、每个会话只能有一个团队、不支持嵌套团队（Teammates 不能生成自己的团队），以及 Teammates 有时不能将任务标记为完成，这可能阻塞依赖任务。随着功能从实验状态发展，这些限制预计会得到改善。