2026-08-11 推出的 Grok Bot 是一個名字容易誤導的產品：它不是聊天機器人，而是常駐的電腦操作代理。使用者建立具名的 Bot、指派職務，然後像交辦同事一樣把工作丟給它。對話關掉就結束，Bot 則保有自己的檔案、瀏覽器登入狀態、記憶與排程——關掉筆電，它仍在跑。
這個產品目前仍是早期測試版。本篇的重點不在功能清單，而在一個官方發布訊息與官方文件互相衝突的安全模型——那是導入前真正需要弄清楚的部分。
📖 它是什麼
官方文件（docs.x.ai/grok-bot/teams-and-enterprises，2026-10-22 查證）的描述：Grok Bot 是一個操作應用程式、瀏覽器與開發環境的「computer-use agent」。每位成員擁有常駐的 Bot，用於研究、營運、文件、瀏覽與自動化等工作。
它跑在 Cursor 的雲端上——這不是巧合：SpaceX 於 2026-08-14 完成對 AI 編碼工具 Cursor 的收購。桌面與行動 App 只是客戶端，負責對話、審閱與核可。
能力：瀏覽器、檔案與命令列存取、外掛（plugins）、群組對話、代理之間的交接、以及排程執行的 routines。部分動作需要人類核可。
與聊天的根本差別：
- 對話是一次性的，Bot 是持續的
- 對話沒有登入狀態，Bot 的瀏覽器保有 session
- 對話要你在場，Bot 的 routine 會自己跑
📖 那台電腦是共用的
這是本篇最重要的一節，也是官方兩種說法衝突的地方。
發布訊息被廣泛解讀為「每個 Bot 有自己的電腦」。官方文件寫的是另一回事：
每位使用者的工作跑在一台持續存在的 Firecracker microVM 上（具備自己的 kernel、記憶體與虛擬裝置），而該使用者的每一個 Bot 都共用這台電腦。
兩層隔離的差別必須講清楚：
| 隔離層級 | 實際情況 |
|---|---|
| 使用者之間 | 有硬體層級隔離，一個使用者無法觸及另一個使用者的電腦 |
| Bot 之間 | 沒有運算隔離，只分開「人格」與「工作區」 |
官方文件的指引是：把這台電腦上的任何登入狀態與檔案，都視為該使用者的每一個 Bot 都拿得到。並建議：
- 讓瀏覽器登出 Bot 不再需要的帳號
- 工作結束後刪除敏感的暫存檔
- 需要獨立電腦與獨立憑證的工作負載，應該給它自己的 Cursor 使用者
為什麼這件事重要？ 很多人會下意識地用「分開的 Bot」做權限切分——例如一個 Bot 管客戶資料、一個 Bot 跑對外的自動化。這個切分在安全上是無效的：對外那個 Bot 一旦被 prompt injection 之類的手法劫持，它看得到另一個 Bot 留在同一台機器上的所有登入狀態與檔案。
正確的切分單位是使用者，不是 Bot。
📖 權限與核可
預設沒有任何存取權。 Bot 只能使用使用者或團隊明確授予的帳號與外掛。團隊的連接器政策同樣適用於外掛。
OAuth token 不會交到 Bot 手上——token 留在 Cursor 的連接器後端，Bot 透過它呼叫工具，但拿不到 token 本身。登入、兩步驟驗證與付款步驟會交還給人類成員。
核可機制（Auto Review）：敏感動作需要使用者核可，由一個獨立的審閱模型評估。企業版可設定團隊層級的規則（「先問」或「自動允許」），以及禁止成員關閉審閱的 Enforce Auto-review（企業版限定，預設關閉）。
在成員本機執行的工作，預設是每次任務都先詢問。 官方對本機執行的建議是：除非 Bot 有明確理由需要在成員機器上工作，否則選「永不允許」。
核可能擋的與不能擋的：核可控制的是「即將發生的動作」。它不會回復一個已經發生的變更——若 Bot 已經改了 CRM 的一筆資料，核可機制救不了你。因此高風險的整合應該在授權階段就不給，而不是指望逐次核可。
📖 Routines
排程執行的工作。官方文件只零散提到：routine 的執行會記錄為 Action Recording 事件、控制平面事件會進稽核日誌、關閉 Agent Email 開關會停掉 email routine。
官方建議定期檢視啟用中的 routine，並在來源系統變動時暫停對應的 routine。
這條建議值得照做。 一個排程代理最危險的狀態不是做錯事，而是在環境已經改變之後，仍然照舊執行——它不會知道那份報表的欄位上週換過了。
📖 誰能用、多少錢
這一節的資料品質最差，二手來源彼此矛盾，我無法從官方確認。
已知的不同說法：
- 測試版初期限 SuperGrok Heavy 與 Cursor Ultra／Cursor Teams Premium
- 2026-10-12 起隨訂閱改組，較高層級的 X Subscription 可用
- 有報導給出約 $120／月的數字
- 有報導指 X Premium+ 包含 Grok Bot
合規：有評論指出推出時未附帶 SOC 2、ISO 27001、GDPR、HIPAA 或 FedRAMP 的聲明。若你所在的產業有合規要求，這一點應該在評估的第一步就去向官方確認，而不是依賴任何二手說法。
📖 導入前的檢查清單
把上面的內容整理成可以照做的順序：
一、確認切分單位。 需要互相隔離的工作負載，各自配一個使用者，不要用不同的 Bot 充當邊界。
二、最小授權。 從零開始加外掛，每加一個問「這個 Bot 的職務真的需要嗎」。
三、本機執行設為永不允許，除非有明確理由。
四、敏感整合在授權層排除，不要依賴逐次核可——核可擋不了已發生的變更。
五、列出所有 routine 並排定檢視週期，在來源系統變動時主動暫停。
六、合規先確認再導入，不要先接再補。
🧠 重點整理
Grok Bot 不是聊天機器人，是常駐的電腦操作代理，跑在 Cursor 的雲端上。
同一使用者的所有 Bot 共用一台 microVM——官方文件如此寫明，與發布訊息被解讀的「各自一台」相衝突。
使用者之間有硬體隔離，Bot 之間沒有。 正確的安全切分單位是使用者。
把機器上的任何登入與檔案，視為每個 Bot 都拿得到。
預設零權限，OAuth token 不交給 Bot，登入與付款交還人類。
核可擋得住即將發生的動作，擋不住已經發生的變更。
本機執行預設應選「永不允許」。
Routine 最危險的狀態是環境變了它還照跑，要定期檢視。
訂閱層級、價格與合規狀態目前無法由官方確認，導入前須自行查證。
✍️ 動手做
在交付任何實際工作之前，先做一次隔離測試，約 20 分鐘：
- 建立兩個 Bot，分別取名為「公開」與「內部」。
- 用「內部」那個在瀏覽器登入一個無關緊要的測試帳號（絕對不要用真實的工作帳號）。
- 切換到「公開」那個，叫它列出瀏覽器目前登入了哪些帳號。
- 觀察結果。
若它看得到測試帳號，你就親眼確認了文件所寫的共用模型——而這個確認應該發生在你把任何真實憑證放上去之前，不是之後。
🔗 資料來源
- xAI 文件 — Grok Bot for teams and enterprises——Bot 定義、Firecracker microVM 共用模型、使用者與 Bot 的隔離差別、外掛與 OAuth、Auto Review、本機執行建議、routine 稽核（一手，2026-10-22 查證）。
- 英文維基百科 — Grok (chatbot)——Grok Bot 的推出日期（2026-08-11）與早期測試版定位。
- 英文維基百科 — SpaceXAI——Cursor 收購於 2026-08-14 完成。
- 訂閱層級、約 $120／月的價格與合規狀態取自二手報導（VentureBeat 等），彼此矛盾且未經官方確認，見 主張 vs 可佐證。