用 Google Antigravity 从零构建操作系统（及更多工程实践）

我们让 Google Antigravity 2.0 中的 Agent 从零构建一个能够运行 FreeDoom 的功能完备的操作系统，涵盖从内核到进程与内存管理、文件系统，再到视频和键盘驱动程序的所有部分。由多 Agent 团队攻克数周冲刺（Sprint）规模项目的未来已近在眼前。

核心论点

与 Agent 协作通常可以分为两大类——同步模式（即人机协同）和异步模式（即下达指令后交由其自主执行）。直到最近，前一类模式一直占据主导地位，这有着充分的理由：模型的智能程度还不够高，人类在没有一定程度的监督和引导下，很难放心地通过编排将任务完全交给它们。人机协同仍然是一种关键范式，因为就像任何复杂的软件项目一样，需求规范总是存在模糊之处，而且许多新挑战只有在取得一定进展后才会显现出来。尽管如此，Gemini 3.5 系列模型在智能水平上迈出了重大一步，让我们对 Agent 独立、异步地攻克复杂任务的可能性倍感振奋。

这揭示了这两种范式之间的鲜明差异。在同步交互中，模型的“性格”和行为方式至关重要。Agent 思考得够深入还是过度思考？是全面周到还是过于偷懒？是听从引导还是固执死板？它是高效直接，还是会在途中采取无关、多余的步骤？这些因素独立于原始智能水平之外，即使每种过程排列最终给出相同的输出，它们也会直接影响用户的信心。

而在异步交互中，这些通常并不重要。唯一重要的是模型有多聪明，哪怕为了充分挖掘其潜力需要花费更多精力去构建编排机制。

有一件事我们非常确定：Gemini 是一个相当聪明的模型。每一项基准测试和内部 A/B 测试都印证了这一点。这让我们产生了一个简单的问题：如果我们构建一个由具有不同角色和通信机制、并行工作且运行在 Gemini 之上的 Antigravity Agent 系统，我们究竟能将它推向多远？这对于未来将多 Agent 团队投入生产、异步处理更具分量、更具挑战性的任务又意味着什么？

操作系统……

我们就不卖关子了。我们直接让它从零开始构建一个操作系统。结果成功了。整个过程动用了 93 个子 Agent、15,314 次模型调用，以及超过 3.39 亿个输入 Token（如果算上缓存读取、输出和思考过程，总计超过 26 亿个 Token）。我们甚至可以在它上面玩《毁灭战士》(Doom)。但代码本身并不是最令人兴奋的部分。

这一切是通过单个提示词、仅使用 Gemini 3.5 Flash 完成的。

这不仅（a）充分展示了 Gemini 系列模型（哪怕是 Flash 级别）的内在智能已经达到了何种高度（Gemini 3.1 Pro 此前无法做到这一点），而且（b）表明在经济上更加可行的 Agent 团队生产化落地已经近在咫尺。按照 API 定价计算，构建这个操作系统的成本仅为 916.92 美元。

当然，这个操作系统并不完美，因为它是根据单个提示词生成的，没有任何来自人类的额外指导或纠偏。代码质量无法立即达到资深开发者的同等高水准。它不支持浮点运算、硬件加速、复杂多线程、沙盒隔离、JIT 编译、复杂音视频解码，以及许多其他将基础可用操作系统提升到现代操作系统水准所需的组件。

但仅凭一个高层级提示词，且成本不到 1000 美元就能做到这一步呢？

……以及更多作品

就像你现在可能的想法一样，我们起初也并未完全信服。网上有大量公开的基础可用操作系统实现代码，这也是大多数计算机科学本科课程中的常见项目。这究竟是真正的智能，还是仅仅在背诵复述训练数据？

顺便提一个有趣的插曲：当我们第一次让 Agent 端到端构建出这个操作系统时，它完成得快得令人起疑。后来我们发现，原来是因为我们忘了清除之前运行的对话记录，Agent 通过查阅历史对话“作弊”了。为了确保真正的从 0 到 1 自主构建，我们最终实施了防作弊措施与安全护栏（稍后会详细介绍）。在全新的一次运行中，Agent 以光明正大的方式成功构建出了我们所描述的完整可用操作系统。

回到操作系统任务的话题，我们想给 Agent 布置一些更具“研究性质”的任务。它能否实现极具开创性的 AlphaZero 论文，并亲自构建出一个精通史上最复杂棋类游戏的 AI？

Agent 团队再一次成功了，它们复现了一个轻量但可对弈的 AlphaZero 版本。在几乎没有人类干预的自主运行状态下，Agent 使用 JAX 和 Flax 构建了强化学习流水线，利用多 TPU Pod 通过自我对弈从零开始（tabula rasa）训练了一个 ResNet 模型，随后还创建了一个沉浸式的全栈应用供用户与该 AI 对弈。以下是最终生成的全栈应用界面：

这绝不是简单的死记硬背。Agent 构建了一条高度灵活的流水线，能够从较小规模的本地训练循环无缝扩展到用于高强度 9x9 棋盘训练的多 TPU Pod。但就像操作系统任务一样，真正令人兴奋的地方在于加深了我们对“当配备 Agent 团队时，哪些任务属于能力前沿之内”的理解。在这个案例中，我们证明了复杂的机器学习工程可以以传统成本的一小部分实现自动化管理。

在这些案例之后，我们又让 Agent 构建了照片编辑套件、实时通讯应用以及多用户协作平台，全都取得了同样的成功。虽然这些成果在保真度、规模和安全性上还无法与现有的商业解决方案相提并论，但它们都是功能完备、切实可用的起点，而这本身就是根本性的突破，令人无比振奋。

整体架构设置

让我们拆解一下编排这些 Agent 团队的方法。我们不会假装这只用了几行提示词（实际上最终写了数千行），但最令人兴奋的关键点在于：我们仅仅复用了如今在 Antigravity 2.0 中已经开放的核心 Agent 原语，例如并行运行的子 Agent、异步任务和钩子（Hooks）。我们并没有使用任何特殊定制版的产品来做到这一点。

我们没有让单个 Agent 身兼数职，而是创建了一系列具有专门目标和约束条件的子 Agent 类型：

• 哨兵（The Sentinel）：项目的“前台经理”，自己不编写代码、不分析日志，也不做技术决策。它完全专注于梳理用户意图、派生编排器（Orchestrator）并监督整体任务的完成情况。
• 编排器（The Orchestrator）：一个仅负责调度的管理者（即自己从不编写代码或执行构建）。它专注于将需求拆解为里程碑、启动其他专业化子 Agent 并综合汇总报告。
• 探索者（The Explorer）：分析需求和历史日志，为编排器编写正式的执行策略，但自己从不编写代码。
• 工作者（The Worker）：真正负责编码的角色，用于实现策略、构建代码并运行测试。
• 审查者（The Reviewer）：独立审查工作者的代码变更，检查设计正确性、边界情况以及接口契约合规性。
• 评判者（The Critic）：对解决方案执行压力测试并运行对抗性测试，以找出测试覆盖率中的漏洞。
• 审计员（The Auditor）：一名独立的调查员，负责验证所生成解决方案的真实性与稳健性。

虽然并行工作的专业化子 Agent 是涌现出团队协作行为的基础，但为了应对大语言模型（LLM）执行过程中的经典陷阱，我们还采取了一系列巧妙机制：

• 自我继任（Self-succession）以应对上下文长度限制：面对如此庞大复杂的任务，上下文窗口会迅速填满，因此编排器（Orchestrator）会追踪其累计派生的子 Agent 数量。一旦达到上限，它会将完整状态转储到交接文件中，终止自身的后台任务，并调用一个具有相同目标和权限的子 Agent。这个继任子 Agent 会从交接文件中平滑地恢复执行，而父级编排器则终止运行，从而最大限度地减少上下文长度限制带来的影响。
• 定时任务（Crons）以处理卡死或阻塞的进程：在如此多的并行进程下，如果采用朴素的实现方式，一旦某个子 Agent 陷入死循环、在编译期间挂起或卡在阻塞式 I/O 上，就会拖垮整个团队。我们使用全新的计划任务原语设置了一个后台周期性运行的 Cron 任务，用于检查各个子 Agent 写入的进度文件；如果时间戳过久未更新，哨兵（Sentinel）就会终止该进程并重新派生它。
• 应对大语言模型“偷懒”的审计员：众所周知，如果一项任务难度过高，大语言模型可能会硬编码测试输出或编写一个伪造的包装层（mock facade），在不真正实现核心逻辑的情况下让测试蒙混过关。审计员（Auditor）子 Agent 类型会对代码运行严格的静态分析检查，不局限于测试结果看似通过的表象，而是深入代码内部检测作弊行为。当编排器认为自己已完成所有里程碑时，在哨兵通知用户之前，系统会强制执行最后一次审计。

在这一过程中，我们学到了许多关于如何对待 Agent 的基础知识，从而构建出高度自主、具备自愈能力的 Agent 团队，成功攻克复杂的代码库目标。虽然目前仍有一些粗糙之处，还有许多东西需要探索，但早期的成果令我们倍感鼓舞。

/teamwork-preview

正如上一节所提到的，所有这一切都是使用今天在 Antigravity 中新推出的核心 Agent 原语、结合今天同步上线的 Gemini 3.5 Flash 编排而成。我们正通过一个全新的斜杠命令 /teamwork-preview，向用户开放这一完全相同的 Agent 团队编排能力。

这是一项研究预览功能，我们将持续迭代编排机制与 UI 界面，以提升性能、可靠性和可观测性。这些 Agent 遵循你为调用 Agent 团队所在项目设置的相同权限和其他安全考量。由于它目前仍在你的本地机器上运行，因此即使你没有主动监控，也需要在 Agent 团队运行期间保持机器处于唤醒状态。

/teamwork-preview 现已作为研究预览功能，向订阅每月 200 美元 Google AI Ultra 方案的 Antigravity 用户开放，可搭配 Gemini 模型使用。

我们强烈建议将 /teamwork-preview 与 Gemini 3.5 Flash 搭配使用，否则你可能会产生相当高昂的账单费用。即便在 AI Ultra 方案上使用 Gemini 3.5 Flash，我们也建议你额外购买一些 AI 额度，因为仅运行一两个任务（甚至视复杂程度，可能在第 1 个任务进行到一半时）就会耗尽你整周的配额。如果 Agent 团队因配额或额度耗尽而在中途停止，你只需购买更多额度，然后告诉团队“继续”（Continue），它就会从中断的地方无缝恢复执行。

我们非常期待看到用户使用这些 Agent 团队开展探索实验。欢迎告诉我们你在哪些场景取得了成功，以及哪些地方仍有待改进。

展望未来

虽然我们在释放这些模型的原始智能方面取得了进展，但仍有大量工作要做，也有许多重要问题亟待解答。正如我们在本文开头提到的，与 Agent 异步协作确实需要一种不同于同步工作流的用户体验。然而目前，这两者的体验还是相同的。

未来的体验应该是什么样子？这是否会减少开发者测试和验证所交付代码的投入，我们又该如何避免这种情况？随着模型不可避免地变得更加聪明，我们是否需要把整套编排机制推倒重来、重新思考？

尽管这些问题宏大、复杂，甚至坦率地说有些令人望而生畏，但我们首先为那些积极的应用前景感到兴奋——现在有了一种（相对）经济实惠的方式，可以将具有挑战性（且定义明确）的重要工作块委托给异步 Agent 团队。我们相信，这能进一步激发人类的集体雄心，帮助整个社会共同应对当今人类面临的一些最复杂的挑战。

立即在 Google Antigravity 2.0 中试用 /teamwork-preview：