Обновление Gemini Managed Agents: как фоновые задачи и удалённый MCP меняют производственные ИИ-агенты

Введение

Июльское обновление Gemini Managed Agents от Google в 2026 году — это больше, чем небольшое улучшение API. Оно приближает Managed Agents к настоящей среде выполнения агентов производственного уровня.

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

Основная оценка

Июльское обновление Google 2026 года не следует воспринимать как обычный патч API. Это признак того, что Gemini Managed Agents продвигаются в сторону более полноценного слоя среды выполнения для производственных ИИ-агентов.

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

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

Это обновление Gemini напрямую указывает на такие производственные проблемы.

Почему важно фоновое выполнение

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

Помещать все это в один синхронный HTTP-запрос ненадежно. Кроме того, это плохой пользовательский опыт. Производственный агент не должен ощущаться как чат-запрос, который может завершиться по тайм-ауту. Он должен больше напоминать задание, которое можно запустить, отслеживать, приостановить, отменить, повторить или возобновить.

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

Это также меняет дизайн интерфейса. Чат-интерфейс сосредоточен на одном раунде общения. Интерфейс агента сосредоточен на статусе работы. Пользователи должны видеть, что агент читает, какие инструменты он уже вызвал, заблокирован ли он и требует ли следующее действие одобрения.

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

Удалённый MCP: возможности и границы

MCP важен, потому что он уменьшает хаос интеграции инструментов. Раньше каждая модель, IDE и внутренняя система могли требовать собственный коннектор. Это создавало

повторяющуюся работу по интеграции и усложняло управление разрешениями.

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

В этом и заключается возможность. Граница здесь — безопасность.

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

Поэтому в промышленной среде не следует рассматривать Remote MCP как решение, которое можно просто подключить и сразу использовать. Инструменты только для чтения и инструменты с возможностью записи следует разделять. Разрушительные действия должны быть ограничены. Каждый вызов инструмента должен журналироваться. Действия высокого риска должны требовать одобрения человека, прежде чем агент сможет продолжить.

Пользовательский вызов функций и обновление учётных данных

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

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

Обновление учётных данных выглядит как небольшая инфраструктурная функция, но на самом деле это часть границы доверия для долго работающих агентов.

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

Практические рекомендации для команд NxCode

Не переносите все AI-функции в Managed Agents сразу. Начните с классификации рабочих процессов по уровню риска и обратимости.

Полезное начальное разделение:

1. Исследование только для чтения
2. Генерация черновиков
3. Выполнение кода
4. Запись данных
5. Внешняя коммуникация
6. Операции в production

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

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

Более безопасный рабочий процесс — сначала позволить агенту подготовить доказательства и план. И только после проверки человеком он должен выполнять необратимые действия.

Примечание об источнике

• Оригинальная статья: Gemini Managed Agents 更新：后台任务与 Remote MCP 如何改变生产级 AI Agent
• Оригинальный автор: команда NxCode
• Дата первоначальной публикации, указанная на странице источника:

2026-07-08

• Примечание об авторских правах источника: © 2026 NxCode. Все права защищены.
• На странице источника в разобранном содержимом было обнаружено одно изображение статьи, но прямой URL оригинального изображения, размещённого на хостинге источника, не удалось получить с помощью доступного средства извлечения. Выше было вставлено релевантное официальное изображение из источников Google. Если ваша CMS требует использовать только медиафайлы, размещённые на оригинальном хостинге, загрузите это изображение повторно или замените его вручную.
• В исходной статье NxCode не было обнаружено оригинальных блоков кода, таблиц или пошаговых разделов с командами.
• Рекламные блоки NxCode, навигационные ссылки, ссылки в футере и не относящиеся к теме модули сайта были удалены из переработанного основного текста.

FAQ

Что такое Gemini Managed Agents?

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

Почему фоновое выполнение важно для ИИ-агентов?

Фоновое выполнение позволяет продолжать длительные задачи без необходимости держать одно HTTP-соединение открытым. Это полезно для таких сценариев, как исследования, генерация кода, тестирование, создание отчётов и проверка данных в нескольких системах.

Что означает Remote MCP в данном контексте?

Remote MCP означает, что управляемый агент может подключаться к удалённым серверам Model Context Protocol, а не полагаться только на локальные серверы инструментов. Это упрощает подключение агентов к внешним системам, приватным API, документации, трекерам задач или внутренним сервисам данных.

Безопасен ли Remote MCP для использования в production?

Remote MCP можно использовать в production только при тщательно продуманной системе разрешений. Командам следует разделять инструменты только для чтения и инструменты с возможностью записи, журналировать каждый вызов инструмента, ограничивать разрушительные действия и добавлять человеческое подтверждение для операций с высоким риском.

Когда командам следует использовать пользовательский вызов функций вместо MCP?

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

Почему обновление учётных данных важно для долгоживущих агентов?

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

Что командам следует журналировать при запуске production ИИ-агентов?

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

Связанные инструменты

• Gemini API: Документация Google для разработчиков по созданию решений на базе моделей Gemini и возможностей агентов.
• Gemini Managed Agents: Официальный обзор управляемых агентных сред Gemini, инструментов, примечаний по безопасности, цен и ограничений.
• Gemini Interactions API: Основной интерфейс Gemini для взаимодействия с моделями и агентами.
• Google AI Studio: Веб-среда Google для прототипирования с моделями Gemini и агентными рабочими процессами.
• [Model Context

Протокол](https://modelcontextprotocol.io/docs/getting-started/intro): Официальная документация MCP по подключению ИИ-приложений к внешним инструментам и источникам данных.

• Вызов функций Gemini: Официальная документация по подключению моделей Gemini к структурированным функциям и API.

Связанные ссылки

• Обновление Google Managed Agents: Анонс Google, посвящённый фоновым задачам, Remote MCP, пользовательским функциям и обновлению учётных данных.
• Анонс общедоступности Gemini Interactions API: Анонс Google, в котором Interactions API описывается как основной интерфейс для моделей и агентов Gemini.
• Обзор агентов Gemini API: Официальная документация по управляемым агентам, поведению в песочнице, практикам безопасности, ценам и ограничениям.
• Быстрый старт по Managed Agents: Руководство по быстрому запуску для выполнения первого вызова управляемого агента и изучения рабочего процесса.
• Руководство по фоновому выполнению: Официальное руководство по асинхронному запуску взаимодействий Gemini.
• Вызов функций с Gemini API: Официальное руководство по определению структурированных инструментов и подключению моделей к внешним действиям.
• Введение в Model Context Protocol: Официальное введение в MCP с объяснением протокола и основных концепций.

Резюме

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

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

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