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