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

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

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

Непродакшен-деплой — это ваш агент, работающий под другим именем: тот же образ, что и в production, в том же проекте, с теми же секретами. Их может быть несколько одновременно, и создание одного занимает одну команду.

Как ведёт себя непродакшен-деплой#

У каждого агента есть один зарезервированный деплой под названием production. Он создаётся вместе с агентом, является целью по умолчанию для всех команд и остаётся запущенным после деплоя агента. А вот те, что вы добавляете, — самое интересное.

Непродакшен-деплой запускает тот же контейнерный образ, что и production. Вы не собираете ничего отдельного. Вы указываете имя при сборке, и он появляется рядом с остальными. Он живёт в том же проекте, использует секреты агента, и вы обращаетесь к нему с помощью одного флага: --deployment <name>. Без флага вы работаете с production.

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

Последние две строки — это то, что стоит учитывать при планировании. Повторный деплой непродакшен-деплоя немедленно останавливает его активные сессии, а откат доступен только для production. Production переключается плавно и даёт активным сессиям до часа на завершение. Держите трафик, который нельзя прерывать, на production, а непродакшен-деплои используйте как место для итераций.

Один агент — один набор секретов#

Секреты принадлежат агенту, и каждый деплой этого агента их видит. Например, если ваш агент обращается к OpenAI как к внешнему провайдеру моделей, задайте OPENAI_API_KEY один раз — и production, staging и все остальные деплои будут читать одно и то же значение. Не нужно ничего копировать между местами и синхронизировать.

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

Та же идея на Node.js:

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

Работа с деплоями из CLI#

create, deploy, promote, logs и delete принимают опциональный флаг --deployment. Передайте его, чтобы нацелиться на непродакшен-деплой, не передавайте — и команда применится к production. Чтобы поднять такой деплой из того же кода, соберите и запушьте образ под именем:

Дальше используйте тот же флаг на всём жизненном цикле: смотрите логи конкретного непродакшен-деплоя, продвигайте его протестированный образ в production или удаляйте его, когда закончите. (lk agent status, versions и list не принимают этот флаг. Вместо этого они показывают все деплои в колонке.) Полная справка по командам есть в документации, но паттерн всегда один и тот же.

С одним флагом стоит быть осторожным: lk agent delete без --deployment удаляет всего агента, включая production. Всегда передавайте имя, если хотите удалить только непродакшен-деплой.

Отправка вызова на непродакшен-деплой#

Код вашего агента не меняется. LiveKit Cloud сообщает агенту, в качестве какого деплоя он работает, а остальное берёт на себя SDK.

Для этого нужен свежий SDK: livekit-agents 1.6 или новее для Python, @livekit/agents 1.7.1 или новее для Node. На старых версиях он вместо этого поднимается как production, поэтому звонки, предназначенные ему, не доходят, и он начинает принимать реальный трафик. Обновитесь перед созданием такого деплоя.

Чтобы обратиться к непродакшен-деплою, укажите deployment рядом с agent_name в любом месте, где вы диспатчите вызовы. Без него вы получите production.

Самый быстрый способ отправить на него реальный вызов — токен:

То же поле есть в dispatch API и во встроенном в токен диспатче, так что любой из уже используемых вами способов работает одинаково.

Поскольку все деплои живут в одном проекте под одним набором ключей, вы можете выразить процесс релиза как правила веток. Запустите CLI в вашем workflow и выберите цель по ветке: merge в main обновляет staging-деплой, merge в релизную ветку обновляет production:

Чтобы перед production требовался человек, поместите эту задачу за GitHub-окружение с обязательными ревьюерами. GitHub-окружение и имя деплоя независимы, так что вы можете ограничить production, не меняя процесс выката staging.

Полезно знать#

Деплои доступны на тарифе Ship и выше. Каждый тариф предоставляет определённое количество непродакшен-деплоев на агента: 2 на Ship и 5 на Scale. Деплой занимает место в лимите независимо от того, бодрствует он или спит, так что удаляйте его, чтобы освободить слот.

Вы создаёте и управляете деплоями из CLI. В дашборде вы можете выбрать деплой при диспатче через Agent Console или SIP-правило диспатча, а страница с деталями агента показывает, на каком деплое работает каждая версия. Одно ограничение, о котором стоит знать сегодня: метрики в Agent Observability отправляет только production, так что пока что для изучения непродакшен-деплоя используйте логи. Метрики по каждому деплою появятся позже.