Создание ИИ-агентов: конструктор, фреймворк или собственный цикл

Что это решает

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

Как устроено

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

Слой 0. Готовый агент-продукт. Кодовые агенты в терминале и редакторе, агенты внутри CRM и почтовых сервисов, встроенные помощники в трекерах. Инструменты уже подключены, петлю никто не пишет. Подходит, когда задача совпадает с той, под которую продукт сделан. Не подходит, когда нужен доступ к собственным таблицам.

Слой 1. Конструктор сценариев. Узлы на холсте: триггер, вызов модели, ветвление, HTTP-запрос, запись в таблицу. Инструменты подключаются готовыми коннекторами. Из этого класса — n8n, Make, Zapier и агентские конструкторы у поставщиков моделей и облаков.

Слой 2. Фреймворк. Библиотека на коде, которая даёт петлю, память, передачу задач между агентами и перезапуски. Из этого класса — LangGraph, CrewAI, AutoGen, Pydantic AI и агентские SDK самих поставщиков моделей. Код лежит в git, отлаживается обычным отладчиком.

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

Сравнение по тому, что болит на практике

Что переносится между слоями

Переносятся три вещи: описания инструментов, промпты и набор проверок. Не переносится обвязка — расписания, повторы, очереди, хранение состояния. Поэтому инструменты с самого начала стоит держать отдельно от платформы: собственный HTTP-сервис или сервер по протоколу MCP подключается и к конструктору, и к фреймворку, и к своему циклу. Тогда переезд между слоями стоит переписывания петли, а не всей интеграции.

Правило: инструменты и промпты живут вне платформы сборки, иначе смена слоя означает переписывание всего.

Как подключить

Маршрут A. Конструктор

1. Завести сценарий с триггером: расписание, вебхук или новое письмо.
2. Подключить источники готовыми коннекторами, для остальных — узел HTTP-запроса с токеном в хранилище платформы.
3. Поставить узел вызова модели, в нём описать инструменты как отдельные узлы-функции.
4. Добавить ветку отказа: пустые данные, ошибка коннектора, превышение лимита времени.
5. Включить журналирование запусков и выгрузку сценария в файл — это единственная резервная копия.
6. Прогнать на подготовленных задачах, поставить сценарий на реальный триггер только после этого.

Маршрут B. Фреймворк

1. Поднять проект, зафиксировать версии библиотек — агентские фреймворки меняют интерфейсы быстро.
2. Описать инструменты типизированными функциями, схему аргументов брать из типов.
3. Собрать граф или последовательность шагов, отдельно вынести узлы проверки данных между шагами.
4. Включить встроенную трассировку и убедиться, что в трассе виден полный запрос к модели, а не только итог.
5. Написать тесты на инструменты обычными средствами языка, отдельно — прогон набора задач для агента.
6. Собрать вручную один запрос к модели теми же данными и сравнить с тем, что отправил фреймворк.

Маршрут C. Собственный цикл

1. Взять клиент API модели и включить параметр со списком инструментов.
2. Написать петлю: запрос, разбор ответа, выполнение вызова, дозапись результата, лимит итераций.
3. Добавить проверку прав перед каждым вызовом и таймаут на инструмент.
4. Писать трассу в файл или таблицу: шаг, инструмент, аргументы, ответ, токены.
5. Сверху повесить обвязку: расписание, повтор при сбое сети, очередь задач.
6. Набор проверок гоняется тем же скриптом, что и рабочие задачи, чтобы пути не разошлись.

Как выбирать

Четыре вопроса, ответы на которые закрывают выбор:

• Кто будет чинить это через полгода? Аналитик — конструктор. Разработчик — код.
• Нужен ли контроль над тем, что именно уходит в модель? Нужен — код.
• Требуется ли ревью изменений и откат? Требуется — код.
• Сколько таких агентов планируется? Один — конструктор. Семейство похожих — фреймворк или свой цикл с общей библиотекой.

Полезные сценарии

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

Ограничения

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

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

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

Общее для всех. Смена модели меняет поведение агента даже при неизменном промпте. Набор проверок нужен на любом слое; без него переход на другую модель или другой слой превращается в лотерею.

Как проверить результат

Один и тот же набор задач на всех прототипах. Сравнивать слои имеет смысл только на одинаковых входах и одинаковых инструментах, иначе сравниваются формулировки промптов.

Посмотреть итоговый запрос к модели. На каждом слое найти способ увидеть, что именно ушло: полный текст, порядок сообщений, описания инструментов. Способа нет — это главный аргумент против слоя.

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

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

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