LangGraph научили переживать сбои: ретраи, таймауты и обработчики ошибок для продакшн-агентов

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

Почему прототипы ломаются в продакшне В лабораторных условиях

LangGraph-агент выглядит надёжным: входные данные фиксированы, внешние API отвечают быстро, пользователь всегда доступен. В реальной эксплуатации картина другая. Внешние сервисы зависают или возвращают 503 под нагрузкой. LLM-провайдеры на пике спроса откладывают ответы на минуты. В human-in-the-loop сценариях человек может не ответить часами. Каждый из этих случаев без специальной обработки превращается в зависший или упавший агент. Классическое решение — оборачивать каждый вызов в try/except, писать таймеры, добавлять retry-логику вручную. Это работает, но защитный код разрастается, перемешивается с бизнес-логикой и сам становится источником ошибок. LangGraph предлагает другой подход: три примитива, встроенных в движок и работающих декларативно.

RetryPolicy: автоматические повторные попытки **RetryPolicy**

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

TimeoutPolicy: ограничения по времени **TimeoutPolicy** решает другую

задачу — ограничивает время, которое узел имеет право занять. Поддерживаются два типа ограничений: `wall_clock_timeout` — максимальное астрономическое время выполнения узла от запуска до завершения `idle_timeout` — максимальное время бездействия. Особенно важно в human-in-the-loop сценариях: если пользователь не ответил за N минут, агент должен продолжить по альтернативной ветке или завершить работу с ошибкой Оба ограничения можно комбинировать в одной политике — сработает то, что наступит первым При превышении лимита движок автоматически поднимает исключение * Политика применима к узлу, подграфу или всему графу Ключевое преимущество обоих примитивов — они живут внутри движка и видят полный контекст состояния графа. Внешние декораторы и обёртки на это неспособны.

error_handler и паттерн SAGA **error_handler** — третий примитив,

который срабатывает после того, как все ретраи исчерпаны. Это финальная точка восстановления: отмена уже выполненных действий, отправка уведомлений, сохранение диагностики, перевод агента в безопасное состояние. Для многошаговых агентов с реальными побочными эффектами — резервирование ресурсов, списание средств, создание записей во внешних системах — LangChain рекомендует паттерн SAGA. Идея: каждый шаг агента сопровождается компенсирующей операцией, которая отменяет его эффект. Если шаг N упал после успешного завершения шагов с 1 по N-1, компенсирующие операции запускаются в обратном порядке — система возвращается в консистентное состояние. LangGraph позволяет встроить SAGA прямо в граф: компенсации хранятся рядом с узлами, а error_handler запускает их цепочку при сбое.

«Наличие политик отказоустойчивости внутри движка, а не снаружи него — принципиальная разница: логика восстановления получает полный контекст состояния графа», — блог

LangChain.

Что это значит

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