Grok Bot 团队的一位工程师，把同时运行的云端 Agent 数量从 15 个提升到了 200 多个。
靠的不是 200 个 bot，而是 6 个。
5 个工程师 bot，各管一个领域；再加 1 个运维 bot，一行代码都不写。同一个团队里，Lauren Tan 一个月提交了 2000 多个 PR。
这才是大多数人忽略的地方。第一个 bot 跑通了，他们就加第二个、第五个、第十个。结果手里多了十个聊天窗口，还多了一份全职工作：挨个看消息。
一堆 bot 只是人头数，团队才是结构。 这份指南就是这套结构，完全来自 xAI 自己人的实战打法。
30 秒速览版
- 一个 bot 算一次招聘。而一个团队需要五样东西：入口、专家、项目、时钟和关卡。
- 你只跟一个 bot 说话，由它把工作分派给其他 bot。
- 每个专家负责一个领域，并维护自己的记忆。
- 工作沉淀在项目里，而不是聊天记录里。
- 你睡觉时，例行任务推着工作往前走；审批决定哪些东西能放行。
- xAI 自己的团队大概用 6 个 bot 就跑起来了，不是 60 个。
第一部分：什么时候该招第二个 bot
不是在第一个 bot “忙不过来”的时候。bot 不会像你一样“忙”。
Kevin Niparko 在 SpaceXAI 做 PM，带着一整支 bot 团队。他的指南给出了把工作拆分到不同 bot 的三个理由：可追溯性（“你知道谁在干什么”）、并行能力，以及隔离的记忆。
第三点才是真正的答案。用他的话说：
Chief of Staff 不该去调试 computer-use evals。
当一个 bot 的记忆开始装两份工作时，就该招第二个 bot 了。
你往往先感觉到不对劲，然后才说得清问题在哪。收件箱 bot 开始用代码审查员的口吻回话；日历偏好混进了调研简报；每次发消息前，你都得先提醒它今天戴的是哪顶帽子。
用 Grok Bot 构建 Grok Bot 的 Lingxi Li，从工程角度说了同样的话：bot “专注单一领域时表现最好”。
判断标准：该做成 skill，还是新 bot？
文档把 skill 定义为“一套可复用的任务执行指令”，而你的私有 skills 是所有 bot 共享的一个库。
所以，一个新任务是 skill；一个自带独立记忆的新领域才是 bot。如果你没法用三个词说清这个领域，说明你还不需要新 bot。
第二部分：团队的五个组成部分
1. 入口
你真正会去对话的那个 bot。Josh Kim 的指南叫它 Bot Boss，也就是“唯一入口”。Niparko 叫它 Chief of Staff，两句话就讲明白了：“唯一的通才。没变化就不吭声。”
入口负责分发，不负责干活。Kim 自己的 prompt 写得很直白：“you are hub and spoke EA, not a builder and not an auditor”。
可以直接抄的 prompt：
你是我的 Chief of Staff，也是我只会对话的 bot。把每个请求路由给负责的专家，收集结果，对照我的要求检查一遍，然后用五行话汇报。没有变化就保持沉默。
2. 专家
Niparko 的阵容：一个 Chief of Staff、一个叫 Emily 的工程经理、5 个工程师 bot、一个数据分析师、一个 PM bot 和一个招聘专员。Li 的阵容：5 个按端划分的工程师 bot（iOS、桌面端、基础设施、Android、harness），加上运营负责人 Jenny。
看看两支团队的共同点：都有一个不干具体活的管理者。Emily 拆解任务、分派工作、拿产出和目标对齐。Jenny 负责新 bot 上手和事后复盘。两人都不写代码。
第一支团队，3 个专家足够了。Eric Zakariasson 把每个项目频道限制在 6 个 bot 以内，还说这个数字“只是随便定的”。随便定的，但很对。
3. 项目
聊天记录刷着刷着就没了。团队需要一个地方来承载工作状态。
Li 的团队用 Notion 里的共享追踪表。每 30 分钟，bot 会检查每个 PR 有没有 CI 失败、评审意见和合并冲突。有问题的打回 Working，没问题的推进到 Ready for Review。
Zakariasson 跑了两个数据库：Projects 和 Tasks，每个项目一个频道。卡住的 bot 会把自己的任务标成 Blocked，然后 ping 人。其余时间，人只需要看着卡片挪动。
所有指南里最精彩的一句话，就出自他这篇：
有意思的是，我在这上面搭得越多，它就越像一套最初为人类设计的系统。
4. 时钟
按文档的说法，routine “告诉某个 Bot 何时运行 workflow”。每个 bot 最多可以挂 50 个 routine，最快每 5 分钟触发一次，而且合上笔记本它们照样跑。
Li 的时钟长这样：凌晨 3 点跑夜间审计——死代码、加载耗时、包体积。早上 5 点，Jenny 跟团队里每个 bot 开 1:1，过一遍 playbook，把阻塞项捞出来。结果是：哪怕过了好几周，bot 也“很少忘记我那些复杂的 workflow”。
这场早 5 点的站会，是整套方案里最被低估的设计。bot 的上下文是有限的。重复，是团队守住标准的方式；而在这里，重复的活儿由 bot 干了，你不用操心。
5. 关卡
关于哪些事还得人来把关，Niparko 这么说：
对外发邮件、采购任何东西，或者删除这类破坏性操作，最终 review 我还是自己留着。
Kim 做得更绝。他的收件箱 bot 是只读的，除非你当场敲下 “send” 这个词，否则它什么都不发。
文档里有两条事实，会改变你设计关卡的思路：
- 后台审批会过期。 当 routine 或另一个 bot 触发了需要你点头的操作，请求大约 10 分钟后就会失效，操作不会执行。凌晨 3 点等你批准的任务，只会等到死。提前想好：要么给它写一条 allow 规则，要么让 routine 停在草稿阶段。
- 你所有的 bot 共用一台云电脑。 文件、浏览器会话和登录态在整个团队里通用。文档说得很直接：别把不同的 bot 当成安全边界。
拆分 bot 是为了专注和记忆，安全感要靠关卡来给。
第三部分：五天搭起来
第 1 天：入口。 用上面的 prompt 把你的第一个 bot 提拔成 Chief of Staff。从现在起，它是你唯一打开的聊天窗口。
第 2 天：按记忆拆分。 列出第一个 bot 现在干的所有事，按领域分组。最大的两组，就是你头两个专家。bot 的设置只有三个字段：Name、Title、Description。像写招聘 JD 一样填它们。
第 3 天：项目。 建一张表，包含 Task、Owner 和 Status：Todo、Working、Blocked、Ready for Review、Done。然后告诉每个 bot 同一件事：项目没说完成就不算完成；卡住了就标 Blocked，然后 ping 我。
第 4 天：时钟。 先上 3 个 routine：Chief of Staff 的晨报、每 30 分钟扫一次项目、一次夜间审计。先用安全的输入跑一遍测试。文档提醒过，测试运行“会执行真实操作”。
第 5 天：关卡。 写下“先问再做”的规则：发送、采购、删除、发布，任何涉及生产环境的操作。再为你已经连续批准过 5 次的动作加一条 allow 规则。
然后放手一周，再去招第四个 bot。
搞垮一支 bot 团队的五个错误
克隆大军。 5 个一模一样的通才。没有隔离的记忆，没有领域划分，毫无收益。你只是把成本翻了倍，混乱照旧。
没有项目的群聊。 bot 之间可以互相发消息、互相触发。但没有共享状态，那就是开会，不是干活。
亲自下场干活的老板。 入口开始自己动手做任务。一旦你的 Chief of Staff 开始写代码，就没人分发，也没人检查了。
全量监听。 每条新消息都触发一次。文档专门警告过这种做法，因为它制造噪音、狂烧用量。匹配条件要收窄。
安全幻觉。 以为财务 bot 看不到研究 bot 登录了什么。同一台电脑，同一批会话。
组织架构图就是产品本身
打造 Grok Bot 的人，并没有为自己的团队发明什么新架构。他们重建的是最古老的那一套：一个经理、几个专家、一块看板、一场站会、一道审批。
区别在于，这支团队的站会开在早上 5 点，而且没人抱怨。
从入口开始。加一个专家。项目搭起来之前，别急着加第三个。
附：如果你还没招第一个 bot，先看我上一篇指南《Grok Bot：如何招聘你的第一位 AI 员工》。本文引用的所有内容，均来自 xAI 公开的 Grok Bot 指南与文档。
