xAI 上線 Grok Build 工作流：最多呼叫 1024 個智慧體併發幹活

如果你經歷過在 GitHub 上對付幾千行程式碼的超大 PR，或者面對堆積如山的上百個陳舊 issue，你肯定知道靠單個 AI 聊天視窗有多折磨：上下文塞滿後不是開始胡說八道，就是卡頓到讓人絕望。

xAI 在 Grok Build 中推出了名為 Workflows 的全新功能。說白了，它把 AI 從「單打獨鬥的聊天助手」，變成了「能隨時指揮上千個小兵的工程包工頭」。

讓上千個 Agent 並行幹活，還自帶質檢員

以往很多所謂的複雜任務，我們習慣在同一個對話方塊裡不斷給 AI 塞提示詞。Grok Build 的 Workflows 徹底換了思路，專為單個對話裝不下的複雜任務設計，比如稽核大型 PR 的每項功能、對最後 100 個 issue 進行分類分診，或者全庫審計某類特定 bug。

使用者只需要用自然語言說出大任務，Grok 就會自動將其規劃成一份執行指令碼，並拆解為不同的階段。比如先做背景梳理、再逐項審查、接著驗證，最後彙總。

在執行上，預設預算直接拉到 128 個 agent，遇上超大任務甚至能調動 1024 個 agent 並行跑在後臺。而且在整個執行期間，使用者的當前對話會話完全不受干擾，依然可以隨時做別的事。

每個 agent 都拿著乾淨且獨立的上下文，避免了上下文汙染。更有意思的是，計劃中可以內建獨立的「懷疑者」角色，負責在最終報告出爐前交叉核驗每一個發現。

任務進度即時儲存，哪怕中途暫停或重啟，也不會重複幹已經做完的活。輸入 `/workflows` 就能即時檢視各階段的推進情況，甚至還能精細監控到每個 agent 消耗了多少 token。

告別手寫指令碼，一鍵存成斜槓命令

最省心的地方在於，使用者完全不需要自己寫編排指令碼。Grok 會根據需求自動編寫程式碼，在正式啟動前先跑一輪冒煙測試，還會在多次執行之間自我最佳化。

一旦某個工作流跑得順手，你隨時可以把它儲存下來。存進 `.grok/workflows/` 就能直接同步給團隊成員，存進個人根目錄則能跨專案隨身攜帶。

儲存下來的工作流會立刻變成一個支援傳參的自定義斜槓命令。比如你跑順了一套 PR 審查邏輯，下次直接在命令列敲 `/pr-review 5137` 就完事了。

此外，官方還直接內建了 `/deep-research` 工作流。它會把調研課題分發給多個並行的調查 agent，逐一核實每個論點與來源，最後交出一份帶完整引用的研究報告。

為什麼重要

我們認為，xAI 這一步走得相當務實，切中了專業開發者最耗費精力的髒活累活。對於工程團隊來說，稽核複雜 PR 或全庫查蟲往往要耗費資深工程師幾天時間，現在交給上千個 agent 幾分鐘掃完，確實值得主力在 Grok Build 的團隊第一時間試用。

它的聰明之處在於把複雜的 Agent 編排門檻降到了極低。以往要把幾十個 agent 串起來，開發者得折騰各種複雜的編排框架或手寫繁複的排程邏輯，而 Grok 直接把指令碼生成、冒煙測試、錯誤校驗全部包辦，還順手封裝成了最順手的斜槓命令。

不過隱患也顯而易見。預設 128 個、最多 1024 個 agent 的併發規模，哪怕有 token 計數看板，跑一次大型任務消耗的算力和成本也絕非小數目。如果團隊沒有做好預算把控，賬單可能會非常驚人。另外，並行 agent 互相交叉驗證雖然能篩掉一部分淺層錯誤，但如果底層模型本身對某些隱蔽 bug 存在共同盲區，再多的「懷疑者」也可能給出整齊劃一的誤判。

從行業來看，AI 程式設計工具的競爭已經徹底從「程式碼行自動補全」升級到了「非同步多智慧體協同工程」。當 Grok Build 率先把千級併發排程常態化，Cursor、GitHub Copilot 以及各大模型廠商在工程化落地上勢必會面臨更大的跟進壓力。