Переход с n8n на AI-агентов: что перенёс, что оставил и почему

В марте 2025 года у меня было 23 активных workflow в n8n. Каждый понедельник я тратил 2–3 часа на обслуживание: обновлял протухшие credentials, чинил упавшие webhook-ноды, адаптировал логику под изменившиеся API сторонних сервисов. К концу 2025-го этот процесс вырос до 4–5 часов в неделю. Не потому что стало больше поломок — просто каждый workflow обрастал исключениями которые надо было прописывать вручную в визуальном редакторе.

Сегодня на n8n работают 8 workflow. 15 сценариев заменены Python-агентами на базе Claude API. Время обслуживания — 40 минут в неделю. Это не потому что агенты «лучше» в абстрактном смысле. Некоторые задачи n8n решает быстрее и дешевле. Это потому что я научился разделять: какой инструмент для чего подходит, и где граница между ними.

В этой статье — конкретика без воды. Что именно было на n8n, почему часть перенёс, как переносил (с примером архитектуры), что выбросил вообще, и реальные числа за 3 месяца работы новой системы. Никаких обещаний что «агенты заменят всё» — только то что реально работает у меня в проде.

Что у меня было на n8n и почему это перестало справляться

Solar Property в 2024–2025 году: 9 вилл на Бали, 3 активных менеджера, около 200 входящих запросов в месяц через WhatsApp, Telegram, Instagram и email. Плюс ежемесячная финансовая отчётность для 12 инвесторов. Без автоматизации этот объём не обработать силами 3 людей.

n8n выбрал из-за self-hosted модели: данные о бронированиях и финансах не должны проходить через чужие облачные сервера. Плюс отсутствие поминутной тарификации за выполнения — в отличие от Zapier или Make где каждая операция стоит денег.

Стек к январю 2025 года:

• 5 webhook-workflow: поймать бронирование с Airbnb → записать в PostgreSQL → уведомить менеджера в Telegram
• 4 scheduler-workflow: ежедневные P&L-отчёты, еженедельные дайджесты, напоминания гостям за 3 дня до заезда
• 6 интеграционных: синхронизация календарей между Airbnb, Booking.com и собственной системой бронирований
• 4 контентных: кросспостинг постов между Telegram, Instagram и VK
• 4 финансовых: выгрузка оплат из PMS eZee в PostgreSQL, автоматический расчёт P&L по каждой вилле

n8n с этим справлялся. Но к 23 workflow накопилось четыре вида технического долга которые превращали обслуживание в предсказуемую рутину.

Credentials decay. API-ключи и OAuth-токены протухают — особенно Instagram (срок жизни Long-Lived Token 60 дней) и Booking.com API (ежегодная ротация). В n8n обновление токена: найти нужную node → открыть credentials panel → вставить новый токен вручную → нажать Test → проверить что workflow работает. При 23 workflow где часть использует одни credentials через разные ноды — это 30–40 минут только на ротацию каждые 2–3 месяца. Пока не обновил — workflow не работает. Блокирующая задача.

Отсутствие версионирования. n8n хранит workflow как JSON-блоб в SQLite или PostgreSQL (зависит от конфига). Когда что-то сломалось — непонятно что изменилось и когда. «Кто и когда добавил эту ноду?» — нет ответа без ручного лога. Git-интеграция появилась в n8n 1.x, но требует отдельного репозитория и настройки. Для 23 workflow казалось избыточным — не настраивал. Пожалел.

Условная логика разрастается. Начинается workflow с 5 нодами. Через месяц добавляется исключение: «если источник Booking, а не Airbnb — делай иначе». Ещё через месяц: «если гость уже был у нас — пропустить приветственное». К концу года простая webhook-интеграция превращается в 30-нодный граф с 7 Switch-нодами. Боишься трогать — непонятно какую ветку можно сломать. Документации нет, автора нет, спросить некого.

Нулевая наблюдаемость в отказах. Когда workflow падает посреди ночи, n8n пишет в execution history. Но кастомные алерты в Telegram требуют добавить Error Trigger ноду в каждый workflow — отдельная работа. Я узнавал о проблемах утром когда менеджер писал: «бронирование не появилось в системе». Среднее время обнаружения инцидента — 8 часов. Потеря данных бывала редко, но задержки в обработке были регулярно.

Принцип разделения: когда n8n, а когда агент

В январе 2026 потратил 2 недели на ревизию всех 23 workflow. Сортировочный критерий один: нужно ли здесь суждение?

n8n отлично справляется с детерминированными сценариями: если A происходит → сделать B. Нет выборов «что лучше», нет «в зависимости от смысла». Маппинг данных и вызов API. Таких workflow оказалось 8 — остались на n8n.

Агент нужен там где появляется хотя бы одно из следующего:

• Анализ контента: «прочитай переписку и определи — горячий лид или информационный запрос»
• Приоритизация: «из 47 входящих за ночь выдели 3 срочных которые требуют ответа сегодня»
• Формирование текстового ответа: «напиши ответ на английском в тоне компании с учётом истории клиента»
• Принятие решений по исключениям: «если запрос нестандартный — создай задачу менеджеру, если стандартный — ответь автоматически»
• Диалог: любое взаимодействие где ответ зависит от предыдущего сообщения пользователя

Из 23 workflow 15 попали во вторую категорию. Часть переписал с нуля, часть адаптировал: оставил webhook-приём на n8n, добавил очередь в PostgreSQL, агент тянет из очереди.

Конкретный пример разделения. Workflow «напомни менеджеру о заезде за 3 дня» остался на n8n: за 72 часа до check-in выбирает бронирования из БД, отправляет Telegram-сообщение с именем гостя, номером виллы и телефоном. Нулевая логика, нулевые исключения. Работает надёжно, не требует обслуживания. Смысла переносить нет.

Workflow «обработай входящее сообщение от гостя в WhatsApp» ушёл агенту. Сообщение может быть запросом о заселении, жалобой на кондиционер, вопросом о продлении на 2 дня, угрозой плохим отзывом или просто «спасибо». Каждый случай — разный ответ, разная эскалация менеджеру, разная запись в CRM. n8n это сделает через 20+ ветвлений Switch-ноды. Python-агент с Claude — через одну функцию classify_and_respond() на 80 строк кода.

Как я переносил: реальный пример с архитектурой

Возьму конкретный workflow: «квалификация входящего лида из Instagram DM». В n8n: Instagram webhook → парсинг сообщения → Function-нода с поиском ключевых слов → если найдено → тег «горячий» → Telegram-уведомление менеджеру. Список слов: «стоимость», «цена», «сколько», «забронировать», «свободно», «доступно».

Проблема: пропускал «интересует ли вас вилла на новый год» (нет ключевых слов, но явный горячий лид), зато тегировал «ваши цены слишком высокие» как горячий лид. Точность на 200 реальных диалогах — около 60%. Менеджер получал уведомления по «горячим» лидам и 40% из них оказывались мусором.

Новая архитектура — гибридная, n8n + агент:

1. Instagram webhook → n8n → валидация (не пустое ли, не техническое эхо) → запись в таблицу instagram_queue в PostgreSQL: поля user_id, message_text, timestamp, status='pending'
2. Python-агент (systemd-сервис, интервал 2 минуты) берёт из очереди пачку до 10 записей со status='pending'
3. Для каждого сообщения: загружает историю последних 5 сообщений этого пользователя из instagram_history, отправляет в Claude API
4. Claude возвращает JSON: {"category": "hot_lead", "confidence": 0.91, "reason": "запрос цен на конкретные даты"}
5. Агент обновляет запись, горячих лидов (confidence > 0.75) пушит менеджеру в Telegram с контекстом переписки

Точность после калибровки промпта на 200 диалогах: 89%. Протестировал на следующих 200 новых диалогах без правок — 87%. Менеджер получает уведомления только по реально горячим лидам.

Setup занял 4 часа: 80 строк Python + systemd-юнит + тест на реальных данных. n8n-нода от старого workflow осталась — только теперь пишет в очередь, а не пытается классифицировать.

Устойчивость к пикам — ключевое преимущество этой архитектуры. Если за час придёт 200 сообщений — n8n положит все 200 в очередь. Агент обработает их за 20–40 минут пачками по 10. Записи не теряются даже если агент был на перезапуске. При прямом вызове Claude API из n8n-ноды — таймаут или ошибка API потеряет запись навсегда.

Стек для агентов: что использую в проде

Никакого экзотического фреймворка. Весь стек — стандартный Python-сервис.

Python 3.11. Не потому что единственный вариант — просто Claude API лучше всего задокументирован для Python, и большинство примеров кода на Python. Меньше трения при работе с Claude Code.

PostgreSQL 15. Агенты пишут туда всё: входящие запросы, результаты классификации, логи решений, очереди, метрики. В любой момент можно сделать SQL-запрос и понять что происходит. Никаких дополнительных дашбордов для отладки — только psql.

systemd. Каждый агент — отдельный юнит с Restart=always и RestartSec=30. Если агент падает — systemd поднимает через 30 секунд. Логи в journald: journalctl -u agent-instagram -f. Стандартный Linux-инструмент, работает предсказуемо.

Нет оркестратора. 14 агентов работают независимо — каждый тянет из своей PostgreSQL-очереди или запускается по таймеру через systemd timer. Нет центрального диспетчера, нет единой точки отказа. Упал один агент — остальные продолжают работать. Это важное архитектурное решение: с оркестратором типа Celery или Airflow падение диспетчера останавливает всё. Без него — только изолированный агент.

Claude API. claude-sonnet-4-6 для классификации (баланс скорости и качества), claude-opus-4-7 для генерации текстов где важно качество. За май 2026: $187 суммарно при 14 агентах и ежедневных сессиях разработки через Claude Code.

.env файлы через python-dotenv. API-ключи, строки подключения к PostgreSQL, токены Telegram — всё в .env, не в коде. Каждый агент читает нужные переменные при старте. При ротации токена — обновить .env, перезапустить systemd-юнит. Никакой правки кода, никакого нового деплоя.

Структура директорий. /opt/agents/ — все агенты. Каждый агент в своей папке: main.py, .env, requirements.txt, agent-name.service (systemd-юнит). Одинаковая структура у всех 14 агентов — легко разбираться в новом, легко передавать другому человеку. Claude Code при создании нового агента всегда смотрит в /opt/agents/ и копирует эту структуру.

Мониторинг: как я знаю что агенты работают

Самая большая проблема n8n была — узнавать об инцидентах от менеджеров, не от системы. У агентов это решено на уровне архитектуры.

Каждый агент при любой необработанной ошибке делает три вещи: записывает stacktrace в таблицу agent_errors в PostgreSQL, отправляет Telegram-сообщение в рабочий чат с типом агента и первыми 200 символами ошибки, и продолжает работать (если ошибка не критическая — пропускает одну запись и берёт следующую из очереди).

Это поведение прописано один раз в базовом классе BaseAgent и наследуется всеми 14 агентами. Новый агент автоматически получает правильное поведение при ошибках без дополнительного кода. В n8n нужно было добавлять Error Trigger ноду в каждый workflow вручную — и я это не делал, потому что лень. Результат: 2–3 тихих инцидента в месяц. После перехода на агентов с наследуемым error handling — ноль тихих инцидентов за 3 месяца.

Отдельный мониторинг-агент каждые 5 минут проверяет: все ли 14 systemd-сервисов активны, есть ли записи со status='pending' старше 30 минут (признак зависшей обработки), не выросла ли очередь ошибок за последний час. При отклонении — алерт в Telegram.

Среднее время обнаружения инцидента после перехода: 5 минут вместо 8 часов. За 3 месяца после перехода: 0 тихих инцидентов. Все падения агентов обнаружены и починены в тот же день.

Что выбросил полностью

При ревизии нашёл 4 zombie-workflow: работают, но не нужны.

Первый отправлял ежедневный email с выгрузкой бронирований. Проверил статистику: последнее открытие — 7 месяцев назад. Данные смотрю в PostgreSQL напрямую или через дашборд инвесторов. Удалён.

Второй синхронизировал данные между двумя таблицами PostgreSQL, дублируя записи которые уже появлялись там через другой workflow. Появился как временный костыль при миграции схемы БД в 2024-м. Миграция давно завершена, костыль остался работать и накопил 14 GB дублей за год. Удалён.

Третий публиковал посты VK через API. VK-аккаунт заблокировали в ноябре 2024. Workflow исправно пытался публиковать каждую неделю и тихо падал с ошибкой 403. 7 месяцев тихих падений которые никто не читал. Удалён.

Четвёртый пинговал сторонний сервис мониторинга цен на аренду. Сервис закрылся в августе 2024. Workflow падал но не критично — просто тратил ресурсы. Удалён.

Это типичная картина роста: автоматизации живут дольше контекста в котором создавались. Раз в квартал стоит делать аудит — какие workflow реально используются, какие тихо падают, какие решают задачу которой больше нет. Я не делал такой аудит 12 месяцев — нашёл 4 зомби.

Результаты за 3 месяца

Цифры за февраль–апрель 2026 года в сравнении с ноябрём–январём 2025–2026:

• Время обслуживания автоматизации в неделю: с 4–5 часов до 35–40 минут
• Инциденты без уведомления: с 2–3 в месяц до 0
• Точность классификации входящих лидов: с ~60% до ~89%
• Среднее время обнаружения инцидента: с 8 часов до 5 минут
• Стоимость: $22/мес VPS n8n + $140–187/мес Claude API. Итого $162–209/мес против $22/мес только n8n раньше
• Время добавления нового сценария: с 2–4 часов на n8n-граф до 1–2 часов Python + 30 минут деплой

Главный выигрыш — наблюдаемость. Каждый агент ведёт лог каждого решения в PostgreSQL: что пришло, что классифицировано, что отправлено в ответ, какая ошибка если была. Я могу в любой момент посмотреть почему агент принял конкретное решение 3 недели назад. В n8n для этого нужна была отдельная структура логирования.

Юрий Солар, основатель Solar Property: «Переход с n8n на агентов — это не замена инструмента. Это решение перестать обслуживать автоматизацию и начать её использовать. Разница в том, кто кем управляет.»

Где оставляю n8n

Есть задачи где n8n лучше агентов — и я не планирую их переносить.

ETL без логики. Выгрузить данные из PMS eZee, преобразовать формат, записать в PostgreSQL. Нет решений, нет текста, нет классификации. n8n делает это надёжно, и визуальный граф позволяет за 30 секунд понять что происходит — удобно при онбординге.

SaaS-интеграции через встроенные коннекторы. Подключить Calendly к уведомлению в Telegram, Stripe к записи в Google Sheets. n8n имеет 400+ встроенных коннекторов с готовой обработкой OAuth. Писать OAuth-flow руками на Python — 4–6 часов на каждую интеграцию. Нет смысла.

Сложные OAuth-цепочки. Refresh-токены с автоматическим обновлением, многошаговая авторизация, подписи запросов. n8n справляется из коробки.

Мой принцип: если workflow рисуется как блок-схема без ветвлений «в зависимости от смысла сообщения» — n8n. Если появляется «а что если содержимое запроса...» — это задача для агента.

Ещё одно применение n8n которое не планирую менять — быстрое прототипирование новых интеграций. Когда нужно проверить идею «а можно ли получить данные из этого API?» — в n8n я делаю это за 10 минут через HTTP Request ноду без единой строки кода. Если идея подтвердилась и нужна логика — переношу в Python-агента. n8n как песочница для новых интеграций, агенты как прод. Это неочевидное разделение, которое у меня сложилось само собой за первые 2 месяца после перехода.

Итог

Переход с n8n на агентов — не замена одного инструмента другим. Это решение использовать каждый там где он сильнее. n8n для детерминированных сценариев: webhook-приём, маппинг данных, ETL, SaaS-интеграции из коробки. Агенты на Python + Claude — для всего что требует понимания контекста, суждения или диалога.

Три месяца после перехода: 40 минут обслуживания в неделю вместо 4–5 часов, 0 тихих инцидентов, точность классификации входящих с 60% до 89%, время обнаружения инцидентов с 8 часов до 5 минут. Конкретные числа из конкретного бизнеса с 200 входящими в месяц и 9 виллами на Бали.

Неожиданный бонус который не ожидал: скорость экспериментов. Чтобы попробовать новую логику классификации в n8n — открыть редактор, найти Function-ноду, отредактировать JS-код, сохранить, тестировать вручную. В Python-агенте — изменить промпт в .txt файле, перезапустить systemd-юнит (systemctl restart agent-instagram), смотреть результаты в PostgreSQL через psql. Цикл итерации сократился с 20–30 минут до 3–5 минут. За 3 месяца я сделал 47 итераций промпта для классификатора входящих лидов — то что в n8n заняло бы месяц.

Если сейчас 10+ workflow на n8n и всё больше времени уходит на их поддержку — это не значит что n8n плохой. Это значит что часть задач переросла то для чего n8n создавался. Разберите workflow по критерию «нужно ли здесь суждение» — и станет ясно что переносить, что оставить, а что выбросить вообще.

О похожей трансформации операционки — в статье AI-агент вместо операционного менеджера. О том как писать агентов через Claude Code без найма разработчика — в отдельном материале.

Главный вывод который я сделал за эти 3 месяца: автоматизация — это не про выбор правильного инструмента. Это про понимание границы между детерминированными триггерами и суждениями на основе контекста. n8n отлично делает первое. AI-агенты на Python + Claude — второе. Используйте каждый для своего, и обслуживание автоматизации перестанет быть отдельной еженедельной работой которая съедает 4–5 часов.

Детали архитектуры, примеры кода агентов, шаблоны AGENTS.md для разных типов задач, промпты-классификаторы с реальными данными — в клубе «Solar — внутрянка». Раз в неделю — новый артефакт из рабочей системы Solar. Бери и адаптируй под свой бизнес: https://4bos.ru/inside/

— Solar OS.