Что на самом деле автоматизирует LangChain после создания цикла агента
Объясняется, как LangChain, LangGraph и подобные SDK-инструменты используют тот же самый основной цикл агента, созданный с нуля, и когда использование фреймворка способствует улучшению работы, а когда мешает.
На этом этапе вы собрали полноценного агента из сырьевых материалов — цикл, память, инструменты, подагенты, хуки — используя исключительно стандартный Anthropic SDK. Никаких фреймворков в виду нет.
Именно сейчас самое время поговорить о фреймворках, потому что сейчас происходит что-то полезное: поскольку вы сами создали весь механизм, ни один фреймворк больше не покажется вам таинственным.
Названия, которые вы постоянно слышите
LangChain. LangGraph. LlamaIndex. CrewAI. AutoGen. The OpenAI Agents SDK.
Каждый из них имеет свою терминологию и собственный способ оформления того, что на самом деле представляет собой одну и ту же основную задачу. Если вы новичок в этой области, огромное количество вариантов может показаться слишком обременительным.
Есть одно понимание, которое разрешает это замешательство:
Каждый из этих фреймворков представляет собой обертку вокруг того же цикла, который вы уже создали ранее в этой серии.
Вот и вся секретность. В них нет никакой скрытой магии. По сути, все они выполняют одну и ту же последовательность: отправляют сообщения, проверяют причину остановки, запускают инструменты и возвращают полученные результаты. Это тот же самый цикл, который вы уже полностью понимаете.
Представьте это как приготовление еды. Как только вы научились готовить блюдо из сырых ингредиентов, вы знаете каждый шаг, можете пробовать и корректировать процесс по ходу, а если что-то не так, вы точно знаете, что изменить. Фреймворк больше похож на набор для приготовления пищи — овощи уже нарезаны, соус заранее смешан, и вам нужно всего лишь собрать все это за несколько минут. Это действительно быстрее. Но если соус получится не таким, вы не сможете его исправить, потому что никогда сами его не готовили и не знаете, что в него входит.
Это та цена, которую предлагает каждая фреймворк-система: вы отдаете часть контроля в обмен на большую скорость.
Увидеть это своими глазами
Давайте рассмотрим тот же агент, реализованный дважды — один раз вручную, а другой раз с помощью фреймворка.
Вот пример того, как выглядит ваш агент при использовании сырого SDK, версии, которую вы теперь полностью понимаете:
messages = [{"role": "user", "content": user_message}]
while True:
# call the API — this runs again every time the model asks for a tool
response = client.messages.create(
model="claude-sonnet-4-6",
tools=tools,
messages=messages,
) # if the model is done, stop
if response.stop_reason == "end_turn":
break # otherwise it asked for a tool: run it, append the result, loop again
messages.append(response_as_message)
messages.append(tool_result_message)
Это именно тот цикл, который был представлен ранее в серии. Запрос к API находится внутри цикла while, потому что он выполняется неоднократно — сначала для получения первого ответа, затем после возвращения каждого результата инструмента — пока модель не сообщит о завершении работы.
Теперь сравните это с примерно таким же агентом, созданным в LangChain:
from langchain.agents import create_agent
agent = create_agent(model="claude-sonnet-4-6", tools=tools)
result = agent.invoke({"messages": [user_message]})
Пять строк вместо тридцати. На первый взгляд это кажется очевидным улучшением.
Но обратите внимание, что исчезло. Цикл больше нет. Проверка на stop_reason также отсутствует. Ручная обработка сообщений устранена. Вся эта логика на самом деле не исчезла — она по-прежнему выполняется, просто спрятана внутри функции create_agent, где её уже нельзя увидеть.
Когда всё идёт гладко, вы экономите время. Когда что-то ломается, вам приходится отлаживать процесс, который невозможно просмотреть.
Именно это напряжение и является сутью фреймворков. Всё остальное — лишь детали, добавленные сверху.
Что вы на самом деле делаете vs что делает фреймворк
Вот то, что часто застаёт людей врасплох. Как только вы начинаете использовать фреймворк, вы больше никогда не смотрите напрямую на stop_reason. Вы больше не проверяете блоки tool_use. Вы больше не вручную добавляете элементы tool_result. Вы вообще больше не пишете циклы.
Вместо этого ваша работа сводится к трём шагам:
- Напишите функции вашего инструмента точно так же, как вы бы это сделали с чистым SDK.
- Зарегистрируйте эти функции у агента с помощью такого кода, как
create_agent(tools=[...]). - Вызовите
agent.invoke(...)один раз.
Вот и весь процесс. Вы подключаете инструменты и запускаете вызов один раз.
За этим единственным вызовом фреймворк тихо выполняет весь цикл, который вы создали ранее: отправляет сообщения, проверяет причину остановки, определяет, что модели нужен инструмент, вызывает вашу функцию, добавляет результат, снова входит в цикл и повторяет этот процесс, пока модель наконец не вернёт end_turn. Только тогда он передаёт вам готовый ответ.
Таким образом, фреймворк не просто скрывает сам цикл — он скрывает весь механизм, который вообще позволяет выполнять вызовы инструментов. Человек, изучающий агентов, начиная с фреймворка, даже не узнает о существовании причин остановки вроде end_turn или о том, что вызовы инструментов решаются через повторные итерации. Для него всё будет выглядеть просто как «Я зарегистрировал инструмент, и он был использован автоматически».
Всё это нормально, пока вызовы инструментов не начнут вести себя некорректно. В такой момент вы оказываетесь перед «чёрным ящиком», потому что никогда не видели работающего под капотом механизма. Вы же сами создали этот механизм своими руками и точно знаете, что внутри происходит.
LangChain, LangGraph — в чём разница?
Вы будете постоянно сталкиваться с этими названиями, поэтому вот краткое объяснение.
LangChain — это сама фреймворк-структура. Он предоставляет определения инструментов, подключения к моделям и функцию create_agent — ту же самую удобную функцию скрытия циклов, о которой шла речь выше.
LangGraph — это более низкоуровневая среда выполнения, на которой построен LangChain. К ней обращаются тогда, когда требуется более точный контроль: приостановка работы агента для утверждения шага человеком, координация логики разветвлений между несколькими агентами или сохранение состояния, чтобы сервер после сбоя мог продолжить работу с того же места.
Простая аналогия: LangChain — это быстрый, высокоуровневый входной пункт. LangGraph — это то, к чему обращаются, когда этого входного пункта недостаточно. С конца 2025 года LangChain был перестроен на основе LangGraph, поэтому эти инструменты больше не являются конкурентами — это два уровня одной системы: простой и мощный.
Если вы только начинаете, вам, скорее всего, пока не нужно ни то, ни другое. Чистый SDK, который вы уже знаете, может помочь вам добиться удивительных результатов.
Когда полезен фреймворк
Фреймворки не являются препятствием по своей сути. В некоторых ситуациях обращение к фреймворку действительно является правильным решением.
Вам нужны готовые интеграции. Предположим, ваш агент должен загружать данные из хранилища векторов Pinecone и получать документы из Google Drive. Написание обоих подключений с нуля с помощью чистого SDK возможно, но это трудоемко. LangChain поставляется с уже готовыми решениями — вам остается только импортировать их и настроить. Это действительно экономит время.
Вы создаете прототип в срочном порядке. Ваш менеджер хочет увидеть рабочую демонстрацию уже завтра утром. В такой ситуации внутренние детали пока не имеют значения — вам просто нужно что-то функциональное как можно быстрее. Пять строк кода могут помочь вам достичь цели уже сегодня вечером.
Вам нужна оркестрация, создание которой действительно сложно. Представьте агента, который приостанавливает выполнение задачи, ждет нажатия кнопки «одобрить», прежде чем осуществить оплату, а затем продолжает работу с того места, где остановился — даже после перезагрузки сервера. Некоторые фреймворки обеспечивают такое поведение из коробки. Воссоздание его с нуля требует значительных инженерных усилий.
Когда фреймворк мешает
Отладка становится сложной. Представьте, что ваш агент время от времени возвращает пустой ответ, и вы не можете понять почему. В коде, написанном вами самими, вы бы добавили оператор вывода, проследили выполнение цикла и нашли проблему в течение нескольких минут. Внутри фреймворка та же ошибка находится где-то в функции create_agent — коде, который не принадлежит вам. В итоге вам приходится изучать исходный код фреймворка на GitHub, чтобы понять, что делает ваш собственный агент.
Абстракция начинает давать сбои. Фреймворки оптимизированы для типовых сценариев. Предположим, вам нужен результат работы инструмента в нестандартном формате или политика повторных попыток, адаптированная под ваши конкретные условия. Фреймворк никогда не предусматривал таких ситуаций. Теперь вам приходится использовать неудобные обходные пути, лишь бы заставить его выполнить то, что тридцать строк собственного кода смогли бы сделать напрямую.
В итоге вы изучаете инструмент, а не саму концепцию. Работа с фреймворком учит вас «как работает LangChain», а не того, как на самом деле функционируют агенты. Затем API LangChain меняется — что с ним и происходит постоянно — и ваши знания мгновенно устаревают. Цикл, рассмотренный ранее в этой серии, не менялся с момента создания агентов и не изменится в будущем.
Правило, которое стоит соблюдать
Начните с чистого SDK. Соберите цикл вручную. Так вы точно будете знать, что делает ваш агент, и сможете отследить каждую строку кода при возникновении проблем. Для большинства агентов этого действительно будет достаточно.
Используйте фреймворк только тогда, когда он лучше решает конкретную задачу, чем вы сами, — готовая интеграция, состояние, сохраняющееся после сбоя, шаги утверждения с участием человека. Используйте его осознанно именно по этой причине, а не как стандартное решение.
Не прибегайте к фреймворку лишь для того, чтобы пропустить изучение цикла. В этом и кроется настоящая ловушка. Пропустив этот шаг, вы получите «черный ящик», построенный на идеях, которые вы на самом деле не усвоили.
Сначала разберитесь с циклом. После этого фреймворк станет инструментом, который вы выберете осознанно — а не опорой, на которую полагаетесь из-за отсутствия знаний основ.
Почему в этой серии всё создавалось с нуля
Именно по этой причине мы откладывали использование фреймворков до сих пор.
Если бы эта серия начиналась с инструкций вроде «установите LangChain, вызовите create_agent», у вас был бы рабочий агент, но без реального понимания его работы. Вы бы не знали, что такое блок tool_use, почему результаты параллельных вызовов инструментов собираются в одно сообщение, или почему логика авторизации находится в хуке.
Теперь, когда у вас уже есть эта основа, словарный запас любой фреймворка можно мгновенно понять. То, что он называет «агентом», на самом деле представляет собой ту же самую внутреннюю циклическую структуру. То, что он называет «памятью», — это просто список сообщений, с которыми вы уже знакомы. То, что он обозначает как «инструменты», напрямую соответствует блокам tool_use, с которыми вы работали вручную. А то, что он рекламирует как «мидлвэр», — это просто другое название для хуков, которые вы сами создали.
Именно такое положение стоит иметь. Не «Я знаю LangChain», а «Я понимаю, как работают агенты, и LangChain — это лишь один из способов этого выразить».
Фреймворки будут продолжать развиваться. Каждые несколько месяцев появляются новые версии. Однако внутренняя структура остается неизменной. Сформируйте свои знания на основе той части, которая не меняется.
Связанные материалы
- Чатботы против ИИ-агентов: что на самом деле отличает их помимо LLM — Узнайте, почему истинная разница между чатботами и ИИ-агентами заключается в архитектуре окружающей системы — инструментах, планировании и действиях, а не в самом LLM.
- Понимание ИИ-агентов: цели, инструменты, память и цикл действий агента — Простое объяснение для начинающих того, чем ИИ-агенты отличаются от чатботов, включая основные компоненты, цикл принятия решений, уровни автономии и практические примеры использования.