ИИ-агенты Gemini теперь завершают задачи после отключения

Теперь ИИ-агенты Gemini могут получить многоэтапную задачу и продолжить её выполнение на сервере Google, даже когда пользователь отключился. При этом код, файлы, установленные пакеты и подключения к удалённым инструментам сохраняются. В июльском обновлении Managed Agents 2026 года появились четыре возможности, благодаря которым такой сценарий стал практичным: фоновое выполнение, прямое подключение к удалённым MCP-серверам, вызов пользовательских функций и обновление учётных данных без пересоздания рабочей среды.

Теперь эту технологию полезнее представлять не как чат-бота в постоянно открытой вкладке, а как облачного исполнителя: ему передают задание, а затем возвращаются за готовым результатом.

Как устроены ИИ-агенты Gemini Managed Agents

Gemini Managed Agents — это временные облачные исполнители с собственной рабочей средой Linux. Один вызов через Interactions API разворачивает среду, в которой агент может обдумывать задачу, выполнять команды Bash, Python или Node.js, устанавливать пакеты, работать с файлами, искать информацию в интернете и повторять эти действия до получения результата.

По умолчанию задачи выполняет агент Antigravity от Google, который сейчас обозначается как antigravity-preview-05-2026 и работает на базе Gemini 3.5 Flash. Сам Interactions API стал общедоступным в июне 2026 года, однако Managed Agents и их рабочие среды всё ещё находятся на стадии публичного предварительного доступа.

За два разных вида памяти отвечают два идентификатора:

• previous_interaction_id можно считать папкой задачи: в ней сохраняются диалог, ход рассуждений и история вызова инструментов.
• environment_id служит ключом от мастерской: с ним снова открываются та же файловая система, установленные пакеты и состояние репозитория.

Эти идентификаторы можно использовать независимо. Если передать только ID среды, начнётся новый диалог в прежней рабочей среде. Если передать оба ID, продолжится та же задача в том же месте. Примерно после 135,000 токенов автоматически запускается сжатие контекста: старая детализация сокращается, и длинная сессия не сразу упирается в предел контекстного окна.

По своим возможностям решение находится между пользовательскими ИИ-агентами, знакомыми большинству команд, и инфраструктурой, которую обычно пришлось бы собирать самостоятельно. Google управляет циклом модели и песочницей. Логика продукта, разрешения, правила согласования, мониторинг и пользовательский опыт остаются зоной ответственности разработчика.

Как работает этот процесс — без лишнего жаргона

В новом процессе шесть основных элементов:

1. Создать рабочую среду или открыть прежнюю. Для новой песочницы используется environment: "remote"; для повторного запуска — ID существующей среды. Также можно передать полную конфигурацию с исходными репозиториями и сетевыми правилами.
2. Оставить агенту только необходимые инструменты. В своей среде он может выполнять код, пользоваться Google Search, читать URL и работать с файловой системой. Удалённый MCP-сервер выступает стандартным коннектором к внешним инструментам. Для подключения нужны имя в нижнем регистре, URL и транспорт Streamable HTTP. Кроме того, можно ограничить набор инструментов сервера, доступных агенту.
3. Отправить задачу в фон. Установите background: true. API сразу вернёт ID взаимодействия, поэтому одному нестабильному HTTP-соединению не придётся оставаться открытым до конца работы. Для фоновых задач требуется store: true; это значение используется по умолчанию.
4. Следить за выполнением без постоянно открытого соединения. Состояние взаимодействия можно опрашивать или получать через поток событий. Если поток оборвётся, достаточно переподключиться с последним event_id. Задача может выполняться, ожидать действия, завершиться успешно, завершиться с ошибкой или быть отменена.
5. Выполнять чувствительные бизнес-операции в своём приложении. Встроенные инструменты песочницы работают на стороне Google. Пользовательская функция приостанавливает взаимодействие в состоянии requires_action, чтобы приложение могло проверить запрос, запросить подтверждение человека, выполнить локальную бизнес-логику и вернуть результат агенту.
6. Продолжить работу после завершения. В следующем запросе можно передать ID завершённого взаимодействия вместе с ID его среды. Если токен доступа истёк, тот же ID среды отправляется с новой сетевой конфигурацией. Новые правила заменят прежние, но файлы, пакеты и клонированные репозитории сохранятся.

Рабочая среда сохраняется надолго, но не навсегда. После 15 минут бездействия она останавливается с сохранением снимка состояния, в течение семи дней с момента последней активности её можно возобновить, а затем она удаляется. Сейчас каждой среде выделяются четыре ядра CPU и 16 GB памяти.

Семь сценариев, в которых польза заметнее всего

Сценарии расположены по тому, насколько прямо новые возможности устраняют дорогостоящие операционные узкие места.

1. Ревью pull request с кодом, созданным ИИ

Продуктовая команда, постоянно получающая машинно написанный код, может запускать отдельную фоновую задачу для каждого pull request. Агент откроет репозиторий, изучит diff, развернёт проект, прогонит тесты, найдёт источник сбоя, проследив связи между файлами, и подготовит ревью с логами и предлагаемым исправлением. Подключение к GitHub или GitLab можно организовать через удалённый MCP-сервер, а публикацию итогового комментария или изменение кода оставить за пользовательской функцией, требующей подтверждения.

Главная ценность — не ещё один общий комментарий к коду, а первичная проверка, подкреплённая результатами реального запуска и готовая до того, как pull request откроет старший инженер. Это особенно важно по мере того, как асинхронная разработка становится обычным форматом работы — этот сдвиг уже заметен в мобильных и фоновых агентах для написания кода.

2. Регулярная операционная отчётность для финансовых и аналитических команд

Когда появляются свежие CSV-выгрузки, операционный аналитик может запустить исполнителя, подключить его к хранилищу данных через MCP и поручить ему очистку данных, анализ в Python, построение графиков и сохранение рабочих файлов в одной среде. Если срок действия короткоживущего токена хранилища закончится, приложение передаст новый токен, а агенту не придётся заново устанавливать инструменты или создавать промежуточные файлы.

Преимущество здесь — непрерывность процесса. Аналитик получает на проверку готовый отчёт со всеми вспомогательными файлами вместо того, чтобы снова и снова переносить данные между ноутбуком, таблицей, инструментом визуализации и окном чата.

3. Расследование инцидентов командами надёжности

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

Это ускоряет сбор доказательств в условиях дефицита времени. При этом любые действия по исправлению ситуации в продакшене должны проходить через явное подтверждение человека. Исполнитель с доступом к инструментам полезен во время инцидента, но бесконтрольный исполнитель с широкими учётными данными для продакшена сам рискует стать причиной следующего инцидента.

4. Сбор аудиторских доказательств командами безопасности

Специалист по комплаенсу, готовящий проверку прав доступа, может ограничить песочницу списком разрешённых доменов, передать учётные данные только для чтения через egress-прокси Google и поручить агенту собрать политики, настройки репозиториев и историю изменений. Поскольку учётные данные добавляются на сетевой границе, они не попадают ни в файлы песочницы, ни в переменные среды.

Вместо недели, потраченной на скриншоты и копирование данных, команда получает воспроизводимый пакет доказательств. Но приложению всё равно потребуются собственный аудиторский след и процесс утверждения: Managed Agents не являются готовым продуктом для комплаенса.

5. Комплексная проверка для инвесторов и закупочных команд

Небольшая инвестиционная команда может поручить фоновому исполнителю ограниченное исследование: составить карту рынка, сопоставить заявления поставщиков, изучить репозиторий, провести расчёты и подготовить записку со ссылками на источники. Файлы и скрипты останутся доступными для уточняющих вопросов, поэтому на втором этапе можно проверять исходные предположения, а не воссоздавать всю исследовательскую среду.

Так удаётся повысить глубину анализа, не занимая браузерную сессию аналитика. Однако есть важное ограничение: сейчас Antigravity принимает на вход текст и изображения, но не аудио, видео или документы. Поэтому процессам с большим объёмом документов понадобится внешний этап извлечения данных.

6. Повторяемые клиентские аудиты для агентств

Аналитическое агентство или студия разработки может создать отдельную среду для аудита каждого клиента, подключить только одобренные им системы и запускать длительные проверки независимо друг от друга. В одной среде могут находиться клонированный сайт и скрипты измерения производительности, в другой — выгрузка кампании и код для формирования отчётности.

Преимущества такого подхода — изоляция и воспроизводимость. В течение семидневного окна команда может вернуться ровно к тому же рабочему состоянию, не смешивая файлы или учётные данные разных клиентов.

7. Разбор сложных обращений в бэк-офисе

Страховая, логистическая или клиентская служба может поручить управляемому исполнителю собрать историю обращения из нескольких систем, проверить правила, рассчитать варианты и подготовить следующее действие. Удалённые MCP-инструменты обеспечат доступ на чтение, а пользовательские функции позволят проводить возвраты, изменения аккаунта и решения по страховым случаям только через проверенную логику приложения и с подтверждением человека.

В итоге для всего обращения, связанного с несколькими системами, используется единая непрерывная рабочая среда. Это особенно ценно, когда исследование одного случая занимает несколько минут и не сводится к простой автоматизации по принципу «триггер — действие».

Три продукта, которые стоит создать

Сама технология применима очень широко. Но продаваемые продукты должны решать узкую, измеримую задачу и включать контроль, необходимый для доверия.

1. Самая сильная идея: ИИ для ревью кода с доказательствами

Создайте приложение для GitHub или GitLab, рассчитанное на команды, которым мало комментариев к diff. Для каждого pull request оно запускает проект в изолированной среде, воспроизводит предполагаемые ошибки, прикладывает логи, готовит исправление и ждёт решения человека, прежде чем менять код.

Спрос вполне конкретен. По оценке DataForSEO, запрос “AI code review” получает около 1,300 поисковых запросов в США ежемесячно, а его CPC составляет $46.65. Ещё около 590 запросов в месяц приходится на “AI code review tools”; в текущем наборе ключевых слов его годовой рост составляет 85%. Покупатели уже готовы платить: тарифы CodeRabbit стоят от $24 до $48 за пользователя в месяц при ежегодной оплате, а Greptile указывает цену $30 за рабочее место в месяц.

Минимальная продаваемая версия включает одну интеграцию с системой контроля версий, один файл инструкций для репозитория, фоновый запуск тестов, страницу результата с исходными доказательствами и одно подтверждаемое действие — публикацию ревью или создание патча. Не пытайтесь сразу поддержать все языки. Начните с одной экосистемы, где тесты распространены, а настройка среды выполнения предсказуема.

Главные сложности — насыщенный рынок и дефицит доверия. Среди реальных поисковых вопросов встречаются “How does AI code review work?” и “Is the AI code safe?”. Доступ к Gemini не станет вашим конкурентным преимуществом. Защитить продукт смогут растущий набор оценочных сценариев, правила для конкретных репозиториев, низкая доля ложных срабатываний и проверяемые доказательства для каждого вывода.

2. Агент для регулярной подготовки сверенной отчётности

Создайте исполнителя, который превращает еженедельные или ежемесячные исходные данные одной компании в сверенный отчёт, сохраняя рядом с результатом код анализа и промежуточные файлы. Операционные, финансовые команды и специалисты по выручке платят за такое решение, потому что задача повторяется, а ошибки хорошо заметны.

По оценке DataForSEO, коммерческий запрос “AI for data analysis” получает 3,600 поисковых запросов в США ежемесячно, а его CPC составляет $41.92. Более узкий запрос “AI agent for data analysis” набирает около 320 запросов в месяц, а его сложность по текущему набору ключевых слов равна 2. Это указывает на свободную точку входа в органический поиск, хотя рынок в целом уже конкурентный.

Для MVP нужны внешний планировщик или триггер появления файла, один коннектор к хранилищу данных, выгрузка в одну электронную таблицу, фиксированный шаблон отчёта, журнал запусков и экран сверки. Ограничение, о котором важно говорить прямо, — надёжность результата. Antigravity не поддерживает структурированный вывод, поэтому важные таблицы и итоговые значения необходимо детерминированно проверять до передачи пользователю.

3. Вертикальный исполнитель процессов с настоящими этапами согласования

Выберите один тип задач — например, подключение поставщиков, первичную обработку страховых случаев или сбор доказательств для аудита безопасности. Продукт получает контекст через два-три MCP-подключения, выполняет длительный анализ в фоне, а для немногочисленных действий, требующих проверки или согласования, использует пользовательские функции.

По оценке DataForSEO, коммерческий запрос “AI workflow automation” получает 1,000 поисковых запросов в США ежемесячно, а его CPC составляет $49.51. Ещё около 260 запросов в месяц приходится на “AI workflow automation platform”; в текущем наборе ключевых слов его годовой рост составляет 320%. Пользователи прямо спрашивают: “How can I automate my workflows using AI?”

Минимальная версия — одна очередь, один чётко очерченный процесс, две интеграции, входящие запросы на согласование и полная история выполнения. Основной риск — ловушка горизонтальной платформы. Если первая версия обещает автоматизировать любой процесс, всю команду поглотят разработка коннекторов и обработка пограничных случаев. Сначала нужно занять нишу одного дорогостоящего процесса.

Какие задачи Managed Agents не решают

Управляемое выполнение сокращает объём инфраструктурной работы, но не снимает продуктовые и операционные риски.

Механизм обновления учётных данных тоже важно понимать точно. Когда приложение передаёт новые сетевые правила и свежий токен, Google сохраняет прежнюю среду. Сам агент не выпускает и не обновляет этот токен.

Мой вывод: технология подходит для ограниченных задач с ясными критериями завершения, проверяемыми артефактами, минимальными разрешениями и этапами согласования. Не стоит превращать preview-агента в самостоятельного администратора продакшена. Google рекомендует проверять созданный код, преобразования данных, изменения конфигурации и внешние действия, прежде чем на них полагаться.

Что такое автоматизация рабочих процессов с ИИ?

Это процесс, в котором модель учитывает контекст и сама выбирает инструменты, а не просто выполняет заранее заданную последовательность триггеров. Gemini Managed Agents добавляют облачную рабочую среду и фоновое выполнение, но разрешения, триггеры, проверки и согласования по-прежнему задаёт приложение.

Как автоматизировать рабочие процессы с помощью ИИ?

Начните с одной ограниченной задачи: у неё должны быть однозначные входные данные, проверяемый результат и не более нескольких подключений к инструментам. Выполняйте анализ в фоне, оставляйте узкие права на чтение, а каждое необратимое действие проводите через пользовательскую функцию или подтверждение человека.

Как выглядит рабочий процесс с ИИ-автоматизацией?

Хороший пример — ИИ-ревьюер pull request: он получает новый запрос, открывает репозиторий в песочнице, устанавливает зависимости, запускает тесты, анализирует сбои, готовит ревью и ждёт подтверждения, прежде чем опубликовать результат или изменить код.

Как ИИ выполняет ревью кода?

Система изучает изменение кода в контексте репозитория, ищет дефекты и нарушения правил, а затем формулирует замечания. Управляемый агент способен пойти дальше: запустить проект и приложить логи или результаты тестов. Однако человек всё равно должен решить, соответствует ли вывод реальному замыслу продукта.

Безопасен ли код, созданный ИИ?

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

Если нужен такой исполнитель, спроектированный под ваши системы, разрешения и правила согласования, изучите услугу разработки ИИ-агентов.