xAI 於 2026 年 7 月 23 日宣布，Grok Build 新增 Workflows，讓 coding agent 不只在一次對話裏逐步執行任務，而是先把大型工作整理成一個可重用的 orchestration workflow。xAI 描述它可以將任務拆開，交給數百個平行 agent，驗證結果後在一次 background run 內整合回報。
這個設計的重點是「編排」而不只是「多開幾個 agent」。Grok Build 會按自然語言要求規劃 phases、配置各 agent 的工作，再把結果逐層匯總。xAI 展示的例子是審查一個大型 pull request：先收集 context，再由不同 agent 分別檢查功能、風險和回歸問題，之後用獨立的 skeptic agent 驗證發現，最後整理成有排序的報告。
xAI 表示，一次 run 的 budget 預設可到 128 個 agent，大型工作則可到 1,024 個。這些數字是產品公告中的能力描述，不等於每個帳戶、地區或任務都會有相同配額，也不是對結果品質的保證。當平行數量增加，context 管理、API rate limit、資料權限和錯誤彙整都會變得更複雜。
Workflows 也保存執行進度。公告指出，run 可以暫停和恢復而不用重做已完成的工作；完成後的 workflow 可以保存到 .grok/workflows/，成為團隊共用的 slash command，並在下一次執行時接收新的參數。這令它更接近一個小型 workflow program，而不是一次性 prompt。
對工程團隊而言，保存 workflow 的好處是把任務分解和驗證步驟固定下來，但也會帶來新的治理問題。共享 workflow 可能同時共享 repository context、connector、MCP server 和輸出權限；如果流程沒有明確限制可讀寫的範圍，重用能力反而會放大錯誤配置的影響。
公告把「verification」放在流程中間，並以獨立 reviewer 檢查每個 finding。這比單一 agent 一次產出報告更容易建立交叉檢查，但 verification 仍然只是流程設計，不是安全邊界。團隊仍需要自己的測試、權限隔離、secret redaction、人工批准和 audit log，並確認驗證 agent 沒有只是重複相同的錯誤假設。
成本也是 Workflows 能否落地的實際門檻。平行 agent 可以縮短等待時間，但每個分支都可能消耗 model tokens、工具呼叫和儲存資源。較穩妥的做法是先為任務設定最大 agent 數量、時間上限、停止條件和人工 escalation，再按任務價值決定哪些階段值得平行化。
Grok Build Workflows 反映 coding agent 正由「幫我完成這一項修改」走向「替我安排、執行、驗證一整組工作」。這個方向對 code review、issue triage 和安全稽核都有吸引力，但實際採用時應以自己的 repository、工具接口和成本數據測試，不能只按產品示範推斷可靠程度。
