Инструменты

Фреймворки для AI-агентов: что выбрать и как не попасть в зависимость

Фреймворки для AI-агентов снимают с команды рутину: хранение состояния, вызов инструментов, повторы при сбоях, журнал шагов. Взамен они добавляют зависимость, которая живёт дольше пилота. Разбираем, что даёт и чего стоит фреймворк, чем различаются подходы и как выбирать, чтобы потом не переписывать всё с нуля.

Опубликовано 16 октября 2026

Обсудить задачу Смотреть услуги

Пять семейств подходовВосемь критериев выбораЧек-лист против привязки

Фреймворки для AI-агентов: что они дают и чего стоят

Агент на базе LLM — это языковая модель плюс код вокруг неё. Сама модель только отвечает текстом или просит вызвать функцию. Всё остальное делает код: цикл «модель — инструмент — результат — модель», хранение состояния, повторы, журнал. Либо вы пишете его сами, либо его приносит фреймворк: такие библиотеки для создания ИИ-агентов бывают от тонкого слоя до целой платформы. Как устроен цикл вызова, описано в статье про function calling и MCP, а что такое агент вообще, — в материале что такое AI-агент.

Что обычно получаете:

Управление состоянием

История сообщений и поля задачи хранятся вместе. У ряда фреймворков есть контрольные точки: работу можно остановить на согласование и продолжить после ответа, а при подключении постоянного хранилища и после перезапуска сервиса. Писать это с нуля трудоёмко.

Связка с инструментами

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

Повторы и ошибки

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

Трассировка

Журнал шагов: что ушло в модель, какой вызов вернулся, сколько заняло. Без него ошибку не разобрать, подробнее — в статье про мониторинг агента.

Что платите взамен:

Зависимость. Фреймворк — чужой код, который видит ваши данные и ключи доступа. У него свои уязвимости, зависимости и лицензия (о рисках — в статье про безопасность AI-агентов). Он проработает дольше пилота, и обновлять его придётся постоянно.
Нестабильный интерфейс. Область молодая: примеры из прошлогодних руководств могут не запускаться, а переход на новую версию бывает отдельной задачей с прогоном тестов.
Протекающие абстракции. Слой над моделью скрывает, что именно ушло в запрос. В ряде фреймворков внутри есть собственные шаблоны инструкций, которых вы не писали.
Привязка. Формат состояния, трасс и описания агентов у каждого проекта свой, и переезд означает переписывание.
Лишний вес. Ради цикла из нескольких шагов вы подтягиваете дерево зависимостей, и в строгих контурах каждая проходит проверку службы безопасности.

LangGraph, AutoGen, CrewAI и другие: пять семейств подходов

Подходов пять. Названия в таблице служат примерами, а не рейтингом.

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

Семейство и пример	Как устроено	Когда подходит	Типичные риски семейства
Граф состояний. Например, LangGraph	Процесс описан как граф: узлы (вызов модели, инструмент, обычная функция) и переходы, в том числе по условию, с общим состоянием	Много ветвлений, цикл «доработать и перепроверить», паузы на согласование, возобновление после остановки	Порог входа выше; граф легко усложнить сверх нужды; состояние хранится в формате инструмента
Диалог ролевых агентов. Например, AutoGen	Агенты обмениваются сообщениями, как участники чата; иногда есть менеджер, выбирающий, кто говорит следующим. У проектов этого семейства архитектура и состав пакетов менялись заметно, есть ответвления: проверьте, какая ветка и какой пакет актуальны	Исследовательские задачи с неизвестным ходом; прототипы; пара «исполнитель — критик»	Ход разговора трудно предсказать и воспроизвести; расход растёт с каждой репликой; права сложнее ограничить
Команды «роль — задача». Например, CrewAI	Описывают агентов (роль, цель, инструменты), задачи и порядок: по цепочке или с руководителем	Понятный процесс из этапов, который легко объяснить бизнесу; быстрый прототип	Роли на естественном языке легко множатся без причины; обработку ошибок и состояния, возможно, придётся дописывать
Тонкий SDK над API модели. SDK провайдеров, лёгкие библиотеки	Минимум: агент с инструкцией и инструментами; в части SDK ещё передача управления другому агенту, проверки входа и выхода, трассировка	Один-два агента, несколько инструментов, нужна готовая обвязка без тяжёлой модели процесса	Часто заточены под своего провайдера; для российских и локальных моделей совместимость проверять; трассы могут уходить в облако
Свой минимальный цикл	Небольшой цикл: вызвать модель, выполнить инструмент, вернуть результат, остановиться по лимиту шагов; состояние в вашей базе	Линейный процесс, жёсткий контроль, закрытый контур, команда с опытом	Повторы, возобновление и трассировку пишете и сопровождаете сами

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

Во-вторых, свободный диалог агентов мы для процессов с деньгами и документами по умолчанию не берём: ход труднее ограничить заранее, и сложнее показать, что агент не сделает лишнего. Порядок шагов задаём заранее, как в статье что такое мультиагентная система. Нужны ли отдельные роли, разбираем в статье один агент или несколько.

В-третьих, рядом живут библиотеки для смежных задач: поиск по документам (RAG), структурированный вывод, трассировка, оценка качества. Их выбирают отдельно от оркестратора. No-code-платформы — другой класс, сравнение на странице no-code или разработка.

Оркестрация агентов на условном примере: согласование скидки

Это иллюстрация, а не описание проекта заказчика. Менеджер просит нестандартную скидку. Агент собирает данные (историю клиента из CRM, маржу по позициям из учётной системы, правило согласования), готовит обоснование и отправляет руководителю отдела продаж. Тот отвечает через несколько часов или на следующий день, и только после этого решение записывается в систему. Что из этого следует для оркестрации:

Пауза на часы. Процесс не должен висеть в памяти запущенной программы. Состояние (кто просит, какие данные собраны, что предложено) лежит в базе и поднимается после ответа, даже если сервис перезапускали.
Запись только после согласования. Инструмент записи вызывает код после нажатия «согласовать», а не модель. Принцип описан в статье про человека в контуре.
Повтор без дублей и журнал. Если запись зависла по тайм-ауту, повторная отправка не должна создать вторую скидку. Ключ повтора формирует приложение, а не модель. Журнал фиксирует, что видел руководитель и что ответил.
Диалог агентов не нужен. Шаги известны заранее. Лимит скидки и маржу проверяет обычный код: формулу не стоит поручать «критику» на модели.

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

Критерии выбора: восемь вопросов к любому фреймворку

Число звёзд в репозитории и красота примеров о пригодности не говорят. Мы задаём восемь вопросов и проверяем ответы руками, а не по описанию.

Критерий	Что проверяем	Тревожный признак
Управление состоянием	Где лежит состояние, можно ли хранить его в своей базе, переживает ли перезапуск, можно ли остановить работу на согласование	Состояние живёт в памяти процесса или в формате, который не прочитать без фреймворка
Трассировка	Виден ли дословно запрос в модель, вызовы инструментов с аргументами и результатами, время и расход по шагам. Можно ли писать в своё хранилище и скрывать персональные данные	Трассы возможны только в облаке разработчика, отправку нельзя отключить
Повторяемость	Можно ли зафиксировать версии зависимостей, инструкций и модели и повторить прогон по записанным ответам инструментов; ответы модели при этом могут различаться, поэтому результат сравнивают по тестовому набору	Поведение зависит от скрытых шаблонов, которые меняются вместе с версией пакета
Локальные модели	Работает ли с моделью в вашем контуре через стандартный интерфейс. Как ведёт себя вызов инструментов именно у выбранной модели	Примеры и тесты проходят только на одной облачной модели
Зрелость и поддержка	Как часто выходят изменения, есть ли правила совместимости и пометки об устаревании, кто стоит за проектом	Поломки при мелком обновлении, документация расходится с кодом, проект держится на одном человеке
Лицензия	Лицензия проекта и его зависимостей, условия коммерческого использования, что платное. Юристу показывают до начала работ	Нужные функции есть только в платной облачной части
Зависимость от поставщика	Можно ли сменить модель и инфраструктуру, не трогая логику. Нужен ли аккаунт у разработчика проекта	Ключи или данные обязаны проходить через чужой сервис
Тестируемость	Можно ли подставить фиктивную модель и инструменты, проверить один шаг отдельно, запускать тесты без сети	Каждый тест требует реального вызова модели

Критерии не равны по весу. В закрытом контуре важнее локальные модели, трассировка и лицензия, см. локальные модели для агентов и ИИ в контуре компании. Для пилота на одном процессе важнее тестируемость и независимость от поставщика.

Пробный прогон вместо чтения документации

Лучший способ проверить восемь пунктов — построить в каждом кандидате один и тот же узкий срез: инструмент с побочным эффектом, паузу на согласование, искусственный сбой (тайм-аут) и замену модели. Тот же срез реализуют и на собственном цикле: он служит точкой сравнения. Затем смотрят, сколько кода пришлось дописать вокруг фреймворка, виден ли запрос в модель, поднимается ли задача после остановки сервиса и идут ли тесты без сети. На такой прогон стоит заложить несколько дней на кандидата: это дешевле ошибки, которая вскроется уже после запуска.

Когда фреймворк не нужен

Сначала спросите, нужен ли «агент», который сам выбирает шаги. Часто хватает сценария в коде: шаги фиксированы, а модель вызывается на одном-двух из них, например чтобы определить тип обращения, достать поля из письма или подготовить черновик. Это скучнее агента, зато поведение предсказуемо. См. статьи когда AI-агент не нужен и RPA или AI-агент. Фреймворк, скорее всего, лишний, если:

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

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

Как выбираем мы: по задаче, а код остаётся у заказчика

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

Сначала требования, потом инструмент. На экспресс-аудите фиксируем: нужны ли паузы на согласование, могут ли данные покидать контур, какие модели допустимы, сколько процессов планируется. Из этого следует семейство подхода.
Узкая схема по умолчанию. Порядок шагов задан в коде, права минимальны, на критичных шагах решает человек. Лишних агентов не добавляем.
Логика отдельно от обвязки. Правила, инструменты, инструкции и тесты не импортируют фреймворк, он подключается тонким слоем. Замена оркестратора тогда затрагивает один слой, а не весь проект.
Зависимости фиксируются. Точные версии, файл блокировки, копия пакетов для установки без интернета в контуре. Обновление проходит отдельным шагом с прогоном тестового набора.
Код у заказчика. Исходный код, инструкции, тесты и список зависимостей с версиями передаются вам, а права закрепляются в договоре; что прописать, описано в статье про договор на внедрение ИИ.

Выбор инструмента входит в проектирование и записывается в техническое задание. Ориентиры по стоимости: пилот на одном процессе — от 200 000 ₽, 3-4 недели; мультиагентная система — от 800 000 ₽, 2-3 месяца. Расходы на модель и оборудование считаются отдельной статьёй, как описано в полной смете. Кто обновляет зависимости, прописываем в условиях сопровождения: без этого фреймворк устаревает так же, как агент. Состав работ — на странице разработка AI-агентов.

Чек-лист: как не привязаться к фреймворку

Проверяйте у нас или у любого подрядчика. «Нет» — не запрет, а расход, который вы берёте на себя.

Бизнес-логика (правила, расчёты, проверки) написана обычным кодом без импортов фреймворка.
Инструменты — обычные функции с ясным контрактом: в тестах вызываются без фреймворка, в приложении подключаются тонким адаптером.
Инструкции для модели лежат в репозитории с историей изменений, а не только в интерфейсе облачной платформы.
Состояние хранится в ваших таблицах в понятном формате, а не только во внутренней схеме фреймворка, либо есть проверенная выгрузка.
Модель вызывается через один интерфейс: смена модели означает правку настройки и прогон тестов, а не переписывание шагов.
Версии зафиксированы: точные номера, файл блокировки, зеркало пакетов; тестовый набор и записанные трассы принадлежат вам.
Трассы и журналы пишутся в ваше хранилище; стандартные форматы вроде OpenTelemetry, если инструмент их поддерживает, упрощают переезд.
Установка без интернета проверена: приложение стартует в контуре без обращений к несогласованным внешним сервисам, в том числе без отправки телеметрии: часть библиотек шлёт анонимную статистику по умолчанию, пока это не отключено.
План Б описан: известно, какой слой придётся переписать при замене фреймворка и сколько это работы.
Права на код, инструкции и тесты закреплены за заказчиком; нет доступа, которым единолично владеет подрядчик.

Фреймворк можно поменять, если он держит только оркестрацию. Если он держит бизнес-логику, состояние и инструкции, менять придётся весь агент.

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

Какой фреймворк для AI-агентов выбрать?

Единого ответа нет, выбор следует из задачи. Много ветвлений, паузы на согласование и возобновление после остановки: смотрят в сторону графов состояний. Линейный процесс и закрытый контур: хватает своего небольшого цикла. Один-два агента с несколькими инструментами: подойдёт тонкий SDK. Сначала проверьте восемь критериев и сделайте пробный прогон.

LangGraph, AutoGen или CrewAI: в чём разница?

По общему подходу на момент подготовки материала: LangGraph описывает процесс как граф с общим состоянием, AutoGen строится вокруг обмена сообщениями между агентами (у него архитектура менялась заметно, уточняйте актуальную ветку), CrewAI — вокруг ролей, задач и порядка их выполнения. Это не рейтинг: проекты меняются, поэтому сверяйтесь с документацией и состоянием репозиториев.

Нужен ли LangChain, чтобы сделать AI-агента?

Нет. LangChain — набор готовых компонентов для работы с моделями, а LangGraph — отдельная библиотека оркестрации от той же команды; на момент подготовки материала её описывают как пригодную и без остального набора, но сверьте это с документацией. Агент по сути — цикл: модель просит вызвать функцию, код её выполняет и возвращает результат. Его можно написать самому или взять тонкий SDK. Библиотеки нужны там, где хочется сэкономить на состоянии, повторах и трассировке. Решать стоит по тому, что вы получите и чем заплатите, а не по известности названия.

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

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

Какой фреймворк подойдёт для локальных моделей и работы без интернета?

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

Что будет, если фреймворк перестанут развивать или он сломает совместимость?

Зафиксированная версия, как правило, продолжает работать, пока не изменится интерфейс поставщика модели, но исправлений уязвимостей и поддержки новых версий модели она не получит. Риск снижают заранее: логика и инструменты отдельно от обвязки, версии зафиксированы, есть тестовый набор, который покажет, что сломалось. Тогда замена оркестратора касается одного слоя; без этого переезд превращается в переписывание проекта.

Как выбор фреймворка влияет на стоимость AI-агента?

Цену он сам не определяет: пилот на одном процессе — от 200 000 ₽, сопровождение — от 40 000 ₽/мес. Фреймворк меняет объём кода вокруг модели и нагрузку на обновления. Расходы на модель и оборудование считаются отдельной статьёй. Раскладка — в статье про смету AI-агента.

Выберем инструмент под ваш процесс, а не под моду

На экспресс-аудите фиксируем требования к состоянию, моделям и контуру, и из них следует выбор между фреймворком и собственным кодом. Аудит: 50 000 ₽, 5-7 рабочих дней, сумма засчитывается в проект.

Оставить заявку