Google AX: открытая среда оркестрации AI-агентов для Kubernetes и Redis
Google AX — открытая среда исполнения для оркестрации агентных задач. Проект развивается в репозитории google/ax на GitHub и рассчитан на запуск большого числа краткоживущих задач без лишней нагрузки на управляющий контур Kubernetes.
Если совсем по-человечески: AX пытается взять на себя неприятную «кухню» эксплуатации — приём задач, очереди, согласование состояния, изолированный запуск и масштабирование. А команде оставить работу над логикой самого агента. Звучит разумно, особенно когда прототип уже перестал помещаться в один ноутбук.
Что представляет собой AX
В актуальной архитектуре AX отказался от формата единого CLI-инструмента со встроенным Python-харнессом и превратился в универсальный оркестрационный слой для агентных нагрузок. Задачи описываются декларативными манифестами, а взаимодействие с платформой строится через gRPC API.
Такой подход полезен, когда разработка AI-агентов выходит за рамки разовых сценариев: появляются очереди заданий, несколько моделей, внешние инструменты, требования к воспроизводимости и понятному жизненному циклу задач. Под такой стек нужен живой кластер: если своей инфраструктурной команды нет, мы развернём Kubernetes с мониторингом и возьмём его на сопровождение.
Ключевые компоненты архитектуры
- ax-server — предоставляет gRPC API для отправки манифестов
Task. - ax-controller — горизонтально масштабируемый контроллер-согласователь, который получает задания из Redis Streams и приводит фактическое состояние системы к желаемому.
- ax-task-runner — исполняет задачи в изолированных воркерах.
Состояние задач хранится в Redis, а не в Kubernetes CRD. Это важная деталь, не декоративная: при интенсивном потоке мелких задач уменьшается давление на etcd, и платформа потенциально может обслуживать миллионы коротких запусков. Kubernetes при этом остаётся средой развёртывания и изоляции, но не становится узким горлышком для каждого изменения статуса.
Именно здесь особенно важна продуманная архитектура агентной системы: надо заранее решить, что хранить как состояние, где держать контекст, как обрабатывать повторные попытки и что делать с задачами, которые «зависли» между вызовом инструмента и ответом модели. Магии нет. Есть аккуратная инженерия.
Манифесты и неизменяемость задач
В проекте RPC-метод UpdateTask заменён на CreateTask. После создания задача считается неизменяемой; попытка изменить уже существующий ресурс должна завершаться ошибкой FailedPrecondition.
На первый взгляд правило строгое, но в промышленной среде оно помогает избежать тихих и труднообъяснимых изменений. Вместо «подправим задачу на лету» команда получает чёткую историю: создана новая версия задания, выполнена отдельно, её результат можно проверить. Для корпоративных сценариев с аудитом это скорее плюс, чем бюрократия.
Где здесь безопасность и соответствие требованиям
Изолированные task-runner’ы — хорошая отправная точка, но сами по себе они не превращают агентную систему в безопасную. Для рабочих внедрений нужны разграничение прав, секреты вне манифестов, контроль исходящих сетевых соединений, журналирование вызовов инструментов и политика доступа к данным. Эти меры составляют основу безопасности агентов в рабочей среде.
Если агент обрабатывает персональные, финансовые или внутренние корпоративные данные, к технической схеме добавляются правила хранения данных, трассировка решений и контроль доступа. Это уже область соответствия требованиям к AI — и откладывать её «на потом» обычно выходит дороже. Увы, проверено рынком не раз.
Кому стоит присмотреться к Google AX
- Командам, которые запускают агентные процессы в Kubernetes и хотят отделить оркестрацию от прикладной логики.
- Продуктам с большим количеством коротких, параллельных AI-задач.
- Инженерам, которым нужен декларативный жизненный цикл задач и gRPC-интеграция.
- Организациям, строящим мультиагентные системы с отдельными исполнителями, очередями и изоляцией среды.
AX не заменяет проектирование промптов, инструментов, памяти агента или RAG-контура. Зато он может стать фундаментом, на котором эти части работают устойчивее — без вечного ручного «подталкивания» процессов. Перед внедрением стоит проверить зрелость API, сценарии отказа, совместимость с вашей инфраструктурой и модель угроз: репозиторий развивается быстро, а значит, детали могут меняться.
Если собственная оркестрация пока избыточна, а агент нужен уже сейчас, запустим открытого AI-агента на управляемом сервере — с изоляцией, обновлениями и резервными копиями.