Обвязка AI-агентов быстро превращается из локальной игрушки разработчика в платформенную задачу: контекст, файловая система, права, субагенты и сессии уже нельзя держать только на ноутбуке. По данным The New Stack, основатель и CEO Stacklok Крэйг Маклаки предлагает смотреть на такие системы через урок Kubernetes: монолит, завернутый в контейнер, монолитом и остается.
Повод прозвучал в очередном выпуске Road to KubeCon перед KubeCon + CloudNativeCon North America 2026, который пройдет 9-12 ноября в Солт-Лейк-Сити. Выпуск собрал несколько cloud-native тем, но центральная мысль для AI-команд довольно прикладная: если агентная инфраструктура должна обслуживать сотни сессий, переезжать между клиентами и устройствами, переживать сбои и нормально управлять доступами, ее нельзя проектировать как расширенный терминал одного инженера.
Под agent harness обычно понимают все, что окружает AI-агента: цикл выполнения, контекст, инструменты, доступ к файлам, права, вызовы субагентов, историю сессии. Пока это работает в IDE или локальной консоли, архитектурные грехи выглядят терпимо. Но стоит вынести сценарий в командную работу, CI/CD, внутреннюю платформу или продукт для клиентов, и появляются старые знакомые: состояние, изоляция, наблюдаемость, миграция сессий, контроль blast radius и вопрос, кто чинит все это в три часа ночи.
Маклаки предлагает cloud-native agent harness: распределенное приложение, в котором сам агентный цикл отделен от инфраструктуры и сервисов вокруг него. Это не спор о красивой терминологии. Разделение нужно, чтобы сессии можно было масштабировать, переносить и обслуживать без привязки к одному процессу или одной машине. В такой модели агент становится не магической сущностью в prompt box, а обычной рабочей нагрузкой с требованиями к ресурсам, политиками и жизненным циклом.
Параллель с Kubernetes здесь неприятно точная. В ранние годы контейнеризации многие команды просто клали большой монолит в контейнер и ждали, что дальше начнется cloud-native счастье. Не начиналось: оставались жесткие зависимости, единый релизный контур, тяжелое восстановление и мутная ответственность. С AI-агентами риск похожий: можно завернуть локальный harness в контейнер, добавить API и объявить платформой, но проблемы масштабирования, безопасности и эксплуатации от этого не исчезнут.
В том же выпуске The New Stack приводит пример из другой части Kubernetes-экосистемы: китайская компания Zhuoyu Technology, занимающаяся технологиями автономного вождения, использовала Koordinator, CNCF sandbox-проект для планирования микросервисных, AI- и big data-нагрузок. По опубликованному кейсу, Koordinator помог поднять распределение GPU выше 95%, а общую утилизацию GPU — выше 55%. Для команд, которые платят за ускорители не из воображаемого бюджета, это звучит куда убедительнее лозунгов про эффективность.
Этот пример важен не только для инфраструктурщиков. Он показывает, что дефолтный планировщик Kubernetes не всегда хорошо справляется с AI-нагрузками: могут появляться застрявшие GPU, неудачные запуски, низкая утилизация и проблемы с распределенными заданиями. Когда AI-агенты начинают массово вызывать инструменты, запускать код, обращаться к моделям и держать длинные сессии, планирование ресурсов становится частью продуктовой надежности, а не внутренней кухней SRE.
Для разработчиков вывод простой: обвязка AI-агентов должна проектироваться как среда выполнения, а не как набор скриптов вокруг LLM. Нужны явные границы между агентом, инструментами и инфраструктурой; понятная модель разрешений; логи и трассировка; возможность воспроизвести сессию; ограничение доступа к данным и внешним сервисам. Без этого агент будет выглядеть умным ровно до первого инцидента, после которого команда начнет искать, кто именно дал ему право переписать не тот файл или запустить не тот workflow.
Для бизнеса вопрос еще прозаичнее: локальные агенты ускоряют отдельных сотрудников, но платформенные агенты требуют операционной дисциплины. Здесь всплывают знакомые темы: владение окружениями, стоимость GPU, контроль секретов, аудит действий, поддержка нескольких клиентов и устройств. AI не отменяет DevOps, а скорее просит его вернуться в комнату и забрать маркер у маркетинга.
Похоже, следующий этап AI-инфраструктуры будет меньше про новые кнопки в IDE и больше про скучные, но дорогие слои: планировщики, политики, изоляцию, переносимость сессий и наблюдаемость. Главный открытый вопрос — кто успеет превратить обвязку AI-агентов в нормальную платформу до того, как локальные harnesses разрастутся в очередной распределенный монолит с прекрасной демо-записью и тяжелым продакшеном.