Grok Bot 是什麼？會自己登入公司軟體的 AI 同事，企業導入前要懂的 7 件事（2026）
Grok Bot 是 SpaceXAI 與 Cursor 推出的 AI 同事：每個 Bot 有一台常駐雲端電腦，會自己登入網站與軟體完成工作，不需要 API。本文解釋它的運作方式、共用電腦的資安邊界、審批與 Auto Review、企業版管控、計費模式與上線前的檢查清單。
Grok Bot 是什麼？一句話：它是 SpaceXAI（原 xAI）與 Cursor 在 2026 年 8 月推出的「AI 同事」產品，每個 Bot 有一台常駐的雲端電腦，會自己打開瀏覽器登入公司的網站與軟體，像人一樣操作，完成後回報，碰到該由人決定的事就停下來問你。它不需要 API，也不需要 MCP。
這個定位和過去兩年企業熟悉的 AI Agent 不同：Agent 通常由工程師用 API 建，Grok Bot 則是業務單位自己就能「聘」。這也是為什麼它值得 CTO 與部門主管一起看：導入門檻很低，治理門檻卻不低。
本文整理自 SpaceXAI 官方文件、x.ai 公告與 Cursor 方案頁，查證日期為 2026 年 10 月 14 日。產品仍在 beta，功能與方案持續變動。我沒有實際使用過 Grok Bot，以下是文件分析與第三方評測的整理，不是實測紀錄；會寫明哪些是官方說法、哪些是評測者的判斷。
Grok Bot 是什麼？跟 Grok 聊天機器人、X 上的 @grok 差在哪
Grok 是模型與聊天應用，@grok 是在 X 上標記即可回覆的帳號，Grok Bot 則是會自己操作軟體、持續存在、可排班的 AI 同事。三者共用 Grok 模型家族，但 Grok Bot 多了電腦、記憶與職務。
| 面向 | Grok（聊天應用） | @grok（X 上標記） | Grok Bot |
|---|---|---|---|
| 互動方式 | 你問它答 | 在貼文標記它 | 像傳訊息給同事一樣交辦 |
| 會不會操作軟體 | 不會 | 不會 | 會：瀏覽器、終端機、連接器 |
| 狀態 | 單次對話 | 單次回覆 | 持久：記憶、檔案、登入狀態、偏好 |
| 排程 | 無 | 無 | Routines 可排程、可由事件觸發 |
| 主要入口 | Grok app、X | X | Grok Bot 桌面與行動 app（電腦跑在 Cursor 雲端） |
依 x.ai 的方案公告，Grok Bot 於 2026 年 8 月 11 日以 beta 形式推出；企業版公告則在 9 月 3 日，加入了存取、網路與稽核控管，並點名 Legora、Supermicro、ServiceTitan 等客戶。官方對它的定義是「your team of helpful AI teammates」：為特定職務建一個 Bot，它就在你們已經在用的工具裡自主工作。
值得注意的一個細節：官方文件說 Bot 的電腦跑在 Cursor 的雲端，方案與帳務也走 Cursor，SpaceXAI 與 Cursor 在這個產品上是深度綁定的。如果你的公司對 AI 員工的概念還不熟，可以先讀 AI 員工是什麼？數位員工 vs AI Agent，再回來看 Grok Bot 怎麼把那個概念做成產品。
它怎麼「上班」：一台常駐雲端電腦、瀏覽器、終端機
每位使用者會分到一台常駐的雲端 Linux 電腦，所有 Bot 共用這台電腦，各自有一個螢幕。Bot 用瀏覽器登入網站、用終端機跑指令、把檔案放在 /workspace，電腦在你關掉筆電之後仍持續運作。
官方的電腦與應用程式文件把這台電腦的性質講得很清楚：它「assigned to your user account, not to an individual Bot」。每個 Bot 有自己的螢幕，所以多個 Bot 可以同時操作瀏覽器或桌面工具，但一個 Bot 的螢幕一次只能跑一個電腦操作任務。
圖 1：一位使用者的 Grok Bot 電腦，以及多個 Bot 共用它的方式
graph TD
U[使用者帳號] --> VM[一台常駐雲端電腦<br/>Firecracker microVM]
VM --> SH[共用層：cookie 與登入狀態、/workspace 檔案、CLI 憑證、已安裝連接器]
VM --> S1[Bot A 的螢幕]
VM --> S2[Bot B 的螢幕]
VM --> S3[Bot C 的螢幕]
S1 --> W[公司網站與 SaaS 後台<br/>以瀏覽器登入操作]
S2 --> W
S3 --> CN[連接器<br/>OAuth token 存在 Cursor 後端]
U -.->|密碼、2FA、付款由人接手| VM
螢幕是分開的工作面，不是分開的安全邊界。任何一個 Bot 登入過的帳號、存過的檔案，同一帳號下的其他 Bot 都能用。
連接系統有兩條路。優先用「連接器」：從 Connect apps 安裝，像外掛一樣，OAuth token 由 Cursor 的連接器後端保管，不會放在電腦上；官方建議有連接器就用連接器，因為比點網頁可靠。沒有連接器的服務才用瀏覽器直接操作，這也是 Grok Bot 最大的賣點：沒有 API 的舊系統、純網頁後台，它都進得去。
碰到密碼、passkey、兩步驟驗證、CAPTCHA、付款或身分驗證時，Bot 會停下來請你接手：你打開它的電腦畫面，只完成被擋住的那一步，再叫它繼續。官方特別提醒不要把密碼或一次性驗證碼貼進聊天，支援的連線會出現「secure secret request」，輸入值會被遮罩、不進對話紀錄。
從 Harness Engineering 的角度看，Grok Bot 是把 sandbox、工具執行、狀態保存全部包成一台「電腦」，再把人放在旁邊隨時接手。這個設計讓非工程人員也能用，代價在下一節。
企業能拿它做什麼？官方列的職務與真正適合的場景
官方列的職務集中在業務研究與初步外聯、招募初篩與面試評分表、行銷活動後的跟進、採購與供應商成本監控、工程的 PR 監控與稽核。共同特徵是：要跨好幾個網頁工具、步驟重複、結尾有人看過才送出。
企業版公告的案例還包括讓多個 Bot 在同一個群組對話裡互相傳遞工作。VentureBeat 的報導提到，有員工會在幾個專職 Bot 之上放一個「Chief of Staff」Bot 負責分派；這是使用方式，不是產品內建的角色。
哪些場景真的適合，第三方評測給了比官方更有用的分級。eesel 的評測依場景打分：沒有 API 整合的工具 8 分、先出草稿再由人送出的知識工作 7 分、工程團隊 7 分；需要直接對客戶發訊的客服隊列 4 分、受監管的組織 3 分（滿分 10）。評測者的理由是：它在「沒有整合介面的系統」裡確實能把事做完，但目前沒有試跑模式、審批不能回復已完成的動作、稽核視圖還沒上線。
| 場景 | 適合度 | 原因 |
|---|---|---|
| 沒有 API 的舊系統、純網頁後台 | 高 | 用瀏覽器進得去，是它獨有的能力 |
| 研究、彙整、擬稿，由人送出 | 高 | 不可逆動作在人手上 |
| 跨多個 SaaS 的例行操作 | 中 | 可行，但網站過期登入、驗證會讓流程停下 |
| 直接對客戶發送訊息 | 低 | 無試跑、審批不回復已完成動作 |
| 受監管資料、需要完整稽核 | 低 | 動作層級稽核與保留政策尚不完整 |
我的判斷：Grok Bot 的甜蜜點是「人要做很煩、API 又接不到」的工作。這類工作在多數公司不是沒有，而是從來沒人把它列成清單。
Routines 與 Teach a Task：讓它每天自己跑
Routine 是指定一個 Bot 在固定時間或特定事件後執行某個流程；Teach a Task 是你親自操作一遍，Bot 錄下來存成一個 skill。兩者合起來，Grok Bot 才從「交辦一次」變成「排班上工」。
官方的 skills 與 routines 文件列出的限制，直接決定你能把它用到什麼程度：
| 項目 | 限制或規則 |
|---|---|
| 每個 Bot 的 routine 數 | 最多 50 個 |
| 排程最小間隔 | 5 分鐘 |
| 執行紀錄保留 | 每個 routine 保留最近 20 筆 |
| Teach a Task 錄製長度 | 最多 10 分鐘，只錄可見的電腦操作，不錄麥克風 |
| 事件觸發 | 可由 Slack 訊息、GitHub 通知等事件啟動，需另外連線 |
| 測試 | Test run 會做真實動作：真的上網站、改檔案、呼叫連接器 |
兩個設計上的提醒來自官方本身。第一，Teach a Task 產出的 skill 是草稿：你示範的是「正常路徑」，決策規則、失敗處理、哪一步要審批都得事後補上。第二，routine 要寫明「沒有資料時怎麼辦」，文件給的例子是回報失敗而不是用舊資料；長時間沒人回應時，系統會問你要不要繼續跑，沒回應就暫停。
對照 AI 員工三階段路線圖的「試用期」概念，Teach a Task 剛好是試用期的交接動作，而 20 筆執行紀錄的上限意味著你得自己把結果存到別處，否則一個月後就看不到它做過什麼。
最容易被忽略的風險：所有 Bot 共用同一台電腦
Grok Bot 的安全邊界是「使用者」，不是「Bot」。同一帳號下的每個 Bot 都共用 cookie 與登入狀態、檔案、命令列憑證與已安裝的連接器。刪除一個 Bot 只會刪掉它的設定、對話與 routines，電腦上的登入與檔案都還在。
這不是評測者的推測，是官方文件的原文。電腦與應用程式頁寫道：「Do not place a credential or file on it if another Bot on your account should not be able to use it」，以及「The screens are separate work surfaces, not separate security boundaries」。企業文件則說明架構：每位使用者一台 Firecracker microVM，使用者之間有硬體層級隔離；但同一使用者的所有 Bot 共用一台電腦。
這對企業意味著三件事：
- 「一個 Bot 一個職務」的權限分離在這裡不成立。 你給招募 Bot 登入的人資系統，採購 Bot 也進得去。權限的最小單位是「這個人的所有 Bot」。
- 下線要清理，不是刪除。 官方的退場步驟是：暫停或刪除 routine、在共用電腦上登出網站、移除連接器並到來源端撤銷授權、刪掉
/workspace裡的敏感檔案。來源端撤銷才是最可靠的證明。 - 員工離職的處理要落在身分層。 官方說 Bot 的權限不會超過登入的那個人；從團隊移除成員、或在身分提供者撤銷 session，Bot 就失去存取。
這和我們之前討論 OpenClaw 導入決策時的核心問題是同一個：當 AI 代理用「人的身分」登入系統，企業的存取控制模型就得從「系統對人」改成「系統對人以及這個人養的所有代理」。Grok Bot 把這件事做得更徹底，因為它連 API 都不需要。
審批與 Auto Review：誰來當它主管
Grok Bot 有兩層主管。第一層是審批：碰到有後果的動作，對話裡會顯示它要做什麼與參數，你選 Allow once、Always allow 或 Deny。第二層是 Auto Review：一個獨立的審查模型在危險動作執行前先看一遍，可以放行、要求審批或直接拒絕。
圖 2：一個有後果的動作在 Grok Bot 裡會經過的判斷
flowchart LR
A[Bot 提出動作<br/>例如送出郵件、改正式環境] --> R{Auto Review<br/>獨立審查模型}
R -->|Ask first 規則命中| H[暫停，等人審批]
R -->|判定需要審批| H
R -->|判定可放行且無規則阻擋| X[執行]
R -->|判定拒絕| D[拒絕，回報]
H -->|Allow once| X
H -->|Always allow| X
H -->|Deny| D
X --> N[注意：審批只管這一步<br/>不會回復已完成的工作]
Ask first 規則永遠優先於 Allow automatically。Auto Review 不涵蓋所有副作用，記憶寫入與多數設定變更不在審查範圍。
官方安全文件列的規則裡，有幾條會直接影響你怎麼設計主管機制：
- Auto Review 審查的動作包括 shell 指令、外掛呼叫、電腦操作、自動化寫入、委派給 Cloud Agent 或子代理。
- 個人規則分「Ask first」與「Allow automatically」兩種；前者一定攔，後者只在審查模型沒有其他理由停下時才生效。衝突時 Ask first 贏。
- 企業版管理員可以強制開啟 Auto Review 並加團隊規則，成員不能自己關掉。
- 個人規則存在設定它的那台桌機上並同步到該電腦，換一台桌機要重新確認。
- 本機執行（在你自己的 Mac 或 Windows 上跑指令）是另一條政策，預設每次詢問；官方建議除非有明確需要，否則設成 Never allow。
把這套機制和 Claude Managed Agents 的 permission policy放在一起看會很有意思：Claude 是由開發者在設定檔裡逐個工具宣告政策，Grok Bot 是由使用者在對話中按按鈕、再由審查模型補位。前者適合工程師定規則，後者適合業務單位自己管，但也意味著規則散落在個人設定裡，管理員要靠企業版的強制功能才收得回來。
企業版管控有哪些、哪些還沒有
企業版提供網路白名單、SCIM、Team Secrets、動作錄製與 OpenTelemetry 匯出；但 Grok Bot 專屬的花費上限、Bot 動作層級的稽核視圖與模型白名單，官方文件標示為尚未提供或不保證執行。
依官方企業文件與安全文件整理：
| 管控項目 | 狀態 | 說明 |
|---|---|---|
| 組織層級開關 | 企業版 | Teams 方案預設全員開啟，且「no switch to turn it off」 |
| Network Controls | 企業版 | 四種模式，從全開到只允許團隊白名單；沒設政策就是全開 |
| SCIM 與 SSO | 企業版 | 沿用 Cursor 帳號；SSO 只管登入，不管電腦內的行為 |
| 連接器政策 | Teams 與企業版 | 可全域停用、允許或拒絕特定伺服器 |
| Team Setup 與 Team Secrets | 企業版 | 安裝腳本與加密環境變數；上限 100 個、每個 32 KB |
| Action Recording | 企業版，預設關 | 記錄工具呼叫、shell 指令、瀏覽器導覽，保留 90 天，透過 OpenTelemetry 匯出 |
| 對話內容匯出 | 企業版，選擇加入 | 含 prompt、回應與 MCP 工具 I/O，官方說遮罩不保證抓到所有機密 |
| Grok Bot 專屬花費上限 | 未提供 | 官方原文「A separate Grok Bot spend cap is not available today」 |
| Bot 動作稽核視圖 | 未提供 | 動作紀錄只能透過 Action Recording 匯出，不在稽核日誌頁 |
| 模型選擇 | 不可選 | 由 Cursor 管理，無模型選單；團隊模型白名單企業版有但不保證執行 |
| 本機執行上限 | Teams 與企業版 | 管理員可設團隊上限，成員較嚴的設定仍生效 |
還有幾個會卡住導入的前置條件：使用 Privacy Mode（Legacy）的團隊會被整個擋在產品外；代理伺服器要放行 *.*.cursorvm.com 並排除 TLS 檢查；電腦用共享的靜態出口 IP，不是你公司專屬的；電腦目前在美國，且這不等於 Cursor 的美國資料駐留方案。
把這些放進 企業 AI 治理框架裡看，Grok Bot 在「身分與網路」這兩層已經有企業級的工具，但在「稽核與成本」這兩層，2026 年 10 月的版本還在補。
要花多少錢？週額度、超額與沒有硬上限的問題
Grok Bot 的計費不是按 token 開單，而是方案內含的每週用量額度；用完後若開啟 on-demand 就繼續跑並另計費，沒開就停。官方方案頁不列價格，也沒有 Grok Bot 專屬的花費硬上限。
Cursor 的方案頁列出哪些方案包含 Grok Bot：Cursor 的 Pro、Pro+、Ultra 與 Teams，Cursor Enterprise 由業務開通；也可以連結個人的 SuperGrok、SuperGrok Plus、SuperGrok Heavy 或 X Premium+ 訂閱，用量取較高者，不疊加。SuperGrok Lite 不含。
價格方面，官方頁沒有數字；VentureBeat 的報導寫個人透過 Cursor Ultra 每月 200 美元、團隊透過 Cursor Premium Teams 每席每月 120 美元。這是 8 月上市時的報價，方案已多次調整，請以你的帳號看到的為準。
| 計費面向 | Grok Bot 的做法 | 企業要注意的事 |
|---|---|---|
| 計量單位 | 方案內含週用量，以 agent 步驟與 token 計 | 無法像 API 那樣逐任務算成本 |
| 重置 | 每週 | 常駐 Bot 可能在週中就用完 |
| 超額 | on-demand 繼續跑，透過 Cursor 計費 | Teams 預設開啟 on-demand |
| 上限 | 「On-demand monthly limit」可設，但不是執行中硬停止 | 跑到一半的任務會做完才停 |
| 專屬花費上限 | 無 | 只能靠帳號層級的 on-demand 控制 |
這是 Grok Bot 與 API 型方案最大的財務差異。LLM API 成本監控那套「每個應用對帳」的方法在這裡用不上，因為你看不到每個 Bot 花了多少 token；能做的是從用量分析看每位成員的週用量，以及把 on-demand 月上限設在可接受的範圍。
上線前檢查清單
上線前至少要做完七件事：設網路政策、審連接器清單、強制開 Auto Review、本機執行設 Never allow、關掉不需要的 Cloud Agent 委派、公開範本分享預設關、寫下哪些動作一律 Ask first。這七件都是官方 rollout baseline 的建議。
官方企業文件給了管理員與成員兩份基線，整理如下：
| 對象 | 要做的事 |
|---|---|
| 管理員 | 設 Network Controls（沒設就是全開）；開啟前先審連接器政策；開啟 Enforce Auto-review 再談團隊規則；本機執行設 Never allow；不需要委派就關 Cloud Agent；公開範本分享保持關閉；加窄的團隊 Ask first 規則，官方例子是正式環境部署、對外郵件、付款、接受法律條款；用身分提供者把登入限制在受管裝置 |
| 成員 | 不把憑證貼進聊天，用遮罩的 secret request；敏感動作選 Allow once 不選 Always allow；Bot 的瀏覽器只登入任務需要的帳號，用完登出；新職務先從唯讀與擬稿開始；定期檢查外掛與 routines |
我會再加三件官方沒列、但從文件限制推出來的事：
- 把 20 筆執行紀錄的上限當成稽核缺口處理。 要求每個 routine 把結果寫到你們自己的系統（試算表、工單、Slack 頻道都可以），否則一個月後無法回溯。
- 把「刪 Bot 不等於下線」寫進離職與專案結案 SOP。 清理清單就是官方那五步，負責人要指定。
- 先在 Teams 方案跑一個部門，再決定要不要上企業版。 Teams 沒有組織開關、沒有網路政策、沒有 Auto Review 強制，等於全員預設可用；這適合試點，不適合全公司。
這些和 從 PoC 到 Production 的部署指南裡「權限資安」與「人工覆核」兩個失敗原因直接對應。Grok Bot 降低的是建置門檻，不是治理門檻。
結論：先決定邊界，再決定職務
Grok Bot 真正新的地方只有一個：它讓「沒有 API 的工作」也能交給 AI。其他部分，持久記憶、排程、審批、多 Bot 協作，API 型方案都有，而且稽核與成本控制更成熟。所以企業的問題不是「要不要用 Grok Bot」，而是「哪些工作值得用瀏覽器型的 AI 同事做，而且我們接受它目前的稽核與共用電腦模型」。
想比較 API 型與介面型兩條路各自適合什麼，用 Claude 還是 Grok Bot 建數位員工？8 項差異與各自擅長場景把兩者放在同一張表上，並給出依公司狀況選擇或並用的決策流程。如果你想先為公司盤點哪些工作適合交給 AI 同事、邊界該怎麼畫，歡迎預約 AI 導入顧問諮詢。
常見問題 FAQ
Grok Bot 需要工程師才能用嗎？
不需要。Grok Bot 的操作方式是傳訊息給 Bot、在它的電腦畫面上示範一次任務、在對話裡按審批按鈕，沒有設定檔也沒有程式。需要工程能力的是企業版的網路政策、Team Setup 安裝腳本與 OpenTelemetry 匯出，這些由 IT 或資安團隊處理。
Grok Bot 會不會自己亂買東西或亂寄信？
付款與身分驗證步驟 Bot 做不了，會停下來交給人；寄信、發布、刪除、改正式環境這類有後果的動作會進審批，由你選 Allow once、Always allow 或 Deny，Auto Review 也會先審查。但審批只管該步驟，不會回復已完成的動作，而且目前沒有試跑模式，所以新職務應從唯讀與擬稿開始。
多個 Grok Bot 之間的資料會互相看到嗎？
會。同一位使用者的所有 Bot 共用一台雲端電腦，包括瀏覽器登入狀態、檔案與命令列憑證。官方文件明說螢幕是分開的工作面而不是安全邊界，不該把其他 Bot 不應使用的憑證或檔案放上去。不同使用者之間則有硬體層級隔離。
Grok Bot 的資料存在哪裡、會保留多久？
每位成員的電腦有一顆持久磁碟，保存檔案與瀏覽器狀態；連接器的 token 存在 Cursor 後端，不在電腦上。電腦目前位於美國。保留期限依 Cursor 條款，沒有組織層級的自訂保留政策；服務終止後依 DPA 在書面指示 30 天內刪除或歸還。使用 Privacy Mode（Legacy）的團隊無法使用本產品。
Grok Bot 跟 Claude 的 AI Agent 有什麼不同？
Grok Bot 用瀏覽器與終端機像人一樣操作軟體，業務單位自己就能建，適合沒有 API 的系統；Claude Managed Agents 由工程師用 API 與設定檔建，跑在隔離的 sandbox，有逐工具的權限政策與每次任務的金額硬上限，適合有 API、需要稽核與成本控制的場景。兩者可以並用，前者管前台操作，後者管後端批次。
中小企業適合先用 Grok Bot 嗎？
適合先用一個部門試點，條件是選「人做很煩、API 接不到、結尾有人送出」的工作，並且接受 Teams 方案目前沒有組織開關與網路政策。先從唯讀與擬稿類任務開始，把 routine 結果寫到自己的系統，兩週後再評估要不要擴大或升級企業版。
分享這篇文章
