
谷歌 Antigravity SDK 新增本地模型支持,提升 Token 效率和代码隐私性
谷歌在 Antigravity SDK 中引入了对本地模型的支持,使开发者能够直接在自己的机器上构建和执行智能代理工作流,同时仍然可以灵活地将云端模型融入其中,用于处理更高层次的任务。这使得开发者能够更好地掌控数据隐私、推理成本、网络依赖以及计算工作负载的分配。
以下正文同步自 InfoQ 中国,版权归原站所有,已转换为易读排版。
谷歌在 Antigravity SDK 中引入了对本地模型的支持,使开发者能够直接在自己的机器上构建和执行智能代理工作流,同时仍然可以灵活地将云端模型融入其中,用于处理更高层次的任务。这使得开发者能够更好地掌控数据隐私、推理成本、网络依赖以及计算工作负载的分配。
Antigravity SDK 最具吸引力的功能之一是混合代理编排。该功能将谷歌提出的“架构师-构建者”(Architect-Builder)模式应用于由云计算和本地计算组成的混合环境。
根据“架构师-构建者”模式,一个具备高上下文感知能力的主 AI 代理(即“架构师”)掌握全局视图,包括依赖关系、架构约束以及详细规范或实施计划。一旦架构师制定了计划,多个并行运作且各具专长的 AI 代理(即“构建者”)便会在隔离的环境中独立工作,执行规范中规划的、范围狭窄的离散任务。
谷歌表示,Antigravity SDK 使“架构师”能够在云端运行,通过文件名和任务描述制定策略并将任务分解为更小的单元,而无需访问源代码本身。而“构建者”则在本地运行,执行诸如重现安全漏洞、提出代码修复方案、审查候选补丁以及运行回归测试等任务。其他专门的本地代理可以根据提供的测试套件对拟议的更改进行验证,从而将工作流中的代码密集型阶段保留在设备上。
在一项针对三个存在漏洞的 Python 模块进行审计和修补的演示中,谷歌报告称,在约 3400 个 Token 中,仅有 95 个用于云端规划,其余 97.2% 的 Token 都是在本地消耗的。谷歌还表示,没有源代码被上传到云端。
初步实现主要侧重于通过谷歌的 LiteRT 技术运行 Gemma 4 26B A4B 模型。不过,开发者并非只能使用 LiteRT,因为 Antigravity SDK 还通过 LocalOpenAIAgentConfig 支持与 OpenAI 兼容的本地推理服务器,包括 Ollama、LM Studio 和 vLLM。
针对这一公告,Reddit 用户 ambassadortim 指出:“企业可以对自己的 AI 模型拥有更多的控制权,包括何时进行更改。”在另一场讨论中,FollowingTop3534 质疑云 Token 占比这一指标是否能全面地反映情况:
我会将补丁接受率、运行时间和能耗与云 Token 占比一并作为基准进行对比。“97.2% 的 Token 消耗来自本地模型”这一数据虽然有意思,但并不能说明在你的硬件上运行模型是否更快或更便宜,而且,推荐 24GB+ 的显存或统一内存确实是一道门槛。
关于社区讨论的最后一点补充,用户 Latter_Crazy 对这些新功能发表了热情洋溢的评论:
它能实现我之前使用云规则无法做到的事情。成本、速度和质量都在提升,而这仅仅是个开始。强烈推荐大家了解一下。
请勿将 Antigravity SDK 与 Antigravity IDE 混淆,后者是由 Antigravity SDK 驱动的集成开发环境(IDE)。它们共享相同的底层代理基础设施,但用途不同:SDK 允许你通过编程方式构建自己的 AI 代理,而不只是用于编码任务。
原文链接:https://www.infoq.com/news/2026/10/antigravity-sdk-local-models/
正文由 探How 从来源站点 RSS 同步,内容未经改写;遇到排版缺失或需要图片、视频时请以原文为准。