Пользователь перебил голосового агента, но старый поиск всё равно ответил
Голосовой агент начал говорить: «Ваш заказ 128 будет доставлен…». Пользователь перебивает: «Стоп, я спрашивал про заказ 182». Звук старого ответа останавливается, но поиск по 128 уже выполняется. Когда он заканчивается, агент озвучивает старый статус после нового вопроса. Выглядит так, будто бот не услышал исправление, хотя распознавание сработало. Проблема в жизненном цикле tool call, который пережил прерванный ход диалога.
У перебивания два последствия
Первое — остановить вывод TTS и убрать из истории ту часть ответа, которую пользователь не услышал. Иначе следующая реплика модели может ссылаться на фразу, которая не прозвучала. Фреймворки голосовых агентов, например LiveKit, предоставляют interrupt и обрезку истории услышанной речи. Второе — пометить все асинхронные результаты старого хода как устаревшие. Остановка аудио сама по себе не отменяет HTTP-запрос к CRM и не запрещает позднему ответу попасть в новый ход.
Создавайте для каждого пользовательского хода turn_id и монотонное поколение сессии. При запуске lookup_order(128) сохраните поколение вместе с вызовом. На barge-in увеличьте поколение и, если клиент позволяет, отмените запрос. Когда tool завершится, сравните его поколение с текущим. Старый результат можно записать в технический журнал, но нельзя передавать модели как актуальный ответ и нельзя озвучивать. Для действия с побочным эффектом вроде изменения доставки одного игнорирования результата недостаточно: его нужно заранее защищать подтверждением и идемпотентным контрактом.
Проверка на контролируемой задержке
Задержите ответ CRM по заказу 128 на две секунды. Через полсекунды после начала реплики перебейте агента и попросите заказ 182. Новый поиск пусть вернётся быстро. Ожидаемый голосовой ответ относится только к 182; запоздалый результат 128 отмечен как discarded. Проверьте и транскрипт следующего хода: там не должно быть текста старого ответа, который не был услышан. Без такой проверки агент может молчать правильно, но в следующем предложении продолжить старую мысль.
Время барж-ина важно измерять отдельно от задержки LLM. Зафиксируйте момент начала речи пользователя, момент остановки TTS и момент первого звука нового ответа. Если пользователь вынужден говорить поверх бота ещё секунду, проблема в детекторе хода или аудиобуфере. Если звук остановился мгновенно, но ответ неправильный, ищите устаревший tool result и историю диалога. Эти два дефекта выглядят похожими в жалобе «бот меня не слушает», но чинятся в разных местах.
В платном курсе Voice AI Agents PRO вы связываете STT, LLM и TTS, используете function calling для CRM и измеряете задержку звонка. Сценарий с перебиванием проверяет все три части сразу: что слышит пользователь, какой запрос выполняется и какой результат попадает в следующий ход. Откройте программу курса, чтобы собрать управляемый голосовой агент.
Продолжить на практике
- Voice AI Agents PRO ↗
Практический PRO-курс по созданию production-ready голосовых AI-агентов для бизнеса в РФ. Оба подхода 2026 года: классический cascade pipeline STT → LLM → TTS и realtime speech-to-speech на GPT-Realtime-2. VAD, end-of-turn detection, barge-in, tool calling в звонке, Voice RAG, evals, версионирование агента. Российский стек: Yandex SpeechKit, SaluteSpeech, YandexGPT, 152-ФЗ. Телефония: SIP, Voximplant, Mango Office.
