n8n с AI-агентами на своём сервере

MAATRIX

Обычный сценарий n8n делает то, что вы нарисовали мышью. AI-агент решает сам: какой инструмент вызвать, сколько раз и в каком порядке — и потому ломается там, где линейный workflow живёт годами. Разберём, как собрать n8n с AI-агентами на своём сервере, чтобы он не падал по таймауту прокси, не убивался OOM-киллером и не раздувал базу.

Чем AI-агент в n8n отличается от узла с моделью

Узел Basic LLM Chain — один запрос: подали текст, получили ответ. Узел AI Agent — цикл, к которому подключаются суб-узлы трёх типов: Chat Model, Memory и произвольное число Tool. n8n собирает описания инструментов в JSON-схемы и отдаёт модели вместе с системным промптом; модель возвращает не текст, а tool_call — имя инструмента и аргументы; n8n выполняет узел, кладёт результат в контекст и снова спрашивает модель — до финального ответа или до лимита итераций.

Отсюда три следствия:

• Одно выполнение — не один запрос к API, а от трёх до пятнадцати. Агент с тремя инструментами и парой уточнений съедает 8–12 обращений к модели.
• Время меряется минутами. На gpt-4o-mini те же три вызова укладываются в 20–40 секунд, на рассуждающих моделях — 2–5 минут.
• Payload растёт нелинейно. Каждая итерация тащит весь контекст: выполнение агента в таблице execution_data весит 80–300 КБ против 2–5 КБ у обычного.

Лимит итераций — Options → Max Iterations, по умолчанию 10. Когда модель зацикливается, в интерфейсе появляется ровно это:

Error: Agent stopped due to max iterations.

Ради чего агенты в n8n имеют смысл — выражение $fromAI(): ставится в поле любого узла-инструмента и означает «пусть модель подставит значение сама».

{{ $fromAI('subject', 'Тема письма на русском, до 60 знаков', 'string') }}

Аргументы — ключ, описание, тип. По описанию модель и понимает, что класть в поле.

Почему агента держат на своём сервере, а не в облаке

Первое — доступ. Из российского IP запрос к OpenAI не проходит:

{"error":{"code":"unsupported_country_region_territory",
"message":"Country, region, or territory not supported",
"type":"request_forbidden"}}

Anthropic отдаёт похожий отказ, настройками n8n это не лечится. Лондонская нода закрывает вопрос: RTT до api.openai.com и api.anthropic.com оттуда 8–20 мс, а IP — обычный европейский дата-центр, а не выходной узел VPN, которые провайдеры моделей банят.

Второе — счётчик: агент даёт сотни выполнений там, где обычная автоматизация даёт десятки, а в облаке выполнение и есть единица тарификации. Третье — токены к почте, CRM и платёжкам лежат у вас.

Четвёртое — инструменты: community-узлы отдаются агенту как Tool только на self-hosted и только с N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE=true. Без этой переменной узел работает в обычном сценарии, но в списке инструментов агента не появится.

Честный минус: обслуживание ваше — релизы почти еженедельные, ломающие изменения в AI-узлах случаются, бэкапы за вас никто не сделает.

Конфигурация: compose с Postgres, Redis и воркером

SQLite по умолчанию для агентов не годится: блокируется на записи, а агент пишет в базу на каждой итерации. Нужен Postgres и режим очереди.

x-n8n-env: &n8n-env
  N8N_HOST: n8n.example.com
  N8N_PROTOCOL: https
  WEBHOOK_URL: https://n8n.example.com/
  N8N_ENCRYPTION_KEY: ${N8N_ENCRYPTION_KEY}
  N8N_PROXY_HOPS: 1
  DB_TYPE: postgresdb
  DB_POSTGRESDB_HOST: postgres
  DB_POSTGRESDB_PASSWORD: ${PG_PASS}
  EXECUTIONS_MODE: queue
  QUEUE_BULL_REDIS_HOST: redis
  N8N_RUNNERS_ENABLED: "true"
  N8N_DEFAULT_BINARY_DATA_MODE: filesystem
  EXECUTIONS_DATA_PRUNE: "true"
  EXECUTIONS_DATA_MAX_AGE: 168
  EXECUTIONS_DATA_SAVE_ON_SUCCESS: none
  N8N_COMMUNITY_PACKAGES_ALLOW_TOOL_USAGE: "true"
  NODE_OPTIONS: --max-old-space-size=1536

services:          # postgres:16-alpine и redis:7-alpine — как обычно
  n8n:
    image: docker.n8n.io/n8nio/n8n:1.117.3
    restart: unless-stopped
    ports: ["127.0.0.1:5678:5678"]
    environment: *n8n-env
    volumes: [./n8n-data:/home/node/.n8n]

  n8n-worker:      # тот же образ и анкор
    image: docker.n8n.io/n8nio/n8n:1.117.3
    command: worker --concurrency=5
    environment: *n8n-env

Тег фиксируйте явно (номер — на hub.docker.com/r/n8nio/n8n/tags): на latest вы однажды придёте к сломанным AI-узлам. Три места, где спотыкаются все:

• N8N_ENCRYPTION_KEY задавайте руками (openssl rand -hex 32) и храните отдельно. Если ключ придумает n8n, а каталог .n8n потеряется, креды станут нечитаемым мусором.
• Права на том. Контейнер работает от uid 1000: до первого старта chown -R 1000:1000 ./n8n-data, иначе получите EACCES: permission denied, mkdir '/home/node/.n8n' и рестарт-петлю.
• Порт 5678 наружу не открывать — в compose он на 127.0.0.1, снаружи только ufw allow 22/tcp и ufw allow 80,443/tcp. Живость проверяет curl -s http://127.0.0.1:5678/healthz → {"status":"ok"}.

Базовую установку разбирали пошагово на Ubuntu 24.04.

Собираем первого агента: модель, память, инструменты

Триггер. Для интерактивного агента — Chat Trigger (виджет по адресу вида https://n8n.example.com/webhook/<id>/chat), для фонового — Webhook или Schedule.

Chat Model. Ключевой параметр не модель, а temperature: для агента 0–0.3. На 0.7 модель творчески переименовывает аргументы, и вызовы отваливаются.

Memory. Главная ловушка self-hosted. Узел Simple Memory хранит историю в памяти процесса, и в режиме очереди сообщение может попасть на другой воркер — агент забывает разговор через раз, без единой ошибки в логах. Симптом: пользователь пишет «а теперь то же, но за июль», агент отвечает «что именно?». Лечится заменой на Postgres Chat Memory или Redis Chat Memory; ключ сессии привязывайте к {{ $json.chatId }}, не к executionId.

Tool. Инструментом может быть почти любой узел: HTTP Request Tool, Postgres Tool, Gmail, Telegram, Code Tool, Call n8n Sub-Workflow Tool. Практика, экономящая часы отладки: описание важнее реализации: модель выбирает инструмент по полю Description. «Получить данные» — источник неверных вызовов; «Возвращает остаток на складе по артикулу вида AB-12345, для поиска по названию не использовать» — рабочее описание.

Системный промпт держите коротким: роль, запреты, формат ответа, язык — простыни на 3000 слов топят описания инструментов. В Code Tool внешние npm-модули запрещены; разрешайте точечно (NODE_FUNCTION_ALLOW_EXTERNAL=cheerio,luxon), а не через *: узел исполняет то, что придумала модель.

RAG: векторная база рядом с n8n

Как только агенту нужны документы, появляется вектор-стор. pgvector — расширение того же Postgres:

CREATE EXTENSION IF NOT EXISTS vector;

Узел PGVector Store дальше создаёт таблицу сам: нового сервиса нет, бэкап тем же pg_dump. Минус — свыше миллиона чанков поиск проседает без настройки HNSW.

Qdrant — отдельный контейнер:

  qdrant:
    image: qdrant/qdrant:v1.12.4
    ports: ["127.0.0.1:6333:6333"]
    environment: { QDRANT__SERVICE__API_KEY: "${QDRANT_KEY}" }
    volumes: [./qdrant:/qdrant/storage]

Без QDRANT__SERVICE__API_KEY у Qdrant нет авторизации вообще — откроете 6333 наружу, и коллекцию прочитает и сотрёт любой. Базовый URL для n8n — http://qdrant:6333.

Эмбеддинги для русского дешевле всего у OpenAI: text-embedding-3-small, 1536 измерений. Размерность коллекции обязана совпадать с моделью, иначе прилетит:

ERROR: expected 1536 dimensions, not 768

Значит, коллекцию создавали под другую модель — например под nomic-embed-text из Ollama; пересоздавайте её, а не правьте параметры. Разбиение — Recursive Character Text Splitter, 1000 символов, перекрытие 150.

Что ломается на проде: пять реальных сбоев

1. 504 на четвёртой минуте. Агент думает дольше минуты, nginx его убивает:

upstream timed out (110: Connection timed out) while reading response header from upstream

Дефолт proxy_read_timeout — 60 секунд. Рабочий блок:

location / {
    proxy_pass http://127.0.0.1:5678;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_read_timeout 3600s;
    proxy_buffering off;
}

proxy_buffering off обязателен: иначе потоковый ответ копится в буфере и приезжает одним куском после минуты молчания. Если интерфейс не обновляется вживую — N8N_PUSH_BACKEND=sse.

2. connect ECONNREFUSED 127.0.0.1:11434. Классика связки с локальной моделью: n8n в контейнере, Ollama на хосте, а localhost из контейнера ведёт в сам контейнер. Либо поднимите Ollama сервисом в том же compose (http://ollama:11434), либо добавьте extra_hosts: ["host.docker.internal:host-gateway"] и адрес http://host.docker.internal:11434. Плюс на хосте OLLAMA_HOST=0.0.0.0:11434 — иначе Ollama слушает только петлю. Подробнее — в разборе запуска LLM через Ollama.

3. JavaScript heap out of memory. n8n падает целиком, в docker logs:

FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory

Причина почти всегда одна: агент затащил в контекст бинарник или простыню HTML. Меры — N8N_DEFAULT_BINARY_DATA_MODE=filesystem, N8N_PAYLOAD_SIZE_MAX=16 и лимит heap в NODE_OPTIONS. Норма в покое:

NAME         CPU %   MEM USAGE / LIMIT
n8n          0.51%   412.3MiB / 7.76GiB
n8n-worker   0.33%   377.8MiB / 7.76GiB
postgres     0.02%   58.4MiB / 7.76GiB

На 2 ГБ RAM первый же прогон индексации даст Out of memory: Killed process (node) в dmesg | grep -i oom.

4. База пухнет. Смотрим:

SELECT pg_size_pretty(pg_total_relation_size('execution_data'));

Две тысячи выполнений агента в неделю — легко 1,5–2 ГБ. Отсюда EXECUTIONS_DATA_SAVE_ON_SUCCESS=none: храним только упавшие прогоны.

5. 429 от провайдера. Агент делает десять вызовов подряд и ловит лимит:

Rate limit reached for gpt-4o-mini in organization org-xxxx on tokens per min (TPM)

Лечится не ретраями в лоб, а параллелизмом: --concurrency=5 у воркера и Retry On Fail с задержкой 2000 мс на узле модели. Если агентов несколько — шлюз с балансировкой ключей, LiteLLM. Остальные поломки — в статье про частые ошибки n8n.

Какой сервер взять под n8n с AI-агентами

Считать надо от того, где живёт модель.

Модель по API — основной сценарий. Тяжёлое считает провайдер, ваш сервер оркестрирует. Честный минимум: 2 vCPU, 4 ГБ RAM, 50 ГБ NVMe — n8n, Postgres и Redis без воркера, 3–5 параллельных выполнений, пара сотен запусков в сутки. На 2 ГБ не лезьте: n8n с LangChain-узлами стартует с 400 МБ, а пик при разборе документа уходит за гигабайт.

Комфортный вариант — 4 vCPU, 8 ГБ RAM, 80 ГБ NVMe. Помещается отдельный воркер с --concurrency=5, RAG на pgvector или Qdrant до сотен тысяч чанков и запас на пиковые payload.

Локальная модель — отдельный разговор. На VPS без GPU qwen2.5:7b-instruct-q4_K_M (4,7 ГБ на диске, ~6 ГБ в RAM) на 8 vCPU даёт по ollama run --verbose порядка eval rate: 6.12 tokens/s: ответ на 300 токенов — минута, агент с тремя вызовами — три-пять минут. Для ночной классификации писем приемлемо, для интерактивного чата нет. Плюс модели меньше 7B регулярно ломают формат вызова: Received tool input did not match expected schema. Вывод: CPU-модель — для фона, агенты в реальном времени живут на API.

Локация — UK, Лондон. Прямой доступ к API OpenAI, Anthropic, Google и Mistral без региональных отказов; RTT до европейских SaaS, с которыми агент работает через инструменты, — 10–30 мс; юрисдикция, спокойная и для антифрода платёжек, и для GDPR-контуров клиентов. Нью-Йорк уместен, если инструменты дёргают американские API. RU — только когда модель у отечественного провайдера, а данные обязаны оставаться в РФ по 152-ФЗ.

Оплата — картой российского банка, по СБП, криптой или токеном MAAT; зарубежная карта не нужна. Сомневаетесь в конфигурации — опишите профиль агентов, посчитаем память. Смежное: VPS в Великобритании для нейросетей и AI.

Частые вопросы