AI-агент против Zapier, Make и n8n: в чём разница и что выбирать
Вопрос звучит почти всегда одинаково: «У меня уже настроен Zapier, зачем мне агент?» И это правильный вопрос. Половина того, что сегодня продают как AI-агентов, — это обычные сценарии с языковой моделью в одном из шагов.
Разница есть, она принципиальная, и она не в том, что агент «умнее».
Как устроен сценарий
Zapier, Make и n8n выросли из одного: ждут события и выполняют заранее нарисованную последовательность действий. Пришло письмо с вложением — сохрани файл в папку, создай строку в таблице, отправь уведомление в канал.
Сегодня агентские режимы есть у всех трёх — Zapier Agents, Make AI Agents, AI Agent в n8n. Поэтому честнее сравнивать не продукты, а два способа устроить работу: маршрут и цель. Дальше речь именно об этом.
Ключевое слово — заранее нарисованную. Вы описали маршрут, и система идёт по нему. Каждый раз одинаково.
Это огромное достоинство. Сценарий:
- работает предсказуемо: на одинаковом входе даёт байт в байт одинаковый выход;
- стоит копейки за операцию и держит тысячи срабатываний в час;
- легко проверяется — видно, какой шаг отработал, а какой упал;
- не выдумывает.
Если задача формулируется как «когда происходит X, всегда делай Y», сценарий — правильный инструмент, и агент здесь будет дороже и хуже. Перенос оплаты из Stripe в бухгалтерскую систему, уведомление о новой заявке, синхронизация двух таблиц — это территория Zapier, и отбирать её незачем.
Где сценарий ломается
Проблемы начинаются там, где вход перестаёт быть одинаковым.
Формат поплыл. Клиент прислал не PDF со счётом, а фотографию счёта, снятую под углом в плохом свете. Сценарий не умеет «понять, что это». Он умеет «взять поле amount». Поля нет — ветка упала.
Нужно решение, а не действие. «Если сумма больше десяти тысяч — на согласование» описывается условием. «Если клиент в письме выражает недовольство — не отправлять автоответ, а поднять человека» условием не описывается. Недовольство не лежит в поле.
Ветвлений больше, чем можно нарисовать. Каждое исключение — новая ветка. Через полгода схема из двухсот блоков, и никто, включая автора, не берётся её менять. Знакомая картина: проще завести новый сценарий рядом, чем разобраться в старом.
Общее у всех трёх случаев одно: реальность оказалась богаче, чем схема, а схема не умеет достраиваться.
Что делает агент иначе
Агенту вы задаёте не маршрут, а цель и границы. «Разбирай входящие документы: определи, что это, положи куда следует, чего не хватает — запроси у клиента. Если не уверен — не гадай, отдай мне».
Дальше он сам решает, какие шаги сделать в конкретном случае. Фотография под углом — прочитает. Не прочитает — скажет, что именно не разобрал, и попросит переснять. Пришло что-то неожиданное — опишет своими словами и передаст вам, а не упадёт с ошибкой.
Практическая разница: сценарий обрабатывает случаи, которые вы предусмотрели, агент обрабатывает и остальные тоже — либо делает, либо честно поднимает руку.
Обратная сторона
Здесь начинается то, о чём в рекламе агентов молчат.
Недетерминированность. На похожем входе агент даёт похожий, но не идентичный результат. Для разбора документов это неважно. Для расчёта зарплаты — важно настолько, что туда агента пускать не надо.
Аудит сложнее. В сценарии видно: шаг 4 упал. У агента надо смотреть, что он решил и почему. Хороший продукт показывает ход рассуждения по шагам, но это всё равно чтение текста, а не взгляд на схему.
Дороже за операцию. Не в разы дороже, но разница между вызовом модели и HTTP-запросом объективна. На десяти тысячах однотипных срабатываний в день она заметна.
Шаблонность на одинаковых данных. Если дать агенту одинаковые вводные, он выдаст одинаковый результат — и это его свойство, а не поломка. Мы описывали случай, когда агентство обнаружило, что три стратегии из шести похожи, потому что собирались по одной схеме из похожей фактуры.
Как выбирать
Работающее правило простое.
Берите сценарий, если вход всегда одного формата, решение описывается условием, объём большой, а цена ошибки в одном срабатывании низкая.
Берите агента, если вход приходит от людей и потому разный, требуется понять смысл, а не поле, исключений больше, чем правил, и объём — десятки в день, а не тысячи в час.
Формулировка-подсказка: попробуйте описать задачу словами «если… то…». Получилось за три предложения — это сценарий. Пришлось писать «ну, обычно так, но бывает по-разному, и тогда надо смотреть» — это агент.
Отдельно про n8n
С n8n сравнение получается менее чистым, чем с Zapier, и сказать об этом стоит прямо.
Во-первых, его можно развернуть у себя. Исходный код открыт, но лицензия не открытая в строгом смысле: это Sustainable Use License, «fair-code» — использовать внутри своего бизнеса можно, перепродавать нельзя. При своём развёртывании данные не уходят к посреднику и платы за срабатывания нет вовсе. Облако у n8n тоже есть, и там тарификация по прогонам.
Во-вторых, агент-нода в n8n — полноценная: к ней подключается память, и на Postgres или Redis она переживает перезапуски. То есть граница, о которой вся статья, проходит уже внутри n8n.
Практическое различие остаётся одно, и оно не про возможности.
Кто собирает конструкцию. В n8n процесс проектируете и поддерживаете вы: ноды, связи, ветки, обработка ошибок, память и то, что в ней лежит. Это ровно та работа, ради которой нанимают интегратора. У нас конструкция собирается разговором за 15–30 минут, а дальше вы её правите: дешевле на старте и менее гибко в пределе.
Если у вас в команде есть человек, которому нравится n8n, и он его уже развернул — это сильная позиция, и агент вам нужен не вместо, а поверх: там, где нода перестала справляться с неоднородным входом.
Их не обязательно противопоставлять
На практике связка работает лучше любого из двух по отдельности. Сценарий делает то, что делает хорошо: ловит событие, дёргает API, переносит данные. Агент забирает участок, где нужно понять входящее и решить, что с ним делать.
Типичное разделение у бухгалтера на аутсорсе: сценарий забирает выписку из банка и кладёт транзакции в систему — это механика, тут агент не нужен. Агент разбирает то, что клиенты присылают в мессенджер, потому что там фотографии, голосовые и «а это точно нужно?».
Что в сухом остатке
Агент — не улучшенный Zapier. Это другой инструмент под другой класс задач: там, где вход неоднородный, а работа требует суждения.
И честный вывод: если ваши процессы уже хорошо описываются сценариями и они не падают — вам, скорее всего, не нужен агент. Нужен он там, где автоматизация до сих пор не взлетела именно потому, что задача не сводилась к «если… то…».