Agent Teams 什么时候比子代理更好用？

导读

子代理只能单向汇报，不能横向讨论；当一个任务需要在几个分工之间来回对齐，而不是各干一段再汇总时，就该换成 Agent Teams 的平级协作。代价是协调开销和更笨重的流程。

市面上能实现「多代理平级协作」的产品不止一个：Claude Code 把它叫 Agent Teams，Kimi 叫 Agent Swarm，还有一些办公向产品直接做成开箱即用的「专家团」。底层逻辑都是：多个独立子代理持有各自的上下文，通过某种机制协调分工。

本章以办公向产品的专家团为主叙事，Claude Code 作为参照

Claude Code 的 Agent Teams 和办公向产品里的专家团，是同一个逻辑的两种产品实现：前者更接近开发场景，后者更接近办公场景。本章以专家团为主叙事，Claude Code 作为参照。

和子代理类似，Claude Code 的 Agent Teams 默认关闭，需要改配置文件、配环境变量；办公向产品里的专家团则是开箱即用的功能。找到你想用的专家团，点“召唤”，用自然语言描述任务，团长会自动拆解、分配、执行、交付。

它解决什么问题：单窗口爆炸和子代理的局限

子代理解决的是“中间过程污染主对话”的问题。它像一个外包工人：你派它出去干活，它把摘要交回来，然后消失。三个子代理就是三个各送各的外卖骑手，彼此不认识，也不直接通信。

但子代理有一个结构性局限：它只能单向汇报，不能横向讨论。 基于这个特点，可以让子代理完成很多特殊的任务。但也正因如此，子代理无法胜任多个角色互相质疑、交换中间发现、根据对方的结论调整自己的方向的任务。

专家团的思路是：把一个大目标拆成多个角色，每个角色在自己的上下文里工作，同时能够互相通信、协调进度。

你可以理解为 AI 的一场角色扮演：有专家团长和不同角色的团员。团员各有不同的立场，互相配合或者对抗，由团长从中协调，通过博弈最终产生“深思熟虑过的结果”。

注意：任务一旦开始你通常是没有中途参与的机会的

专家团会按照预先的剧本各自发言，不会像普通对话那样随时停下来等你补充；而你的补充通常只能通过团长转达。

Claude Code Agent Teams 有什么不同：网状直连模式

差异	办公向产品的专家团	Claude Code Agent Teams
队员之间通信	经由团长中转	可直接发消息，不经主管
你与谁对话	只能和团长对话	按上下键切到任意队员，直接下指令
共享任务列表	没有	有，任务卡待处理、进行中、已完成，依赖完成即解锁

• 专家团像传统项目经理制：团长拆活、分配、收口；

• Claude Code 的 Agent Teams 像扁平小组：队员之间可以直接对话，主管只做派单和整合。

• 两者共同的核心是：多个代理各自独立上下文，不把过程噪音灌进主对话。

什么时候用：这些子任务之间有没有通信需求。

• 任务能拆成互不干扰的独立块，每块只需要一个结论 → 子代理就够了，它 Token 消耗更少、简单且稳定；
• 任务需要多角度对齐、相互论证、竞争假设排查，或者角色之间必须交换中间发现才能推进 → Agent Teams 和专家团才有意义。

常见用例：

• 研究和审查：多个角色同时调查问题的不同方面，然后分享并质疑彼此的发现；
• 新模块或功能：各角色负责独立部分，但需要接口对齐和互相评审；
• 竞争假设调试：并行测试不同理论；
• 跨层协调：前端、后端、测试各由不同角色负责。

反过来说：顺序依赖的任务、大量耦合的工作，用 Agent Teams 只会制造协调开销。

两个特别说明

不要用专家团做小任务。 专家团相对笨重。我的实测感受是：它更像一个节省操作时间的工具。如果你开多个窗口、来回复制消息，也能达到类似效果；专家团的优势是你提前把工作流写好了，省了来回复制粘贴。

不要指望团员继承你之前的对话历史。 每个团员启动时只拿到团长分配的任务描述，看不到你和团长之前聊了什么。因此任务描述必须自包含，任务需要的背景信息都要写在里面。

一个推荐妙用：狼人杀——竞争假设排查

同时派三个角色，给它们互相矛盾的理论：一个咬定网络超时，一个咬定并发死锁，第三个专门挑战前两个的论点。每个角色的任务不是证明自己对，而是试图证伪别人。

这种按顺序调查的结构存在锚定效应。 一旦一个理论被探索过，后续调查会偏向它。多个独立调查者主动互相证伪，存活下来的理论更可能是真正的根因。