n8n/Make vs кастомные агенты: выбор, отказ, миграция

n8n/Make выигрывают на детерминированных интеграциях и скорости запуска; кастомные AI-агенты — когда нужен язык, неоднозначный intent и tool-calling с политиками. Смешивать «всё в LLM» или «всё в no-code» без критериев — главная причина простоя при росте.

Я не выбираю стек по хайпу. Смотрю на долю if/then vs «понять человека», частоту смены правил, требования к audit и кто будет дежурить в 2 ночи. Ниже — практическая матрица, точки отказа и миграция без «большого взрыва».

---

Критерии выбора: не «модно», а измеряемо

Критерий	n8n / Make	Кастомный агент (LLM + tools)	Гибрид
Логика в основном правила и API	✅	избыточно	—
Вход — свободный текст/голос	слабо	✅	router → workflow
Нужен write в CRM/1С с политикой	✅ при явных шагах	✅ с guardrails	часто best
Time-to-first-value	дни	недели	зависит от scope
Vendor lock / self-host	n8n self-host силён	свой код	—
Наблюдаемость шагов	высокая	надо строить	строить на стыке
Стоимость при 10k событий/мес	предсказуемее	токены + infra	считать TCO
Команда без разработчика	✅	риск	low-code + подрядчик

Быстрый scorecard (сумма баллов 0–2 по каждому)

1. >70% кейсов закрываются правилами и шаблонами
2. Нет необходимости в multi-step reasoning
3. Критичен предсказуемый latency и $ за 1k runs
4. Нужен сложный диалог и уточнения
5. Разные tool-права и human-in-the-loop на money/legal
6. Есть владелец кода и on-call

Если 1–3 высокие, а 4–6 низкие → n8n/Make. Если 4–6 высокие → агент или гибрид. Споры «Make умер, всё на агентах» в 2026 я не разделяю: deterministic glue никуда не делся.

---

Точки отказа: где ломается каждый путь

n8n / Make

Отказ	Симптом	Что делаю
God-scenario	80+ модулей, никто не понимает	режу на sub-flow, naming, versioning
Silent fail	webhook 200, CRM пустая	явные error paths, dead-letter, алерты
Race / дубли	два update одного лида	идемпотентность, lock key
Секреты в UI	токены у half-team	vault, least privilege
LLM-нода «для красоты»	нестабильный JSON	schema validation + retry + fallback
Нет owner	«настроил подрядчик и исчез»	runbook + доступ + экспорт flow

Кастомные агенты

Отказ	Симптом	Что делаю
Prompt as policy	модель «сама решила скидку»	policy в коде, не только в тексте
Tool spaghetti	15 tools без ролей	whitelist, max steps, circuit breaker
Нет audit	«бот что-то написал клиенту»	session_id, tool args/result redacted
Handoff в никуда	оператор без контекста	пакет handoff + UI
Cost spike	review-агент жрёт бюджет	лимиты токенов, кэш, cheaper model на router
Eval отсутствует	релиз «на глаз»	gold-set, shadow, go/no-go

Гибрид (мой частый default)

• Router (rules или small model) →
• Deterministic workflow для статусов, счетов, синхронизаций →
• Agent только на языковой кусок →
• Guard перед write/send.

Так я не плачу токенами за то, что умеет if status == "paid".

---

Миграция без простоя: пошаговый контур

Цель — не «переписать всё за спринт», а переключить scope с возможностью отката.

Фаза 0 — инвентаризация (3–7 дней)

• Карта flows: trigger → systems → side-effects
• Топ-10 по объёму и топ-5 по деньгам/риску
• Где уже есть скрытый LLM / ручной костыль
• SLA и кто будитcя ночью
• Экспорт сценариев, секреты, зависимости API

Фаза 1 — strangler, не big bang

1. Выбираю один scope (например first-line FAQ или квалификация).
2. Поднимаю новый контур параллельно (shadow или % traffic).
3. Старый flow остаётся source of truth для write, пока не greened KPI.
4. Feature flag / split по каналу, тегу, % пользователей.
5. Откат = выключить flag, не «откатить миграцию БД».

Этап	Длительность (ориентир)	Критерий выхода
Shadow	7–14 дн.	расхождение <X% на gold + нет critical miss
Canary 10–30%	7–14 дн.	error budget, CSAT/re-open в норме
100% scope	3–7 дн.	runbook, on-call, дашборд
Decommission old	после 1–2 стабильных недель	архив flow + документ «как вернуть»

Фаза 2 — данные и идемпотентность

• Единый correlation_id / session_id сквозь n8n и агента
• Write-ключи: не создавать дубль лида при ретрае
• Очередь dead-letter + ручной replay
• Версионирование промптов/policy рядом с версией flow

Что не делать при миграции

• Менять CRM-схему и оркестратор в один релиз
• Отключать старый Make «с понедельника» без canary
• Переносить 40 сценариев разом «раз уж начали»
• Отдавать cutover без владельца бизнеса на связи

---

Чеклист go/no-go перед cutover

• KPI scope записаны заранее (автозакрытие, latency, cost/session)
• Алерты на error rate, queue lag, tool 5xx
• Human-in-the-loop на money/legal работает end-to-end
• Секреты ротированы, доступы least privilege
• Runbook: rollback <15 минут
• Оператор обучен новому handoff-пакету
• Юр./маркировка ИИ и логи хранятся по политике

---

Часто задаваемые вопросы

Можно ли оставить Make и «просто добавить агента»?

Да, и часто так лучше: агент как один HTTP/queue worker, Make остаётся клеем интеграций. Главное — не дублировать write из двух мест без координации.

Когда кастомный агент дешевле n8n на дистанции?

При высоком объёме однотипного языкового труда и хорошем кэше/роутере; при низком объёме и частых сменах API чаще дешевле no-code + точечный LLM.

Как мигрировать с Zapier/Make на n8n без простоя?

Тот же strangler: паритет сценария в shadow, сверка payload, canary по webhook source, затем DNS/flag. Не надеяться на «импорт 1:1» без тестов side-effects.

Нужен ли LangGraph, если есть n8n?

Только если есть граф решений с состоянием, retries и multi-role. Для линейного «форма → CRM → Telegram» n8n достаточно.

---

Читайте также

• Cloud.ru AI workflows: сравнение с n8n и Make
• n8n vs Zapier 2026: сравнение автоматизации
• Пайплайн заявка → результат: интеграции и эскалация
• AI-автоматизация бизнеса без программиста (Россия, 2026)

---

Нужен разбор «оставить Make / переписать / гибрид» под ваш объём и SLA — raisovich.ru

По каким критериям выбирать n8n/Make, а не кастомного агента?

Если больше 70% кейсов закрываются правилами и API, критичны предсказуемый latency и цена за run, а команда без сильной разработки — no-code быстрее и дешевле; LLM нужен там, где свободный текст и неоднозначный intent.

Что входит в strangler-миграцию без big bang?

Один scope параллельно со старым flow, shadow или canary по флагу, старый контур как source of truth для write до green KPI, откат = выключить flag, не откатывать схему БД.

Какие go/no-go пункты обязательны перед cutover?

Заранее записанные KPI scope, алерты и rollback до 15 минут, рабочий HITL на money/legal, least-privilege секреты, обученный оператор и runbook — без этого cutover в прод не делаю.