Antigravity 2.0：许可、配额与 Gemini CLI 迁移指南

Antigravity 2.0 不再只是“带 AI 的编辑器”。它已经变成面向智能体开发的一组界面：桌面应用、IDE、CLI 和 SDK。真正影响预算的变化也不是界面，而是运营模型：消耗由共享配额和基于 compute 的限制来治理，所以模型选择、推理模式和工具调用都会进入成本账本。

TL;DR 截至 2026年6月27日，稳妥的用法是：用 Antigravity IDE 写代码，用 桌面应用 编排智能体，用 agy 做终端自动化，需要在自有治理下托管智能体时使用 SDK。要保护配额，就把模型和推理模式当作 FinOps 政策，而不是个人偏好。

很多团队感到混乱，是因为三个变化同时发生。Google 把体验拆成不同界面。AI 计划开始用 compute 口径描述限制，而不只是简单的 prompt 次数。Gemini CLI 迁移到 Antigravity CLI 也有明确日期：个人用户需要在 2026年6月18日 前迁移旧流程。

本文把用户提供的 Medium 文章作为选题参考，而不是主来源。事实性陈述以 Google 官方公告、文档或产品页面为依据。

Antigravity 2.0 的四个界面

常见错误是把“Antigravity”继续理解成一个窗口。现在的架构更模块化：一个界面负责协调，一个负责编辑，一个负责自动化，一个负责把智能体嵌入企业系统。

界面 1

Antigravity Desktop

用于跟踪智能体、会话和长时间任务。当工作已经超出“编辑器里的聊天”时，它才真正有价值。

界面 2

Antigravity IDE

代码编辑界面，用于重构、查看 diff、运行测试、调试，以及在仓库旁进行上下文聊天。

界面 3

Antigravity CLI `agy`

终端界面，适合脚本、自动化，以及在不打开 IDE 的情况下迁移 Gemini CLI 流程。

界面 4

Antigravity SDK

用于构建定制智能体，并把它们接入企业基础设施、身份、日志、部署和数据控制。

这种拆分对工程团队是健康的。IDE、智能体编排、终端自动化和企业 runtime 是不同问题。把它们混在一起看起来简单，但会隐藏成本和权限边界。

Antigravity 2.0 不应被当作编辑器购买，而应被当作智能体执行界面来治理。

配额变化：compute 成为实际单位

敏感点在消耗。Google 的 AI 计划已经用基于 compute 的限制来描述额度，并按周期刷新直到周上限。实际问题从“我还有多少 prompt？”变成“这个 prompt 要系统做多少工作？”。

在轻量模型上问一个简单问题，和让系统读取仓库、规划步骤、调用工具、生成 patch、再重新评估测试，消耗不是一回事。对 FinOps 来说，长 prompt、智能体循环和高推理模式都需要明确规则。

决策	配额影响	建议政策
默认模型	能力更强的模型通常每个任务消耗更多 compute。	用经济模型处理分流、搜索和简单编辑；只有任务需要时才升级。
推理模式	高推理成本更高，因为模型会在回答前进行更多规划和验证。	保留给复杂 bug、架构、事故和关键迁移。
附加上下文	更多文件、日志和历史会增加处理量。	只附加足够小的上下文，并优先做定向仓库搜索。
智能体循环	每轮都可能调用模型、工具、测试和再次分析。	设置步数限制、人工 checkpoint 和单任务预算。

运营重点很简单：共享配额会惩罚看不见的浪费。如果一个低价值自动化全天用昂贵模式运行，它会消耗本该留给复杂工作的预算。

个人计划 vs. 企业运营

对个人和小团队来说，个人计划可能足够：用户购买容量，在编辑器中使用，并自己控制节奏。问题出现在企业试图管理几十或上百个分散订阅时。成本不再只是“月费”，而是治理：身份、审计、数据政策、账单和访问控制。

画像 1

个人使用

适合测试、学习、原型和独立开发者。因为人员和数据范围小，风险较低。

控制: 用户账号
账单: 订阅

画像 2

技术团队

需要模型政策、使用限制、AI 辅助代码评审，以及原型和生产的边界。

控制: 团队政策
账单: 成本中心

画像 3

受监管企业

需要企业身份、企业条款、审计轨迹、数据控制和统一云账单。

控制: IAM / Cloud Identity
账单: Google Cloud

企业使用时，正确问题不是“哪个计划更便宜？”。而是“哪种访问模型能降低风险，并按产品、团队或流程衡量成本？”。代码智能体会接触知识产权、密钥、依赖、客户数据和流水线。

治理提醒不要把个人订阅当成企业架构。如果智能体访问专有代码、内部工单或受监管数据，安全、法务、IAM 和 FinOps 都必须参与决策。

从 Gemini CLI 迁移到 `agy`

最具体的迁移是从 Gemini CLI 到 Antigravity CLI。Google 已针对个人用户发布说明：需要在 2026年6月18日 前迁移到 agy。此后，旧流程不再是该用户类型的受支持路径。

插件迁移命令很直接：

agy plugin import gemini

不要把它当成“换一个二进制”。要把它当成工程工具迁移。盘点仍然调用旧 CLI 的脚本、alias、hook、插件、环境变量、权限和内部文档。

映射依赖

在脚本、README、本地 CI、shell alias 和项目模板中搜索 Gemini CLI 用法。

迁移插件

运行 agy plugin import gemini，并验证关键流程是否还能读取上下文、调用工具和生成 patch。

重新校准预算

迁移后按任务类型监控消耗；不要假设旧默认配置的运营成本不变。

记录政策

定义何时用 IDE、desktop、CLI 和 SDK；否则每个开发者都会发明自己的成本和风险模式。

实用技巧：按成本和风险路由任务

Antigravity 2.0 的最佳实践不是“永远用最强模型”。而是建立一个简单矩阵：便宜任务用经济模式；不确定任务增加上下文；关键任务使用高推理和人工评审。

任务	初始配置	何时升级
解释文件或函数	经济模型、最小上下文、无长循环。	涉及架构或安全决策时。
局部重构	IDE、小 diff、单元测试和步数限制。	修改公共契约、schema 或认证时。
间歇性 bug	中等推理，附带筛选过的日志。	假设相互冲突且错误代价高时使用高推理。
大型迁移	分阶段计划、人工 checkpoint 和明确预算。	按阶段升级模型和上下文，不要一次性覆盖整个仓库。

这类政策能减少浪费，同时不阻塞生产力。开发者仍然在日常流程中使用 AI，但公司可以避免琐碎任务耗尽本该留给事故、架构和关键交付的配额。

采用前检查清单

在向整个团队开放 Antigravity 2.0 之前，先确定五件事：

默认界面

代码用 IDE，编排用 desktop，自动化用 CLI，内部产品用 SDK。

模型政策

说明分流、简单编辑、调试和架构分别使用哪些模型和推理模式。

允许的数据

分类哪些内容可进入 prompt：公开代码、私有代码、日志、个人数据和密钥。

可观测性

按团队、任务类型、模型和交付结果跟踪消耗。

评审机制

每个由智能体生成的变更都需要与风险相匹配的测试和评审。

结论

Antigravity 2.0 对工程是好消息，但对治理提出了更高要求。它更清晰地分离工作界面，用 agy 改善终端路径，并让开发智能体更接近真实企业流程。作为交换，企业不能再临时 improvisation：共享配额、compute、推理模式和代码访问都需要明确政策。

把它当个人订阅，成本会在之后暴露。把它当智能体执行平台，才能在获得生产力的同时保留控制。

Autenticare 诊断

想启用代码智能体，同时不失去治理能力？

我们帮助团队设计使用政策、CLI 迁移、消耗可观测性，以及安全的工程智能体流水线。

预约沟通查看智能体工厂

延伸阅读

主要来源： Google I/O 2026 developer highlights; Transitioning Gemini CLI to Antigravity CLI; Google AI subscriptions; Google Cloud generative AI security and privacy terms.