Google AX изолирует ИИ-агентов в Kubernetes

AX отделяет агента от кластера

Для меня главное в AX не сам Kubernetes, а попытка превратить запуск потенциально недоверенного агентного кода в отдельную инфраструктурную сущность. В официальном репозитории Google проект описан как декларативный runtime, который изолирует задачи, подключает рабочие пространства, ограничивает исходящую сеть и масштабирует агентные нагрузки на кластере.

По состоянию на сентябрь 2026 года AX, или Agent Executor, опубликован с лицензией Apache 2.0. Его основные примитивы хорошо показывают модель исполнения: Task запускает агентную задачу, Workspace дает ей файловый контекст или репозиторий, Gateway определяет доступ наружу, а Model настраивает провайдера модели и учетные данные.

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

Но AX не самодостаточен. Документация репозитория указывает среди требований Kubernetes-кластер, сборщик образов ko, доступный кластеру реестр контейнеров и Agent Substrate Control API. Значительная часть реального исполнения находится в Agent Substrate, тогда как AX отвечает за декларативное управление и оркестрацию.

Google называет AX высокопроизводительным оркестратором, рассчитанным на миллиарды автономных агентных нагрузок на кластер. Звучит громко, но в доступных материалах нет официального публичного набора воспроизводимых бенчмарков. Пока это архитектурная цель, а не цифра, на которую я бы опирался при расчете емкости.

Изоляция становится частью модели агента

AX меняет полезную вещь: безопасность агента задается не набором договоренностей внутри приложения, а отдельными объектами инфраструктуры. Сеть, рабочая область, модель и исполняемая задача получают явные границы, которые можно описывать и контролировать через Kubernetes-подобный процесс.

Больше всего от такого подхода выигрывают платформы, где одновременно работают разные агенты с недоверенным кодом или разными правами доступа. Для небольшой установки цена входа может оказаться высокой: кроме Kubernetes нужно обслуживать реестр, сборку образов и отдельный слой Agent Substrate.

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

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