2 хв читання

Google AX ізолює ШІ-агентів у Kubernetes

Google AXKubernetesИИ-агенты

Google опублікувала AX, або Agent Executor, як 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-ізоляцію для агентних навантажень.