xAI 發表 Grok Build 0.1:專攻代理式工作流程的程式模型,25.6 萬 token 上下文支援圖文輸入
xAI 於 2026 年 5 月 14 日發表 Grok Build 0.1,這是一款專為「代理式工作流程」(agentic workflow) 訓練的程式模型,支援文字與圖片混合輸入,上下文長度達 25.6 萬 token,鎖定多步驟、需要自主規劃與工具呼叫的軟體開發任務。
xAI 於 2026 年 5 月 14 日發表新一代程式模型 Grok Build 0.1。與過去單純「回答一段程式碼」的模型不同,這款模型明確標榜是為「代理式工作流程」(agentic workflow) 而訓練——也就是能在較長的任務鏈中自主規劃步驟、呼叫工具、讀取回饋並持續修正,而不只是一次性生成程式碼片段。官方公布的兩項關鍵規格是:支援文字與圖片混合輸入,以及上下文長度達到 25.6 萬 (256K) token。
技術意義:從「寫程式」到「跑流程」
代理式工作流程訓練意味著模型的優化目標,不再只是「這段程式碼對不對」,而是「這一連串動作能不能把任務完成」。這通常涉及模型在訓練階段被要求模擬呼叫外部工具(例如執行測試、讀取錯誤訊息、查閱文件)、根據結果調整下一步,並在多輪互動中維持對整體目標的掌握。25.6 萬 token 的上下文,大約可容納一個中大型專案的多個檔案內容,讓模型有機會在單一任務中「看懂」跨檔案的關聯,而不必被切成零碎片段個別處理。圖片輸入的加入,則讓模型能直接讀取介面截圖、架構圖或錯誤畫面的截圖,作為除錯或開發的輔助輸入,減少工程師手動把視覺資訊轉譯成文字描述的工作。
與前代及市場定位的比較
把「代理式」明確寫進模型定位,反映的是整個產業的重心轉移:過去一年多,程式模型的競賽已從「單題程式碼生成準確率」轉向「能不能獨立完成一整個任務鏈」。這與其他廠商近期推出的具代理能力程式模型方向一致,顯示這已成為業界公認的下一階段門檻,而非 xAI 獨有的實驗性嘗試。長上下文與多模態輸入的組合,也符合近期業界對「模型要能處理真實工程情境全貌」的共同要求——真實開發工作本來就混雜著程式碼、文件、截圖與錯誤日誌,單一模態、短上下文的模型越來越難滿足需求。
業界反應與待觀察之處
目前公開資訊集中在規格與定位描述,尚未有大規模第三方基準測試結果或實際部署案例佐證其代理式表現是否真正可靠。代理式工作流程最大的風險在於「多步驟中一旦某一步判斷錯誤,後續步驟可能持續放大偏差」,這正是業界目前對所有主打代理能力的模型最關注、也最謹慎評估的一點。實際可用性,仍需等待更多獨立測試與早期使用者回饋才能判斷。
對管理者的意義
對非技術背景的管理者而言,這則新聞的重點不在於評斷模型好壞,而在於留意一個訊號:AI 工具正從「幫忙寫一段程式碼」演進到「能不能被信任去跑完一整段流程」。若企業內部已有工程團隊在評估導入代理式 AI 工具,管理者可以主動問一句:這類工具目前是用在「輔助」還是「自主執行」的環節?多步驟自主執行的部分,是否有人在關鍵節點做審核,避免錯誤被層層放大。