从单兵到团队
上一个教程解决了「一个 Bot 干一件事」，进阶篇解决「一群 Bot 干一个摊子」。这也是 Grok Bot 和上一代 agent 拉开代差的地方。
当你只有一个 Bot 时，它是你的个人助理。但当你有三五个 Bot 时，最大的问题不再是单个 Bot 的能力，而是调度——这个活该派给谁？谁和谁之间需要配合？
Grok Bot 给出的答案是：给团队请一个总监。
总监模式：所有任务的统一入口
社区里人人都在做的第一件事，就是把第一个 Bot 设置成 Chief of Staff（幕僚长/总监）。做法很简单：在 Bot 列表中把它置顶，命名成真人名，然后所有任务——无论大小——无脑丢给它。
总监的日常工作长这样：你发一句「研究一下最近的 AI 趋势，写封邮件发出去」，它回你一句「研究分给 Barry，写邮件分给 Cindy」，然后自动拆解、派发、追踪进度。
你面对始终只有一个对话框，复杂度全部沉到水面之下。背后的 Bot 有多少个、各自在干什么，你不需要知道。
分工的学问：按专线，不按工具
总监有了，接下来要决定怎么分工。官方推荐的方式是按「专线（lane）」划分：每条专线配一个专家 Bot。
典型的专线配置：
- 收件箱管理——处理邮件，分类归档
- 开支报销——提取发票，整理表格
- 招聘——筛选简历，安排面试
- 修 bug——复现问题，定位修复
- 日常运营——盯竞品，做日报
实践中有两条经验值得记住：
第一，按业务域切，不按软件切。「负责邮件的 Bot」是好设计，「负责 Chrome 的 Bot」不是——工具只是手段，职责才是边界。
第二，花钱的事单独隔离。支付相关的活固定交给一个专门的 Bot，授权范围最小化，出问题也最容易定位。
群聊：它们真的会互相说话
这是 Grok Bot 最让我觉得「时代变了」的瞬间：你把几个 Bot 拉进同一条对话后，它们会自发地互相发消息。
一个社区里流传很广的例子：让写代码的 Bot 开发一个功能，它会主动去给内容 Bot 发消息：「老板前几天发的需求，上下文发我一下。」没人教它这么干——任务交接、上下文传递、进度同步，全部发生在你看不见的后台。
一次真实的多 Bot 接力
据官方公告披露的内部案例，一次完整的 bug 修复经历了这样的旅程：
工程线的 Bot 在产品界面里复现一个 bug → 接着建一张工单 → 把问题转交给负责修复的调试 Bot
这条链子短，但三件事全部说清楚了：
- 发现问题的 Bot 和解决问题的 Bot 是两个不同的专家——「复现」和「修复」被拆成了两个岗位
- 它们之间的交接物是一张工单，不是一段聊天记录——交接有载体、可追溯、丢不了
- 全程没有人在场，你只在最终结果那里出现
五人舰队：一套完整的组织模板
下面这套配置出自 AI 创作者 Alex Finn 的实战分享，经多家媒体转述后在社区广泛传播。它覆盖技术、内容、社区、商务、增长五个方向：
| Bot | 职位 | 日常在干什么 |
|---|---|---|
| Build | CTO | 通过内网穿透控制高性能主机，部署模型、手搓项目、修 bug |
| Barry | 公关内容总监 | 每天 7:00–23:30 每 30 分钟扫一遍行业头部账号，拼 newsletter |
| Dusty | 社群运营 | 用独立邮箱当论坛管理员，24 小时答疑，主动私信潜水成员 |
| Cindy | 商务总监 | 接管商务邮箱，背调发件人，每天下班交一张「今日真机会」表 |
| Reed | 增长黑客 | 找痛点、写小工具、扔出去测市场 |
这套配置最值得注意的地方在于：这些岗位没有一个需要人实时在线。Barry 一天自动执行三十多次，Cindy 每天处理几百封邮件，而你只在他们交作业时出现。
不过要诚实指出一点：这五位其实各管一摊、分别向老板交作业——这个案例展示的是分工，还不是协作。把它们从「五个工位」升级成「一支舰队」也简单，给他们接几条传递线就行：
- 让 Barry 的每日简报自动抄送总监、归档进素材库
- 让 Cindy 筛出的真机会直接 @ Build 评估可行性
- 让 Reed 验证通过的痛点自动生成一条任务卡进入下周排期
工位之间连上线，化学反应才开始发生。
群聊的边界与安全口径
多智能体玩法有两个必须知道的边界：
群聊上限：每个命名空间最多 6 个 Bot。 这是产品机制的上限，不是建议值——6 个同时在线协作已经能覆盖绝大多数团队场景，超过这个数的编排需求要拆成多个命名空间。
安全口径：“Bots are not a security boundary”。 这是官方的原话，含义必须吃透：Bot 之间的隔离是「功能分工」而非「安全隔离」——同一账号（命名空间）下的多个 Bot 共享基础设施，一个 Bot 被污染（比如接收到恶意指令），其他 Bot 一样暴露。所以：
- 敏感授权（支付、核心账号）的隔离必须做在账号层面——给高危操作单独开账号，而不是指望「让另一个 Bot 管钥匙」
- 给 Bot 的密码和 API key 用 secret card 添加，不进对话上下文
- 群聊里让 Bot 互相传递的信息，默认按「可能会被任一成员看到」处理
搞清楚这一点，该用照样用：多智能体的价值在分工协作，只是安全责任始终在你这个「董事长」身上。
一个从 OpenClaw 迁移来的真实案例
有开发者把跑了半年的 OpenClaw 单 Agent 工作流迁到 Grok Bot 多智能体上，得出一条值得借鉴的经验：迁移时不要平移架构，要按「专线」重新拆。单 Agent 时代一个 Bot 既盯邮件又盯代码又写周报，迁移初期照搬成一个超级 Bot + 几个零散助手，效果反而不如原来；后来按业务域重切成「收件箱 / 工程 / 内容」三条专线各配专家 Bot，配合总监调度，效率才超过旧方案。
结论：多智能体的组织设计有自己的最优解，不是单 Agent 架构的简单复制。分工的学问——按业务域切、按专线划分——值得回头再看一遍上文。
上手节奏：舰队是长出来的
不要一次养五只 Bot。正确的顺序是：先养总监，跑一周；哪个环节你最累，就为那一环招第二个「员工」。
推荐的扩编节奏：
- 第一周：只养总监。把大脑倾倒做足，让它充分了解你和你的业务
- 第二周：补上你最烦的那件事对应的专家岗
- 第三周：开始给老员工配 routine
- 第四周：回头清理——两周没被派过活的 Bot 果断删掉
养 Bot 和养团队一样，冗员是悄悄发生的。
多智能体常见问题
Q：6 个 Bot 的上限不够用怎么办？ 拆命名空间。一个命名空间管一条业务线（比如「内容运营」6 个、「工程交付」6 个），命名空间之间互相独立——这同时也是安全的边界，比把 12 个 Bot 塞一个群更合理。
Q：Bot 互相传话会出错吗？ 会出现上下文损耗——A 转述给 B 的信息不如 A 自己执行准确。关键交接物（工单、表格、文档）用文件载体传递，别靠聊天记录转述。
Q：总监 Bot 会自己做活吗？ 会，但不建议。总监的价值在调度和汇总，让它亲自干活会让队列堵塞。职责描述里就写清楚「你是管理者，不执行具体任务」。
Q：怎么判断该加第 N+1 个 Bot？ 两个信号：总监频繁在两类不相关的任务间切换（说明该拆专线）；某个环节你每周亲自补位超过三次（说明该为它招专职）。信号没出现就别扩编。
每周复盘三问
每周花十五分钟做一次复盘，只问三个问题：
- 这周哪个 Bot 替我省的时间最多？
- 哪个 Bot 的产出我返工得最多？
- 下周要不要调分工？
给 Bot 的反馈要像带新人一样具体——「这个不行」没有用，「以后这类消息先用两句话总结再推给我」才有用。