25 мая LangChain выпустила 0.4, и это далеко не косметическое обновление: вся центральная модель описания пайплайнов поменялась. Библиотека появилась в 2022-м как способ склеить языковую модель с внешними инструментами через цепочку шагов. За три года эта линейная Chain-абстракция стала стандартом для RAG-прототипов, но при попытках построить что-то агентное — с ветвлениями, петлями, условными переходами — начинала трещать по швам. Версия 0.4 переносит центр тяжести на StateGraph, который теперь является частью основного пакета, а не отдельной библиотекой LangGraph. Полный changelog опубликован на официальном сайте.
Chain API объявлен deprecated. Полное удаление запланировано на версию 0.6. До конца 2026-го ветка 0.3 продолжает получать security-фиксы, но новых возможностей в ней не будет.
Почему Chain перестала справляться с агентными задачами
Чтобы понять, зачем нужна смена архитектуры, полезно посмотреть на типичный провал Chain-модели. Представьте агента, который должен выяснить, стоит ли выполнять задачу: сначала запросить права у пользователя, потом проверить данные, потом принять решение ветвиться или нет. В Chain-подходе каждый шаг получает на вход сообщение от предыдущего и передаёт сообщение следующему. Если на шаге 2 оказалось, что данные неполные, а нужно вернуться к шагу 1 с другим запросом — Chain не предоставляет для этого никаких примитивов. Разработчик городил обходные конструкции на Python, а отлаживать это было мучительно.
StateGraph предлагает другую модель мышления. Есть явный граф узлов; у каждого узла известен тип входного и выходного состояния; переходы между узлами описываются условиями. Хочешь вернуться на предыдущий шаг — описываешь это как ребро в графе с нужным условием. Хочешь остановиться и спросить пользователя — описываешь это как прерывание с явным типом. Всё видно в структуре графа, а не спрятано в логике внутри узлов.
StateGraph: что меняется в коде
Старая Chain-модель передавала между шагами текстовые сообщения без явной схемы. Это хорошо работало для простых сценариев «запрос — модель — ответ», но для агентных пайплайнов порождало проблему: разработчик не знал, что именно живёт на выходе каждого шага, пока не запустил и не посмотрел. Отладка превращалась в гадание по логам.
StateGraph заменяет это явно типизированным состоянием — TypedDict или Pydantic-схемой, которая описывает структуру данных, передаваемых между узлами. Переходы между узлами тоже описываются явно: можно задать условие, при котором граф идёт в один узел, а не в другой. Это читается и отлаживается несравнимо лучше цепочки без типов.
Встроенная поддержка checkpoint-ов — одно из наиболее практически значимых изменений. Состояние сериализуется после каждого шага; при сбое агента можно перезапустить с последнего успешного чекпоинта, а не с самого начала. Для долгоживущих агентов, выполняющих десятки инструментальных вызовов, это необходимость, а не удобная опция. Без checkpoint-ов агент, упавший на 17-м из 20 шагов, начинает всё сначала, что при дорогих инструментальных вызовах прямо конвертируется в потерянные деньги и время.
Модель инструментов тоже изменилась: Tool теперь полноценный примитив со своей Pydantic-схемой ввода и вывода. Интеграция с tool use API современных моделей — Claude, GPT-5o, Gemini — больше не требует конвертеров и обёрток, написанных под каждый провайдер отдельно.
Что LangSmith получает от новой архитектуры
LangSmith — платформа наблюдаемости от той же команды — становится значительно полезнее при переходе на StateGraph. Когда граф явно типизирован, LangSmith показывает не последовательность событий, а точное состояние на каждом переходе: что было на входе, что получилось на выходе, какой узел активировался следующим. Для команд, которые ловят баги в многошаговых агентах, это принципиально меняет отладку.
Здесь есть и коммерческая логика: переход пользователей на 0.4 увеличивает ценность LangSmith, а значит — косвенный стимул для LangChain поддерживать ещё одну ломающую миграцию понятен. Это не значит, что архитектурное решение неверно — оно технически оправдано. Но осознавать эту связь при оценке скорости следующих breaking changes полезно.
Три стратегии для команд с продакшеном
Команда LangChain выпустила миграционный гайд и автоматический рефакторер на базе libcst. Простые линейные пайплайны конвертируются почти без ручной работы. Сложные случаи — кастомные Chain с переопределённой логикой — потребуют времени и ручной переработки.
Для команд, у которых LangChain встроен в работающий сервис, разумны три подхода. Первый: зафиксироваться на 0.3 и не трогать до тех пор, пока не понадобится новая функциональность — security-поддержка работает до конца 2026-го, этого достаточно для большинства продуктовых циклов. Второй: мигрировать пайплайны по одному, параллельно с разработкой новых фич, используя поддержку двух namespace в одном проекте. Третий — использовать переход как повод для аудита: значительная часть Chain-кода 2023–2024 годов сейчас избыточно сложна и при переходе может быть существенно упрощена. Если ваши пайплайны выглядят как несколько последовательных шагов без ветвлений, возможно, стоит вообще задуматься о переходе на прямые вызовы API без фреймворка — это устраняет один слой абстракции и снижает поверхность сюрпризов при следующем major-обновлении.
Нестабильность или взросление?
Реакция сообщества оказалась сдержанной. Часть команд воспринимает второй major-рефакторинг как сигнал нестабильности и выбирает альтернативы: LlamaIndex для RAG-задач, прямую интеграцию с API для агентной логики. Этот скептицизм не беспочвенен — LangChain менялась быстрее, чем успевала стабилизироваться, и это реальная инженерная проблема для команд, которые за ней следовали.
С другой стороны, 0.4 объективно решает проблемы, которые мешали серьёзной агентной разработке: неявное состояние, отсутствие checkpoint-ов, сложность отладки. Разница между 0.2→0.3 и 0.3→0.4 в том, что прошлая миграция была преимущественно структурной, а эта меняет способ мышления о задаче. Команды, которые уже работали с графовыми моделями — LangGraph в 0.3, Microsoft AutoGen, CrewAI — переход почувствуют как упрощение. Для тех, кто сидел на линейных Chain, придётся перестроить ментальную модель, и это основная часть работы.
Вопрос для каждой команды простой: стоит ли снова платить миграционную цену за библиотеку с историей нестабильности, или дешевле перейти на более предсказуемый стек? Обе позиции рациональны — зависит от того, сколько уже вложено и насколько критичны новые возможности для конкретных задач.