Agent Runtime
Crawbl Agent Runtime — это Go-бинарник, который обеспечивает работу AI-роя каждого пользователя.
Это та часть платформы, которая реально выполняет агентную работу для конкретного пользователя. Оркестратор решает, что должно произойти вокруг него, а Agent Runtime выполняет LLM-вызовы, инструменты и память для агентов этого пользователя.
Это бинарник на Go весом ~26 МБ в distroless-образе, собранный на Google Agent Development Kit (ADK) for Go. Каждый экземпляр работает как gRPC-сервер внутри Kubernetes pod и обслуживает полный мульти-агентный рой одного пользователя.
Что это такое
Agent Runtime — это специализированный Go-бинарник, который:
- Работает как gRPC-сервер на порту 42618 внутри per-workspace pod
- Построен на Google ADK-Go, использует граф агентов ADK и модель делегирования SubAgent
- Запускается с блюпринтом, загружаемым от оркестратора, который определяет граф агентов для этого воркспейса
- Обрабатывает двунаправленный стриминг с оркестратором для многоходовых разговоров с агентами
- Корректно завершает незаконченные стримы при остановке
Каждый pod содержит базового агента Manager пользователя плюс специализированных делегат-агентов — всё в одном лёгком бинарнике.
Мульти-агентная архитектура
Runtime запускает мульти-агентный граф на основе модели делегирования SubAgent из ADK. Оркестратор направляет сообщение в runtime; Manager решает, какой агент должен его обработать.
Manager
В каждом runtime есть корневой агент Manager. Это LLM-маршрутизатор на вершине графа агентов.
Manager:
- Обрабатывает путь по умолчанию, когда конкретный агент не указан
- Направляет работу специализированным агентам через делегирование SubAgent в ADK
- Поддерживает контекст разговора верхнего уровня для воркспейса
Wally
Wally — специализированный агент для исследований и работы с вебом. Он обрабатывает задачи, требующие получения информации из интернета, поиска в вебе и синтеза внешнего контента.
Eve
Eve — специализированный агент по расписанию и календарям. Он обрабатывает задачи, связанные со временем, управлением событиями и координацией на основе календаря.
Конфигурация на основе блюпринта
Граф агентов не захардкожен. При запуске runtime загружает блюпринт от оркестратора, который определяет:
- Какие агенты существуют в этом воркспейсе
- Системный промпт и возможности каждого агента
- Доступ к инструментам на каждого агента
- Назначения LLM-моделей
Это означает, что оркестратор может обновить конфигурацию агента без перезапуска pod.
Система инструментов
Runtime предоставляет агентам два типа инструментов.
Локальные инструменты
Работают полностью внутри pod, без внешних API-ключей:
| Инструмент | Что делает |
|---|---|
web_search | Ищет в вебе через поискового провайдера |
web_fetch | Загружает URL и преобразует HTML в читаемый текст |
memory_store | Сохраняет именованную запись в памяти пользователя |
memory_recall | Извлекает сохранённые записи из памяти |
memory_forget | Удаляет запись из памяти |
MCP-инструменты оркестратора
Оркестратор встраивает MCP-сервер (Model Context Protocol). Agent Runtime подключается как MCP-клиент, чтобы получить доступ к возможностям платформы без хранения учётных данных.
Если MCP — новое понятие: это контракт, через который runtime запрашивает у backend платформенные возможности.
| Инструмент | Описание |
|---|---|
send_push_notification | Отправить пуш-уведомление на телефон пользователя |
get_user_profile | Получить имя, email и настройки пользователя |
get_workspace_info | Детали воркспейса и список агентов |
list_conversations | Все переписки в воркспейсе |
search_past_messages | Поиск по ключевым словам в переписке |
Каждый MCP-вызов аутентифицирован с помощью scoped HMAC-токена, привязанного к вызывающему пользователю и воркспейсу. Каждый вызов записывается в audit log.
Взаимодействие с оркестратором
Runtime общается с оркестратором по gRPC bidirectional streaming. Публичного эндпоинта нет — runtime доступен только через кластерную сеть через ClusterIP-сервис.
Оркестратор вызывает gRPC-сервис runtime на порту 42618. Стрим передаёт:
- Входящие сообщения пользователя
- Ответы агентов и частичные токены исходящие
- Запросы на вызов инструментов и результаты — внутри стрима
Аутентификация: gRPC-метаданные содержат HMAC Bearer-токен, привязанный к пользователю и воркспейсу, который runtime проверяет при каждом вызове.
Хранилище
| Хранилище | Назначение |
|---|---|
| PostgreSQL | Постоянная память агентов, сохраняемая и извлекаемая через memory_store / memory_recall |
| Redis | Состояние сессии для текущих переписок |
| DigitalOcean Spaces | Хранение файлов воркспейса (опционально, настраивается при провизионировании) |
Конфигурация
Runtime настраивается через CLI-флаги и переменные окружения, которые вводятся при запуске pod:
| Параметр | Что контролирует |
|---|---|
workspace_id | Определяет, какой воркспейс обслуживает этот pod |
user_id | Пользователь, которому принадлежит этот runtime |
grpc_listen | Адрес для прослушивания gRPC (по умолчанию :42618) |
mcp_endpoint | URL MCP-сервера оркестратора |
openai_api_key | Ключ LLM-провайдера (вводится через Kubernetes Secret) |
LLM-модель по умолчанию — gpt-4o-mini через OpenAI-совместимый адаптер. Блюпринт, загружаемый при запуске, может переопределить модель для каждого агента.
Деплой
Каждый воркспейс пользователя получает один Agent Runtime pod в общем namespace userswarms. Namespace на пользователя нет — изоляция обеспечивается медиацией backend и лимитами ресурсов на уровне pod, а не разделением namespace.
| Свойство | Значение |
|---|---|
| Образ | Distroless Go-бинарник, ~26 МБ |
| Namespace | Общий namespace userswarms |
| Сеть | ClusterIP-сервис на pod; без публичного доступа |
| Жизненный цикл | Управляется Kubernetes-оператором UserSwarm |
Жизненный цикл pod контролируется кастомным ресурсом UserSwarm. Оператор создаёт StatefulSet, сервисы, хранилище и конфигурацию для каждого воркспейса. Подробнее о машине состояний — в разделе Жизненный цикл UserSwarm.
Почему Go для Agent Runtime?
- Плотность: ~26 МБ distroless-образ; сотни pod умещаются в скромном кластере
- ADK-Go: Google Agent Development Kit предоставляет мульти-агентный граф и модель делегирования SubAgent
- gRPC: двунаправленный стриминг между оркестратором и runtime с сильной типизацией
- Простота: один бинарник, быстрый старт, никакого интерпретатора или overhead от VM
Слой runtime в стеке платформы
Agent Runtime находится в data plane платформы Crawbl вместе с:
| Компонент | Технология | Назначение |
|---|---|---|
| Agent Runtime | Crawbl Agent Runtime (Go + ADK-Go) | Мульти-агентное выполнение, gRPC-сервер на порту 42618 |
| Изоляция | Общий runtime namespace, per-swarm ClusterIP-сервисы | Границы безопасности на уровне pod через backend-медиацию |
| Масштабирование | HPA | Горизонтальное автомасштабирование pod по нагрузке |
| Хранилище | Persistent volumes | Состояние runtime и персистентность воркспейса |
Доставка секретов
Учётные данные провайдеров, например OPENAI_API_KEY, проходят через безопасный пайплайн:
Сохранить секрет внешне
Учётные данные провайдеров хранятся во внешнем менеджере секретов, отдельно от кластера.
Синхронизировать в Kubernetes
External Secrets Operator (ESO) автоматически синхронизирует секреты из внешнего хранилища в Kubernetes Secrets.
Доставить в pod
Оператор UserSwarm подключает секрет к pod как переменные окружения через envSecretRef.
Прочитать при запуске
Runtime читает переменную окружения при старте.
Секрет ни в какой момент не попадает в Git, ConfigMap или образ контейнера.
Пайплайн сборки образа
Сборка бинарника
Agent Runtime собирается из того же backend-репозитория, что и оркестратор, но использует отдельный distroless Dockerfile, создавая образ ~26 МБ.
Публикация в реестр
Собранный образ публикуется в реестр контейнеров платформы по адресу registry.digitalocean.com/crawbl/.
Обновление GitOps-репозитория
Инструмент деплоя обновляет тег образа в репозитории ArgoCD apps.
ArgoCD выкатывает изменения
ArgoCD подхватывает изменение в Git и деплоит новый образ runtime в кластер.
Что дальше
Смотри раздел Жизненный цикл UserSwarm, чтобы понять, как платформа провизионирует и управляет pod, в котором работает Agent Runtime.