谷歌演示十轮通宵重建办公楼

将 7 份城市规划 PDF、206 张工程图纸变成可交互的办公楼三维模型，需要处理的已不只是一段代码。谷歌展示的 Gemini 4 Carbon 案例中，多智能体任务经过 10 轮通宵运行，最终完成了包含约 90.6 万个三角形的 Three.js 模型。这个演示值得关注的地方，是多个任务能够持续衔接，直到形成可查看的工程结果。

随着 Carbon 正式上线，多智能体协作有了更具体的使用入口。Google Antigravity 推出的 /swarm 功能预览版，允许开发者用一条指令组织多个 AI Agent 分工，并实时查看进度。不过，功能开放与项目交付是两回事：入口降低了组织任务的操作门槛，演示中的完成度仍需结合任务本身判断。

分工决定了它能承接什么

爱范儿介绍的模型定位，解释了这套协作方式：Carbon 面向复杂软件工程、跨领域研究等高难度任务，可以消耗更多 Token 深入推理、反复验证和修正错误；Argon 则继续承担大多数日常编程和知识工作。两者有不同的任务侧重，并非新模型上线后，所有工作都要交给它。

在 /swarm 中，Carbon 可以承担架构设计、任务协调和代码审查，其他速度更快、成本更低的模型负责具体开发，另有验证 Agent 检查修改结果。这意味着，任务拆分、执行和检查被放进了同一套协作过程。本文的判断是，此次上线体现的工程范围变化，在于模型开始承接这些环节之间的衔接，而不只是分别生成代码。

谷歌展示的开放世界 3D 游戏，提供了另一个观察样本。游戏让玩家扮演骑自行车的鹈鹕，在谷歌山景城园区探索，开发涉及 Blender 三维建模、Three.js 和 WebGL 游戏开发、程序化音效，以及使用 Lyria 生成背景音乐。不同工具、素材和代码要共同构成一个可玩的结果，多智能体分工因而有了明确的应用场景。

办公楼重建则突出了持续执行的重要性。10 轮通宵运行说明，这项演示依赖多轮任务推进，不能把它理解为输入一次需求便立即交付。原文也没有给出任意工程图纸都能达到同样效果的结论。

完成之后，还要检查修改是否可靠

相较于展示一个新项目，在已有代码库中修复问题，还要确认修改没有破坏原有功能。爱范儿援引的 HubX 报告称，在拥有约 1.4 万项测试的代码库中，Carbon 处理了 16 个真实 Bug，问题解决率达到 94%，且没有引入新的回归问题。

这份第三方报告为结果验证提供了比演示更具体的观察范围：任务数量、代码库测试规模和回归情况都有交代。但它仍是特定代码库中的结果，不能推出 Carbon 对所有项目都有相同的修复能力，也不能据此认定这些任务采用了与谷歌演示完全相同的多智能体流程。

Carbon 已向开发者付费层等渠道开放，普通消费者的入口则是 Google AI Ultra 订阅；/swarm 仍是预览版。对软件工程而言，更值得检验的是：任务能否合理拆分，多个执行环节能否持续衔接，最终修改能否通过检查。现有演示和报告已经呈现出这种工作范围的扩展，但尚不足以承诺任意项目都能无人完成。