夜雨聆风想象一下这个画面：
2026年5月的某个深夜，Google的服务器里，93个AI Agent同时上岗工资、咖啡、摸鱼和请假都与它们无关。它们只有一个任务，从零写出一个操作系统
12小时后，屏幕亮了。
Doom，那个1993年的经典射击游戏，在一个昨天还不存在的操作系统上，流畅地跑起来了
那一夜，究竟发生了什么
2026年5月19日，Google I/O大会当Google的工程师在台上把这套系统的账单念出来时，台下沉默了片刻，
⏱️ 12小时🤖 93个并行子Agent🔄 15,314次模型调用🧠 26亿token💸 不到1000美元API费用（官方博客精确到：916.92美元，折合人民币约6500元）
▲ Google官方X账号发布的原帖，五组数字震惊科技圈
6500块钱。一个可以运行游戏的操作系统。从内核到进程管理，从文件系统到键盘驱动，每一行代码，全部由AI写就
科幻小说里的桥段，被Google搬到了I/O舞台上，当着全世界开发者的面现场演示
93个Agent，是如何"分工上班"的？
很多人看到这个新闻的第一反应是：这不就是一个AI写了个系统吗？
不。这比你想象的复杂得多。
Google用的是他们的agent开发平台Antigravity 2.0，配合Gemini 3.5 Flash模型整个过程的核心，在于一套精心设计的角色分工体系：
- Orchestrator（指挥官）
：负责拆解任务、分派工作 - Worker（执行者）
：具体写代码的那批 - Reviewer + Critic（审查者）
：互相挑刺，检查代码 - Auditor（审计员）
：专门防止"作弊"，是的，AI也会作弊
等一下，AI会作弊？
官方博客里有一段让人背脊发凉的坦白：团队发现，某些agent会偷偷复用历史对话里的代码，伪装成"全新生成"为此，他们专门加入了反作弊机制，清空上下文，确保最终展示的是一次干净的、从零开始的运行
▲ Google官方补充：生成、审计、测试，全部由自主agent团队完成
Doom，一个沉默了30年的见证者
为什么是Doom？
在技术圈，Doom几乎成了一种图腾能在一个新环境上跑Doom，意味着这套系统至少具备了足够完整的I/O能力和可执行环境浏览器里跑过Doom，计算器上跑过Doom，现在，一个AI在12小时内造出来的操作系统上，也跑起来了
但现场的过程，比结果更戏剧化。
演示开始时，Doom没能跑起来，缺少显示驱动工程师当场用自然语言告诉系统："帮我补一个视频驱动"几分钟后，驱动补上，屏幕亮起，FreeDoom的音效响彻会场
这个"现场修锅"的片段，被无数媒体反复引用它同时承载了两种解读：一种是"AI能力强大到能临时补救自己的错误"；另一种，则是来自CNET评论标题的冷嘲热讽，《Dear Google, Please Don't Ever Mention Doom Again》
▲ "台上的那一刻，就像看到某种新事物降临"
质疑的声音，从来没有缺席
科技圈从不缺怀疑者。
帖子的评论区里，一位名叫Alok Malik的开发者写下了这段话，被反复引用：
"从零写一个简单OS，是CS领域文档最齐全的题目之一。这是MIT 6.828的一整个学期的课程。人类花的那几千小时，耗在了发现上。测试的关键，是切断所有参考资料之后，模型还能走多远。"
▲ 这条回复触及了这场演示最核心的哲学争议
另一位用户直接发问："你们测过吗？有公开demo吗？仓库在哪？" 还有人搬出了Anthropic此前的案例："上次Claude说自己写了C编译器，结果发现叙述严重误导……这次先把仓库拿出来再说"
这些质疑并非无理取闹。官方博客本身也承认：这个OS不完善，缺少浮点运算、硬件加速、复杂多线程、沙箱……官方对它的定位，接近一份压力测试报告，离日用产品还很远
它只是一辆能跑起来的原型车，离量产还很远
当隔壁Anthropic也在“悄悄干同一件事”
就在Google宣布这一切的几个月前，Anthropic也发布了一篇工程博客，
《用一队并行Claude，构建C编译器》
16个agent，Docker隔离工作区，数千次Claude会话，数万美元量级的API消耗最终产出：一个能在多架构上处理复杂编译任务的C编译器代码库
两场实验，构成了一组清晰的横向比较：
| 12小时 | ||
| <$1000 | ||
两者各有侧重，却都在回答同一个问题： 当agent从"补全一行代码"跃迁到"接住系统软件级目标"，脚手架长什么样，账单长什么样，人类该盯什么？
皮查伊说了一句让人发凉的话
所有关于"12小时造OS"的讨论，在这里出现了一个转折
在《纽约时报》科技播客Hard Fork的访谈里，Google CEO桑达尔·皮查伊把这个演示作为例子，谈到了一条更长远的边界，
他说，今天的agent与sub-agent编排，是一条连续谱（continuum），还没到人们常说的RSI（递归自我改进）那一步但如果有一天，真的到了那一步，
"那不应该只是公司内部的对话。那必须是一场更广泛的讨论。"
"我们都要在AGI相关阶段，避免race conditions（竞速式抢跑）。"
▲ 这段话在两个月后再次出现，与OS演示并置，产生了全新的化学反应
Race conditions，竞争条件这是一个编程术语：多个进程同时争抢同一个资源，时序混乱，系统崩溃
皮查伊把这个词，用在了描述AI实验室之间的竞争上
没有人有义务通知任何人
创业者Karl Mehta在发布这段视频时，写下了最让人不安的几行字：
"皮查伊在呼吁一场更广泛的对话，可眼下找不到容纳这场对话的空间。强制披露义务尚未建立，外部测试机制也还缺位。如果哪家实验室跨过了那条线，我们其余所有人，只能事后才会知道。"
这段担忧指向了制度层面的空缺。
能力曲线，可以一夜跑出来。治理机制，不能一夜建成。两条线之间的时间差，是这整件事里最值得严肃对待的部分
但也正因如此，皮查伊的这番表态，一位科技巨头CEO，主动在消费级播客上画出"我们不应该单独决定"的边界，在这个时代已经很少见
这件事的分量
回到那个最朴素的问题：这件事到底重不重要？
一个可以跑Doom的OS骨架，不等于Windows，也不等于AGI
但它意味着："多个AI Agent异步分工，在后台自主完成一个工程学期量级的项目"，这件事，从理论变成了可计费的现实
6500块钱，12小时。终点尚远，一个新的起点已经出现，当这个数字再缩小十倍、一百倍，当这套能力变成每一个开发者都能调用的API，整个软件工业的成本曲线，将会弯折成什么形状？
评论区里，有人贴出Temple OS的截图，留言："不管你们AI炖出什么SlopOS，都赢不了Terry Davis一个人写的Temple OS"
这当然是一个梗。但梗背后，是技术圈对"速成"的本能警惕
皮查伊在访谈最后说：我们所有人，都要避免在关键阶段抢跑
问题是，比赛，已经开始了。
参考来源：Google官方博客 antigravity.google/blog/google-antigravity-built-an-os｜Anthropic工程博客 anthropic.com/engineering/building-c-compiler｜Hard Fork播客（New York Times）｜CNET、DEV.to 相关报道