SpaceX 工程师的 AI Coding 玩法太牛了， 200 多个 Agent 并行！

今天看到 SpaceXAI 工程师 Lingxi Li 分享的一篇文章，收益匪浅：《Grok Bot for Engineering》。

简单分享一下，这篇文航里几个很夸张的数字：有团队成员一个月提交了 2,000 多个 PR；作者以前最多手动管理 15 个 Cloud Agent，现在这套系统同时跑着 200 多个。

当然了，这些数字来自产品团队自己的分享，目前没有独立评测，普通团队大概率也复制不了这个规模。

我更想弄明白的是，15 到 200 之间多了什么。

多开几个 Codex、Claude Code 或 Cursor 任务不难。麻烦从任务跑起来以后才开始：这个在等权限，那个卡在测试，还有一个交了 PR，却没人检查截图和 Diff。

Grok Bot 给出的答案是：在 Cloud Agent 前面再放一层工程 Bot。

200 个 Cloud Agent 前面站着 5 个工程 Bot

这里的 Bot，指 Grok Bot 里长期运行、带着岗位记忆和工具权限的 AI 角色。工程 Bot 接任务、创建并跟进 Cloud Agent，Cloud Agent 则进入代码库修改和测试。可以简单理解为：前者带队，后者干具体任务。

作者给五个工程 Bot 分了长期负责的领域。Baltata 管移动端共享层和 iOS，Shaoruru 管桌面端与 CI/CD，Hogan 处理基础设施和归属不明确的问题，Craig 负责 Android，Quill 则盯 Agent Harness。

每个 Bot 都有自己的记忆，能装下的上下文也有限。让它长期守着一个领域，发任务时带上的规格、设计原则和 Skill 会更具体。

比如一条 iOS 任务进来，Baltata 会创建 Cursor Cloud Agent，把任务说明、相关 Skill 和验收要求一起发过去。Cloud Agent 进代码库修改、测试、提交 PR；Baltata 留在外面读运行记录，卡住时补消息，方向跑偏时直接打断。

作者不再逐个守着任务窗口。产品取舍、权限不足以及影响范围较大的修改仍然会回来找人，其余运行中的小问题由工程 Bot 继续追。

原文给视觉任务定了一个很具体的条件：截图里必须真的出现需求要求的变化，最好还有修改前后的对照。代码提交了，页面却没跑通，或者截图答非所问，Cloud Agent 还得继续改。

这和我在《AI 编程实战指南：Claude Code、Cursor、Codex、Trae 使用技巧与面试题》里反复提到的一点一样：AI 回复"已经修复"，不能当作验收结果。

任务发出去之前，可以把交付物直接写在末尾：

diff 复制代码

交付前请自查：
- 使用项目现有命令运行相关测试，贴出命令和结果。
- 页面改动提供前后截图，截图里要能看到需求点。
- 简要说明 git diff 涉及了哪些文件。
- 跑不通就继续排查；被权限或环境卡住，再写清阻塞。

截图只能证明页面确实变了，代码质量还要看测试和 Diff。Agent 连项目都启动不了时，开再多任务也只会多出几个等待人工处理的窗口。

任务跨过一次会话后，光看聊天记录很难知道它停在哪。作者让工程 Bot 共同维护一个 Notion 数据库，每隔 30 分钟检查其中的 PR：CI 有没有失败、是否出现合并冲突、Bugbot 和安全告警是否成立。

发现问题，工程 Bot 就找到原来的 Cloud Agent 继续处理，并把任务改回 Working。CI、冲突和告警都处理好以后，状态才会变成 Ready for Review，接着再跑一次独立代码审查。

这张表解决的是"过一会儿还能不能接着干"。个人项目不一定要上 Notion，在 TASKS.md 或 Issue 里留下当前状态、阻塞、下一步和验收材料就够了。"移动端快照失败"后面最好跟着失败命令和对应 PR，只写"测试有问题"，换个会话还是得重新查。

Jenny 是这支队伍里唯一不写代码的 Bot。每天凌晨 5 点，它分别和工程 Bot 做一次 1:1，过一遍 Playbook 和阻塞，也负责给新 Bot 做入职。

某个 Bot 过早结束任务，Jenny 会回看它当时的判断，找到漏掉的步骤，再更新 Playbook，并把变化告诉其他 Bot。下次碰到同类任务，新的规则已经在上下文里了。

普通项目用不着专门做一个 Jenny。假设 Agent 连续几次跑错测试命令，把正确命令和适用目录写进 AGENTS.md；要是漏掉的是合并前必须执行的检查，就让 CI 卡住；Code Review 总漏权限问题，再补一份专门的 Review Skill。

密钥、生成目录这类明确不能碰的东西，适合交给权限规则、Hook 或 Sandbox。聊天里补一句提醒只管当前会话，下一次任务未必还记得。

下一次把任务交给 Codex、Claude Code 或 Cursor 时，我会先补齐测试命令、截图或 Diff 这类完成证据。任务中断前，再往 TASKS.md 或 Issue 写下当前 PR、失败命令和下一步。

第二天回来，如果不用重读整段聊天就能继续，这一步才算有用。连续跑过几次，再加一个独立 Reviewer，只看 Bug、安全、兼容性和测试缺口。

定时巡检、自动提交 PR 和自动合并可以往后排。支付、权限、数据迁移和生产配置仍然由人确认关键判断，并保留操作记录和回滚方式。

此时 Agent 可能仍然只有一两个。先把这一两个任务跑到"能接续、能验证"，再增加并行数量。

更多 AI 应用开发和 AI 编程内容，我集中整理在《AIGuide：AI 应用开发、AI 编程实战与面试指南》里。