谷歌 Antigravity SDK 支持本地模型：云端只做规划，97% Token 留在本地
谷歌为 Antigravity SDK 加入本地模型支持，开发者可以在自己的机器上构建并执行智能体工作流，同时保留调用云端模型处理高层任务的能力。官方演示中，审计并修补三个存在漏洞的 Python 模块共消耗约 3400 个 Token，只有 95 个用于云端规划，源码未上传。不过社区也提醒，"本地 Token 占比高"并不直接等于更快、更便宜。
本地与云端可以混着用
Antigravity SDK 现在允许开发者在本机构建和执行智能体（agent）工作流，同时仍可灵活接入云端模型处理更高层的任务。对开发者来说，这意味着数据隐私、推理成本、网络依赖以及算力分配都更可控。
对关注 AI 编程和"氛围编程"的读者，这条路线值得留意：它把"昂贵的规划"交给云端，把"敏感的代码"留在本地，可能成为企业级智能体工作流的一种常见形态。
"架构师—构建者"如何分工
Antigravity SDK 的核心机制是混合代理编排，把谷歌提出的"架构师—构建者"（Architect-Builder）模式搬到云与本地混合的环境中。
- 架构师（云端）：具备高上下文感知能力，掌握全局视图，包括依赖关系、架构约束和详细规范。它只通过文件名和任务描述来制定策略、把任务拆成更小的单元，不接触源代码本身。
- 构建者（本地）：多个并行运作、各具专长的智能体，在隔离环境中独立执行范围狭窄的离散任务，比如复现安全漏洞、提出修复方案、审查候选补丁、运行回归测试。另有专门的本地智能体用测试套件验证改动。
这样，工作流中代码密集的阶段全部留在设备上。
演示数据：3400 个 Token，只有 95 个上云
Token 可以粗略理解为模型处理文本的计量单位，也是用量计价的颗粒。在一项针对三个存在漏洞的 Python 模块进行审计和修补的演示中，谷歌报告称：总共约 3400 个 Token，仅 95 个用于云端规划，其余 97.2% 都在本地消耗；同时没有任何源代码被上传到云端。
本地推理不只能用 LiteRT
初版实现主要侧重通过谷歌的 LiteRT（面向端侧的推理运行时）运行 Gemma 4 26B A4B 模型。但开发者并非只能走这条路：Antigravity SDK 还通过 LocalOpenAIAgentConfig 支持与 OpenAI 兼容的本地推理服务器，包括 Ollama、LM Studio 和 vLLM。
社区反应：看好控制力，质疑衡量指标
Reddit 用户 ambassadortim 认为，企业由此对自己的 AI 模型拥有更多控制权，包括何时进行更改。
另一位用户 FollowingTop3534 则对"云 Token 占比"这一指标提出疑问：
我会把补丁接受率、运行时间和能耗与云 Token 占比放在一起对比。"97.2% 的 Token 消耗来自本地模型"这个数字虽然有意思，但并不能说明在你的硬件上跑模型是否更快或更便宜；而且，推荐 24GB 以上的显存或统一内存，确实是一道门槛。
用户 Latter_Crazy 则给出了积极评价，称这些新功能能做到此前用云端规则做不到的事情，成本、速度和质量都在提升。
别把 SDK 和 IDE 搞混
需要注意，Antigravity SDK 与 Antigravity IDE 是两回事：后者是由前者驱动的集成开发环境。两者共享同一套底层代理基础设施，但用途不同——SDK 让你以编程方式搭建自己的 AI 智能体，而不只是用于编码任务。
关键要点
- Antigravity SDK 新增本地模型支持，智能体工作流可在本机执行，云端负责高层规划；官方演示中 97.2% 的 Token 在本地消耗，源码不出设备。
- "架构师—构建者"模式把任务拆解放在云端、把代码操作放在本地，适合对代码隐私敏感的企业场景。
- 本地推理不限于 LiteRT，Ollama、LM Studio、vLLM 等 OpenAI 兼容服务都能接入。
- 本地 Token 占比不等于更快更便宜：24GB 以上显存仍是门槛，评估时应结合实际补丁接受率、耗时与能耗。