Архитектура AI-агентов: Глубокое погружение в LangChain и LangGraph

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

Для Python-разработчика переход к работе с LLM требует изменения мышления. Языковые модели недетерминированы, они возвращают непредсказуемый текст, а не строгие структуры данных. Архитектура LangChain создана для того, чтобы обуздать эту хаотичную природу, превратив stochastic parrots (стохастических попугаев) в надежные вычислительные движки для бизнес-процессов.

Уровень абстракции: Модели и Промпты

Первая архитектурная проблема, с которой сталкивается разработчик AI-приложений — это жесткая привязка к поставщику (vendor lock-in). API OpenAI отличается от API Anthropic, а локальные модели через Ollama имеют свой собственный синтаксис.

LangChain вводит единый интерфейс для всех языковых моделей. В терминах фреймворка существует два основных класса:

LLMs — модели, принимающие строку и возвращающие строку (классическое автодополнение).

Chat Models — модели, принимающие список сообщений (роли: система, пользователь, ассистент) и возвращающие сообщение.

Вместо того чтобы хардкодить текстовые запросы, LangChain использует промпт-шаблоны (Prompt Templates). Это не просто f-строки в Python, а объекты, которые управляют валидацией входных данных и форматированием контекста.

> Промпт-шаблон — это рецепт генерации запроса, который отделяет логику формирования инструкций от пользовательского ввода.

Представьте, что вы автоматизируете анализ отзывов. Без шаблонизации вам пришлось бы каждый раз склеивать строки вручную. С LangChain вы создаете шаблон с переменной review_text, и фреймворк сам заботится о безопасной подстановке данных. Если в будущем вы решите сменить модель GPT-4 на Claude 3, вам потребуется изменить ровно одну строку кода — импорт класса модели. Вся остальная логика останется нетронутой.

Архитектура конвейера и LCEL

Сердце современного LangChain — это LCEL (LangChain Expression Language). Это декларативный способ сборки компонентов в единый конвейер (пайплайн).

Вместо написания процедурного кода, где результат одной функции передается в другую, LCEL использует перегруженный оператор | (pipe) в Python, заимствуя концепцию из Unix-систем. Данные текут слева направо, автоматически трансформируясь на каждом этапе.

Типичная цепочка выглядит так:

!Архитектура базовой цепочки LangChain

Каждый элемент в этой цепи реализует интерфейс Runnable. Это означает, что любая цепочка автоматически поддерживает синхронный вызов (invoke), асинхронный вызов (ainvoke), потоковую передачу токенов (stream) и пакетную обработку (batch).

Парсеры вывода (Output Parsers) играют здесь критическую роль. LLM всегда возвращает текст. Но для автоматизации бизнес-процессов нам нужен JSON, списки или объекты Python. Парсер берет сырой текст от модели, извлекает из него нужную структуру (например, с помощью регулярных выражений или JSON-декодера) и передает дальше по цепочке.

Допустим, вы извлекаете сущности из договора. Модель вернула строку: "{"company": "ООО Ромашка", "amount": 500000}". Парсер вывода автоматически преобразует эту строку в валидный Python-словарь. Если модель ошиблась в синтаксисе, продвинутые парсеры LangChain могут автоматически отправить запрос на исправление (auto-fixing).

Управление состоянием: Иллюзия памяти

Фундаментальное свойство любой LLM — это stateless-архитектура (отсутствие состояния). Модель не помнит ваш предыдущий запрос. С математической точки зрения, каждый вызов модели — это изолированная функция:

Где — это текущий промпт, — языковая модель, а — сгенерированный ответ.

Чтобы создать чат-бота с долгосрочной памятью, мы должны искусственно внедрять историю диалога в каждый новый запрос. Формула преобразуется:

Где — это накопленная история сообщений (Chat History).

LangChain предоставляет модули Памяти (Memory), которые автоматизируют этот процесс. Самый простой вариант — ConversationBufferMemory, который просто сохраняет все реплики и вставляет их в промпт.

Однако здесь возникает физическое ограничение — контекстное окно (Context Window). Это максимальное количество токенов (слов или частей слов), которое модель может обработать за один раз. Если история диалога превысит этот лимит, API вернет ошибку, а деньги за токены будут потрачены впустую.

!Интерактивная демонстрация переполнения контекстного окна

Для решения этой проблемы архитектура LangChain предлагает более сложные виды памяти:

Buffer Window Memory: хранит только последние сообщений (например, ).

Summary Memory: использует саму LLM для периодического сжатия старых сообщений в краткое резюме.

Vector Store-Backed Memory: сохраняет историю в векторную базу данных и извлекает только те прошлые реплики, которые семантически связаны с текущим вопросом пользователя (основа для RAG-систем).

Инструменты: Даем ИИ "руки"

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

Чтобы преодолеть эту изоляцию, LangChain вводит концепцию Инструментов (Tools). Инструмент — это Python-функция, обернутая в специальное описание, которое понятно языковой модели. Описание включает название инструмента, его назначение и схему входных аргументов.

Когда мы подключаем инструменты к модели, мы перестаем использовать ее просто как генератор текста. Мы начинаем использовать LLM как движок рассуждений (reasoning engine).

Процесс выглядит так:

Пользователь задает вопрос: "Какая выручка была у клиента X в прошлом месяце?"

Модель анализирует вопрос и понимает, что ей не хватает данных.

Модель просматривает список доступных ей Инструментов и находит get_client_revenue(client_id, month).

Вместо текстового ответа пользователю, модель генерирует JSON с запросом на вызов этого инструмента.

LangChain перехватывает этот запрос, выполняет реальную Python-функцию (например, делает SELECT в базу данных).

Результат выполнения функции возвращается обратно в модель.

Модель читает результат и формирует финальный ответ пользователю на естественном языке.

Именно в этот момент простая цепочка превращается в Агента (Agent). Агент — это система, в которой LLM сама принимает решения о том, какие действия совершить, в каком порядке, и когда задача считается выполненной.

Однако стандартные агенты LangChain имеют архитектурный предел. Они работают как цикл while, который крутится, пока модель не скажет "я закончила". В реальных бизнес-процессах нам часто нужен строгий контроль: циклы с условиями, обработка ошибок, участие человека для подтверждения критических действий (Human-in-the-loop) и ветвление логики.

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