N8N AI Agent Tutorial: От простого запроса к структурированным данным рабочего процесса
Почему автоматизация рабочих процессов теперь требует больше, чем фиксированные правила
Представьте, что рабочий процесс получает предложение вроде этого: “Новый клиент по имени John купил gpu server 01/06/2026.” Человек читает это и сразу видит три полезных значения: имя клиента, продукт и дату.
Жесткий рабочий процесс — нет. Он может разделять текст, искать закономерности и проверять форматы, но в момент, когда формулировка меняется — “John только что заказал GPU server вчера” или “Новый клиент John приобрел хостинг 1 июня” — хрупкий парсинг начинает ломаться.

Это граница между классической автоматизацией и слоем AI. Детерминированные рабочие процессы превосходны, когда входные данные чистые: маршрутизация данных, преобразование полей, валидация записей, вызов API и надежное повторение последовательностей. Они спотыкаются на грязном первом шаге — интерпретация намерения, классификация запросов, суммирование неструктурированного контента или извлечение полей из естественного языка перед тем, как рабочий процесс может действовать.
Именно здесь n8n AI Agent становится практичным. В этом руководстве вы сначала получите понимание на простом английском языке того, что такое n8n AI Agent на самом деле внутри рабочего процесса, а затем создадите обоснованный первый вариант использования, который превращает естественный язык в структурированные данные.
Что такое n8n AI Agent на самом деле
В n8n AI Agent лучше всего понимается как шаг рассуждения внутри workflow. Это узел, который использует модель для интерпретации входных данных, работы с контекстом и помощи в определении того, что произойдет дальше. Это может означать ответ на запрос, извлечение полей, классификацию запроса или определение того, как должен быть подготовлен следующий шаг workflow. Важная часть в том, что агент находится внутри workflow. Это не вся система сама по себе.

Движущиеся части легче понять, если разделить их по ролям:
| Часть | Что она делает |
|---|---|
| 🤖 Chat Model | Предоставляет языковую модель, которая генерирует или структурирует ответ |
| 🧠 Memory | Переносит контекст разговора или задачи между ходами |
| 🛠️ Tools | Позволяют агенту вызывать внешние возможности или источники данных |
| 🔗 Обычные узлы workflow | Обрабатывают триггеры, маппинг, валидацию, маршрутизацию и последующие действия |
Модель обрабатывает гибкую интерпретацию. Окружающие узлы n8n по-прежнему контролируют структуру: откуда берутся данные, как они маппируются, что валидируется, какой узел запускается следующим и что в итоге записывается в другую систему. Если вам нужно предсказуемое выполнение, одобрения, интеграции или бизнес-правила, workflow остается в управлении.
💡 Совет: Самая чистая ментальная модель такая: workflow — это по-прежнему рельсы; агент — это шаг рассуждения внутри этих рельсов.
Это также облегчает объяснение того, чем n8n AI Agent не является. Это не просто узел чатбота. Это не магическая автономность. Это не то, что нужно каждому workflow. Если фиксированное правило, простое преобразование или один ограниченный AI запрос уже решают задачу, добавление слоя агента только добавляет сложность. Ценность проявляется, когда workflow должен иметь дело с неоднозначностью, прежде чем она снова станет детерминированной.
Где n8n AI Agents помогают больше всего в реальных рабочих процессах
Лучшее место для использования n8n AI Agent — это граница, где человеческая неоднозначность входит в систему.
- Команды поддержки могут нуждаться в чтении входящего запроса и классификации того, является ли он биллингом, техническим или срочным.
- Операционные команды могут получать внутренние запросы на простом языке и нуждаться в извлечении полей перед маршрутизацией.
- Команды продаж могут захотеть превратить беспорядочное сообщение о лиде в чистые данные, готовые для CRM.
- Рабочие процессы с большим количеством документов могут нуждаться в извлечении имен, дат, номеров счетов или деталей услуг из неструктурированного текста.
В каждом из этих случаев разделение труда остается одинаковым. Агент интерпретирует, извлекает, суммирует или классифицирует. Детерминированные узлы затем проверяют выходные данные, маршрутизируют их в правильную ветвь, создают записи, уведомляют людей или записывают результат в другую систему. Эта граница важна, потому что она сохраняет полезную часть AI — гибкую интерпретацию — без потери предсказуемости, которая делает автоматизацию рабочего процесса стоящей использования.

Структурированное извлечение — это особенно сильный первый вариант использования, потому что оно ограничено, видимо и сразу же полезно для последующих операций. Вы можете увидеть входное предложение, определить поля, которые вы хотите получить, а затем использовать эти поля как обычные данные рабочего процесса. Это делает результат конкретным. Вместо «AI сказал что-то полезное» вы получаете «рабочий процесс теперь имеет имя, продукт и дату, и следующий узел может действовать на их основе».
Это также хорошее место, чтобы помнить об одной дисциплине: большее поведение агента не обязательно лучше. Если фиксированное правило или один запрос уже решают проблему, вам, вероятно, не нужен полный слой агента. Эта статья сосредоточена на структурированном извлечении, потому что оно показывает реальную ценность рабочего процесса без претензии на то, что каждая проблема автоматизации требует широкой автономии.
Что мы создаем в этом руководстве

Это руководство намеренно учит двум рабочим процессам. Workflow A — это наименьший возможный паттерн:
Manual Trigger -> Set -> AI Agent -> OpenRouter Chat Model -> plain responseЕго задача не впечатлить вас. Его задача сделать путь данных видимым, чтобы вы могли точно увидеть, как prompt входит в workflow, достигает agent и возвращается как обычный ответ.
Workflow B сохраняет ту же базу и улучшает ее с помощью Structured Output Parser плюс код node Create invoice. Вместо возврата абзаца agent вернет предсказуемые поля. Эти поля затем используются для создания объекта счета, что делает вывод сразу же полезным для остальной части workflow.
Эта двухэтапная прогрессия важна. Сначала вы видите, как agent ведет себя в самой простой форме. Затем вы видите, почему простой вывод AI — это только половина истории для автоматизации. Реальная выгода приходит, когда workflow превращает естественный язык в структурированные данные.
Перед началом: предварительные требования и подготовка

Перед построением рабочего процесса подготовьте три вещи:
- Работающий экземпляр n8n
- Разрешение на создание и редактирование рабочего процесса
- Рабочие учетные данные API OpenRouter
Вы можете запустить ту же логику в n8n Cloud, если хотите, но эта статья ориентирована на самостоятельно размещенную среду, потому что это типичный сценарий AlexHost, когда команды хотят больше контроля над данными, сетью или приватными интеграциями.
Практический источник для этого руководства был протестирован на n8n 2.26.8, работающем на AlexHost VPS. Если вам все еще нужно развернуть n8n перед попыткой работы с AI, используйте отдельное руководство AlexHost здесь: n8n automation tutorial for Ubuntu: from zero to flow.
📓 Примечание: Одно небольшое уточнение терминологии перед тем, как продолжить: более новая документация может показывать узел Set как Edit Fields (Set), но в этом пошаговом руководстве используется более простое название Set, потому что именно это используется в практическом источнике.
Причина, по которой эта статья начинается с Manual Trigger + Set вместо Chat Trigger, проста: это делает входные данные явными, упрощает проверку сопоставления и устраняет один уровень путаницы при первой сборке. Вы изучаете, как узел AI Agent встраивается в рабочий процесс и как этот рабочий процесс переходит от свободной подсказки к структурированному, готовому к автоматизации выводу.
Практическая часть 1: создание наименьшего возможного потока n8n AI Agent
Этот первый рабочий процесс доказывает базовый паттерн перед тем, как попросить его сделать что-то более полезное. Вы создадите видимый ввод, передадите его в AI Agent, подключите модель OpenRouter и подтвердите, что рабочий процесс возвращает обычный текстовый ответ.
1.0 Добавьте триггер и узел ввода
Начните с размещения узла Manual Trigger и узла Set на холсте. Это упрощает точку входа и дает вам одно четкое поле для передачи в агент.

На этом этапе вы еще не делаете ничего “специфичного для ИИ”. Вы подготавливаете чистый ввод рабочего процесса, чтобы следующий узел имел что-то явное для чтения.
1.1 Настройте узел Set
Откройте узел Set, переключитесь на Manual Mapping, создайте поле с именем prompt и вставьте стартовый текст ниже. Это дает рабочему процессу одно видимое значение, которое вы позже можете заменить на более деловое предложение.
Hello, who are you?
Это делает простое, но важное: вместо того чтобы скрывать подсказку внутри узла ИИ, вы сохраняете ее в обычных данных рабочего процесса. Это упрощает понимание и повторное использование пути ввода.
2.0 Разместите AI Agent и подключите модель чата
Теперь добавьте узел AI Agent и подключите OpenRouter Chat Model к его входу Chat Model. В начинающих терминах видимые входы означают следующее: Chat Model — это модель, которую агент использует для ответа, Memory — это необязательный контекст, который сохраняется между ходами, и Tool — это необязательное соединение, которое позволяет агенту вызывать внешние возможности. В этом первом рабочем процессе подключена только модель, потому что цель — понять наименьший рабочий паттерн.

Как только это будет на месте, разделение ролей станет видимым: рабочий процесс несет ввод, а агент будет обрабатывать этап интерпретации.
2.1 Настройте модель OpenRouter
Выберите учетные данные OpenRouter account и выберите ту же модель, что показана в исходном рабочем процессе: deepseek/deepseek-v4-flash. Вам не нужна дополнительная настройка для этого первого прохода.

📝 Примечание: Доступные модели OpenRouter могут различаться в зависимости от учетной записи, даже если пример источника истины здесь использует deepseek/deepseek-v4-flash.
Если ваша учетная запись показывает другой список, паттерн рабочего процесса все еще важнее, чем точное имя модели.
3.0 Сопоставьте поле prompt с AI Agent
Подключите выход узла Set к AI Agent, установите Source for Prompt (User Message) на Define below и сопоставьте значение рабочего процесса с полем подсказки, используя выражение ниже. Это говорит агенту читать значение prompt из данных выше по потоку вместо использования жестко закодированного сообщения внутри узла.
{{ $json.prompt }}
Это сопоставление — ключевой мост между обычными данными n8n и этапом ИИ. Как только это станет понятно, остальная часть учебника станет намного легче для понимания.
3.1 Выполните рабочий процесс
Запустите рабочий процесс, чтобы данные прошли через полную цепь: Manual Trigger -> Set -> AI Agent -> OpenRouter Chat Model. Вы проверяете не только то, что модель отвечает, но и то, что рабочий процесс чисто передает подсказку от одного узла к другому.

Если выполнение успешно, у вас теперь есть доказательство того, что агент может использовать данные рабочего процесса вместо того, чтобы только вводить текст внутри собственного интерфейса.
3.2 Проверьте ответ
Откройте выход и проверьте результат. На этом этапе AI Agent возвращает обычный текстовый ответ на подсказку. Это базовый паттерн в его простейшей форме: подсказка на входе, ответ на выходе.

Этот первый рабочий процесс важен, потому что он доказывает сантехнику. Он также четко показывает ограничение: абзац хорош для взаимодействия, но неудобен для автоматизации нижестоящих процессов. Следующий шаг — это то, где рабочий процесс становится намного более полезным.
Практическая часть 2: преобразование ответа в структурированные данные рабочего процесса
Теперь мы сохраняем тот же базовый рабочий процесс и меняем цель. Вместо того чтобы просить агента дать общий ответ, мы попросим его извлечь предсказуемые поля, которые следующий узел может использовать как обычный JSON.
4.0 Измените подсказку и требуйте определённый формат
Вернитесь к узлу Set и замените случайное приветствие на деловое предложение ниже. Затем включите Require Specific Output Format в AI Agent, чтобы рабочий процесс перестал стремиться к прозе и начал стремиться к структурированному извлечению.
A new client named John bought a gpu server on 01/06/2026
Это момент, когда вариант использования становится реальным. Предложение содержит данные, которые человек понимает мгновенно, и рабочий процесс теперь обучается возвращать эти данные в форме, пригодной для машины.
4.1 Добавьте парсер структурированного вывода
Подключите Structured Output Parser к входу Output Parser AI Agent. Этот парсер — это то, что дает модели целевую структуру вместо того, чтобы позволить ей отвечать свободным текстом.

📝 Примечание: Structured Output Parser хорошо подходит для этой первой демонстрации, но официальное руководство n8n отмечает, что прямой парсинг на агентах может быть менее надежным в более продвинутых рабочих процессах. Для этого паттерна для начинающих это всё ещё правильный обучающий шаг, потому что он делает изменение формы данных легко видимым.
Важная идея — это не дополнительный узел сам по себе. Это то, что вы превращаете “ответ AI” в “контракт рабочего процесса”.
4.2 Определите схему вывода из примера JSON
В парсере установите Schema Type на Generate From JSON Example и используйте точный пример ниже. Это дает агенту четкую схему с тремя полями, которые рабочий процесс ожидает получить обратно.
{
"name": "Alex",
"product": "VPS hosting",
"date": "21/6/2026"
}
Как только вы определите этот пример, вы больше не просите модель “сказать что-то полезное”. Вы просите её вернуть предсказуемую структуру с name, product и date.
4.3 Проверьте структурированный результат
Выполните рабочий процесс снова и проверьте вывод AI Agent. На этот раз результат должен вернуться как поля вместо абзаца.

Это изменение формы — настоящее улучшение. Структурированный вывод — это не просто более красивое форматирование. Это то, что делает результат достаточно надежным, чтобы нисходящая логика могла его использовать без угадывания.
4.4 Используйте разобранные поля в узле JavaScript для создания счета
Теперь передайте результат в узел JavaScript Create invoice. Ключевой деталью источника истины в этом пошаговом руководстве является то, что разобранный объект читается из $input.first().json.output, что означает, что код потребляет структурированный вывод агента напрямую.
// Input data
const order = $input.first().json.output
// Parse the order date
const [day, month, year] = order.date.split("/");
const orderDate = new Date(`${year}-${month}-${day}`);
// Generate a pseudo unique invoice ID (8 chars)
function generateId() {
return Math.random().toString(36).substring(2, 10);
}
const invoiceId = generateId();
// Calculate payment due date (7 days later)
const dueDate = new Date(orderDate);
dueDate.setDate(orderDate.getDate() + 7);
// Build invoice record
const invoice = {
invoice_id: invoiceId,
customer: order.name,
product: order.product,
order_date: orderDate.toISOString().split("T")[0],
due_date: dueDate.toISOString().split("T")[0],
status: "Pending"
};
// Print invoice
console.log("Invoice Generated:");
for (const [key, value] of Object.entries(invoice)) {
console.log(`${key}: ${value}`);
}
// If inside n8n Function node, return JSON
return [{ json: invoice }];
Это момент, когда рабочий процесс перестает вести себя как демонстрация чата и начинает вести себя как автоматизация. Агент извлек поля, и следующий узел использовал их точно так же, как любой другой структурированный ввод.
4.5 Проверьте сгенерированные данные счета
Откройте финальный вывод и проверьте объект счета. Вы должны увидеть полезные поля, такие как invoice_id, customer, product, order_date, due_date и status.

Это полный жизненный цикл, к которому статья вела: предложение на естественном языке -> структурированное извлечение -> запись счета. Как только результат имеет эту форму, рабочий процесс может передать его в последующие шаги так же надежно, как любой другой JSON-полезный груз.
Что на самом деле доказывают эти первые два рабочих процесса

Вместе эти два рабочих процесса демонстрируют два разных паттерна для n8n AI Agent. Первый паттерн — простой запрос-ответ: агент получает текст и отвечает текстом. Второй паттерн — структурированное извлечение: агент получает беспорядочный человеческий язык и возвращает поля, которые рабочий процесс может реально использовать.
Это различие важно, потому что обновление касается возможностей, а не внешнего вида. Генерация текста помогает во взаимодействии. Структурированное извлечение помогает в автоматизации. Второй паттерн — это то, что превращает шаг AI из «интересного» в операционно полезный.
Таблица ниже суммирует этот переход:
| Паттерн | Что сделал агент | Что рабочий процесс может сделать дальше |
|---|---|---|
| Простой запрос-ответ | Прочитал видимый запрос и вернул обычный текстовый ответ | Отобразить ответ, проверить его или использовать для легкого взаимодействия, ориентированного на человека |
| Структурированное извлечение | Прочитал предложение и вернул предсказуемые поля, такие как имя, продукт и дата | Проверить значения, создать записи, разветвить логику, уведомить системы или передать JSON в последующие узлы |
Когда вы понимаете этот путь обновления, пример счета-фактуры перестает быть «учебником по счетам-фактурам» и становится переиспользуемым паттерном рабочего процесса. Тот же подход может использоваться для захвата лидов, приема поддержки, анализа заказов, обогащения тикетов или внутренней маршрутизации запросов. В каждом случае цель одна и та же: превратить естественный язык в структурированные данные, а затем позволить детерминированным узлам рабочего процесса сделать остальное.
Что попробовать дальше после этого первого варианта использования

Самый безопасный шаг — это не автономность, а сохранение ограниченного паттерна и обновление одной переменной за раз. Замените Manual Trigger на Chat Trigger или Webhook, когда вам нужен входящий ввод. Добавьте память только когда важна непрерывность. Подключите инструменты только когда агент должен что-то найти или действовать за пределами узла. Затем добавьте валидацию или одобрение, если выходные данные касаются реальных систем.
Самостоятельный хостинг становится критическим, когда рабочие процессы требуют приватных входных данных, доступа к внутренним сервисам, предсказуемого времени безотказной работы или более строгого контроля — здесь инфраструктура VPS в стиле AlexHost является частью дизайна, а не просто фоном. Для развертывания тот же справочник AlexHost охватывает настройку: n8n automation tutorial для Ubuntu: от нуля до потока.
📝 Примечание: Руководящее правило: эвристика наименьшей системы. Если структурированное извлечение решает проблему, остановитесь на этом. Не добавляйте память, инструменты или автономность, если рабочий процесс их действительно не требует.
Начните с ограниченного варианта использования, а не с шумихи об автономности

Жесткая автоматизация обычно ломается в момент, когда в систему поступают беспорядочные данные от человека. На этот разрыв была сосредоточена данная статья. Теперь у вас есть как ментальная модель, так и рабочий паттерн: n8n AI Agent обрабатывает этап гибкой интерпретации, а окружающий workflow преобразует результат в нечто структурированное и надежное.
Это правило проектирования, которое стоит сохранить. Начните с контролируемых задач интерпретации, которые выдают готовые для workflow данные. Расширяйте функциональность памятью, инструментами или более сложными триггерами только когда это действительно требуется workflow — а не потому, что слово “агент” делает большую автономность более впечатляющей.
на всех хостинговых услугах