Grok Build CLI 是什麼？從 Plan Mode、相容性到 early beta 風險

本篇是「AI Coding CLI 觀察筆記」系列的第 1 / 3 篇。你可以從系列總覽開始閱讀，也可以直接接著看本文。

Grok Build 剛公開時，我最先注意到的不是模型，而是 xAI 幾乎把 coding agent 的主流介面一次補齊：terminal TUI、Plan Mode、headless、平行 subagents、worktree、Skills、MCP，還加上 ACP 讓其他應用程式可以呼叫它。

初稿寫完兩個月後，官方文件已經變動不少。原本流傳的模型名稱、context window、subagent 數量和訂閱價格都不適合繼續寫死。這篇依 2026-07-14 的 Grok Build 官方文件重新整理：它現在能做什麼、真正值得看的設計是什麼，以及哪些結論還不能只靠發表文下判斷。

這是「AI Coding CLI 觀察筆記」第 1 篇。下一篇會把 autocomplete、IDE agent、CLI 與 cloud agent 放回同一張演化地圖。

Grok Build 現在是什麼？

Grok Build 是 xAI 推出的 coding agent。它可以在 terminal 裡互動執行，也能用 headless 模式放進 script 或 bot，或透過 Agent Client Protocol（ACP）接入其他 client。

目前官方入口很簡單：

# macOS / Linux / WSL
curl -fsSL https://x.ai/cli/install.sh | bash

cd /path/to/your/repo
grok

要非互動執行，使用 -p：

grok -p "Explain this codebase"
grok -p "Review the current architecture" --output-format streaming-json

目前正式文件的互動入口是 grok；-p 本身就是 headless 入口。安裝後先以 grok --help 確認版本，比沿用 beta 初期流傳的指令可靠。

官方文件目前表示，Grok Build 使用的模型是 Grok 4.5，也支援在 ~/.grok/config.toml 設定自訂模型與相容 endpoint。模型名稱和可用清單會更新，使用時應以 /model、grok inspect 與當下文件為準，而不是照抄文章裡的固定版本。

第一個值得看的設計：Plan、review、approve

Grok Build 把 Plan Mode 放在很顯眼的位置。複雜任務可以先進入 /plan，讓 agent 建立工作計畫；你能先審核、對個別步驟留言，或直接重寫計畫，再決定是否執行。

/plan Refactor the authentication flow without changing the public API.
/view-plan

Plan Mode 不代表完全沒有副作用。依 Modes and Commands，plan file 的修改會自動通過，其他檔案寫入仍需批准。這是一個「先規劃、再控制寫入」的互動模式，不是獨立容器或作業系統沙箱。

Grok Build 目前有三種可循環切換的模式：Normal、Plan、Always-approve。預設 permission mode 是 ask；always-approve 會略過工具批准，不該拿來當新專案的預設。

第二個值得看的設計：沿用既有 agent 設定

xAI 在正式發表文中明確寫出，Grok Build 會讀取：

AGENTS.md；
plugins；
hooks；
Skills；
MCP servers。

這比「相容 Anthropic Skills」更準確。它採用的不是單一廠商的全部 runtime，而是盡量接住開發者已經建立的 agent 設定與開放格式。

你可以用下面的指令查看它在目前目錄實際發現什麼：

grok inspect

TUI 也提供 /import-claude，用來開啟 Claude 設定匯入流程。這能降低第一次嘗試的 setup cost，但「能讀」不等於「行為完全相同」：

權限模式和工具名稱可能不同；
hook event 與 payload 需要逐項驗證；
同一個 Skill 依賴的 binary、路徑或 MCP server 可能不存在；
project config 的優先順序未必相同。

真正安全的遷移方式，是先用 grok inspect 確認來源，再拿一個小型、可回滾的任務測試，不是直接把 production repo 丟進 always-approve。

第三個值得看的設計：平行 subagents 與 worktree

xAI 把平行 subagents 和 worktree integration 當成 Grok Build 的主打功能。大型任務可以拆給不同 agent 探索，並讓 subagent 在各自 worktree 工作，減少同時修改同一份 working tree 的衝突。

這個方向很實用，但不是 Grok Build 獨有。Claude Code 目前有 subagents、background agents、agent teams 與 worktree sessions；Codex 也有 subagents 與 worktree 工作流。差異不在「有或沒有」，而在：

何時自動拆任務；
如何檢視與中止 subagent；
如何合併 worktree 的成果；
權限與 context 是否能分別控制；
失敗時能不能清楚找到是哪一個 agent 出錯。

目前官方發表文沒有承諾固定的最大 subagent 數量。這類限制應從當下版本與帳號方案查詢。

ACP 解決的是 client integration，不是 agent 品質

ACP 讓 Grok Build 可以被編輯器、bot 或 orchestration app 當成 agent backend。這對想做自訂介面的人很有用，例如把任務從內部工具送入 agent，再把進度顯示在自己的 dashboard。

但協議支援只回答「怎麼連」，不回答：

agent 會不會改對；
權限邊界是否足夠；
session 中斷後能否可靠恢復；
大型任務的 cost 和 latency；
外層 client 能否完整呈現批准、diff 與錯誤。

評估 ACP 時，應該測完整生命週期，而不是只確認連線成功。

三分鐘上手，任務要刻意選小

第一次測試，我會用一個不牽涉 secrets、部署或資料庫的任務：

Read AGENTS.md and the package scripts.
Plan a README update that documents install, check, and build commands.
Do not edit files until I approve the plan.
After editing, show the diff and list what you verified.

觀察五件事：

是否讀到正確的 project instructions；
Plan Mode 是否真的在寫檔前停下；
diff 有沒有超出需求；
指令失敗時會不會自行擴大範圍；
最後是否誠實區分「已驗證」和「尚未驗證」。

這比一開始就測跨 20 個套件的 monorepo refactor 更容易看出工具的基本行為。

訂閱與認證：只寫官方目前保證的部分

xAI 在正式發表文中說明，early beta 開放給 SuperGrok 與 X Premium Plus 訂閱者。第一次啟動會透過瀏覽器登入；沒有瀏覽器的環境可以使用 XAI_API_KEY。

價格、額度和 beta 資格都可能調整，因此這篇不再維護固定月費表。決定前請直接查看帳號頁面的即時方案，並分開計算訂閱額度與 API key 用量。

現階段我的結論

Grok Build 值得注意的不是「又多一個模型」，而是 xAI 選擇跟進一套已經被驗證的 coding-agent 工作流：project instructions、Plan Mode、Skills、MCP、hooks、subagents、worktrees，再用 ACP 和可切換模型增加整合彈性。

它仍是 early beta。官方發表文能證明功能存在，不能證明它在你的 repo 裡比 Claude Code、Codex 或 Copilot CLI 更可靠。真正有意義的比較，仍然要在同一個 repo、同一組需求、同一套測試下進行。

下一篇先把「為什麼工具都走向 agent」講清楚，第三篇再提供一套不靠固定模型和價格表的選擇方法。

下一篇：AI Coding 工具不是三代淘汰：從補全、IDE Agent 到 CLI 與 Cloud Agent