Google Antigravity и Managed Agents перекраивают Gemini API: что это значит для вашей routing-архитектуры

На Google I/O 2026 Google не просто выпустила новую модель. Она перестроила всю поверхность для разработчиков вокруг агентной оркестрации — и тем самым тихо повысила ставки для каждой команды, эксплуатирующей multi-provider AI-инфраструктуру.

Самое значимое для инженерных команд изменение — не Gemini 3.5 Flash (мы уже разбирали её отдельно). Это Managed Agents в Gemini API: примитив на один вызов, который поднимает полностью изолированное Linux-окружение, позволяет агенту рассуждать и пользоваться инструментами, и сохраняет состояние этого окружения между ходами сессии. Сопутствующая платформа — Google Antigravity 2.0 — заменяет нынешнюю Gemini CLI, представляет автономное agent-first приложение для десктопа и Antigravity SDK, и сигнализирует, что Google теперь конкурирует на том же архитектурном поле, что и слои оркестрации мульти-агентов вроде OpenAI Codex и Claude Code.

Что изменилось

Google I/O 2026 (19–20 мая) принёс пять взаимосвязанных кусочков:

1. Managed Agents через Interactions API. Один вызов API создаёт агента, работающего внутри изолированного Linux-окружения. Агент рассуждает, вызывает инструменты, выполняет код с полным сохранением состояния между последующими вызовами. Под капотом по умолчанию — Gemini 3.5 Flash; harness оркестрации тот же, что Google использует внутри. Доступно уже сейчас в Gemini API и Google AI Studio.

2. Десктопное приложение Antigravity 2.0. Самостоятельное приложение — не плагин к IDE, — построенное вокруг параллельного выполнения агентов, динамических subagent-ов, фоновых задач по расписанию и голосовых команд. Возможность планирования примечательна: задачи могут запускать агентов автоматически, без человеческого промпта, фактически превращая инструмент из single-turn ассистента в постоянный пайплайн автоматизации.

3. Antigravity CLI заменяет Gemini CLI. Gemini CLI объявлена устаревшей. Antigravity CLI сохраняет Agent Skills, Hooks, Subagents и Extensions из Gemini CLI (теперь они называются Antigravity-плагинами), но работает на общем harness-е Antigravity. Миграция задокументирована, но не опциональна — у старого CLI есть дата отключения.

4. Antigravity SDK. Программный доступ к тому же agent-harness-у, который питает продукты Google. Разработчики могут описывать кастомные поведения агентов и самостоятельно хостить их на своей инфраструктуре. Это путь для команд, которым нужны агенты в стиле Antigravity без привязки к managed execution plane Google.

5. Gemini Enterprise Agent Platform. Корпоративный путь развёртывания, связывающий Antigravity с Google Cloud проектами и ориентированный на команды, которым нужно, чтобы агенты работали внутри существующего периметра cloud governance.

Почему это важно для AI-инженерных команд

Фича Managed Agents — самое острое изменение для команд, которые сейчас обращаются к Gemini API через OpenAI-совместимые эндпоинты или стандартные chat completions. Interactions API для Managed Agents не OpenAI-совместимая поверхность. Это отдельный протокол: вы вызываете agent ID (antigravity-preview-05-2026), передаёте неструктурированный input и получаете agentic-ответ от stateful окружения. Это означает:

• Существующие routing-proxy, которые перенаправляют /v1/chat/completions в Gemini, не маршрутизируют вызовы Managed Agent. Форма API другая.
• Модель тарификации другая. Managed Agents тарифицируются по сессиям взаимодействия с агентом, а не только по числу токенов. Текущий учёт стоимости per-token может не отражать это корректно.
• Состояние сессии создаёт «липкость» на уровне сессии. Если агент сохраняет окружение между ходами, то routing/балансировка нагрузки между instance-ами provider-а должна учитывать session affinity. Наивный round-robin сломает возобновлённые сессии.
• Миграция Gemini CLI → Antigravity CLI затрагивает тулчейн разработчиков. Командам, использующим Gemini CLI в локальных или CI-воркфлоу, нужно спланировать миграцию. Extensions (плагины), оборачивающие поведение Gemini CLI, придётся портировать в формат плагинов Antigravity.

Antigravity SDK — куда более дружелюбная к router-у поверхность: self-hosted, оптимизированная под Gemini, но потенциально адаптируемая, и позволяет командам оставить оркестрацию под собственным контролем. Но если вам нужно именно исполнительное окружение Managed Agents, вы зовёте облако Google, а не свой routing-слой.

Взгляд router/operator

Это объявление вводит реальную архитектурную развилку в том, как команды потребляют Gemini:

Путь A: стандартный Gemini API через OpenAI-совместимый proxy. Вы зовёте /v1/chat/completions (или нативный Gemini), routing-слой делает fallback, ограничение стоимости, балансировку нагрузки. Этот путь не затронут Antigravity, пока вы не мигрируете.

Путь B: Managed Agents через Interactions API. Google управляет исполнением, персистентностью и доступом к инструментам. Ваш routing-слой по факту обходится стороной для agent-вызовов. Вы меняете контроль над оркестрацией на надёжность и персистентность окружения от Google.

Путь C: Antigravity SDK, self-hosted. Кастомный agent-harness на вашей инфраструктуре, модели Gemini под капотом. Больше работы по интеграции, зато routing и governance остаются вашими.

Главный operator-вопрос: для каких нагрузок вы отдаёте слой оркестрации Google? Предложение Managed Agents привлекательно для эфемерных, tool-heavy stateful задач (research-обходы, многошаговая генерация кода, задачи на файловой системе). Но согласие на него означает, что эти вызовы не маршрутизируются через ваш стандартный gateway, не дают стандартной телеметрии по token-usage и не могут отказно перейти к не-Google provider-у без переписывания клиента.

Отдельно, deprecation Gemini CLI создаёт срочное окно миграции для любой команды, в чьём тулчейне есть Gemini CLI. Antigravity CLI совместим на уровне фич, но переименование, смена формата плагинов и новый harness означают, что автоматические скрипты, вызывающие команды gemini, нужно обновлять. Заложите время на это до даты отключения.

На что обратить внимание пользователям TheRouter

• Проверьте, использует ли ваша Gemini-интеграция chat completions или agentic эндпоинты. Если вы зовёте стандартный /v1/chat/completions через routing-proxy, запуск Antigravity не ломает этот путь сегодня. Однако, если Managed Agents дают возможности, которых хочет ваша команда (персистентное окружение, tool use, multi-turn state), вам придётся решить, звать их напрямую или оборачивать.

• Внимательно следите за прайсингом Interactions API. Тарификация по сессиям агента — это другая модель учёта, нежели per-token billing. До того как закладывать Managed Agents в production-воркфлоу, проверьте, как usage будет отображаться в сверке счетов и сможет ли ваш cost-control тулинг его правильно интерпретировать.

• Спланируйте миграцию Gemini CLI. Если CI-пайплайны, скрипты разработчиков или agent-каркасы ссылаются на CLI gemini, запланируйте миграцию на Antigravity CLI до даты отключения. Протестируйте совместимость Extensions → Antigravity-плагины, особенно кастомные определения инструментов.

• Оцените Antigravity SDK для self-hosted сценариев. Если вам нужны параллельные агенты в стиле Antigravity, но при этом важно держать оркестрацию внутри своего routing-периметра, SDK — правильная поверхность. Он оптимизирован под Gemini, но архитектурно отделим от managed execution plane Google.

TheRouter маршрутизирует стандартные OpenAI-совместимые запросы между provider-ами. Сессии Managed Agent через Interactions API по дизайну находятся вне этой зоны — они несут состояние сессии, требующее персистентности на стороне provider-а. Решение router/operator — рассматривать ли Managed Agents как отдельный сервис, управляемый provider-ом (и просто учитывать его стоимость отдельно), либо инвестировать в путь Antigravity SDK, чтобы сохранить контроль над оркестрацией внутри команды.