Google Antigravity协调93个AI编程智能体，用12小时构建出一个能运行DOOM的操作系统内核。这次运行使用Gemini 3.5 Flash，处理了26亿个token，花费不到$1,000的API额度。这是大规模并行编程任务取得可见成果的一个具体案例。但仅凭这一点，还不能证明同样的任务在下一次运行中也能稳定成功。
内核构建证明了什么
内核是让程序得以在计算机上运行的核心软件。这次的目标是从零开始构建一个内核，并在其上运行DOOM，整个过程没有人工编写代码。最终的内核在Google I/O上现场演示了运行这款游戏。
| 指标 | 公布结果 |
|---|---|
| 编程智能体 | 93个子智能体 |
| 耗时 | 12小时 |
| 模型请求 | 超过15,000次 |
| 处理文本量 | 26亿个token |
| API额度 | 不到$1,000 |
token是模型读取或生成文本的单位。这些数字描述的是这一次运行的规模，并不是对未来项目价格或完成时间的估算。花费数字只涵盖API额度，并未完整计入项目的其他成本。
▲ 共同内核的并行开发
这一成果之所以重要，是因为任务远不止生成一个代码文件。多个智能体必须在数小时内朝着同一个成果协同工作。能够运行DOOM，比生成了多少文件更能说明进展，但它只检验了人们对内核的部分需求。
Antigravity如何协调工作
Google Antigravity通过/team命令提供Agent Teams模式。智能体是指能够为完成任务采取行动的AI系统，而不仅仅是返回一段文字回答。主智能体会评估请求，必要时询问缺失的约束条件，再把工作分配给各有专长的子智能体。这些子智能体可以在相互独立的代码工作区（即工作树）和隔离的执行环境中并发工作。主智能体还可以搭建一个定制界面，用来跟踪它们的进度。
这是Antigravity为大型任务提供的架构。不过，内核项目公布的数字并未说明那次运行中的每一个角色、每一项分工或每一次协调决策，只能确认该项目使用了93个子智能体和Gemini 3.5 Flash。Antigravity 2.0把代码编辑环境IDE与独立的Agent Manager分开，后者专门用于监督并发工作。
并行处理可以解释为什么一个项目能在12小时内发出超过15,000次模型请求。但这并不意味着每一次请求都推动了内核的进展，也不意味着增加智能体数量总能改善结果。任务拆分、协作和错误处理，仍是多智能体系统有待改进的领域。
演示成功不等于可复现性验证
证明项目完成的最明确依据，是该内核在Google I/O现场演示中运行了DOOM。这只能支持一个有限的结论：生成的一个系统在演示环境中运行了这款游戏。资源总量描述的是那次运行的消耗。
▲ 已演示的成果与待验证的问题
要判断可复现性，需要构建步骤、环境规格、测试矩阵以及重复运行的结果，而一次演示无法提供这些。缺少这些细节，读者就无法从这个案例判断同样的流程成功的频率，也无法判断另一个团队能否在相同条件下复现这一结果。运行一款游戏，也不足以证明内核的整体质量，比如在其他程序上的表现或长期使用的情况。这些只是演示所能证明范围的局限，并不意味着该内核未能通过这些测试。
Google DeepMind还把Antigravity用于另一类并行工作：比较模型评估结果。在这一工作流程中，一个研究智能体会针对结果之间的差异提出约100个解释，再由子智能体同时逐一核查。这个例子说明了该系统为何重视任务委派，但它与内核成果是两回事，也无法证明内核成果的可复现性。
可以带走的启示
DOOM案例表明，一组相互协调的编程智能体在公布的时间和API额度内，做出了可运行并经过演示的成果。Antigravity团队将其视为长时间智能体工作如今已具备经济可行性的证据，同时也承认，每天花费数百乃至数千美元生成一个内核目前还不现实。这次运行在可复现性和软件整体质量方面仍留下了重要疑问。评估类似的由智能体构建的项目时，应把实际演示的表现与资源数字分开看待，并在把一次成功视为可靠方法之前，先查看构建细节、测试和重复运行的结果。