Claude Code的agent teams，真的很强么？

Claude Code的agent teams模式，适用场景不多，token消耗数倍，实际成果不稳定。

最近Claude的Agent Teams很火。

我试了一下，发现适合ClaudeCode Teams模式开发的任务很少。

它看起来很高级、很牛，一个lead agent领着几个职能agent分工协作，把活儿干了，好像一个分工明确，组织有效的Agent团队一般。

其实，目前它更像是一个有趣的实验，而非实用稳定的服务。

首先是贵。

当单agent串性工作相比，Agent Teams token消耗量可能是其4x～15x，堪称无法预料的烧钱机器。

因为它要消耗大量的token用于沟通协调，重复的上下文输入也是成倍增加。

单一agent单点失效后，连锁debug会引发链式的质量退行，甚至崩溃。

其实，这个事情经不起推敲，你稍微琢磨一下就知道，在目前的技术水平下，用好Agent Teams是门槛极高的事情。

关键是适合这种模式的任务少之又少。

它需要极其复杂的协调机制、明确的分工、清晰的兜底责任划分、干净彻底的任务解耦。

这样的项目实在少之又少。

譬如SaasS开发中，开发到一半发现需要新字段，数据库迁移和数据回填是常见操作，而且是典型串行的任务。

Agent Teams模式下，这类任务就不得不block，处理不好整个Agent Teams就卡死了。

还有框架版本大升级，也不适合Agent Teams模式。

Breaking changes 往往是牵一发动全身的——路由改了影响所有页面，API 变了，影响所有请求处理。

这种升级是长链式依赖，串行做反而更可控。

还有，2000行以下代码的任务、高度依赖人机交互反馈的任务，譬如算法调优，前端界面调优，使用Agent Teams都是费力不讨好。

Agent Teams做涌现性的发散的任务适合，广撒网的。

聚焦收敛的任务容易吃力不讨好，白白消耗巨多token。

随着软件开发接近尾声收敛的时候，你需要的是一条清晰的逻辑链往下走。每一步紧扣上一步的结论，不断收窄范围。

这时候多个 agent 协作反而互相干扰——它们各自收敛到不同的方向，Lead 还得花大量精力去调和和裁决，最后的协调成本可能比让一个 agent 从头到尾想清楚还大。

这跟人类团队是一样的。

头脑风暴的时候人越多越好，越杂越好。

写最终方案的时候，一个人闷头写出来的东西往往比产出的更连贯。

大多数开发任务，做好需求prd和规范spec设计，用好任务依赖拆分，用单一agent串行工作，即可高质量，也能高效率。

Agent Teams并不是一无是处。

发散型任务可以用Agent Teams。

先让一群 agent 把可能性空间探索够，你从中选定方向，然后一个 agent 把方案写扎实，最后再用 Cursor /CC把项目实现出来。

Agent Teams模式是CC一次有趣的尝试，其用户价值仍需时日。对于大多数开发者而言，不值得一试。

---

原文链接：https://mp.weixin.qq.com/s/idfR9NbLTAfKBb0Z5q-wpA

来源：XT