n8n (произносится «н-эйт-эн») — это платформа автоматизации рабочих процессов (workflow automation platform) с нативными возможностями для создания AI-агентов. Название происходит от сокращения слова «nodemation» — сочетания node (узел) и automation (автоматизация), где 8 букв между «n» и «n» заменены цифрой 8, аналогично известным сокращениям вроде i18n или l10n n8n Official Site.
Проект основан Яном Оберхаузером (Jan Oberhauser); первый публичный коммит датируется 2019 годом. Изначально n8n задумывался как инструмент для визуальной автоматизации, связывающий различные API и сервисы через графический интерфейс. Со временем платформа эволюционировала, добавив мощнейшую интеграцию с LangChain и превратившись в полноценную среду для создания AI-агентов n8n GitHub.
| Характеристика | Описание |
|---|---|
| Лицензия | Fair-code: Sustainable Use License (SUL) — исходный код открыт, но коммерческое использование крупными конкурентами ограничено |
| Интеграции | 400+ встроенных нод-коннекторов к различным сервисам и API |
| Развёртывание | Self-hosted (на собственной инфраструктуре) или n8n Cloud (SaaS) |
| Язык реализации | TypeScript / Node.js |
| AI-поддержка | Нативная интеграция с LangChain JS, поддержка множества LLM-провайдеров |
| Визуальный редактор | Drag-and-drop canvas на Vue 3 |
Позиционирование n8n формулируется как «flexibility of code with the speed of no-code» — гибкость программирования при скорости no-code разработки. Это означает, что разработчик может использовать визуальный конструктор для быстрого прототипирования, но при необходимости углубиться в код — писать кастомные ноды, использовать выражения (expressions), выполнять JavaScript или Python внутри workflow n8n Official Site.
В контексте AI-агентов n8n выделяется среди конкурентов (Zapier, Make) тем, что предоставляет не просто вызов LLM по API, а полноценную инфраструктуру для создания автономных агентов: с памятью, инструментами, векторными хранилищами и поддержкой мультиагентных паттернов n8n AI Agents.
Архитектурное устройство n8n имеет решающее значение для понимания того, как платформа выполняет workflows, масштабируется и обеспечивает расширяемость. Рассмотрим внутреннюю организацию кодовой базы и принципы проектирования.
Исходный код n8n представляет собой TypeScript монорепозиторий, построенный на pnpm workspaces и Turbo (Turborepo) для управления зависимостями и параллельной сборки пакетов. Такой подход позволяет единообразно версионировать взаимосвязанные пакеты и ускорять CI/CD за счёт кеширования результатов сборки DeepWiki n8n Architecture.
Монорепозиторий содержит следующие основные пакеты, каждый из которых отвечает за определённый слой функциональности:
Базовый пакет, определяющий фундаментальные абстракции всей системы: интерфейсы нод (INodeType), типы данных, параметры нод, систему expressions (выражений вида {{ $json.field }}). Этот пакет не зависит от конкретного окружения выполнения и используется всеми остальными пакетами DeepWiki n8n Platform Architecture.
Движок выполнения workflows. Отвечает за запуск нод в правильной последовательности, обработку ошибок, загрузку credential-объектов и инициализацию нод. Ядро координирует передачу данных между нодами согласно топологии графа workflow DeepWiki n8n Architecture.
Основной исполняемый пакет — точка входа приложения. Включает REST API сервер, взаимодействие с базой данных (PostgreSQL/MySQL/SQLite), обработку webhook-запросов, планировщик cron-задач, а также CLI-команды для запуска и управления экземпляром n8n n8n GitHub.
Коллекция из 400+ встроенных нод-интеграций (аппаратных коннекторов к внешним сервисам) плюс ~100 Core-нод (управляющая логика, трансформация данных) — итого более 500 нод в совокупности: GitHub, Slack, Telegram, Google Sheets, Jira, Salesforce, HTTP Request и множество других. Каждый узел реализует интерфейс INodeType и описывает свои параметры, credential-требования и логику выполнения n8n GitHub.
Специализированный пакет AI/LLM-нод, построенный поверх LangChain JS framework. Содержит корневые ноды (AI Agent, Chain, Vector Store) и подноды (Language Models, Memory, Tools, Embeddings, Document Loaders, Text Splitters, Output Parsers, Retrievers). Именно этот пакет превращает n8n в полнофункциональную платформу для AI-агентов LangChain in n8n Docs.
Визуальный редактор workflows на Vue 3 с drag-and-drop canvas. Реализован как SPA (Single Page Application), взаимодействует с бэкендом через REST API и WebSocket. Редактор отображает workflow как ориентированный граф, позволяя пользователю соединять ноды перетаскиванием DeepWiki n8n Architecture.
Схема конфигурации и валидация переменных окружения. Централизует описание всех настраиваемых параметров n8n, обеспечивая типобезопасность и автогенерацию документации по конфигурации DeepWiki n8n Platform Architecture.
Изолированная песочница (sandbox) для безопасного выполнения пользовательского кода — JavaScript и Python. Используется нодой Code для исполнения произвольных скриптов вне основного процесса n8n, предотвращая утечки памяти, бесконечные циклы и несанкционированный доступ к ресурсам сервера DeepWiki n8n Architecture.
AI-помощник для управления экземпляром n8n: помогает настраивать credentials, создавать workflows и конфигурировать экземпляр через естественный язык. Компоненты: InstanceAiService, InstanceAiAdapterService, DomainAccessApproval, CredentialSetup DeepWiki n8n Platform Architecture.
Архитектура n8n следует строгой слоистой модели без циклических зависимостей:
┌─────────────────────────────────────┐
│ Application Layer │ n8n (CLI), n8n-editor-ui
├─────────────────────────────────────┤
│ Core Layer │ n8n-core, @n8n/task-runner
├─────────────────────────────────────┤
│ Foundation Layer │ n8n-workflow, @n8n/config
└─────────────────────────────────────┘
Extension Packages
n8n-nodes-base, @n8n/nodes-langchain,
custom/community nodesПринцип направления зависимостей: верхний слой зависит от нижнего, но никогда наоборот. Пакет n8n-workflow (Foundation) ничего не знает о n8n-core или n8n. Пакет n8n-core зависит только от n8n-workflow. Основной пакет n8n зависит от обоих. Такая структура гарантирует отсутствие циклов и упрощает тестирование отдельных компонентов DeepWiki n8n Architecture.
Расширения (nodes-пакеты) зависят от n8n-workflow, реализуя его интерфейсы, но сами не являются частью ядра — они загружаются динамически во время выполнения.
Выбор модели выполнения критически влияет на производительность, отказоустойчивость и масштабируемость развернутого экземпляра n8n. Разработчику необходимо понимать обе модели, чтобы принимать обоснованное решение об архитектуре продакшен-разворачивания.
По умолчанию n8n работает в Regular Mode — однопоточном процессе, который обслуживает всё: пользовательский интерфейс, REST API, обработку webhook-запросов, выполнение scheduled-задач и собственно исполнение workflows. Все задачи обрабатываются последовательно в рамках одного процесса Node.js.
# Пример запуска в Regular Mode
npx n8n startПреимущества:
Ограничения:
Regular Mode приемлем для сред с невысокой нагрузкой и отсутствием жёстких требований к SLA. Официальная документация не приводит конкретных пороговых значений — решение о переходе на Queue Mode зависит от характера workflows и доступных ресурсов Queue Mode Docs.
Для высоконагруженных и mission-critical сценариев n8n предлагает Queue Mode — многопроцессную архитектуру с разделением ролей, использующую Redis как брокер сообщений и PostgreSQL как постоянное хранилище.
┌──────────────────┐
│ Main Process │
│ (API, UI, │
│ Webhooks, │
│ Timers) │
└────────┬─────────┘
│
Redis (Bull/BullMQ)
╱ ╲
┌──────▼──────┐ ┌─────▼────────┐
│ Worker 1 │ │ Worker N │
│(Execute WF) │ │ (Execute WF) │
└─────────────┘ └────────────────┘
┌──────────────┐
│Webhook Proc │ ← опционально, отделяет
│(HTTP inlet) │ inbound-трафик
└──────────────┘Main Process — центральный координатор. Принимает запросы к REST API, обслуживает Editor UI, регистрирует incoming webhook-маршруты и планирует timer/cron-задачи. Сам Main Process не выполняет workflows — он помещает задания в очередь Redis Queue Mode Docs.
Worker Processes — независимые процессы, подписанные на очередь заданий Bull в Redis. Каждый Worker извлекает следующее ожидающее выполнение workflow из очереди и исполняет его. Workers можно запускать на разных машинах, достигая горизонтального масштабирования.
# Переменные окружения для включения Queue Mode
N8N_QUEUE_BULL_REDIS_HOST=redis.local
N8N_QUEUE_BULL_REDIS_PORT=6379
DB_TYPE=postgresdb
DB_POSTGRESDB_HOST=postgresql.local
DB_POSTGRESDB_DATABASE=n8n
DB_POSTGRESDB_USER=n8n
DB_POSTGRESDB_PASSWORD=<password>
# Запуск Main процесса
npx n8n start
# Запуск Worker процесса (другая машина или тот же хост)
EXECUTIONS_MODE=queue npx n8n workerWebhook Process — выделенный процесс для обработки входящих HTTP-запросов. Если ваш workflow начинается с Webhook trigger, отделение обработки webhook-трафика от основного процесса снижает задержку ответа и повышает пропускную способность.
# Запуск выделенного Webhook Processor
EXECUTIONS_MODE=queue npx n8n webhookRedis выступает в роли message broker на базе библиотеки Bull/BullMQ (env-переменные используют префикс QUEUE_BULL_). Очередь обеспечивает приоритетизацию задач, повторные попытки при неудаче (retries), отложенное выполнение (delayed jobs) и мониторинг прогресса Queue Mode Docs.
PostgreSQL — единственная официально поддерживаемая БД для Queue Mode. SQLite не поддерживается, поскольку нескольким процессам нужен совместный доступ к одной реляционной базе данных с транзакционной целостностью Queue Mode Docs.
Каждый Worker одновременно обрабатывает до N8N_CONCURRENCY_PRODUCTION_LIMIT executions. По умолчанию установлено значение 10, однако для AI-heavy workflows (интенсивные вызовы LLM, долгие ожидания токенов) рекомендуется снизить до 5 и ниже, чтобы избежать исчерпания памяти и превышения rate-limit провайдеров API.
# Ограничение количества одновременных выполнений на Worker
N8N_CONCURRENCY_PRODUCTION_LIMIT=5Для обеспечения высокой доступности n8n допускает развёртывание нескольких Main процессов в режиме Leader/Follower. Только Leader обрабатывает записи (создание/обновление workflows); Followers обслуживают чтение API и UI. При падении Leader автоматически назначается новый Queue Mode Docs.
# На каждом Main-узле
N8N_MULTI_MAIN_SETUP_ENABLED=trueЭто особенно важно для enterprise-развёртываний, где downtime недопустим.
Нода (node) — элементарная единица работы в n8n. Каждая нода получает данные со входа, выполняет операцию и передаёт результат на выход. Связывая ноды друг с другом, пользователь строит направленный граф — workflow. Понимание типов нод и их назначения критически важно для эффективного проектирования workflows.
Trigger-ноды инициируют выполнение workflow. Они не имеют входов — только выходы. Workflow обязан содержать ровно одну trigger-ноду (за исключением случаев manual triggering).
| Trigger | Назначение |
|---|---|
| Webhook | Срабатывает при поступлении HTTP-запроса на зарегистрированный endpoint |
| Schedule | Выполняется по расписанию (cron или интервал) |
| Chat Trigger | Специальный триггер для чат-интерфейсов AI-агентов |
| Manual | Запускается вручную кнопкой «Test» в editor UI |
| Email Trigger (IMAP) | Срабатывает при получении email |
| Kafka Trigger | Подписка на сообщения Apache Kafka |
Webhook-trigger является одним из наиболее часто используемых — он создаёт публичный HTTPS-endpoint, на который могут отправляться данные из любого внешнего сервиса. Chat Trigger специально оптимизирован для диалоговых AI-агентов: он открывает чат-панель прямо в интерфейсе n8n Advanced AI Docs.
Action-ноды (также называемые App Nodes) выполняют операции во внешних сервисах: читают данные, создают ресурсы, обновляют записи, отправляют сообщения. Их более 400 штук апп-интеграций в составе n8n-nodes-base (плюс ~100 Core-нод, управляющих потоком и трансформацией данных).
Наиболее востребованные категории:
Core-ноды предоставляют управляющую логику и преобразование данных, не привязаны к конкретному приложению:
@n8n/task-runner)Эти ноды составляют «скелет» любого нетривиального workflow, обеспечивая flow-control.
Cluster-ноды (кластерные ноды) — ключевое нововведение для AI-функций. Кластер состоит из корневой ноды (root node) и присоединённых к ней поднод (sub-nodes). Корневая нода определяет общую цель (например, «быть AI-агентом»), а подноды поставляют компоненты: языковую модель, память, инструменты, embeddings.
Визуально cluster выглядит так: корневая нода находится слева, а её sub-nodes прикрепляются справа, образуя компактную группу. Эта группировка делает сложные AI-configurations удобочитаемыми на canvas AI Agent Node Docs.
Пример состава кластера AI Agent:
[AI Agent] ←→ [OpenAI Chat Model] (Language Model sub-node)
←→ [Window Buffer Memory] (Memory sub-node)
←→ [HTTP Request Tool] (Tool sub-node)
←→ [Wikipedia Tool] (Tool sub-node)Корневая нода AI Agent координирует работу всех своих sub-nodes: вызывает LLM, передаёт ей список доступных инструментов, обрабатывает ответы, при необходимости повторяет цикл (agent loop).
Если встроенной интеграции недостаточно, любой разработчик может создать собственную ноду и опубликовать её как npm-пакет. Другие пользователи n8n устанавливают такие ноды через меню Settings → Community Nodes, указав имя npm-пакета. Подробнее см. раздел 13 «Расширение: создание кастомных нод».
Понимание внутренней модели данных n8n абсолютно необходимо для написания корректных expressions, отладки workflows и проектирования кастомных нод.
Все данные в n8n передаются между нодами как массив объектов фиксированной структуры. Каждый объект (часто называемый «item») имеет два свойства:
interface INodeExecutionData {
json: Record<string, any>; // Структурированные данные
binary?: IBinaryKeyData; // Файлы (опционально)
}Таким образом, выход каждой ноды выглядит так:
[
{ "json": { "firstName": "John", "lastName": "Doe", "age": 32 } },
{ "json": { "firstName": "Jane", "lastName": "Smith", "age": 28 } }
]Поле json обязательно и содержит структурированные данные — числа, строки, вложенные объекты, массивы. Поле binary опционально и хранит бинарные данные (файлы, изображения, PDF-документы) вместе с метаданными (mime-type, filename, размер) Data Structure Docs.
Фундаментальный принцип n8n: каждая нода обрабатывает каждый item независимо. Если на вход приходит массив из пяти items, нода выполнит свою операцию пять раз — по одному разу для каждого item. Результат тоже будет массивом из пяти items (если нода не фильтрует и не агрегирует данные).
Этот дизайн называется «run-once-per-item» и существенно упрощает рассуждения о поведении workflow: вам не нужно думать о том, как нода обрабатывает весь массив целиком — достаточно понять, что она делает с одним элементом.
Исключение составляет нода Code, которая может работать либо в режиме «Run Once for All Items», либо «Run Once for Each Item». Первый режим даёт полный контроль над всем массивом, второй — следует стандартному принципу индивидуальной обработки Data Structure Docs.
Expressions — механизм доступа к данным внутри полей параметров нод. Синтаксис двойных фигурных скобок позволяет ссылаться на данные предыдущей ноды:
// Доступ к полю текущего item
{{ $json.firstName }}
// Доступ к выходу конкретной ноды по имени
{{ $('My Previous Node').item.json.lastName }}
// Доступ к metadata выполнения
{{ $execution.id }}
{{ $execution.mode }}
// Работа с датами
{{ $now.format('yyyy-MM-dd') }}
{{ DateTime.now().plus({ days: 7 }).toFormat('yyyy-MM-dd') }}Expression engine реализован в пакете n8n-workflow и поддерживает богатый набор функций: строковые операции, математические вычисления, форматирование дат (Luxon), работа с массивами и объектами Data Structure Docs.
Начиная с версии 0.166.0, при использовании нод Function или Code, если нода возвращает простой объект { key: value } вместо массива [{ json: { key: value } }], n8n автоматически оборачивает его в требуемый формат. Аналогично, если возвращена строка или число, оно будет обёрнуто как { json: { data: <value> } }. Это поведение применяется только к Function/Code нодам — при разработке кастомных нод вы обязаны явно следовать спецификации INodeExecutionData[] Data Structure Docs.
При отладке полезно знать о механизме pairedItem — связи между входящими и исходящими items. Когда нода фильтрует данные, n8n сохраняет информацию о том, какой выходной item соответствует какому входному. Это позволяет трассировать путь данных через цепочку нод в интерфейсе отладчика.
Особенность AI-нод заключается в том, что многие из них нарушают правило «one-output-per-input». Например, AI Agent может вернуть один ответ на основе нескольких входных items, или Vector Store Retrieve вернёт переменное число чанков в зависимости от запроса. Поэтому при работе с AI-нодами важно проверять форму выходных данных через панель Output в редакторе, прежде чем предполагать конкретную структуру.
Ещё одна тонкость: поле $json.chatInput автоматически заполняется Chat Trigger-нодой и содержит текст текущего сообщения пользователя. Оно служит стандартным входом для AI Agent:
// В AI Agent ноде, выражение для получения пользовательского ввода:
{{ $json.chatInput }}При использовании других triggers (Webhook, Telegram) входные данные приходят в иной структуре, и mapping может потребоватьсяручная настройка через Set-ноду или expressions Data Structure Docs.
Интеграция n8n с LangChain — одно из самых значимых событий в экосистеме low-code/no-code AI. Вместо того чтобы изобретать свой велосипед для взаимодействия с LLM, n8n полностью приняла зрелый фреймворк LangChain JS, адаптировав его концепции под парадигму визуальных workflows LangChain in n8n Docs.
Поддержка AI/LangChain доступна начиная с версии 1.19.4 и выше.
n8n не просто «оборачивает» LangChain вызовы в визуальную оболочку — он переосмысливает компоненты LangChain как cluster-ноды. Абстрактные понятия LangChain (Agent, Chain, Retriever, Tool) становятся визуальными блоками на canvas, которые можно комбинировать перетаскиванием, не жертвуя глубиной контроля.
Root nodes — точки входа в AI-subgraph. Они определяют стратегию работы AI-системы:
AI Agent — автономный интеллектуальный агент. Получает задачу, самостоятельно решает какие инструменты вызвать, сколько итераций выполнить, и формирует итоговый ответ. Это самая мощная и гибкая root-нода AI Agent Node Docs.
Chains — детерминированная последовательность шагов: LLM → Prompt Template → Output Parser. В отличие от агента, chain не обладает autonomy — каждый следующий шаг заранее определён. Подходит для воспроизводимых трансформаций (перевод, суммаризация, экстракция).
Vector Stores — интерфейс к векторным базам данных. Позволяет вставлять документы (Insert) и искать ближайшие векторы (Retrieve). Работает как самостоятельный entry point для RAG-pipelines.
LangChain Code — возможность написать произвольный LangChain JS-код внутри ноды. Даёт полную свободу, но лишает визуального редактирования. Применяется, когда готовые комбинации нод не покрывают потребностей.
Sub-nodes подключаются к root node и поставляют конкретные компоненты:
Провайдеры LLM, которые будут использоваться для генерации текста и принятия решений:
Управление контекстом разговора (conversation history):
Без Memory агент «не помнит» предыдущие реплики пользователя, что непригодно для многоходовых диалогов.
Инструменты, которые агент может вызывать для выполнения действий:
Генераторы векторных представлений текста:
Embeddings используются для индексации документов в vector stores и семантического поиска.
Загрузчики сырых данных из различных источников для подачи в RAG pipeline:
Разделители длинных документов на чанки (chunks) для векторизации:
Структурирование выхода LLM в машинно-читаемый формат (JSON, списки, enums).
Интерфейсы поиска по проиндексированным документам. Векторный retriever берёт запрос пользователя, эмбеддингует его, ищет k-nearest соседей в vector store и возвращает найденные документы как контекст для LLM RAG in n8n Docs.
AI Agent Node — сердце AI-возможностей n8n. Понимание механики этой ноды необходимо для осмысленного проектирования любых рабочих процессов на базе ИИ.
Агент в терминологии n8n — это автономная система, которая: (1) получает вводные данные, (2) принимает решения на основе этих данных и возможностей имеющихся инструментов, (3) действует — вызывает выбранные инструменты, (4) оценивает результаты и формирует финальный ответ пользователю. В отличие от простой цепочки (chain), агент обладает свободой выбора: он сам определяет, какие инструменты нужны в данной ситуации и сколько итераций потребуется AI Agent Node Docs.
Начиная с версии 1.82.0 все варианты AI Agent были консолидированы в единый тип — Tools Agent. Согласно официальной документации, «This has now been removed and all AI Agent nodes work as a Tools Agent» AI Agent Node Docs. Среди ранее доступных типов, согласно данным сообщества и архивной документации, были Conversational Agent, OpenAI Functions Agent, Plan and Execute Agent, ReAct Agent, SQL Agent и ряд других (сообщество n8n).
Вероятная причина консолидации — распространение нативной поддержки вызова функций (function/tool calling) в современных LLM (GPT-4o, Claude 3.5 Sonnet и др.), благодаря чему специализированные промежуточные форматы взаимодействия с моделями стали избыточными. Однако официальная документация лишь констатирует факт объединения, не приводя его обоснования.
Tools Agent реализует интерфейс вызова инструментов (tool calling interface) из LangChain: модель получает описание доступных инструментов и их схемы (schemas) и сама решает, какие из них вызвать с какими аргументами Tools Agent Docs.
Минимальная конфигурация AI Agent включает:
| Компонент | Обязательность | Тип sub-node | Описание |
|---|---|---|---|
| Chat Model (LLM) | ✅ Обязательно | Language Model | «Мозг» агента — модель, принимающая решения и генерирующая текст |
| Tools | ✅ Минимум 1 | Tool sub-node | Действия, которые агент может выполнять |
| System Message | ⚙️ Настраивается | Параметр корневой ноды | Системный промпт, задающий поведение и личность агента |
| Memory | 🔧 Опционально | Memory sub-node | Контекст разговора в пределах текущей сессии |
Документация явно указывает: к AI Agent необходимо подключить хотя бы один tool sub-node и одну chat model AI Agent Node Docs. System Message — это не sub-node, а параметр самой ноды AI Agent (настраивается в разделе Node Options). Memory опциональна, но без неё агент не будет сохранять историю диалога в рамках одного сеанса общения. При этом важно учитывать: согласно официальной документации, память не сохраняется между сессиями — после окончания сессии чата история теряется Tools Agent Docs.
Tools Agent поддерживает следующие модели: OpenAI Chat Model, Groq Chat Model, Mistral Cloud Chat Model, Anthropic Chat Model, Azure OpenAI Chat Model Tools Agent Docs.
Работа Tools Agent следует итеративному алгоритму, иногда называемому agentic loop или ReAct-циклом (Reason + Act):
Цикл продолжается, пока LLM не сочтёт, что собрана достаточная информация для окончательного ответа. Количество итераций ограничено настройкой Max Iterations (по умолчанию — 10) Tools Agent Docs. При достижении лимита итераций выполнение завершается; точное поведение (что именно возвращается пользователю) зависит от версии n8n и внутреннего состояния агента на момент остановки.
Одна из ключевых особенностей n8n — возможность подключить многие стандартные ноды к AI Agent как Tool sub-node. Например, можно добавить ноду GitHub, Slack, PostgreSQL, HTTP Request, Code или даже целый суб-рабочий процесс (через ноду Call n8n Workflow), и агент сможет обращаться к ним по мере необходимости Tools Agent Docs. Это принципиальное преимущество n8n перед программными фреймворками вроде LangGraph или CrewAI: там для подключения каждого нового сервиса обычно требуется написать код (хотя и существуют встроенные абстракции — декораторы @tool, классы StructuredTool и библиотеки интеграций), тогда как n8n предоставляет готовые операции для сотен приложений визуально, без написания кода Strapi Guide.
При подключении ноды-как-инструмента n8n формирует для неё объявление (declaration), включающее название, описание и схему параметров, чтобы LLM могла корректно определить, когда и как вызвать данный инструмент. Этот механизм является частью внутренней архитектуры платформы и основан на общем принципе предоставления LLM машинно-читаемого описания доступных действий.
Для динамического заполнения параметров инструментов используется функция $fromAI() — она позволяет агенту самостоятельно определять значения параметров при вызове ноды, что особенно полезно для параметров, которые невозможно задать статически. Важно: $fromAI() работает только с инструментами, подключёнными непосредственно к AI Agent node; эта функция не применяется к ноде Code tool и другим sub-node, не являющимся инструментами [$fromAI() Docs]. Активировать функцию можно двумя способами: нажав специальную кнопку в интерфейсе параметра ноды (UI toggle), которая автоматически вставит выражение $fromAI(), либо вручную прописав вызов функции в поле Expression.
Human-in-the-loop. n8n позволяет требовать подтверждение человека перед выполнением определённых инструментов. Это критично для инструментов, выполняющих необратимые действия (отправка сообщений, удаление записей, изменение данных). При срабатывании такого инструмента рабочий процесс приостанавливается и отправляет запрос на подтверждение через выбранный канал (Chat, Slack, Telegram и др.) [Human-in-the-loop Docs].
Streaming. По умолчанию AI Agent отправляет данные пользователю в реальном времени по мере генерации ответа. Для корректной работы streaming требуется триггер, поддерживающий потоковые ответы (Chat Trigger или Webhook с режимом Streaming) Tools Agent Docs.
Require Specific Output Format. Агент можно настроить на обязательный формат вывода, подключив output parser sub-node. Это полезно, когда результат должен соответствовать строгой схеме (например, JSON с заданными полями) Tools Agent Docs.
Return Intermediate Steps. Опция, позволяющая включить в финальный вывод все промежуточные шаги агента. Полезна для отладки и последующей оптимизации поведения агента Tools Agent Docs.
Опыт сообщества n8n и практика внедрения AI-агентов выявили ряд устойчивых архитектурных паттернов. Каждый паттерн подходит для определённых сценариев и характеризуется своими компромиссами AI Agentic Workflows Blog Product Compass AI Agent Architectures.
Самый простой паттерн: последовательность предопределённых вызовов разных LLM или prompts, где выход одной ноды становится входом другой. Никакой автономии — маршрут фиксирован.
[Prompt A] → [LLM #1] → [Prompt B] → [LLM #2] → [Output]Когда использовать:
Преимущества:
Ограничения:
Реализация в n8n: прямое соединение нескольких LLM Chain нод или обычных нод с HTTP Request/OpenAI.
Один AI Agent с набором инструментов и (опционально) памятью. Агент автономно решает, какие инструменты использовать и в каком порядке.
[User Input] → [AI Agent] ⇄ [Tool 1]
⇄ [Tool 2]
⇄ [Tool 3]
→ [Final Response]Когда использовать:
Преимущества:
Ограничения:
Главный агент (Gatekeeper/Router) принимает входящий запрос и делегирует его специализированному подчинённому агенту. Подчинённые агенты сфокусированы на своей предметной области и оснащены соответствующим набором инструментов.
[Gatekeeper Agent]
↙ ↓ ↘
[Sales Agent] [Tech Agent] [HR Agent]
↓ ↓ ↓
[Reply] [Reply] [Reply]
↘ ↓ ↙
[Combined / Selected Response]Когда использовать:
Преимущества:
Ограниченности:
Реализация в n8n: Gatekeeper — AI Agent с инструментом Switch/Routing, перенаправляющим на разные sub-workflows, каждый из которых содержит своего собственного AI Agent.
Несколько равноправных агентов работают совместно над общей задачей. Возможны три варианта организации:
Mesh (сетевой): агенты общаются peer-to-peer, каждый может обратиться к любому другому. Отличается гибкостью, но трудно прогнозируем.
Hierarchical (иерархический): менеджер-агент распределяет задачи, собирает результаты, формирует synthesis. Более управляем, но bottleneck на уровне manager.
Hybrid (гибридный): сочетает элементы mesh и hierarchy — группы специалистов внутри team с внутренними лидерами.
[Hierarchical]
[Manager Agent]
↙ ↓ ↘
[Researcher] [Writer] [Reviewer]
↑ ↑ ↑
└──────────┴─────────┘
Feedback LoopКогда использовать:
Преимущества:
Ограничения:
В n8n multi-agent teams обычно реализуются через цепочку AI Agent нод, связанных через Intermediate Flow ноды (Set, Merge, Switch), где выход одного агента (intermediate conclusion) питает вход другого AI Agentic Workflows Blog.
Retrieval-Augmented Generation (RAG) — методология улучшения качества ответов LLM путём обогащения промпта релевантными данными, извлечёнными из внешнего источника. Без RAG модель ограничена знаниями, заложенными на момент обучения; с RAG — она получает актуальную, специфичную информацию из вашей корпоративной базы знаний RAG in n8n Docs.
Vector Store (векторное хранилище) — специализированная база данных, хранящая числовые представления (эмбеддинги) текстовых фрагментов и поддерживающая быстрый поиск k-nearest neighbours в пространстве высокой размерности.
n8n поддерживает следующие векторные хранилища:
| Хранилище | Тип | Особенности |
|---|---|---|
| Simple Vector Store | Built-in | Встроенное хранилище в оперативной памяти; удобно для prototyping, не переживает рестарт |
| PGVector | Self-hosted | Расширение PostgreSQL для векторного поиска; recommended для production self-hosted |
| Pinecone | Managed Cloud | Fully-managed vector DB; масштабируется автоматически |
| Qdrant | Self-hosted / Cloud | High-performance vector similarity search; Rust-based |
| Supabase | Managed Cloud | Postgres + pgvector как часть Supabase ecosystem |
| Zep | Specialized | Optimised для conversation memory и долгосрочный context |
Перед тем как осуществлять retrieval, необходимо проиндексировать документы. Типичный ingestion pipeline в n8n выглядит следующим образом:
[Document Source] ← Fetch данных (HTTP Request, Google Drive, Manual)
↓
[Default Data Loader] ← Загрузка сырого содержания
↓
[Text Splitter] ← Разбивка на чанки (chunks)
↓
[Embedding Model] ← Преобразование текста в векторы
↓
[Vector Store Insert] ← Запись векторов + метаданных в БДПример конфигурации Text Splitter (Recursive Character):
{
"chunkSize": 1000,
"chunkOverlap": 200,
"separators": ["\n\n", "\n", ". ", " ", ""]
}Здесь chunkSize — максимальная длина чанка в символах, chunkOverlap — количество перекрывающих символов между соседними чанками (сохраняет контекст на границах). Separators задают приоритет разделителей: сначала по абзацам, затем по строкам, предложениям, пробелам RAG in n8n Docs.
После индексации доступны два режима запроса:
Через AI Agent (Vector Store как Tool): подсоедините Vector Store sub-node к AI Agent. Агент автоматически обратится к нему, когда вопрос касается проиндексированных данных. Преимущество — seamless integration; агент сам решает, нужен ли retrieval.
Напрямую через Vector Store ноду (Get Many): явный вызов Vector Store retrieve operation. Вы задаёте запрос, получаете top-k релевантных чанков и далее подаёте их в LLM через prompt. Преимущество — полный контроль над retrieved context и прозрачность процесса.
Выбор модели эмбеддингов определяется балансом стоимости, качества и латентности:
Правило thumb: начинайте с малой модели (small/ada), переходите к большой (large) только если наблюдаете poor recall при testing RAG in n8n Docs.
| Стратегия | Алгоритм | Когда применять |
|---|---|---|
| Character | Разрезает по первому попавшемуся разделителю из списка | Простые uniform-тексты (log files, plain text) |
| Recursive Character ★ | Последовательно пытается резать по каждому уровню разделителей (абзац → строка → предложение → слово) | Большинство реальных документов (HTML, Markdown, статьи) — рекомендуемый вариант |
| Token | Разрезает точно по количеству токенов модели | Когда критично точное соблюдение token-budget (например, tight context window) |
Перекрытие (overlap) между чанками критически важно: без него смысл на границе двух чунков теряется. Рекомендуемое значение overlap — 10–20% от chunk_size RAG in n8n Docs.
Model Context Protocol (MCP) — открытый стандарт, предложенный компанией Anthropic в конце 2024 года, предназначенный для универсального подключения AI-приложений к внешним инструментам и источникам данных. MCP позиционируется как «USB-C для AI»: единый протокол, через который любой MCP-совместимый клиент может обращаться к любому MCP-совместимому серверу MCP Client Tool Docs.
До появления MCP каждая AI-платформа реализовала собственные SDK для работы с инструментами: OpenAI Function Calling, LangChain Tools, Anthropic Tool Use. Инструмент, написанный для одной экосистемы, не работал в другой. MCP стандартизирует интерфейс: один MCP-сервер экспонирует свои capabilities одинаково для любого клиента.
Нода MCP Client Tool (из пакета @n8n/nodes-langchain) позволяет AI Agent в n8n подключаться к внешнему MCP-серверу и использовать его инструменты как свои own. Таким образом, если ваша организация уже имеет MCP-сервер с инструментами (например, для работы с CRM, ERP или внутренних микросервисов), агент n8n может мгновенно получить к ним доступ без написания кастомных нод.
Конфигурация MCP Client Tool:
{
"connectionType": "sse",
"serverUrl": "http://my-mcp-server:3000/sse",
"headers": {}
}Или для stdio transport (локальный процесс):
{
"connectionType": "stdio",
"command": "python",
"arguments": ["path/to/mcp_server.py"]
}MCP Client Tool автоматически обнаруживает доступные инструменты на сервере, генерирует их descriptions и делает видимыми для LLM внутри AI Agent MCP Client Tool Docs.
Существует и обратный сценарий: сторонние проекты, такие как n8n-mcp-server, позволяют другим AI-приложениям (Cursor IDE, Claude Desktop и т.д.) управлять n8n workflows через MCP. То есть внешний AI-клиент может создавать, активировать, деактивировать и запускать n8n workflows через стандартный MCP-протокол.
Такая двунаправленная роль (client ↔ server) делает n8n центральным hub в растущей экосистеме MCP-инструментов.
Выше описан встроенный MCP Client Tool из пакета @n8n/nodes-langchain — это sub-node, подключаемая к AI Agent для вызова внешних MCP-tool servers изнутри workflow. Существует также community-пакет n8n-nodes-mcp, который предоставляет дополнительные MCP-интеграции, не входящие в стандартную поставку n8n. Установка community-пакета:
n8n-nodes-mcpКогда нужен community-пакет: если встроенный MCP Client Tool не покрывает ваши потребности (например, требуется специфический transport или расширенная конфигурация). Для большинства сценариев достаточно встроенной ноды.
Безопасность — критический аспект любой платформы автоматизации, а для AI-агентов, обладающих правом выполнять реальные действия (отправлять письма, изменять данные, делать API-звонки), вопросы безопасности приобретают ещё большую остроту.
Все credentials (учётные данные: API-ключи, пароли, tokens), хранящиеся в n8n, шифруются симметричным алгоритмом AES с использованием ключа, заданного переменной окружения N8N_ENCRYPTION_KEY. Без этого ключа невозможно расшифровать сохранённые credentials — ни в базе данных, ни при экспорте конфигурации.
# Обязательно задайте encryption key в production!
N8N_ENCRYPTION_KEY=<случайная_строка_минимум_32_символа>⚠️ Критическое предупреждение: потеря N8N_ENCRYPTION_KEY означает необратимую утрату доступа ко всем сохранённым credentials. Резервное копирование этого ключа должно быть первым приоритетом при настройке n8n.
n8n Enterprise поддерживает RBAC — разграничение прав доступа на основе ролей. Администратор может определить проекты (workspaces), назначить пользователей на роли (Admin, Editor, Viewer) и ограничить доступ к конкретным workflows и credentials. Это особенно важно в командах, где разные сотрудни