Google Antigravity 现在不再只是开发者单独使用的 AI 编码工具。符合条件的 Gemini Enterprise Standard、Plus 和 Standard Emerging Market 订阅，已经可以启用 Antigravity，并将授权、预算、审计、数据隐私和使用量分析统一纳入 Gemini Enterprise 管理体系。
这次扩展解决的是企业落地 AI 开发工具时最现实的三件事：开发者要在熟悉的环境中工作，治理团队要能设定边界，财务团队则要避免预付配额闲置或失控超支。
一个订阅覆盖开发工具与企业治理
企业通常不缺 AI 工具，真正棘手的是工具越多，账号、发票、账单控制台和安全策略越分散。Antigravity 被纳入 Gemini Enterprise 订阅后，管理员可以为符合条件的用户启用 AI Developer Tools 和 Android Studio，同时在统一的管理控制台中处理：
- 用户和许可证分配
- 项目级月度预算上限
- Token、API 调用和开发者活动统计
- 工作区隔离、浏览器访问和 MCP Server 访问策略
- 审计日志和合规报告
- Google Cloud 体系下的数据隐私与安全控制
这意味着企业可以把 Antigravity 当成软件交付平台的一部分来管理，而不是给开发团队临时采购的一项独立 SaaS 服务。开发速度和组织控制不再需要依赖两套互相脱节的系统。
预算控制从“买多少”转向“怎么使用”
Antigravity 的企业计费能力包含几个关键机制。
项目级支出阈值允许管理员直接在 Billing 控制台设置月度预算上限。每用户和每团队的更细粒度控制也在逐步推出。共享配额池则让高需求团队可以使用组织内的剩余 Token，降低某个团队配额用不完、另一个团队却不够用的情况。
当共享配额达到上限时，管理员还可以选择启用超额消费，并设置月度支出封顶。这样，开发者的任务不会因为配额耗尽突然中断，同时财务团队仍然拥有明确的成本边界。
可以这样设计一份“上线前预算策略”清单：
- 为每个开发项目设置月度预算上限。
- 为实验性项目分配较小的共享配额。
- 对生产交付项目允许有限超额，但配置月度封顶。
- 按项目、团队和用户观察 Token 消耗与 API 调用。
- 每月根据实际使用量调整配额，而不是一次性扩大所有人的额度。
下面是一个示意性的策略配置，用于表达企业内部可以采用的治理结构。字段名称并非 Antigravity 官方 API 格式，落地时应映射到实际的 Gemini Enterprise Billing 和安全策略界面。
# 示例：企业内部的 Antigravity 使用策略
# 假设由平台团队转换为 Gemini Enterprise 管理控制台中的配置
organization: example-corp
ai_developer_tools:
antigravity:
enabled: true
allowed_surfaces:
- vscode
- antigravity-cli
- desktop
projects:
- name: payments-api
monthly_budget_usd: 1500
pooled_quota: engineering-shared
overage:
enabled: true
monthly_cap_usd: 300
- name: prototype-lab
monthly_budget_usd: 300
pooled_quota: experimentation
overage:
enabled: false
security:
workspace_sandboxing: required
browser_access: restricted
mcp_server_access: approved-only
audit_logging: enabled
identity:
workforce_identity_federation: enabled
application_default_credentials: enabled
这类配置的重点不是 YAML 本身，而是把成本、身份和安全规则写成可审查的组织策略，避免每个团队按照自己的理解配置 AI Agent。
在开发者熟悉的工作面中使用 Antigravity
新的 IDE 扩展让开发者可以在原有工作流中使用 Antigravity，包括 Visual Studio Code、Visual Studio 预览版、JetBrains 预览版和 Zed 预览版。此外，团队还可以选择 Antigravity 2.0 桌面应用或 Antigravity CLI。
多入口支持的价值很直接：开发者不必为了使用 Agent 而迁移整个开发环境。IDE 适合代码导航、局部修改和测试反馈；桌面应用适合跨文件、跨步骤的任务；CLI 则更容易接入脚本、CI 流程和远程开发环境。
对于企业 IT 团队，统一身份标准同样重要。Antigravity 的 Workforce Identity Federation（WIF）和 Application Default Credentials（ADC）支持，可以减少人工配置凭据的步骤，并让企业继续沿用现有的身份与访问管理方式。实际部署时，仍应配合最小权限、短生命周期凭据和审计策略，不能因为使用了 ADC 就放宽权限边界。
把 Agent 纳入软件交付的控制面
企业采用 Antigravity 时，重点不应只是“模型能生成多少代码”，而应观察它是否改善了完整的软件交付流程：需求拆解、代码修改、测试执行、问题定位、文档更新和部署准备。
中央审计日志可以记录提示词、Agent 响应及相关元数据，为合规审查和事故调查提供依据。工作区沙箱、浏览器访问和 MCP Server 访问策略，则帮助限制 Agent 能接触的环境与外部系统。数据方面，相关活动仍处于 Google Cloud 的安全边界和服务条款体系中，企业需要结合自身数据分类制度确认哪些代码、凭据和业务数据允许进入 Agent 工作区。
采用时可以按下面的顺序推进：
- 先选择一个有明确交付指标的工程团队进行试点。
- 为试点项目设置预算、配额和超额封顶。
- 仅开放经过审核的 IDE、浏览器和 MCP Server 能力。
- 打开审计日志，观察提示词、响应和敏感数据暴露情况。
- 用交付周期、缺陷率、返工量和 Token 成本评估实际收益。
- 通过试点结果决定是否扩大到更多团队和开发环境。
结语：速度必须和边界一起交付
Google Antigravity 的企业化扩展，核心变化不是增加了一个 IDE 插件，而是把 Agentic Coding 放进了企业已经熟悉的许可证、账单、身份、安全和审计框架中。开发者可以选择 VS Code、JetBrains、CLI 或桌面应用，管理员则可以集中管理访问范围和支出。
对于组织而言，合理的采用标准应当是：能否持续交付更高价值的软件，同时清楚知道谁在使用、消耗了多少、访问了什么数据，以及超出预算时会发生什么。只有当这些问题都有可执行的答案，Antigravity 才适合从个人效率工具走向企业级开发基础设施。