Как остановить 90% бесполезных retries в ReAct-агентах: анализ архитектурной ошибки

Что ломается на самом деле? Диагностика слепого retry

Представьте типичную сцену. Ваш агент пытается вызвать внешний API для проверки погоды. API возвращает "400 Bad Request: Invalid city parameter". Что делает стандартный агент? Правильно - пробует ещё раз. И ещё. И ещё пять раз. Потому что в коде написано что-то вроде:

# Классическая (НЕПРАВИЛЬНАЯ) реализация
max_retries = 5
for attempt in range(max_retries):
    try:
        response = call_weather_api(city)
        return response
    except Exception as e:
        if attempt == max_retries - 1:
            raise
        time.sleep(2 ** attempt)  # Экспоненциальная задержка

Почему это происходит? Потому что разработчики фреймворков (да, LangChain, смотрю на тебя) реализовали retry-механизм как обёртку вокруг ВСЕХ ошибок. Не делая различия между "сервер упал" и "вы передали некорректные данные". Первое нужно ретраить. Второе - никогда.

Анатомия ошибки: почему 90% retries бесполезны

Давайте разберём реальные данные из продакшена. Мы мониторили 50+ агентов в течение месяца и классифицировали причины сбоев:

Видите проблему? 73% ошибок (валидация + авторизация) НИКОГДА не исправятся при повторной попытке с теми же параметрами. Но стандартный механизм упорно пытается. Каждый такой retry - это:

• Лишний вызов LLM (дорого)
• Лишний вызов инструмента (латентность)
• Задержка для пользователя (плохой UX)
• Зашумление логов (сложность отладки)

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

Архитектурное решение: интеллектуальный retry с классификацией ошибок

Нужно не просто уменьшить количество retries, а сделать их умными. Ошибки должны классифицироваться на:

1. Неповторяемые (non-retryable) - ошибки клиента, валидации, авторизации. Retry бесполезен.
2. Повторяемые (retryable) - серверные ошибки, таймауты, сетевые сбои. Retry имеет смысл.
3. Условно повторяемые (conditional) - требуют изменения параметров перед retry.

1 Шаг 1: Создаём классификатор ошибок

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

from enum import Enum
from typing import Optional

class ErrorType(Enum):
    NON_RETRYABLE = "non_retryable"  # 4xx ошибки, валидация
    RETRYABLE = "retryable"          # 5xx, таймауты, сетевые
    CONDITIONAL = "conditional"      # требует изменения параметров

def classify_error(error: Exception) -> ErrorType:
    """Классифицирует ошибку для определения нужен ли retry"""
    error_str = str(error).lower()
    
    # Неповторяемые ошибки
    non_retryable_keywords = [
        'invalid', 'not found', 'missing', 'required',
        'validation', 'bad request', 'unauthorized',
        'forbidden', 'not allowed', 'quota exceeded'
    ]
    
    for keyword in non_retryable_keywords:
        if keyword in error_str:
            return ErrorType.NON_RETRYABLE
    
    # Повторяемые ошибки
    retryable_keywords = [
        'timeout', 'internal server', 'gateway',
        'service unavailable', 'connection', 'network'
    ]
    
    for keyword in retryable_keywords:
        if keyword in error_str:
            return ErrorType.RETRYABLE
            
    # Для HTTP ошибок смотрим статус код
    if hasattr(error, 'status_code'):
        status = getattr(error, 'status_code')
        if 400 <= status < 500:
            return ErrorType.NON_RETRYABLE
        elif status >= 500:
            return ErrorType.RETRYABLE
    
    # По умолчанию считаем повторяемой (консервативный подход)
    return ErrorType.RETRYABLE

2 Шаг 2: Интегрируем в LangGraph (актуально на 2026)

LangGraph 0.2.3 (последняя стабильная версия на апрель 2026) позволяет перехватывать исключения прямо в узлах графа. Используем эту возможность:

from langgraph.graph import StateGraph, END
from typing import TypedDict, Annotated
from langgraph.graph.message import add_messages
import operator

class AgentState(TypedDict):
    messages: Annotated[list, add_messages]
    error_count: int
    last_error_type: Optional[ErrorType]
    should_retry: bool

def tool_node(state: AgentState) -> AgentState:
    """Узел с инструментом и интеллектуальным retry"""
    max_retries = 3
    retry_delay = 1  # секунда
    
    for attempt in range(max_retries):
        try:
            # Вызываем инструмент
            result = call_external_tool(state["messages"][-1].content)
            return {"messages": [result], "error_count": 0, "should_retry": False}
            
        except Exception as e:
            error_type = classify_error(e)
            
            if error_type == ErrorType.NON_RETRYABLE:
                # НЕ повторяем - сразу фейл
                return {
                    "messages": [f"Error: {str(e)}"],
                    "last_error_type": error_type,
                    "should_retry": False
                }
                
            elif error_type == ErrorType.RETRYABLE and attempt < max_retries - 1:
                # Повторяем с экспоненциальной задержкой
                time.sleep(retry_delay * (2 ** attempt))
                continue
                
            else:
                # Все попытки исчерпаны или conditional ошибка
                return {
                    "messages": [f"Final error: {str(e)}"],
                    "last_error_type": error_type,
                    "should_retry": False
                }
    
    return state

# Создаём граф с обработкой ошибок
graph_builder = StateGraph(AgentState)
graph_builder.add_node("tool_call", tool_node)
graph_builder.set_entry_point("tool_call")
graph_builder.add_edge("tool_call", END)

# Важно: настраиваем перехват исключений
graph = graph_builder.compile(interrupt_before=["tool_call"])

3 Шаг 3: Добавляем адаптивную логику для conditional ошибок

Самый интересный случай - conditional ошибки. Например, "Rate limit exceeded". Тут нужно не просто ждать, а адаптироваться: увеличить задержку, использовать другой endpoint, или даже сменить API ключ.

def handle_rate_limit(state: AgentState, error: Exception) -> AgentState:
    """Обработка ограничения запросов с увеличением задержки"""
    base_delay = 5  # секунд
    max_delay = 60  # не больше минуты
    
    # Анализируем, есть ли в ошибке информация о времени ожидания
    error_msg = str(error)
    if 'retry after' in error_msg.lower():
        # Пытаемся извлечь рекомендуемое время ожидания
        import re
        match = re.search(r'retry after (\d+)', error_msg.lower())
        if match:
            base_delay = int(match.group(1))
    
    # Увеличиваем задержку с каждой попыткой
    attempt = state.get("rate_limit_attempts", 0)
    delay = min(base_delay * (2 ** attempt), max_delay)
    
    time.sleep(delay)
    
    # Возвращаем обновлённое состояние
    return {
        **state,
        "rate_limit_attempts": attempt + 1,
        "last_delay": delay
    }

Мониторинг и метрики: как измерить эффект

Внедрили решение - отлично. Теперь нужно доказать, что оно работает. Вот метрики, которые нужно отслеживать:

• Retry Efficiency Ratio = (Успешные retries) / (Все retries). Цель: > 0.8
• Wasted Retry Cost - стоимость токенов и вызовов API в бесполезных retries
• Error Classification Distribution - распределение ошибок по типам
• Mean Time To Fail (MTTF) для неповторяемых ошибок - должно стремиться к 0

Настройте алерты на увеличение доли бесполезных retries. Если показатель падает ниже 80% - что-то сломалось в классификаторе.

Распространённые ошибки при реализации (и как их избежать)

Я видел десятки попыток внедрить эту архитектуру. Вот топ-5 ошибок, которые всё портят:

1. Слишком агрессивная классификация как NON_RETRYABLE. Опасно: если вы случайно пометите временную ошибку как неповторяемую, агент будет фейлиться там, где мог бы восстановиться. Решение: начинайте с консервативного подхода (всё что не уверены - RETRYABLE), итеративно уточняйте.
2. Отсутствие circuit breaker. Даже с классификацией, если один endpoint постоянно возвращает 500, не нужно пытаться 5 раз подряд. Добавьте паттерн Circuit Breaker: после N ошибок подряд, временно прекращаем запросы к этому сервису. Как в разборе инцидента с Replit.
3. Игнорирование контекста. Одна и та же ошибка "Not found" может быть как неповторяемой (неверный ID), так и conditional (ресурс ещё не создан, нужно подождать). Решение: анализировать не только текст ошибки, но и контекст вызова.
4. Жёсткие константы для задержек. Экспоненциальная backoff с фиксированными значениями - это 2010 год. В 2026 используйте адаптивный backoff на основе истории ошибок конкретного endpoint.
5. Отсутствие A/B тестирования классификатора. Не доверяйте своему коду слепо. Запустите канарейку: 5% трафика идёт через старую логику retry, 95% - через новую. Сравнивайте метрики неделю.

FAQ: ответы на частые вопросы

Главный вывод прост: retry-механизм в AI-агентах - это не просто техническая деталь, а архитектурное решение, влияющее на надёжность, стоимость и пользовательский опыт. Слепые retries ушли в 2024. В 2026 году production-ready агенты должны уметь отличать временную недоступность от фатальной ошибки. Если ваш агент всё ещё ретраит invalid API key - вы теряете деньги и время. Исправляйте архитектуру сейчас, пока пользователи не начали жаловаться на медленную работу.

Подписаться на канал