第 5 课 · 多智能体协作：给团队请一个总监

🎯 学完这一课，你将能够

• 理解为什么第一个该养的 Bot 是「总监」，并按社区惯例完成总监的设置
• 说清多智能体协作的四块拼图：分工、通信、交接、上报
• 用「按业务域切」和「花钱隔离」两条经验，给你的 Bot 团队划出合理的分工边界

🤔 开始之前，先想想

• 第 4 课结束时你手里已经有两三个 Bot 了。可当 Bot 多到五六个，「能力」反而不是问题——那新的问题会是什么？
• 两个 AI 在云端各自干活，它们怎么知道对方在干什么？靠你来回传话吗？

这一课讲的就是：Bot 从「几个工位」变成「一支团队」的那条线，怎么连起来。

一、从「一件事」到「一个摊子」

先对个表。入门篇（第 2 到第 4 课）解决的是「一个 Bot 干一件事」；从这一课开始的进阶篇，解决的是「一群 Bot 干一个摊子」。橙皮书的原作者说得很直白：这也是 Grok Bot 和上一代 agent 拉开代差的地方。

上一代 agent 工具里，「多智能体」多半是你手动编排的流程图：谁先跑、结果传给谁，都得你来设计。而在这里，协作是自发发生的——下面你会看到几个具体的画面。

二、总监模式：Chief of Staff

当你有三五个以上的 Bot，最大的问题就不再是能力，是调度：这个活该派给谁？总不能每次都让你自己在脑子里过一遍花名册。

于是社区里人人都在做的第一件事，就是把第一个 Bot 设置成 Chief of Staff（幕僚长/总监）：

1. 置顶； 2. 命名成真人名； 3. 所有任务无脑丢给它。

它的日常工作长这样：你发一句「研究一下最近的 AI 趋势，写封邮件发出去」，它回你一句「研究分给 Barry，写邮件分给 Cindy」，然后自动拆解、派发、追踪进度。你面对的始终只有一个对话框，复杂度全部沉到水面之下。

体会一下这句话的分量：你不需要知道团队里有谁、各管什么——你只需要认识总监一个人。这跟现实里的管理是一回事：好老板不亲自排班。

三、群聊：它们真的会互相说话

这是整本橙皮书里最让人觉得「时代变了」的画面之一。你把几个 Bot 拉进同一条对话后，它们会自发地互相发消息。

一个社区里流传很广的例子：让写代码的 Bot 开发一个功能，它会主动去给内容 Bot 发消息：「老板前几天在 X 上发的需求，上下文发我一下。」没人教它这么干——任务交接、上下文传递、进度同步，全部发生在你看不见的后台。

再配合云端共享的工作环境，协作顺滑度远超预期：一个 Bot 登录过的网站，另一个接手时不用重新登录。工作环境是全队共用的，不是每个员工一间锁着门的办公室。

四、分工的学问：按专线，不按工具

官方推荐的分工方式是按「专线（lane）」划分：收件箱管理、开支报销、招聘、修 bug、日常运营，一条线一个专家。实践中有两条经验值得记住：

• 按业务域切，不按软件切。「负责邮件的 Bot」是好设计，「负责 Chrome 的 Bot」不是——工具只是手段，职责才是边界。道理很简单：你的业务不会因为换个浏览器就变样，但按软件切的岗位会。
• 花钱的事单独隔离。支付相关的活固定交给一个专门的 Bot，授权范围最小化，出了问题也最容易定位。这和财务制度里「出纳与会计分设」是一个思路。

五、官方自己的演示：一个 Bug 的旅程

光说原则有点抽象，看一段官方公告里信息量最大的实况——一次真实的多 Bot 接力（据 FoneArena、Techstrong 转述的官方口径）：

工程线的 Bot 在产品界面里复现一个 bug，接着建一张工单，然后把问题转交给负责修复的调试 Bot。

这条链子很短，但把多智能体协作的三件事都说清楚了：

1. 发现问题的 Bot 和解决问题的 Bot 是两个不同的专家——「复现」和「修复」被拆成了两个岗位； 2. 它们之间的交接物是一张工单，不是一段聊天记录——交接有载体、可追溯、丢不了； 3. 全程没有人在场，你只在最终结果那里出现。

其他官方内部部署也是同样的形状：销售 Bot 过夜研究潜在客户、准备好跟进话术等老板早上过目；运营 Bot 自动处理 Gmail 里收到的发票；CRM 在通话结束后自动更新记录。

至于协作机制本身，官方的原话是这样的：Bot 之间可以自主互发消息、在同一线程里共享上下文；当多个项目重叠时，它们会在同一个账号或项目上自动保持对齐，「不需要用户在对话之间复制信息」；把它们拉进群聊，就能「协调任务、互相传递工作、分配归属，只在需要人类判断时把你拉进来」。

把这几点合起来，多智能体协作的完整拼图就是四块：

记住这四块。下一课的五人舰队案例，你就当成照着这块拼图搭一套完整组织的练习题来看。

✍️ 动手练习

练习 1：任命你的第一位总监

1. 把你现有 Bot 中最了解你的那个置顶，命名成一个真人名（比如「老陈」「Ada」）； 2. 给它补一句职责说明：「你是我的幕僚长，我发给你的所有任务由你判断拆解并派给合适的 Bot，完成后向我汇报进度」； 3. 验收标准：接下来一天内，所有新任务都先发给它而不是直接派给具体 Bot。

练习 2：给现有 Bot 划一次「专线」

拿出一张纸（或备忘录），列出你现在所有 Bot 的职责，逐个检查：它的边界是业务域还是软件？有没有两个 Bot 职责重叠？有没有涉及支付的活混在通用 Bot 身上？验收标准：改完之后，每个 Bot 都能用「负责 XX 这条线的一句话」描述，且支付类职责单独在一个 Bot 名下。

练习 3：观察一次后台通信

把两个 Bot 拉进同一条对话，给其中一个派一个需要另一个提供背景的任务（比如让写作 Bot 向调研 Bot 要资料）。验收标准：能在对话记录里找到至少一次它们之间的自发消息往来。如果暂时没有多 Bot 额度，可以先做练习 1 和 2，这个留到额度充裕时再做。

✅ 自测一下

1. 【单选】当你的 Bot 达到三五个以上，最大的问题通常是什么？ A. 单个 Bot 能力不够强 B. 调度：这个活该派给谁 C. 对话框数量太多 D. 头像不好看 2. 【单选】下列哪种分工设计符合「按业务域切」？ A. 负责 Chrome 的 Bot B. 负责邮件的 Bot C. 负责 Safari 的 Bot D. 负责截图工具的 Bot 3. 【判断】官方 Bug 接力案例中，两个 Bot 之间的交接物是一段聊天记录。 4. 【简答】为什么支付相关的任务要单独隔离给一个专门 Bot？ 5. 【简答】说出多智能体协作四块拼图的名称，并用一句话概括每块。

点开查看答案

1. B。橙皮书原话：最大的问题不再是能力，是调度——这正是第一个该养总监的原因。 2. B。「负责邮件的 Bot」是好设计，「负责 Chrome 的 Bot」不是——工具只是手段，职责才是边界。 3. 错。交接物是一张工单，不是聊天记录——交接有载体、可追溯、丢不了。 4. 因为花钱的事风险最高：单独隔离、授权范围最小化之后，一旦出问题最容易定位，损失也可控——类似财务上出纳与会计分设的思路。 5. 分工（各管一条专线）、通信（互发消息、共享上下文）、交接（以工单/任务卡为载体）、上报（只把需要人类判断的部分留给人）。

📌 一句话带走

先请一位总监替你调度全场，再按业务域划专线、把钱袋子单独锁起来——剩下的协作，交给它们自己互发消息。