LangGraph и Temporal: где агентная логика, а где надежность

Когда команда начинает собирать агентный сценарий, очень быстро возникает соблазн решить все одной системой: и рассуждение, и вызовы инструментов, и повторные попытки, и хранение состояния, и контроль ошибок. На практике это почти всегда приводит к путанице. Одни и те же термины начинают означать разное: «состояние», «шаг», «поток», «оркестрация», «память», «выполнение». В результате разработчики строят красивую схему, но потом не могут понять, где именно живет бизнес-логика, где — агентная логика, а где — надежная доставка и восстановление процесса.

Полезнее сразу разделить задачу на две плоскости:

• LangGraph — для организации агентного поведения, разветвлений, циклов, принятия промежуточных решений и передачи контекста между шагами.
• Temporal — для надежного исполнения долговременных процессов: сохранения прогресса, повторов, таймаутов, восстановления после сбоев и контроля жизненного цикла работы.

Это не конкурирующие замены один другого. Это разные уровни системы. Если смешать их функции, архитектура быстро станет хрупкой. Если разделить правильно, можно собрать решение, где агент «думает» в одном месте, а бизнес-процесс исполняется надежно в другом.

Сначала разделите три слоя: логика, исполнение, состояние

Самая частая ошибка — считать, что «состояние агента» и «состояние процесса» это одно и то же. На самом деле это три разных слоя.

1. Агентная логика
Это то, как система принимает локальные решения: что спросить у модели, какой инструмент вызвать, стоит ли повторить шаг, нужно ли перейти в другую ветку. Здесь важны граф переходов, условия, узлы, циклы, формат входа и выхода между шагами.

2. Исполнение процесса
Это вопрос надежности: что будет, если сервис упал посреди шага, запрос ушел в сеть, ответ не пришел, а пользователь уже не может ждать. Здесь нужны ретраи, таймауты, компенсации, журналирование прогресса и возможность продолжить с места остановки.

3. Бизнес-состояние
Это данные предметной области: заказ, заявка, счет, маршрут согласования, статус проверки, артефакты, которые имеют ценность вне конкретного выполнения. Такое состояние нельзя прятать внутри «временной памяти» агента. Оно должно жить в устойчивом хранилище и иметь ясные правила изменения.

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

Где LangGraph полезен на практике

LangGraph удобно мыслить как граф агентного поведения. Не как «платформу для всей автоматизации», а как способ описать, как рассуждение переходит от шага к шагу.

Практически это полезно там, где есть:

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

Например, у вас есть сценарий обработки входящего запроса:

1. классифицировать обращение;
2. определить, достаточно ли данных;
3. при необходимости запросить уточнение;
4. выбрать инструмент;
5. собрать результат;
6. проверить полноту;
7. либо завершить, либо вернуться на предыдущий шаг.

Это хорошо ложится на граф. Тут важно не «магическое мышление», а дисциплина: каждый узел получает понятный вход, возвращает понятный выход, а переходы задаются явно. Тогда агентная часть остается читаемой.

Практический смысл LangGraph не в том, что он «делает ИИ умнее», а в том, что он делает маршрут принятия решений явным. Это сильно помогает, когда нужно:

• разбирать, почему система пошла не туда;
• тестировать отдельные ветки;
• менять порядок шагов без переписывания всего процесса;
• добавлять новые условия и проверки.

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

Где Temporal нужен именно как слой надежности

Temporal нужен там, где важно не «что решить», а как гарантированно довести процесс до конца или корректно его прервать.

Если говорить по-простому, Temporal полезен для таких задач:

• долгие процессы, которые переживают падения сервиса;
• шаги с ожиданием внешних систем;
• повторные попытки по правилам;
• таймауты и дедлайны;
• компенсационные действия;
• стабильное продолжение workflow после перезапуска;
• контролируемая оркестрация бизнес-операций.

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

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

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

Как их сочетать без смешения ролей

Самая рабочая схема — считать LangGraph и Temporal двумя независимыми уровнями.

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

Temporal: - запускает и контролирует workflow; - хранит прогресс выполнения; - обеспечивает retries, timeouts, recovery; - управляет долгоживущими этапами; - фиксирует факт прохождения критичных шагов.

Идея проста:
агент решает, что делать; workflow гарантирует, что это будет доведено до результата.

Ниже компактная таблица, которая помогает выбрать роль каждого слоя:

Главное правило архитектуры: не делать из графа рассуждения единственный источник истины о бизнес-процессе. И наоборот — не пытаться засунуть все агентное поведение в workflow-оркестрацию, где потеряется гибкость принятия решений.

Практический рабочий метод: как проектировать сценарий

Если вы строите реальную систему, полезно начинать не с библиотек, а с карты процесса.

Шаг 1. Выпишите бизнес-цель

Не «сделать агента», а что именно должно происходить: - обработать обращение; - подготовить черновик ответа; - согласовать документ; - проверить данные и передать результат в систему.

Шаг 2. Отделите решения от действий

Спросите себя: - где система должна решать? - где должна действовать? - где должна запоминать?

Решения — это LangGraph.
Действия и надежное исполнение — это Temporal.
Запоминание предметных данных — отдельное хранилище или доменная система.

Шаг 3. Определите критичные операции

Что нельзя потерять и нельзя выполнить дважды без последствий: - изменение статуса заявки; - отправка клиенту; - финансовая фиксация; - запуск внешней проверки; - резервирование ресурса.

Такие шаги должны жить в надежном workflow-контуре, а не в «временном» состоянии агента.

Шаг 4. Сведите агентный цикл к понятным узлам

Лучше иметь несколько простых узлов: - классификация; - проверка полноты; - выбор инструмента; - сборка результата; - контроль качества; - решение о повторе.

Чем меньше скрытой магии в узле, тем проще тестирование.

Шаг 5. Пропишите контракт между слоями

Между LangGraph и Temporal нужен не «общий словарь», а контракт: - что приходит на вход; - что считается завершением; - какие данные являются результатом; - какие ошибки считаются временными; - какие ошибки требуют остановки.

Так вы избежите ситуации, когда агент «думает», что что-то сделал, а workflow этого не зафиксировал.

Типичные ошибки, которые ломают архитектуру

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

Ошибка 1. Хранить бизнес-состояние в памяти агента
Память шага и история решения полезны, но они не заменяют устойчивое хранилище. Если процесс остановится, «память» исчезнет вместе с ним.

Ошибка 2. Делать из графа рассуждения оркестратор надежности
Граф может красиво описать путь принятия решения, но он не должен подменять механизм восстановления и гарантированного исполнения.

Ошибка 3. Смешивать шаги анализа и побочные эффекты
Если внутри одного узла и решение принимается, и запись в системе меняется, и внешняя отправка делается, отладка становится мучительной. Лучше сначала вычислить решение, потом отдельно исполнить действие.

Ошибка 4. Не разделять временные и доменные данные
Промежуточные выводы модели — это не те же данные, что заказ или заявка. У них разная цена ошибки и разный жизненный цикл.

Ошибка 5. Ожидать, что оркестрация заменит проектирование процесса
Ни LangGraph, ни Temporal не решают за вас, где проходит граница между аналитикой, автоматизацией и бизнес-правилами.

Короткий рабочий чек-лист перед запуском

Перед тем как соединять оба слоя, проверьте себя:

• [ ] Я отдельно описал решения и отдельно описал действия.
• [ ] Я знаю, какие данные являются бизнес-состоянием.
• [ ] Я понимаю, какие шаги должны быть надежно восстановимы.
• [ ] Я не храню критичные данные только внутри агентного цикла.
• [ ] У меня есть явный контракт между агентной логикой и workflow.
• [ ] Я могу объяснить, что произойдет после сбоя на любом шаге.
• [ ] Я знаю, где будет жить повторная попытка, а где — повторное рассуждение.

Если на один из пунктов ответа нет, архитектуру еще рано считать собранной.

Вывод: разделяйте мышление и гарантии исполнения

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

Практическое правило простое:
если вы проектируете решение — думайте о графе; если вы проектируете надежность — думайте о workflow; если вы проектируете предметные данные — думайте о домене.

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