GO/NO-GO для голосового AI-агента: как выпускать в прод

GO/NO-GO для голосового AI-агента — это набор проверок, который решает, можно ли пускать бота к живым клиентам после демо. 9 июля 2026 года у меня был рабочий Telegram voice gateway: в 07:24 прошёл первый полный голосовой контур, в 14:43 состоялся ручной входящий звонок, к 15:53 было 3 успешных прогона подряд. Статус остался NO GO, потому что два аккаунта упёрлись в PeerFlood, а длинный тест показал риск на стабильности.

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

Ниже разложен практический контур запуска голосового агента: какие проверки ставить до cutover, почему 3 зелёных теста не равны готовности, как разделять Telegram, WhatsApp и SIP-каналы, где нужны ручные стоп-краны и какие данные собирать, чтобы решение о релизе принимал не оптимизм, а факты.

Почему голосовой агент ломается иначе, чем чат-бот

Текстовый бот живёт в терпимом мире. Пользователь может подождать 4 секунды, перечитать ответ, отправить уточнение, а оператор может войти в переписку через 10 минут. Голосовой агент живёт в режиме секунд. Пауза в 2 секунды уже похожа на зависание, задержка в 5 секунд рушит доверие, а неправильный ответ произносится вслух и сразу звучит как ошибка компании.

У голосового контура больше движущихся частей. Есть входящий звонок, аудиокодек, распознавание речи, LLM-ответ, синтез голоса, проигрывание обратно в канал, запись обеих сторон, barge-in, обрыв связи, повторный набор и handoff человеку. В тексте можно сохранить черновик ответа и показать его оператору. В голосе агент либо говорит сейчас, либо молчит. Третьего варианта клиент не слышит.

9 июля Telegram voice gateway прошёл через несколько стадий за один день. Сначала система отвечала кусками TTS, затем через прямой поток голоса, затем через frame audio из звонка. После первого полного контура в 07:24 появился соблазн назвать это релизом. После ручного входящего теста в 14:43 соблазн стал сильнее. После 3 успешных прогонов подряд к 15:53 демо выглядело готовым. Потом появились ограничения исходящих звонков, PeerFlood на двух аккаунтах и вопрос, который никакая демка не любит: что будет на 31-м звонке.

Голосовой агент требует отдельного класса проверок, потому что пользователь не видит архитектуру. Он слышит только паузы, перебивания и уверенность голоса. Если агент ошибся в тексте, сообщение можно удалить или поправить. Если агент перебил клиента в звонке, это уже часть опыта. Поэтому GO/NO-GO должен оценивать не наличие ответа, а устойчивость всей цепочки.

GO/NO-GO матрица: из чего состоит решение о запуске

Я использую простую модель: голосовой агент получает GO только тогда, когда прошёл 5 групп проверок. Первая группа — канал связи. Вторая — качество диалога. Третья — контроль рисков. Четвёртая — наблюдаемость. Пятая — план отката. Если одна группа красная, релиз откладывается. Да, звучит скучно. Зато потом не приходится объяснять клиентам, почему бот внезапно стал философом на линии бронирования.

Канал связи проверяет, что аккаунт, номер или провайдер выдерживает рабочий сценарий. Для Telegram это лимиты аккаунта, PeerFlood, возможность принимать входящий звонок, стабильность записи, доступность тестовой пары аккаунтов. Для WhatsApp это отдельный тестовый номер, доступ к провайдеру, запрет на использование боевого номера, подтверждённая доставка, понятная цена минуты и отсутствие связи с рабочей модерацией. Для SIP это маршрутизация, caller ID, запись, webhook, failover и понятный владелец номера.

Качество диалога проверяется не вопросом «ответил ли агент». Нужны сценарии: короткий запрос, длинный запрос, перебивание, тишина, шумный фон, повторное уточнение, отказ клиента, просьба позвать человека, вопрос вне базы знаний. В голосовом тесте агент должен не только говорить, но и корректно замолчать, когда клиент перебивает. Barge-in — мелкая деталь на схеме и большая деталь в ухе клиента.

Контроль рисков отвечает за запреты. Агент не должен обещать цену без источника, принимать оплату без подтверждения, раскрывать внутренние данные, звонить по чужим номерам, использовать боевой WhatsApp для эксперимента или продолжать диалог после потери контекста. На 9 июля у меня один из главных стоп-кранов был жёстким: пока нет отдельного тестового WhatsApp-номера, никаких живых голосовых тестов в WhatsApp. Боевой Solar Property номер остался закрыт для голосовых экспериментов, потому что он связан с рабочими сервисами.

Наблюдаемость проверяет, есть ли у владельца доказательства работы. Нужны записи звонков, транскрипты, тайминги, статусы провайдеров, причина каждого NO GO, идентификатор теста, версия промпта, версия кода и короткий отчёт после прогона. Если команда не может объяснить, почему тест красный, она не управляет системой. Она смотрит на дым и спорит, пожар это или спецэффект.

План отката нужен до релиза. В голосовом агенте откат — это не «потом починим». Это конкретная команда, флаг или маршрутизация, которая возвращает входящие звонки человеку или в старый сценарий. Для Telegram это может быть отключение outbound-flow и сохранение inbound-only режима. Для WhatsApp — блок голосового маршрута до тестового номера. Для SIP — перевод звонков на обычный номер или IVR. Без отката GO не ставится.

Почему 3 успешных теста подряд не дают права на прод

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

9 июля после 3 успешных тестов появились два факта, которые сильнее демки. Первый: Telegram дважды упёрся в ограничения исходящих звонков. Второй: два разных аккаунта получили PeerFlood. Это значит, что система умеет говорить, но инфраструктурный контур ещё не доказал устойчивость. Если выпустить такого агента на клиентов, владелец получит не автоматизацию, а рулетку с приятным голосом.

Для прод-решения нужна серия тестов другого типа. Минимальный набор: 20 коротких входящих звонков, 10 длинных диалогов, 5 сценариев перебивания, 5 сценариев молчания, 3 обрыва связи, 3 возврата после ошибки, 1 ручной cutover и 1 ручной rollback. Числа можно менять под бизнес, но нельзя менять принцип: тестировать надо не то, что удобно показать, а то, что обычно ломается в пятницу вечером.

Отдельная ловушка — «среднее качество». В голосе среднее качество не спасает. Если 19 звонков прошли хорошо, а 20-й агент начал отвечать чужим контекстом, владелец запомнит 20-й. Поэтому в GO/NO-GO матрице критические ошибки считаются отдельно от обычных. Одна утечка номера, один неверный финансовый ответ, один звонок на боевой контакт без разрешения — красный статус до исправления причины.

Зелёные тесты полезны, когда они сопровождаются красными статусами. Красный статус говорит, где система знает свои границы. В моём контуре 9 июля демо было готово, а замена продакшена — нет. Это нормальный результат дня. Машина доказала, что умеет говорить. Потом доказала, что её рано выпускать без поводка. Для бизнеса второе доказательство дороже первого.

WhatsApp и Telegram: разные каналы, разные стоп-краны

Telegram удобен для быстрых экспериментов: аккаунты, звонки, боты, тестовые пары, логи, ручной входящий flow. Но Telegram имеет собственные лимиты и репутационные механики. PeerFlood не спрашивает, насколько красивая у вас архитектура. Он просто говорит, что аккаунт выглядит подозрительно. Поэтому Telegram voice gateway нельзя оценивать только по качеству ответа LLM. Нужно отдельно проверять поведение аккаунтов, частоту звонков, сценарии входящих и ограничения исходящих.

WhatsApp устроен иначе. Там главный риск — случайно тронуть боевой номер. Если номер связан с клиентскими чатами, модерацией, заявками или продажами, голосовой эксперимент на нём запрещён до отдельного тестового контура. 9 июля WhatsApp-линия получила около 50 контрольных артефактов: one pager, GO/NO-GO, intake для Telnyx, проверку провайдеров, dry run конфигурации, отчёт по стоимости, защиту от утечки номеров и контракт на отчёт владельцу. Всё это появилось до первого живого голосового теста.

Разные каналы требуют разных доказательств. Для Telegram надо доказать, что аккаунты и входящие звонки выдерживают сценарий. Для WhatsApp — что тестовый номер отделён от боевого и провайдер подтверждён. Для SIP — что маршрутизация, запись и fallback работают до клиентского трафика. Если смешать эти проверки в одну строку «voice agent ready», получится таблица для самоуспокоения. Таблицы для самоуспокоения обычно красивее отчётов об инцидентах, но пользы меньше.

Хорошая практика — держать канал в статусе отдельно от мозга агента. Мозг может быть green: корректно отвечает, держит контекст, не врёт, зовёт человека при риске. Канал может быть red: нет тестового номера, лимиты, нет записи, провайдер не подтверждён. Итоговый статус остаётся red. Владелец бизнеса покупает не мозг отдельно от провода, а результат звонка целиком.

Как выглядит наблюдаемость для голосового AI-продавца

Наблюдаемость начинается с журнала. В день голосовых тестов у меня было 143 записи в journal по 6 рабочим линиям: Telegram voice gateway, WhatsApp voice R&D, GEO SEO core, Atomi GEO, SolarBali GEO, 4bos и Elefterri GEO. Для голосового агента такая плотность записей не роскошь. Это способ потом восстановить, почему конкретный статус стал красным и что именно поменялось перед следующим тестом.

Минимальный лог звонка должен содержать 12 полей: канал, номер или аккаунт, время старта, длительность, версия кода, версия промпта, статус STT, статус LLM, статус TTS, наличие записи, результат barge-in, итоговый статус. Если звонок упал, нужна причина. Если причина неизвестна, это отдельный статус, а не пустая ячейка. Пустая ячейка — любимое место будущей аварии.

Для владельца нужен короткий отчёт, а не дамп логов. Хороший отчёт после теста отвечает на 4 вопроса: что проверяли, что прошло, что заблокировало GO, какой следующий шаг. Пример: «Telegram inbound voice: 3/3 коротких диалога прошли, barge-in работает, запись обеих сторон есть, outbound ограничен PeerFlood на 2 аккаунтах, следующий шаг — тест входящих без исходящего спама и отдельный аккаунт-пул». В таком отчёте нет драматургии, зато есть управление.

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

Отдельная часть наблюдаемости — качество конверсий. 9 июля в SEO-контуре я отдельно разделял qualified, unverified, suspect, organic и direct события. В голосовом контуре нужен такой же подход. Не каждый звонок — лид. Не каждый успешный TTS — польза. Не каждый разговор длиннее 2 минут — продажа. Система должна различать живого клиента, тест, повторный звонок, шум, проверку владельца и ошибку провайдера.

Сценарии handoff: когда агент зовёт человека

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

Handoff должен иметь явные триггеры. Первый — финансовый вопрос без источника: цена, скидка, возврат, депозит, штраф. Второй — персональные данные: паспорт, банковские реквизиты, приватные контакты. Третий — конфликт: жалоба, угрозы, негатив, спор по оплате. Четвёртый — неизвестный интент: агент не понимает цель после 2 уточнений. Пятый — технический сбой: потеря контекста, пустой STT, повтор TTS, задержка выше лимита.

Передача человеку должна быть удобной. Агент собирает имя, контакт, цель, 3 последних реплики, статус, риск и рекомендуемый следующий шаг. Менеджер не должен слушать весь звонок с нуля, чтобы понять, почему его позвали. Для Telegram это может быть сообщение в рабочий чат. Для WhatsApp — карточка в CRM или Telegram-уведомление. Для SIP — запись, транскрипт и ссылка на звонок.

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

Как оформлять протокол решения для владельца

Решение GO или NO GO должно быть коротким, но не устным. Устное решение исчезает через 30 минут, а через 3 дня команда уже спорит, кто разрешил тест на боевом номере. Протокол хранит 6 строк: дата, система, канал, итоговый статус, блокирующий риск, следующий тест. Для голосового агента этого достаточно, чтобы не превратить запуск в реконструкцию чужих воспоминаний.

Статусы лучше держать грубыми: GO, LIMITED GO, NO GO, ROLLBACK. GO означает, что канал, диалог, handoff, логи и откат проверены. LIMITED GO означает ограниченный трафик, например 10 входящих звонков или один источник заявок. NO GO означает блокер, который нельзя закрыть обещанием «посмотрим по ходу». ROLLBACK означает возврат на старый маршрут после факта, который был заранее описан как красный.

В протоколе должна быть фраза «что будет считаться аварией». Для Telegram это может быть PeerFlood, потеря записи звонка, задержка ответа выше 5 секунд, неправильный handoff или повтор чужого контекста. Для WhatsApp — любой тест на боевом номере, утечка номера, отсутствие провайдера или неизвестная стоимость минуты. Для SIP — неработающий fallback, отсутствие caller ID, потеря записи или сбой webhook.

Хороший протокол не заменяет инженерию, но убирает театр. Команда не спорит, достаточно ли красиво прозвучал агент. Она смотрит на таблицу. Владелец не выбирает между восторгом и тревогой. Он видит статус, риск и следующий шаг. Агент не получает право на прод из-за удачного ролика. Он получает право на следующий тест, если закрыл предыдущие красные строки. Вот такая канцелярия и спасает бизнес от технического энтузиазма с кредитной картой.

Для Solar OS это стало стандартом: любой голосовой контур получает не только код, но и запреты. Запрет звонить с боевого номера. Запрет продолжать диалог без контекста. Запрет считать raw-события победой. Запрет трогать клиентский канал без отдельного тестового маршрута. Автоматизация без запретов похожа на стажёра с root-доступом. Иногда он даже делает полезное. Потом однажды делает всё остальное.

Ещё одна строка протокола — владелец решения. Не команда, не чат, не абстрактный проект, а конкретный человек или агент, который имеет право поставить GO. Для теста 9 июля таким владельцем был контур Solar OS: Telegram оставался в демо-режиме, WhatsApp ждал отдельный номер, а SEO-события считались только через проверенные источники. Без владельца статуса система сама себе выдаёт разрешения, а это уже не автоматизация, а маленькая диктатура с вебхуками.

Практический чек-лист перед cutover

Перед cutover я бы не смотрел на презентацию. Я бы смотрел на 7 строк в таблице. Строка 1: канал подтверждён, тестовый номер или аккаунт отделён от боевого. Строка 2: записи звонков и транскрипты сохраняются. Строка 3: barge-in работает на коротком и длинном диалоге. Строка 4: есть лимиты стоимости и количества звонков. Строка 5: handoff человеку работает с резюме. Строка 6: rollback проверен руками. Строка 7: владелец понимает, какие статусы считаются красными.

Для первого дня после запуска нужен режим shadow или ограниченный трафик. Например, агент принимает только входящие с тестового источника, только 10% заявок или только один тип вопросов. Остальной поток идёт старым маршрутом. Через 24 часа смотрим не на настроение, а на таблицу: количество звонков, успешные завершения, handoff, ошибки STT, задержка ответа, стоимость, жалобы, ручные вмешательства. Если данные чистые, долю можно увеличить. Если данные грязные, откат не считается поражением. Это штатная кнопка.

Хороший cutover не выглядит как праздник релиза. Он выглядит как аккуратная смена маршрута с логами, лимитами и человеком на дежурстве. Владелец знает, где выключатель. Команда знает, какие события считать аварией. Агент знает, когда молчать и звать человека. Клиент слышит быстрый ответ, а не внутреннюю кухню. Вот такой скучный дизайн обычно и живёт дольше красивой демки.

У меня 9 июля голосовой контур дошёл до состояния «демо можно показывать, бизнесу замену ещё нельзя». Это не провал. Это нормальная зрелость системы, которая умеет отличать доказанный путь от рабочего продукта. В моём клубе «Solar — внутрянка» я выкладываю такие чек-листы, AGENTS.md, промпты, схемы gate-контроля и живые разборы запусков. Кому интересно, как это устроено внутри — клуб от 2 500 ₽/мес. Бери и адаптируй: https://4bos.ru/inside/

Solar OS.