Appearance
智能体团队 (Agent Teams) 与多智能体架构
智能体团队 (Agent Teams) 在子智能体 (sub-agent) 模式的基础上,进一步引入了平等的点对点通信 (peer-to-peer communication)。团队成员不仅只是向主管进行汇报,他们还可以互相发送消息、质疑彼此的发现,并通过协作来逐步达成共识。

这是一项实验性功能。 可以在环境变量或 settings.json 中配置 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 来开启。
核心组件
| 组件 | 角色 |
|---|---|
| 团队主管 (Team Lead) | 主要的 Claude Code 会话节点。负责建立团队、生成并分发任务、统筹汇总成果,以及在工作结束时解散团队。 |
| 团队成员 (Teammates) | 独立的 Claude Code 实例,各自拥有独立的上下文窗口。它们负责从共享任务池里领取任务。 |
| 任务清单 (Task List) | 位于 ~/.claude/tasks/{team-name}/ 目录下的共享队列。任务包含 pending (待处理) / in_progress (处理中) / completed (已完成) 等状态,并且可以声明依赖关系。一旦前置依赖项处理完毕,被阻塞的任务就会自动解锁。 |
| 信箱 (Mailbox) | 支持点对点 (message) 和全服广播 (broadcast) 的通讯方式。广播的 token 开销与团队规模成正比——请谨慎使用。 |
重要提示: 团队成员并不会继承主管的对话历史。它们仅仅通过启动时的初始提示词 (spawn prompt) 获取信息。因此,主管必须在最开始就提供所有必要的上下文:项目架构、约束条件、可用的工具、目标交付物以及输出模板。
子智能体 (Sub-Agents) vs 智能体团队 (Agent Teams)
| 特性 | 子智能体 (Sub-Agents) | 智能体团队 (Agent Teams) |
|---|---|---|
| 通讯机制 | 仅向主管汇报 | 成员之间可以互相发消息 |
| 协调方式 | 集中式(由主管控制) | 分布式(点对点协作) |
| 适用场景 | 并行执行任务,汇报结果 | 协同调查案件,方案辩论 |
| Token 开销 | 中等 | 高昂 |
| 系统复杂度 | 较低 | 极高 |
| 最佳用武之地 | 流水线作业,高噪音的操作 | 竞争性假设求证,多角度代码审查 |
一句话决策法则: 如果员工互相之间不需要交流 → 用子智能体。如果员工需要讨论并相互质疑 → 用智能体团队。
经典协作模式
1. 竞争性假设求证 (Competing Hypotheses)
应用场景: 当故障根本原因极度不明朗、存在多种推理流派、且害怕单股调查路线产生“先入为主”偏差时使用。
运作机制:
- 将每一个底层假设分别指派给一名独立的团队成员。
- 要求成员们不能仅仅为了证明自己是对的,更要尽力去证伪其他人的猜想。
- 最终能存活下来、解释所有报错症状且顶住了所有交叉火力质疑的假设,即为最终结论。
实战案例: 一场导致会话丢失、API 降速、数据泄漏的连环雪崩事故,其背后的诱发原因可能是由于 4 个互相纠缠的 bug:数据库连接池太小、Redis 断线重连没处理好、抓取订单时发生 N+1 查询风暴、无隔离机制的缓存条件读写冲突竞争。你可以分别指派一名“会话侦探”、“数据库侦探”、“缓存侦探”和“架构侦探”作为并发成员。他们各自独立调查,互通有无,并相互拆台。
为何奏效: 避开了让人极度痛恨的“只查到一个说得过去的 bug 就收工”的敷衍。辩论机制会无情过滤掉弱假设,倒逼浮现出整个完整的雪崩事故链路。
最佳用处: 生产环境突发事故扑火、复杂的性能倒退追踪、以及任何存在着交织影响因素的巨型灾难。
2. 多重并发审查 (Parallel Review / Multi-Angle Code Review)
应用场景: 当一个拉取请求 (PR) 或是核心代码变动,需要从完全不同的维度去进行独立评估时。
常规小队配置:
- 安全审查员:专盯漏洞、输入合法性校验、身份鉴权机制
- 性能审查员:看重算法复杂度、资源闲置损耗、查询命中效率
- 测试审查员:审阅覆盖盲区、极端边缘场景、代码倒退回归风险
每个人都在平行宇宙并行干活。若出现跨界连环事故(例如:一个安全大漏勺同时也会狂吃性能资源),就会通过成员间的高频发信交流浮出水面。
为何奏效: 单个评审人在评审时潜意识里肯定会有不同维度的权重偏差。这种按职能挂载专职审查员的操作,能确保没有哪个核心防线会被系统性地漏掉。
3. 模块划江而治 (Module Ownership)
应用场景: 一个大功能不可避免横跨了多个不同的模块(前端、后端、数据库、测试套件),如果要并行硬推很容易搞出无休止的合并冲突。
核心机制:
- 任务依赖锁: 任务通过明确声明前置条件进行串联;只有上游做完了,下游才会动工(例如:测试必须等着前端画完骨架)。
- 文件包产到户: 每个人认领绝不重叠交叉的代码文件领地;而涉及到三不管地带的共享接口层,则单独再指定专人去主刀。
- 自动解锁: 一旦卡脖子的依赖项宣告竣工,所有被冻结阻塞的下游任务将自动解锁并被各认领人顺手带走。
为何奏效: 它的逻辑是用“文件边界”的围墙去硬物理隔离出了各路开发的兵道,避免了多人同时抢着写同一个块区的流血合并惨案 (merge conflicts)。
4. 方案批准上马 (Plan Approval)
应用场景: 对于那些极高危的任务——例如认证模块大重构、数据库表结构连根拔起迁移、核心服务底层重写——在动第一行代码前,必须拿到设计图纸的过审御批。
工作流:
- 架构师成员交出一份完整的图纸规划——纯方案和设计,半行代码都没有。
- 团队主管拿着预设的“过放要求死刑线 (approval criteria)”去审阅评估。
- 只有顺利盖过章拿了通行证的方案,才能下发并进入到“实施 (implementation)”环节。
请务必在主管的提示词中设好这类验收死标准,例如:
- “只有在规划书里写明了完整测试大修方案的才能准许通过。”
- “任何企图妄动、且要求横加修改数据库核心主表字段的图纸,一律直接枪毙退回。”
为何奏效: 确立了“在写字前必须过脑子先全盘想清楚”的硬道理,而不是一句空话。这直接物理防杀掉了一大批事后发现方向全错从而导致返工重写的高昂悲剧。
最佳实践指南
架构团队设计
- 开局灌满上下文。 团队成员在出生时只带有那一句可怜的拉起指令。你务必要在其中塞满详尽的项目地基架构、各种清规戒律、能够动用的工具火力库、总体方向标以及所有的输出排版模板。
- 恰到好处的任务颗粒度。 切得太碎:成员们互相哔哔沟通开会的精力成本,将彻底盖过双线并行的红利。切得太大:任务黑盒运行时间过长,中间无回传监控档案。比较健康的数值是,给每个干活的马仔下发 5 到 6 项任务,每一项任务都必须有个能看见摸得着的实打实交付物(比如写一个函数代码、一个测试文件、或者一份分析报告)。
控制擦枪走火
- 严防死守文件冲突。 指派工作时切莫重叠文件。涉及到双边共享的公共接口领地一定要分配给某一人专管;一切的根基前提是“兵马未动,粮草(接口契约)先行”。
- 强力的人类督军。 永远别心大地让这些机器团队自己在后台大撒把跑大长途。请勤动手检查其进度,若发现大家都不懂交流沟通,请亲自上手注入强制大家交头接耳相互确认的特使任务,对于跑偏路线的人更要手起刀落地直接拉回。
- 掌控好主将的节奏。 若有必要,请对主将耳提面命下达最死板的指示:“老老实实给我等着!等下面所有的打工仔把活全交齐了之后,你再去做全盘总结并给我决定下一步大动作,否则哪都不许去。”
上兵伐谋的进阶之路
初涉水时,请务必先从那些“只读、写不坏”的破事开始练手:找 Bug 排查命案现场、深水区技术前沿调研、帮着 Review 一下 PR 或设计长文。这些局的边界划得很死,打群架的优势一目了然,还没有并发互篡代码的炸库风险。等你在指挥大兵团作战的微操走位极其顺溜之后,再去真刀真枪接管“模块划江而治”以及“方案批准上马”这种大型深水区操作。
关于性能支出与钱包开销账
拉起一支多智能体机器军团,必将带来复合型的惊人性能叠加和昂贵成本账:
| 成本源头 | 具体影响 |
|---|---|
| Token 放大乘数 | 是单干智能体会话的 15 倍左右 |
| 单次出勤开销 | 每次拉起特工都需要:环境载入 + 执行跑团 + 汇总回传 |
| 跨网交流通讯税 | 随队伍人员扩列及扯皮频次呈大爆炸式递增 |
| 调试查错灾难级 | 因为行为极其不可捉摸(非确定性),排雷必须完全依赖全链路超级生产追溯 |
| 走投无路风险 | 跑到一半想强行刹车就等同丢掉全盘努力;强行要求通过渐进分批交付来对冲风险 |
能帮你心安理得花掉这笔巨资的理由:
- 所要办的差事,通过发散型横向勘察能在品质上捞回巨大优势——重大事故排查溯源、多方假设互驳修 Bug、多重维度的毒辣设计文案审核。
- 任务复杂度极其变态但做成后的回馈价值高绝,所能拉升提档出来的极致代码质量,完全足以支付其天价 Token 印钞费。
- 团队和企业为了在组织架构层面能够独立管理各自负责的代理机队阵列运维权限而强行实施组织级物理隔绝割裂。
最高军规铁律:
- 强行能单兵扛的局绝不拉满编大队起调子。 只有真正遭遇架构深水区的实质性死锁瓶颈时,再祭出这支吞金神兵。
- 能塞“工具”的事,绝对不塞“新兵仔”。 工具永远才是能低耗且最快拓宽边界大扩容火力的微型最小单位。
- 选对一头极其精悍生猛的“主将大模型”,永远比你瞎拼人数去硬堆出更多的垃圾 Token 开销来得更是上策!
- 多智能体军团最大的存在意义与统治力精髓在于:用沙箱物理彻底硬隔离出无污染的清爽上下文环境,并以多路并发狂飙战术暴力执行——而非单纯去搞出那一套花里胡哨空谈炫技、却烂泥扶不上墙的极其花哨表面大架构破迷宫。
- 退一万步来讲,天底下最极致的大美架构,永远是那些极其极其平凡且仅用能最低配简陋代价搞定惊天难题的大道至简系统!