Жизненный цикл UserSwarm

Каждый пользователь Crawbl получает собственный изолированный Agent Runtime.

Простыми словами, UserSwarm — это запись системы "создать приватный рой для этого пользователя". Платформа создаёт эту запись, а кластер превращает её в реальный runtime pod, хранилище и сервисы, необходимые пользователю.

Технически платформа управляет этим через Kubernetes-ресурс UserSwarm. Kubernetes-оператор наблюдает за этими ресурсами и приводит к желаемому состоянию всю runtime-среду: StatefulSet, постоянное хранилище, сервисы и конфигурацию.

Один UserSwarm становится одним Agent Runtime pod. Этот pod содержит базового агента Manager пользователя плюс любые делегат-агенты, определённые в блюпринте воркспейса.

Машина состояний

UserSwarm проходит через набор фаз, отслеживаемых в status.phase.

Эти фазы описывают, на каком этапе провизионирования находится runtime пользователя.

Click diagram to zoom

Что происходит на каждой фазе

Оператор записывает эти значения фаз в статус UserSwarm:

Step 1

Progressing

Оператор определил желаемые дочерние ресурсы и ещё сходится к ним.

На практике это обычно означает, что pod, конфигурация, хранилище, сервисы или рабочая нагрузка ещё не готовы.

Step 2

Ready

Рабочая нагрузка имеет хотя бы одну готовую реплику.

В этот момент runtime pod запущен и условие Ready истинно.

Step 3

Suspended

Runtime приостановлен: рабочая нагрузка масштабирована до нуля реплик.

Хранилище и сервисы остаются на месте, чтобы runtime можно было возобновить без потери состояния.

Step 4

Deleting

UserSwarm удаляется.

Оператор удаляет дочерние ресурсы и ждёт, пока все они не исчезнут.

Step 5

Error

Оператор не смог создать желаемое состояние runtime.

Обычная причина — загрузочная конфигурация или конфигурация Agent Runtime не смогла быть корректно сформирована.

Backend также выводит пользовательский runtime.status из фазы:

ready — когда runtime верифицирован
provisioning — для Progressing, Deleting или пустой фазы
offline — для Suspended
failed — для Error

Что создаётся

Для каждого UserSwarm оператор создаёт следующие дочерние ресурсы в общем namespace userswarms:

Step 1

ServiceAccount

Идентификатор для runtime pod.

Step 2

ConfigMap

Загрузочные файлы, монтируемые в runtime: файлы личности, файлы идентификации, руководство по инструментам и записи навыков на каждого агента, которые init-контейнер позже разворачивает в долговременное хранилище.

Step 3

PersistentVolumeClaim

Долговременное хранилище для пользовательских данных, сессий, памяти и извлечённых директорий навыков на каждого агента.

Step 4

Headless Service

Стабильная DNS-идентификация для pod рабочей нагрузки.

Step 5

ClusterIP Service

Внутренний сервис, через который оркестратор обращается к runtime.

Step 6

StatefulSet

Сам Agent Runtime pod.

Step 7

Backup Job

Опциональная резервная задача, если настроены параметры резервного копирования.

Если Kubernetes для тебя в новинку: главная идея в том, что одна высокоуровневая запись превращается в более мелкие ресурсы кластера, которые делают runtime реально работающим.

Форма нативного runtime

Важная текущая деталь: pod — это уже не просто "один generic агентный процесс".

Каждый pod UserSwarm запускает Agent Runtime с блюпринтом, загружаемым от оркестратора при старте. Этот блюпринт определяет:

корневого агента Manager и его конфигурацию
делегат-агентов (Wally, Eve и любых других, определённых для воркспейса)
доступ к инструментам и назначения LLM-моделей на каждого агента

Это означает, что один Kubernetes pod содержит полный мульти-агентный рой без необходимости оркестратору пересоздавать идентичность агентов при каждом запросе.

Очистка

Когда UserSwarm удаляется, оператор удаляет все дочерние ресурсы. Он продолжает сходиться к состоянию, пока все наблюдаемые потомки не исчезнут, затем завершает удаление.

Этот явный шаг очистки корректно останавливает runtime.

Что дальше

Смотри раздел Agent Runtime, чтобы узнать, что работает внутри agent pod.

Машина состояний​

Что происходит на каждой фазе​