Практический разбор AI Agent в n8n: четыре паттерна агентов, LangChain.js под капотом, self-hosted Docker, Ollama для локальных LLM и память агента.
Обновлено: 12 июня 2026
n8n в 2026 году стал визуальным движком для AI-воркфлоу на базе LangChain.js. Узел AI Agent оборачивает агентные примитивы (инструменты, память, парсеры вывода) в стандартный canvas n8n и работает с любым провайдером: OpenAI, Anthropic, Google или локальные модели через Ollama. В этом руководстве я разбираю архитектуру AI-узлов, четыре практических паттерна агентов, настройку self-hosted в Docker и подводные камни, на которые я наступила за последний год в продакшене.
sessionKey и contextWindowLength, это ключ к контролю над затратами на токены.http://host.docker.internal:11434 и закрывают задачи высокого объёма, где не нужен фронтир.Узел AI Agent в n8n играет роль root-узла, который связывает языковую модель, набор инструментов и память в один исполняемый агент. По сути это LangChain-агент, собираемый мышью: вы перетаскиваете на canvas AI Agent, подключаете к нему sub-узлы (Chat Model, Memory, Tool) и получаете рабочий цикл reasoning → tool call → observation → next step. Никакой Python и никакого ручного промпт-инжиниринга для самого ReAct-цикла не требуется.
В моей практике именно это разделение root/sub-узлов делает n8n удобным для команды: разработчик собирает узел AI Agent один раз, а аналитик потом меняет инструменты и системный промпт без правки кода. На уровне реализации root-узел дёргает LangChain.js chat models и оркестрирует sub-узлы как providers. Это видно в трейсах исполнения, где каждый шаг рендерится отдельной итерацией.
Важный нюанс. AI Agent — это не одна «волшебная коробка». Под ним скрывается четыре разных типа агента (см. ниже), и от выбора зависит и латентность, и счёт за токены. Я видела команды, которые ставят Plan-and-Execute на каждый чих и удивляются, почему счёт от Anthropic вырос в 5 раз, а им хватило бы простого Tools-агента.
n8n использует иерархическую модель: cluster nodes (root) определяют основную логику, а sub-nodes предоставляют провайдеров для конкретных возможностей (языковой модели, памяти, эмбеддингов, retriever'а, output-парсера). Это прямой перенос архитектуры LangChain.js в визуальный редактор: каждое поле, которое в коде вы передаёте в AgentExecutor, в n8n становится отдельным портом узла.
На canvas это выглядит как звезда: в центре AI Agent, по периметру Chat Model (например, Anthropic Claude), Memory (Buffer Window или Postgres Chat Memory), три-четыре Tool-узла (HTTP Request Tool, Workflow Tool, Vector Store Tool) и опциональный Output Parser. Когда срабатывает trigger, n8n сериализует это в LangChain-граф и запускает один executor. Никаких ручных вызовов API между узлами не происходит, всё идёт через единый event loop.
Из 70+ AI-узлов в каталоге 2026 года я регулярно использую около десяти: Chat Trigger, AI Agent, Anthropic/OpenAI/Ollama Chat Model, Vector Store (Qdrant), Embeddings (OpenAI или локальные), Buffer Window Memory, Workflow Tool и HTTP Request Tool. Остальное это либо нишевые интеграции (Cohere Rerank, MongoDB Atlas Vector), либо устаревшие узлы первой волны. Если вы только начинаете, начните с этих десяти и закроете 90% задач. Подробнее про подбор векторного хранилища я писала в сравнении векторных БД 2026 года.
Узел AI Agent в n8n поддерживает четыре режима: Conversational, ReAct, Plan-and-Execute и Tools. Выбор тут не вопрос вкуса, а вопрос компромисса между интеллектом, латентностью и стоимостью.
| Тип агента | Когда использовать | Латентность | Стоимость токенов | Поддерживает инструменты |
|---|---|---|---|---|
| Conversational | Чат-боты без внешних действий | Низкая | Низкая | Нет |
| Tools | Один-два tool call на запрос, понятные действия | Низкая/средняя | Средняя | Да (native) |
| ReAct | Многошаговые задачи с явным reasoning | Средняя | Высокая | Да (через промпт) |
| Plan-and-Execute | Длинные исследовательские задачи | Высокая | Очень высокая | Да |
Мой эвристический выбор. Tools-агент по умолчанию (он использует нативный function calling провайдера и экономит токены), ReAct когда нужно увидеть цепочку рассуждений в логах для дебага, и Plan-and-Execute только для задач длиннее 5 шагов. Conversational подходит для случаев, когда вы хотите просто «обёртку над LLM», а не агента. Подробный разбор различий между подходами я давала в руководстве по Function Calling и Tool Use.
На уровне применения я обычно собираю эти четыре сценария:
Community-редакция n8n распространяется под Sustainable Use License и бесплатна для self-hosted развёртывания. Запуск в Docker Compose это файл из 30 строк, который поднимает n8n, Postgres для хранения воркфлоу и опционально Qdrant для векторного поиска.
# docker-compose.yml: минимальная конфигурация n8n + Postgres + Qdrant
services:
postgres:
image: postgres:16
restart: unless-stopped
environment:
POSTGRES_USER: n8n
POSTGRES_PASSWORD: change_me_in_prod
POSTGRES_DB: n8n
volumes:
- postgres_data:/var/lib/postgresql/data
n8n:
image: n8nio/n8n:latest
restart: unless-stopped
ports:
- "5678:5678"
environment:
DB_TYPE: postgresdb
DB_POSTGRESDB_HOST: postgres
DB_POSTGRESDB_DATABASE: n8n
DB_POSTGRESDB_USER: n8n
DB_POSTGRESDB_PASSWORD: change_me_in_prod
N8N_ENCRYPTION_KEY: replace_with_32_byte_random_hex
N8N_HOST: n8n.example.com
WEBHOOK_URL: https://n8n.example.com/
GENERIC_TIMEZONE: Europe/Moscow
volumes:
- n8n_data:/home/node/.n8n
depends_on:
- postgres
qdrant:
image: qdrant/qdrant:latest
restart: unless-stopped
ports:
- "6333:6333"
volumes:
- qdrant_data:/qdrant/storage
volumes:
postgres_data:
n8n_data:
qdrant_data:
Несколько практических замечаний из боевого опыта. Во-первых, N8N_ENCRYPTION_KEY должен быть сгенерирован один раз и сохранён в менеджере секретов. Если потеряете, все сохранённые credentials придётся вводить заново. Во-вторых, для продакшена обязательно вынесите n8n за reverse proxy с HTTPS (Caddy или Traefik, оба настраиваются за 10 минут). В-третьих, для нагрузки больше пары сотен выполнений в минуту переключайтесь на queue mode с Redis и отдельными worker-контейнерами. Это официально задокументированный паттерн.
Ollama это локальный рантайм для LLM с OpenAI-совместимым REST API. В связке с n8n он закрывает класс задач, где не нужен фронтир: классификация писем, извлечение сущностей из коротких текстов, генерация черновиков. Узел Ollama Chat Model подключается к адресу http://host.docker.internal:11434 (если n8n в Docker, а Ollama на хосте) или к имени сервиса в Compose, если оба контейнера в одной сети.
Мой бенчмарк на типичном email-triage пайплайне. Claude Haiku 4.5 даёт 380 мс на запрос, $0.0008 за тысячу запросов. Llama 3.1 8B на локальном RTX 4090 показывает 220 мс, $0 за запросы (но электричество и амортизация). На 50 000 запросов в месяц локалка окупает железо за 4 месяца, на 1 000 запросов никогда. Считайте unit-экономику до того, как закупаете GPU.
Архитектурный паттерн, который я ставлю чаще всего, это двухступенчатая маршрутизация. Первый AI Agent на Ollama решает «эта задача требует фронтира?». Если да, передаёт во второй AI Agent на Claude Sonnet через Workflow Tool, если нет, обрабатывает сам. На реальных данных в среднем 70-80% запросов закрываются локально, и счёт от провайдера падает в 3-4 раза без потери качества на сложных кейсах.
Память в n8n живёт в отдельном sub-узле, который подключается к AI Agent. Базовый вариант это Buffer Window Memory с параметрами sessionKey (привязка к пользователю или треду из Chat Trigger) и contextWindowLength (сколько последних сообщений хранить). Для долговременной памяти есть Postgres Chat Memory, Redis Chat Memory и MongoDB Chat Memory. Выбор зависит от того, что у вас уже стоит в стеке.
Подводный камень. contextWindowLength измеряется в сообщениях, а не в токенах. Если у вас длинные сообщения, окно в 20 реплик легко превысит контекст модели. Я обычно ставлю 10-15 и добавляю summarization-узел, который сжимает старые сообщения в краткий контекст. Это базовый паттерн контекстного инженерства. Подробнее про управление памятью писали мои коллеги в статье о мульти-агентных AI-системах.
Для RAG-сценариев нужно отдельное векторное хранилище. n8n поддерживает Qdrant, Pinecone, Weaviate, Supabase Vector, pgvector, MongoDB Atlas Vector и Milvus как нативные узлы. Для self-hosted я по умолчанию выбираю Qdrant: он живёт в одном Docker Compose рядом с n8n, имеет фильтрацию по метаданным и hybrid search из коробки. Если бэкэнд и так на Postgres, pgvector проще операционно (не нужен ещё один сервис).
Сборка занимает четыре узла: Webhook → Embeddings (OpenAI) → Vector Store (Qdrant) Retrieve → AI Agent с инструментом Vector Store Tool. Документы заливаются отдельным воркфлоу: Cron Trigger → Read Binary Files → Text Splitter → Embeddings → Vector Store Insert. Это две связанные пайплайны: одна для индексации (offline), вторая для запросов (online).
Короткий ответ: n8n даёт визуальный LangChain в self-hosted, тогда как Zapier предлагает AI Actions поверх готовых интеграций без контроля над агентным циклом. Длинный ответ в таблице.
| Возможность | n8n (self-hosted) | Zapier |
|---|---|---|
| AI Agent с tool use | Да (LangChain.js, 4 режима) | Ограниченно (Zapier AI Actions) |
| Векторные БД как узлы | 7 нативных интеграций | Нет (нужны API через HTTP) |
| Локальные LLM (Ollama) | Да, нативный узел | Нет |
| Self-hosted | Да, бесплатно (Community Edition) | Нет (только облако) |
| Цена при 30k запусков/мес | ~$5 (VPS) | $73+ (Pro) |
| Версионирование (JSON) | Да, git-friendly | Ограниченно |
| Кривая обучения | Средняя | Низкая |
Честный tradeoff. Zapier выигрывает на скорости первичной сборки и количестве готовых интеграций для нетехнических пользователей. n8n выигрывает на контроле, цене и сложных AI-воркфлоу. Я выбираю n8n каждый раз, когда заказчик готов на DevOps-минимум (Docker Compose, домен, бэкап Postgres). Если этого нет, Zapier или Make.com экономят месяц найма.
За год консультаций я повторно вижу одни и те же грабли в AI-воркфлоу на n8n.
Wait с webhook-апрувом. Один ложный tool call, и у клиента 200 удалённых строк. Я этот сценарий хлебнула на проекте по очистке CRM, с тех пор апрув обязателен.maxIterations. По умолчанию AI Agent делает до 10 итераций, и зацикленный ReAct может сжечь $20 за один запрос. Ставьте 4-5 и логируйте превышения.Retry On Fail с экспоненциальным бэк-оффом на всех узлах Chat Model.N8N_LOG_LEVEL=debug на стейджинге и отправляйте трейсы агента в Langfuse через HTTP Request. Без этого вы не отладите сложные multi-tool сценарии.Да. n8n поставляет нативный узел Anthropic Chat Model, который подключается к узлу AI Agent. Поддерживаются все актуальные модели семейства Claude 4.x, включая Opus 4.8, Sonnet 4.6 и Haiku 4.5, через API-ключ из консоли Anthropic.
Community Edition бесплатна. На VPS за $5/мес помещается 50+ активных воркфлоу при умеренной нагрузке. n8n Cloud Pro стоит €60/мес за 30 000 выполнений. Разница 10-15x в пользу self-hosted, но вам нужен Docker и базовый DevOps.
Да, нативно. Узел Ollama Chat Model подключается к локальному рантайму по адресу http://host.docker.internal:11434 и работает с любой моделью, которую вы скачали через ollama pull (Llama 3.x, Qwen, Mistral, Phi и другие).
Обычный узел Chat Model делает один вызов модели и возвращает ответ. AI Agent добавляет цикл «reasoning → tool call → observation → next step», управление памятью и output-парсинг. Это исполнительный движок LangChain-агента, обёрнутый в визуальный узел.
Переключайтесь в queue mode: добавьте Redis как очередь, отделите main-инстанс (UI/API) от worker-инстансов и горизонтально масштабируйте воркеров. Это официально задокументированный паттерн, на нём работают команды с миллионами выполнений в месяц.
Практическое руководство по prompt caching в OpenAI, Anthropic и Gemini на 2026 год: цены, TTL, cache_control breakpoints, совместимость с tool use и мониторинг hit rate с примерами на Python.
Сравнение Langfuse, LangSmith и Arize Phoenix в 2026: self-host, OpenTelemetry, prompt management, LLM-as-Judge и реальные цены на 3M трейсов в месяц.
Как получить гарантированно валидный JSON от LLM в 2026: Structured Outputs OpenAI, tool use в Claude, responseSchema в Gemini, Pydantic через Instructor и эвалы перед продакшном.