Без retry многие процессы ломаются из-за случайных ошибок. Например, ИИ-агент отправляет данные в CRM, но API на секунду отвечает 503. Если сразу завершить процесс ошибкой, заявка потеряется. Если сделать аккуратный retry, агент повторит запрос через несколько секунд и продолжит работу.
Но retry нельзя включать без правил. Повторная попытка может создать дубль: два счета, две сделки, два письма клиенту, два списания или две задачи. Поэтому для важных действий нужны retry policy, idempotency key, лимит попыток, задержка между повторами, логирование и понятный fallback, если все попытки закончились ошибкой.
В ИИ-агентах retry особенно важен при tool calling, webhooks, очередях задач, интеграциях с CRM, Telegram, email, доставкой и платежами. Агент должен понимать: какие ошибки можно повторять, какие нельзя, сколько раз повторять, как не превысить бюджет токенов и когда передать проблему человеку.
Примеры
- API CRM вернул 503 Service Unavailable. Система ждет 5 секунд и повторяет запрос, вместо того чтобы сразу терять заявку.
- Telegram webhook не смог обработаться из-за таймаута. Задача попадает в очередь и повторяется с задержкой.
- ИИ-агент вызывает внешний инструмент, но получает rate limit. Retry откладывается на время, указанное в заголовке Retry-After.
- Отправка письма клиенту упала из-за временной ошибки SMTP. Система делает несколько попыток, но не отправляет письмо дважды благодаря idempotency key.
- После трех неудачных попыток агент создает тикет для человека и прикладывает trace, чтобы проблему можно было быстро разобрать.
Где используется
- Повторять временно упавшие API-запросы без ручного вмешательства.
- Обрабатывать webhooks, даже если сервис на короткое время недоступен.
- Делать надежнее интеграции с CRM, Telegram, email, доставкой и платежами.
- Защищаться от случайных сетевых ошибок и таймаутов.
- Снижать число потерянных заявок, сообщений, заказов и событий.
- Настраивать очереди задач с лимитом попыток и задержкой.
- Передавать проблему человеку после исчерпания попыток.
- Контролировать стоимость повторных вызовов модели или инструментов.
- Логировать ошибки так, чтобы можно было понять, какая попытка и почему не прошла.
Связанные термины
Частые вопросы
Какие ошибки можно повторять?
Обычно повторяют временные ошибки: timeout, 429 rate limit, 500, 502, 503, 504, сетевой сбой. Ошибки валидации, неверный API key или запрещенное действие обычно повторять бессмысленно.
Сколько retry делать?
Часто хватает 3-5 попыток. Важно не только количество, но и задержка между ними. Для внешних API лучше учитывать Retry-After и не создавать лишнюю нагрузку.
Что такое exponential backoff?
Это стратегия, где пауза между попытками растет: например 1 секунда, 2 секунды, 4 секунды, 8 секунд. Так система не долбит перегруженный сервис одинаково часто.
Почему retry может быть опасен?
Потому что повтор может выполнить действие дважды: создать дубль сделки, отправить письмо два раза или списать деньги повторно. Для таких действий нужны idempotency key и проверка состояния.
Как retry применять в ИИ-агенте?
Для каждого инструмента нужно описать, какие ошибки повторять, лимит попыток, задержку, бюджет, журналирование и fallback. Если действие рискованное, после неудачных попыток лучше передавать его человеку.
