Автоматизация под ключ на n8n: как собрать агента, который ведёт процесс сам
Разбираю на своём кейсе автовыдачи ключей, чем «агент, который ведёт процесс» отличается от простого сценария, и как собрать такой процесс в n8n, чтобы он работал без вас.
Когда говорят «автоматизация под ключ», обычно представляют красивую схему из квадратиков: пришло письмо — создалась задача — ушло уведомление. Это линейный сценарий. Он ломается на первом же исключении: дубль оплаты, сбой внешнего сервиса, пустой ответ API. И тогда «под ключ» превращается в «под присмотром».
Агент, который ведёт процесс сам, устроен иначе. У него есть цель, состояние и право принимать решения на каждом шаге. Я разберу это на своём живом примере и покажу, как переносится в n8n.
Мой кейс: автовыдача ключей на FunPay
Мы продаём Prism Pro на FunPay. Логика простая только на словах: покупатель оплатил — покупатель получил рабочий ключ. Проблема в том, что у FunPay нет официального API и вебхуков. Дёрнуть нас по факту оплаты некому.
Поэтому процесс ведёт бот на базе FunPayCardinal. Он сидит на cookie-сессии нашего аккаунта, слушает чат и заказы, ловит оплаченный заказ. Дальше вступает наш плагин qolab_delivery.py: он чеканит свежий ключ через POST /admin/keys к нашему лицензионному серверу (Hono + SQLite, Ed25519) и отправляет ключ покупателю прямо в чат FunPay.
Четыре шага ядра: match (это наш товар?), mint (выпустить ключ), message (доставить), dedup (не выдать дважды на один заказ). Последний пункт — самый важный и самый скучный. Без дедупликации ретрай или повторное срабатывание превращается в раздачу лишних ключей за наш счёт.
Вот это и есть агент, который ведёт процесс сам: он держит состояние заказа, сам решает, надо ли выпускать ключ, сам справляется с тем, что источник событий официально не существует.
Что из этого переносится в n8n
n8n я держу для процессов, где не хочется писать отдельный сервис. Логика та же самая, что в боте, разложенная на ноды.
Триггер и вход. Если у сервиса есть вебхук — берём Webhook-ноду. Если нет, как у FunPay, ставим Schedule и опрашиваем источник сами. Опрос честнее выглядит на схеме, чем магия «оно само прилетело».
Ветвление вместо прямой линии. IF и Switch — это те самые решения агента. «Товар наш?» «Оплата подтверждена?» «Ключ уже выдавали?» Каждая развилка — точка, где линейный сценарий бы просто продолжил и накосячил.
Дедупликация как отдельный шаг. В n8n я держу таблицу выданных заказов (Postgres или встроённая база) и первым делом проверяю, нет ли записи по этому order_id. Есть — выходим тихо. Нет — идём выпускать и сразу пишем запись. Порядок важен: сначала фиксируем намерение, потом действуем.
Внешний вызов с обработкой ошибки. HTTP Request к своему API — здесь у меня выпуск ключа. К ноде обязательно цепляю ветку на ошибку через Error Trigger или настройку «continue on fail». Молчаливый провал в продаже — это недовольный покупатель, который уже заплатил.
Доставка результата. Финальная нода отправляет ключ обратно. В моём боте это чат FunPay, в n8n это может быть письмо, сообщение в Telegram, запись в CRM.
Где обычно всё разваливается
За этими кейсами я вынес несколько простых правил.
- Идемпотентность прежде красоты. Любой шаг, который тратит деньги или ресурсы, должен переживать повторный запуск без последствий. Дубль оплаты, ретрай ноды, перезапуск воркфлоу — всё это случается.
- Состояние живёт снаружи. n8n перезапускается, инстанс падает, вы деплоите обновление. Прогресс процесса храните в базе, тогда агент подхватит работу с того места, где остановился.
- Провал должен быть громким. Заведите отдельную ветку ошибок с уведомлением себе. Тихая автоматизация опасна именно тем, что ломается тихо.
- Ядро под тестами. У бота FunPay match/mint/message/dedup покрыты тестами, потому что это деньги. В n8n аналог — ручной прогон каждой развилки с тестовыми данными перед боевым запуском.
С чего начать
Не пытайтесь сразу собрать «умного агента». Возьмите один реальный процесс, который вы делаете руками, и разложите его на вопросы: что запускает, какие решения принимаются, что считается «уже сделано», что делать при ошибке.
Эти четыре вопроса и есть каркас агента. У меня в случае FunPay ответы дали ровно четыре шага ядра. Соберите их в n8n, прогоните на тестовых данных, добавьте дедупликацию и уведомления об ошибках — и процесс начнёт вести себя сам.
Под ключ означает, что вы можете уйти. А уйти можно только тогда, когда система знает, что делать в тот момент, когда что-то пошло не так.