LangChain vs LangGraph: как выбрать основу для ИИ-агента

LangChain vs LangGraph: что выбрать для своей задачи?

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

Если вы создаёте помощника службы поддержки, который ищет заказы и отвечает на вопросы, используйте create_agent из LangChain. Вы задаёте модель, инструменты и инструкции, а агентный слой берёт на себя повторяющееся взаимодействие модели с инструментами. Когда понадобится проверка правил или согласование, добавьте middleware — код, который выполняется вокруг этого взаимодействия.

Если приложение на LangChain уже работает, оставьте его как есть, пока не появится конкретное требование к процессу, которое неудобно выразить средствами этой абстракции. Память диалога или проверка предложенного вызова инструмента сами по себе не повод для перехода: актуальные агенты LangChain поддерживают и то и другое благодаря LangGraph. Документация по агентам LangChain.

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

Условия использования библиотек указаны на странице LangChain и странице LangGraph. Сравнение возможностей опирается на обзор среды исполнения и документацию по middleware для согласования от разработчиков. Здесь мы выбираем архитектуру, а не ранжируем библиотеки по скорости.

Как сегодня устроены LangChain и LangGraph

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

LangChain: настраиваемый слой агента

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

Преимущество LangChain — удобная исходная структура. В помощнике по заказам можно превратить существующую функцию поиска в инструмент и задать правила её использования. Не нужно вручную собирать цикл взаимодействия, прежде чем приступать к работе над продуктом.

Ограничение возникает, когда эта структура перестаёт подходить задаче. Длительный процесс с отдельными бизнес-этапами бывает труднее понять, если каждый переход спрятан в промптах, соглашениях об использовании инструментов и middleware. Речь об удобстве сопровождения, а не о том, что агенты LangChain не умеют ветвиться или хранить состояние. Библиотека бесплатна; доступ к моделям и выбранная инфраструктура оплачиваются отдельно.

LangGraph: среда исполнения под вашим контролем

LangGraph называет себя «низкоуровневым фреймворком оркестрации и средой исполнения» для агентов, которые работают длительное время и сохраняют состояние. Узел — это единица работы; ребро определяет, куда пойдёт выполнение; состояние — информация, которая передаётся между шагами. Обычную логику приложения можно сочетать с решениями, которые принимает модель. Обзор LangGraph.

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

Ограничение здесь — объём вашей ответственности. Нужно продумать содержательное состояние, переходы и поведение при сбоях. Граф с неясными границами остаётся сложным для понимания кодом. LangGraph тоже бесплатен и может работать без LangChain, хотя компоненты LangChain для моделей и инструментов часто удобно сохранить.

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

Агенты LangChain и LangGraph: где проходит граница управления

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

Цикл агента и согласование вызовов: преимущество LangChain

Помощник, который читает заказ, объясняет его статус и предлагает ответ, хорошо укладывается в цикл «модель — инструменты». Проверка перед отправкой ответа через инструмент тоже вписывается в эту схему: HumanInTheLoopMiddleware умеет приостанавливать настроенные вызовы инструментов и принимать одобрение, изменённые аргументы или отказ. Для сохранения прерванного состояния используется механизм LangGraph. Документация по участию человека в цикле.

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

Явные бизнес-этапы: преимущество LangGraph

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

Граф позволяет напрямую описать эти переходы. При этом узел сбора данных по-прежнему может вызывать агента LangChain. Проверку и активацию можно реализовать обычными функциями с явно заданными результатами. Существенное отличие здесь — документированная возможность LangGraph сочетать детерминированные шаги с агентными. Обзор LangGraph.

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

Восстановление после сбоев: общая основа, разный объём проектирования

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

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

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

Разработчики описывают это поведение при возобновлении и необходимость идемпотентных побочных эффектов — операций, повторение которых не повторяет их бизнес-результат. Например, используйте стабильный идентификатор операции, чтобы возобновлённая задача не могла создать одного и того же поставщика дважды. Правила прерывания и повторного выполнения.

LangChain и LangGraph на Python: одна задача, два подхода

Для простой проверки статуса заказа LangChain позволяет выразить ту же задачу с меньшим объёмом кода оркестрации. Собственный граф делает маршрут между моделью и инструментами явным — это оправданно, когда маршрут понадобится менять.

В примерах используются одинаковые модель, промпт, инструмент только для чтения и входные данные. Запись о заказе — заведомо вымышленные локальные тестовые данные. Установите langchain[anthropic] и langgraph; для обращения к настоящей модели приложению потребуется ANTHROPIC_API_KEY. Идентификатор модели в примере взят из актуальных обзора LangChain и краткого руководства по LangGraph от разработчиков. Оба фрагмента локально проверены с моделью, ответы которой заданы программно: проверка подтвердила выполнение инструмента и сохранение состояния. Это проверка взаимодействия компонентов, а не поведения или производительности реальной модели.

Сохраните общую часть в файле common.py:

from langchain.chat_models import init_chat_model
from langchain.tools import tool

model = init_chat_model("claude-sonnet-4-6", temperature=0)
prompt = "Use lookup_order for order status. Do not invent a status."
request = {"messages": [{"role": "user", "content": "Status of order demo?"}]}
config = {"configurable": {"thread_id": "order-demo"}}

@tool
def lookup_order(order_id: str) -> str:
    """Read an order's status from a fictional local fixture."""
    return {"demo": "shipped"}.get(order_id, "unknown order")

LangChain: используем готовый цикл

Запустите этот код отдельным скриптом рядом с common.py:

from common import model, prompt, request, config, lookup_order
from langchain.agents import create_agent
from langgraph.checkpoint.memory import InMemorySaver

agent = create_agent(
    model, tools=[lookup_order], system_prompt=prompt,
    checkpointer=InMemorySaver(),
)
print(agent.invoke(request, config)["messages"][-1].content)

Под этим агентом уже работает среда исполнения графа. Передача checkpointer не требует заменять create_agent на написанный вручную граф. Настройка агента.

LangGraph: описываем тот же цикл явно

Запустите альтернативный скрипт рядом с тем же common.py:

from common import model, prompt, request, config, lookup_order
from langchain.messages import SystemMessage
from langgraph.checkpoint.memory import InMemorySaver
from langgraph.graph import StateGraph, MessagesState, START
from langgraph.prebuilt import ToolNode, tools_condition

bound_model = model.bind_tools([lookup_order])

def call_model(state: MessagesState):
    reply = bound_model.invoke([SystemMessage(prompt)] + state["messages"])
    return {"messages": [reply]}

builder = StateGraph(MessagesState)
builder.add_node("model", call_model)
builder.add_node("tools", ToolNode([lookup_order]))
builder.add_edge(START, "model")
builder.add_conditional_edges("model", tools_condition)
builder.add_edge("tools", "model")
agent = builder.compile(checkpointer=InMemorySaver())
print(agent.invoke(request, config)["messages"][-1].content)

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

Оба фрагмента намеренно используют память внутри процесса и показывают только успешное чтение. Ни один из них не является инструкцией по развёртыванию, настройкой постоянного хранилища в базе данных или полной политикой обработки ошибок. Совпадение конфигурации не гарантирует дословно одинаковых ответов модели.

Для этой задачи выбирайте LangChain. Собственный граф становится полезен, когда следующее требование меняет сам процесс: обязательная проверка перед поиском, отдельная очередь исключительных ситуаций или этап согласования со своим состоянием и результатами.

Стоимость LangSmith и развёртывания LangGraph

Выбор библиотеки не означает выбор отдельного тарифа на хостинг. Платное решение определяется тем, какие сервисы LangSmith и какая среда развёртывания вам нужны. Приведённые ниже цены и сведения из документации сверены с действующими страницами разработчиков 13 октября 2026 года.

LangChain, LangGraph и LangSmith: за что отвечает каждый

LangSmith — платформа для трассировки, оценки и развёртывания приложения. Трасса фиксирует выполнение приложения и может включать вызовы модели и другие шаги. Это отдельная сущность, отличная от контрольной точки, по которой приложение возобновляет работу. Цены и определения LangSmith.

Обе библиотеки бесплатны. При запуске любой из них в собственной инфраструктуре всё равно нужно учитывать расходы на вызовы моделей, вычисления, хранение и эксплуатацию. Покупка LangSmith — отдельное решение; в документации по развёртыванию прямо указана поддержка приложений на LangGraph и LangChain.

Это условия тарифов на langchain.com/pricing. Калькулятор на странице описывает включённый объём Plus как 10K трасс суммарно: добавление мест не означает, что за каждое место полагается ещё такой же объём. Для показанной конфигурации наблюдаемости он указывает 0.005 LSU за дополнительную трассу. Это значение из калькулятора нельзя распространять на все варианты хранения трасс.

Базовые трассы хранятся 14 дней, расширенные — 180 дней и требуют дополнительной оплаты. Более длительное хранение и сервисы оценки — отдельные статьи бюджета, а не бесплатное следствие выбора графа. Вопросы о тарифах.

Варианты развёртывания и их ограничения

Cloud — управляемый вариант, доступный на тарифе Plus и выше. Инфраструктуру обслуживает LangChain. В рамках Cloud на публичной странице цен представлены развёртывания Serverless и Dedicated в размерах Small, Medium и Large. Среды развёртывания.

Serverless подходит для нерегулярной, фоновой или нечувствительной к задержкам работы. При отсутствии нагрузки он масштабируется до нуля, а в Plus включено небольшое развёртывание. Dedicated подходит для пользовательских сервисов, которым нужна стабильная доступность: инфраструктура работает постоянно, предусмотрены автомасштабирование, резервные копии и высокая доступность. Так назначение продуктов описывает сам разработчик; это не результаты измерения производительности в рамках данного сравнения. Вопросы о стоимости развёртывания.

На план миграции влияет практическое ограничение: размер развёртывания можно изменить, а его тип после создания — нельзя. Поэтому переход с Serverless на Dedicated требует смены развёртывания, а не простой корректировки размера. Ресурсы Serverless также оплачиваются всё время, пока они выделены, включая простой до уменьшения масштаба. «Масштабирование до нуля» не означает, что каждая секунда без запросов бесплатна. Возможности платформы Cloud.

Hybrid сохраняет управляемый контур управления, а инфраструктуру агентов обслуживаете вы. Контур управления — сервис, который управляет развёртываниями; контур данных запускает агентов и обслуживающие их сервисы. При самостоятельном размещении с контуром управления оба контура находятся в вашей среде. На странице цен гибридные варианты и самостоятельное размещение отнесены к Enterprise с индивидуальной ценой. Публичной фиксированной месячной стоимости Enterprise, которую можно подставить в расчёт, нет. Цены и среды развёртывания.

Автономный Agent Server — ещё один вариант эксплуатации, без контура управления и с собственными вспомогательными сервисами. Согласно документации, ему нужны лицензия LangSmith, PostgreSQL и Redis. Это отличается от встраивания бесплатной библиотеки LangGraph в собственное приложение. Документация по автономному серверу также предостерегает от его размещения в бессерверной среде с масштабированием до нуля; управляемый продукт Cloud Serverless имеет отдельную конфигурацию. Автономный Agent Server.

Одинаковая нагрузка стоит одинаково на обоих фреймворках

Публичная страница задаёт цену $1.00 за LSU, то есть LangChain Standard Unit, и следующие ставки за ресурсы развёртывания:

• Вычисления среды исполнения (Runtime Compute): 0.0675 LSU / vCPU-hr.
• Память среды исполнения (Runtime Memory): 0.0090 LSU / GiB-hr.
• Вычисления базы данных (Database Compute): 0.177 LSU / vCPU-hr.
• Память базы данных (Database Memory): 0.025 LSU / GiB-hr.

Эти ставки применяются к оплачиваемому потреблению ресурсов дополнительных развёртываний Serverless и Dedicated. Опубликованные ставки за развёртывание.

И для агента LangChain, и для собственного приложения LangGraph месячный расчёт на Plus устроен одинаково: $39 × число мест, плюс количество оплачиваемых часов использования каждого ресурса, умноженное на его ставку выше, плюс модели, трассировка и прочее оплачиваемое использование. Прежде чем считать платные ресурсы, учтите включённый в тариф объём развёртывания. Не переводите запросы или узлы графа в часы ресурсов без измерений.

Ниже — арифметика по опубликованным разработчиком размерам: это именно расчёт, а не заявленные цены тарифов. Дополнительное развёртывание Small Serverless получает 1 vCPU и 2 GiB ресурсов среды исполнения, что даёт 1 × 0.0675 + 2 × 0.0090 = $0.0855 за час выделенных ресурсов. Для Small Dedicated указаны 3 vCPU и 6 GiB для среды исполнения, а также 1 vCPU и 4 GiB для базы данных: 3 × 0.0675 + 6 × 0.0090 + 1 × 0.177 + 4 × 0.025 = $0.5335 за час выделенных ресурсов. Это оценки стоимости ресурсов для указанных размеров без дополнительного масштабирования и других сервисов; они основаны на таблице размеров и опубликованных ставках.

Для одного места Plus и неизменного указанного набора ресурсов Dedicated промежуточная месячная сумма составляет $39 + $0.5335 × часы выделенных ресурсов, без остальных перечисленных расходов. Формула одинакова для обоих фреймворков. Чтобы получить определённую месячную сумму, нужны фактические данные о времени использования ресурсов и масштабировании вашего развёртывания.

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

Переход с LangChain на LangGraph без переписывания приложения

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

Сначала отделите обновление устаревшего API от решения писать собственный граф. Актуальное руководство по миграции рекомендует langchain.agents.create_agent вместо прежнего конструктора langgraph.prebuilt.create_react_agent. Такая миграция не означает отказа от LangGraph под капотом. Более старому приложению могут сначала пригодиться нынешние возможности LangChain, и лишь затем — собственная оркестрация. Руководство по миграции LangChain.

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

Зависимость от выбранного стека тоже возникает на разных уровнях. Повторно используемые компоненты модели и инструментов могут остаться прежними, пока состояние графа и поток управления меняются. Управляемая инфраструктура добавляет свои ограничения: доступ к сохранённому состоянию Cloud идёт через Agent Server, а прямого доступа к размещённой там базе данных нет. Учитывайте эту границу доступа при будущем экспорте или смене хостинга. Подробности хранения в Cloud.

Если выбираете между оркестрацией через граф и абстракцией команды специалистов, прочитайте сравнение LangGraph и CrewAI. Варианты за пределами этого стека разобраны в более широком сравнении фреймворков для ИИ-агентов.

Частые вопросы при выборе фреймворка

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