В graph-based агенте, например на LangGraph, checkpointer позволяет продолжить выполнение по `thread_id` или похожему идентификатору. Если процесс остановился на human approval, упал сервер или пользователь вернулся позже, система может поднять последний checkpoint и продолжить без потери контекста.
Checkpointer может хранить состояние в памяти, файле, SQLite, Postgres, Redis или другом backend. Для локальных тестов часто хватает in-memory варианта, но для production нужен надежный persistent storage, потому что состояние должно переживать перезапуск приложения.
Важно не путать checkpointer и memory. Memory хранит полезные факты и историю, которые могут пригодиться в будущем. Checkpointer хранит техническое состояние конкретного запуска: текущий node, pending approval, промежуточные результаты, версию схемы и служебные метаданные.
Хороший checkpointer учитывает безопасность: не пишет секреты, ограничивает доступ к состоянию по пользователю или workspace, поддерживает TTL, версионирование схемы и audit log. Иначе сохраненный state сам становится источником утечки или странных ошибок при resume.
Примеры
- LangGraph checkpointer сохраняет state после каждого node, чтобы агент мог продолжить выполнение по тому же thread_id.
- Агент подготовил письмо, остановился на approval, а checkpointer сохранил черновик, получателя и следующий шаг.
- После перезапуска сервера workflow не начинается заново: checkpointer достает последний checkpoint из Postgres.
- В тестах используют in-memory checkpointer, а в production - persistent storage с TTL и доступами.
- Если схема state изменилась, checkpointer должен понимать версию checkpoint и не пытаться слепо восстановить старый формат.
- При отладке агентского flow checkpointer помогает увидеть, какой node последним изменил state.
Где используется
- сохранение состояния LangGraph-агента
- продолжение workflow после паузы или сбоя
- ожидание human approval между шагами
- восстановление контекста по thread_id или run_id
- долгие multi-step сценарии с несколькими tools
- отладка agent state и переходов графа
- повтор последнего безопасного шага после ошибки
- разделение локальных тестов и production-хранилища state
- контроль TTL и устаревших checkpoints
- аудит того, что агент видел и сделал до остановки
Связанные термины
Частые вопросы
Чем checkpointer отличается от checkpoint?
Checkpoint - это сохраненный снимок состояния. Checkpointer - механизм или компонент, который эти снимки создает, хранит, читает и помогает восстановить выполнение.
Зачем checkpointer нужен в LangGraph?
Он сохраняет state графа между шагами и вызовами. Это позволяет продолжать диалог или workflow по thread_id, делать human approval и переживать перезапуск сервера.
Можно ли обойтись без checkpointer?
Для простого одношагового запроса - да. Для долгих агентов, approval, tool calls, resumable workflows и production-сценариев checkpointer почти всегда нужен.
Где хранить checkpoints?
Для разработки подойдет память или SQLite. Для production лучше использовать надежное хранилище вроде Postgres, Redis или managed storage с резервным копированием, TTL и правами доступа.
Что нельзя класть в checkpoint?
Не стоит сохранять API-ключи, пароли, лишние персональные данные и большие файлы. Лучше хранить ссылки, идентификаторы и минимальный state, необходимый для продолжения.
Как понять, что checkpointer настроен неправильно?
После паузы агент теряет контекст, повторяет уже выполненные действия, путает пользователей, не может продолжить approval или падает при изменении схемы state.
