Grok Build Workflows 以最多 1,024 個代理拆解程式任務，加入分階段驗證與可續跑狀態

SpaceXAI 於 7 月 23 日為終端程式代理 Grok Build 推出 Workflows，將原本以單一對話推進的工作方式擴充為可程式化的多代理執行圖。使用者只需描述目標，系統便會產生一段編排腳本，定義工作階段、各階段要啟動的代理，以及中間產物如何傳遞和彙整；官方示範把大型 pull request 審查拆成取得上下文、專項審查、對抗式驗證及結果排序四個階段。

每次執行預設可使用 128 個代理，大型任務上限為 1,024 個。每個代理從乾淨、聚焦的上下文開始，適合把大量議題分類、逐路由權限稽核或跨模組審查分割為相互獨立的子工作。系統會保存已完成階段及個別代理的 token 用量，暫停後可續跑而不必重做；穩定的流程可存入專案的 `.grok/workflows/`，成為團隊共享、可帶參數呼叫的斜線指令。內建的 `/deep-research` 也採取先平行蒐集、再驗證來源的結構。

技術上的變化不只是「多開幾個代理」，而是把上下文隔離、扇出、聚合與複核提升為編碼代理的一級抽象。這能降低單一超長上下文造成的注意力稀釋，也讓驗證代理在未受原始解法影響的情況下重新檢查結論。Grok Build 的 Rust 代理執行環境與 TUI 已在 GitHub 以 Apache 2.0 公開，但公開儲存庫由內部 monorepo 定期同步，不保證涵蓋託管工作流後端的全部實作。

工程團隊仍應注意，代理數量增加不等於獨立證據增加：共用模型、提示或錯誤上下文可能讓數百個代理產生高度相關的誤判。官方也未提供與單代理相比的通過率、延遲、token 成本、重試策略或沙箱隔離數據。下一步值得觀察的是工作流定義是否具穩定格式、能否離線執行，以及驗證階段能否接入確定性的測試與安全掃描器，而不只依靠另一個模型判斷。