Claude Code 的 Agent Team 已经发布几个月，官方文档至今仍把它标成 experimental。这不是巧合。我们的判断是：现在该上的是 Subagent，Agent Team 先按住。但 Anthropic 把它留在实验阶段而不急着强推这件事本身，可能比功能本身更值钱——这是他们对"agent 工作流真正瓶颈"的产品级表态。
反方先讲清楚
看到 "Agent Team" 这个名字，本能反应是：多 agent 并行 = 加速研发。再加一条更隐蔽的逻辑——Anthropic 既然做了，肯定有他们的理由，跟一波准没错；Cursor 已经有 Cloud Agents，Cline 在卷 multi-agent 编排，LangGraph / CrewAI / AutoGen 把协作框架做了一遍，不上车就掉队。
反方有它的道理，但漏洞也明显：它把"并行"和"协作"等同起来了。Subagent 已经能解决并行——三个子 agent 拆任务跑、独立上下文回汇报，wall time 接近最慢的那一支。Agent Team 真正多出来的不是并行，而是队员之间的对等通信、共享任务列表、Lead 审批工作流。换句话说，Team 解决的是"协作开销"，并不是"生成速度"。这层差别在算账时会变得很要命。
论据一：实验阶段的警告不是营销话术
Agent Team 默认是关闭的，必须设 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 才能启用。这不是新功能的"低调发布"惯例，因为官方文档把已知问题列得很清楚：in-process 队员无法 /resume 续会话、任务状态会延迟、shutdown 缓慢、不能把队员升为 Lead、队员不能再开自己的 team。GitHub Issue tracker 里还有更硬的伤——#57037 同一条消息里多次 spawn 子 agent 会触发权限连锁失败；#40459 自 v2.1.84 起子 agent 不再加载 CLAUDE.md，项目约定全部丢失；#19077 子 agent 无法再嵌套子子 agent，OOM 崩溃在某些场景必现。
把这三条对照 Subagent 的成熟度看：Subagent 在 changelog 里已经迭代了几十个版本，/agents Library、frontmatter mcpServers 加载等接口都在收敛。一个稳定到默认开启、一个实验到默认关闭——产品状态自己已经把答案说清楚了。
如图所示，Subagent 是星形拓扑，N 个子 agent 各自独立、只跟主 agent 通话，消息边数 O(N)；Agent Team 在加上对等消息后变成完全图加共享任务列表，消息边数 O(N²) 还要再加邮箱协调。两者的工程复杂度根本不是一个量级。
论据二：协作开销不是免费的，按 7 倍走
Hindsight 团队 2026 年 5 月那篇评测里给了一个我们一直没忘的数：Agent Team 在 plan mode 下 token 消耗约为 Subagent 的 7 倍。这数字看起来夸张，拆开就合理——共享任务列表要被每个队员反复读写，对等消息把上下文放进每个队员的输入，Lead 审批工作流再叠一层 plan 往返。每多一个角色，开销不是线性增长。
3 个角色是临界点：Subagent 仍接近线性增长，Agent Team 已经把开销拉开一倍多；到了 5 角色，Hindsight 实测出来约 7 倍，和我们图里的曲线吻合。对个人订阅者，这个倍数把月度配额砸出一个洞；对团队订阅，问题转成"并行省下的 wall time，是不是值这 7 倍 token 钱"。绝大多数日常开发任务的回答都是不值——一个 PR 开三个 reviewer subagent 跑安全 / 性能 / 测试覆盖三视角，已经能把 review 时间压到 1/3 而不烧多余 token。Team 真正能发挥的是 5+ 角色、需要互相辩论的复杂场景，比如多假设并行 debug、跨模块重构、架构评审——这些才值得为对等消息买单。
论据三：真问题是 review，不是 generation
Addy Osmani 在《The Code Agent Orchestra》里的那句话值得抄下来："The bottleneck is no longer generation. It's verification." 模型已经能把代码量打出来，工程师卡的是审阅、对账、跑测、验证。多上一个 agent，生成提速 2 倍，review 工作量也跟着翻倍。如果没有强自动化质量门——hooks、plan approval、测试覆盖率红线——多 agent 反而把 reviewer 变成瓶颈。
Anthropic 在 Agent Team 文档里特意暴露了 TeammateIdle、TaskCreated、TaskCompleted 这几个 hooks，方向是对的：把质量门做进协作框架本身。但工具链还没成熟到让普通团队接得住——hooks 怎么写、plan approval 怎么定阈值、什么样的 review 自动化能信赖，这些都还是开放问题。所以它停在实验阶段，不是 Anthropic 偷懒，是他们也清楚 review 那侧的工具链没跟上。
重申与边界
我们的判断不变：Subagent 现在就该用——上下文隔离 + 角色分工是被验证过的工程套路，star topology 容易理解、token 开销可控；Agent Team 先关注、不押注，等到 CLAUDE.md 上下文回归、permission cascade 修掉、官方把"实验"标签摘掉再上。边界值得说清：5+ 角色、需要队员之间真互动的场景（多假设 debug、跨域架构评审）确实是 Agent Team 的发挥位，但这种场景每个团队一个月遇不到几次，没必要为此把全部工作流重构一遍。
最后一个信号是写给所有还在做 agent harness 的人的：Anthropic 把 Agent Team 留在实验、不强推、还公开列 known limitations，这本身是产品级表态——他们已经默认 agent 工作流的真瓶颈在 verification 而不是 generation，押的方向是"分工 + 质量门"，不是"更多 agent + 更长上下文"。如果我们做的工具链还在往"再多塞几个 agent 进编排"的方向卷，方向可能就错了。
