Как сделать своего ИИ-агента: от no-code до скрипта на Python

Создать ИИ-агента можно двумя путями: в конструкторе без программирования (no-code) или на Python с прямыми вызовами модели по программному интерфейсу (API). Конструктор быстрее для простых сценариев, код дает контроль над инструментами и расходом токенов. Оба пути упираются в один вопрос: откуда агенту из России взять доступ к модели.

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

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

Разница видна на примере. Обычный бот на Discord-сервере отвечает на вопрос «какие правила на сервере» заранее заготовленным текстом. Агент получает запрос «найди в логах, кто заспамил чат ночью», сам лезет в историю сообщений, фильтрует по времени, считает и возвращает список. Первый знает один ответ. Второй собирает ответ из действий.

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

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

Раз агент действует сам, его нужно из чего-то собрать. Вариантов ровно два, и начать стоит с того, который проще.

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

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

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

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

Конструктор без программирования (no-code) подходит, когда сценарий линейный и предсказуемый. Модерация Discord-сервера по простым правилам, FAQ-бот по вашему моду, автоответ на типовые вопросы в сообществе, разовый помощник без ветвлений. Везде, где шаги известны заранее, мышка и готовые блоки соберут агента быстрее, чем вы настроите окружение для кода.

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

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

Как не надо: брать первый попавшийся конструктор и строить на нем сложную ветвистую логику с десятком инструментов и внешними вызовами. Как надо: взять конструктор под простой сценарий, собрать прототип, и если уперлись в пределы, переезжать в код осознанно. Из живых инструментов сейчас, как по мне, смотрят в сторону Dify.ai и n8n. А вот популярный раньше Flowise как основу брать не стоит: проект закрыт, конец поддержки 31 августа 2026 года, строить новое на мертвом инструменте значит терять время.

Как только сценарий обрастает инструментами и ветвлениями, конструктора становится мало. Тогда открываем редактор кода.

В коде агент начинается с одного запроса к модели. Вы отправляете на базовый адрес (base URL) сервиса POST-запрос с ключом в заголовке и списком сообщений в поле messages, а в ответ получаете, что модель решила делать дальше. Это сердце любого агента на Python, и пока оно не работает, остальное смысла не имеет.

Минимальный каркас выглядит так:

Здесь три важные вещи: базовый адрес https://api.provod.ai/v1, заголовок с ключом и поле messages со списком реплик. Рядом с chat/completions живут и другие адреса метода (endpoint): POST /v1/messages со своим форматом и полем stop_reason, а также /v1/responses для сценариев с состоянием и ссылкой на предыдущий ответ. Форматы разные, принцип один: запрос ушел, ответ пришел, агент решает следующий шаг.

Готовые каркасы не обязательно писать с нуля. Ориентиры 2026 года: OpenAI Agents SDK для Python 3.9 и выше, LangGraph и LangChain 1.x для графов из шагов агента, а для бота в Discord подойдет библиотека discord.py на Python 3.8 и выше. Эти штуки берут на себя рутину: хранят историю, крутят цикл, подключают инструменты.

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

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

Работает это так: вы меняете в коде базовый адрес на адрес агрегатора, подставляете его ключ, и запросы идут к каталогу моделей без VPN. Один из таких сервисов, Provod, работает по базовому адресу https://api.provod.ai/v1, оплата картой, СБП или счетом с юрлица, а баланс общий и в рублях. Команде так удобнее: баланс один на всех, роли и ключи раздаются внутри, трата видна в одном окне. И не нужно под каждого разработчика искать живую зарубежную карту.

По данным компании, на 1 ноября 2026 года в каталоге было 83 модели со статусом «доступна», минимальное пополнение для первого запроса — 100 рублей, а ключ выдается почти сразу после оплаты. Это заявления сервиса, так что перед стартом доступность и условия стоит проверить на его странице, а не верить на слово.

Схема «один ключ ко многим моделям» встречается у разных операторов, поэтому сама по себе она не делает сервис особенным. Ценность именно в оплате и доступе из России без танцев с зарубежной картой. И сразу оговорюсь: это способ оплаты и маршрут доступа. Юридической чистоты он сам по себе не дает, поэтому «законно и без рисков» я тут обещать не буду, это вопрос к вашему юристу, а не к гайду. Доступ есть, запросы идут. Теперь важно не спалить бюджет токенов, потому что платите вы за каждый прогон.

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

В конструкторе эта кухня спрятана. Вы видите результат, но не видите, что именно улетело в модель на каждом шаге и сколько истории вы тащите за собой из прошлых реплик. В коде иначе: перед вами весь список messages, вся история, которую вы прикладываете к запросу, и каждый вызов инструмента. Хотите дешевле, режете историю, убираете лишний контекст, отключаете reasoning там, где он не нужен.

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

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

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

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

Инструменты (tools) работают как функции, которые агент дергает сам: поиск по базе, запрос к API сервера, чтение файла, выгрузка результата. Через них агент из болталки превращается в работника: отвечает и сразу действует, вызывает функцию и возвращает результат. Вы описываете функцию и отдаете ее агенту, а он решает, когда ее вызвать, исходя из задачи.

Для пайплайна важен и формат выгрузки, иначе результат агента некуда девать. Чат с файлами отдает XLSX, CSV, TSV, TXT, MD и JSON, так что ответ можно сразу забрать в таблицу, скормить следующему скрипту или положить в репозиторий мода. Когда агент собран и модель выбрана, связку надо проверить, и вот тут новички чаще всего спотыкаются.

Больше всего времени новички теряют на четырех мелочах. Неверный базовый адрес, и запрос уходит в никуда без внятной ошибки. Забыли ключ или вписали не тот, сервис отвечает отказом доступа. Выбранная модель недоступна, хотя в каталоге рядом лежит такая же, но с другим ID. Кривой формат messages, где перепутаны роли или поехала структура, и модель не понимает, чего от нее хотят.

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

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

С чего начать сегодня: взять простой сценарий, собрать минимальный каркас, прогнать на одной тестовой задаче. Если связка «базовый адрес, ключ, messages» отвечает, дальше вы просто достраиваете инструменты и шаги по одному. Если нет, вы уже знаете, где искать, потому что звенья проверяются по порядку. Путь выбран, доступ есть, модель проверена, остается сделать первый шаг.

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

Прикиньте свой сценарий: простой — no-code, с контролем — Python, а доступ к модели подключите по одному ключу.

А у вас какой сценарий: где хватит конструктора, а где уже без кода не обойтись?