Один пользовательский запрос к ИИ-агенту способен развернуться примерно в 20 внутренних операций. Именно этот сдвиг нагрузки становится новой проблемой для Kubernetes для ИИ-агентов: кластеру нужно обслуживать не просто приложение с предсказуемым числом запросов, а цепочку краткоживущих, зависимых друг от друга действий.
На это обращает внимание The New Stack в очередном материале цикла Road to KubeCon. Издание рассматривает тему через проект Kagent и более широкий вопрос: как Kubernetes должен меняться, когда агентная система начинает сама планировать шаги, обращаться к инструментам и запускать работу от имени одного внешнего запроса.
Для обычного веб-сервиса схема понятна: пользователь нажал кнопку, бэкенд обработал запрос, база вернула данные, сервис отдал ответ. Даже если за этим стоит несколько микросервисов, их поведение можно относительно неплохо измерить и спрогнозировать. У агентной системы внешне всё выглядит ещё проще: человек просит разобраться с инцидентом, подготовить сводку или выполнить операцию в инфраструктуре. Внутри же один запрос может превратиться в серию обращений к модели, поиск контекста, вызовы API, проверки результатов и повторные попытки.
Число около 20 здесь важно не как магическая константа, а как иллюстрация коэффициента разрастания работы. Платформа должна учитывать, что стоимость и нагрузка определяются не количеством сообщений в интерфейсе, а всей цепочкой действий за ними. Агент может остановиться после пары шагов, а может продолжить работу, если предыдущий результат оказался неполным или инструмент вернул ошибку. Для команды эксплуатации это означает, что метрики «запросов в секунду» уже недостаточно, чтобы понять реальную картину.
В такой архитектуре Kubernetes сталкивается сразу с несколькими типами задач. Нужно выделять ресурсы для компонентов, которые работают неравномерно и могут жить очень недолго. Нужно ограничивать последствия неудачного или слишком деятельного агента, чтобы одна цепочка не заняла вычислительные ресурсы кластера. Нужны наблюдаемость и трассировка: без них сложно ответить на базовый вопрос, какой именно шаг сделал ответ медленным, дорогим или небезопасным. Наконец, требуется управление доступом, поскольку агент не только генерирует текст, но и потенциально получает право вызывать инструменты.
Это меняет и разговор о платформенной инженерии. Раньше внутренней платформе часто достаточно было предложить командам шаблон деплоя, CI/CD и мониторинг. Для агентных приложений придётся описывать ещё и границы исполнения: какие инструменты доступны, сколько действий допускается в одной цепочке, где хранятся промежуточные данные, как фиксируется история решений. Иначе в кластере появится не просто новый тип ворклоада, а набор непрозрачных автоматизаций с непонятным потреблением ресурсов.
Для разработчиков практический вывод довольно приземлённый: агента нельзя оценивать только по качеству финального ответа. При проектировании нужны лимиты времени, ресурсов и числа шагов, понятные условия остановки и телеметрия для каждого обращения к внешнему инструменту. Для руководителей и владельцев продуктов вопрос ещё жёстче: полезный демо-сценарий может оказаться дорогим в эксплуатации, если его агентская логика регулярно умножает один пользовательский запрос на десятки внутренних операций.
Kubernetes для ИИ-агентов поэтому становится не отдельной функцией и не косметическим обновлением существующих практик. Речь идёт о новом профиле распределённой нагрузки: он асинхронный, ветвящийся и сильнее зависит от внешних сервисов. Не случайно тема появляется в повестке cloud-native-сообщества перед KubeCon: агентные системы быстро выходят из экспериментальных интерфейсов в инфраструктурные процессы.
Главный открытый вопрос — сможет ли Kubernetes-экосистема дать командам достаточно удобные примитивы для контроля таких цепочек, не превратив запуск агента в проект по сборке собственной платформы. Пока очевидно одно: если один запрос пользователя действительно порождает около 20 действий, то планировать мощности, доступы и наблюдаемость придётся вокруг этой внутренней работы, а не вокруг красивого окна чата.