Google Antigravity SDK 本地模型让智能体离线运行，但硬件划定了边界

Google 新增了 Antigravity SDK 本地模型支持，让开发者首次能够在无需 API 密钥或互联网连接的情况下运行智能体工作流。

首个优化路径将 Gemma 4 26B A4B 与 Google AI Edge 的 LiteRT 运行时结合。Google 建议至少配备 24 GB 显存或统一内存。尽管承诺实现本地执行，这一要求仍使完整体验超出了许多普通笔记本电脑的能力范围。

此次发布改变了一条重要边界。开发者不再需要将每个提示词、源文件或工具结果都发送至托管模型。不过，云端智能体仍具备更易部署、更大的模型容量以及更少硬件限制等优势。

因此，Google 正在挑战仅限云端的智能体模式，但并未放弃云端。其演示方案使用了一个 Gemini 云端规划器，以及多个本地 Gemma 工作节点。更重要的故事并非全面替代云端，而是能够控制智能体的每个部分在哪里运行。

Antigravity SDK 本地模型将智能体循环移至设备端

Google 已将智能体的模型调用、工具循环和工作上下文移至由开发者控制的硬件上。

Google 于 2026 年 9 月 23 日宣布本地模型支持。该公司表示，Antigravity SDK 现已支持跨多种模型和执行选项的本地工作流。

该 SDK 通过 Python 提供 Google Antigravity 背后的智能体能力。这些能力包括模型交互、工具、策略、工作区、钩子和子智能体。

开发者此前通常将这些工作流与远程推理关联起来。新配置允许智能体针对存储并在同一台机器上执行的模型检查点运行。

Google 的本地模型发布公告重点介绍了 Gemma 4 26B A4B，作为首个优化模型。LiteRT 通过设备可用的加速硬件处理推理。

受支持的路径使用 LiteRTAgentConfig，将智能体指向 .litertlm 检查点。SDK 会启动一个回环服务器，即仅可通过本机网络接口访问的服务。

该本地服务位于 Antigravity 智能体与模型运行时之间。它让更广泛的智能体框架能够与检查点通信，而无需调用公共模型端点。

据 Google 介绍，生成的工作流可以在无需 API 密钥或互联网连接的情况下运行。这与那些仅将部分文件存储在本地的产品有着重要区别。

完全离线运行意味着模型输入、生成的 token 和工具交互都可以留在设备上。具体的隐私结果仍取决于开发者启用的工具和集成。

调用网络搜索服务的智能体并非完全离线。连接到远程数据库、分析系统或托管的 Model Context Protocol 服务器的智能体也是如此。

SDK 还通过 LocalOpenAIAgentConfig 支持外部本地服务器。该路径可连接到在开发者机器或私有网络上提供 OpenAI 兼容 API 的软件。

Google 将 Ollama、LM Studio 和 vLLM 列为示例。这种兼容性很重要，因为本地 AI 用户已经围绕这些服务器组织模型和自动化流程。

两条路径服务于不同需求。LiteRT 提供围绕其运行时优化、由 Google 管理的路径，而兼容服务器则让团队对模型托管拥有更多控制权。

Google 的本地执行指南记录了两种配置。它还确认支持 Apple Silicon Metal、Nvidia CUDA 以及自动检测的加速器后端。

这不只是编辑器内又一个模型选择器。SDK 允许开发者将本地推理置入自己的脚本、服务、评估系统和专用智能体工作流中。

这种可编程性构成了本文的核心张力。将推理移至设备上能改善控制力，但也将基础设施责任从 Google 转移给用户。

离线智能体让仅限云端的工作流承压

此次发布通过让数据本地性成为架构选择而非产品限制，对仅限云端的智能体平台施加压力。

云端推理仍是大多数编码智能体的默认选择。它让用户无需工作站级 GPU 或漫长的模型下载，即可立即使用大型模型。

这种便利的代价不止是使用费用。源代码、提示词、检索到的文档和工具输出都必须进入远程处理环境。

提供商政策可以限制数据保留和训练用途。企业协议能够增加更强的控制措施。即便如此，一些组织仍无法将敏感材料发送到获准机器或网络之外。

隔离网络的开发环境是最清晰的案例。这些系统有意不具备直接互联网访问能力，因为其中包含受监管、机密或商业敏感信息。

仅限云端的智能体无法在这种环境中正常运行。离线 Antigravity 智能体则可以，前提是其模型和软件依赖项通过获批的传输流程进入环境。

同样的优势也适用于处理未发布产品、安全报告、法律文件和专有算法的开发者。本地执行减少了接收其上下文的系统数量。

它也改变了服务可用性。本地工作流不会因为模型提供商发生故障、更改配额或撤销端点而停止。

这种独立性在长时间运行的任务中可能很重要。审计代码仓库的智能体可能会在读取文件、规划改动、运行测试和审查错误时执行许多轮模型调用。

延迟的表现也不同。本地推理避免了广域网络延迟，但 token 生成完全取决于可用硬件和运行时优化。

配置良好的工作站可以提供可预测的响应时间。接近最低内存建议的机器可能带来慢得多的体验，尤其是在并发工作负载下。

云端平台仍保有明显优势。它们能够提供更大的模型、弹性容量、集中式监控和托管更新，而无需占用本地内存。

它们还让团队能够在使用不同电脑的员工之间实现性能标准化。本地优先的方法使设备规格成为部署计划的一部分。

因此，此次发布并未确立本地 AI 与云端 AI 之间的简单竞争。它对那些无法在这些执行环境之间提供有意义选择的平台施加了压力。

战略优势属于那些能够根据敏感性、复杂度和可用算力来路由工作的平台。Google 的 SDK 现已支持这一更广泛的模式。

对企业而言，决策变得更加精细。团队可以将托管模型留给要求更高的规划任务，同时将重复性的文件分析保留在受控硬件上。

个人开发者获得了另一种主动权。即使不希望每项任务都受远程认证或用量限制约束，他们仍能继续使用智能体工作流。

限制在于能否获得合适的硬件。Google 针对主推的 Gemma 检查点建议至少配备 24 GB 显存或统一内存。

许多主流计算机低于这一门槛。一些机器在技术上达到要求，但还必须与操作系统、编辑器、浏览器和构建工具共享这些内存。

仅限云端的提供商可以合理主张，托管推理仍是更易获取的路径。本地智能体提升了自主性，但并未消除计算成本。

因此，这种压力在重视安全且技术成熟的团队中最为明显。这些买家可能足够看重本地控制，从而愿意接受配置工作和硬件要求。

LiteRT 和 Gemma 4 说明离线工作流的运行方式

这一机制依赖于稀疏 Gemma 模型、本地推理运行时，以及能够将控制循环保留在附近的智能体框架。

Gemma 4 26B A4B 采用混合专家架构。这种设计让每个 token 仅通过模型的一部分进行路由，而不是激活全部参数。

Google 列出的该模型总参数量为 252 亿，活跃参数量为 38 亿。A4B 标签指的是推理期间约有 40 亿参数处于活跃状态。

这种区别对于本地执行很重要。该模型可以利用更大的参数池，而无需在每个 token 上对全部 252 亿参数进行稠密计算。

这并不意味着检查点在存储或内存中只占用 40 亿参数。用于路由的完整专家集合必须保持可用。

Google 表示，LiteRT 格式的检查点下载大小约为 16.8 GB。建议的 24 GB 内存水平为推理状态和其他进程预留了额外容量。

Gemma 4 模型卡列出，26B A4B 模型的上下文窗口最高可达 256,000 个 token。它还支持文本和图像输入。

较大的标称上下文窗口并不保证每台本地机器都能轻松使用它。在实际工作负载中，更长的上下文会增加内存需求和处理时间。

Gemma 4 还包含原生函数调用。函数调用让模型能够请求结构化操作，例如读取文件或调用开发者定义的工具。

这一能力对智能体至关重要。传统聊天机器人只会生成回复，而智能体则在推理、操作、观察和修正后的决策之间交替进行。

Antigravity 提供周边控制系统。它管理工作区、可用工具、执行策略以及与本地模型的通信。

LiteRT 提供推理层。Google 将该运行时设计为可跨受支持硬件后端进行设备端机器学习。

LiteRT 模型指南介绍了面向从手机到消费级 GPU 和工作站等设备的 Gemma 变体。该系列的硬件目标差异很大。

对于 Antigravity 集成，开发者需要安装 SDK 和 litert-lm 包。随后，他们将模型导入 LiteRT 的检查点格式。

智能体通过其配置接收模型路径。程序启动时，SDK 会创建本地模型服务，并将生成的 token 流式传回应用程序。

这一架构使集成方式相对熟悉。开发者仍然只需实例化智能体并向其发送任务，而不必独立构建推理服务器和工具循环。

另一种 OpenAI 兼容配置拓宽了模型选择。团队可以将 Antigravity 指向现有的 Ollama、LM Studio 或 vLLM 部署。

OpenAI 兼容接口对常见请求和响应格式进行了标准化。这并不意味着底层模型来自 OpenAI。

这种区别使 Antigravity 能够位于多种推理栈之上。智能体框架可以保持稳定，而所选的本地服务器或模型可以变化。

兼容性也降低了运行时层面的锁定。已经在内部服务器上使用 vLLM 的团队无需为每个工作流采用 LiteRT。

LiteRT 仍受到特别关注，因为 Google 围绕它优化了初始的 Gemma 4 路径。这一组合让 Google 能够同时控制模型格式和执行运行时。

该架构支持的不仅是完全本地运行。它也支持混合编排：由云端模型规划工作，本地代理执行受限任务。

这一混合选项最能解释 Google 选择此时推出该功能的原因。本地模型已足以完成实用的编程工作，无需取代能力最强的托管规划模型。

Google 的混合演示揭示了真正的战略

Google 自己的示例表明，本地代理正成为执行层，而云端模型仍负责规划。

该公司演示了一种 Architect-Builder 模式：使用 Gemini 3.8 Flash 作为云端架构师，本地 Gemma 4 26B 实例作为构建者。

演示中，系统被分配了三个存在漏洞的 Python 模块，分别名为 auth.py、billing.py 和 database.py。本地工作节点负责在设备上进行审计和修补。

云端规划器协调更广泛的流程。这种分工让大部分代码仓库工作保留在本地，同时仍能借助更大型的托管模型进行编排。

这比声称单一本地 checkpoint 能匹配所有云端模型更可信。代理任务的不同阶段，对准确性、隐私和算力有不同需求。

规划往往受益于在广泛上下文中的更强推理能力。重复性的检查、编辑和验证工作，则可以分配给较小的工作节点。

这一模式类似于传统计算架构。集中式系统负责调度任务，而专用机器则在接近相关数据的位置执行任务。

对于软件团队而言，实用的混合工作流可以从托管模型拆解一次迁移任务开始。随后，本地代理可以检查各个模块并提出修改建议。

在敏感细节被最小化后，最终审查可以回到云端规划器。或者，人工也可以直接审查本地输出，无需再次进行远程调用。

隐私收益取决于这一边界。如果云端规划器接收完整源文件，本地构建者并不能阻止数据暴露到远端。

开发者必须决定哪些上下文可以跨越边界、共享哪些摘要，以及哪些工具能够访问外部服务。SDK 无法自动做出这些政策决策。

Google 的政策系统为开发者提供了施加限制的位置。不过，宽松的示例配置不应在未经审查的情况下成为生产环境默认设置。

该公司的基础示例使用本地代理检查当前目录中的文件。更高级的示例则允许代理创建监控工具并运行命令。

这些能力让代理更实用，但也提高了风险。出错或受到操纵的模型可能修改文件、调用进程，或通过已连接工具暴露信息。

本地推理并不会让代理变得无害。它改变的是模型计算发生的位置，而不是生成的操作是否需要监督。

混合执行也带来了运维复杂性。团队必须同时监控远程调用和本地运行时，并理解跨越边界的故障。

云端规划器可能产生有缺陷的任务拆解。本地构建者随后可能一致地执行该计划，将一个错误扩散到多个文件中。

并发带来了另一项限制。运行多个 Gemma 4 实例，可能需要比单一推荐配置所提供的更多内存。

Google 尚未发布针对 Antigravity 集成的独立、特定工作负载基准测试。因此，该公告证明的是可用性，而非普遍性能。

不过，这一演示仍释放出明确的产品方向信号。Google 正将本地模型定位为更广泛代理系统中的互补型工作节点。

这一战略会促使其他代理框架支持类似的路由方式。客户在接受纯云端方案前，会越来越多地询问任务是否能留在本地。

它也让 Google 能够覆盖两个市场。Gemini 服务仍适用于高要求的编排工作，而 Gemma 和 LiteRT 则覆盖注重隐私或成本敏感的执行场景。

24 GB 建议是第一个现实检验

离线运行消除了对远程端点的依赖，但也以硬件、维护和模型质量限制取代了这种依赖。

Google 建议为 Gemma 4 26B A4B 配备至少 24 GB 的 VRAM 或统一内存。该措辞描述的是建议，而不是普适性保证。

VRAM 是独立 GPU 使用的专用图形内存。统一内存则是处理器和图形硬件共享的内存池，例如 Apple Silicon Mac 所采用的架构。

这些配置在高负载下的表现不同。独立 GPU 可以提供较高的推理吞吐量，而统一内存能在 CPU 和图形任务之间提供更大的灵活性。

可用容量比标称总容量更重要。一台 24 GB 的机器如果同时运行容器、浏览器、构建任务和多个代理，可能几乎没有剩余空间。

16.8 GB 的 checkpoint 下载也带来了部署负担。组织必须在获准设备之间分发、验证、更新并存储这一工件。

模型来源成为一个运维问题。团队应确认 checkpoint 的来源、转换方式，以及其许可证是否允许预期用途。

根据 Google 的文档，Gemma 4 采用 Apache 2.0 许可证。外部微调版本和转换后的 checkpoint 可能带来独立条款或安全问题。

模型质量带来了更大的不确定性。Google 发布了 Gemma 4 的基准测试结果，其中包括编程和面向代理的评估。

这些基准描述的是底层模型在既定测试条件下的表现。它们并不能证明 Antigravity 能否在开发者代码仓库中可靠完成长时间、工具驱动的任务。

代理的可靠性会让错误在多个步骤中叠加。一个微小误解就可能影响文件选择、命令执行、测试解释以及最终补丁。

本地模型也可能缺少最新的托管端改进。云服务提供商可以集中更新推理系统，而本地部署需要有意识地升级并进行回归测试。

团队可能更偏好这种稳定性。固定 checkpoint 能提供更受控的环境，并避免远程模型更新后出现意料之外的行为变化。

不过，固定并不意味着确定性。采样设置、工具结果、工作区状态和并发情况仍可能改变结果。

安全团队还必须审查本地服务器。回环地址能限制暴露范围，但配置不当仍可能开放端口，或授予过于宽泛的文件系统访问权限。

兼容 OpenAI 的服务器也需要同样严格的审查。vLLM 服务文档 展示了本地或私有端点如何模拟常见的模型 API。

兼容性提高了可移植性，但也可能掩盖重要差异。不同模型在工具调用格式、上下文处理、安全行为和结构化输出支持方面各不相同。

因此，开发者应测试完整代理循环，而不仅仅是提示词响应。一个能写出好代码的模型，仍可能难以可靠地选择工具。

Google 的硬件建议缩小了初期受众范围。配备大显存 Nvidia GPU 的工作站，以及配置更高的 Apple Silicon 系统，是自然的起点。

更小的 Gemma 模型能够扩大覆盖范围，但 Google 的公告将优化工作流的重点放在 26B A4B checkpoint 上。这是支撑最强发布主张的版本。

“可在本地运行”与“能在我的机器上良好运行”之间的差距仍未解决。性能会因硬件、上下文大小、工具使用方式和任务复杂度而变化。

目前也尚无证据表明，离线 Antigravity 代理在完整软件工程任务上能与领先的托管系统匹敌。Google 也没有提出这一更广泛的主张。

更负责任的解读应当更为有限：Antigravity 现在可以在本地执行有实际意义的代理工作流，且具备文档化的配置方式和较高的内存建议。

即使尚未达到性能对等，这一能力也很重要。它为先前不允许或不适合远程推理的团队提供了可部署的选择。

三个信号将显示本地代理是否成为默认选择

接下来的考验在于：本地执行能否超越注重隐私的实验和配备大内存的开发者工作站，成为日常实践。

第一个信号是更广泛的模型和硬件支持。开发者需要为低于 24 GB 建议配置的机器提供实用选择。

更小的 Gemma 变体可让更多笔记本电脑使用离线代理。额外的优化 checkpoint 也能让团队在能力、速度和内存使用之间权衡。

仅有支持还不够。Google 必须发布覆盖 Apple Silicon、Nvidia GPU 和其他受支持加速器的清晰性能数据。

有价值的指标包括生成速度、首个 token 的时间、峰值内存使用量和端到端任务完成情况。代理基准测试还应覆盖工具使用和多步骤恢复能力。

如果这些结果显示常见硬件上的性能可以接受，本地路线就不再只是专家功能。若结果较弱，云端推理将继续巩固其默认地位。

第二个信号是来自生产部署的证据。早期演示证明软件能够运行，但无法揭示日常可靠性。

团队需要报告本地代理如何处理大型代码仓库、长时间会话、并发工作节点和可重复的评估套件。

以安全为导向的采用尤其值得关注。隔离网络环境中的组织有充分理由接受较慢的性能，前提是工作流符合内部控制要求。

开发者反馈也会揭示实际摩擦点。安装失败、checkpoint 转换问题、散热限制和工具调用错误，可能超过架构带来的收益。

第三个信号是竞争对手的反应。其他代理框架已经能够连接本地模型服务器，但集成深度差异很大。

重要的比较并不是某个产品是否将 Ollama 列为选项，而是本地模型能否使用相同的工具、政策、工作区和编排功能。

竞争对手可能通过更强的本地路由、企业托管推理，或在远程与设备端模型之间自动选择来回应。

迅速的回应将支持 Google 的核心判断：执行位置正成为采购标准。有限的回应则表明需求仍主要集中在爱好者群体。

Google 的混合模式同样值得审视。它可以提供务实的平衡，但前提是开发者能够验证哪些信息会传送给云端规划器。

清晰的日志、政策控制和可追溯的路由，将与模型支持同等重要。企业需要证据证明，声明的边界会在每一次代理轮次中得到执行。

此次发布也应推动更严谨的任务设计。开发者可以将本地代理保留给受约束的工作，而不是期待一个系统自主管理整个项目。

例如，对私有文档进行分类、审查范围明确的模块、生成测试，或总结本地技术笔记。每项任务都具有可衡量的输入和输出。

这种方法适合更广泛的 AI 工作流，让敏感上下文保留在用户身边。人工审查仍然负责把关具有重要影响的操作。

Antigravity SDK 本地模型如今让离线代理执行成为 Google 有文档支持的工作流，而不再是非官方的变通方案。这次发布并未解决质量或可及性问题。

但它改变了开发者可以向代理平台提出的要求。云端访问不再必然是自动化不可避免的代价。

最有价值的下一步是进行具体测试。选择一项私密、范围有限的任务，记录内存使用情况和完成质量，然后比较本地运行与托管运行的结果。

本地 agent 是否能在完成足够多工作、证明硬件投入合理的同时，保护真正重要的上下文？这个答案将决定 Google 创造的是一种默认架构，还是一个有价值的例外。