Недавно мы рассказывали о RAG — подходе, который позволяет языковой модели отвечать с опорой на внешние документы. То есть перед генерацией ответа программа находит подходящие фрагменты текста и добавляет их в контекст запроса. Например, помощник интернет-магазина может найти характеристики товара в каталоге и точно ответить на вопрос покупателя.
Чтобы такой помощник заработал, вам нужно собрать цепочку из нескольких этапов: загрузить каталог товаров, привести его к удобному виду, настроить поиск по каталогу и научиться извлекать оттуда нужные фрагменты информации под конкретный вопрос. При этом все компоненты должны правильно взаимодействовать друг с другом. А если вы захотите, чтобы помощник запоминал диалог, проверял наличие товаров или обращался к другим сервисам (CRM, склад, доставка), придется написать еще больше связующего кода.
Именно здесь пригодится фреймворк LangChain. Он служит прослойкой между языковой моделью и остальной частью приложения: помогает подключать данные и инструменты так, чтобы вам не приходилось вручную писать много кода для их совместной работы. В статье мы разберем, что такое LangChain, как он работает и для чего нужен, а также сравним его с другими инструментами для разработки ИИ‑приложений — LangGraph, LangSmith и Langflow. А в конце будет немного практики, где вы сможете собрать простого ИИ‑агента на Python.
Что такое LangChain и для чего он нужен
На официальном сайте LangChain представлен как open-source‑фреймворк, который предлагает готовые архитектуры агентов и интеграции с разными моделями и инструментами. Получается своего рода конструктор: вы выбираете подходящие блоки, настраиваете их и соединяете в готовое ИИ‑приложение. Например, сначала агент может только отвечать по базе знаний. Если позже ему понадобится проверять статус заказа, вы можете подключить новый инструмент для работы с CRM или складом — перестраивать все приложение не придется.
Название LangChain образовано от английских слов «Lang» — сокращения от language («язык») — и «Chain» («цепочка»). Поэтому его можно условно попробовать перевести как «цепочки для языковых моделей». Под цепочкой здесь понимается последовательность операций, в которой модель соединяется с промптами, данными, программными функциями и прочими компонентами.
Для наглядности давайте схематично представим помощника интернет‑магазина из нашего введения к этой статье и разберем последовательность его шагов:
Как видите, система устроена как конвейер: каждый этап принимает результат предыдущего и передает его дальше — так формируется цепочка. При этом LangChain сам по себе не ищет товары в каталоге и не генерирует ответ вместо модели. Он лишь организует процесс и связывает все компоненты приложения так, чтобы данные и запросы проходили по нужным шагам без лишнего кода.
И вот на создание таких линейных цепочек LangChain был ориентирован в первые годы после запуска в 2022 году. Сегодня его основное направление — создание ИИ-агентов, которые могут самостоятельно выбирать следующее действие. Например, помощник интернет-магазина может найти информацию о товаре в каталоге, проверить статус заказа в CRM или ответить сразу. Получив результат, агент решает, достаточно ли этих данных для ответа или нужно обратиться к другому инструменту. Посмотрите, как это выглядит на схеме:
В отличие от линейной цепочки, здесь последовательность шагов заранее не задана. При этом LangChain организует весь цикл работы агента: помогает передавать модели доступные инструменты, выполнять выбранные действия и возвращать их результаты, чтобы агент мог принять решение о следующем шаге.
Разработчики и продуктовые команды используют LangChain в проектах, где одного запроса к модели недостаточно и ей нужно взаимодействовать с данными или внешними сервисами. С его помощью создают консультантов для техподдержки, помощников для работы с документами, системы для поиска и анализа информации, инструменты для обработки текстов, а также агентов для автоматизации рабочих процессов. И это лишь часть возможных сценариев.
Из каких компонентов состоит LangChain и как они взаимодействуют
LangChain — модульный фреймворк, а не готовое приложение с единственной архитектурой. Он предлагает совместимые блоки, а разработчик выбирает их под задачу: для простой обработки текста могут быть нужны только модель и инструкция, а для полноценного агента — еще инструменты, доступ к данным, память и контроль выполнения. Но если выделять основные компоненты, то к ним относят: модель, сообщения и промпт, инструменты, поиск по данным, агент, состояние и память, промежуточный слой и структурированный ответ.
Модель. Это основной компонент, который анализирует запрос и контекст, генерирует текст и принимает решения. В агенте модель определяет, может ли она ответить сразу или нужно воспользоваться одним из инструментов. LangChain предоставляет общий интерфейс для моделей разных провайдеров — GPT от OpenAI, Claude от Anthropic, Gemini от Google и многих других.
Промпт и сообщения. Перед каждым обращением к модели LangChain формирует контекст. С помощью промпта разработчик задает постоянные инструкции — например, роль помощника или доступные действия. Сообщения передают информацию, которая появляется во время работы: это может быть вопрос пользователя, результаты вызова инструментов и прочее. Получается, промпт определяет общие правила, а сообщения описывают текущую ситуацию, на основе которой модель готовит ответ или выбирает следующее действие.
Инструменты. Это функции, через которые агент может получать внешние данные или выполнять действия: например, искать по документации, обращаться к базе данных, CRM, калькулятору или другому сервису. Когда пользователь задает вопрос, модель решает, нужно ли ей сначала вызвать какой‑то инструмент, выбирает его и передает ему нужные аргументы. После этого приложение выполняет функцию и возвращает результат обратно модели.
Поиск по данным. Это компонент, который находит информацию во внешних источниках и добавляет ее в контекст модели. Он нужен, например, в RAG‑системах для работы с корпоративными документами или каталогом товаров. В агенте поиск можно подключить как один из доступных инструментов.
Агент. Если модель анализирует запрос и принимает решения, то агент — это система, которая помогает ей выполнить задачу. Он объединяет модель с промптом и инструментами, вызывает функции и возвращает их результаты. Если все шаги заранее известны и не требуют выбора, отдельный агент не нужен.
Состояние и память. Состояние позволяет хранить сообщения и промежуточные результаты внутри текущего запуска. Краткосрочная память помогает продолжать диалог в рамках одной сессии, а долгосрочная — сохранять сведения между разными сессиями. Например, если пользователь сначала выбрал ноутбук, а затем спросил: «Сколько он стоит?», краткосрочная память поможет понять, о каком товаре идет речь. Долгосрочная память может сохранить предпочтения пользователя и учесть их при следующем обращении.
Промежуточный слой. В LangChain его называют middleware — в переводе «промежуточное программное обеспечение». Это дополнительная логика, которая подключается к отдельным этапам работы агента и проверяет или изменяет происходящее до и после обращения к модели. Например, она может ограничивать число шагов, обрабатывать ошибки, скрывать часть данных, вести технические записи или запрашивать подтверждение перед важным действием.
Структурированный ответ. Обычно модель отвечает свободным текстом и выдает что-то вроде: «Ноутбук стоит 80 тысяч рублей и относится к игровой категории». Однако если эти сведения нужно сохранить или передать другой программе, разработчик задает строгую схему с отдельными полями: название, цена, категория. LangChain помогает получить ответ в таком формате и проверить, что модель заполнила все необходимые поля. Затем данные можно записать в таблицу, показать в интерфейсе или отправить другому сервису.
Если объединить перечисленные компоненты, то это может выглядеть так:
Конечно, подключать сразу все компоненты необязательно. Их набор определяется не ограничениями LangChain, а задачами вашего приложения. Так, простому генератору текста может быть достаточно модели и промпта, а помощнику, который работает с документами и внешними сервисами, понадобятся поиск, инструменты, память и механизмы контроля. В этом и есть преимущество модульного подхода: разработчик начинает с минимального набора и затем добавляет новые компоненты по мере усложнения проекта.
Чем отличаются LangChain, LangGraph, LangSmith и Langflow
До этого в статье мы говорили только про LangChain, поскольку это основной высокоуровневый фреймворк для создания ИИ-агентов и приложений с языковыми моделями. Однако по мере роста проекта вам могут понадобиться дополнительные решения: для сложных агентов — более точное управление маршрутом выполнения, для разработки — отладка и оценка качества, а для быстрого прототипирования — визуальная среда. Для этих задач есть три инструмента с похожими названиями: LangGraph, LangSmith и Langflow.
LangGraph. Это более низкоуровневый фреймворк и среда выполнения для сложных агентов, которые работают с состоянием. Вместо линейной последовательности шагов процесс в нем представляют как граф, где каждый узел — конкретное действие, а связи — правила переходов между действиями. Такой подход нужен, когда в сценарии есть ветвления, повторные попытки, длинные задачи, паузы или шаги, где требуется подтверждение человека.
Например, агент по оформлению возврата может проверить заказ, запросить недостающие данные и, при необходимости, передать спорный случай сотруднику, а после его одобрения продолжить процесс с того же шага.
При этом агенты LangChain уже используют LangGraph внутри. В типовых сценариях разработчику не нужно работать с графом напрямую — достаточно архитектуры LangChain. К LangGraph обращаются, когда нужно вручную настроить ветвления, паузы, состояние и другие особенности сложного процесса.
LangSmith. Это платформа для отладки, тестирования и наблюдения за ИИ‑приложениями. Она записывает так называемую трассу выполнения: какие запросы получила модель, какие инструменты выбрал агент, что они вернули, сколько времени заняли шаги и где возникла ошибка. За счет этого разработчик видит не только итоговый ответ, но и весь путь, который к нему привел.
LangSmith также позволяет собирать тестовые наборы, сравнивать модели и промпты, оценивать качество ответов и следить за приложением после запуска. Например, команда может взять набор типовых пользовательских вопросов, прогнать их со старым и новым промптом, сравнить ответы и заодно посмотреть метрики: среднее время ответа и стоимость запроса. Так можно понять, стала ли новая версия отвечать точнее и не выросли ли при этом задержка и стоимость.
Хотя LangSmith тесно интегрирован с LangChain и LangGraph, его можно использовать и с приложениями на других фреймворках. Например, в одной системе ваш пользовательский консультант может быть собран на LangChain, а отдельный сервис для анализа документов — на CrewAI, PydanticAI, Vercel AI SDK или даже реализован напрямую через API модели. Оба компонента можно подключить к LangSmith и в одном интерфейсе смотреть, как они работают.
Langflow. Это отдельная платформа с визуальным редактором, которая по принципу сборки процессов напоминает n8n: вы размещаете модель, промпт, источник данных, инструменты и другие компоненты на рабочем холсте, а затем соединяете их линиями. Разница в том, что Langflow специализируется на ИИ‑приложениях и RAG‑системах, а n8n — более универсальная платформа: с ее помощью можно синхронизировать данные между CRM и таблицами, обрабатывать заявки, формировать отчеты и связывать различные сервисы.
Langflow удобно использовать для прототипирования: например, чтобы быстро создать чат-бота по документам, RAG‑помощника, агента с несколькими инструментами или процесс для сравнения моделей и промптов. Если сценарий выходит за пределы ИИ‑приложения, Langflow можно дополнить платформой n8n. При дальнейшем развитии проекта агентную логику можно реализовать с помощью LangChain или другого фреймворка, а процессы из Langflow и n8n подключить к агенту как внешние инструменты через API или протокол MCP.
Как создать простого ИИ-агента с помощью LangChain на Python
В этом разделе мы создадим ИИ‑агента, который будет получать вопрос, выбирать инструмент, получать из него данные и использовать их для ответа. Пример простой, однако он хорошо показывает базовый цикл работы агента.
Если на вашем компьютере установлен Python, вы можете выполнять пример в привычном редакторе кода. Но если нет, рекомендуем воспользоваться Google Colab — онлайн‑сервисом, который позволяет запускать Python прямо в браузере без установки дополнительных программ. Достаточно войти в аккаунт Google, создать новый блокнот и затем последовательно выполнять код в его ячейках.
Шаг 1. Устанавливаем LangChain и добавляем API-ключ
Так как мы будем использовать модели OpenAI, сначала установим LangChain и соответствующий пакет интеграции. Вставьте в первую ячейку вот эту команду:
!pip install -qU langchain "langchain[openai]"
Если вы планируете использовать модель другого провайдера, замените langchain[openai] в команде установки на пакет нужной интеграции. Например, для Claude используйте langchain-anthropic, а для Gemini — langchain-google-genai. Подробности читайте в официальной документации.
Далее вам нужно запустить ячейку и дождаться, пока Colab установит LangChain и пакет для работы с моделями OpenAI. После этого в левой части Colab откройте раздел Secrets. Создайте секрет с именем OPENAI_API_KEY, вставьте в него сгенерированный API‑ключ OpenAI и включите для него доступ из блокнота.
Когда ключи созданы — добавьте новую ячейку и выполните код:
import os
from google.colab import userdata
os.environ["OPENAI_API_KEY"] = userdata.get("OPENAI_API_KEY")
Код будет получать ключ из защищенного хранилища Colab и сохранять его в переменной окружения. Благодаря этому сам ключ не отображается в блокноте — это важно для безопасности. Если у вас возникнут вопросы, рекомендуем посмотреть статью про RAG, где мы этот процесс более подробно расписывали. А если вы раньше не получали API‑ключ, загляните в статью про текстовый редактор Obsidian, где мы как раз настраивали интеграцию для моделей OpenAI.
Шаг 2. Создаем инструмент с ценами и собираем агента
Теперь создадим агента‑помощника по покупке билетов. Сначала опишем функцию get_ticket_price, которая хранит наши цены и возвращает стоимость одного билета до выбранного города. Затем передадим эту функцию агенту как инструмент и явно укажем модели, что цены нельзя выдумывать. Когда пользователь спросит о стоимости, агент поймет, что для ответа нужно вызвать инструмент, получит из него цену и использует ее для расчета.
Чтобы все это реализовать, добавьте следующий код в новую ячейку:
from langchain.agents import create_agent
def get_ticket_price(city: str) -> str:
"""Возвращает цену одного билета до указанного города."""
prices = {
"москва": 3500,
"санкт-петербург": 4200,
"казань": 4500,
"самара": 3800,
"пермь": 5200,
"екатеринбург": 6000,
"сочи": 7000,
"новосибирск": 8500,
}
price = prices.get(city.lower())
if price is None:
return "Для этого города цена не найдена."
return f"Один билет до города {city} стоит {price} рублей."
agent = create_agent(
model="openai:gpt-5.4-mini",
tools=[get_ticket_price],
system_prompt=(
"Ты помощник по покупке билетов. "
"Используй инструмент, когда нужно узнать цену. "
"Не выдумывай цены и отвечай по-русски."
),
)
Мы создали словарь prices и вручную задали цены для восьми городов. Названия записаны со строчной буквы, потому что перед поиском метод city.lower() приводит введенное пользователем значение к тому же виду. В реальном сервисе это функция могла бы получать актуальные цены через API билетной системы или из базы данных. Но для учебного примера достаточно статических значений — так мы сможем не усложнять проект подключением внешнего сервиса.
И еще момент: при подготовке статьи GPT‑5.4 mini считается актуальной компактной моделью, которая поддерживает вызов инструментов. Если к моменту чтения она станет недоступна или устареет, замените ее идентификатор на название другой доступной модели OpenAI с поддержкой инструментов.
Шаг 3. Запускаем агента и получаем ответ
Теперь нам осталось проверить агента. Для этого добавьте ячейку и вставьте в нее последний фрагмент кода. В нем метод agent.invoke принимает список сообщений: мы передаем одно сообщение с ролью user и текстом вопроса. Агент обработает запрос, вызовет инструмент get_ticket_price и сформирует ответ.
result = agent.invoke(
{
"messages": [
{
"role": "user",
"content": "Сколько стоят два билета в Казань?",
}
]
}
)
print(result["messages"][-1].content)
После выполнения кода вы получите примерно такое сообщение:
Один билет до Казани стоит 4500 рублей, значит два билета — 9000 рублей.
Такой запуск может включать несколько коротких обращений к модели: агенту нужно выбрать инструмент, получить от него результат и уже на его основе подготовить ответ. Но не переживайте, ведь при использовании недорогой модели подобный эксперимент расходует незначительную часть API‑баланса. Например, до запуска у нас было 3,7 доллара — и столько же осталось после, ведь весь запрос обошелся дешевле 0,01 доллара и уложился где-то в 440 токенов.
Если захотите попрактиковаться, попробуйте развить пример самостоятельно. Для начала замените учебный словарь с ценами на обращение к реальному API или базе данных, а затем постепенно добавляйте агенту новые возможности: инструмент для проверки наличия билетов, поиск подходящих рейсов, память о выбранном городе и датах, получение данных из CRM или системы бронирования и подтверждение от пользователя перед оформлением заказа.
