Grok Build Workflows：AI 编程工具开始进入百 Agent 并行时代
过去一年 AI 编程工具的主流形态，是一个 Agent 接手一个任务：读代码、改文件、跑测试、提交结果。xAI 新发布的 Grok Build Workflows 把这个模式往前推了一步：AI 不只是执行任务，而是可以写 workflow，把任务拆开，分发给大量并行 Agent，再汇总验证结果。
官方描述里最关键的词是 fan out、parallel agents、verify results、save/reuse workflows。也就是说，Grok Build 不再只是“让模型帮我写一个函数”，而是试图变成一个可重复运行的工程流程系统。大 PR review、issue triage、代码库迁移、依赖升级、测试补齐，这些任务天然就适合拆成很多小单元并行处理。
这代表 AI 编程工具的竞争焦点正在变化。第一阶段拼补全，谁能更懂上下文；第二阶段拼 Agent，谁能自己改代码、跑命令；第三阶段开始拼编排能力：谁能稳定调度多个 Agent，谁能把流程沉淀为团队资产，谁能让人审核关键节点，而不是每次从一句 prompt 重新开始。
多 Agent 并行听起来很酷，但真正难的是工程化。并行 Agent 会带来冲突：多个 Agent 可能改同一块代码，结论可能互相矛盾，测试结果可能受环境影响。要把它做成可用产品，必须有任务隔离、结果归并、冲突检测、权限控制和可观察性。否则“百 Agent 并行”只是把混乱放大一百倍。
Grok Build Workflows 的另一个重点，是 workflow 可以保存为 slash command。这点很有产品意味。团队里真正有价值的不是某次 AI 回答，而是可复用的操作范式：检查安全风险、扫描无用依赖、统一改接口、补齐某类测试、生成迁移报告。当这些流程可以被保存和复跑，AI 编程工具就开始接近内部研发平台，而不是聊天窗口。
这对 Codex、Claude Code、Cursor、Devin 类产品都有压力。单 Agent 体验会越来越同质化，模型差异也会被快速追平。下一轮差异可能来自三个地方：是否能把复杂任务拆好，是否能让多个 Agent 安全协作，是否能把团队经验固化为 workflow。
我的判断是，Grok Build Workflows 值得重点跟踪，不是因为“128 个 Agent”这个数字本身，而是因为它把 AI 编程工具的形态从助手推进到调度系统。未来开发者可能不会只问“哪个模型写代码最强”，而会问“哪个平台最会组织一群 Agent 干活”。