Урок 5 из 8

Устойчивость: чекпоинты, пауза и человек в контуре

Цель урока: понять четыре суперспособности, которые даёт автосохранение процесса. Именно ради них LangGraph выбирают для серьёзных продуктов.

Чекпоинтер: автосохранение как в игре

Если при сборке графа подключить чекпоинтер (checkpointer), LangGraph начинает сохранять снимок состояния после каждого узла (документация по persistence). Каждый снимок - чекпоинт, как сохранение в компьютерной игре.

Каждый процесс живёт в своём треде (thread) - это «номер разговора». Один ученик - один тред: все чекпоинты его диалога лежат в одной цепочке.

Узел 1 Узел 2 Узел 3 💾 чек 1 💾 чек 2
После каждого узла - автосохранение. Сбой между узлами 2 и 3? Продолжим с чекпоинта 2.

Четыре суперспособности

1. Выживание после сбоев

Сервер перезагрузился, API модели упал, кончился лимит - процесс не погибает. Он продолжится с последнего чекпоинта. Для процесса, который стоит клиенту денег (например, глубокое исследование на 20 минут), это разница между «извините, начните заново» и «всё в порядке, продолжаем».

2. Память диалога

Тред помнит всё, что в нём было. Ученик вернулся через три дня - бот продолжает разговор с того же места, потому что состояние треда лежит в базе, а не в оперативной памяти.

3. Человек в контуре (human-in-the-loop)

Внутри узла можно вызвать interrupt() - и процесс замирает: состояние сохранено, ничего не крутится, деньги не тратятся. Когда человек принял решение, процесс будят командой «продолжай с таким-то ответом» - и он идёт дальше, как будто паузы не было. Пауза может длиться минуту или месяц.

Аналогия

Это согласование у руководителя. Менеджер подготовил скидку 25%, положил заявку тебе на стол и занялся другими делами. Ты вернулся из отпуска, написал «ок» - и заявка поехала дальше по процессу. Никто не стоял у твоей двери всё это время.

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

4. Машина времени

Time travel: можно взять любой прошлый чекпоинт и переиграть процесс с него - или создать развилку с изменёнными данными: «а что было бы, если бы категория была другой?» Это мощнейший инструмент отладки: не гадать, почему агент ошибся, а вернуться к моменту ошибки и посмотреть.

Чекпоинтер и Store: две разные памяти

ЧекпоинтерStore
Что помнитХод одного разговора (треда)Факты о пользователе между всеми разговорами
АналогияСтенограмма конкретной встречиЛичное досье клиента в CRM
Пример«На чём мы остановились вчера»«Юрий предпочитает короткие ответы и живёт на Бали»

Они дополняют друг друга: чекпоинтер - краткосрочная память процесса, Store - долгосрочная память о человеке.

Практическая деталь

Для продакшена чекпоинты хранят в настоящей базе (обычно PostgreSQL). Вариант «в памяти» (InMemorySaver) - только для эксперимента: перезапуск сервера сотрёт всё. Когда Claude Code строит тебе прототип - это нормально, но перед деплоем проси перевести на PostgreSQL.

Проверь себя

1. Процесс упал на шаге 7 из 10 (сбой API). Что произойдёт при повторном запуске с чекпоинтером?

2. Пока процесс стоит на паузе interrupt() и ждёт твоего решения, что происходит?

3. Бот должен помнить, что ученик предпочитает видео-объяснения, во всех будущих диалогах. Что для этого нужно?

Спроси своего Claude

Примерь на свой проект: «Вот мой процесс: [описание]. Где в нём нужны interrupt-паузы на моё согласование, и что хранить в Store, а что в чекпоинтах?»