Облачные вычисления переживают очередную трансформацию. Если раньше инфраструктура проектировалась вокруг приложений и контейнеров, то теперь на первый план выходят автономные ИИ-агенты — сущности, которые принимают решения, вызывают инструменты и взаимодействуют друг с другом. Компания Google объявила о запуске Agent Compute Engine — специализированного сервиса в составе Google Cloud, который выделяет каждому ИИ-агенту отдельную микро-виртуальную машину. Это решение обещает перевернуть представление о том, как строятся среды выполнения для agentic AI, и задаёт новые стандарты изоляции, безопасности и управляемости.
Что такое Agent Compute Engine и зачем он нужен
Agent Compute Engine (ACE) — это управляемый вычислительный слой, ориентированный исключительно на рабочие нагрузки, связанные с ИИ-агентами. В отличие от классических serverless-функций или контейнерных платформ, где несколько процессов делят общее окружение, ACE предоставляет каждому агенту персональную микро-VM. Такая виртуальная машина запускается за доли секунды, имеет собственное ядро, файловую систему, сетевой стек и изолированную память.
Подобный подход решает фундаментальную проблему: агенты, работающие на базе больших языковых моделей (LLM), ведут себя непредсказуемо. Они генерируют код, выполняют его, обращаются к внешним API, читают и записывают данные. Если несколько таких агентов работают в одном процессе, риск конфликтов, утечек контекста и взаимного влияния становится критическим. Микро-VM устраняет эти риски на аппаратном уровне изоляции.
Ключевые отличия от традиционных подходов
- Полная изоляция: каждый агент работает в собственном ядре, что исключает атаки типа side-channel и утечки данных между задачами.
- Мгновенный запуск: микро-VM стартуют за миллисекунды, что критично для сценариев, где агенты вызываются массово и параллельно.
- Гибкость конфигурации: можно задавать лимиты CPU, памяти, дискового пространства и сетевых политик индивидуально для каждого агента.
- Интеграция с инструментами Google Cloud: логирование, мониторинг, IAM и биллинг работают «из коробки».
Почему именно микро-VM, а не контейнеры
Контейнеры долгое время были золотым стандартом изоляции в облаке, но для агентных нагрузок они оказываются недостаточно надёжными. Агент, выполняющий сгенерированный код, может попытаться выйти за пределы песочницы, использовать уязвимости ядра или злоупотребить общими ресурсами. Микро-VM, построенные на технологиях вроде gVisor или облегчённых гипервизоров, обеспечивают более жёсткую границу между средами.
Кроме того, микро-VM позволяют реализовать так называемую «песочницу с состоянием»: агент может сохранять файлы, устанавливать зависимости и накапливать контекст в рамках своей сессии, не опасаясь, что это повлияет на других. Это особенно важно для длительных задач — например, агентов, которые часами исследуют данные или ведут многошаговые переговоры с другими сервисами.
Роль контекстной инженерии
Отдельная микро-VM открывает новые возможности для context engineering — дисциплины, которая управляет тем, какая информация попадает в окно контекста языковой модели. Изолированная среда позволяет агентам хранить промежуточные артефакты, кэшировать результаты вызовов инструментов и вести собственные журналы, не перегружая общий контекст. В результате модели получают более чистые и релевантные данные, а значит, работают точнее и дешевле.
Безопасность и управляемость на новом уровне
Google делает акцент на том, что ACE создан с прицелом на корпоративное использование. Каждый агент получает собственные учётные данные и политики доступа, что упрощает аудит. Если агент скомпрометирован, злоумышленник остаётся запертым в пределах одной микро-VM и не может дотянуться до соседних задач или корпоративных данных.
Дополнительно платформа поддерживает:
- Автоматическое завершение сессий по истечении заданного времени или бюджета.
- Детальную телеметрию: сколько токенов потрачено, какие инструменты вызывались, сколько длился каждый шаг.
- Политики сетевого доступа, ограничивающие, к каким внешним сервисам может обращаться агент.
- Возможность «заморозить» состояние агента и возобновить его позже — полезно для долгоживущих рабочих процессов.
Как это вписывается в экосистему Google Cloud
Agent Compute Engine не существует в вакууме. Он тесно интегрирован с Vertex AI, где разрабатываются и настраиваются сами модели, а также с Gemini — флагманским семейством LLM от Google. Разработчик может описать агента, определить его инструменты и политики, а затем развернуть его в ACE буквально одной командой или через консоль.
Для команд, которые уже используют Google Kubernetes Engine, предусмотрены мосты совместимости: агенты могут вызываться как обычные сервисы, а результаты их работы — попадать в общие пайплайны данных. Это снижает порог входа и позволяет встраивать agentic AI в существующие архитектуры без полной перестройки.
Влияние на рынок AI Infrastructure
Запуск ACE — это сигнал всему рынку AI-инфраструктуры. Конкуренты, включая AWS и Microsoft Azure, уже предлагают собственные песочницы для агентов, но идея «одна микро-VM на агента» пока выглядит наиболее радикальной. Она отражает сдвиг в мышлении: агенты рассматриваются не как функции, а как полноценные вычислительные субъекты со своим жизненным циклом, состоянием и зоной ответственности.
Аналитики отмечают, что подобный подход может стать стандартом де-факто для корпоративных внедрений agentic AI, где вопросы комплаенса и безопасности стоят особенно остро. Банки, медицинские организации и госсектор получают инструмент, который позволяет экспериментировать с автономными агентами, не рискуя периметром безопасности.
Что это значит для разработчиков
Для инженеров и архитекторов Agent Compute Engine открывает несколько практических сценариев. Во-первых, это мультиагентные системы: десятки специализированных агентов могут работать параллельно, обмениваясь сообщениями через защищённые каналы. Во-вторых, это агенты-инструменты, которые выполняют код, работают с базами данных или управляют инфраструктурой — и всё это в изолированной среде.
В-третьих, ACE упрощает отладку. Разработчик может «зайти» в микро-VM агента, посмотреть логи, воспроизвести шаги и понять, где именно модель ошиблась. Это радикально отличается от традиционных чёрных ящиков, где поведение агента остаётся загадкой.
Ограничения и открытые вопросы
Несмотря на амбициозность, у технологии есть свои вызовы. Микро-VM потребляют больше ресурсов, чем контейнеры, и при массовом параллельном запуске это может сказаться на стоимости. Google пока не раскрывает точных тарифов, но обещает «прозрачную модель оплаты по факту использования».
Кроме того, остаётся вопрос совместимости: не все библиотеки и фреймворки для агентов оптимизированы под работу в столь изолированных средах. Разработчикам придётся адаптировать свои пайплайны, особенно если они привыкли к общей памяти и быстрым локальным вызовам.
Вывод
Запуск Agent Compute Engine — это шаг, который может определить облик корпоративного ИИ на ближайшие годы. Выделяя каждому агенту отдельную микро-VM, Google решает сразу несколько задач: безопасность, управляемость, масштабируемость и удобство отладки. Для одних это станет стимулом перейти на agentic-архитектуры, для других — поводом пересмотреть собственные инфраструктурные стратегии. Одно очевидно: эпоха, когда ИИ-агенты ютились в общих контейнерах, подходит к концу, а на смену ей приходит новая модель вычислений, где у каждого автономного агента есть собственный дом.
