Claude Code 现已支持 agent teams（群组）。 不再是单个 agent 顺序地处理任务，一个 lead agent 可以委托给多个 teammates 并行工作------进行研究、调试和构建，同时相互协调。在您的 settings.json 中启用 agent teams 来试试看。如果您一直在通过 Conductor、Gas Town 或类似工具进行 multi-agent orchestration 的实验，这个消息会让您兴奋不已。
社区将这些模式称为 swarms（群组）------协调的 AI agent 团队，每个都有专门的角色，通过结构化通信并行工作。从开发者在 Claude Code 二进制文件中发现 feature-flagged 功能开始，通过 subagents 和 bash 脚本构建变通方案，现在这已经是一个一等特性。TeammateTool、基于 inbox 的通信、tmux 分割窗格------所有东西都在这里了。
这很重要，因为它与我们大多数人一直在使用的 single-agent 模型有着根本不同的架构。如果您一直在关注从 conductor 到 orchestrator 的转变，或者试验并行 agent workflows，agent teams 就是这些想法变得具体的地方。
为什么 multi-agent coordination 很重要
Single-agent 模型有一个众所周知的失败模式。您让 Claude 做一些复杂的事情------比如重构三个服务的认证------它可能在上下文退化之前完成 60%。第 2 步的细节模糊到第 5 步中。您 /clear 并重新开始。重复直到沮丧。
Swarms 背后的核心见解很简单：随着上下文的扩展，LLM 的性能会下降。 这不仅仅是关于达到 token 限制，而是上下文窗口中的信息越多，模型就越难专注于现在重要的事情。将项目经理的战略笔记添加到正在修复 CSS bug 的上下文中会损害性能。
人类团队以类似的方式工作。我们不让后端工程师参加前端代码审查。我们不会在每条 Slack 线程中抄送整个公司。专业化是为了专注。
Multi-agent patterns 将此形式化。通过给每个 agent 一个狭窄的范围和清晰的上下文，您可以在每个领域内获得更好的推理、独立的质量检查、阶段之间的自然检查点，以及当一个 agent 失败时的优雅降级。测试 agent 的上下文中有测试，而不是三小时的规划讨论。安全审查者不需要通过性能优化笔记。
警告是这仅在任务正确范围化时才有效。"给我构建一个应用程序"会消耗 tokens 而 agents 徒劳无功。"根据此规范实现这五个明确定义的 API 端点"会产生好的结果。
Agent teams 是什么
架构很简单。一个 Claude Code 会话成为 team lead 。它生成 teammates------每个都是一个完整的、独立的 Claude Code 实例，有自己的大型 token 上下文窗口。有一个共享的任务列表，具有依赖关系跟踪，一个基于 inbox 的消息传递系统用于 agent 间通信，teammates 可以在完成任务时自己认领工作。
| 组件 | 角色 |
|---|---|
| Team lead | 创建团队、生成 teammates、协调工作 |
| Teammates | 在分配的任务上工作的独立 Claude Code 实例 |
| Task list | 具有依赖关系跟踪和自动解除阻止的共享工作项 |
| Mailbox | agent 之间的直接消息传递------不仅仅是向 lead 报告 |
这与 Claude Code 现有的 subagents 不同。Subagents 是向单个父级报告结果的专注工作者------它们不能相互交谈。Agent teams 是真正的协作------teammates 分享发现、挑战彼此的方法并独立协调。权衡是 token 成本------每个 teammate 都是一个独立的 Claude 实例。
| Subagents | Agent teams | |
|---|---|---|
| 上下文 | 自己的窗口；结果返回给调用者 | 自己的窗口；完全独立 |
| 通信 | 仅向主 agent 报告 | Teammates 直接相互消息传递 |
| 协调 | 主 agent 管理一切 | 具有自我协调的共享任务列表 |
| 最适合 | 只关注结果的专注任务 | 需要讨论和协作的复杂工作 |
| Token 成本 | 较低 | 较高------每个 teammate 都是一个独立的实例 |
当您需要快速、专注的工作者时使用 subagents。当 teammates 需要分享发现、相互挑战并独立协调时使用 agent teams。
Claude Code 现已支持 agent teams（研究预览版）
不是单个 agent 顺序地处理任务，lead agent 可以委托给多个 teammates 并行工作，进行研究、调试和构建，同时相互协调。
今天就试试看... pic.twitter.com/vi7lUJDOTi
--- Lydia Hallie ✨ (@lydiahallie) 2026年2月5日
入门
通过在设置中添加实验标志来启用 agent teams：
json
// settings.json
{
"env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
}然后用自然语言告诉 Claude 您想要什么团队。它从那里处理生成和协调：
objectivec
我正在设计一个 CLI 工具，帮助开发者在其代码库中跟踪 TODO 注释。
创建一个 agent team 从不同角度探索这个问题：一个 teammate 负责 UX，
一个负责技术架构，一个扮演唱反调的角色。Claude 创建具有共享任务列表的团队，为每个角度生成 teammates，让它们探索问题，并综合发现。Lead 的终端列出了所有 teammates 及它们正在处理的工作。
您也可以明确团队结构：
创建一个有 4 个 teammates 的团队来并行重构这些模块。
每个 teammate 使用 Opus。在哪些方面表现出色
这是一个有效的模式：并行探索真正有价值且 teammates 可以很大程度上独立操作的任务。
用于调试的竞争假设。 生成五个 teammates，每个调查一个关于为什么应用程序在一条消息后退出的不同理论。让它们相互交谈来反驳彼此的理论，就像科学辩论一样。这确实比顺序调查更好，顺序调查会受到锚定的影响------一旦您探索了一个理论，随后的调查就会偏向它。多个调查者进行对抗性辩论更快地收敛到根本原因。
使用不同镜头的并行代码审查。 一个 teammate 负责安全影响，一个检查性能影响，一个验证测试覆盖率。单个审查者倾向于一次专注于一种类型的问题。将审查标准拆分为独立领域意味着每个领域同时得到彻底关注。
跨层功能工作。 跨越 frontend、backend 和 tests 的变更------每个由不同的 teammate 拥有。而不是一个 agent 在层之间上下文切换，三个 agents 并行工作，完全专注于其领域。
研究和探索。 多个 teammates 同时调查不同的方法，分享它们发现的内容，并收敛到最佳前进路径。研究发现直接流入实现上下文------没有电话游戏。
控制团队
您通过 lead 的终端与 agent teams 交互。一些在实践中重要的控件：
显示模式
两个选项。In-process （默认）：所有 teammates 在您的主终端内运行。使用 Shift+Up/Down 选择一个 teammate 并输入以直接向它们发送消息。按 Enter 查看 teammate 的会话，Escape 中断它们的回合，Ctrl+T 切换任务列表。适用于任何终端。
Split panes：每个 teammate 通过 tmux 或 iTerm2 获得自己的窗格。您同时看到每个人的输出，并点击窗格直接交互。在设置中或按会话设置：
json
{
"teammateMode": "tmux"
}或为单个会话覆盖：
bash
claude --teammate-mode in-process计划批准
对于有风险的工作，要求 teammates 在实施之前先计划。Teammate 在只读模式下工作，直到 lead 批准它们的方法：
生成一个架构师 teammate 来重构认证模块。
要求它们在进行任何更改之前获得计划批准。如果被拒绝，它们会修改并重新提交。您可以使用标准影响 lead 的判断："仅批准包含测试覆盖的计划"或"拒绝修改数据库架构的计划"。
委托模式
按 Shift+Tab 将 lead 限制为仅协调------生成、消息传递、关闭 teammates 和管理任务。不接触代码。这停止了一个常见问题：lead 分心并自己实现事情，而不是等待 teammates。
直接 teammate 交互
每个 teammate 都是一个完整的 Claude Code 会话。您可以向其中任何一个直接发送消息以提供额外指令、提出后续问题或重定向其方法------无需通过 lead。
任务管理
共享任务列表协调整个团队的工作。任务有三种状态：pending、in progress 和 completed。任务可以依赖于其他任务------具有未解决依赖关系的 pending 任务在那些依赖完成之前不能被认领。当阻止任务完成时，自动解除阻止发生。
Lead 可以显式分配任务，或者 teammates 可以在完成时自己认领下一个未分配、未阻止的任务。任务认领使用文件锁定来防止竞争条件。
Teams 和 tasks 本地存储：
ruby
~/.claude/teams/{team-name}/config.json # Team metadata + members
~/.claude/tasks/{team-name}/ # Task listTeammates 可以读取配置文件来发现其他团队成员。
关闭
要求 lead 关闭特定的 teammates------它们可以批准或拒绝请求并提供解释。要清理整个团队：
bash
/cleanup始终使用 lead 进行清理。Teammates 不应该运行它，因为它们的团队上下文可能无法正确解析，可能会使资源处于不一致状态。Lead 检查活跃的 teammates，如果仍在运行则失败，因此先关闭它们。
这里有管理学的类比
我不断回到这一点：使某人成为强大的工程经理的技能直接转化为有效的 agent orchestration。Agent teams 使这更加明确。
任务大小很重要。 太小而协调开销占主导地位。太大而 teammates 工作时间太长而没有检查，冒着浪费精力的风险。最佳点是产生清晰交付成果的自包含单元。每个 teammate 有 5-6 个任务保持每个人的生产力，并让 lead 在某人被卡住时重新分配工作。
文件所有权很重要。 两个 teammates 编辑同一个文件会导致覆盖。分解工作，使每个 teammate 拥有不同的文件集。与人类团队相同的边界设置以避免合并冲突。
上下文加载很重要。 Teammates 自动获取您项目的 CLAUDE.md、MCP 服务器和技能，但它们不继承 lead 的对话历史。在生成提示中包含特定于任务的详细信息：
arduino
生成一个安全审查者 teammate，提示为："审查 src/auth/ 处的认证模块
是否存在安全漏洞。专注于令牌处理、会话管理和输入验证。
应用程序使用存储在 httpOnly cookies 中的 JWT 令牌。报告任何带有
严重性评级的问题。"简报越具体，输出越好。和往常一样------但现在您是为一个团队而不是单个 agent 编写简报。
需要注意什么
这是实验性的。粗糙的边缘是真实的，值得了解。
Lead 有时会实现而不是委托。 告诉它等待："在继续之前等待您的 teammates 完成他们的任务。"或使用委托模式（Shift+Tab）将 lead 限制为仅协调工具。
In-process teammates 没有会话恢复。 /resume 和 /rewind 不会恢复 in-process teammates。恢复后，lead 可能会尝试向不再存在的 teammates 发送消息。生成新的。
任务状态可能滞后。 Teammates 有时未能将任务标记为完成，阻止依赖任务。检查工作是否实际完成并推动 lead 或手动更新。
每个会话一个团队，没有嵌套团队。 Lead 一次管理一个团队。Teammates 不能生成自己的团队或 teammates。只有 lead 管理团队。这是故意的------防止无限递归、失控的 token 成本和失去人类监督。在开始新团队之前清理当前团队。
Token 成本随 teammates 扩展。 每个 teammate 都是一个具有自己上下文窗口的独立 Claude 实例。对于常规任务，单个会话更具成本效益。Multi-agent patterns 在更大的、可并行的工作上得到回报------而不是修复拼写错误。
Split panes 需要 tmux 或 iTerm2。 在 VS Code 的集成终端、Windows Terminal 或 Ghostty 中不支持。默认的 in-process 模式在任何地方都有效。
权限从 lead 传播。 所有 teammates 从 lead 的权限设置开始。如果 lead 使用 --dangerously-skip-permissions 运行，所有 teammates 也是如此。您可以在生成后更改各个 teammate 模式，但不能在生成时设置每个 teammate 的模式。
关闭可能很慢。 Teammates 在关闭之前完成当前的请求或工具调用，这可能需要时间。
警告
观看 agents 并行工作有一种诱人的特质。活动指标令人印象深刻------每小时提交、并行任务完成、接触的代码行数。
但活动并不总是转化为价值。
Multi-agent systems 的风险在于它们使快速生成大量代码变得容易。这些代码仍然需要正确、可维护并且真正解决问题。我看到开发者失去了情节，花更多时间配置 orchestration patterns 而不是思考他们在构建什么。
让问题指导工具，而不是相反。 如果专注会话中的单个 agent 更快地让您到达那里，请使用它。如果您需要并行专家，请使用 agent teams。Agent teams 增加协调开销并使用明显比单个会话更多的 tokens。当 teammates 可以独立操作时，它们效果最好。对于顺序任务、同文件编辑或具有许多依赖的工作，单个会话或 subagents 更有效。
使用 Compound Engineering 最大化您的 swarms
如果您想要围绕 agent teams 的更结构化的工作流，Every 的 Compound Engineering Plugin 可能值得一看。它是一个 Claude Code 插件，添加了专门的审查 agents 和 plan → work → review → compound 循环，设计围绕每个工程工作单元应该使后续单元更容易的想法。
直接在 Claude Code 中安装：
bash
/plugin marketplace add https://github.com/EveryInc/compound-engineering-plugin
/plugin install compound-engineering与 agent teams 最相关的部分：/workflows:plan 将功能想法转化为详细的实施计划（正是使 agent 委托工作良好的那种前期规范），/workflows:review 在合并之前运行 multi-agent 代码审查（安全、性能、架构和复杂性------每个都有自己的专门审查者），/workflows:compound 记录学习，以便未来的 agents 从过去的工作中受益。
最后一部分是有趣的部分。插件的哲学------80% 的规划和审查，20% 的执行------清晰地映射到使 agent teams 有效的内容。您的规范越好，agent 输出越好。您将学习形式化的越多，每个后续 agent 徒劳的时间越少。这与我用 AGENTS.md 和持久上下文描述的复合动态相同，但打包成可重复的工作流。
如果您不专门使用 Claude Code，它也可以与 OpenCode 和 Codex 一起使用（实验性地）。
入门------我会这样做
如果您是 multi-agent coordination 的新手，从小处着手。
从研究和审查开始。 具有清晰边界且不需要编写代码的任务------从三个角度审查 PR、研究库、使用竞争理论调查 bug。这些展示了并行探索的价值，而没有并行代码更改的协调复杂性。
然后尝试跨层功能。 Frontend、backend 和 tests 各由不同的 teammate 拥有。清晰的边界、清晰的交付成果。
然后扩展到更大的重构。 多个服务、共享设计阶段后的并行实现。这就是时间压缩变得戏剧性的地方------可能需要数天顺序工作的东西压缩成几个小时的并行执行加上审查。
核心技能不是写更少的代码。它是将问题分解为 agent teams 可以执行的结构------知道要构建什么、正确性意味着什么以及如何验证结果。实施越来越变成一个充分精确规范的问题。
这就是当 agents 实际可以协调时的 agentic engineering 的样子。协调 AI agent systems 的架构就在这里。明智地使用它。
完整的 Claude Code agent teams 文档有完整的设置和使用指南。
我在我的 Elevate newsletter 和我的 O'Reilly 书籍 Beyond Vibe Coding 中撰写关于 agentic coding workflows 的演变。如果您正在试验 agent teams 或 multi-agent workflows，我很乐意听到什么对您有效。