Kubernetes для AI-агентов: когда постоянно работающим агентам нужен control plane

OpenClaw Enterprise развивается как open-source control plane для управления постоянно работающими AI-агентами. По информации проекта, в нём участвуют OpenAI, NVIDIA и Red Hat, а OpenAI и Red Hat уже тестируют технологию внутри собственных инфраструктур. Архитектурная идея почти дословно повторяет Kubernetes: единый control plane управляет множеством агентов, которые работают в разных средах. Сам control plane при этом разворачивается поверх Kubernetes.

Для собственника и технического директора здесь важна не конкретная система, а сигнал. У отрасли начинает оформляться отдельный инфраструктурный слой для агентов, за которым уже закрепилось название AgentOps. И появляется он ровно по тому сценарию, по которому в своё время появились оркестраторы контейнеров.

Сюжет, который повторяется третий раз

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

Потом количество переходит в качество. Самоделка перестаёт держать нагрузку, её перестаёт понимать кто-либо кроме автора, и появляется слой оркестрации, который забирает себе жизненный цикл, расписание, доступы и наблюдаемость. То, что было личной практикой одного инженера, становится инфраструктурой компании. Так было с виртуализацией. Так было с контейнерами: про момент, когда оркестрация контейнеров стала операционной нормой, я писал в заметке про Kubernetes 1.0. Так было с данными, где ручной cron превратился в планировщики пайплайнов. Сейчас тот же сюжет идёт с агентами, и скорость у него выше: инженерные паттерны уже известны и их берут готовыми из мира Kubernetes.

Что на самом деле закрывает этот слой

На control plane для агентов полезно смотреть как на список задач, которые кто-то всё равно решает. Вопрос только в том, решает их человек руками или система.

• Жизненный цикл и расписание. Когда агент запускается, как долго живёт, что происходит при падении, сколько экземпляров работает одновременно. У постоянно работающего агента это уже не разовый запуск, а состояние, за которым надо следить.
• Выдача и отзыв доступов. Агент ходит в почту, в CRM, в репозиторий, в платёжный шлюз. Пока агентов три, ключи лежат в переменных окружения, и это нормально. Когда их сорок, вопрос "кто и к чему имеет доступ сегодня" становится вопросом безопасности, а отзыв доступа у одного агента должен занимать минуту, а не вечер.
• Лимиты на расход. Агент, который работает постоянно, тратит токены постоянно. Цикл с ошибкой, гоняющий модель по кругу, обнаруживается по счёту в конце месяца, если жёсткий потолок не стоит в системе. Как ставить токенные бюджеты, я разбирал в заметке про контроль затрат на LLM.
• Изоляция. Что агенту видно, куда он может писать, что произойдёт с остальными, если один сойдёт с ума. Ровно тот вопрос, ради которого в контейнерном мире появились namespace и квоты.
• Наблюдаемость. Что агент сделал, почему он так решил, где он встал. Логи одного агента читает его автор. Журнал сорока агентов нужен в одном месте, иначе разбор инцидента превращается в археологию.
• Единая кнопка остановки. Самый недооценённый пункт. Когда что-то пошло не так, нужно одно место, где всё останавливается, и один человек, который знает, где это место.

Это те же задачи, которые оркестратор контейнеров закрывает для процессов, а планировщик - для пайплайнов данных. Разница в том, что агент принимает решения и действует во внешних системах, поэтому цена сбоя у него выше, чем у упавшего воркера.

Кому рано, а кому уже пора

Рано тем, у кого два скрипта по расписанию. Cron, очередь задач и внятное логирование закрывают такой объём полностью, причём дешевле и понятнее для команды. Платформа здесь добавит слой, который придётся кому-то обслуживать, и заберёт время, которое пока разумнее потратить на то, чтобы агенты приносили пользу.

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

• Счёт идёт на десятки. Агентов больше, чем людей, которые их помнят. Пока весь список держится в голове одного инженера, отдельный слой ещё не нужен.
• Появился дежурный по агентам. Кто-то регулярно тратит часы на перезапуски, разбор падений и выдачу доступов. Это уже эксплуатация, просто ручная.
• Отзыв доступа занимает больше часа. Если на вопрос "у какого агента есть ключ от продовой базы" нет ответа за минуту, управление доступами уже сломано.
• Расход непредсказуем. Счёт за инференс скачет, и объяснить скачок постфактум получается не всегда.
• Разбор инцидента идёт дольше самого инцидента. Логи лежат в разных местах, решение агента восстанавливается по косвенным признакам.
• Агенты пересекаются по данным и правам. Два агента ходят в одну систему с разными намерениями, и границы между ними держатся на устной договорённости людей.

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

Типичная ошибка: платформа раньше нагрузки

Самый дорогой способ потратить год - поставить платформу оркестрации до того, как появилась нагрузка, которую нужно оркестрировать.

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

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

С чего начинать, если признаки совпали

1. Составьте реестр агентов. Что это, чей, что делает, к чему имеет доступ, сколько тратит. Одна таблица, один день работы. Она регулярно вскрывает половину проблем ещё до всякой платформы.
2. Закройте доступы раньше оркестрации. Выдача ключей через хранилище секретов, короткий срок жизни, возможность отозвать одним действием. Эта ценность остаётся с вами независимо от того, появится платформа или нет.
3. Поставьте лимиты расхода на каждого агента. Жёсткий потолок по токенам и вызовам, который останавливает агента, а не присылает предупреждение.
4. Сведите журналы в одно место. По журналу видна реальная картина запусков, падений и расхода вместо ощущений, и она же показывает, пора ли вам оркестрация.
5. Сделайте одну кнопку остановки. Даже если это скрипт, который гасит всё разом, он должен существовать и быть проверен до того, как понадобится.
6. Платформу выбирайте последней. Когда первые пять шагов сделаны, у вас на руках реальные требования, и выбор перестаёт быть ставкой на моду.

Честные оговорки

• Про конкретный проект я сознательно говорю мало. Известно, что он развивается как open-source control plane, что в нём участвуют OpenAI, NVIDIA и Red Hat и что две из этих компаний тестируют его внутри себя. Делать отсюда выводы о зрелости, функциональности или готовности к вашему контуру рано. Здесь важнее категория решений, чем конкретное название.
• Категория молодая. Слой, которому год от роду, меняет интерфейсы и модель развёртывания быстрее, чем компания успевает встроить его в процессы. Если ставите сейчас, закладывайте стоимость переезда и держите своих агентов слабо связанными с платформой.
• Оркестрация не чинит плохого агента. Агент, который принимает неверные решения, под control plane будет принимать их регулярнее и в большем объёме. Платформа решает задачу эксплуатации, а качество самого решения остаётся на вас. Про разрыв между работающим демо и системой, которой можно доверить продакшн, есть отдельная заметка: из демо в платформу.
• Свой control plane тоже слой. Соблазн написать его самому велик и обычно заканчивается тем, что команда поддерживает платформу вместо того, чтобы ею пользоваться. Если задачи типовые, типовое решение выходит дешевле.

Если коротко

• OpenClaw Enterprise развивается как open-source control plane для постоянно работающих AI-агентов, в проекте участвуют OpenAI, NVIDIA и Red Hat; архитектурно он повторяет Kubernetes и разворачивается поверх него.
• Значим сам факт появления слоя AgentOps: отрасль идёт тем же путём, которым до неё прошли контейнеры и пайплайны данных.
• Слой закрывает шесть вещей: жизненный цикл, доступы, лимиты расхода, изоляцию, наблюдаемость и единую кнопку остановки. Эти задачи существуют и до платформы, просто решаются руками.
• Нужен тем, у кого десятки постоянно работающих агентов, внешние действия с последствиями и заметный расход на инференс. Двум скриптам по расписанию хватает cron.
• Частая ошибка - поставить платформу раньше нагрузки. Начинать стоит с реестра агентов, доступов, лимитов и журналов, а платформу выбирать последней.

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