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、工具接口和成本数据测试，不能只按产品示范推断可靠程度。
