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

Выбор влияет на стоимость владения, а не на «умность» агента. Модель делает одно и то же при любом фреймворке; разница в том, как вы будете отлаживать цепочку шагов, сохранять её ход и менять модель через год. Что такое агент и чем он отличается от чат-бота, описано в статье «Чем ИИ-агент отличается от чат-бота», здесь только инструменты.

Коротко. Начинайте с самого простого: цикл вызовов модели и инструментов на вашем коде. Берите LangGraph, когда понадобятся состояние, паузы на человека и восстановление. LangChain берите точечно, ради адаптеров. Любой вариант проверяйте на эталонных ситуациях заказчика, а не на демонстрации.

Три варианта и что за каждым стоит

Всё перечисленное — библиотеки обвязки. Они не делают модель умнее, а определяют, как вы организуете шаги, инструменты, память и ошибки.

ВариантЧто даётЧем платитеКогда подходит
Прямые вызовы модели и свой кодПолный контроль над циклом: вы сами решаете, что отправить модели, как разобрать ответ и какой инструмент вызвать. Минимум зависимостейСостояние, повтор после сбоя, паузы на человека и журнал вы пишете самиКороткий сценарий, несколько инструментов, команда, которая умеет поддерживать свой код
LangChainГотовые адаптеры к десяткам моделей, векторных хранилищ и загрузчиков документов; единый интерфейс вызоваМного уровней абстракции, интерфейсы менялись от версии к версии, стек вызовов трудно читать при отладкеНужно быстро попробовать разные модели и хранилища, прототип, разовые обработки документов
LangGraphАгент как граф: узлы-шаги, ветвления, общее состояние, сохранение хода и пауза до ответа человекаНадо описывать граф заранее и сопровождать его вместе со схемой состояния; ещё одна зависимостьДлинный процесс с ветками, подтверждения человеком, возобновление после сбоя, несколько ролей в одном процессе
Другие фреймворки для агентовУ каждого своя модель: роли и переговоры агентов, шаблоны для поиска по документам, интеграции с платформамиМеньше людей знают инструмент, выше риск, что поддержка прекратится или правила изменятсяЕсли фреймворк уже принят в компании и под него есть обученные люди

LangGraph создан авторами LangChain и может использоваться с его адаптерами, а может без них. Поэтому вопрос «одно из двух» часто ставят неверно: можно взять граф для хода агента и написать собственные тонкие вызовы модели.

Пять вопросов, которые решают выбор

Ответьте на них для вашей задачи до того, как открывать документацию фреймворка. Ответ «нет» на все пять означает, что фреймворк вам пока не нужен.

ВопросЕсли «нет»Если «да»
Агент работает дольше одной минуты или ждёт внешних событий?Цикл выполняется в одном запросе, состояние живёт в памяти процессаНужно сохранять ход в базе: иначе перезапуск сервера обрывает работу. Это довод за LangGraph или собственную таблицу состояний
Есть ли ветки, где путь зависит от результата шага?Линейная цепочка шагов, достаточно обычного кодаОписывайте ветки явно (граф или конечный автомат), а не просьбой к модели «решить самой»
Нужно ли ждать человека между шагами?Агент отвечает сразу и действий не совершаетНужна пауза на подтверждение и возобновление через часы. Это самое сильное основание для графа с сохранением хода
Меняются ли модели и хранилища?Модель зафиксирована на весь срок проектаЕдиный интерфейс вызова нужен. Его дают LangChain, но можно написать свой тонкий слой на сотню строк
Работает ли агент в закрытом контуре?Облачные сервисы допустимы, зависимости ставятся из публичного репозиторияКаждая зависимость идёт через ваше зеркало пакетов и проверку лицензий; чем меньше библиотек, тем проще приёмка и обновления

Что такое агент в коде и почему без фреймворка это возможно

Ядро любого агента — цикл. Фреймворк его не отменяет, он только оборачивает:

  1. Собрать запрос: задача, история, описания инструментов.
  2. Спросить модель, что делать: ответить или вызвать инструмент.
  3. Если инструмент: проверить права, выполнить, записать результат в журнал.
  4. Добавить результат в историю и вернуться к шагу 2. Остановиться, когда модель дала итог или превышен лимит шагов.

На своём коде этот цикл занимает небольшой модуль. Сложность появляется не в цикле, а вокруг него: сколько шагов можно делать, что при сбое инструмента, как не выполнить действие дважды, как показать человеку, что произошло. Эти задачи остаются у вас при любом выборе. Фреймворк закрывает часть из них (граф и сохранение хода), но не правила доступа и не оценку качества.

Что фреймворк закрывает, а что остаётся вам

Самая частая ошибка выбора: считать, что фреймворк даёт безопасность и качество. Он даёт структуру. Защита и проверка пишутся в любом случае.

ЗадачаЧто может дать фреймворкЧто остаётся вам
Права инструментовНичего: инструмент вызывает то, что вы ему разрешилиОтдельная учётная запись агента с минимальными правами, список действий, подтверждения, см. «Как ограничить ИИ-агента»
Повторный вызов без дублейСохранение хода позволяет продолжить, но не делает действие безопасным для повтораКлючи идемпотентности в запросах к CRM и 1С, проверка «уже сделано»
Пауза на человекаГраф с точкой остановки и возобновлениемИнтерфейс подтверждения, срок ожидания, правило «что делать, если никто не ответил»
Журнал и трассировкаВывод шагов в отладочном видеЖурнал без лишних персональных данных, хранение на ваших серверах, срок хранения
Оценка качестваПомощь в запуске прогона по набору примеровЭталонные ситуации заказчика, критерий приёмки, регулярный прогон при каждом изменении модели и шаблонов
Лимиты и стоимостьОграничение числа шагов рекомендуется, но задаётся вамиЛимит шагов, бюджет запросов на пользователя, остановка по аномалии

Эти же части описаны в статье «Архитектура LLM-приложения». Если на этот список у проекта нет ответов, выбор фреймворка преждевременен.

Риски, которые чаще всего проверяют слишком поздно

  • Изменчивость интерфейсов. Библиотеки для работы с моделями развиваются быстро, и код с одной версии может не запуститься на другой. Закрепляйте версии, читайте журнал изменений перед обновлением и держите обновление отдельной задачей.
  • Глубина стека. Через несколько слоёв абстракции трудно увидеть, какой запрос на самом деле ушёл к модели. Для отладки нужен вывод итогового запроса и ответа, это проверяется до выбора.
  • Облачные сервисы вокруг. У авторов фреймворков есть облачные платформы для трассировки и запуска. Это отдельные продукты: они получают тексты запросов и ответов, и для данных ограниченного доступа по требованиям заказчика они чаще не подходят. Трассировку в закрытом контуре можно вести своим журналом.
  • Зависимости в закрытом контуре. Пакеты ставятся через внутреннее зеркало, у каждого своя лицензия и свои вложенные зависимости. Проверьте дерево зависимостей заранее и сверьтесь с требованиями к отечественному ПО, см. «Реестр отечественного ПО».
  • Привязка к одному поставщику моделей. Если код написан под особенности одного интерфейса, смена модели затронет весь проект. Вызовы модели прячьте за своим тонким интерфейсом, это нужно независимо от выбора.
  • Нехватка людей. Если после ухода автора никто не знает фреймворк, поддержка превращается в переписывание. Проверьте, сколько часов уйдёт на то, чтобы новый разработчик разобрался в графе.

Как выбрать за один день: сравнение на вашей задаче

Не выбирайте по обзорам. Возьмите один реальный сценарий и соберите его дважды: на прямых вызовах и на выбранном фреймворке. Сравнивать нужно на одних и тех же эталонных ситуациях.

Что взять для проверки

  • Один сценарий с реальной веткой и реальным инструментом (на тестовой копии ваших систем).
  • Десять-двадцать эталонных ситуаций с известным правильным результатом, среди них две-три, где агент должен отказаться или спросить человека.
  • Один искусственный сбой: инструмент не отвечает на третьем шаге.

По каким критериям сравнивать

КритерийЧто смотримЧто считаем плохим знаком
ЧитаемостьМожет ли разработчик, не писавший код, объяснить ход шагов за полчасаНужно читать исходники фреймворка, чтобы понять свой же сценарий
Результат на эталонеСколько ситуаций решено верно и как ведёт себя агент в отказныхРазница между вариантами заметна не по качеству, а по случайности запуска
Поведение при сбоеПродолжается ли работа с места остановки, нет ли двойного выполнения действияПосле перезапуска агент начинает заново и повторяет действие
Видимость запросаМожно ли увидеть итоговый текст, ушедший моделиПриходится подключать отдельный облачный сервис
Объём чужого кодаСколько библиотек добавилось в проект и каковы их лицензииДесятки вложенных зависимостей ради одного адаптера

Если оба варианта ведут себя одинаково, выбирайте тот, что проще поддерживать вашей командой. Если граф выигрывает по сбоям и паузам, а прямой код по читаемости, возможна комбинация: граф для хода, свой тонкий слой для вызовов.

Один агент, несколько агентов и роль фреймворка

Мультиагентные схемы часто подают как довод за конкретный фреймворк. Это перепутанные причины. Несколько агентов нужны, когда у ролей разные права, разные инструменты или разный уровень доверия, а не потому, что в библиотеке есть такой режим. Чаще достаточно одного агента с понятным набором инструментов и явных шагов. Когда нескольких действительно нужно, это решается архитектурой и правами, фреймворк лишь упрощает запись. Подробнее на странице «Мультиагентные ИИ-системы» и в статье «Мультиагентные системы: когда хватает одного агента».

Общая рамка внедрения агента, от выбора процесса до приёмки, описана в статье «Как внедрить AI-агента и не потерять данные».

Что делаем мы и с чего начать

Фреймворк не выбираем заранее: это решение записывается в документе обследования вместе с причинами. Обследование стоит 200 000 ₽ за один-два процесса (2–3 недели) или 350 000 ₽, если агент работает с несколькими системами (3–4 недели). На выходе схема шагов агента, список инструментов и прав, эталонные ситуации, выбор обвязки с доводами и вилка бюджета. Стоимость вычитается из первого этапа, если продолжаете с нами.

Дальше лёгкий пилот (150 000–400 000 ₽, 2–8 недель) или тяжёлый (400 000–1 200 000 ₽, 2–3 месяца), и на любой ступени можно остановиться. Обвязку делаем тонкой, чтобы её можно было заменить, а исходники лежат в вашем репозитории с первого коммита. Мы не привязываемся к одному фреймворку и не продаём собственную платформу агентов. Все цены и сроки — на странице «Тарифы», описание услуги — на странице «Мультиагентные ИИ-системы».

Частые вопросы

LangChain или LangGraph: что выбрать для первого агента?

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

Можно ли делать агентов без фреймворка?

Да. Ядро агента — цикл из вызова модели, проверки прав и вызова инструмента. Фреймворк упрощает сохранение хода и ветвление, но не заменяет права, журнал и оценку качества. Для короткого сценария собственный код проще поддерживать.

Работают ли LangChain и LangGraph в закрытом контуре?

Сами библиотеки открыты и могут работать с моделями на ваших серверах. Проблемы возникают вокруг них: зависимости, которые ставятся из зеркала пакетов с проверкой лицензий, и облачные сервисы трассировки, куда уходят тексты запросов. Для данных ограниченного доступа такие сервисы чаще всего не подходят по требованиям заказчика.

Сильно ли выбор фреймворка влияет на качество ответов?

Нет, качество определяют модель, данные, шаблоны запросов и проверки. Фреймворк влияет на то, как удобно отлаживать и сопровождать агента. Сравнивать варианты по качеству нужно на эталонных ситуациях заказчика, а не по обзорам.

Как не привязаться к одному фреймворку?

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

Сколько стоит разработка ИИ-агента на таком фреймворке?

Цена не зависит от фреймворка напрямую. Обследование стоит 200 000 ₽ (350 000 ₽ при нескольких системах), лёгкий пилот 150 000–400 000 ₽, тяжёлый 400 000–1 200 000 ₽, вывод в эксплуатацию от 1 500 000 ₽ этапами по 300 000–700 000 ₽. Больше всего цену двигают права, подтверждения и число систем.

Когда стоит взять мультиагентную схему?

Когда у ролей разные права или инструменты, либо когда шаги можно проверять независимо. Если всё делает один набор инструментов с одним уровнем доверия, хватает одного агента. Режим «несколько агентов» в библиотеке сам по себе не довод.

Кому принадлежит код агента, если мы выбрали фреймворк с открытым кодом?

Вам. Исходный код сценариев и обвязки лежит в вашем репозитории и передаётся по акту; порядок передачи прав записывается в договоре. Открытые библиотеки остаются под своими лицензиями, их список с версиями входит в документацию.