LangChain против LangGraph: что на самом деле показывают зависимости пакетов
Анализ на уровне зависимостей показывает, что LangGraph является обязательной частью LangChain, в связи с чем выбор фреймворка следует рассматривать как использование трех пакетов, а не двух.
Дискуссии о LangChain против LangGraph постоянно возникают в технических обсуждениях, и стандартный ответ практически всегда одинаков: обращайтесь к LangChain, когда вам нужны цепочки операций и вызовы инструментов, а к LangGraph — когда требуются агенты с состоянием и циклами. Этот ответ не ошибочен, но он основан на предпосылке, которая теряет силу при более внимательном рассмотрении.
Более точный ответ оказывается прямо перед глазами — в самой метаданных пакета.
Что раскрывает простая установка
Попробуйте выполнить команду pip install langchain, а затем проверьте, что на самом деле было сохранено на диске.
langchain-core==1.5.0
langgraph==1.2.9
pydantic==2.7.4
LangGraph автоматически входит в состав LangChain. Это не факультативный дополнительный компонент, который можно пропустить — это обязательная зависимость. Если посмотреть на манифест версии langchain 1.3.14, то как строгие требования указаны только три пакета, среди которых находится langgraph, ограниченный версиями от 1.2.5 до 1.3.0 включительно.
Теперь попробуйте сделать наоборот: pip install langgraph. В этом случае будет установлен langchain-core вместе с собственными подпакетами LangGraph, но сам langchain так и не установится.
Это означает, что типичное представление ситуации как выбора «либо это, либо то» описывает что-то, что ваш менеджер пакетов просто не позволит сделать. Установка LangChain гарантирует наличие LangGraph вместе с ним. Обратной гарантии не существует.
Три пакета, а не два
Большинство сравнений представляют это как двустороннее решение. На самом деле существует три отдельных пакета, и как только вы правильно назовёте каждый из них, большая часть путаницы исчезнет.
langchain-core — это общая основа, лежащая в основе всего остального. В нём содержатся типы сообщений, абстракция Runnable, BaseTool и RunnableConfig. И langchain, и langgraph напрямую зависят от него — без него ничто в этих пакетах не будет работать.
langgraph — это фактический движок выполнения. Можно рассматривать его как машину состояний, построенную из узлов, условных рёбер, общего объекта состояния и поддержки сохранения точек контроля. Он разработан для обработки циклов, что по сути и является сутью цикла агента. Примерно 40,2% собственных исходных файлов LangGraph напрямую импортируют langchain_core, что говорит о том, что он не является конкурирующей альтернативой LangChain — он создан на основе основных абстракций LangChain.
langchain находится над обоими как универсальный пакет. Он объединяет интеграции с моделями, соединители с поставщиками и удобные обёртки для создания агентов на основе только что описанных двух пакетов. Именно его следует установить, если вы хотите иметь в распоряжении ChatOpenAI или ChatAnthropic готовыми к использованию, не писая собственного HTTP-клиента с нуля.
Описание этого как «линейные цепи против графов с состоянием» отражает более старое разделение, которого больше нет в кодовой базе. Более точный способ сформулировать это сегодня: LangGraph — это движок выполнения, выполняющий фактическую работу, а LangChain — это слой удобства, который объединяет этот движок с интеграциями поставщиков.
Настоящий выбор, который вы делаете
Как только вы четко поймёте направление зависимостей — LangChain находится сверху LangGraph, а не наоборот — суть вопроса, на который вы отвечаете, меняется.
Вопрос уже не «LangChain или LangGraph?», а становится таким: хотите ли вы получить полный набор инструментов langchain с возможностью интеграции с различными поставщиками, компонентом ChatOpenAI, инструментами для создания агентов и более чем 30 дополнительными факультативными пакетами? Или же предпочитаете разрабатывать непосредственно с использованием langchain-core и langgraph, избегая лишних компонентов?
В обоих случаях в основе всё равно лежит LangGraph. Разница заключается во всех остальных компонентах, которые подключаются к вашей среде вместе с ним.
Если вы создаёте образ агента для производственного использования, где требуется строго ограниченный и легко проверяемый набор зависимостей, установка langgraph вместе с клиентом соответствующего провайдера позволит сократить размер образа. Если же вы быстро разрабатываете прототип и хотите, чтобы ChatOpenAI работал без необходимости ручной настройки обёртки провайдера, команда pip install langchain[openai] поможет достичь цели с меньшим количеством настроек.
Стоит отдельно упомянуть один момент: langchain-core устанавливает LangSmith — клиент для отслеживания действий в LangChain, как обязательную зависимость. Он не будет отправлять никаких данных, если вы этого явно не настроите. Однако если вы проверяете содержимое своего контейнера, этот компонент там будет присутствовать независимо от того, включены ли его функции.
Почему выбор имеет значение не только из-за размера установки
Было проведено контролируемое сравнение LangGraph 1.2.9 и Pydantic AI 2.13.0 в четырех задачах, всего 160 запусков с использованием gpt-4o. Оба фреймворка достигли 100% точности. LangGraph выполнял задачи примерно на 1,4–1,8 секунды быстрее, причиной чего стало использование Pydantic AI механизма преобразования асинхронных операций в синхронные, однако разница в точности между ними не была заметна.
Фактически на результаты повлиял базовый модель, а не выбор фреймворка. При выполнении тех же задач с использованием gpt-4o-mini была полная неудача — 0 из 20 — в одной задаче, связанной с арифметикой дат; более крупная модель справилась с этим сложным случаем без проблем.
Короче говоря, выбор между LangChain и LangGraph в основном сводится к решению о том, насколько большую часть окружающей экосистемы LangChain вы хотите включить в свой проект, поскольку обе библиотеки работают на одном и том же движке. С другой стороны, выбор между LangGraph и Pydantic AI означает сравнение двух полностью отдельных библиотек — и приведенные выше результаты показывают, что при использовании gpt-4o ни одна из них не демонстрирует явного преимущества в точности, хотя разница в задержке достаточно значительна, чтобы ее измерять в собственной среде.
Связанные статьи
- Что на самом деле автоматизирует LangChain после создания цикла агента — Объясняется, как LangChain, LangGraph и подобные SDK-ы используют тот же основной цикл агента, созданный с нуля, и когда использование фреймворка помогает, а когда мешает.