Бум автономных агентов поставил инженеров перед инфраструктурным парадоксом. С одной стороны, агент — это сессионная программа: ей нужны локальная файловая система, сохранение контекста в памяти и песочница для исполнения кода. С другой стороны, до 95% времени агент бездействует, ожидая ответа большой языковой модели (LLM), завершения сетевого вызова или подтверждения от человека.
В классическом Kubernetes выделение постоянного пода под каждого агента приводит к огромным расходам: память и ядра процессора простаивают вхолостую. Открытый проект Agent Substrate (лицензия Apache-2.0) решает эту проблему разделением логических акторов и физических воркеров, обеспечивая мультиплексирование сотен процессов на общий пул серверов с субсекундным пробуждением.
Инфраструктурный тупик: почему не подходят стандартные поды и serverless
До появления специализированных агентных рантаймов разработчики выбирали между двумя компромиссными моделями.
Классический под в Kubernetes гарантирует надежную изоляцию, но требует статического резервирования ресурсов. При запуске тысяч независимых агентов кластер удерживает гигабайты памяти даже при отсутствии активности. Гашение неактивных подов экономит ресурсы, но вызывает «холодный старт» длительностью 10–30 секунд, разрушая интерактивность диалога.
Бессерверные функции (подобные AWS Lambda) масштабируются в ноль, но рассчитаны на вычисления без состояния (stateless). Агенту же необходим персистентный диск: он клонирует репозитории, создает файлы, держит сессии сред разработки и вызывает локальные инструменты. Синхронизировать дисковое состояние с внешним хранилищем перед каждым шагом слишком накладно.
Концепция Agent Substrate: разделение акторов и воркеров
Архитектура Agent Substrate разделяет логического «актора» (actor) и физического «воркера» (worker). Актор представляет собой виртуальную сущность агента с уникальным адресом, состоянием оперативной памяти и файловой системой. Воркер — это стандартизированный контейнер в кластере Kubernetes, готовый исполнять назначенного актора.
Когда агент завершает шаг и ждет ответа нейросети, рантайм выполняет гибернацию: снимок памяти и изменения файловой системы выгружаются в хранилище, а воркер немедленно освобождается для других задач. Как только поступает новый запрос, актор пробуждается на любом свободном узле быстрее чем за 500 миллисекунд.
В публичной демонстрации авторы показали работу ~250 stateful-акторов всего на 8 физических подах. Это соответствует коэффициенту переподписки более 30 раз при пропускной способности свыше 500 переключений состояний в секунду.
Анатомия архитектуры: модули платформы и изоляция в gVisor
Система написана на Go и работает поверх Kubernetes, принимая стандартные OCI-образы. Ключевые компоненты платформы:
- ateapi: gRPC control plane для регистрации акторов и управления их жизненным циклом.
- atelet: фоновый агент (DaemonSet) на каждом узле кластера, координирующий снимки и передачу состояния воркеров.
- atecontroller: оператор Kubernetes, согласующий манифесты (CRD)
WorkerPoolс нагрузкой. - atenet: маршрутизатор на базе Envoy, направляющий запросы по заголовку
ate-target-actor: <пространство>/<актор>и паркующий входящие соединения (Request Parking) на время пробуждения процесса. - Песочницы ateom-gvisor и ateom-microvm: контур безопасности. Для изоляции недоверенного кода используется gVisor (перехват системных вызовов через
runsc) или микро-ВМ (cloud-hypervisor), что дает надежную границу защиты ядра хоста.
Механика Actor Teleport: жизненный цикл гибернации
Ключевой механизм платформы — Actor Teleport («телепортация актора»). Цикл обработки запроса включает шесть этапов:
- Инициализация: администратор задает шаблон актора (ActorTemplate) с лимитами ресурсов и политиками изоляции.
- Исполнение: актор запускается на свободном воркере и обрабатывает задачу.
- Фиксация простоя: процесс
ateletрегистрирует паузу в сетевой и процессорной активности. - Снапшот: через механизм
runsc checkpointпамять и измененные файлы сохраняются в хранилище (GCS или RustFS), а воркер возвращается в пул. - Входящий триггер: маршрутизатор
atenetполучает пакет для усыпленного актора. - Восстановление: состояние мгновенно распаковывается на свободном воркере, и запрос доставляется процессу.
Сравнение сред исполнения для агентных нагрузок
| Критерий | Kubernetes Pods | Бессерверные функции | Agent Substrate |
|---|---|---|---|
| Плотность размещения | Низкая (1 под на агента) | Высокая | Очень высокая (переподписка >30x) |
| Задержка старта | 10–30 с (холодный старт) | 1–5 с | Менее 500 мс |
| Сохранение RAM | Оплата полного простоя | Сброс состояния | Снапшоты через gVisor |
| Локальный диск | Требует постоянных PVC | Временный каталог /tmp | Полное сохранение файловой системы |
| Изоляция ядра | Базовые namespaces | Изоляция платформы | Аппаратная / gVisor sandbox |
| Инфраструктурные затраты | Высокие из-за 90% простоя | Низкие при редких вызовах | Экономия до 5–10 раз |
Инструкция по локальному развертыванию и проверке
Для тестирования архитектуры в локальном окружении используется утилита kind (Kubernetes in Docker).
Предварительные требования:
- Установленные
docker,kubectlи компиляторgoне ниже версии 1.22. - Не менее 8 ГБ оперативной памяти на рабочей станции.
Пошаговый запуск:
- Создание кластера:
В корне склонированного репозитория создайте тестовый контур:
./hack/create-kind-cluster.sh - Развертывание системы:
Установите управляющие компоненты и маршрутизатор:
./hack/install-ate-kind.sh --deploy-ate-system - Запуск тестового актора:
Разверните демонстрационный сервис-счетчик, сохраняющий состояние между вызовами:
./hack/install-ate-kind.sh --deploy-demo-counter - Установка плагина CLI:
Скомпилируйте консольную утилиту управления:
go install ./cmd/kubectl-ate - Проброс порта маршрутизатора:
Откройте доступ к сетевому шлюзу:
kubectl port-forward -n ate-system svc/atenet-router 8000:80
Проверка результатов: Проверьте активность фонового сервиса узлов и наличие метки версии:
kubectl get ds -n ate-system -l app=atelet -L ate.dev/substrate-version
Выполните проверочный запрос к актору через заголовок ate-target-actor:
curl -X POST http://localhost:8000/increment -H "ate-target-actor: default/counter-1"
После паузы повторите вызов: счетчик продолжит расти, подтверждая восстановление памяти из снапшота.
Ограничения технологии и критерии применимости
Авторы подчеркивают, что проект находится на стадии активной разработки (early development): интерфейсы API могут меняться, обратная совместимость не гарантируется, а коммерческая поддержка со стороны Google отсутствует.
Скорость телепортации зависит от объема рабочей памяти: если агент загружает локальные веса нейросетей на десятки гигабайт, сброс снапшота займет больше времени, чем заявленные 500 мс. Кроме того, воркеры запускаются только на узлах с меткой ate.dev/substrate-version, требуя аккуратного управления пулами серверов при обновлении кластера.
Когда решение оправдано:
- Сессии помощников по написанию кода (Claude Code, Cursor, Antigravity) с долгими паузами между правками.
- Изолированные серверы инструментов Model Context Protocol (MCP).
- Агентные сценарии с подтверждением действий человеком (human-in-the-loop).
Для монолитных сервисов с непрерывной нагрузкой стандартный Kubernetes остается более простым решением, однако в агентных сценариях Agent Substrate предлагает качественно новый уровень плотности инфраструктуры.