Как вы обрабатываете ошибки агента (action не сработал, API вернул ошибку)?

Краткий тезис

Обработка ошибок в AI-агенте — это не просто try‑catch, а целая стратегия graceful fallback (плавного отказа). Нужно передать агенту информацию о сбое, дать 1–2 retry (повтора), предусмотреть альтернативное действие (например, спросить пользователя) и, если ничего не помогло, эскалировать (передать человеку). Никогда не падаем молча: агент должен корректно сообщить пользователю о проблеме.

1. Термины: действие агента, API‑ошибка, graceful fallback

• Action (действие агента) — вызов инструмента (интеграции, API, функции), который агент может инициировать для получения данных или выполнения операции. Например: поиск в базе знаний, вызов внешнего REST API, отправка email.
• API‑ошибка — ответ от внешнего сервиса с кодом ошибки (4xx/5xx), таймаут или сетевая недоступность. В контексте агента это означает, что инструмент не отработал штатно.
• model|Graceful fallback — стратегия, при которой в случае сбоя агент не прекращает работу, а плавно переключается на запасной вариант: повтор попытки, использование другого инструмента, запрос подтверждения у пользователя или эскалация.

2. Наблюдение ошибки (Observation of Error)

Агент должен осознать, что инструмент не сработал. Для этого в system prompt или в логику выполнения закладывается правило:

• Если вызванный инструмент возвращает поле error, status_code не 200, или возникает исключение — эта информация передаётся агенту как observation.
• Агент анализирует ошибку и решает: повторить, использовать другой инструмент или сообщить пользователю.

Пример наблюдения

User: "Какая погода в Москве?"
Agent (plan): Use weather_api('Moscow')
Observation: {"error": "API rate limit exceeded", "retry_after": 60}

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

3. Retry (повтор)

Первый и самый очевидный шаг — повторить вызов. Рекомендуется 1–2 попытки, иначе пользователь будет ждать слишком долго.

• Идиопатический retry — просто повтор с той же конфигурацией (подходит для временных сбоев).
• Экспоненциальная задержка (exponential backoff) — увеличиваем паузу между попытками (0.5s → 1s → 2s) для снижения нагрузки на API.
• Агент решает сам — более гибко: если ошибка "rate limit", подождать и повторить позже; если "not found" — сразу перейти к fallback.

Пример кода (Python, упрощённый агент):

import time
import requests

def call_with_retry(url, max_retries=2, backoff=0.5):
    for attempt in range(max_retries + 1):
        try:
            response = requests.get(url, timeout=5)
            if response.status_code == 200:
                return response.json()
            error = f"HTTP {response.status_code}"
        except requests.exceptions.Timeout:
            error = "timeout"
        except requests.exceptions.ConnectionError:
            error = "connection error"

        if attempt < max_retries:
            time.sleep(backoff * (2 ** attempt))  # exponential backoff
            continue
        return {"error": error}

4. Альтернативное действие (Fallback)

Если retry не помог, агент должен переключиться на запасной сценарий. Возможные варианты:

Пример из практики: если action — это вызов LLM через API, и он вернул ошибку, можно попробовать другую модель (провайдера) или снизить контекст.

Важно альтернативное действие должно быть определено на этапе проектирования агента (в plan или system prompt).

5. Эскалация (Escalation to human)

Когда все fallback исчерпаны, агент должен передать управление человеку. Это может быть:

• Создание тикета в системе поддержки (Jira, Zendesk).
• Отправка сообщения в Slack/Telegram чат оператору.
• Возврат ответа пользователю: "Извините, произошла ошибка, мы уже передали проблему инженерам".

Пример system prompt для агента:

Если инструмент вернул ошибку после двух попыток, сообщи пользователю:
"К сожалению, сервис временно недоступен. Я передал задачу на ручную обработку. Ожидайте ответа от support."

Эскалация — это крайняя мера, но она обязательна, чтобы пользователь не остался в неведении.

6. Пример промпта с обработкой ошибок

Ты — ассистент, у тебя есть инструменты: search_web, call_api. 
Правила обработки ошибок:
1. Если инструмент вернул ошибку (поле "error"), попробуй повторить один раз через 1 секунду.
2. Если повтор не помог, используй другой инструмент (например, вместо search_web используй call_api с поисковым эндпоинтом).
3. Если все инструменты недоступны, скажи пользователю: "Не удалось выполнить запрос, попробуйте позже".
4. Никогда не выдавай пользователю сырую ошибку — пиши человеческим языком.

Реализация в коде агента (на примере LangChain / OpenAI Functions):

def execute_action(action_name, params):
    if action_name == "search_web":
        result = search_web_api(params)
        if "error" in result:
            # retry once
            time.sleep(1)
            result = search_web_api(params)
            if "error" in result:
                # fallback to different action
                return execute_action("call_api", {"endpoint": "fallback_search", ...})
        return result
    # ...

7. Мониторинг и логирование ошибок

Обработка ошибок не заканчивается на пользователе. Важно логировать каждый сбой для анализа:

• Тип ошибки (таймаут, 4xx, 5xx).
• Количество retry.
• Какой fallback сработал (или не сработал).
• Время восстановления.

Логи можно отправлять в ELK, Datadog или Prometheus. Это позволяет выявлять слабые места и улучшать устойчивость агента.

8. Практические рекомендации

• Не используй бесконечные retry — фиксируй максимум попыток (2–3).
• Всегда явно пиши в промпт агенту, как обрабатывать ошибки (иначе он может "замолчать").
• Тренируй агента на историях с ошибками — добавь в train‑data примеры, где инструмент возвращает ошибку, и агент корректно переключается.
• Используй паттерн Circuit Breaker — если API падает слишком часто, временно отключай его для агента и сообщай пользователю о недоступности.

Пет-проект для закрепления

Задача: Создать Telegram‑бота (агента) с одним инструментом — получение курса валют от внешнего API. Реализовать:

• При ошибке API (например, таймаут) — повтор 1 раз.
• Если повтор не удался — бот должен ответить: "Сервис временно не работает, попробуйте позже".
• Логировать ошибки в файл.

Инструменты: Python, python‑telegram‑bot, requests, time.

Шаги:

1. Написать функцию get_currency_rate() с retry и fallback‑сообщением.
2. В обработчике команды /rate вызвать эту функцию.
3. Если ошибка — отправить пользователю человекочитаемое сообщение.
4. Добавить запись логов в errors.log.

Ожидаемый результат: Бот стабильно отвечает, даже если внешний API падает, не зависая и не выдавая технических деталей.

Связь с другими вопросами

Навигация

• Предыдущий: 59
• Следующий: 61
• Индекс: 00. Индекс разборов