如何用 Grok 4.7 操作已登入的瀏覽器

若要讓 Grok 4.7 操作你已登入的網站，請在本機 Agent 客戶端中執行模型，並為該客戶端提供瀏覽器工具。一種有官方文件可查的做法是 Grok Build 搭配 Tabbit CLI Skill，呼叫方式為 /tabbit。xAI 的 Web Search 和 X Search 可以搜尋公開網頁，卻不會替你操作本機已登入的瀏覽器。xAI 開發指南列出 grok-4.7 與 API 工具，Tabbit 快速開始說明 Skill 與登入狀態的沿用方式。

這幾件事很容易混為一談。一位 Reddit 使用者表示，Grok Bot 無法在自己的 Edge 視窗中「點擊」；另一位使用者表示，自己設定中的 Grok 簡單網站點擊測試失敗。這些是個人使用經驗，不能證明所有 Grok 客戶端都缺少瀏覽器控制。應該分別確認客戶端、它能呼叫的工具，以及登入狀態所在的瀏覽器環境。

重點

• Grok 4.7 是模型，光看模型名稱無法判斷它能控制哪個瀏覽器。

• xAI 文件列出 Grok 4.7 API 與 Grok Build。Grok Build 也會尋找 ~/.agents/skills/，並用 /<skill-name> 呼叫使用者 Skill。

• 分別確認模型、Tabbit Skill 和網站登入狀態。

• Tabbit CLI 可使用所選 Tabbit Browser 環境中的既有登入。任務會使用獨立分頁，你仍可在其他視窗工作。

• 先讓 Agent 檢查頁面並準備未發布草稿，再由人核對內容並決定是否儲存或發布。

• 本機測試頁驗證了該環境中的 Tabbit CLI 登入狀態沿用，但未測試 Grok Build 或正式後台。

先分清工作層

「Grok 能搜尋網頁」和「Grok 能操作我已登入的後台」是兩種能力。前者可能使用 xAI 代管工具；後者需要 Agent 客戶端連上瀏覽器。

Grok 4.7 官方指南列出 API 函數呼叫、Web Search、X Search 和程式碼執行。xAI 函數呼叫文件說明，內建 Web/X 搜尋會在 xAI 伺服器執行；自訂函數則由呼叫端執行。自訂函數可以連接瀏覽器，但前提是客戶端確實完成設定。只有搜尋工具，並不代表可以操作網頁。

設定 Grok Build 與 Tabbit

可以先檢查 Grok Build，因為 xAI 將 Grok 4.7 列為它的預設模型。官方文件也表示它會讀取 ~/.agents/skills/ 下的使用者 Skill，並將可呼叫 Skill 顯示為 /<skill-name>。Tabbit Skill 名稱是 tabbit，確認載入後即可輸入 /tabbit。參閱 Grok Build 概覽與 Skill 發現規則。

開始前依序確認三個條件：

1. 執行 grok models，確認列表中有 grok-4.7。API 模型 ID 和產品選單的名稱可能不同，請以客戶端顯示為準。

2. 執行 grok inspect --json，確認已載入 Tabbit Skill。若沒有，先啟動 Tabbit、重新啟動 Grok Build，再查一次。Tabbit CLI 完整指南說明安裝檢查；Codex 設定指南則展示另一種本機 Agent 如何載入相同 Skill。

3. 在 Tabbit Browser 中自行開啟目標網站，確認登入的是正確帳號和工作區。Skill 載入不會替你登入網站。若 Agent 顯示 /tabbit，但 CLI 無法連上 Tabbit，先檢查啟動器和瀏覽器控制器。

在本機啟動 Grok Build，選擇模型並呼叫 Skill：

grok models
grok inspect --json
grok -m grok-4.7

在工作階段輸入 /tabbit，並指出允許檢查的網站和頁面。不要在提示中放入密碼、一次性驗證碼、復原金鑰或客戶資料。CLI 安裝和任務回執可參閱完整 Tabbit CLI 指南。若已有登入分頁，請看讓 Agent 使用既有瀏覽器，了解工作階段的邊界。

Tabbit Skill 會提供支援的啟動器與任務語法。唯讀任務可以指定新的任務名稱和唯一請求 ID：

"$HOME/.local/bin/tabbit-cli" nodejs \
  --task "Grok release review" \
  --request-id grok-release-review-001 <<'JS'
return {
  title: await page.title(),
  url: page.url(),
  headings: await page.getByRole('heading').allTextContents()
};
JS

即使在這個範例中，也要分別確認 Skill 載入、啟動器連線與網站登入。它只示範唯讀檢查，沒有證明 Grok Build 會自動接受所有 Tabbit CLI 參數，也沒有測試 CMS 編輯。若任務要更改頁面，先檢查頁面和預計操作，再決定是否允許寫入。

在瀏覽器中核對有來源的更新

可以用發布說明草稿當作範圍明確的例子。先查看公開發布來源，再檢查已登入的營運頁面。然後請 Agent 準備一份有名稱的草稿，停在瀏覽器中讓人檢查。每項事實旁都保留來源連結。

2026-11-09 的本機測試頁在未登入時回傳 401。設定短時間有效的測試 Cookie 後，第二個 Tabbit CLI 任務在同一 Tabbit Browser 環境開啟相同頁面，讀到標題 Release notes review 和測試記錄 GEO-104，回應為 200。每個任務各有一個工作分頁。測試後已清除 Cookie 並關閉臨時分頁。這只驗證該本機測試頁的登入狀態沿用，並未測試 Grok Build、CMS 編輯器或實際發布。

以下是參考 xAI 的 Grok 4.7 公告與開發指南撰寫的草稿建議。公開來源說明模型；測試頁只提供範例複核頁標題與記錄 ID。

提示詞應提供來源、唯讀檢查內容和停止條件：

/tabbit
在我的 Tabbit Browser 中開啟已登入的發布複核頁面。只讀取畫面上可見的草稿名稱和記錄 ID。
請用下列公開來源核對這則更新：https://x.ai/news/grok-4-7 和 https://docs.x.ai/developers/grok-4-7。
準備名為「Grok 4.7 發布說明複核」的草稿，讓草稿在瀏覽器中保持可見，並附上來源連結。不要儲存、發布或更改狀態。
回覆草稿全文、頁面標題、記錄 ID 和任何不一致處。停下來等我複核。

預期結果是可見但未發布的草稿、官方公告與 API 指南連結、從營運頁讀到的標題和記錄 ID，以及簡短的不一致清單；不執行儲存或發布。若網站沒有草稿編輯器，請 Grok 在對話中提供文字，再由你貼入。測試頁是唯讀頁面，因此這部分是示範流程，不是已觀察到的端到端操作。

第一次實際操作時，先依照瀏覽器 Agent 首次任務清單，選低風險頁面。如果操作會更改資料、付款或需要確認，就先停下來複核。其他連線方式可看瀏覽器 MCP 與 CLI 比較。能讀取或更改網頁的 Agent 也有權限風險，可先閱讀 AI 瀏覽器概覽、網頁互動指南和瀏覽器 Agent 安全風險。

本機或遠端流程怎麼選

若任務需要本機瀏覽器的登入狀態，而且 Tabbit Skill 可用，本機 Grok Build 更合適。不要假設雲端 Runner 能連到本機 Tabbit Browser。若沒有連線功能，請遠端 Agent 先整理有來源的檢查清單，再交由本機 Grok Build 或你自己完成瀏覽器操作。

Tabbit 適合這個流程，因為任務依賴既有的瀏覽器登入狀態。它不是 Grok 4.7 的替代模型，設定也不表示 xAI 有內建 Tabbit 連接器。Tabbit 快速開始提到任務分頁可讓你繼續在其他視窗工作。Agent 在獨立分頁中操作，你仍可查看過程並決定是否允許它變更已登入網站。

簡單來說：選擇已核實可用的 Grok 客戶端，確認 grok-4.7 和 /tabbit，在 Tabbit Browser 登入目標網站，再從唯讀檢查開始。讓 Agent 準備附來源的草稿，在瀏覽器裡核對後再決定是否儲存或發布。

Secholar.L

Tabbit 成長與內容

Secholar.L 專注 AI 瀏覽器與 Agent 工作流的實測寫作,基於真實調研比較工具,引用可查證的一手來源。