LangGraph и FastAPI: как построить чат-бота в формате микросервиса

В последние годы экосистема инструментов для разработки ИИ-приложений стремительно развивается. Одним из ярких примеров является LangChain – фреймворк, который сделал работу с большими языковыми моделями (LLM) более структурированной и доступной. Но, как это часто бывает в технологиях, с ростом популярности начинают проявляться и ограничения. На смену привычным подходам приходит LangGraph, предлагающий новый взгляд на построение сложных интерактивных систем.

В этой статье мы разберем, чем отличаются LangChain и LangGraph, почему последний все чаще выбирают для построения чат-ботов, и как можно выстроить надежный микросервис на их основе в связке с FastAPI.

Что такое LangChain

LangChain – это фреймворк для работы с LLM, который позволяет связывать модель с внешними источниками данных, инструментами и логикой в виде цепочек (chains). Каждая цепочка – это последовательность шагов, через которые проходит пользовательский запрос: от предварительной обработки данных, до генерации ответа.

Ключевые возможности LangChain:

• Подключение к API моделей и векторных баз данных.
• Организация конвейеров обработки.
• Работа с памятью (memory) для сохранения контекста диалога.
• Поддержка инструментов для извлечения и поиска информации.

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

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

Проблематика LangChain в чат-ботах

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

Основные проблемы:

• Ограниченная гибкость: изменение порядка шагов или добавление ветвлений требует значительной перестройки цепочки.
• Сложность управления состоянием: особенно при длинных или прерванных диалогах.
• Слабая поддержка асинхронного взаимодействия: чат-боту бывает необходимо “заморозить” сценарий и вернуться к нему позже – с LangChain это неудобно.

LangGraph

LangGraph – это библиотека, которая расширяет идею LangChain, но переносит ее в графовую парадигму. Вместо линейных цепочек, взаимодействие описывается в виде графа состояний, где каждый узел – это шаг или действие, а ребра – возможные переходы между ними.

Преимущества LangGraph:

• Гибкие сценарии: легко описывать сложные ветвления, циклы и условные переходы.
• Управление состоянием: встроенные механизмы сохранения прогресса и возобновления работы.
• Human-In-The-Loop: возможность встроить этапы, где решение принимает человек.
• Ожидание и асинхронность: можно остановить выполнение на этапе и продолжить позже.

Эта платформа поддерживает не только графовую, но и функциональную парадигму разработки: можно задействовать state‑менеджмент, human‑in‑the‑loop, механизм “путешествия во времени” (time travel), стриминг ответов и сохранение Durable execution даже без явного описания графа – все это доступно через новый Функциональный API, который остался легким и гибким и отлично вписывается в разнообразные приложения.

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

Human-In-The-Loop

Одна из ключевых функций LangGraph – это поддержка Human-In-The-Loop (HITL). В контексте чат-бота это означает, что на определенном шаге выполнения бот может передать контроль человеку, дождаться ответа или подтверждения, и только потом продолжить выполнение графа.

Применение:

• Ожидание ответа от пользователя при итеративном поочередном способе взаимодействия с системой.
• Верификация критичных решений (например, юридические консультации, медицинские рекомендации).
• Подтверждение сложных действий (оформление заказа, списание средств).

Технически это реализуется через “паузу” в графе: узел переходит в режим ожидания и продолжает работу только после получения данных от внешней системы или оператора. Такая архитектура не ограничена временем. Если операция требует внешнего подтверждения или дополнительных данных, выполнение может быть отложено на неопределенный срок – в ожидании ответа будет физически сохранен каждый шаг. После получения подтверждения оператором, система легко восстанавливает выполнение через механизм Command, позволяя продолжить работу графа.

Состояния и сессии в LangGraph

В отличие от LangChain, где контекст обычно хранится в памяти цепочки, LangGraph оперирует понятиями состояний и сессий.

• Состояние описывает, на каком узле графа сейчас находится выполнение и какие данные уже получены.
• Сессия – это уникальный контекст конкретного взаимодействия (например, диалога с пользователем), который можно сохранить, выгрузить или восстановить.

Это позволяет:

• Приостанавливать выполнение графа в любой момент.
• Возобновлять работу после перезапуска сервиса.
• Масштабировать приложение, передавая сессии между экземплярами микросервиса.

Архитектура микросервиса чат-бота

Клиент (веб или мобильное приложение, либо любой бэкенд) отправляет обычный POST на шлюз FastAPI с сообщением пользователя и идентификаторами сессии/пользователя. На границе мы валидируем вход и сразу подготавливаем ответную модель: либо вернем готовый текст, если ветка исполнения короткая, либо мгновенно отдадим “квитанцию” с message_id, чтобы клиент мог опросом (‘GET /messages/{id}’) забрать готовый ответ чуть позже.

Сердце сервиса – компилированный граф LangGraph. Каждый вызов поднимает из постоянного хранилища снимок состояния по ключу сессии, выполняет несколько “шагов” графа и снова делает чекпойнт. Если сценарий прост и укладывается в тайм-аут запроса, мы формируем ответ сразу и возвращаем его синхронно. Если шагов много или участвуют “долгоиграющие” инструменты, FastAPI после базовой проверки и записи задания немедленно отвечает клиенту, а продолжение логики уходит в фоновую задачу. В этом месте отлично работает встроенный механизм фоновых задач FastAPI: операция продолжает выполняться уже после того, как клиент получил HTTP-ответ, что убирает блокировки интерфейса и снимает давление по тайм-аутам. Для простых сервисов этого достаточно, не прибегая к очередям и воркерам; при росте нагрузки можно заменить встроенный фон на внешний раннер, не меняя контрактов.

Состояние – ключ к предсказуемости и “живучести”. LangGraph после каждого значимого шага сохраняет снимок (checkpointer) и благодаря “durable execution” позволяет восстановиться ровно с той точки, где нас прервали – будь то рестарт контейнера, отказ внешнего сервиса или намеренная пауза HITL. Это убирает необходимость в самописных “машинах состояний” и делает долгие диалоги воспроизводимыми: мы не проигрываем ветку заново и не теряем контекст, а просто продолжаем. Для простого варианта достаточно одинарного устойчивого хранилища для чекпойнтов (SQL/NoSQL – по требованиям), при этом сам принцип “сохранился → продолжил” встроен в библиотеку.

Про исполнение “внутри” важно помнить баланс синхронного и асинхронного. FastAPI одинаково поддерживает оба подхода, но блокирующие операции (вызовы внешних HTTP-сервисов, I/O) лучше либо уносить в фон сразу после быстрого ответа клиенту, либо вызывать в неблокирующем режиме, чтобы не нагружать воркеров во время ожидания. Это поддержит стабильность: очередной клиент не должен ждать, пока предыдущий запрос закончит медленную обработку, например, цепочки промптов.

Итого получается стабильный конвейер: клиент запрашивает в обычный HTTPS-маршрут, сервис валидирует и либо сразу возвращает готовый ответ, либо отдает “квитанцию” и продолжает шаги графа в фоне; каждый значимый шаг фиксируется в стойком хранилище, поэтому любой сбой или пауза будет обрабатываться корректно; человеческое участие включается тем же HTTP, без постоянных соединений. Такой дизайн не требует необычных шаблонов инфраструктуры и легко разрабатывается для большинства проектов и задач.

Итог

LangGraph в сочетании с FastAPI предоставляет надежную и гибкую основу для построения production-ready чат‑ботов. LangGraph выводит организацию логики взаимодействия на новый уровень, позволяя проектировать диалоги в форме графов, а не линейных цепочек, и обеспечивая встроенный контроль состояния и возможность возобновления выполнения через механизм durable execution. Это делает возможным разработку диалоговых систем с ветвлениями, циклами, Human‑In‑The‑Loop и устойчивостью к сбоям, в отличие от LangChain, где подобные сценарии становятся трудно поддерживаемыми.

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

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

Николай Андрющенко, ML-инженер