Google выложил AX - оркестратор для армии ИИ-агентов

Google выложил в открытый доступ AX - оркестратор, который запускает и держит под контролем тысячи ИИ-агентов сразу. Если Kubernetes в своё время научился управлять контейнерами, то AX делает то же самое для автономных агентов: даёт каждому песочницу, лимиты по тратам и белый список сети. Лицензия Apache-2.0, код лежит на GitHub, версия уже 0.3.0.

Звучит как штука для больших дата-центров, и отчасти так и есть. Но за этим релизом видно, куда едет вся индустрия агентов, и разобраться в нём полезно, даже если ты гоняешь одного-двух агентов на своём сервере. Ниже - что такое AX, из чего он собран и что из этого стоит забрать себе.

Зачем агенту вообще оркестратор

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

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

Вот тут и нужен слой над агентами: кто-то должен их запускать, изолировать друг от друга, ставить лимиты, поднимать после сбоя и показывать, что вообще происходит. Ровно эту роль десять лет назад для обычных программ взял на себя Kubernetes с контейнерами. AX заявляется как тот же уровень, только для ИИ-агентов.

Что такое AX простыми словами

AX намеренно сделали похожим на kubectl - командную утилиту Kubernetes. Ты описываешь задачу в текстовом манифесте, а AX её запускает: сажает в песочницу, подключает рабочее окружение, огораживает сеть и помогает держать всё это на масштабе. Разработчики прямо пишут: система рассчитана на миллиарды агентных задач в одном кластере.

Команды почти один в один как у Kubernetes:

ax apply -f task.yaml - запустить задачу из манифеста
ax get / ax describe - посмотреть список и детали
ax watch task test - следить за задачей в реальном времени
ax delete - убрать

Плюс несколько глаголов, которых у обычного kubectl нет, потому что они специфичны для агентов: suspend и resume (заморозить и разморозить агента), ssh (зайти внутрь его песочницы и посмотреть, что он там делает). Если ты хоть раз работал с Kubernetes, интерфейс будет ощущаться знакомо с первой минуты.

Четыре кирпича, из которых собран агент

Вся логика описывается через четыре типа ресурсов. Это и есть словарь, на котором ты объясняешь AX, что запускать.

Четыре ресурса AX: Task - задача в песочнице, Workspace - рабочее окружение, Gateway - белый список сети, Model - выбор модели

Task - сама задача. Запускает недоверенный код агента в изолированной песочнице с лимитами по процессору и памяти.
Workspace - рабочее окружение. Заранее подключает Git-репозитории, MCP-серверы и наборы навыков, чтобы агент стартовал не с пустого места, а сразу тёплым.
Gateway - шлюз наружу. Запирает исходящий трафик агента белым списком: ходить можно только на разрешённые адреса, всё остальное блокируется.
Model - какую модель дать платформе, с ключами из защищённого хранилища.

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

Песочница, деньги и белый список сети

Самое интересное в AX - не то, что он умеет запускать агентов, а то, как он их огораживает. Три вещи здесь стоят на первом месте.

Первое - изоляция. Каждая задача едет в отдельной песочнице с потолком по процессору и памяти. Агент не утащит соседа за собой и не съест всю машину.

Второе - деньги. Агент в цикле, который дёргает платную модель, - это открытый кран. AX даёт описать рамки заранее, а не ловить перерасход по факту в биллинге.

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

Шлюз Gateway: агент ходит только на адреса из белого списка, остальное блокируется

Фишка, которой нет у обычных фреймворков

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

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

Что под капотом: Agent Substrate

AX работает не сам по себе, а поверх другой гугловской штуки - Agent Substrate. Это нижний слой, kubernetes-родной рантайм, заточенный именно под агентов: сессии, состояние, возобновляемость и песочницы. The New Stack описал ситуацию метко: Kubernetes выиграл десятилетие контейнеров, а Agent Substrate метит на следующее - десятилетие агентов.

Причина, почему понадобился отдельный слой, техническая, но важная. Обычный Kubernetes хранит описания задач в своём хранилище (etcd), и оно не рассчитано на то, как ведут себя агенты: миллионы коротких задач, которые постоянно создаются и умирают. Поэтому в версии 0.3.0 AX переехал: состояние задач вынесли в Redis Streams, а сам оркестратор разбили на три сервиса - приёмную часть, реконсайлер и запускатель песочниц. Смысл ровно в том, чтобы держать миллионы короткоживущих задач и не задушить при этом хранилище Kubernetes.

Как попробовать и кому это вообще надо

Ставится AX одной командой Go:

go install github.com/google/ax/cmd/ax@latest

Дальше начинается честная часть. Чтобы это заработало, тебе нужен не ноутбук, а кластер Kubernetes, сборщик образов ko, доступ к реестру контейнеров, инстанс Redis и подключённый Agent Substrate. Это не «открыл вкладку и попробовал» - это инфраструктура для тех, кто уже гоняет агентов пачками и упёрся в то, что вручную ими не поуправляешь.

Стоит держать в голове и то, что версия ещё 0.x и проект молодой. В том же релизе 0.3.0 из состава выкинули часть прежних кусков - Python-обвязку, старый клиент, примеры навыков. Ранняя стадия: острые углы будут, API ещё будет меняться.

Но даже если ты никогда не поднимешь AX, вывод один. То, что Google выкатывает под открытой лицензией целый оркестратор именно для агентов, - сигнал, что агенты перестают быть игрушкой на один запуск и превращаются в нагрузку, которую надо запускать пачками и держать в узде. А песочница, лимиты по деньгам и белый список сети - это гигиена, которую стоит завести у себя задолго до того, как понадобится кластер.