Grok Build 是 SpaceXAI 推出的終端 coding agent，可用互動式 TUI、headless 指令或 Agent Client Protocol（ACP）執行。它能讀寫程式碼、執行 Shell、規劃修改、分派子 Agent，也能載入 AGENTS.md、skills、plugins、hooks 與 MCP servers。

這些功能讓 Grok Build 看起來像是「裝好就能工作的 AI 工程師」，但真正的導入門檻落在權限、工作範圍與驗收。只要 Agent 能改檔、跑指令和連外，它就已經超出聊天工具的範疇。團隊應先限制它能碰什麼、哪些動作必須核准，以及完成任務後要通過哪些測試，再考慮把它放進 CI 或無人值守流程。

Grok Build 在 2026 年 5 月以 early beta 推出，7 月公開原始碼。官方目前將它定位為可延伸的 coding agent，能力範圍也超過綁定單一模型的封閉 CLI。這也是本文和早期教學最大的差異：以下流程以 2026 年 8 月官方文件與 1.0.x 版本為準。

Grok Build 官方首頁，顯示終端安裝指令與 Grok 4.6

一行安裝，先用小型儲存庫驗證

macOS、Linux 與 WSL 可執行官方安裝指令：

curl -fsSL https://x.ai/cli/install.sh | bash

Windows PowerShell 使用：

irm https://x.ai/cli/install.ps1 | iex

完成後先確認版本，再從一個可丟棄或已提交的測試儲存庫啟動：

grok --version
cd /path/to/your-project
grok

互動環境首次啟動會引導登入。SSH、容器或沒有瀏覽器的環境可用 device-code 登入：

grok login --device-auth

腳本與 CI 也能從 XAI_API_KEY 取得憑證，但不要把金鑰寫入儲存庫、AGENTS.md 或 prompt。應由 CI secret store 注入環境變數，並限制它能存取的專案與外部服務。

第一次任務不要叫它重寫整個系統。先用可讀取、容易驗證的要求確認索引範圍與專案理解：

請摘要這個儲存庫的架構，列出主要進入點、測試指令與三個最高風險區域。先不要修改任何檔案。

接著執行 grok inspect，檢查它從目前目錄載入了哪些設定、instructions、skills、plugins、hooks 與 MCP servers。這一步可以提早發現從上層目錄繼承而來、你原本沒有打算啟用的能力。

Plan mode 的價值是把意圖變成核准點

複雜修改可按 Shift+Tab 切換到 Plan mode，或直接輸入：

/plan 將 session-based authentication 遷移為支援 token rotation 的 JWT；先盤點相依模組、資料遷移與回滾方式。

Plan mode 會先探索程式碼並產生計畫；在你核准之前，編輯工具只能修改該 session 的 plan file。官方特別說明，這個檔案編輯限制和權限模式是兩回事：即使使用 Auto 或 Always-approve，尚未核准的計畫也不應直接變成程式碼變更。

Grok Build 官方 Plan viewer，顯示 JWT 遷移計畫與核准介面

審查計畫時至少看四件事：

  1. 範圍是否封閉。 修改檔案、資料庫與外部服務是否都在需求內。
  2. 驗收是否可執行。 每個階段是否有測試、lint、type check 或可觀測指標。
  3. 回滾是否具體。 失敗時如何撤回 schema、feature flag 或部署。
  4. 未知事項是否暴露。 Agent 是否把推測寫成事實，或漏掉需要人決策的相依關係。

計畫通過不代表實作正確。它只是把高成本錯誤提前到較便宜的討論階段。

Ask、Auto 與 Always-approve 代表核准策略

Grok Build 的權限模式控制哪些 tool call 可以執行；sandbox 則限制已獲核准的動作能碰到哪些檔案與網路。兩者不能互相取代。

模式 行為 建議用途
Ask（預設） 未被允許的工具操作會詢問 新儲存庫、敏感環境、需求尚未穩定
Auto 分類器自動核准較安全的工具，危險操作仍可能詢問 已建立測試與邊界的日常工作
Always-approve 跳過一般 tool-call 詢問；deny rules 與 hooks 仍可阻擋 隔離工作區、可重建環境、短時間監看任務

不要把 --always-approve 當作「更聰明」或「更快」的模式。它只是在減少詢問。若工作區含部署憑證、正式資料或可推送的 Git remote，省下的點擊可能換來更大的事故半徑。

可以先在 ~/.grok/config.toml 或專案 .grok/config.toml 設定 allow／deny rules。官方規則支援 Read、Edit、Bash、Grep、MCPTool、WebFetch 與 WebSearch 等工具類型，而且 deny 優先於 allow。對 CI 而言，使用 dontAsk 並列出必要權限，通常比全面核准更容易稽核。

Headless 適合窄任務，不適合把模糊需求直接自動化

單次 headless 任務用 -p 或 --single：

grok -p "找出所有 TODO 註解，依目錄分組並輸出 JSON。不要修改檔案。" \
  --output-format json

需要串流事件時：

grok -p "解釋目前分支的架構變更與測試風險。" \
  --output-format streaming-json

官方目前支援 plain、json 與 streaming-json。腳本環境還應加上 --no-auto-update，避免背景更新檢查改變 CI 行為：

grok --no-auto-update -p "審查這次 API 變更，只回報可重現的問題。" \
  --permission-mode dontAsk \
  --allow 'Bash(git *)' \
  --allow 'Read' \
  --allow 'Grep' \
  --deny 'Bash(rm -rf *)' \
  --sandbox strict \
  --output-format json

真正適合 headless 的任務有三個共同點：輸入邊界清楚、成功條件可以機器判斷、失敗時不會直接影響正式環境。產生 release note、摘要測試失敗或盤點 TODO 都比「自行修好所有問題並部署」更適合作為第一批自動化。

子 Agent 帶來吞吐量，也放大協調成本

Grok Build 能把大型任務分派給多個子 Agent，每個子 Agent 有自己的 context，也能搭配 worktree 隔離修改。這適合平行探索不同服務、執行獨立測試或分別研究效能、資料庫與快取問題。

Grok Build 官方 Subagents 畫面，多個探索 Agent 平行追查 p99 latency regression

但「可以平行」不代表「應該平行」。如果多個 Agent 同時修改共享介面、schema 或同一批檔案，整合衝突會快速吃掉節省的時間。分派前應先定義：

  • 每個子任務的檔案或服務所有權
  • 共用介面由誰決定
  • 何時回報、何時合併
  • 最終由哪個驗證流程判定成功

平行化最有效的場景通常是研究與驗證。多人同時修改同一個核心模組，整合成本往往更高。

AGENTS.md、skills、plugins 與 MCP 的採用順序

Grok Build 會從目前目錄向儲存庫根目錄讀取 AGENTS.md，也會發現 .grok/skills/、使用者層級 skills、plugins、hooks 與 MCP servers。它還能相容讀取部分 Claude Code 與 Cursor 設定。這讓既有 agent workflow 容易遷移，也表示設定來源可能比預期更多。

建議順序是：

  1. 先寫 AGENTS.md。 放入建置、測試、目錄慣例、不可修改區域與完成定義。
  2. 再加入 skill。 把重複而且已驗證的流程封裝成可重用指令。
  3. 接著才裝 plugin。 Plugin 可帶入 skills、agents、hooks、MCP 與 LSP，權限面比單一 instruction 大。
  4. 最後連接外部 MCP。 每個 server 都應有最小 credentials、用途說明、timeout 與停用方式。

官方 Marketplace 會把遠端 plugin 固定到特定 commit SHA，能降低無聲更新的風險；但 commit pin 並不等於安全審查。正式採用前仍要檢查來源、腳本、hooks、MCP 權限與更新流程。

一套可執行的導入清單

如果團隊要在一週內評估 Grok Build，可以用以下順序：

  1. 選一個有測試、無正式憑證、可重建的儲存庫。
  2. 以 Ask mode 完成三個任務：架構摘要、小型 bug fix、測試補強。
  3. 用 Plan mode 處理一個跨檔案變更，記錄計畫被人類改寫的地方。
  4. 用 grok inspect 保存載入設定與擴充來源。
  5. 為 Shell、MCP 與寫檔動作建立 allow／deny rules。
  6. 把一個唯讀任務改成 headless，讓 CI 驗證 JSON schema 與 exit code。
  7. 最後才測試子 Agent、plugin marketplace 與 Always-approve。

這套順序評估團隊能不能預測、限制並驗證 Agent 的行為，而非比較回答看起來多聰明。Grok Build 已把 coding agent 的功能鋪得很完整；是否適合正式環境，仍取決於你能否把每個高風險能力變成清楚的控制點。

常見問題

Grok Build 現在還只是 early beta 嗎？ 2026 年 5 月的官方發布文確實稱為 early beta；之後官方在 7 月開源，公開 changelog 到 8 月已進入 1.0.x。評估時應看目前版本、文件與部署政策，不要只沿用首發標籤。

Grok Build 一定要用 Grok 模型嗎？ 官方文件支援在 ~/.grok/config.toml 設定自訂模型與 endpoint，也可從原始碼編譯後指向本機 inference。不過，不同模型對工具格式、context 與指令遵循的表現會不同，不能假設換 endpoint 後行為完全一致。

可以直接把 Grok Build 放進 CI 嗎？ 可以用 headless mode，但應從唯讀、可驗證任務開始，採用 dontAsk、明確 allow／deny rules、sandbox、最小金鑰與機器可判斷的輸出格式。

權威來源

Author Insight

Grok Build 最有價值的變化，在於把 TUI、plan review、權限、sandbox、extensions、headless 與 ACP 放進同一個可檢查的 harness。這讓團隊有機會把 coding agent 從個人效率工具變成工程系統。不過，系統化也意味著責任不能再推給 prompt：權限設計、測試、憑證隔離與失敗回復，最後仍是軟體工程問題。

術語表

  • TUI：在終端內運作的全螢幕文字介面。
  • Headless mode：不開啟互動介面，以單次指令、腳本或 CI 執行 Agent。
  • ACP：Agent Client Protocol，讓 IDE 或其他應用程式以協定連接 Agent。
  • Permission mode：決定 tool call 是否要核准；和限制檔案、網路能力的 sandbox 不同。
  • Worktree：Git 提供的平行工作目錄，可讓子 Agent 在不同分支或目錄隔離修改。
Share this post
Ewan Mak

I'm a Full Stack Developer with expertise in building modern web applications that fast, secure, and scalable. Crafting seamless user experiences with a passion for headless CMS, Vercel and Cloudflare

Loading...