前言
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 阶段，需要通过环境变量手动启用：
export CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
或者在~/.claude/settings.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+)
组件一个团队, 包括资深前端, 后端与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&w=2048&q=75)
高成本并非 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 足矣；单人能搞定的，别强行组队。