Google Antigravity SDK 新增本地模型支持，提升令牌效率与代码隐私

Google 在 Antigravity SDK 中引入了本地模型支持，让开发者能够直接在自己的机器上构建并执行智能体工作流，同时保留混用云端模型处理更高层任务的灵活性。按 InfoQ 的报道，这一方案让开发者对数据隐私、推理成本、网络依赖和计算负载分布拥有更大的控制权。

真正值得追问的不是“能不能本地跑”，而是本地化把哪些环节从云端拿走了、又留下了什么代价。Google 给出的演示数字是：在审计并修补三个存在漏洞的 Python 模块的任务中，约 3400 个 token 里只有 95 个用于云端规划，其余 97.2% 在本地消耗，并称没有源代码被上传到云端。这组数字是厂商自述，尚无独立验证，因此它更适合被当作一个待检验的起点，而不是结论。

Antigravity SDK 的一项核心能力是混合智能体编排，把 Google 提出的 Architect-Builder 模式适配到云端与本地混合的计算环境。按该模式，一个高上下文的主智能体“architect”掌握依赖关系、架构护栏和详细规格或实施计划等宏观系统视图；随后由多个并行的专门化“builder”智能体在隔离环境中独立执行规格拆出的离散窄任务。

分工的关键在于信息边界。Google 表示，Antigravity SDK 让 architect 在云端运行，用文件名和任务描述制定策略并把任务拆成更小单元，而无需访问源代码本身。builder 则在本地运行，执行复现安全漏洞、提出代码修复、审查候选补丁和运行回归测试等任务；额外的专门化本地智能体还可依据给定测试套件验证拟议改动，使代码密集阶段留在设备上。

这套设计的直接含义是：云端看到的是任务结构而非代码内容，本地承担的是需要接触源码的密集工作。但“architect 不访问源代码”是 Google 的说法，属于厂商自述；它在真实生产环境中的表现与稳定性，报道并未给出证据。

初始实现聚焦于通过 Google 的 LiteRT 技术运行 Gemma 4 26B A4B。这意味着本地侧的能力上限，至少在起步阶段，与这一模型和这一运行时绑定。

开发者并不局限于 LiteRT。Antigravity SDK 还通过 LocalOpenAIAgentConfig 支持 OpenAI 兼容的本地推理服务器，包括 Ollama、LM Studio 和 vLLM。对已经自建本地推理栈的团队来说，这条兼容路径降低了迁移成本，也让“本地模型”不必等同于“Google 指定的本地模型”。

需要区分的是产品边界：Antigravity SDK 不应与 Antigravity IDE 混淆，后者是一个由 Antigravity SDK 驱动的 IDE。两者共享同一套底层智能体基础设施但用途不同，SDK 让人以编程方式构建自己的 AI 智能体，而不只是用它们做编码任务。

在 Reddit 讨论中，用户 ambassadortim 评论称，企业可以对自家 AI 模型以及何时更换模型拥有更多控制权。这呼应了 Google 关于控制权的表述，但同样属于社区个人观点，而非可验证的产品能力结论。

更值得重视的是对指标的质疑。用户 FollowingTop3534 质疑云端 token 占比这一指标是否说明了全部问题，建议同时基准测试补丁接受率、墙钟时间和能耗。该用户还提到，推荐配置为 24GB 以上显存或统一内存，并称这是一道实实在在的门槛。

这两条社区意见指向同一个缺口：97.2% 的本地 token 占比说明工作负载分布，却不直接说明这次运行在特定硬件上是否更快或更便宜。补丁接受率、墙钟时间和能耗等指标在报道中并未披露。

也有用户 Latter_Crazy 对新增能力表示热情，称它能做到此前在云端规则下做不到的事，并认为成本、速度和质量都在提升。这属于社区主观评价，报道未提供支撑数据。

上述所有信息均来自 InfoQ 一篇报道，其中 Google 的演示数据与说法属于厂商自述，尚无独立第三方验证。这意味着 95/3400 的 token 分布、97.2% 的本地占比以及“没有源代码上传到云端”都应被读作 Google 的声明，而非已确认事实。

同样处于未验证状态的还有 24GB 以上显存或统一内存门槛对实际可用性的影响程度，以及混合编排在真实生产环境中的表现与稳定性。除 InfoQ 报道外，缺少其他独立来源交叉印证。

因此，对这套方案的合理判断是：产品方向与架构分工已被清晰描述，但收益幅度与工程可用性仍待独立测量。