Голосовой ИИ-агент врал клиентам и путал звонящих — разработчик нашёл причину не в промпте

Разработчик голосового ИИ-агента для бизнеса провёл три месяца в боевых условиях — и задокументировал все грабли: агент врал, путался в клиентах и подделывал голос совсем не так, как было задумано.

Три главных провала агента

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

• Агент называл нового клиента по имени предыдущего звонящего * Помнил детали чужого заказа и предлагал «продолжить оформление»
• Подтверждал несуществующие договорённости из прошлых сессий * Извинялся за «задержку», которой не было — перепутав текущий звонок с предыдущим Третий случай — самый долгий по времени обнаружения. Целый месяц агент выдавал обычный TTS-синтез, представляясь клиентам как «клонированный голос». Клонирование не подключилось из-за ошибки конфигурации, но нигде не выбросило исключение — просто тихо деградировало до стандартного синтеза.

Почему промпт не лечит

Первая интуитивная реакция — дописать в промпт «не придумывай имена», «не помни предыдущих звонящих», «всегда уточняй, есть ли голосовой профиль». Автор попробовал — и объясняет, почему это не работает системно. Языковая модель не разграничивает запрет из промпта и данные из контекста сессии. Если история прошлого звонка физически попадает в контекстное окно — модель её использует. Нельзя инструкцией запретить то, что уже находится в памяти.

«Промпт — это рекомендация, а не архитектурный барьер.

Барьер должен быть в коде.» Решение — изолировать состояние на уровне инфраструктуры: жёсткий сброс контекста между звонками, проверка наличия голосового профиля до начала звонка (не в процессе), явная валидация каждого факта перед озвучиванием.

Российский стек и его особенности

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

Именно поэтому ошибка с клонированием голоса оставалась невидимой: провайдер при отсутствии голосового профиля не возвращал ошибку — он тихо отдавал стандартный синтез с кодом 200. Обнаружить подмену можно было только анализом выходного аудио или явной проверкой метаданных ответа. Практические выводы из трёхмесячного опыта: Проверяй наличие всех ресурсов (голос, профиль, сессия) до старта операции — не в процессе Логируй не только ошибки, но и «успешные» ответы: тихая деградация опаснее явного краша Изолируй состояние агента между сеансами на уровне кода, а не промпта Тестируй аудиовыход, а не только текстовый лог — синтез и клон звучат по-разному ## Что это значит Голосовые ИИ-агенты в продакшене ломаются иначе, чем чат-боты: ошибки звучат вслух, клиент слышит их в реальном времени и не может перечитать или проигнорировать.

Это делает архитектурную аккуратность критичной. Большинство «странного поведения» голосового агента — не галлюцинации модели, а архитектурные дыры в коде вокруг неё. Починить это можно.

Но не промптом.