Claude Code Agent Team 实验阶段:Subagent 该用,团队先按住
Claude Code 的 Agent Team 已经发布几个月官方文档至今仍把它标成 experimental。这不是巧合。我们的判断是现在该上的是 SubagentAgent Team 先按住。但 Anthropic 把它留在实验阶段而不急着强推这件事本身可能比功能本身更值钱——这是他们对agent 工作流真正瓶颈的产品级表态。反方先讲清楚看到 “Agent Team” 这个名字本能反应是多 agent 并行 加速研发。再加一条更隐蔽的逻辑——Anthropic 既然做了肯定有他们的理由跟一波准没错Cursor 已经有 Cloud AgentsCline 在卷 multi-agent 编排LangGraph / CrewAI / AutoGen 把协作框架做了一遍不上车就掉队。反方有它的道理但漏洞也明显它把并行和协作等同起来了。Subagent 已经能解决并行——三个子 agent 拆任务跑、独立上下文回汇报wall time 接近最慢的那一支。Agent Team 真正多出来的不是并行而是队员之间的对等通信、共享任务列表、Lead 审批工作流。换句话说Team 解决的是协作开销并不是生成速度。这层差别在算账时会变得很要命。论据一实验阶段的警告不是营销话术Agent Team 默认是关闭的必须设CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS1才能启用。这不是新功能的低调发布惯例因为官方文档把已知问题列得很清楚in-process 队员无法/resume续会话、任务状态会延迟、shutdown 缓慢、不能把队员升为 Lead、队员不能再开自己的 team。GitHub Issue tracker 里还有更硬的伤——#57037同一条消息里多次 spawn 子 agent 会触发权限连锁失败#40459自 v2.1.84 起子 agent 不再加载 CLAUDE.md项目约定全部丢失#19077子 agent 无法再嵌套子子 agentOOM 崩溃在某些场景必现。把这三条对照 Subagent 的成熟度看Subagent 在 changelog 里已经迭代了几十个版本/agentsLibrary、frontmattermcpServers加载等接口都在收敛。一个稳定到默认开启、一个实验到默认关闭——产品状态自己已经把答案说清楚了。如图所示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不是 generationAddy 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 进编排的方向卷方向可能就错了。