Длительный процесс — заявка, согласование, исправление, повторная проверка — держится на трёх вещах: состоянии, ветвлениях и паузах на человека. LangChain LangGraph оформляет все три в виде графа, где каждый шаг знает о предыдущем, если подключён постоянный checkpointer и сохранён идентификатор потока. Если процесс укладывается в один рабочий день и идёт по единственному маршруту без возвратов, граф даёт лишнюю сложность: хватит обычной цепочки.
Когда граф нужен
LangGraph описывает состояние, переходы и паузу на решение человека. Для ожидания и восстановления после сбоя подключите постоянный checkpointer и передавайте тот же thread_id при возобновлении.
Обычная цепочка вызовов модели годится для коротких задач: ответил — и забыл. Как только процесс требует ожидания внешнего события — письма от клиента, подписи руководителя, — состояние нужно сохранять между шагами, иначе каждый перезапуск начинает всё сначала. LangGraph хранит его в явном объекте: какие документы собраны, кто подтвердил, какие шаги впереди. Идентификатор потока служит ключом заявки: одна заявка — один thread_id, по нему граф находит свою историю, а новый идентификатор открывает историю с чистого листа. Состояние можно вывести в журнал или служебный экран, но экран для руководителя команда собирает отдельно: LangGraph отвечает за хранение данных, интерфейс остаётся задачей команды. Для первого проекта берите процесс на пять-семь шагов: он достаточно живой, чтобы оправдать инструмент, и достаточно короткий, чтобы прогнать руками за один день. Знакомство с библиотекой и её местом в стеке — в статье о LangChain для компаний. Там же разобрано, когда обходятся одними цепочками, а когда без графа уже тесно.
Состояние процесса
Состояние — словарь, который путешествует по графу и пополняется на каждом шаге. Собирайте его из коротких полей с понятными именами: номер заявки, список документов, отметки о подтверждениях, журнал действий. Длинные простыни текста в состоянии мешают: отладка тяжелеет, а нужный шаг в журнале тонет в лишнем объёме. Checkpointer сохраняет снимки состояния на границах шагов графа. Историю можно посмотреть и продолжить выполнение из сохранённой точки; совершённые ранее внешние действия при этом остаются выполненными. Правило проверки состояния одно: после чтения поля человек с ходу отвечает, что там лежит. Если ответ требует расшифровки, поле переделайте: любой коллега из соседнего отдела должен прочитать его без подсказок автора.
- Одно поле — одна роль: заявка, документы, подтверждения.
- Каждый переход добавляет запись в журнал действий.
- Проверьте, что постоянный checkpointer сохраняет нужные контрольные точки.
- Проверочные тесты читают состояние, а интерфейсы — журнал.
- Секреты храните вне состояния; доступ к самому состоянию ограничьте.
Схема состояния живёт вместе с графом: добавили поле — проверьте, как поведут себя сохранённые точки заявок, которые ещё ждут решения. Для долгих процессов держите в тестовом наборе часть заявок, начатых на старой схеме, и часть на новой.
Ветвления и паузы
- Опишите шаги процесса и условия переходов между ними.
- Отметьте шаги, где решение принимает человек.
- Настройте паузу: граф ждёт подтверждения и лишь потом идёт дальше.
- Проверьте ветку отказа: куда уходит заявка при отрицательном ответе.
- Прогоните процесс на тестовой заявке с реальными ожиданиями.
Для паузы LangGraph использует interrupt: выполнение останавливается, а состояние сохраняется через checkpointer. После решения человека продолжайте тот же thread_id. Код узла после возобновления запускается с начала, поэтому внешние действия до interrupt делайте идемпотентными или выносите в отдельный шаг. Ветвления по исходам рисуйте до написания кода: схема с веткой отказа, возвратом на доработку и повторной проверкой сокращает переделки, ведь двигать стрелки на бумаге дешевле, чем узлы в коде. Сценарий поиска с цитатами, которому граф даёт руки для действий, разобран в материале про RAG-агента с инструментами. Ждать решения граф готов сколько угодно, поэтому напоминания согласующим организуйте через внешний планировщик и отдельный маршрут эскалации: interrupt лишь останавливает выполнение.
На каком шаге процесс чаще всего ждёт человека?
Восстановление после сбоя
Сбои случаются: сервис недоступен, ответ пришёл в неверном формате, согласующий ушёл в отпуск на середине маршрута. С постоянным checkpointer граф возобновляется из сохранённого состояния. Перед повтором вызова проверьте, успело ли внешнее действие выполниться: иначе возможна повторная запись или отправка. Ограничьте число повторов и опишите аварийный выход: кому уходит заявка, если после нескольких попыток шаг так и остался невыполненным. Без аварийного выхода заявки зависают между узлами, и их ищут неделями. Подходы к безопасным границам таких контуров разобраны в материале про права и секреты ИИ-агентов. Поскольку возобновление идёт с сохранённого узла, его код может выполниться ещё раз: отсюда требование идемпотентности для внешних действий. Для каждого шага с внешним эффектом заведите ключ операции: повторный вызов с тем же ключом должен приводить к одной записи, а в журнале видно, что шаг уже выполнялся.
Восстановление проверяется репетицией: гасите сервер на середине процесса, поднимайте заново и смотрите, продолжается ли граф с того же узла, а внешние действия остаются без дублей. Повторяйте репетицию после каждого серьёзного обновления библиотеки или хранилища состояния: так проблема с чтением сохранённых точек находится до первой настоящей аварии.
Границы инструмента
LangGraph добавляет сложность, и она оправдана при конкретной потребности в маршрутизации, паузах или восстановлении. Процесс из трёх шагов без ожиданий живёт в цепочке вызовов, там граф — лишний вес. Точный признак лишнего веса: команда проводит больше времени с инструментом, чем с самим процессом. Выбор между цепочкой, графом и готовой платформой разобран в статье о выборе платформы для ИИ-агентов, а состав работ по внедрению и этапы — на странице про внедрение ИИ. Стоимость зависит от числа интеграций и требований к отказоустойчивости; фиксируется на созвоне.
| Сигнал | Что это значит | Куда смотреть |
|---|---|---|
| Процесс длиннее дня | Нужно хранение состояния | LangGraph или платформа |
| Ожидание людей | Паузы и напоминания | Узел человека в графе |
| Частые возвраты | Ветвления по исходам | Условные переходы |
Таблица помогает выбрать момент перехода: сопоставьте свой процесс с тремя сигналами, и совпадение хотя бы двух уже повод нарисовать граф на бумаге. Рисовать граф полезно и до решения о разработке: когда процесс описан и прогнан вручную, видно, какие шаги лишние, и часть работы отпадает ещё до первой строчки кода. Обратная сторона вопроса — команда: граф требует навыка чтения чужих схем, поэтому минимум один человек в компании должен уметь разбирать маршрут без автора.