谷歌把 AI 编程拆成「云端架构师 + 本地工人」：97% 的 token 不出你的电脑

一个安全团队接到任务：审计三个 Python 模块，找出漏洞并给出补丁。按常规做法，代码要打包上传给云端模型，等它读完、想完、写回。可这三个模块里可能有客户密钥、内部接口、还没公开的业务逻辑，法务那一关就过不去。谷歌在 Antigravity SDK 里给出的解法，是把这件事拆成两半：云端只当“架构师”，本地模型当“工人”。

10 月 28 日，谷歌宣布 Antigravity SDK 支持本地模型，开发者可以在自己的机器上构建和执行智能体工作流，同时按需调用云端模型处理更高层的任务。数据隐私、推理成本、网络依赖和算力分配，重新回到开发者手里。

一分钟速览

• Antigravity SDK 新增本地模型支持，可混合编排云端与本地智能体
• 沿用“架构师—构建者”模式：云端拆分任务，本地执行代码密集型工作
• 官方演示中，约 3400 个 token 里只有 95 个用在云端，占 2.8%
• 默认通过 LiteRT 运行 Gemma 4 26B A4B，也兼容 Ollama、LM Studio、vLLM
• 本地推理建议 24GB 以上显存或统一内存，门槛不算低

“架构师—构建者”到底怎么分工

这套模式的核心是职责分离。架构师是一个上下文感知能力很强的主智能体，它掌握全局视图：依赖关系、架构约束、实施计划。它不需要读源码，只看文件名和任务描述，就能把一个大目标拆成若干范围明确的小任务。

构建者是多个并行工作的专门智能体，在隔离环境里各自执行：复现安全漏洞、提出修复方案、审查候选补丁、跑回归测试。它们的活儿高度依赖代码细节，因此放在本地跑。

这个分工带来的直接结果是：云端看到的只有文件名、任务描述和少量规划信息，源码不出机器。谷歌在演示中审计并修补三个存在漏洞的 Python 模块，约 3400 个 token 中有 95 个用于云端规划，其余 97.2% 在本地消耗，没有源码被上传。

为什么这个数字值得琢磨

“97.2% 的 token 在本地”听起来很漂亮，但它回答的是成本结构，不是绝对成本。本地跑 300 多亿参数的模型，电费、显存占用、推理时间都要算进去；云端 token 便宜，但架不住量大和合规风险。

社区里的质疑也很实在：有人指出，应该把补丁接受率、运行时间和能耗一起纳入基准，单看云 token 占比，说明不了本地推理是否更快更便宜；而 24GB 以上显存或统一内存的推荐配置，本身就是一道门槛。

不过支持者的反馈同样直接：以前用云端规则做不到的事，现在能做了。成本、速度、质量三个维度同时改善，对需要在内部网络里处理敏感代码的团队来说，这几乎是唯一可行的路径。

不只有 Gemma，也不只有编程

初版实现主要围绕 LiteRT 运行 Gemma 4 26B A4B，但 SDK 通过 LocalOpenAIAgentConfig 支持任何兼容 OpenAI 接口的本地推理服务，包括 Ollama、LM Studio 和 vLLM。这意味着开发者不必被绑定在谷歌的模型上，手上已有的本地模型可以直接接进来。

另一个容易被混淆的点：Antigravity SDK 不是 Antigravity IDE。两者共享底层智能体基础设施，但 SDK 是让开发者用代码构建自己的智能体，用途不限于写代码；IDE 只是它的一个上层应用。

趋势洞察

过去两年，AI 编程工具的竞争集中在“模型谁更强”。现在战场正在往下一层移动：谁能把模型、工具和数据放在正确的位置上。全部上云，成本高且合规难；全部本地，能力又不够。混合编排是折中方案，也是最接近企业真实约束的方案。

这条路上，谷歌不是唯一的玩家，但它的位置很特殊：既有云端模型，又有 Gemma 这样的开放权重模型，还有 LiteRT 这样的端侧运行时。把三者串起来，卖的不是一次 API 调用，而是一套“数据不出门也能用 AI”的架构。

接下来要看的，是这套架构在真实项目里的补丁接受率。如果本地“工人”写出的补丁需要人来反复返工，省下的 token 费就会以工时的方式还回去。