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-и обгортають один і той самий основний цикл агента, створений з нуля, та коли використання фреймворку допомагає чи шкодить.