2026-05-18 — views

xAI 推出 Grok Build CLI：8 個子代理並行、SWE-Bench 70.8%、$99 入門價

為什麼值得讀值得盯緊的不是 benchmark 分數，而是「8 個 subagent 並行」這個結構選擇。若它站得住，成本模型從「每任務多少 token」轉成「每分鐘多少任務」 —— 跑 Claude Code 或 Codex 的團隊都得從 throughput 重做評估。

5/14 公開測試。SWE-Bench 70.8%、256K context、$0.20/$1.50 每百萬 tokens、$99 入門價。8 個子代理並行 git 分支 —— 競賽變四方。

xAI 於 5/14 把首款 agentic coding CLI Grok Build 推上公開測試。Elon Musk 在 X 上親自招募測試者。出貨水準是真的：SWE-Bench Verified 70.8%、256K context、8 個 subagent 並行於獨立 git 分支，入門價狠狠殺穿所有既有對手。

規格對照

規格	Grok Build	Claude Code (Sonnet 4.6)	OpenAI Codex
SWE-Bench Verified	70.8%	~70%	~68%
Context	256K	1M（Sonnet 4.6 large）	200K
API 輸入	$0.20 / 1M	$3.00 / 1M	$1.50 / 1M
API 輸出	$1.50 / 1M	$15.00 / 1M	$10.00 / 1M
訂閱	$99/月入門、$299/月標準	$20–$200/月	$20–$200/月
並行子代理	8 個並行	子任務派生	子任務派生

API 定價是最猛的部分。輸入 每百萬 $0.20 比 Claude Sonnet 4.6 便宜 15 倍、比 OpenAI Codex 便宜 7.5 倍。輸出 每百萬 $1.50 分別便宜 10 倍與 6.7 倍。

8 個子代理的設計

結構性的下注：

Plan mode 需要先核可才寫檔案。 Agent 先輸出結構化計畫（步驟、檔案、預期 diff），使用者按下核可後才開始執行。
子代理在獨立 git 分支上派生。 每次最多 8 個並行。每個處理一個獨立子任務 —— 一個單元測試、一個 refactor 分支、一個調查 —— 完成後合併回來。
衝突解決交給使用者。 當並行分支動到同一個檔案，agent 會把兩個 diff 都呈現出來、問你保留哪個，而不是自己猜。

心智模型的轉變：寫程式不再是「一個 agent 慢慢做一件事」，而是「8 個 agent 各自在 sandbox 內做 8 件事」。能不能省下 wall-clock 時間，完全取決於你的任務拆得乾不乾淨。

跟既有作品比，哪些是新的

Anthropic 在 Claude Code 推出 sub-agents（Agent 工具）—— 但預設是循序執行，要明確指定才會並行。
OpenAI Codex 推出多檔編輯與背景任務 —— 一樣預設單執行緒。
Grok Build 預設多分支並行。 這是新的結構選擇。能否一般化 —— 或只是製造一堆半成品分支 —— 是仍待經驗驗證的問題。

定價戰術

$99/月跑 6 個月 vs $299/月標準價，是刻意的搶地。xAI 在做所有後進者都會做的事：用毛利換市佔。算術：

一個團隊用 Claude Code $200/月 × 10 個席次 = $2,000/月
同一團隊用 Grok Build 入門價 = $990/月
省下：10 人團隊年省 $12,000 美元

如果 Grok Build 在日常任務上跟 Claude Code 打平（benchmark 分數說不了全部 —— 還是開放問題），每席經濟學就會迫使各家評估。風險在 6 個月後續訂時要回 $299 —— xAI 押注的是切換成本（codebase context、prompt 調優、工作流的肌肉記憶）會在便宜窗口關上前把客戶鎖死。

通路與安裝

通路是 x.ai/cli —— Anthropic 和 OpenAI 都用同樣方式。沒有 App Store 戰、沒有 MDM 摩擦，但也沒有企業採購的故事。產品先打個人開發者與小團隊；企業 SKU 應該還鎖在 xAI 還沒推出的 SSO + 稽核日誌方案後面。

Practitioner note

對已經用 Claude Code 或 Codex 的團隊：

第一天不要切換。 SWE-Bench 跟現實任務品質只有粗略相關。誠實的測試是：把上週 5 個已合併的 PR 拿給 Grok Build 跑，跟既有工具比怎麼處理。挪兩個小時，結果比你想的更快會分曉。
要評估的是 8 子代理設計，不是價格。 如果你的工作量天生可拆（如：大型 refactor 加測試、為多個框架產生實作、平行探索競爭設計），Grok Build 的結構選擇就有意義。如果不是（單檔修改、循序 debug），並行只是多餘的 overhead。
Plan-mode workflow 可移植。 如果你的團隊已經訓練成「先讀 agent 計畫再核可」，Grok Build 的核可閘就合身。如果團隊習慣 yolo 改動，這個閘會變成摩擦。先存在的紀律才是關鍵。

被低估的角度：dev-tools coding-agent 市場現在是四方商品化競賽。 當 SWE-Bench 分數在四家供應商間聚集到 68–71% 帶、API 價差到 15 倍，瓶頸就從模型品質轉成整合深度 —— agent 能多熟地讀你的 codebase 慣例、測試套件、CI、團隊規範。未來 18 個月的競爭是哪家供應商在你既有技術棧內做最深的勾子，不是哪家把 benchmark 多刷 2 分。