Grok Bot 團隊的一位工程師，原本一次只跑 15 個雲端 Agent，現在能同時跑超過 200 個。
靠的不是 200 個 bot，而是 6 個。
五個工程師 bot，各自負責一個領域；再加上一個完全不寫任何一行程式碼的營運 bot。在同一個團隊裡，Lauren Tan 一個月內送出了超過 2,000 個 PR。
這正是大多數人忽略的地方。第一個 bot 跑得很順，於是他們加了第二個、第五個、第十個。結果就是開了十個聊天視窗，還多了一份全職工作：讀訊息。
一堆 bot 只是人頭數，團隊才是一套架構。 這份指南就是那套架構，直接取自 xAI 內部團隊的實際做法。
30 秒快速版
- 一個 bot 算是一個員工。但一支團隊需要五樣東西：單一入口、專家、專案、時鐘和關卡。
- 你只跟一個 bot 對話，由它把工作分派給其他 bot。
- 每位專家負責一個領域，並保留自己的記憶。
- 工作進度存在專案裡，而不是聊天紀錄中。
- 例行任務會在你睡覺時推動進度，審核機制則決定哪些東西可以放行。
- xAI 自己的團隊大約只用六個 bot 就跑起來了，不是六十個。
第一部分：什麼時候該請第二個 bot
不是因為第一個 bot 太忙。bot 不會像你一樣「忙不過來」。
Kevin Niparko 在 SpaceXAI 擔任 PM，管理著一整支 bot 團隊。他的指南列出了把工作拆分給不同 bot 的三個理由：可追溯性（「你知道誰負責什麼」）、平行處理，以及限定範圍的記憶。
第三點才是真正的關鍵。用他的話來說：
幕僚長不該去 debug computer-use evals。
當一個 bot 的記憶開始同時裝下兩份工作時，就該請第二個 bot 了。
你會在說得出原因之前就先察覺到異狀。收件匣 bot 開始用程式碼審查員的口吻回話；行事曆偏好設定混進了研究簡報裡；每次開啟對話，你都得先提醒 bot 今天該戴哪頂帽子。
用 Grok Bot 打造 Grok Bot 的 Lingxi Li，也從工程角度說了同樣的話：bot「專注於單一領域時表現最好」。
判斷標準：該做成技能，還是新 bot？
官方文件將技能定義為「一組可重複使用的任務執行指令」，而你的私有技能庫是所有 bot 共用的同一個資料庫。
所以，新任務是技能；擁有獨立記憶的新領域才是 bot。如果你沒辦法用三個字說出這個領域的名稱，代表你還不需要新的 bot。
第二部分：團隊的五個組成要素
1. 單一入口
就是你真正會對話的那個 bot。Josh Kim 的指南稱它為 Bot Boss，也就是「唯一的入口」。Niparko 叫它 Chief of Staff（幕僚長），並用兩句話形容它：「唯一的通才。沒事發生就保持安靜。」
入口負責分派，不負責實作。Kim 自己的 prompt 寫得非常直白：「你是 hub and spoke EA，不是 builder，也不是 auditor」。
你可以直接複製這段 prompt：
你是我的幕僚長，也是唯一跟我對話的 bot。把每個請求轉派給負責的專家，收集結果，對照我的原始需求檢查一遍，最後用五行回報。如果沒有變動，就保持沉默。
2. 專家
Niparko 的陣容：一位幕僚長、一位名叫 Emily 的工程經理、五個工程師 bot、一位資料分析師、一個 PM bot 和一位招募專員。Li 的陣容：五個按介面劃分的工程師 bot（iOS、桌面端、基礎設施、Android、測試框架），加上營運主管 Jenny。
看看這兩支團隊的共同點：都有一位不親自動手的管理者。Emily 負責拆解任務、分派工作，並檢查產出是否符合目標。Jenny 負責讓新 bot 上線，並主持事後檢討。兩人都不寫程式碼。
對第一支團隊來說，三位專家就夠了。Eric Zakariasson 把每個專案頻道的 bot 上限設為六個，並說這個數字「只是隨便定的」。雖然是隨便定的，但很正確。
3. 專案
聊天紀錄會被洗掉。團隊需要一個地方來記錄工作的最新狀態。
Li 的團隊使用 Notion 的共用追蹤表。每 30 分鐘，bot 會檢查每個 PR 是否有 CI 失敗、審查留言或合併衝突。有問題的退回「Working」，沒問題的移到「Ready for Review」。
Zakariasson 跑了兩個資料庫：Projects 和 Tasks，每個專案對應一個頻道。卡住的 bot 會把自己的任務標記為 Blocked，並通知人類。其餘時間，人類只需要看著卡片移動就好。
所有指南中最精彩的一句話，就出自他這篇：
有趣的是，我在這上面建得越多，它就越像一套最初為人類打造的系統。
4. 時鐘
根據文件說明，例行任務（routine）會「告訴某個 Bot 何時執行工作流程」。每個 bot 最多可設定 50 個，最短每五分鐘觸發一次，而且就算筆電蓋上也會持續執行。
Li 的時鐘是這樣安排的：凌晨 3 點執行夜間檢查——無用程式碼、載入時間、打包大小。清晨 5 點，Jenny 會與團隊中的每個 bot 進行一對一會議，檢視 playbook 並找出阻礙進度的問題。據回報，這些 bot「即使過了幾個星期，也很少忘記我複雜的工作流程」。
這場清晨 5 點的 standup，是整套架構中最被低估的設計。bot 的 context 是有限的，而重複提醒正是團隊維持標準的方式——在這裡，由 bot 負責重複提醒，你就不用自己來了。
5. 關卡
關於哪些事仍需要人類介入，Niparko 這麼說：
任何對外寄出的信件、購買行為，或是刪除這類破壞性操作，我仍然會做最終審核。
Kim 的做法更嚴格。他的收件匣 bot 是唯讀的，除非當下打出「send」這個字，否則絕對不會寄出任何東西。
文件中有兩個事實，會改變你設計關卡的方式：
- 背景審核會過期。 當例行任務或其他 bot 觸發需要你批准的動作時，請求大約 10 分鐘後就會失效，動作也不會執行。凌晨 3 點等你批准的任務，只會等到死。請事先決定好：要嘛為它寫一條允許規則，要嘛讓例行任務停在草稿階段。
- 你所有的 bot 共用同一台雲端電腦。 檔案、瀏覽器 session 和登入狀態在整支團隊之間都是互通的。文件說得很直接：不要把不同的 bot 當成安全邊界。
拆分 bot 是為了專注力與記憶，安全性則要靠關卡來守。
第三部分：五天內把團隊建起來
第 1 天：單一入口。 用上面的 prompt 把你的第一個 bot 升格為幕僚長。從現在起，它是你唯一會打開的聊天視窗。
第 2 天：依記憶拆分。 列出第一個 bot 目前負責的所有事情，並按領域分組。最大的兩組，就是你的前兩位專家。bot 的設定有三個欄位：Name、Title、Description。把它們當作徵才啟事來填。
第 3 天：專案。 建一張表格，包含 Task、Owner 和 Status：Todo、Working、Blocked、Ready for Review、Done。然後告訴每個 bot 同一件事：專案上沒更新就不算完成；卡住了就標記 Blocked 並通知我。
第 4 天：時鐘。 先設三個例行任務：幕僚長的晨間專案彙報、每 30 分鐘掃描一次專案，以及一次夜間檢查。每個都要先用安全的輸入值跑一次測試。文件警告過，測試執行「會產生真實的工作量」。
第 5 天：關卡。 寫下「先問再做」的規則：寄送、購買、刪除、發布，以及任何上 production 的操作。再針對你已經連續批准五次的動作，加上一條允許規則。
接著放著跑一個星期，再去請第四個 bot。
搞垮 bot 團隊的五個錯誤
分身大軍。 五個一模一樣的通才 bot。沒有專屬記憶、沒有領域劃分，也沒有任何效益。你只是把成本乘以五，混亂卻原封不動。
沒有專案的群組聊天。 bot 之間確實可以互相傳訊、互相觸發。但如果沒有共享的狀態，那就只是在開會，不是在工作。
親自動手的老闆。 入口 bot 開始自己跳下去做事。一旦你的幕僚長開始寫程式碼，就沒人分派工作，也沒人檢查成果了。
來者不拒的監聽器。 每收到一則新訊息就觸發一次。文件明確警告不要這麼做，因為這會製造大量雜訊並燒掉用量。條件要設得精準。
安全錯覺。 以為財務 bot 看不到研究 bot 登入了什麼。它們用的是同一台電腦、同一批 session。
組織圖就是產品本身
打造 Grok Bot 的人，並沒有為自己的團隊發明什麼新架構。他們重建的是最古老的那一套：一位管理者、幾位專家、一塊專案板、一場 standup，以及一道簽核關卡。
差別只在於，這支團隊的 standup 開在清晨 5 點，而且沒有人抱怨。
從單一入口開始，加上一位專家。在專案板建好之前，不要急著加第三位。
P.S. 如果你還沒請第一個 bot，可以先看我上一篇指南〈Grok Bot: How to Hire Your First AI Employee〉。本文引用的所有內容，皆來自 xAI 公開的 Grok Bot 指南與文件。
