Claude Code 中的 Agent Teams 让你能够编排多个 AI 编码会话，它们可以直接通信、共享任务并自主协调——将数小时的串行工作压缩为几分钟的并行执行。这一实验性功能随 Claude Opus 4.6 于 2026 年 2 月 5 日发布，只需设置一个环境变量即可启用，支持 2-16 个智能体在共享代码库上协同工作。Agent Teams 在计划模式下大约消耗单会话 7 倍的 token（code.claude.com/docs/en/costs，2026 年 2 月），但对于合适的任务——并行代码审查、多模块功能开发和复杂调试——生产力提升远超成本增加。
要点速览
Claude Code Agent Teams 允许一个会话充当团队负责人，生成独立的队友，每个队友拥有自己的上下文窗口和工具访问权限。队友通过邮箱系统直接通信，并通过共享任务列表进行协调——这与子代理（subagents）不同，后者只能向父会话汇报。你可以通过在 settings.json 或 shell 环境中设置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 来启用 Agent Teams。Agent Teams 的最佳应用场景是复杂的多文件工作，队友之间确实需要通信：横跨前端、后端和测试的全栈功能开发；审查人员需要对比发现结果的并行代码审查；以及多个调查者测试竞争性假设的调试场景。Agent Teams 的 token 消耗大约是单会话的 3-7 倍（取决于配置），因此对于简单的串行任务，应避免使用——单会话或轻量级子代理能以极低的成本完成这类工作。
Agent Teams 是什么，为什么需要它
Claude Code 在处理复杂任务方面经历了三个不同的范式演进。最初的单会话模式按顺序处理所有内容——一个上下文窗口，一次处理一个任务。随 Task 工具引入的子代理添加了星型拓扑模式，父会话可以生成轻量级工作进程来执行特定任务、报告结果然后终止。2026 年 2 月随 Opus 4.6 发布的 Agent Teams 则更进一步，实现了持久化、独立的 Claude 实例之间的完整点对点通信。关于该功能及其发布背景的更全面介绍，请参阅我们的 Claude 4.6 Agent Teams 完整指南。
Agent Teams 解决的核心问题是智能体间通信。使用子代理时，如果工作进程 A 发现了工作进程 B 需要知道的信息，它无法直接告诉 B——必须先向父会话汇报，然后由父会话通过生成另一个子代理或更新自身上下文来转发信息。当任务相互依赖时，这种瓶颈会成为严重的限制。编写 UI 组件的前端开发者需要知道后端开发者正在创建哪些 API 端点，编写集成测试的测试人员则需要知道两者各自在构建什么。Agent Teams 通过让所有智能体通过共享邮箱直接通信，消除了这一瓶颈。
该架构由四个相互关联的组件组成。团队负责人（Team Lead）是你的主 Claude Code 会话——它分析任务、使用 TeamCreate 工具创建团队、生成队友并协调整体工作流。队友（Teammates）是独立的 Claude Code 进程，每个都有自己的上下文窗口和完整的工具访问权限，通过带有 team_name 参数的 Task 工具生成。共享任务列表位于 ~/.claude/tasks/{team-name}/，作为协调骨干，包含具有状态、所有权和依赖关系的任务。最后，邮箱系统（Mailbox System）通过 SendMessage 工具实现直接的点对点消息传递——任何队友都可以向其他队友发消息或向整个团队广播。
Anthropic 的工程团队通过使用 16 个 Agent Teams 构建了一个完整的 C 编译器来验证这一架构（anthropic.com/engineering，2026 年 2 月）。该项目消耗了大约 2,000 个会话、20 亿输入 token 和 1.4 亿输出 token，产生了 100,000 行 Rust 代码，成功编译了 Linux 6.9 内核，API 使用成本约为 20,000 美元。这一概念验证证明了多智能体协调可以在真实的软件工程中大规模运作——而不仅仅是玩具示例。
如何配置 Agent Teams（完整配置指南）
Agent Teams 目前是实验性功能，这意味着你需要通过三种方法之一显式启用它。最持久的方法是将标志添加到 settings.json 文件中，这将应用于你机器上的所有会话。运行 claude config 或直接编辑 ~/.claude/settings.json 打开 Claude Code 设置，并在 environment 部分添加实验性功能标志。这确保 Agent Teams 始终可用，无需每次启动会话时都记住设置环境变量。
json{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }
第二种方法是在启动 Claude Code 之前设置 shell 环境变量。如果你只想在特定终端会话中使用 Agent Teams，或者不想修改全局配置文件，这种方法很有用。只需在 shell 配置文件中导出变量，或在启动 Claude Code 时内联设置。
bashexport CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 claude
第三种方法是通过启动参数按会话启用 Agent Teams，适合在不进行永久配置更改的情况下进行实验。一旦通过任何方法启用，Agent Teams 立即可用——当 Claude Code 判断某个任务适合多智能体协调时，就会使用团队相关工具（TeamCreate、TaskCreate、SendMessage）。
Agent Teams 支持两种显示模式，控制队友会话的显示方式。默认的进程内模式（in-process mode）在单个终端窗口中运行所有队友，以内联方式显示状态更新和空闲通知。这在任何终端中都能工作，但 3 个或更多智能体时可能会变得杂乱。分屏模式（split-pane mode）使用 tmux 或 iTerm2 为每个队友生成单独的终端面板，让每个智能体拥有自己的可视工作区。对于 3 个或更多智能体的团队，强烈推荐使用分屏模式，因为它让你能够实时直观地监控每个智能体的工作。
要使用 tmux 分屏，确保已安装 tmux 并在 tmux 会话中启动 Claude Code。Claude Code 会自动检测 tmux 并为每个队友创建新面板。对于 macOS 上的 iTerm2，原生分屏支持会自动检测——无需额外配置。如果你使用的终端既不支持 tmux 也不支持 iTerm2 分屏，Agent Teams 在进程内模式下仍然可以正常工作，但视觉反馈仅限于主会话中的状态消息。
权限配置对 Agent Teams 至关重要。默认情况下，队友继承与团队负责人相同的权限模型，这意味着它们在执行过程中可能会提示确认。为了高效的团队运作，考虑在受控开发会话中使用 --dangerously-skip-permissions，或在设置中配置允许工具的白名单。你还可以在生成队友时利用 mode 参数将其设置为 "bypassPermissions" 或 "plan" 模式。计划模式（Plan mode）特别有用——它强制队友在实施之前先提出变更方案，在共享代码库中添加了一道质量关卡来防止代价高昂的错误。
为 Agent Team 工作流优化项目的 CLAUDE.md 文件是一个关键但经常被忽视的步骤。当队友被生成时，它会读取项目的 CLAUDE.md 来理解编码规范、架构和约束。一个结构良好的 CLAUDE.md 应该包含：项目模块边界的清晰描述（让队友知道哪些文件属于哪个领域）、编码风格指南（确保不同智能体的修改保持一致）以及不应修改的文件或目录（防止并发智能体之间的合并冲突）。添加专门用于 Agent Team 协调的章节——例如"作为队友工作时，开始新工作前始终检查 TaskList"——可以显著改善团队行为。
Agent Teams vs 子代理：实用决策框架
在开始任务之前，选择单会话、子代理还是 Agent Teams 是你做出的最关键决定，因为它直接决定了成本和效果。错误的选择要么在不必要的协调开销上浪费 token，要么因为强制串行执行本可并行的工作而浪费生产力。这个决策框架将选择提炼为三个逐步缩小范围的问题，理解它可以避免新用户最常犯且最昂贵的错误：对所有任务都使用 Agent Teams。
第一个维度是评估你的任务是否真正受益于并行执行。如果你只是修复单个文件中的 bug、更新文档或进行自然串行的修改，单会话每次都是最优选择。单会话的 token 成本最低（1x 基线）、零协调开销，并且能完美处理绝大多数日常编码任务。因为 Agent Teams 听起来很强大就想使用它，这种冲动可以理解，但只有当确实存在可以并发运行且互不干扰的工作时，并行化才有价值。
第二个问题是子代理和 Agent Teams 之间的关键分叉点：并行工作进程是否需要相互通信？子代理采用星型拓扑模式运行，每个工作进程将结果报告回父会话然后终止，但兄弟子代理之间无法直接通信。这使得子代理非常适合"天然并行"的任务——跨五个不同模块运行测试、在多个目录中搜索模式或为独立组件生成文档。子代理的成本大约是单会话的 1.5-2 倍，比完整的 Agent Teams 便宜得多。
Agent Teams 只有在队友确实需要点对点通信时才值得其 3-7 倍的 token 成本。典型例子是构建全栈功能：前端开发者需要知道后端开发者正在创建哪些 API 端点，测试编写者需要知道双方的接口契约。如果没有直接通信，父会话就成了在工作进程之间传递信息的昂贵瓶颈——而这个中转过程本身也在消耗 token 并引入延迟。同样，当你希望审查人员相互借鉴发现时，代码审查也适合使用 Agent Teams：一个审查人员发现性能问题并通报，另一个审查人员则验证建议的修复方案是否会引入安全漏洞。
下表从关键维度对比了三种方法：
| 维度 | 单会话 | 子代理 | Agent Teams |
|---|---|---|---|
| Token 成本倍数 | 1x | 1.5-2x | 3-7x |
| 智能体通信 | 不适用 | 仅星型拓扑 | 完整点对点 |
| 上下文持久性 | 持续 | 任务后终止 | 跨轮次持久 |
| 任务协调 | 串行 | 父会话管理 | 通过任务列表自协调 |
| 最适合 | 单文件修改、串行工作 | 独立并行任务 | 相互依赖的并行工作 |
| 配置复杂度 | 无 | 最小 | 环境标志 + 显示模式 |
| 最优团队规模 | 1 | 2-5 个工作进程 | 2-7 个队友 |
一个实用的经验法则：如果你能在完全不涉及其他工作进程工作内容的情况下描述每个并行工作进程的任务，那就使用子代理。如果工作进程需要互相提问、共享中间结果或协调修改以避免冲突，那就使用 Agent Teams。
Agent Teams 的真实成本（附美元计算）
成本是采用 Agent Teams 的最大障碍，而标题数字——计划模式下大约 7 倍的 token（code.claude.com/docs/en/costs，2026 年 2 月）——在缺乏上下文的情况下听起来很吓人。这个倍数代表的是使用多个队友的计划模式使用上限，但实际成本会因团队规模、模型选择和任务复杂度而有巨大差异。Anthropic 报告称，Claude Code 用户平均每位开发者每天花费约 6 美元，第 90 百分位为每天 12 美元（code.claude.com/docs/en/costs，2026 年 2 月）。关于 Claude 不同订阅层级和 API 访问的定价详细分析，请参阅 Claude Opus 4.6 定价与订阅详解。
为了让成本更具体直观，以下是基于已验证的 API 定价（claude.com/pricing，2026 年 2 月）的三种常见场景计算。这些计算假设团队负责人使用 Opus 4.6，队友使用 Sonnet 4.5，这是推荐的性价比最优配置。
场景 1：并行代码审查(3 个审查者，约 30 分钟)。单会话对中等规模 PR 的代码审查通常消耗约 200K token（150K 输入，50K 输出），使用 Opus 4.6 成本约 2.00 美元。使用 3 个 Agent Team 审查者——分别负责安全、性能和代码质量——团队负责人消耗约 100K token 用于协调，每个 Sonnet 4.5 审查者消耗约 180K token。总计：约 640K token，混合成本约 4.50 美元。2.25 倍的成本带来了单个审查者会遗漏的三个专业化视角，而且审查者可以实时互相标记发现。对大多数团队来说，额外的 2.50 美元与发布一个安全漏洞的代价相比微不足道。
场景 2：全栈功能构建(前端 + 后端 + 测试，约 2 小时)。单会话功能实现通常消耗 400-600K token（取决于复杂度），使用 Opus 4.6 成本 8-15 美元。使用 3 个专业化队友的 Agent Team——前端、后端 API 和集成测试——Opus 负责人消耗约 300K token，每个 Sonnet 队友消耗约 350K token，总计约 1.35M token，混合成本约 20 美元。2.5-3 倍的成本将 4-6 小时的串行工作压缩为约 90 分钟的并行执行。对于时薪 100 美元的开发者来说，额外的 12 美元 API 成本节省了 300-500 美元的时间成本。
场景 3：竞争性假设调试(3-5 个调查者，约 1 小时)。复杂的 bug 通常需要同时测试多个理论。单会话按方法逐一测试 3 个假设，需要 1-2 小时消耗约 500K token，成本约 10 美元。使用 3 个调查者的 Agent Team，每人追查一个假设，负责人消耗约 200K token，每个调查者约 250K token，总计约 950K token，成本约 13 美元。看似只有 1.3 倍的成本增加——但真正的节省在于实际耗时。三个并行调查者在 20 分钟内找到根因，而不是 90 分钟，而且他们可以实时共享发现，更快排除错误方向。
最有影响力的单一成本优化策略是战略性模型选择。团队负责人应使用 Opus 4.6，因为它需要最强的推理能力来进行任务分解、协调和决策。队友应默认使用 Sonnet 4.5，它提供出色的编码能力，同时输入成本低 60%（3 美元 vs 5 美元/MTok），输出成本低 40%（15 美元 vs 25 美元/MTok）。对于团队中简单的、定义明确的子任务——如运行 linter、格式化代码或搜索模式——队友可以生成自己的 Haiku 4.5 子代理，成本为 1 美元/5 美元每 MTok，形成三级成本层级。关于何时使用 Opus 与 Sonnet 的更深入对比，请参阅我们的 Opus vs Sonnet 模型对比。
除了模型选择外，还有四种额外的成本优化策略可以显著降低 Agent Team 开销。第一，在生成提示中设置明确的范围边界——告诉队友"审查 auth 模块的安全问题"比告诉它"审查整个代码库"消耗的 token 少得多。第二，使用 max_turns 参数限制队友的 API 往返次数，防止失控的智能体消耗无限 token。第三，保持团队精简：2-3 个专注的队友始终优于 5 个以上职责重叠的智能体。第四，对复杂实现使用计划模式——负责人在队友执行前审查拟议的修改，防止代价高昂的返工。如果你运行大量的 Agent Team 工作负载且需要经济实惠的 API 访问，laozhang.ai 等平台以相同的 API 接口提供多种 Claude 模型的有竞争力的定价。
高效 Agent Teams 的提示词模板
一个高效的 Agent Team 会话与一个浪费 token 的会话之间的区别，几乎完全取决于你如何向 Claude Code 描述任务。模糊的指令如"重构用户模块"会产生一个在不明确职责和重复工作中挣扎的团队。有效的生成提示需要明确目标、分配清晰角色、定义范围边界并设置质量标准。以下模板可以直接复制并根据你的具体项目进行调整。
模板 1：并行代码审查(3 个专业化审查者)
Review pull request #47 using a team of 3 specialized reviewers.
Create a team called "pr-47-review".
Reviewer 1 (Security): Review all changes in src/auth/ and src/api/
for authentication bypasses, injection vulnerabilities, and unsafe
data handling. Use Sonnet model.
Reviewer 2 (Performance): Review all changes for N+1 queries,
unnecessary re-renders, missing indexes, and memory leaks. Focus on
files touching database queries and React components. Use Sonnet model.
Reviewer 3 (Code Quality): Review for consistent error handling,
proper TypeScript types, test coverage gaps, and adherence to our
coding standards in CLAUDE.md. Use Sonnet model.
After all reviewers complete, synthesize findings into a single
prioritized report. Flag any conflicts between reviewers'
recommendations.
这个模板之所以有效，是因为它为每个审查者分配了不重叠的领域，指定了模型以控制成本，并在最后包含了汇总步骤。团队负责人负责协调，三个 Sonnet 队友完成详细的审查工作，总成本大约 4-5 美元。
模板 2：全栈功能实现
Implement the user notification preferences feature from issue #234.
Create a team called "notification-prefs".
Teammate 1 (Backend): Create the API endpoints in src/api/notifications/
- GET /api/notifications/preferences (read current prefs)
- PUT /api/notifications/preferences (update prefs)
- Add database migration for notification_preferences table
- Write unit tests for the new endpoints
Use Sonnet model.
Teammate 2 (Frontend): Build the settings UI in src/components/settings/
- Create NotificationPreferences component
- Connect to the API endpoints (coordinate with Backend teammate
for exact request/response shapes)
- Add form validation and loading states
- Write component tests
Use Sonnet model.
Teammate 3 (Integration): After Backend and Frontend complete:
- Write end-to-end tests covering the full flow
- Verify the database migration runs cleanly
- Test error scenarios (network failures, invalid data)
Use Sonnet model. This task is blocked by Teammates 1 and 2.
Use delegate mode. I want to review the overall plan before
implementation begins.
这个模板明确设置了任务依赖（队友 3 被队友 1 和 2 阻塞），请求委托模式让负责人协调而非实现，并告诉队友在 API 契约上进行协调。前端队友知道要向后端队友询问请求和响应的格式，而不是凭猜测。
模板 3：竞争性假设调试
The checkout flow is failing intermittently with a 500 error in
production. Error logs show "connection refused" but only for ~10%
of requests. Create a team called "checkout-debug" with 3 investigators.
Investigator 1: Hypothesis — Database connection pool exhaustion.
Check src/db/pool.ts configuration, look for connection leaks in
the checkout transaction code, analyze connection pool sizing vs
concurrent request volume.
Investigator 2: Hypothesis — Redis session store timeout.
Check src/cache/redis.ts for timeout configuration, look for
blocking operations in the session middleware, verify Redis health
check implementation.
Investigator 3: Hypothesis — Downstream payment API flakiness.
Check src/services/payment.ts for retry logic, look at error
handling for the payment provider webhook, check if circuit breaker
is configured correctly.
Each investigator: Share findings via messages as you go. If you
find strong evidence for your hypothesis, broadcast to the team
immediately. If you can rule out your hypothesis, say so and help
another investigator.
这个模板的关键创新在于明确指示调查者共享发现并互相帮助。这使团队变成了真正的协作调查，而不是三个孤立的工作者。一个调查者排除了自己的假设后，可以立即帮助缩小搜索范围。
模板 4：研究与探索
I need to understand how our authentication system works before
refactoring it. Create a research team called "auth-research".
Researcher 1: Map the authentication flow from login to session
creation. Document every file involved, every middleware touched,
and every database query executed. Output a flow diagram in markdown.
Researcher 2: Identify all places in the codebase that check
authentication or authorization. List every guard, middleware,
decorator, and manual check. Flag any inconsistencies in how
auth is verified.
Researcher 3: Analyze the test coverage for authentication.
Which flows are well-tested? Which have no tests? What edge
cases are missing?
All researchers: Use read-only operations only. Do not modify
any files. Share interesting findings with each other as you discover them.
这个模板将 Agent Teams 用于探索而非实现，关键约束是只读操作。研究团队是开始使用 Agent Teams 最安全的方式之一，因为文件冲突或意外修改的风险为零。
五个要素使生成提示有效：清晰的团队名称用于追踪、具有不重叠范围的明确角色分配、用于成本控制的显式模型选择、定义好的通信预期（何时共享发现、如何协调），以及质量标准或约束（只读、计划模式、阻塞依赖）。当你包含所有五个要素时，Agent Teams 就能持续产出专注且高性价比的结果。
高级模式与最佳实践
当你熟悉了基本的 Agent Team 工作流后，几种高级模式可以解锁更为精密的协调方式。这些模式解决了有经验的用户报告的最常见失败模式，代表着来自实际使用的宝贵经验。
委托模式(Delegate mode) 通过在团队负责人会话中按 Shift+Tab 激活，它从根本上改变了负责人的运作方式。在委托模式下，团队负责人将自身限制为仅使用协调工具——不能编辑文件、运行命令或直接实现任何内容。这迫使负责人将任务分解为清晰、定义明确的工作项并分配给队友，而不是急躁地自己抓取工作。"负责人自己实现而非委派"是最常见的 Agent Team 反模式之一：如果不使用委托模式，能力出众的 Opus 负责人经常会自己开始实现第一个任务，而队友闲置等待，完全违背了团队的初衷。委托模式使这种情况不可能发生，其结果是任务分解和资源利用率持续改善。
计划审批(Plan approval) 为高风险工作增加了关键的质量关卡。当队友以 mode: "plan" 生成时，它们在只读计划模式下运行——可以探索代码库、分析需求和设计实现方案，但在团队负责人明确批准其计划之前不能做出任何修改。队友在计划准备好后调用 ExitPlanMode，这会向负责人发送计划审批请求。负责人审查提议的方案，批准（队友退出计划模式并开始实现）或带反馈拒绝（队友修改计划）。这种模式对于错误修改代价高昂的代码库非常有价值——数据库迁移、公共 API 变更和安全敏感代码都受益于实现前的审查步骤。
钩子质量关卡(Hooks for quality gates) 让你通过在智能体事件响应中执行的 shell 命令来自动化团队级别的质量管控。两个钩子事件对 Agent Teams 特别有用。TeammateIdle 钩子在队友完成一轮并进入空闲状态时触发，这是对队友最近修改运行 linter、类型检查器或测试套件的完美时机。如果钩子检测到失败，反馈会直接返回给队友，让它在负责人认为任务完成之前就修复问题。TaskCompleted 钩子在任务被标记为完成时触发，允许你在达到里程碑时自动运行集成测试或部署预览。钩子将 Agent Teams 从"信任并期望"的工作流转变为"信任并验证"的工作流。
任务依赖设计 决定了队友自协调的有效程度。创建任务时，使用 addBlockedBy 和 addBlocks 参数来表达顺序约束。设计良好的依赖图确保基础工作（数据库迁移、共享类型、API 契约）在依赖工作（UI 组件、集成测试）之前完成。队友会自动遵守这些依赖——在所有阻塞项解决之前不会认领被阻塞的任务。需要避免的错误是创建一个扁平的、无结构的任务列表，其中每个任务都没有依赖关系。没有明确的顺序，队友会竞相认领任务，经常在不稳定的基础上构建，导致返工和浪费 token。
浪费 token 的常见错误值得特别提出，因为它们非常容易犯。对串行任务使用 Agent Teams 是最昂贵的错误——如果每一步都依赖前一步，就没有并行化的好处，而协调开销会以 3-7 倍的成本换来零速度提升。生成太多队友是第二常见的问题：超过 4-5 个活跃智能体经常互相干扰，产生冗余上下文，花在智能体间消息上的 token 超过了并行化带来的收益。一开始就给出过于宽泛的范围意味着队友会花前 10-20 轮探索代码库而不是执行，而这些探索 token 在 5 个智能体之间迅速累积。解决方法是给每个队友一个专注的、边界明确的任务，带有清晰的文件或模块范围。
Agent Teams 故障排除
Agent Teams 引入了单会话和子代理可以避免的协调复杂性，因此了解常见故障模式及其修复方法有助于你在出错时快速恢复，而不是在困惑的智能体上浪费 token。
队友不出现 通常是因为功能标志没有在正确的作用域中设置。如果你将 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 设置为 shell 变量，它只适用于该终端会话——其他终端或新会话不会有这个设置。最可靠的修复方法是将标志添加到 ~/.claude/settings.json，使其全局持久化。同时验证你的 Claude Code 版本是最新的，运行 claude --version，因为 Agent Teams 需要 2026 年 2 月 5 日之后发布的版本。如果你使用分屏模式，通过 tmux ls 确认 tmux 实际在运行——如果未检测到 tmux，Agent Teams 会静默回退到进程内模式。
队友之间的文件冲突 发生在两个智能体试图同时修改同一文件时。症状通常是一个队友的更改被另一个队友的写操作覆盖，或者在 git status 中出现合并冲突。预防策略是在生成提示中分配清晰的文件或目录所有权——"队友 1 负责 src/api/，队友 2 负责 src/components/"——这样它们永远不会触碰相同的文件。如果确实发生了冲突，团队负责人应暂停两个队友、手动解决冲突或指示一个队友重新读取文件并进行调和，然后以更严格的边界恢复工作。设置在冲突更改时失败的 pre-commit 钩子可以及早发现这个问题。
团队负责人自己实现而非委派 是一种行为问题，Opus 负责人开始自己编写代码而不是将工作分配给队友。这违背了团队的目的，经常导致队友闲置消耗 token 却无所事事。修复方法是按 Shift+Tab 激活委托模式，将负责人限制为仅使用协调工具。如果你在会话中途发现这种模式，也可以明确指示负责人："不要自己实现任何内容。将这些分解为任务并分配给队友。"
孤立的 tmux 会话 在 Agent Team 会话异常结束时累积——网络断连、终端崩溃或强制退出负责人。这些孤立进程继续在后台运行，消耗系统资源但不再连接到任何协调基础设施。运行 tmux ls 列出所有会话，使用 tmux kill-session -t {name} 清理不再需要的会话。一个实用的做法是在团队名称中包含日期或任务名，这样你可以轻松识别哪些会话已经过时。
任务状态滞后 发生在队友完成工作但任务列表没有立即反映更新的情况下。这可能导致负责人认为任务仍在进行中，或其他队友避免认领后续工作。根本原因通常是队友完成了实现但未调用 TaskUpdate 将任务标记为已完成。修复方法是在生成提示中明确说明："完成任务后，始终调用 TaskUpdate 将其标记为已完成，然后调用 TaskList 检查下一个可用任务。"将此纳入你的标准提示模板可以防止问题再次发生。
立即开始使用 Agent Teams
开始使用 Agent Teams 不需要理解每个高级模式——你可以用最简配置就能高效工作，在遇到具体需求时再学习细节。以下清单可以在 5 分钟内让你从零开始完成第一个高效的 Agent Team 会话。
从这个快速配置开始：将 "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" 添加到 ~/.claude/settings.json 的 env 部分。如果你想要分屏显示（3 个以上智能体时推荐但不是必需的），安装 tmux。然后打开 Claude Code 并描述一个可并行化的任务——从低风险的事情开始，如代码审查或代码库探索，而不是关键功能实现。观察团队负责人如何分解任务、生成队友并协调它们的工作。
推荐的学习路径可以系统性地建立信心。首先，尝试一个 2 个智能体的研究团队，以只读模式探索你的代码库——这在零风险的情况下引入团队动态。接下来，尝试一个 3 个智能体的代码审查团队，每个审查者专注于不同的质量维度（安全性、性能、可维护性）。然后尝试一个小型功能实现，2-3 个队友在不同模块上工作。最后，当你熟悉了协调机制后，再尝试委托模式、计划审批和钩子等高级模式。
对于通过 API 运行大量智能体工作负载的团队，成本管理成为一个实际关注点。前面描述的模型混合策略（Opus 负责人 + Sonnet 队友 + Haiku 子代理）是最有效的优化。通过 laozhang.ai 等平台获取 API 访问可以为 API 消耗量大的团队提供额外的成本效率。将你的实验预算集中在理解哪些任务真正受益于 Agent Teams，哪些更适合单会话或子代理——这种理解带来的回报远超初始学习成本。
常见问题
Agent Teams 能同时操作同一个文件吗？ 可以，但不应该。两个智能体同时写入同一文件会造成竞态条件，一个智能体的修改会覆盖另一个的。在生成提示中为每个队友分配明确的文件或目录所有权来防止这种情况。
团队负责人在会话中途崩溃怎么办？ 队友会继续独立运行但失去了协调中心。它们会完成当前任务但无法接收新的分配。你可以重启 Claude Code 并通过任务列表接管孤立的队友，或者清理 tmux 会话重新开始。
应该使用多少个队友？ 2-3 个专注的队友始终优于更大的团队。超过 4-5 个活跃智能体时，协调开销和文件冲突的风险增长速度超过了生产力收益。C 编译器项目使用了 16 个智能体，但是分布在大约 2,000 个会话中——而非 16 个智能体同时运行（anthropic.com/engineering，2026 年 2 月）。
Agent Teams 支持 MCP 服务器吗？ 支持。队友从项目设置中继承 MCP 服务器配置，因此团队负责人可用的任何 MCP 工具对队友也同样可用。这意味着智能体可以在团队会话中使用自定义工具、数据库连接和外部服务集成。
有没有办法恢复被中断的 Agent Team 会话？ 目前，Agent Teams 不支持原生会话恢复。如果会话被中断，~/.claude/tasks/{team-name}/ 中的任务列表会持久保存，显示哪些任务已完成、进行中或待处理。你可以启动新会话、引用现有任务列表，并从最后完成的检查点恢复工作。