Создайте своего ИИ-агента, и он будет работать за вас: что на самом деле продают

В рекламе курсов по ИИ всё чаще звучит одно обещание: за пару вечеров вы соберёте агента, который будет делать за вас работу. Искать клиентов, отвечать в директ, писать посты, искать вакансии. Звучит так, будто вы нанимаете сотрудника, только бесплатного и без выходных.

Проблема в том, что слово «агент» в этой рекламе никогда не объясняется. А от того, что под ним понимать, зависит, правда это или нет.

Что такое агент на самом деле

В ИТ агентом называют программу, которая сама решает, какой следующий шаг сделать, чтобы достичь цели. У неё есть инструменты (поиск, почта, доступ к сайтам), и она по кругу смотрит на результат и выбирает, что делать дальше. Важное слово здесь «сама решает».

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

Разберём на примере: агент, который ищет вам работу

Типичное обещание: агент сам соберёт вакансии, отберёт подходящие и пришлёт вам на почту. Посмотрим, из чего это состоит на самом деле.

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

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

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

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

Почему обещание — либо лукавство, либо непонимание

Честное описание звучало бы так: «Научим собрать цепочку автоматизации с шагом через ChatGPT. Она будет стоить денег, потребует настройки и присмотра, и часть задачи можно решить встроенными функциями сайтов». Так не продашь.

Поэтому вариантов два. Либо автор курса понимает разницу и сознательно называет простую автоматизацию «агентом», потому что это модное слово. Либо не понимает сам и искренне считает, что собранный в конструкторе сценарий — это самостоятельный помощник. Во втором случае он не сможет научить вас тому, чего не знает: что делать, когда всё сломается.

Как выглядит реальная работа с агентами

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

Наглядный пример: сервисы вроде Lovable или bolt.diy («опишите приложение — получите готовый код») действительно ведут себя как агенты в этом смысле. Внутри у них не жёсткий сценарий, а цикл: сгенерировать код → собрать и запустить в песочнице → увидеть ошибку сборки → исправить → повторить, пока приложение не заработает. И за этим стоит настоящая инфраструктура, а не одна кнопка: у Lovable — свой облачный бэкенд на Supabase (база данных, аутентификация, серверная логика, платежи), у bolt.diy — деплой через Docker с вариантами хостинга. Это ровно то, о чём предупреждает предыдущий раздел: за честным словом «агент» всегда стоят деньги на инфраструктуру и её обслуживание, а не бесплатный сотрудник, появившийся из одного промпта.

Что именно такое Supabase, если коротко: это открытая (open source) платформа «бэкенд как сервис» — по сути альтернатива Firebase от Google. Из коробки в ней есть настоящая база данных PostgreSQL (а не урезанная имитация), готовая аутентификация пользователей (email, Google, GitHub и другие), хранилище файлов, серверная логика (Edge Functions), обновление данных в реальном времени и автоматически сгенерированный REST/GraphQL API — не нужно писать эндпоинты вручную. Именно поэтому такие конструкторы, как Lovable, подключают Supabase вместо того, чтобы писать свой бэкенд с нуля: получают базу данных, логины и хранилище сразу. Пользоваться можно облаком Supabase (платно по мере роста нагрузки) или развернуть self-hosted версию на своём сервере бесплатно.

Supabase — частный пример более широкого класса сервисов: BaaS (Backend-as-a-Service, «бэкенд как сервис»). Это готовый бэкенд, который не нужно разворачивать и поддерживать самому — вы просто подключаетесь к нему по API-ключу. Продаётся это так же, как и «агент»: как экономия времени — не пишешь бэкенд с нуля, а берёшь готовый конструктор.

То, что именно экономит время в BaaS, называется «обвязкой» — это весь код и инфраструктура вокруг голой технологии, которые делают её удобной в использовании. Сырой PostgreSQL — это просто СУБД: чтобы им реально пользоваться, нужно самому прикрутить авторизацию, REST-эндпоинты, права доступа на уровне строк, вебхуки на изменения данных. Вся эта прослойка вокруг базы — и есть обвязка, которую Supabase даёт готовой, а при самостоятельной сборке бэкенда её приходится писать вручную.

Когда Supabase (или любой BaaS) — разумный выбор, а не собирать всё вручную: нужен обычный логин пользователей через email или Google/GitHub с подтверждением почты и сбросом пароля; нужны живые обновления в интерфейсе без ручной настройки WebSocket; нет ресурса на администрирование базы — бэкапы, миграции, мониторинг; нужны права доступа «каждый пользователь видит только своё», которые в BaaS задаются декларативными политиками, а не написанным и протестированным вручную кодом; или просто важна скорость запуска прототипа, а не контроль над инфраструктурой.

И наоборот, собирать бэкенд самому на голой базе разумнее, когда часть этой обвязки объективно не нужна: авторизация уже решена другим способом (SSO компании, вход через мессенджер), нужная инфраструктура уже есть для других задач, или схема данных настолько простая, что вся выгода BaaS сводится к нулю, а платить за неиспользуемые функции — незачем. Это тот же принцип, что и с «ИИ-агентом» из начала статьи: смотреть не на модное название инструмента, а на то, какую конкретно работу он реально снимает с вас — и стоит ли это тех денег и той зависимости, которую вы на себя берёте.

А если сайт на заказ делаете вы сами

Тот же вопрос «а что конкретно это мне экономит» стоит задать и про Supabase, если вы сами берёте заказы на разработку сайтов. Для обычного сайта без личных кабинетов — визитки, лендинга, портфолио, каталога без входа пользователей — Supabase не нужен вообще, там достаточно статики или простой базы без всякой обвязки. Ставить туда облачный BaaS — тот же случай, что и с «агентом» из начала статьи: красивое название инструмента подменяет вопрос о том, какую именно работу он снимает.

Supabase в заказе оправдан, когда клиенту реально нужна часть той самой обвязки: личные кабинеты с входом через email или соцсети, подтверждением почты и сбросом пароля; живые обновления в интерфейсе — чат, уведомления, совместная работа — без ручной настройки WebSocket; права доступа «каждый пользователь видит только своё», заданные готовыми политиками, а не написанным вручную и непротестированным кодом. Писать и тестировать всё это самому — реальные часы работы и риск ошибок именно там, где ошибка дороже всего: в авторизации и правах доступа.

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

Что спросить у автора курса, прежде чем платить

Что именно вы называете агентом: он сам принимает решения или выполняет заданную цепочку шагов? Где он будет работать и сколько это стоит в месяц? Кто и как будет его чинить, когда он сломается? Не нарушает ли он правила сайтов, с которых берёт данные? И можно ли решить эту задачу без ИИ, встроенными средствами?

Если на эти вопросы нет прямых ответов, вам продают не навык, а слово.

Глоссарий терминов

• ИИ-агент — программа, которая сама решает, какой следующий шаг сделать для достижения цели, используя доступные ей инструменты и оценивая результат на каждом шаге, а не просто выполняет заранее заданный сценарий.
• Автоматизация — заранее заданная цепочка шагов («взять данные → обработать → отправить»), которая выполняется одинаково при каждом запуске; в отличие от агента, ничего не «решает» сама.
• LLM (large language model, большая языковая модель) — модель вроде ChatGPT, которая генерирует текст или код по запросу; сама по себе это не агент, а инструмент, который агент может использовать.
• API (application programming interface) — способ, которым один сервис официально предоставляет доступ к своим данным или функциям другим программам, обычно с ограничениями и условиями использования.
• Промпт — текстовый запрос на естественном языке, которым пользователь описывает задачу для ИИ.
• BaaS (Backend-as-a-Service, «бэкенд как сервис») — готовый бэкенд в виде облачного сервиса: база данных, авторизация, хранилище файлов и API уже настроены и работают у провайдера, подключаетесь по API-ключу вместо того, чтобы разворачивать всё самому.
• Обвязка — код и инфраструктура вокруг «голой» технологии, которые делают её удобной в использовании: например, авторизация, готовые API-эндпоинты и права доступа вокруг обычной базы данных.
• SSO (single sign-on, единый вход) — способ входа, при котором один аккаунт (например, рабочая учётная запись Google или Microsoft) даёт доступ сразу к нескольким сервисам без отдельной регистрации и пароля в каждом из них. Компании используют SSO, чтобы сотрудники входили везде одной и той же корпоративной учёткой — тогда отдельный вход через email/пароль в конкретном сервисе просто не нужен.
• Lovable — сервис, который генерирует рабочее веб-приложение (фронтенд + бэкенд на Supabase) по текстовому описанию и дорабатывает его дальше в диалоге.
• bolt.diy — опенсорсный форк bolt.new: похожий генератор приложений по промпту, который можно развернуть на своём сервере через Docker.
• Supabase — открытая (open source) платформа «бэкенд как сервис», альтернатива Firebase: готовая база данных PostgreSQL, аутентификация пользователей, хранилище файлов, автоматически сгенерированный API и серверная логика (Edge Functions); можно использовать в облаке Supabase или развернуть self-hosted версию на своём сервере бесплатно.
• WebContainers — технология запуска Node.js-окружения прямо в браузере, которая позволяет таким сервисам, как bolt.diy, собирать и тестировать код без отдельного сервера.
• Docker — инструмент для упаковки приложения со всем его окружением в контейнер, который одинаково запускается на любом сервере.
• Инфобизнес — продажа обучающих курсов и консультаций как основной вид заработка; в контексте статьи — курсы, продающие простую автоматизацию под видом «ИИ-агента».

Вопросы: @romanreikikaz

Теги: #ии-агенты #инфобизнес #автоматизация #честныйразбор