Grok Bot 掛了嗎？四種看似斷線的故障，以及該先檢查什麼

如果你的 Grok Bot 今天早上停止回應，那多半不是平台中斷，原因在於結構設計。Grok Bot 是 SpaceXAI 的常駐代理，於 2026 年 8 月 11 日推出，並以一小群具名機器人的形式，運行在分配給你的帳戶的雲端電腦上。它幾乎每一種故障方式，都會產生相同的症狀——沉默——而平台本身卻完全正常。因此，對於「它是不是掛了？」這個問題，誠實的第一個答案是：單憑症狀無法判斷；而有一套檢查順序，能讓你在約三分鐘內得到答案。

在開始檢查清單之前，先說明一點：就我們所閱讀的 SpaceXAI Bot 文件而言，它提供帳戶層級的用量讀數，以及各例行程序的執行記錄，但沒有公開的正常運作時間或事件動態來源。沒有任何頁面可供你重新整理，以得知服務是否處於降級狀態。正因為這項資訊的缺失，本文才會存在，而不是只給你一個狀態頁面的連結。

這四項失敗，依照它們實際發生的順序

第一：帳戶的內含用量已用完。這是最常見的情況，也最能讓人誤以為是服務中斷，因為觸及上限的機器人會直接停止運作。Grok Bot 的使用權限是隨付費 Cursor 方案與 SuperGrok 各級方案提供，而文件所述的計量方式是帳戶每週的內含用量，而非每個機器人各自計算。這個差別正是整個陷阱所在：一個多話的機器人就能耗盡五個機器人共享的額度，而從外部看起來，就像整個機群同時停擺。Usage & Billing 會為符合資格的帳戶顯示每週內含用量與隨需用量，帳戶選單中則有每週讀數；而內含用量用盡的方案，可額外產生隨需支出，並依模型與權杖成本計費。若你同時付費使用兩者，同一份 FAQ 中有一句話值得知道：若你持有 Cursor 訂閱與 SuperGrok 訂閱，Bot 會使用用量較多的那一個。

第二：例行程序是暫停，而非故障。例行程序是機器人依排程或事件觸發運作的方式，而且不保證在你不在的期間會持續運作。文件指出，Grok Bot 可能在你長期未出現後詢問是否要讓例行程序繼續運作，若你未回覆，便會將它們暫停。若機器人在假期、長週末或一則未讀提示之後沉寂下來，最可能正是處於這種狀態。

第三點：電腦遭到重設，你安裝的東西也一併被帶走了。你帳號上的每個機器人共用同一台電腦，這台電腦具備常駐的 Linux 環境、瀏覽器、命令列，以及共用工作區，位於 code>/workspace/code>。說明文件明確指出，暫存目錄、手動安裝的套件，以及未提交的應用程式狀態，都應視為可替換的——而且兩種復原路徑並不相同：「重設」會還原上次儲存的快照，而「重新建立」則「移除成員自行安裝的應用程式與套件」。如果你的機器人依賴你手動安裝的東西——第三方程式碼代理、CLI、函式庫——復原作業可能會把它移除，留下一個能回應但無法完成本職工作的機器人。這看起來像是部分服務中斷，實際上卻是缺少一個二進位檔。

第四點：機器人背後的模型已改變，或已劣化。 Cursor 負責管理模型選擇。對於「我該在哪裡挑選 Grok 4.7 與另一個模型」這個問題，文件給出的答案很直接：沒有模型選擇器、沒有個別機器人設定、沒有個別例行程序設定，也沒有個別技能設定。10 月 7 日，Elon Musk 公開表示，Grok Bot 將不再僅限於 SpaceXAI 自家模型，而會採用「針對任何給定任務的最佳後端模型」——這項說法沒有附上費率表、更新日誌條目，也沒有任何外部測量。因此，引擎是你看不見的平台端決策。當它改變時，你觀察到的不是錯誤訊息，而是同一批任務上的輸出品質、延遲與成本發生漂移。突然寫得更差或耗時更久的機器人，未必是故障了。

三分鐘檢查

按順序執行這些項目，並在第一個能解釋你所見情況的項目停下來：

• 帳號用量優先。 打開帳號選單，先讀取每週包含用量數字，再動其他任何東西。如果它已耗盡或接近耗盡，下游的一切——每個機器人、每個例行程序——都因同一個原因而失敗，再怎麼對機器人除錯都於事無補。隨需支出是那個槓桿，而這是帳務決定，不是技術決定。

• 其次看執行記錄。每個常式會保留最近 20 筆執行記錄。這是刻意設計得較淺的稽核軌跡，但仍足以回答真正重要的問題：該常式是有執行並失敗，還是根本從未啟動？沒有近期記錄的常式表示已暫停或從未觸發；有記錄但最後失敗的常式表示是機器人問題；有成功記錄但沒有可見輸出的常式表示是輸出傳遞問題。

• 第三：電腦。直接問機器人它能看到什麼——code>/workspace/code> 的內容、某個已安裝的工具是否仍然存在、某次登入是否仍然有效。因為這台電腦是整個帳號共用的一台機器，而且每個機器人都能看到檔案，所以這也能讓你判斷，另一個機器人做過的事是否影響到這一個。

• 第四點：觸發條件。 如果機器人是依事件而非排程運作，請檢查觸發條件的涵蓋範圍。文件警告不要使用過於廣泛的監聽器，例如「每則新訊息」，這會產生雜訊、耗用額度，並對不相關的輸入採取行動。若機器人頻繁觸發卻毫無用處，或情況相反，通常問題出在觸發條件的界定，而不是服務本身。

只有在這四項全部乾淨之後，「平台」才是合理的假設——而且即使在那時，你掌握的證據仍是間接證據，因為沒有狀態資訊流可供對照確認。

為什麼共用電腦會讓這件事變得比應有的更難

Grok Bot 最關鍵、也最不顯眼的設計，就是單一電腦架構——直到出問題才會顯現。一台電腦是指派給你的帳號，而不是指派給任何個別機器人；每個機器人看到的畫面被描述為「獨立的工作介面，而非獨立的安全邊界」；在 Team Bot 上，任何機密都能用於任何隊友的對話中。這對診斷有兩個後果。

首先，故障很少只影響局部。你的研究機器人寫入的檔案，你的拓展機器人也能讀取；而在重設期間移除的套件，會影響所有曾使用該套件的機器人。其次，復原是以帳號為範圍。刪除機器人會移除使用中的設定檔、對話與例行程序，但電腦檔案與登入狀態並非依機器人個別隔離，且可能持續留存。隱藏機器人是可逆的替代做法；刪除例行程序則會立即生效，且無法復原。

如果你在凌晨兩點還在除錯，這種不對稱性比任何日誌都來得重要：那些看似清理的操作，恰恰是沒有回頭路的那些。

「status」實際上需要什麼？

一個真正的狀態答覆需要三件事，而 Grok Bot 目前並未提供給你；值得把這三件事點名出來，因為它們正是「你能操作的产品」與「你只能觀看的产品」之間的差別：

• 每個 bot 的計量器。使用量是以帳戶層級計算，因此若一整群 bot 一起失效，就無法拆解出是哪個 bot 造成的。

• 更深入的執行歷程。 每個例行工作保留二十筆紀錄，足以在本週捕捉到一次失敗，卻不足以在一個月內捕捉到漂移——這種失效模式會無聲無息地造成金錢損失，而不是大張旗鼓。

• 事件資訊流。若缺少它，「服務已降級」便是從四項缺失推論而來的結論，而非一項實際觀察。

這些都不是對產品設計的批評；就其本質而言，這套設計是連貫一致的：一個透過對話來設定的訂閱代理。這確實意味著，每當機器人沉寂無聲時，舉證責任就落在你身上，而上述的檢查順序正是承擔這份責任最省力的方式。

路由器適用之處，以及不適用之處

Grok Bot 是訂閱制產品，不是能透過第三方端點繞送的東西，任何誠實的指南都不該暗示 otherwise。模型選擇問題所帶出的疑問則是另一回事：如果你需要刻意選擇引擎——為了成本、為了授權、為了結果的可重現性——這項需求根本無法在機器人內部表達，它必須存在於更下層的層級。

那一層正是我們所賣的東西。OrcaRouter 是一個與 OpenAI 相容的單一端點，涵蓋 200 多個模型，且對供應商定價不加價，因此廠商一降價，當天就即時反映。Grok 4.6 在其上，採用 SpaceXAI 自行公布的價格：每百萬輸入 token 2.00 美元、每百萬輸出 token 6.00 美元，上下文視窗為 500,000 個 token，實測 p50 首字時間為 1.65 秒。當某個尚未驗證的環節失敗時，真正要緊的是那些能防止故障演變成事故的機制：當某家供應商效能下降時，自動跨供應商容錯切換；可將多個模型組成單次呼叫的路由 DSL；以及讓多個模型一起作答的模型融合。

對任何因為自己的機器人突然安靜無聲而讀到這裡的人來說，實際可行的做法是最無趣的那一種。先把技能寫好，手動對你原本打算信任的模型跑一次，然後才把它自動化。一個已用你能直接呼叫的模型驗證過的機器人，其失敗是可以歸因的——而「它掛了嗎？」真正在問的是歸因，不是正常運行時間。