Gemini Managed Agents получили фоновое выполнение и удалённые MCP-серверы: архитектурные изменения для операторов маршрутизации

7 июля 2026 года Google выпустила четыре новых возможности для Gemini Managed Agents (Interactions API): фоновое выполнение, интеграция с удалёнными MCP-серверами, вызов пользовательских функций рядом со встроенными инструментами sandbox, а также обновление учётных данных между взаимодействиями. Первые два пункта напрямую влияют на то, как AI-инженерные команды проектируют, развёртывают и маршрутизируют production-пайплайны на основе агентов.

Что произошло

Платформа Gemini Managed Agents, построенная поверх Interactions API, которое достигло GA в июне 2026 года, позволяет отправить запрос к единственному endpoint и доверить Gemini рассуждение, выполнение кода, установку пакетов и управление файлами внутри изолированного облачного sandbox. Обновление 7 июля добавляет:

1. Фоновое выполнение (background: true): вместо поддержки открытого HTTP-соединения во время работы агента API немедленно возвращает interaction ID. Клиенты могут опрашивать статус, получать потоковый прогресс или переподключаться позже.

2. Интеграция с удалёнными MCP-серверами: операторы могут передавать инструмент mcp_server с любым URL, комбинируя подключение к приватным внутренним сервисам со встроенными возможностями sandbox (выполнение кода, веб-поиск) — без построения proxy-middleware.

3. Вызов пользовательских функций: клиентские функции работают рядом со встроенными инструментами sandbox. API использует step matching — встроенные инструменты выполняются автоматически на сервере; пользовательские функции возвращаются как события requires_action для клиентского выполнения.

4. Обновление учётных данных: передача существующего environment_id с новой конфигурацией network ротирует токены без переинициализации sandbox-окружения. Файловая система, установленные пакеты и склонированные репозитории сохраняются.

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

Синхронная HTTP-модель была главным операционным возражением против использования managed agents в production. Долгосрочные задачи — аудит репозитория, генерация compliance-отчёта, оркестрация многошагового data pipeline — регулярно выходят за разумные бюджеты HTTP-таймаутов. Прежде команды либо ограничивались короткими задачами, либо строили собственные асинхронные обёртки поверх API.

Фоновое выполнение превращает Interactions API в queue-backed worker. Interaction ID заменяет открытое соединение в качестве точки привязки состояния. Это одновременно меняет два инженерных паттерна:

• Политика таймаутов: жёсткие ограничения на время HTTP-ответа больше не определяют сложность допустимых задач. Задача на 20 минут запускается так же просто, как задача на 20 секунд.
• Переподключение клиента: если клиентский процесс упал, достаточно возобновить мониторинг по interaction ID — повтор задачи не требуется.

Интеграция удалённых MCP-серверов решает отдельную проблему: доступ к приватным инструментам. Раньше операторам приходилось строить HTTP proxy middleware, чтобы sandbox-агент мог обращаться к внутренним базам данных, telemetry API или реестрам кода. Теперь достаточно передать mcp_server как инструмент — агент подключается напрямую из безопасного sandbox.

Угол зрения маршрутизатора и оператора

Для команд, маршрутизирующих нагрузку между несколькими AI-провайдерами, оба обновления меняют позиционирование Gemini Managed Agents как варианта для routing.

Фоновое выполнение смещает ось сравнения провайдеров. Синхронные провайдеры агентов (клиент держит соединение открытым) накладывают жёсткий потолок на длительность задачи. Провайдеры с фоновым выполнением (Gemini Interactions API и аналогичные платформы) создают лишь overhead на polling. Для задач, стабильно укладывающихся в минуту, синхронная маршрутизация даёт меньшую воспринимаемую задержку. Для открытых агентных задач с непредсказуемой длительностью фоновое выполнение надёжнее. Это теперь явное измерение маршрутизации, которое операторы должны настраивать под каждую рабочую нагрузку.

Удалённые MCP меняют топологию инструментов. Если ваши внутренние инструменты уже реализованы как MCP-серверы, Gemini Managed Agents может обращаться к ним напрямую — без промежуточного proxy. Это структурное упрощение: один сервис меньше для поддержки, одна точка отказа меньше в цепочке зависимостей. Операторам стоит проверить, какие внутренние инструменты сейчас проксируются в их agent-пайплайны, и оценить, упростит ли переход на прямые MCP-подключения инфраструктуру.

Ротация учётных данных без перезапуска окружения — третье изменение с прямым операционным эффектом. Короткоживущие токены в долгосрочных агентных задачах прежде требовали либо долгосрочных учётных данных (риск безопасности), либо перезапуска sandbox (потеря состояния выполнения). Паттерн повторного использования environment_id позволяет ротировать токены в любой момент многошагового workflow.

Таблица для принятия решений:

Что стоит проверить пользователям TheRouter

Если вы маршрутизируете agentic-нагрузки на программирование между несколькими провайдерами, Gemini Managed Agents теперь стоит повторно рассмотреть как целевой routing-вариант. Модель фонового выполнения и поддержка удалённых MCP устраняют два наиболее распространённых операционных возражения: хрупкость соединения и доступ к приватным инструментам.

При сравнении провайдеров для долгосрочных агентных задач тестируйте с учётом реальных требований к таймаутам и переподключению, а не только по benchmark-результатам. Провайдер с поддержкой фонового выполнения и polling API может превосходить синхронного конкурента по надёжности даже при схожей пропускной способности.

Подробный справочник параметров для фонового выполнения и конфигурации удалённых MCP доступен в документации Antigravity agent.

Контекст об эволюции более широкой платформы Gemini managed agents см. в материале о решении по маршрутизации Interactions API GA.