Grok Build 上线 Workflows，一次编排上百个 agent 干活

是什么

Grok Build 新增了 Workflows 功能。用自然语言描述一个大任务，Grok 会自己拆解成编排脚本，分成若干阶段，每个阶段并行跑一批 agent，最后汇总成报告返回，整个过程在后台运行，不占用当前会话窗口。单次运行默认预算 128 个 agent，大任务可扩到 1024 个。运行状态用 /workflows 命令实时查看，能看到当前阶段和每个 agent 的 token 用量。

这和 Grok Build 自带的子 agent 机制不是一回事。子 agent 是遇到复杂任务时自动触发的并行委派，每个子任务有独立上下文窗口。Workflows 是把这套机制包装成可复用、可编排的完整流程，粒度更粗，规模也更大。

为什么

这个功能冲着单次对话装不下的复杂任务去。比如审查几十个文件改动的大 PR，把最近一百个 issue 挨个 triage 一遍，或者审计整个代码库里某一类漏洞。靠一轮对话推进，要么上下文爆掉，要么中途断了得从头再来。Workflows 把任务拆成互相独立的小块分别跑，还能插入交叉验证步骤，让一个 agent 的结论被另一个 agent 挑刺复核，再进最终报告。

怎么用

不需要自己写编排脚本，直接用自然语言描述需求即可，比如：

用 workflow 审查这个 PR 里的每个 feature 把最近 100 个 Linear issue 分类，给我一份 top 10 待办清单 审计所有路由处理函数有没有漏加权限校验，每条发现都要交叉验证

Grok 收到需求后自己生成编排脚本，先跑一遍 smoke check 再正式执行。跑通的流程可以保存复用，存在 .grok/workflows/ 里的随仓库同步给团队，存在 ~/.grok/workflows/ 的跟着个人走，保存后会变成专属 slash command，比如存下 PR review，以后就是一句 /pr-review 加 PR 号。

系统还内置了 /deep-research，拆给多个并行调研 agent，核对信源后给出带引用的报告。

评价和看法

把子 agent 包装成可保存、可复用的编排流程，是这次更新最值得关注的地方。能沉淀成团队共享的 slash command，才是长期效率提升的关键。128 到 1024 的预算听起来豪爽，实际效果取决于任务能不能被干净拆解，拆得不好，并行反而放大噪音。日常写代码，子 agent 的自动委派够用，Workflows 更适合批量化、需要交叉验证的场景。