本文梳理 Claude Code 新增的 Agent Team 功能的核心机制，并与既有 Sub-Agent 体系做结构性对比。目标读者：对 AI 工程架构感兴趣但不一定有编程背景的人。

背景

Claude Code 的 Sub-Agent 能力已经相对成熟——给它一个任务，它会在独立进程中并行处理多个子任务，完成后把结果汇回主对话。这套机制在大多数场景下够用。

但有一类任务它处理得不好：子任务之间存在强依赖关系，或需要实时协商。比如你想让 AI 同时负责写文档和写测试，而测试必须基于最新的接口定义——这时候两个 Sub-Agent 的孤立执行就会出问题。它们各自为政，没有任何横向沟通通道。

Agent Team 就是针对这个问题设计的。

架构设计

Agent Team 的核心抽象由四个组件构成：

Main Agent（队长）：解析用户意图，拆解任务，创建并分配队友，最终汇总交付。

Team Members（队友）：每个队友在独立的上下文窗口中运行，持有自己的”大脑”。这意味着队友 A 写了什么，队友 B 不会自动感知——这是刻意的设计，目的是防止上下文污染。

Mailbox 系统：队友之间显式通信的唯一渠道。需要共享信息时，必须主动发消息；系统不会自动广播状态。

共享任务看板：所有队友可见的任务列表。任务状态在这里更新，队长和队友都可以认领或查看。

协作流程：

1
2
3
4
5
用户描述需求
  → 队长拆解为子任务 → 创建队友并分配任务
    → 队友并行执行 → 通过 Mailbox 互相通信
      → 任务依赖自动阻塞（C 等 A 完成后再开始）
        → 队长汇总 → 交付用户

这套设计的一个值得关注的细节是用户可达性：用户可以直接和任意队友对话，而不是只能通过队长中转。这在 Sub-Agent 体系里是做不到的——Sub-Agent 对用户完全不可见。

与 Sub-Agent 的结构性差异

拓扑结构是最根本的区别。

Sub-Agent 是星型拓扑：主 Agent 是唯一的调度中心和信息枢纽，所有 Sub-Agent 只跟它通信，彼此之间没有连接。这意味着主 Agent 的上下文会成为瓶颈——所有的进展汇报最终都要流回来。

Agent Team 是网状拓扑：成员之间可以直接通信，任务可以自行认领，不需要每个决策都经过队长。队长负责战略层面的协调，不参与每一次细节对齐。

其他几个关键差异：

维度 Sub-Agent Agent Team
生命周期 一次性，任务结束即销毁 持久运行，可接收新指令
通信机制 无横向通信 Mailbox 显式通信
上下文管理 结果摘要仍会流回主对话 各队友上下文独立，不污染主对话
任务依赖处理 需要用户手动排序 系统自动阻塞依赖任务

一个工程级验证案例

最能说明问题的是 Anthropic 安全研究员 Nicholas Carlini 在 2026 年 2 月发表的工程博客。他用 Agent Team 指挥了 16 个 Claude 实例并行工作，从零构建了一个 C 编译器：超过 10 万行代码，通过数百个测试用例。

做法是把编译器拆成词法分析器、语法解析器、类型检查器、代码生成器等模块，分配给不同的队友。各模块的接口定义通过 Mailbox 流转——词法分析器定好 Token 格式后，语法解析器立即收到通知并开始对接。这种协作方式在 Sub-Agent 体系下需要人工介入，在 Agent Team 里自动发生。

这个案例的意义不在于”16 个 AI 一起工作”这个数字，而在于：AI 之间的接口协商和冲突解决，已经可以在没有人工干预的情况下完成。

选择标准

判断用 Sub-Agent 还是 Agent Team，问两个问题就够了：

  1. 子任务之间需要互相沟通吗？
  2. 子任务数量超过 3 个且存在依赖关系吗？

两个都是否定答案，用 Sub-Agent——更快、更省 token。有一个肯定答案，用 Agent Team。

现有局限

这个功能目前是实验性的，默认关闭。已知限制：不支持会话恢复、不支持嵌套团队、费用比 Sub-Agent 高。

开启方式：在 ~/.claude/settings.json 里添加对应配置项，或在启动前临时设置环境变量。

结语

从 Sub-Agent 到 Agent Team，变化的不只是功能。Sub-Agent 体系下，你仍然是调度中心；Agent Team 体系下，你是目标的定义者，执行层完全交给团队自治。

这个转变对用户意味着什么？你需要更清晰地定义任务边界，而不是更清晰地描述执行步骤。一个写得好的目标描述，比一份详细的操作流程更有价值。这可能是使用 Agent Team 最需要适应的地方。