n8n + Claude API: Автономия в маркетинговых операциях

Автоматизация в маркетинговых операциях давно вышла за пределы «отправить письмо вовремя». Когда LLM'ы вроде Claude 3.5 Sonnet попадают в production, настоящий вопрос не в том, сколько секунд потребовалось workflow'у, а в том, как ты спроектировал управление ошибками. Комбинация n8n + Claude API позволила нам генерировать 200+ статей без ручного вмешательства — но такой результат достигнут благодаря правильной архитектуре идемпотентности, retry-стратегии и отслеживанию состояния.

Определение автономного workflow'а

Автономный workflow — это система, которая выполняет свою задачу от начала до конца без участия человека. Если ты можешь сказать «запустить и забыть» — это автономно. В маркетинговых операциях это означает: выгрузить ключевые слова из Google Search Console, отправить их Claude, получить контент, закоммитить на GitHub, управлять версионированием — всё одним триггером.

n8n здесь выступает как orchestrator. Он срабатывает по webhook'у, хранит состояние между каждым шагом, при ошибке запускает retry-логику. Claude API — генератор контента, но его нужно настроить так, чтобы производство не требовало ручного контроля. Если ты хардкодишь prompt прямо в workflow, любое обновление означает редактирование 15 мест. Начни с версионирования prompt'а с самого начала.

В нашей установке n8n работает на бесплатном self-hosted инстансе. Пять workflow-узлов: webhook-триггер, HTTP-запрос (Claude API), трансформация данных, коммит на GitHub, логирование в Supabase. Полное выполнение занимает 3 минуты — 90 секунд уходит на генерацию Claude'ом 1500 слов, остальное на I/O.

Идемпотентность: один input, один output

Идемпотентность — гарантия того, что повторное выполнение одной операции не изменит результирующее состояние. В workflow'ах на основе LLM это не гарантируется по умолчанию — один prompt'у даст разные output'ы. Но операции с файловой системой и git должны быть идемпотентны.

Наш подход: каждый контент связан с уникальным идентификатором (i18nKey). i18nKey имеет формат {category}-{seq}-{YYYY-MM}. Workflow генерирует этот ключ, передаёт его Claude'у и использует для пути к файлу. Если второй раз запустить с тем же ключевым словом, workflow проверяет Supabase — если запись существует, SKIP, если нет, PROCESS.

// n8n Function node — проверка идемпотентности
const existingRecord = await $('Supabase').first().json.data.find(
  (r) => r.i18n_key === $json.i18nKey
);
if (existingRecord) {
  return { skip: true, reason: 'already_published' };
}
return { skip: false };

При коммите на GitHub также проверяется наличие файла. Если файл существует, возвращается 409 Conflict, error-handling узел ловит это и логирует — но workflow не останавливается. Таким образом, если в batch'е из 50 ключевых слов 3 уже обработаны, workflow обработает только оставшиеся 47.

Claude API: версионирование prompt'ов и бюджет токенов

Использование Claude API в production требует стабильности prompt'ов. Если ты захардкодишь prompt прямо в n8n, каждое обновление потребует ручного редактирования workflow'а. Вместо этого храни prompt'ы как Markdown-файлы на GitHub и загружай их по raw-URL.

Наша схема: файл prompts/roibase-master-ru.md на GitHub. HTTP Request узел n8n загружает этот URL, содержимое становится SYSTEM-сообщением для Claude'а. USER-сообщение генерируется динамически в workflow'е — ключевое слово, категория, список внутренних ссылок, текущая дата и другие контекстные переменные.

{
  "model": "claude-3-5-sonnet-20241022",
  "max_tokens": 200000,
  "system": "{{$node['Fetch_Prompt'].json.content}}",
  "messages": [
    {
      "role": "user",
      "content": "KEYWORD: {{$json.keyword}}\nCATEGORY: {{$json.category}}\n..."
    }
  ]
}

Бюджет токенов: context window Claude 3.5 Sonnet — 200K токенов. Наш prompt занимает 8K токенов (master prompt на русском + категориальные инструкции), USER-сообщение — 500 токенов, output Claude'а — в среднем 2.5K токенов (1500 слов). Итого ~11K токенов, cost per run при batch-pricing ~ $0.04. 200 статей = $8 на API.

Управление ошибками: retry, fallback и логирование состояния

В LLM-workflow'ах есть три класса ошибок: временные (rate limit), постоянные (некорректный output) и непредвиденные (network timeout). Встроенная логика n8n не различает эти три типа — тебе нужно спроектировать retry-стратегию самостоятельно.

Наш подход: для каждого узла включены retry-настройки. HTTP Request узел (Claude API) имеет retryOnFail: true, maxRetries: 3, waitBetweenTries: 5000ms. При rate limit (429) применяется экспоненциальная задержка. Если три попытки не удались, срабатывает error-catching узел — в Supabase пишется лог failed_generation, workflow останавливается, но обработка остальных ключевых слов продолжается.

Для некорректного output (Claude генерирует меньше 1400 слов или не хватает frontmatter'а) есть validation-узел. Он парсит JSON, проверяет поля readingTime и title. Если проверка не пройдена, Claude получает сообщение «regenerate with stricter length constraint» — на этот раз параметр max_tokens увеличивается. При второй неудаче запись попадает в очередь на ручную проверку.

Логирование состояния ведётся в Supabase по такой схеме:

Поле	Тип	Описание
`i18n_key`	text	Уникальный идентификатор
`keyword`	text	Запрос из GSC
`status`	enum	`pending`, `generated`, `failed`
`retry_count`	int	Количество retry'ев
`error_log`	jsonb	Детали ошибки
`created_at`	timestamp	Время первого запуска
`completed_at`	timestamp	Время завершения (NULL если ещё идёт)

Эта таблица используется как для мониторинга, так и для отладки. В Grafana на dashboard'е появляются записи с retry_count > 2 — так мы видим, на каких ключевых словах Claude постоянно застревает.

Production-опыт: 200+ статей, 4% failure rate

Первые 50 статей мы генерировали с ручным надзором. Следующие 150 — полностью автономно. Результаты:

Success rate: 96% (192/200)
Среднее время выполнения: 3.2 минуты
Rate limit hits: 7 раз (все успешно retried)
Требуется ручное вмешательство: 8 статей (некорректный output + неоднозначность ключевого слова)

50% failure'ов произошли из-за слишком generic ключевых слов (вроде «цифровой маркетинг»). На таких словах Claude пытается достичь 1500 слов, генерируя filler-контент — validation-узел это ловит, но regenerate не помогает. Такие ключевые слова мы добавляем в чёрный список.

Остальные 50% — это race condition в GitHub API (возвращается 409 Conflict: файл существует, но в Supabase нет записи). Мы решили эту проблему, добавив atomicity-проверку: перед коммитом на GitHub записываем pending-статус в Supabase, после успешного коммита обновляем на generated. Failure rate упал с 4% до 1.5%.

Профиль latency: 90 секунд — Claude API, 45 секунд — GitHub коммит (большие markdown-файлы), 15 секунд — запись в Supabase, 30 секунд — внутренняя обработка n8n'а. Самый медленный шаг — Claude, но параллелизм не нужен из-за rate limit. Мы используем batch-processing: 10 ключевых слов в час, 240 ключевых слов в день.

Trade-off'ы: что мы выиграли, что потеряли

При проектировании автономного workflow'а есть три основных компромисса:

Качество vs скорость: Качество output'а Claude'а зависит от tuning prompt'а. В первой версии rate reject был 40% — добавили в prompt правило «1400-1600 слов ОБЯЗАТЕЛЬНО», reject упал до 4%. Но теперь Claude иногда генерирует filler-контент. Человеческий редактор это заметит, AI — нет.
Стоимость vs надёжность: Агрессивная retry-логика увеличивает потребление токенов. Изначально при каждом retry отправлялся весь prompt (8K токенов × 3 = 24K). Сейчас при retry отправляется только USER-сообщение, SYSTEM кешируется (prompt caching — функция Claude от мая 2025). Стоимость упала на 60%.
Гибкость vs сложность: Хотели иметь отдельный prompt для каждой категории (AI-категория более техническая, marketing-категория более бизнес-ориентированная). Но это означало бы 6 файлов prompt'ов — nightmare версионирования. Решение: один master-prompt + категориальный блок CATEGORY_GUIDANCE, который append'ится в USER-сообщение. Сложность возросла, но гибкость тоже.

Будущее: multi-agent и self-healing

Текущая архитектура — single-agent (Claude работает один). В следующей итерации тестируем multi-agent: один agent генерирует контент, другой проводит review, третий оптимизирует SEO. n8n поддерживает sub-workflow'ы, но стоимость токенов возрастает в 3 раза.

Self-healing — это когда workflow анализирует причину сбоя и исправляет себя. Пример: если Claude постоянно генерирует короткий контент, добавить в prompt примечание «требуется больше длины», переозапустить. Это meta-оптимизация — LLM эволюционирует собственный prompt. Опасно, но эффективно.

В работе Roibase по First-Party Data & Attribution Architecture используется похожий подход: автономно собирай сигналы конверсии, обнаруживай аномалии, самовосстанавливайся. Строя автономные системы в production, базовый принцип един: спроектируй управление ошибками с самого начала, логируй состояние, сделай retry-логику идемпотентной.