Патерн Fallback-Recovery Agent: відновлення після збоїв

Суть патерна

Fallback-Recovery Agent - це патерн, у якому агент при помилці не просто завершується, а проходить через керований процес відновлення: класифікує збій, застосовує fallback і намагається відновити виконання.

Коли потрібен: коли важливо не падати на першій помилці, а відновлювати виконання за контрольованим сценарієм.

У реальних системах збої неминучі:

• таймаути зовнішніх API
• тимчасова недоступність інструмента
• помилки валідації відповіді
• часткові outage залежностей

Fallback-Recovery підхід перетворює "помилка = stop" на "помилка = контрольований сценарій відновлення".

Проблема

Уяви, що агент готує щоденний звіт для клієнта:

1. зчитати метрики з API
2. зібрати таблицю
3. відправити результат

На другому кроці API повертає timeout.

Без recovery-логіки workflow просто зупиняється.

Одна локальна помилка не повинна валити весь процес, якщо решта кроків працездатні.

Що ти отримуєш:

• зірваний дедлайн
• втрачений проміжний прогрес
• ручний перезапуск з нуля
• непередбачувану поведінку в проді

У цьому й проблема: без стратегії відновлення навіть одиничний збій ламає весь сценарій.

Рішення

Fallback-Recovery вводить recovery-policy для контрольованого відновлення після збоїв.

Аналогія: це як автозбереження в редакторі. Якщо програма падає, ти не починаєш усе з нуля, а продовжуєш із останнього безпечного стану. Тут працює та сама логіка, але з чіткими межами.

Ключовий принцип: Не кожну помилку треба "ламати об stop": частину помилок треба класифікувати і безпечно відновлювати.

Агент може запропонувати retry, але шар виконання вирішує:

• чи дозволений retry
• чи потрібен fallback
• чи треба escalation/stop

Керований процес:

1. Виявити: зафіксувати збій
2. Класифікувати: визначити тип помилки
3. Прийняти рішення: retry/fallback/escalation
4. Відновити: продовжити з checkpoint
5. Безпечно завершити: зупинити з прозорим stop_reason

Це дає:

• відновлення довгих процесів після тимчасових збоїв
• м'яку деградацію (cached/partial result)
• без дублювання вже успішних кроків
• прозору причину зупинки

Працює добре, якщо:

• є ліміти max_retries і max_fallbacks
• checkpoint зберігається після безпечного прогресу
• класифікація розділяє retriable/non-retriable
• high-risk кейси не відновлюються автоматично

Модель може "хотіти" робити retry нескінченно, але саме recovery-policy визначає межі безпечного відновлення.

Як працює

Критично: відновлення має мати межі.

• max_retries і max_fallbacks
• step_timeout і total_timeout
• stop_reason для кожного виходу
• заборона “fallback -> retry -> fallback” без лічильника

У коді це виглядає так

fallbacks_used = 0

for attempt in range(max_retries + 1):
    try:
        result = run_step(goal, context, timeout_sec=step_timeout)
        checkpoint.save(task_id, context, result)
        return result

    except TimeoutError as err:
        kind = "retriable"

    except ToolUnavailableError as err:
        kind = "tool_unavailable"

    except ValidationError as err:
        kind = "invalid_output"

    except Exception as err:
        kind = classify_error(err)

    if kind == "retriable" and attempt < max_retries:
        sleep(backoff(attempt))
        continue

    if kind == "tool_unavailable" and fallbacks_used < max_fallbacks:
      fallbacks_used += 1
      context.append(f"fallback_used={fallbacks_used}")
      context.append("route=secondary_tool")  # або alt_model / cached_path
      continue

    if kind == "high_risk":
        return escalate_to_human(goal, err, stop_reason="high_risk")

    return stop_with_reason(goal, stop_reason=kind, detail=str(err))

Checkpoint зберігають після успішного кроку або після безпечного часткового прогресу (idempotent state). Інакше retry може дублювати дію.

Як це виглядає під час виконання

Goal: сформувати звіт для клієнта

Step 1: зібрати метрики
- timeout у primary analytics API
- classify: retriable
- retry #1 -> fail
- retry #2 -> fail

Fallback:
- переключення на read-replica API
- успіх

Resume:
- звіт зібрано
- step завершено без повного зриву процесу

Коли підходить — і коли ні

Підходить

Не підходить

Бо патерн відновлення додає операційну складність: логіку помилок, стан і оверхед підтримки.

Чим відрізняється від Supervisor

Supervisor - це профілактика. Fallback-Recovery - це відновлення після збою.

Коли використовувати Fallback-Recovery (vs інші патерни)

Використовуйте Fallback-Recovery, коли потрібно відновити виконання після збоїв, а не зірвати весь процес.

Короткий тест:

• якщо потрібно "retry/fallback/escalation після помилки" -> Fallback-Recovery
• якщо потрібно "зупинити ризикову дію ще до виконання" -> Guarded-Policy Agent

Як комбінувати з іншими патернами

• Fallback-Recovery + ReAct: якщо збій стався в середині циклу, агент повторює лише проблемний крок і не стартує з нуля.
• Fallback-Recovery + Orchestrator: при паралельній роботі відновлюється тільки зламана гілка, а інші підзадачі продовжують виконання.
• Fallback-Recovery + Supervisor: перед відновленням перевіряються політики, щоб fallback не порушив правила безпеки.

Коротко

Переваги та Недоліки

FAQ

Q: Чи достатньо просто додати повтор?
A: Ні. Мінімальний безпечний набір: max_retries + backoff + step_timeout + stop_reason. Без цього повтори перетворюються на цикл, який спалює бюджет.

Q: Коли краще резервний сценарій, а не повтор?
A: Коли помилка системна: інструмент недоступний, quota вичерпана або кінцева точка деградувала.

Q: Навіщо checkpoint, якщо є fallback?
A: Резервний сценарій змінює шлях виконання, але контрольна точка зберігає прогрес, щоб не повторювати весь сценарій спочатку.

Що далі

Fallback-Recovery підхід додає стійкість до збоїв.

Але як зробити так, щоб небезпечні дії взагалі не запускались без policy-умов?