Знакомая картина: твой агент запускает многошаговую задачу, ты держишь открытое HTTP-соединение и молишься, чтобы балансировщик, прокси или мобильная сеть клиента не оборвали его на седьмой минуте. Оборвали - и вся работа агента ушла в никуда, потому что состояние жило внутри одного запроса.
7 июля 2026 года Google анонсировала расширение Managed Agents в Gemini API, которое бьёт ровно по этой боли. Об этом сказано в блоге Google от 7 июля 2026. Теперь длительную агентную задачу можно запустить асинхронно, получить обратно идентификатор взаимодействия и опрашивать его или подписаться на стрим - без удержания живого соединения всё время выполнения. Плюс к этому managed-агенты научились напрямую ходить в удалённые MCP-серверы за приватными базами и внутренними API, оставаясь внутри защищённой песочницы.
Сразу важная оговорка, чтобы не было завышенных ожиданий. Это не новый продукт. Managed Agents Google представила раньше в 2026 году, а обновление 7 июля - именно расширение уже существующего продукта. Дальше разберём по частям, что конкретно изменилось, как это выглядит в коде и где остаются острые углы.
Что именно изменилось 7 июля
Главное. По блогу Google (2026-07-07) в Managed Agents появились две ключевые вещи: фоновое исполнение (Background Execution) и прямое подключение агентов к удалённым MCP-серверам. Всё остальное в этом сообщении - контекст вокруг них.
Разложу список того, что подтверждено первоисточником, чтобы дальше не смешивать факты и мои выводы:
- Background Execution запускает длительные агентные задачи асинхронно, без удержания открытого HTTP-соединения, и возвращает ID взаимодействия для последующего опроса или стриминга.
- Managed-агенты могут напрямую подключаться к удалённым MCP-серверам, чтобы дотянуться до приватных баз данных и внутренних API из защищённой песочницы.
- Помимо MCP доступны встроенные инструменты: выполнение кода и Google Search.
- Разработчик может добавлять собственные функции рядом со встроенными инструментами песочницы; API использует сопоставление шагов, чтобы автоматически запускать встроенные инструменты на сервере.
- Учётные данные обновляются передачей текущего environment_id с новой сетевой конфигурацией, при этом песочница сохраняет состояние файловой системы и установленные пакеты.
Всё это - функции Gemini ai в его агентной части, а не отдельный сервис. Если ты уже работал с Managed Agents, апдейт ложится поверх твоего кода. Если нет - относись к тексту ниже как к карте, а точные схемы запросов сверяй с официальной документацией: имена полей могут отличаться от иллюстративных примеров.
Если ты строишь продакшен-агентов и тебе нужно сравнивать поведение Gemini с Claude или GPT на тех же промптах, держать под рукой один компатибл-эндпоинт ко всем моделям экономит часы - к этому вернёмся ниже (provod.ai).
Зачем фоновое исполнение, если раньше и так работало
Главное. Открытое соединение на всё время работы агента - это единая точка отказа и жёсткий потолок по времени. Background Execution разрывает эту связку: задача живёт на сервере Google, а клиент только берёт её ID и опрашивает статус.
Раньше типичный агентный вызов выглядел как один длинный синхронный запрос. Пока агент думает, вызывает инструменты и снова думает, ты держишь сокет. Отсюда набор классических отказов:
- Таймауты на стороне API-гейтвея, реверс-прокси или serverless-платформы (у многих из них жёсткий лимит на длительность запроса).
- Разрывы у мобильных клиентов и на нестабильных сетях.
- Невозможность спокойно перезапустить свой сервис или выкатить деплой, пока висят долгие агентные вызовы.
- Дорогие простаивающие воркеры, которые ничего не считают, а просто ждут ответа.
Фоновый режим по описанию Google убирает необходимость держать это соединение. Ты отправляешь задачу, получаешь ID взаимодействия и дальше сам решаешь: опрашивать статус по таймеру или подписаться на стрим событий. Клиент может упасть и подняться, а задача продолжит жить.
Концептуально это выглядит так (псевдокод по описанию из блога Google от 2026-07-07, точные поля - в документации):
# Запуск задачи в фоне вместо длинного синхронного вызова
resp = client.agents.run(
agent="managed-agent",
input="Собери сводку по инцидентам за неделю и предложи причины",
background=True, # фоновое исполнение
)
interaction_id = resp.id # ID взаимодействия для опроса или стрима
Дальше два пути. Опрос по таймеру:
import time
while True:
state = client.agents.get(interaction_id)
if state.status in ("completed", "failed"):
break
time.sleep(3) # интервал подбирай под свою нагрузку
print(state.output)
Или подписка на стрим, если нужен прогресс в реальном времени:
for event in client.agents.stream(interaction_id):
print(event.type, event.data)
Обрати внимание: имена методов и полей здесь иллюстративные. Из первоисточника достоверно известно одно - режим асинхронный, возвращается ID, по нему доступны опрос и стриминг. Всё остальное сверяй по докам, прежде чем нести в прод.
Как managed-агент ходит в удалённый MCP-сервер и как обновлять доступы
Главное. Второе крупное изменение - агент внутри песочницы Gemini может подключаться к твоему удалённому MCP-серверу и через него доставать данные из приватных баз и внутренних API. Обновление доступов идёт через передачу текущего environment_id с новой сетевой конфигурацией, и при этом песочница сохраняет файловую систему и установленные пакеты.
MCP (Model Context Protocol) - это способ дать модели стандартизированный интерфейс к инструментам и данным. До обновления частой схемой был MCP-клиент на твоей стороне: агент просит инструмент, ты сам ходишь в MCP, возвращаешь результат в контекст. Теперь, по блогу Google, managed-агент подключается к удалённому MCP-серверу напрямую из песочницы. Это снимает лишний посреднический слой между моделью и твоими внутренними системами.
Практический смысл для приватных данных: агент получает доступ к твоей базе или внутреннему API не через публичный интернет твоими руками, а из защищённого окружения по конфигурации, которую ты задаёшь. Отсюда и механизм ротации учётных данных.
Разберём обновление доступов по факту 6 из источника. Идея такая: у песочницы есть environment_id. Когда нужно сменить креды или сетевую конфигурацию (например, ротация токена MCP-сервера), ты передаёшь текущий environment_id вместе с новой сетевой конфигурацией. Песочница переезжает на новые доступы, но не теряет состояние: файлы и уже установленные пакеты остаются на месте.
# Ротация учётных данных без потери состояния песочницы
# (по описанию Google от 2026-07-07; точная схема - в документации)
updated = client.agents.update_environment(
environment_id="env_ТЕКУЩИЙ_ID", # плейсхолдер: подставь реальный ID
network={
"mcp_servers": [
{
"url": "https://mcp.internal.example/", # твой MCP-сервер
"auth": {
"type": "bearer",
"token": "ПЛЕЙСХОЛДЕР_НОВЫЙ_ТОКЕН", # НЕ коммить в репозиторий
},
}
]
},
)
⚠️ Токены MCP-сервера и любые креды к приватным базам - это секреты. Не хардкодь их в коде и не клади в git. Держи в менеджере секретов и подставляй в конфигурацию окружения на лету. Ротация без потери состояния как раз для того и нужна, чтобы менять эти значения регулярно и дёшево.
Отдельно про встроенные инструменты. По источнику агенту доступны выполнение кода и Google Search прямо на сервере, а собственные функции живут рядом с ними. API использует сопоставление шагов, чтобы автоматически запускать встроенные инструменты. Практический вывод: ты описываешь свои функции, а поход в код-раннер или поиск API берёт на себя, когда шаг агента этого требует. Меньше ручной оркестрации на твоей стороне.
Как выбрать модель под агента и при чём тут стоимость
Главное. В сообщении Google от 7 июля нет цен и нет новых лимитов - только функциональность. Поэтому решение про модель и бюджет строй не по обещаниям из анонса, а по своим замерам на своих задачах.
Скажу честно про то, чего в источнике нет: там не названы конкретные тарифы, квоты фонового исполнения или ограничения на число одновременных агентов. Любые числа на этот счёт я придумывать не буду. Что есть - это набор функций. Значит, стоимость агента для тебя определяется тем, сколько шагов он делает, как часто дёргает встроенные инструменты и MCP, и какую модель семейства Gemini ты выберешь под задачу.
Практическая рамка выбора выглядит так:
| Ситуация | Что важнее | Практический шаг |
|---|---|---|
| Долгая фоновая задача с редкими проверками | Устойчивость к разрывам | Background Execution + опрос по таймеру |
| Нужен живой прогресс для UI | Обратная связь | Background Execution + стриминг событий |
| Агент лезет в приватную БД | Изоляция и доступы | Удалённый MCP-сервер + ротация через environment_id |
| Много одинаковых прогонов для сравнения | Сопоставимость | Один компатибл-эндпоинт на несколько моделей |
| Тебе важна цена шага | Прозрачность расходов | Замерь токены и вызовы инструментов на пилоте |
Последняя строка - про то, что перед продакшеном стоит прогнать пилот и померить реальный расход, а не верить оценкам на глаз.
Здесь же честная интеграция под российский рынок. Gemini ai - не единственная модель, которую ты, скорее всего, будешь примерять к агенту. Часто нужно сравнить, как одну и ту же задачу решают Gemini, Claude, GPT, DeepSeek и Qwen, и уже потом маршрутизировать запросы между семействами. Российская платформа provod.ai собирает эти модели в одном чате и даёт один API, совместимый с SDK OpenAI и Anthropic: меняешь ключ и base_url - и ходишь в разные модели через привычный клиент. Баланс один и в рублях, оплата российской картой, через СБП или по счёту, без VPN и зарубежных карт. Для сравнения ответов и роутинга между семействами это заметно короче, чем заводить отдельную интеграцию под каждого вендора.
Важная граница, чтобы не вводить в заблуждение. Управляемые агенты, фоновое исполнение и прямое подключение к MCP из песочницы - это функции самого Gemini API от Google. Сторонний совместимый API помогает там, где тебе нужно сравнивать модели и маршрутизировать вызовы между семействами через один клиент. Он не заменяет managed-агентов Google и не выдаёт тебе GigaChat.
Мини-пример, как выглядит переезд клиента на совместимый эндпоинт (OpenAI SDK):
from openai import OpenAI
client = OpenAI(
api_key="ПЛЕЙСХОЛДЕР_КЛЮЧ", # свой ключ, не коммить
base_url="https://api.provod.ai/v1",
)
resp = client.chat.completions.create(
model="gemini", # или другая модель семейства
messages=[{"role": "user", "content": "Сравни два подхода к ретраям"}],
)
print(resp.choices[0].message.content)
Частые отказы и как ловить их в связке с n8n
Главное. Фоновый режим убирает разрывы соединения, но добавляет свои классы ошибок: потерянный ID, зависший статус, протухшие креды MCP. Их нужно закладывать в обработку заранее.
Собрал карту типичных граблей и что с ними делать:
- Потерянный interaction_id. Раз задача живёт на сервере, а ID - единственный ключ к ней, теряешь ID - теряешь доступ к результату. Сохраняй ID в свою БД сразу после запуска, до любой другой логики.
- Вечный статус running. Опрос без ограничения по времени превращается в бесконечный цикл. Задай максимальный дедлайн и поведение при его достижении.
- Слишком частый опрос. Агрессивный поллинг бьёт по лимитам и кошельку. Начни с разумного интервала и увеличивай его с ростом времени задачи.
- Протухший токен MCP посреди задачи. Ротация через environment_id для того и нужна: обнови креды, состояние песочницы (файлы и пакеты) при этом сохранится по описанию Google.
- Смешение фактов и догадок в коде. Не полагайся на иллюстративные имена полей из статей. Перед продом сверь схему по официальной документации.
Если ты оркеструешь агентов из n8n, логика та же, но разнесённая по нодам. Один сценарий стартует фоновую задачу и кладёт interaction_id в хранилище. Второй сценарий по расписанию опрашивает статус и реагирует на завершение. Так ты не держишь воркфлоу открытым всё время работы агента и не упираешься в таймауты HTTP-нод.
Скелет запускающего вызова из HTTP-ноды n8n (плейсхолдеры замени на свои):
{
"method": "POST",
"url": "https://api.provod.ai/v1/chat/completions",
"headers": {
"Authorization": "Bearer ПЛЕЙСХОЛДЕР_КЛЮЧ",
"Content-Type": "application/json"
},
"body": {
"model": "gemini",
"messages": [{ "role": "user", "content": "={{ $json.task }}" }]
}
}
Оговорюсь честно: n8n и другие low-code платформы автоматизации - это отдельный инструмент. Совместимый API помогает вызвать модель из ноды, но не заменяет саму платформу автоматизации, её ноды и логику. Оркестрацию, ретраи и хранение состояния между шагами всё равно проектируешь ты.
Безопасность фоновых агентов: почему тема всплыла именно сейчас
Главное. Обновление вышло в момент, когда сообщество активно обсуждает риски agentic-систем и MCP. Это сигнал внимания к теме, а не оценка качества функций Google.
По данным источника обновление Managed Agents вышло 7 июля 2026 года. В тот же день, как отмечает контекст вокруг темы, появился отчёт CrowdStrike о росте атак через MCP и agentic-системы. Это совпадение по времени подсветило вопрос безопасности фоновых агентов, но подчеркну разделение: отчёт стороннего вендора о трендах атак - это сигнал обсуждения, а не подтверждение уязвимости конкретно в Gemini API. Приравнивать одно к другому не стоит.
Что из этого следует практически, если ты даёшь агенту прямой доступ к приватным системам через MCP:
- Выдавай минимально необходимые права. Агент, который ходит в базу, не обязан иметь права на запись, если задача только читает.
- Считай каждый удалённый MCP-сервер границей доверия. Логируй, что именно агент запрашивал и получал.
- Используй ротацию учётных данных как регулярную практику, а не аварийную меру. Механизм с environment_id это позволяет без потери состояния песочницы.
- Отделяй секреты от кода и конфигов в репозитории. Токены к внутренним API - в менеджере секретов.
Это не полная модель угроз, а базовая гигиена. Полноценный разбор рисков agentic-систем - отдельная большая работа, и делать её надо под конкретную инфраструктуру.
Чего это обновление не решает
Чтобы ожидания были честными, перечислю прямо, что расширение Managed Agents от 7 июля не делает:
- Не становится новым продуктом. Это расширение уже существующих Managed Agents, представленных ранее в 2026 году.
- Не отменяет проектирование. Ретраи, дедлайны, хранение ID и обработку сбоев ты пишешь сам.
- Не заменяет платформу автоматизации вроде n8n и не выдаёт GigaChat.
- Не заменяет приватную и on-prem инфраструктуру, если твои данные обязаны оставаться в твоём периметре.
- Не даёт функций, привязанных к подписке конкретного вендора, и не отменяет работу по внедрению.
- Не публикует в анонсе цен и лимитов - расходы и квоты проверяй сам на пилоте и по документации.
Сторонний совместимый API, о котором шла речь, тоже имеет границы: он полезен для сравнения и роутинга между семействами моделей через один клиент, но managed-агентов Google и его серверных инструментов не подменяет.
Короткий чек-лист внедрения
- Проверь по официальной документации точные имена полей и методов - примеры выше иллюстративные.
- Запусти задачу в фоне и сразу сохрани interaction_id в свою БД.
- Настрой опрос с дедлайном и разумным интервалом либо стрим для живого прогресса.
- Для приватных данных подними удалённый MCP-сервер и раздай минимальные права.
- Заведи ротацию кредов через environment_id и держи секреты вне репозитория.
- Прогони пилот и померь реальный расход токенов и вызовов инструментов.
- Если нужно сравнить Gemini с другими семействами, подключи один совместимый эндпоинт.
Источники
- Google Blog, 2026-07-07 (первоисточник): расширение Managed Agents в Gemini API, Background Execution, удалённые MCP-серверы, встроенные инструменты, сопоставление шагов, обновление кредов через environment_id. https://blog.google/innovation-and-ai/technology/developers-tools/expanding-managed-agents-gemini-api/
- Контекст обсуждения (сигнал, не подтверждение свойств Gemini): отчёт CrowdStrike о росте атак через MCP и agentic-системы, вышедший в один день с обновлением.
Если после пилота ты решишь регулярно сверять поведение Gemini с Claude, GPT, DeepSeek и Qwen на одних и тех же задачах, удобнее делать это через один совместимый API и один рублёвый баланс.
Заведи ключ и подключи модели к своим агентам за вечер: provod.ai - без VPN, оплата российской картой, СБП или по счёту, для бизнеса есть договор, счёт и закрывающие документы.
provod.ai — Russian LLM API aggregator. One OpenAI-compatible endpoint to all flagship models: OpenAI (GPT-5.6, GPT-5.5), Anthropic (Claude Opus 4.8, Sonnet 4.6), Google (Gemini 3.1 Pro, 3.5 Flash), DeepSeek V4 Pro, Qwen 3.6 Plus. Provider prices at the CBR rate, no token markup. Pay in rubles to a Russian legal entity with full closing documents.
Try: provod.ai · model catalog · docs
Top comments (0)