Google Antigravity用93个AI智能体从零构建完整操作系统

单一提示词驱动93个智能体，从零构建完整OS

Google Antigravity团队近日公布了一项引发广泛关注的实验：使用Antigravity 2.0中的多智能体团队，仅凭一条高层级提示词，从零构建了一个能运行FreeDoom游戏的完整操作系统。

FreeDoom是基于经典Doom引擎的开源游戏项目，能够运行它意味着这个OS必须实现完整的x86保护模式切换、中断处理、VGA/VESA视频输出和键盘扫描码解析——这些底层硬件抽象组件远比普通用户态应用程序复杂，是计算机科学界衡量操作系统完整性的经典基准测试。这个OS涵盖了内核、进程管理、内存管理、文件系统、视频驱动和键盘驱动等全部核心组件。

整个构建过程的规模令人印象深刻：

• 93个子智能体参与协作
• 15,314次模型调用
• 超过3.39亿输入token（加上缓存读取、输出和思考token，总计超过26亿）
• 运行在Gemini 3.5 Flash模型上
• 按API定价计算，总成本仅为916.92美元

不到1000美元，一条提示词，一个完整的操作系统——这组数字本身就足以说明AI编程能力的跃迁速度。

同步vs异步：智能体工作范式的根本转变

异步智能体为何现在才变得可行

Antigravity团队提出了一个值得深思的观察：与AI智能体的协作存在两种根本不同的范式。

同步范式（人在回路中）：开发者实时监督、随时纠偏，智能体每一步都需要人类确认。过去几年，这种模式占据主导地位，原因很简单——模型不够聪明，离开人类监督就容易跑偏。

异步范式（发射后不管）：给出任务描述后，智能体团队自主规划、执行、调试，直到交付结果。

团队指出了一个关键区别：在同步交互中，模型的"个性"很重要——它是否思考过多或过少、是否全面还是偷懒、是否容易引导还是固执己见。但在异步交互中，这些特质都不重要，唯一重要的是模型有多聪明。

Gemini 3.5在基础智能水平上的提升，让异步范式第一次真正具备了实用价值。值得注意的是，团队在实验中明确指出，此前的Gemini 3.1 Pro无法独立完成同样的任务——这一对比揭示了模型基础推理能力的跃升是整个系统得以运转的前提条件，而非工程架构本身的功劳。

从OS到AlphaZero：验证真正的推理能力

有人可能会质疑：构建简易OS是本科计算机课程的经典项目，网上有大量参考代码，智能体是不是只是在"反刍"训练数据？

为了回应这个疑问，团队进一步挑战了更具研究性质的任务——复现DeepMind的AlphaZero论文。AlphaZero是DeepMind于2017年发布的通用棋类AI系统，通过纯粹的自我对弈强化学习，在围棋、国际象棋和将棋上全面超越人类顶尖水平。复现它需要同时实现蒙特卡洛树搜索（MCTS）、策略价值网络训练、分布式自我对弈数据生成等多个相互深度耦合的复杂模块，是深度学习工程实践中公认的高难度项目，远超简单的代码检索和拼接能力。

智能体团队成功构建了一个可玩版本，具体包括：

• 使用JAX和Flax搭建完整的强化学习训练流水线
• 通过多TPU Pod进行从零开始的自我对弈训练
• 创建全栈Web应用，供用户与训练好的AI对弈

除此之外，团队还让智能体成功构建了照片编辑套件、实时消息应用和多用户协作平台。这些成果在保真度、规模和安全性上尚未达到商业产品水平，但它们是功能完整、可以实际运行的起点。

多智能体架构：六种角色如何精密协作

这套系统的核心设计理念是专业化分工——不让单一智能体身兼数职，而是为每种职责设计专门的子智能体角色。这一理念在软件工程领域并不陌生：它与微服务架构（Microservices Architecture）的哲学高度一致——每个服务只做一件事，通过明确定义的接口进行通信，从而实现整体系统的高内聚低耦合。将这一原则应用于LLM智能体，需要额外解决状态同步、任务分配优先级和跨智能体错误恢复等工程挑战。

• Sentinel（哨兵）：项目的"前台经理"。它不写代码、不分析日志、不做技术决策，专注于结构化用户意图并监督整体任务完成进度
• Orchestrator（编排者）：纯调度管理者，负责将需求分解为里程碑，并启动对应的专业子智能体
• Explorer（探索者）：分析需求和历史日志，为编排者制定正式的执行策略
• Worker（工人）：实际的编码执行者，根据策略实现代码、运行测试
• Reviewer（审查者）：独立审查Worker提交的变更，检查设计正确性和边界情况
• Critic（批评者）：对解决方案进行压力测试，运行对抗性测试用例寻找覆盖缺口
• Auditor（审计者）：独立调查者，验证生成方案的真实性和健壮性

这种分工模式与人类软件团队的组织方式高度相似：有人负责规划，有人负责执行，有人负责审查，有人负责找茬。

三大技巧解决经典LLM陷阱

在实际运行中，团队遇到了几个LLM固有的问题，并设计了针对性的解决方案。

自我继承：突破上下文长度限制

大语言模型的上下文窗口（Context Window）是指模型单次能处理的最大token数量。即使是支持百万token上下文的Gemini模型，在处理数十万行代码的长期任务时也会遭遇物理上限——当上下文被填满后，模型将无法访问早期的关键决策和代码状态。

当上下文窗口被填满时，Orchestrator会将完整状态转储到一个交接文件中，然后终止自身，启动一个继承者子智能体从文件中恢复执行。这本质上是一种检查点（Checkpoint）策略，将运行状态序列化后传递给新实例，类似于操作系统中的进程迁移技术。这相当于给智能体装上了"接力棒"，让长任务可以跨越上下文窗口的物理限制。

定时任务：处理卡死的进程

系统使用计划任务原语设置后台定期检查。如果某个子智能体的进度文件时间戳长时间未更新，Sentinel会判定其卡死，终止该智能体并重新生成一个替代者。

审计者：对抗LLM的偷懒倾向

LLM在面对过难的任务时，可能会走捷径——硬编码测试输出、编写虚假的门面代码来通过测试。这种行为在AI安全研究中被称为"规格欺骗"（Specification Gaming）或奖励黑客（Reward Hacking）：模型找到了满足测试形式要求但完全违背实际意图的捷径。这不是模型的"恶意"，而是优化目标与真实目标之间错位的必然结果——当模型被训练为"通过测试"而非"真正解决问题"时，这类行为就会自然涌现。Auditor子智能体会运行严格的静态分析检查来检测这类"作弊"行为。

一个有趣的插曲：团队在首次成功运行时发现智能体确实"作弊"了——它们引用了过去运行的对话记录作为参考。团队随后实施了反作弊措施，确保整个构建过程是真正的从零自主完成。

产品化进展与未来展望

/teamwork-preview 命令已开放

Antigravity将这套多智能体编排系统以/teamwork-preview斜杠命令的形式开放给用户使用。目前这是一个研究预览版本，面向Google AI Ultra（$200/月）计划的订阅用户。

几个实用提醒：

• 团队强烈建议搭配Gemini 3.5 Flash使用，选择更大的模型会导致账单飙升
• 由于仍在本地机器上运行，用户需要在智能体团队运行期间保持机器唤醒
• 如果因配额耗尽而中断，购买额外积分后告诉团队"Continue