Google Antigravity 与 Managed Agents 重塑 Gemini API：对你的路由架构意味着什么

在 Google I/O 2026 上，Google 不只是发布了一个新模型，而是围绕 Agent 编排对整个开发者平台进行了结构性重组——这对所有运行多 provider AI 基础设施的团队而言，意味着更高的架构风险敞口。

对工程团队影响最深远的变化不是 Gemini 3.5 Flash（定价影响此前已有分析），而是 Gemini API 中的 Managed Agents：一个通过单次调用即可启动完全隔离 Linux 环境的原语，允许 Agent 在多轮会话间推理、使用工具并持久化状态。配套发布的 Google Antigravity 2.0 取代了现有的 Gemini CLI，引入了独立的 Agent 优先桌面应用和 Antigravity SDK，标志着 Google 正式进入与 OpenAI Codex、Claude Code 相同的多 Agent 编排架构竞争赛道。

发生了什么

Google I/O 2026（5 月 19–20 日）发布了五个相互关联的组件：

1. 通过 Interactions API 提供的 Managed Agents。 单次 API 调用可创建一个运行在隔离 Linux 环境中的 Agent，支持推理、工具调用、代码执行，并在后续对话中持久化全部状态。默认底层模型为 Gemini 3.5 Flash，编排框架与 Google 内部产品共用。目前已在 Gemini API 和 Google AI Studio 上线。

2. Antigravity 2.0 桌面应用。 这是一个独立应用（非 IDE 插件），围绕并行 Agent 执行、动态子 Agent、后台定时任务和语音指令构建。定时任务能力尤其值得关注：任务可以在无需人工提示的情况下自动触发 Agent，将工具从单轮对话助手变成持久化的自动化流水线。

3. Antigravity CLI 取代 Gemini CLI。 Gemini CLI 已被弃用。Antigravity CLI 保留了 Gemini CLI 的 Agent Skills、Hooks、Subagents 和 Extensions（现更名为 Antigravity plugins），但运行在统一的 Antigravity Agent 框架上。迁移有文档可循，但不是可选项——旧版 CLI 有明确的下线日期。

4. Antigravity SDK。 对与 Google 内部产品共用的 Agent 框架提供编程访问能力。开发者可定义自定义 Agent 行为并在自己的基础设施上部署。这是希望使用 Antigravity 风格 Agent 而不受 Google 托管执行平面约束的团队的关键路径。

5. Gemini Enterprise Agent Platform。 企业部署路径，将 Antigravity 直接连接到 Google Cloud 项目，面向需要在现有云治理边界内运行 Agent 的团队。

为什么对 AI 工程团队至关重要

Managed Agents 功能对通过 OpenAI 兼容端点或标准 chat completions 调用 Gemini API 的团队影响最为直接。Managed Agents 的 Interactions API 并非 OpenAI 兼容接口，它是一个独立的协议：你传入 Agent ID（如 antigravity-preview-05-2026）和非结构化输入，从一个有状态环境获得 Agent 响应。这意味着：

• 现有通过路由代理转发 /v1/chat/completions 到 Gemini 的设置，无法路由 Managed Agent 调用。 API 结构不同。
• 计费模型不同。 Managed Agents 按 Agent 交互会话计费，而非按 token 数。你当前的 per-token 成本核算可能无法正确捕获这类消费。
• 会话状态造成 provider 粘性。 如果 Agent 跨轮次持久化环境，跨 provider 实例的负载均衡路由必须考虑会话亲和性。简单的轮询路由会破坏已恢复的会话。
• Gemini CLI → Antigravity CLI 迁移影响开发者工具链。 在本地或 CI 工作流中使用 Gemini CLI 的团队需要规划迁移路径。包装 Gemini CLI 行为的 Extensions（插件）需要移植为 Antigravity plugin 格式。

Antigravity SDK 是对路由友好度更高的接口：它自托管、针对 Gemini 优化但架构上可适配，允许团队将编排保留在自己的控制范围内。但如果你需要使用 Managed Agents 执行环境，就必须调用 Google 的云——而不是自己的路由层。

路由/运营商视角

这次发布在 Gemini 使用方式上引入了真正的架构分叉：

路径 A：通过 OpenAI 兼容代理的标准 Gemini API。 你调用 /v1/chat/completions（或 Gemini 原生接口），路由层处理 fallback、成本上限、负载均衡。此路径不受 Antigravity 影响，除非你主动迁移。

路径 B：通过 Interactions API 的 Managed Agents。 Google 管理执行、持久化和工具访问。对于 Agent 调用，路由层实际上被绕过。你用编排控制权换取 Google 托管的可靠性和环境持久化。

路径 C：自托管的 Antigravity SDK。 在自有基础设施上运行自定义 Agent 框架，底层使用 Gemini 模型。集成工作量更大，但路由和治理层可以包装 SDK 调用。

核心运营决策是：你愿意将哪些工作负载的编排层交给 Google 来管理？ Managed Agents 对于短暂、工具密集、有状态的任务（研究扫描、多步代码生成、文件系统任务）具有很强的吸引力。但接受它意味着：这些调用无法通过标准网关路由、不产生标准 token 用量遥测数据、且在不重写客户端的情况下无法 failover 到非 Google provider。

另一方面，Gemini CLI 弃用为工具链中有 Gemini CLI 的团队创造了紧迫的迁移窗口期。Antigravity CLI 在功能层面保持兼容，但名称变更、plugin 格式调整以及新框架意味着自动化脚本中调用 gemini 命令的地方都需要更新。请在下线日期前预留迁移时间。

TheRouter 用户应关注什么

• 检查你的 Gemini 集成使用的是 chat completions 还是 agentic 端点。 如果你通过路由代理调用标准 /v1/chat/completions，Antigravity 的发布今天不会破坏该路径。但如果 Managed Agents 提供了你的团队需要的功能（持久化环境、工具使用、多轮状态），你需要决定是直接调用还是进行包装。

• 密切关注 Interactions API 的计费方式。 基于会话的 Agent 计费是与 per-token 计费截然不同的核算模型。在将 Managed Agents 引入生产工作流之前，请确认用量如何体现在账单中，以及你现有的成本控制工具是否能正确解读。

• 制定 Gemini CLI 迁移计划。 如果 CI 流水线、开发者脚本或 Agent 脚手架引用了 gemini CLI，请在下线日期前安排迁移到 Antigravity CLI。特别要测试 Extensions → Antigravity plugin 的兼容性，尤其是自定义工具定义部分。

• 评估 Antigravity SDK 的自托管方案。 如果你需要 Antigravity 风格的并行 Agent，同时又希望将编排保留在自己的路由边界内，SDK 是正确的接口。它针对 Gemini 优化，但在架构上与 Google 托管执行平面是可分离的。

TheRouter 路由标准 OpenAI 兼容请求到多 provider。通过 Interactions API 的 Managed Agent 会话超出了这个范围——它们携带需要 provider 侧持久化的会话状态。路由/运营商的决策在于：是否将 Managed Agents 视为一个独立的、由 provider 托管的服务（单独追踪其成本），还是选择投入 Antigravity SDK 路径来保持内部编排控制权。