前言
Claude Code 有个老问题：单 Agent 模式下，随着任务复杂度增加，上下文窗口迅速膨胀，压缩后性能明显退化
跑到一半 Agent 突然"忘了"之前的约定，开始做一些莫名其妙的事情。
相比之下，GPT-5.2 在上下文管理和压缩损耗方面确实更稳，我一度切换到 Codex 作为主力。
但随着Claude 发布了 Opus 4.6的同时带来了 Agent Team功能 让多个 Claude Agent 自主协作完成复杂任务。
体验了一段时间后，我又切回了 Claude。
Agent Team——从传话筒到自主沟通
当任务涉及多模块重构、全栈功能开发、或需要多视角审查时——比如前端要问后端一个字段名，如果用传统 SubAgent（Task 工具），这个问题得先回到主 Agent，主 Agent 再转发给另一个 SubAgent，回答再原路返回。
主 Agent 成了传话筒，上下文被大量无关细节占满，信息还可能在转达中失真。
这正是 Agent Team 要解决的问题：
让 Agent 之间直接沟通，不再经过传话筒。
什么是 Agent Team？
Agent Team 是 Claude Code 随 Opus 4.6 于 2026 年 2 月 5 日发布的实验性功能，由 Anthropic 官方博客正式宣布。它允许一个 Lead Agent 协调多个 Teammate Agent，以团队形式协作完成复杂任务。
各 Agent 拥有独立上下文窗口，通过共享任务列表和消息系统实现自主协作。
需要说明的是，多 Agent 协同沟通本身并不是新概念——AutoGen（微软）、LangGraph（LangChain）、CrewAI 等框架早已实现了 Agent 间的直接通信和任务协调。
Agent Team 的独特之处在于：它是 Claude Code CLI 的原生功能，无需安装额外框架、无需定义工作流，设置一个环境变量就能用。
目前该功能处于 preview 阶段，需要通过环境变量手动启用：
bashexport CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
或者在~/.claude/settings.json加入以下配置
json "env": {
"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
}
核心架构：Lead-Teammate 模式
实际用下来，Agent Team 的架构可以拆成四个部分：
-
Team Lead（团队领导）：负责理解用户意图、拆解任务、分配工作、监控进度。它是用户与团队之间的唯一接口——我只需要描述需求，Lead 就会自己拆任务分下去。
-
Teammates（团队成员）：每个 Teammate 是一个独立的 Claude 实例，拥有自己的上下文窗口，专注于被分配的具体任务。
-
Task List（任务列表）：共享的任务看板。Lead 通过
TaskCreate创建任务，Teammate 通过TaskUpdate更新进度，所有成员通过TaskList查看全局状态——就像团队用的 Kanban，我能随时看到每个 Agent 干到哪了。 -
Mailbox（消息邮箱）：异步消息系统。Agent 之间通过
SendMessage发送私信或广播消息，实现点对点或一对多的通信。这是和 SubAgent 最大的区别——消息不再需要经过主 Agent 中转。
简单概括这个设计：
- Lead 负责"做什么"
- Teammate 负责"怎么做"
- Task List 让所有人知道全局进度
- Mailbox 让 Agent 之间不用再打传话筒
Agent Team vs 传统 SubAgent：传话筒升级为自主通信
如果你用过 Claude Code 的 SubAgent（Task 工具），可能会问：这和 Agent Team 有什么区别？
通过下面的图例，来简单展示下
| 维度 | 传统 SubAgent | Agent Team |
|---|---|---|
| 通信方式 | 只能向主 Agent 单向汇报（传话筒） | Agent 之间可直接交流 |
| 上下文 | 独立上下文，结果返回给主 Agent | 独立上下文，完全自主 |
| 拓扑结构 | 星型（主 Agent 中转一切） | 网状（带 Lead 节点，非完全去中心化） |
| 并行能力 | 受限于主 Agent 调度 | 真正的并行执行 |
| 适用场景 | 简单的子任务委派 | 需要 Agent 间频繁协调的复杂任务 |
Agent Team 工作流程
一个典型的 Agent Team 工作流程：
-
创建团队：用户向 Claude Code 描述任务，Lead Agent 判断需要组建团队，自动创建 Teammate 并分配角色（如 researcher、coder、reviewer）。
-
分配任务：Lead 将大任务拆解为多个子任务，分配给不同的 Teammate。官方建议每个 Teammate 分配 5-6 个任务以保持较好的工作节奏。
-
协作执行：各 Teammate 并行工作，遇到需要协调的问题时通过
SendMessage直接沟通——不需要经过 Lead 传话。 -
完成汇总：Teammate 通过
TaskUpdate标记任务完成，Lead 监控全局进度，最终汇总结果交付给用户。
整个过程中，Lead 更像是一个项目经理——它不需要亲自写每一行代码，而是把精力放在任务拆解、进度跟踪和质量把控上。
实际使用感受
说实话，第一次看到多个 Agent 在终端里同时工作、互相发消息协调的时候，体验挺新鲜的。 你可以通过下面的方式快速的创建一个团队(前提: 升级到Claude Code CLI 2.1.34+)
shell组件一个团队, 包括资深前端, 后端与DBA 描述你的需求和团队成员需要做的事情
我用 Agent Team 做了一个全栈功能开发——用户资料页的头像上传功能。Lead 协调了 3 个 Teammate：
- 前端 Agent
- 后端 API Agent
- 数据库 Agent
整个过程中，Agent 之间的通信方式让我印象比较深。SendMessage 支持两种模式：
点对点私信（message）——两个 Agent 直接对话，不经过 Lead：
前端 Agent -> 后端 Agent：「用户头像字段叫什么？返回的是 URL 还是 Base64？」
后端 Agent -> 前端 Agent：「字段是
avatar_url，返回 CDN 的 URL，格式是https://cdn.xxx/avatars/{user_id}.webp」
这些对话完全在 Teammate 之间完成，Lead 不需要介入，也不会占用 Lead 的上下文。如果是传统 SubAgent，这个简单的字段确认就得在主 Agent 那里绕一圈——主 Agent 的上下文白白多了一轮无关对话。
广播消息（broadcast）——一条消息同时通知所有 Agent： 如果一个功能非常重要，那么这时候任意Agent均可以调用广播，通知包括Lead在内的所有Agent
后端 Agent -> 全体广播：「注意：文件上传接口从
/api/upload改为/api/v2/files，所有涉及上传的地方请同步更新」
前端 Agent 和数据库 Agent 同时收到，各自更新引用。不需要 Lead 逐个转达，也不会有人漏掉。
当然，Agent Team 目前也有一些明显的不足：
- 不支持嵌套团队
- Lead 角色固定不可转移
- 有用户反馈在复杂软件开发场景下，Agent 之间的协调容易崩溃，消耗大量 token 却无法完成任务
任务粒度的把握也需要经验——太小则协调开销超过收益，太大则 Teammate 工作太久缺乏检查点。
Agent Team很好，但也很贵
聊 Agent Team 绕不开一个现实问题：它不便宜。
.webp)
高成本并非 Agent Team 独有的问题。 无论是用 Agent Team 还是用传统 SubAgent，只要是多个 Agent 并行工作，每个 Agent 都是独立的 Claude 实例、拥有独立的上下文窗口，核心成本结构是相似的。
Agent Team 相比 SubAgent 的额外开销主要来自 Mailbox 通信和共享 Task List 的协调机制，但是也带来了更强的能力，在差不多的成本情况下，我倾向于选择Agent Team
简单说：多 Agent 本身就贵，不管你用什么模式。Agent Team 和 SubAgent 的成本差距没有想象中那么大。
个人建议是把 Agent Team 留给真正需要 Agent 间频繁协调的复杂任务。 如果子任务之间相互独立、不需要沟通，用 SubAgent 就够了；如果任务本身是单线程的，普通单 Agent 模式最合适。
总结
Agent Team 我个人觉得比较有价值的点，就是那个通信拓扑的升级——从 SubAgent 的传话筒模式，到 Teammate 之间的直接对话。
点对点私信解决技术细节，广播消息同步全员，Lead 不再被细节淹没。对于需要多角色频繁协调的任务，这个改进是比较实在的。
什么时候值得用 Agent Team？我的一些想法是：当你的任务较为复杂，天然需要多个角色频繁沟通——比如前后端联调、多模块重构、需要同时跑测试和修代码的场景。
反过来，如果子任务之间互相独立不需要沟通，SubAgent 足矣；单人能搞定的，别强行组队。