Что делать при сбое AI-агента: fallback, очередь задач и ручной режим

Коротко

• Fallback — заранее заданный запасной сценарий: резервная модель, упрощённый ответ или передача человеку.
• Очередь задач — входящее событие сначала сохраняется, потом обрабатывается. Если обработка упала, задача повторяется, а не исчезает.
• Ручной режим — рубильник, который за минуту и без разработчика переводит поток на людей.
• Повторы без защиты от дублей опасны: агент дважды создаст сделку или трижды напишет клиенту.
• Без логов и алертов всё это не работает: тихий сбой хуже громкого.
• Для одного процесса базовый контур обычно собирается за 1–3 недели.

Какие сбои бывают и почему тихие опаснее

Громкий сбой виден сразу: модель не отвечает, срабатывает таймаут, API Wildberries возвращает ошибку авторизации, на балансе у провайдера ноль. Такое ловит обычный мониторинг.

Тихий сбой хуже: формально агент работает, но:

• уверенно называет клиенту старую цену или неверный срок доставки;
• создаёт сделку в CRM без телефона, потому что на сайте поменялась форма;
• зацикливается, десятки раз вызывает один инструмент и сжигает лимиты;
• пропускает сообщения, потому что после перезапуска сервера отвалился Telegram-вебхук.

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

Правило простое: исходи из того, что каждый внешний вызов однажды не сработает. Если в схеме нет ответа на вопрос «что будет, если этот шаг упадёт», ответ придёт из production.

Fallback: запасной сценарий на каждом шаге

Fallback — это лестница деградации. С каждой ступенью сервис становится проще, но не останавливается. Пример для агента поддержки интернет-магазина:

1. Основной режим. Агент отвечает по базе знаний и проверяет статус заказа в CRM.
2. Резервная модель. Основной провайдер молчит 15–20 секунд — запрос уходит другой модели с теми же инструментами.
3. Упрощённый режим. CRM недоступна. Агент отвечает на общие вопросы, а про заказ пишет честно: «Статус уточню у коллег, ответим до 12:00».
4. Шаблон и человек. Не работает ничего. Клиент получает сообщение, что вопрос принят, а тикет уходит оператору.

Fallback должен быть честным. Если у агента нет данных, он не выдумывает ответ. Сказать «уточню и вернусь» дешевле, чем потом исправлять выдуманный срок доставки.

Запасной сценарий тоже проверяют. Типичная история: резервную модель настроили полгода назад, с тех пор промпт трижды переписали, и в момент сбоя она отвечает в другом формате, на котором ломается парсер.

Очередь задач: ничего не теряется

Самая дорогая ошибка простых интеграций — обрабатывать событие прямо в момент получения. Заявка пришла, агент начал разбор, CRM упала, а заявку нигде не сохранили.

Правильный порядок: сначала записать, потом обработать. Заявка, сообщение, отзыв на WB, вебхук оплаты сначала попадают в очередь со статусом. Отдельный обработчик берёт задачи по одной:

new → processing → done
          ↓
       retry (повтор через 1, 5, 15 минут)
          ↓
       failed → ручной разбор

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

Лимит попыток. После 3–5 неудач задача получает статус failed и уходит человеку. Бесконечные повторы — та же потеря, только медленная.

Защита от дублей. У каждой задачи есть ключ идемпотентности, например ID заявки. Перед действием обработчик проверяет, не выполнено ли оно уже. Запрос мог дойти до CRM, а потеряться только ответ, и без такой проверки повтор создаст вторую сделку.

Срок жизни. Ответ на отзыв можно отправить и на следующий день. А сообщение «перезвоним через 5 минут» после ночного сбоя лучше заменить звонком менеджера.

Для малого бизнеса отдельная инфраструктура обычно не нужна: хватает таблицы со статусами в базе данных и воркера по расписанию. Брокеры вроде RabbitMQ понадобятся, когда событий будут тысячи в час.

Ручной режим: рубильник для команды

Ручной режим — это команда «агент: стоп» в админке или служебном Telegram-боте. После неё сообщения клиентов идут операторам, а очередь не обрабатывается автоматически. Агент при этом может остаться в роли помощника: готовит черновик ответа, человек его проверяет и отправляет.

Чтобы рубильник сработал в момент сбоя, договоритесь о трёх вещах заранее:

• Кто включает. Конкретные люди с правами: руководитель поддержки, дежурный менеджер.
• Где работают люди. Очередь и история диалога видны в CRM или рабочем чате, а не в серверных логах.
• Как возвращаться. После включения агент не должен разом ответить на 200 накопившихся сообщений, часть которых уже закрыли вручную. Такие задачи помечаются и пропускаются.

Ручной режим нужен не только при сбоях. Его включают на время распродажи, смены цен или спорной ситуации с крупным клиентом, то есть когда ошибка временно стоит дороже обычного.

Как это работает вместе: заявка с сайта

1. Заявка записывается в очередь с ID и временем, клиенту сразу приходит подтверждение.
2. Воркер берёт задачу, агент определяет тип запроса, бюджет и срочность.
3. Модель не ответила — повтор, затем резервная модель.
4. Обе модели недоступны — сделка создаётся без квалификации с пометкой «разобрать вручную».
5. CRM не отвечает — задача ждёт в retry. После пятой неудачи в рабочий чат приходит алерт, а контакты клиента — менеджеру в Telegram.
6. Каждый шаг пишется в лог: что пришло, что решил агент, какой инструмент вызван и с каким результатом.

В худшем случае менеджер получит заявку в Telegram вместо CRM. Это неудобно, но лид не потерян.

У селлеров на WB и Ozon всё устроено так же: ответы на отзывы, остатки, цены. Только для действий с деньгами — цен, акций, рекламных ставок — действует дополнительное правило: если неясно, выполнилось ли действие, агент не повторяет его, а останавливается и спрашивает человека.

Сколько это экономит

Условный пример: 40 заявок в день, средний чек 60 000 ₽, в сделку конвертируется 15%. Интеграция лежит 4 рабочих часа, за это время приходит около 10 заявок.

Без очереди часть из них пропадает. Если потерялась половина, это примерно 0,75 сделки, или около 45 000 ₽ выручки за один инцидент. Сверху полдня менеджера и разработчика: найти заявки в логах, написать клиентам, извиниться.

С очередью и fallback все 10 заявок дойдут до менеджеров, пусть с задержкой и без автоматической квалификации. Весь разбор инцидента сводится к просмотру задач в статусе failed.

Сравнивай стоимость надёжного контура не с вариантом «и так работает», а с ценой одного сбоя в сезон. Как оценить экономику автоматизации до старта, мы разбирали в статье как понять, что процесс пора автоматизировать.

Риски и типовые ошибки

Fallback скрывает проблему. Агент неделю отвечает шаблонами, и никто этого не замечает. Каждое переключение на запасной сценарий должно отправлять алерт.

Повтор опасного действия. Изменение цены, платёж или рассылку нельзя повторять, не проверив, выполнено ли действие. Нужны идемпотентность и подтверждение человеком.

Слишком широкие права. Если ошибка модели может удалить сделки или снять товар с продажи, проблема в правах доступа, а не в модели. Агент получает ровно те права, которые нужны для его задачи, а необратимые действия проходят через человека.

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

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

Чем production-агент отличается от демо, подробно разобрано в статье AI-агент для бизнеса.

Как внедрить: порядок работ

Начни с одного процесса, где сбой обходится дороже всего. Обычно это заявки или поддержка.

1. Карта сбоев. Выпиши шаги процесса. Для каждого ответь, что будет, если он упадёт, и кто об этом узнает.
2. Очередь. Сохраняй события до обработки, добавь статусы, повторы, лимит попыток и ключ против дублей.
3. Fallback. Резервная модель, упрощённый режим, шаблон с передачей человеку. Отключи каждую зависимость и посмотри, что произойдёт.
4. Рубильник и роли. Решите, кто может остановить агента и где в этот момент работают операторы.
5. Алерты. Ошибки, переход на fallback, рост очереди, тишина во входящем потоке — всё уходит в рабочий чат.
6. Учебный сбой. Отключи модель на 15 минут в рабочее время и проверь, что сделает команда.

Чек-лист: готов ли агент к сбою

• [ ] События сохраняются до обработки.
• [ ] У задачи есть статус, счётчик попыток и ключ идемпотентности.
• [ ] Резервная модель проверена на текущем промпте.
• [ ] Без данных агент говорит «уточню», а не выдумывает.
• [ ] Переход на fallback отправляет алерт.
• [ ] Ручной режим включается без разработчика.
• [ ] Необратимые действия подтверждает человек.
• [ ] По логам любой инцидент восстанавливается за 10 минут.

FAQ

Нужна ли резервная модель, если провайдер стабилен?

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

Чем очередь отличается от простого повтора запроса?

Простой повтор живёт в памяти процесса: сервер перезапустился, и задача пропала. Очередь хранит задачу в базе со статусом. Её можно повторить через час или после перезапуска, передать человеку, а ещё по очереди видно, сколько задач застряло.

Как не отправить клиенту одно сообщение дважды?

Нужен ключ идемпотентности: например, ID входящего сообщения плюс тип действия. Перед отправкой обработчик ищет успешную запись с таким ключом. Если она есть, повторная отправка пропускается.

Когда выключать агента вручную, не дожидаясь автоматики?

Когда агент работает, но делает что-то не то: массово отвечает неверно, странно меняет данные в CRM, клиенты жалуются. Автоматика ловит технические ошибки, а смысловые обычно первым замечает человек. Если сомневаешься, выключай: включить обратно быстрее, чем исправлять последствия.

Можно ли собрать это на no-code?

Частично. В n8n и Make есть обработка ошибок, повторы и запасные ветки. Но нормальная очередь со статусами, идемпотентность и аудит действий там быстро обрастают сложностью. Для процессов с деньгами и большим потоком обычно надёжнее небольшой кастомный сервис.

Сколько стоит сделать агента устойчивым к сбоям?

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

Что делать дальше

Сбой AI-агента нельзя исключить, но его можно сделать предсказуемым. Очередь сохраняет задачи, fallback не даёт оставить клиента без ответа, ручной режим возвращает контроль людям, а логи и алерты показывают, что произошло. Первый шаг — карта сбоев для одного процесса: выпиши шаги и честно ответь, что будет, если каждый из них откажет сегодня вечером.

Если хочешь понять, что автоматизировать у себя, напиши Дмитрию в Telegram @dmkosik или опиши процесс для диагностики Paramiko.