08 · 多个 AI 怎么协作

翔宇在做一个前后端分离的项目时遇到了一个场景：后端改了接口字段名，前端不知道，继续用旧的写了半天——最后集成时全对不上，返工。当时用的是 SubAgents，前端和后端各一个子代理。问题出在哪？它们互相不认识，没法通信。这就让翔宇开始想：如果给它们加一个群聊和一块共享白板，事情会不会不一样？——翔宇

要点速览

1. 你将理解 SubAgents 在什么场景下会力不从心——需要互相通信和共享状态的任务
2. 你将理解 Agent Teams 比 SubAgents 多了什么——一块共享白板（TaskList）和一个群聊（SendMessage）
3. 你将理解为什么共享任务列表是 Agent Teams 的灵魂，没有它多个 Agent 就是各干各的
4. 你将理解这个功能为什么是实验性的，以及什么时候该用什么时候不该用

1. 从一个搞不定的场景开始

我们一起想一个场景。

你在开发一个用户认证功能。需要三件事同时进行：

后端——实现 JWT 认证 API（登录、注册、刷新 token）。 前端——实现登录页面和注册页面。 测试——等前后端都完成后写集成测试。

上一篇讲了 SubAgents。用它来做会怎样？

你同时派三个子代理——一个做后端，一个做前端，一个等着写测试。听起来挺好。但很快你会发现三个问题：

前端需要问后端。 前端开发到一半，需要知道注册接口返回什么字段格式。但子代理之间不能互相通信——它们只和你（主对话）沟通。前端得回来问你，你再去问后端，后端回答你，你再转告前端。你变成了传话筒。

后端的变更前端不知道。 后端把 userName 改成了 name，前端继续用旧字段名写代码——最后集成时对不上，返工。

测试不知道什么时候能开始。 它怎么知道前后端都完成了？只能定期问你：「完了吗？」

这三个问题有一个共同的根源：SubAgents 之间没有沟通渠道，也没有共享的任务状态。 它们是三个互不相识的人，各自在各自的房间里工作，唯一的联系人是你。

那怎么办？

2. 试着加一个群聊

最直接的想法——给它们一个能互相发消息的渠道。

前端需要问后端接口格式？直接发消息问。后端改了字段名？直接通知前端。不需要通过你传话。

这解决了前两个问题。但第三个问题——测试怎么知道什么时候能开始——光有通信还不够。

想象一下：三个人有了群聊，但没有任务清单。前端做完了自己的事，不知道接下来该干什么——因为没有一个地方告诉它「还有哪些任务没人领」。后端做完了 API，不知道测试是不是可以开始了——因为它不知道前端完成没有。

你作为「项目经理」必须手动跟踪每个人的进度、手动分配下一个任务、手动判断依赖关系是否满足。你从「传话筒」升级成了「人肉看板」。

所以光有通信不够。还需要一块共享白板。

3. 再加一块共享白板

在群聊的基础上，加一块所有人都能看到的白板——上面写着所有任务、每个任务的状态（待做 / 进行中 / 已完成）、任务之间的依赖关系。

现在事情变了。

后端做完了 API，在白板上把任务标记为「已完成」。前端也做完了，同样标记。白板自动检测到：集成测试的两个前置依赖都满足了——测试任务从「被阻塞」变成「可以开始」。

不需要你去判断「后端做完了吗？前端做完了吗？可以开始测试了吗？」——白板自动处理。

成员完成当前任务后，自动看白板，领取下一个状态为「待做」、没人认领、依赖已满足的任务。不需要你逐个分配。

🎯 一句话理解 Agent Teams = SubAgents + 共享任务列表 + 互相通信。那块「共享白板」（TaskList）和那个「群聊」（SendMessage）就是 SubAgents 和 Agent Teams 的全部差异。

4. 共享任务列表为什么是灵魂

我们刚才的探索过程其实已经揭示了答案：通信解决了「你问我答」，但共享任务列表解决了协调。

🧠 底层逻辑 没有 TaskList 时，所有协调都经过你（中心化）——你是瓶颈。有了 TaskList，成员自己查看全局状态、自己领取任务、自己判断依赖——协调变成分布式的。你从调度员变回了决策者。这和软件团队用 Jira / Linear 的逻辑完全一样——看板存在的意义不是好看，是让每个人都能自主行动。

任务列表有三个关键能力：

状态追踪——每个任务有 pending（待做）、in_progress（进行中）、completed（已完成）三个状态。任何成员更新状态，所有人都能看到。

依赖管理——任务之间可以设置依赖。「集成测试」依赖「后端 API」和「前端页面」——只有两个都完成了，测试才变成可领取的。

自动领取——成员完成当前任务，自动查看列表领取下一个。不需要你逐个分配。

5. 团队的组织结构

Agent Teams 的结构简单直接。

Lead——就是你的主对话窗口。你是项目经理，负责创建团队、定义任务、做关键决策。

Teammates——团队成员。每个是一个独立的 Claude 实例，拥有完整的 1M 上下文窗口。可以读写代码、执行命令、互相通信。

推荐团队规模是 3 到 5 个 Teammates。

太少（1-2 个）——并行优势不明显，不如用 SubAgents 更便宜。太多（6 个以上）——协调成本急剧上升。每个人发一条广播消息，就要被其他所有人处理。七个人的群聊比三个人的群聊嘈杂得多，而且每个 Teammate 都是一个完整的 Claude 实例，成本线性增长。

🎨 打个比方 如果 SubAgents 是你派出去的快递员——各跑各的路线，只和你联系——那 Agent Teams 就是你组建的施工队。施工队里有水电工、瓦工、木工，他们在同一个工地上，看同一张施工图纸（TaskList），遇到问题当面沟通（SendMessage）。你作为工头不需要每件事都亲自盯，只需要定好计划和处理冲突。

6. 通信的几种方式

Teammates 之间的通信不只是「发消息」那么简单。

直接消息——发给特定的人。前端问后端接口格式，直接发，不打扰其他人。

广播消息——发给所有人。场景：发现了一个关键 Bug，所有人需要暂停。但要谨慎——五人团队广播一次等于发五条消息，成本乘五。

Idle 状态——Teammate 发完消息后会进入空闲状态。初看你可能会慌：「怎么停了？」不是。就是「说完了，等回复」。像你发了一条微信，手机放下等回复。给它发消息就能唤醒。

Shutdown 协议——任务全部完成后关闭 Teammates 释放资源。不是直接杀进程——先发 shutdown_request（「活干完了」），Teammate 回 shutdown_response（「好的」或者「等一下还有事没收尾」）。这给了它收尾的机会。

7. 一个完整的流程

把前面的概念串起来走一遍。

你说：「帮我组建一个团队开发用户认证功能。」

Claude（作为 Lead）做了这些事：

创建团队 auth-feature。创建三个任务——后端 JWT API、前端登录注册页面、集成测试（依赖前两个）。添加两个 Teammate——backend-dev 和 frontend-dev。分配任务——任务 1 给后端，任务 2 给前端。任务 3 暂时没人领（被阻塞了）。

两个 Teammate 并行工作。

frontend-dev 做到一半需要确认字段格式，直接给 backend-dev 发消息。后端回复。前端继续。

backend-dev 做完，在白板上标记完成。frontend-dev 也做完，标记完成。

系统检测到集成测试的两个依赖都满足了，任务变成可领取。某个 Teammate 自动领取，开始写测试。

全部完成后，Lead 发 shutdown，团队解散。

💬 通俗讲 整个过程你只说了一句话。Claude 自己完成了团队创建、任务拆解、人员分配、进度协调。你可以随时插手——调整优先级、修改需求——也可以让它自己跑完。

8. 两种显示模式

多个 Teammate 同时工作时，怎么看它们的状态？

In-Process 模式——所有 Teammate 在你的主终端里运行。按 Shift+Down 在不同 Teammate 之间切换查看。简单，不需要额外工具，但同一时间只能看一个。

tmux/Split-Pane 模式——每个 Teammate 占一个独立的终端窗格。可以同时看到所有人的实时输出。需要安装 tmux 或使用 iTerm2，但可视化程度高得多。

熟练之后推荐用后者——看着三四个 Claude 同时在不同窗格里写代码，颇有「指挥大军」的感觉。

9. 什么时候用，什么时候不用

这个判断很重要，因为 Agent Teams 的成本显著高于 SubAgents。

用 Agent Teams：多个独立模块需要并行开发且需要互相沟通（前后端分离）；需要多个专家协作且需要交换信息（安全审查 + 性能优化 + 测试）；复杂 Bug 的多假设调查（一个查缓存、一个查并发、一个查数据一致性，最后比较哪个假设成立）。

用 SubAgents：快速聚焦的单项任务（「帮我查一下这个文件」）；多个任务互相独立不需要通信（搜索三个不同模块，各搜各的）；成本敏感的场景。

什么都不用：简单的单步任务。改个变量名，问个问题，直接在主对话里做。

⚡ 速记 需要互相通信 → Agent Teams。不需要通信 → SubAgents。不需要子任务 → 直接做。

10. 实验性功能——需要知道的事

Agent Teams 目前是实验性功能，默认关闭。使用前需要设置环境变量：

CLAUDE_CODE_EXPErimeNTAL_AGENT_TEAMS=1

为什么是实验性的？因为多个 Claude 实例并行工作、互相通信、共同编辑代码库——这个场景的复杂度很高。

🔍 深入一步 几个可能遇到的问题：文件冲突——两个 Teammate 同时编辑同一个文件，可能互相覆盖（解决方案是让每个人负责不同的文件或目录，或用 Worktree 给每人独立工作目录）；任务协调的边界情况——Teammate 卡住了怎么办、误判完成了怎么办；成本不可控——五个人并行消耗 token，如果有一个陷入死循环，成本快速积累。

Anthropic 把它做成实验性而非默认开启，说明他们对多 AI 协作的可靠性还没完全满意。翔宇的建议：在个人项目上先试，了解能力和边界。不要在生产环境的关键任务上贸然使用。

11. 回到最初的问题

退一步想：为什么我们需要多个 AI 协作？一个超级强大的 AI 不就够了吗？

答案和人类团队存在的理由一样——上下文窗口是有限的。

一个 Claude 实例有 100 万 token 的上下文。听起来大，但一个复杂项目——前端、后端、数据库、测试、配置——加起来容易超过这个限制。而且第 2 篇和第 5 篇讲过：上下文越大，注意力越分散，质量越下降。一个 Claude 同时处理前端和后端，不如两个 Claude 各专注一个领域。

多代理的本质不是「算力不够所以分工」——它是认知资源的分治策略。每个代理专注于问题的一个切面，用自己全部的上下文深度去处理，然后通过通信把结论共享。

这和人类团队的逻辑完全一样：不是一个人不够聪明才需要团队，而是一个人的注意力有限——你不可能同时在脑子里装着前端的状态管理和后端的数据库事务和测试的覆盖率。

SubAgents 是「串行的分治」——主对话拆分子任务，各个击破。Agent Teams 是「并行的协作」——多个实例同时工作，通过共享状态和通信协调。前者适合互不依赖的任务，后者适合互相关联的任务。两者不是替代关系，是互补关系。

12. 自检问题

这篇我们一起探索了一个问题：当子任务之间需要互相沟通和共享状态时，SubAgents 就不够了，需要 Agent Teams。

费曼检验时间：

• 有人说「Agent Teams 就是更多的 SubAgents」。你能解释这个理解缺了什么吗？Agent Teams 比 SubAgents 多了哪两个关键机制？
• 共享任务列表解决了什么具体问题？如果只有通信能力没有共享任务列表，会出什么情况？
• 你的朋友要用 Agent Teams 做一个简单的代码搜索任务。你会怎么建议他？
• Agent Teams 是实验性功能。你觉得默认关闭而不是默认开启，背后的考量是什么？