Соберите своего первого ИИ-агента в n8n: рабочий процесс триажа лидов от начала до конца

Узел n8n AI Agent позволяет модели выбирать среди настроенных инструментов. Эта гибкость добавляет недетерминизм и расширяет поверхность возможных сбоев, поэтому используйте агента только тогда, когда более простые детерминированные маршрутизации оказываются недостаточными.

В данной статье описывается дизайн для первичной обработки лидов: получение лида, извлечение разрешённого контекста, предложение оценок и черновика, проверка результата и направление его на рассмотрение специалисту. Это не импортируемый рабочий процесс и не отчёт об исполнении; приведённые ниже критерии приёмки определяют, что необходимо выполнить, чтобы система заработала в полном объёме.

Мы предполагаем, что n8n у вас уже установлен (на собственном сервере или через n8n.cloud) и есть рабочий API-ключ к Claude или OpenAI. Если вы новичок в n8n — сначала пройдите их базовый туториал.

Дизайн также учитывает предупреждение OWASP относительно чрезмерных полномочий агента: минимизируйте права доступа инструментов, ограничивайте автономию и требуйте утверждения на уровне рабочего процесса для значимых действий. Если данные лидов получены от третьей стороны или будут использоваться для исходящих коммуникаций, проверьте источник, уведомления, законное основание, списки отказа от рассылки и правила каналов перед загрузкой данных или контактом; Европейская комиссия поясняет, что данные третьей стороны не могут автоматически повторно использоваться для маркетинга.

Не позволяйте первой версии автоматически отвечать реальным лидам. Отправляйте черновики на проверку человеком, пока у вас нет логов, идемпотентности, порогов оценки и достаточного числа проверенных запусков, чтобы понимать поведение процесса на грязных входах.

Что именно мы строим

Рабочий процесс:

1. Новый лид поступает через вебхук (из формы, события, CRM и т. д.).
2. Агент обогащает данные лида информацией о компании (используя веб-поиск).
3. Он оценивает лид по трём параметрам: соответствие, намерение, срочность.
4. Составляется персонализированный ответ.
5. В зависимости от оценки:
   • Для высококонфиденциальных лидов с высоким соответствием формируется очередь ответа и предложения для CRM на утверждение;
   • Для лидов среднего уровня составляется черновик ответа для проверки специалистом и отправляется уведомление в Slack;
   • Или просто фиксируется результат и отправляется уведомление без ответа (для лидов с низким соответствием).

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

Сопутствующая JSON-схема из этой статьи описывает входную полезную нагрузку. Используйте её, чтобы валидировать вход вебхука до того, как его увидит нода агента.

Добавьте валидационный шлюз перед агентом

Вебхук не должен передавать произвольные данные формы прямо агенту. Поставьте шаг валидации между триггером и агентом:

Этот шлюз защищает процесс от некорректных отправок, повторов вебхука и инъекций в промпт, спрятанных в полях формы. Агент всё ещё может прочитать сообщение, но рабочий процесс решает, достаточно ли запись корректна для обработки.

Ментальная модель: агент = LLM + инструменты + цикл

Прежде чем строить, разберёмся с концепцией.

«Агент» в 2026 году означает LLM, которая умеет пользоваться инструментами. Вместо того чтобы выдать один ответ, модель сама решает, какие действия (которые называются «tools») вызывать. После каждого вызова инструмента модель видит результат и решает, что делать дальше — ещё один инструмент, ещё один шаг или финальный ответ.

Нода AI Agent в n8n реализует этот цикл. Модели вы даёте:

• Системный промпт (её инструкции и характер).
• Пользовательский промпт (вход для конкретного запуска).
• Набор инструментов (другие ноды n8n или вложенные процессы, которые модель может вызывать).

Модель сама решает, какие инструменты вызывать, в каком порядке и с какими аргументами. После каждого вызова она пересматривает план. Когда сочтёт, что сделала достаточно, выдаёт финальный ответ.

Это принципиально отличается от статичного рабочего процесса, потому что порядок шагов определяет модель, а не вы. Мастерство проектирования агента состоит в:

1. Выдаче модели правильных инструментов (не слишком мало, не слишком много).
2. Написании системного промпта, который ограничивает поведение.
3. Добавлении ограничителей, чтобы агент не съезжал с рельсов.
4. Проектировании выхода так, чтобы следующие ноды могли надёжно его использовать.

Шаг 1: триггер

Откройте n8n и создайте новый рабочий процесс. Триггер:

• Node: Webhook
• HTTP Method: POST
• Response Mode: “When last node finishes”
• Path: что-то вроде /lead-triage

Этот вебхук будет принимать заявки от лидов. n8n даёт вам URL, который можно подставить в качестве адресата для отправки форм или исходящего вебхука вашей CRM.

Для теста сохраните рабочий процесс один раз, чтобы URL вебхука стал активным, и подготовьте пример полезной нагрузки. Типичная полезная нагрузка для лида может выглядеть так:

{
  "name": "Anna Lehtinen",
  "email": "anna@somecompany.fi",
  "company": "Some Company OÜ",
  "role": "Head of Marketing",
  "message": "Interested in your AI consulting services. We have a team of 10 and need help with prompt engineering training.",
  "source": "website-form",
  "timestamp": "2026-05-15T14:30:00Z"
}

Нажмите «Test step» и отправьте тестовую полезную нагрузку, чтобы увидеть, как данные приходят внутрь.

Шаг 2: нода AI Agent

После вебхука добавьте ноду AI Agent. Настройте её:

• Агент / Инструментальный агент (Tools Agent): Текущие узлы n8n AI Agent (версия 1.82+) больше не содержат выпадающего списка выбора типа агента; они работают как Инструментальные агенты. Подключите модель чата и перечисленные ниже инструменты. В старых шаблонах, где всё ещё отображается тип агента, выберите «Инструментальный агент» — другие устаревшие типы были удалены.
• Модель чата: Claude (Anthropic) или OpenAI. Начните с текущей универсальной модели вашего провайдера, затем переходите к более быстрой или мощной версии только тогда, когда ваши тесты обоснуют необходимость. Режимы рассуждения могут добавлять задержки и затраты на каждый шаг агента.
• Память: Не используется для первичной обработки без сохранения состояния (каждый лид независим). Для многошаговых диалогов с агентом используйте узел памяти.
• Системное сообщение: Здесь определяется поведение агента. Используйте шаблон ниже.
• Пользовательское сообщение: Извлеките данные лида из вебхука.

Системное сообщение:

Вы — агент первичной оценки лидов для [название вашей компании], консалтинговой компании в области ИИ.

Ваша задача — обрабатывать входящие лиды и выдавать структурированное решение о маршрутизации.

Для каждого лида необходимо:

1. Используйте инструмент `enrich_lead` для сбора контекста о компании.
2. Оцените лид по трём параметрам:
   - Соответствие: соответствует ли лид нашему профилю идеального клиента?
     - Компании со штатом 10–200 человек в сфере B2B, производства или профессиональных услуг.
     - Роли в маркетинге, операционной деятельности, инженерном руководстве или на исполнительных должностях.
   - Намерение: насколько серьёзен запрос?
     - «Просто любопытно» vs «активно оценивает» vs «готов купить».
   - Срочность: есть ли заявленная или подразумеваемая временная рамка?
3. Используйте инструмент `score_lead` для фиксации оценок.
4. Используйте инструмент `draft_response` для создания персонализированного ответа.
5. Используйте инструмент `propose_route` с одним из значений: "review_priority", "human_review", "log_only".

Правила маршрутизации (оцениваются в указанном порядке; первое совпадение побеждает):
- "review_priority", если Fit >= 7/10 И Intent >= 7/10. Ответ получает приоритетную проверку человеком.
- "human_review", если Fit >= 5/10 ИЛИ Intent >= 5/10. Человек проверит ответ перед отправкой.
- "log_only" в остальных случаях (Fit < 5/10 И Intent < 5/10). Мы просто фиксируем результат и переходим к следующему.

Никогда не выдумывайте информацию. Если что-то неясно, поставьте отметку [неясно] в обосновании оценки.

Всегда завершайте возвращением объекта JSON:
{
  "fit_score": <1-10>,
  "intent_score": <1-10>,
  "urgency_score": <1-10>,
  "reasoning": "<2-3 предложения>",
  "drafted_response": "<тело письма>",
  "routing": "<review_priority|human_review|log_only>"
}

Обратите внимание на структуру. Здесь есть:

• Чёткое описание задачи.
• Явный процесс (шаги 1–5).
• Явные критерии оценки.
• Явная логика маршрутизации.
• Обязательный формат вывода.

Агент не всегда будет следовать этому идеально. Но чем конкретнее системное сообщение, тем стабильнее он выдаёт одну и ту же форму ответа.

Одного JSON-объекта недостаточно. Добавьте шаг валидации после ноды агента и отклоняйте запуски, где отсутствуют оценки, routing вне разрешённого enum или черновик ответа пустой.

Шаг 3: инструменты

Агенту нужны инструменты для вызовов. В n8n инструменты настраиваются под нодой агента и могут быть:

• Вложенными процессами.
• HTTP-запросами.
• Встроенными tool-нодами.

Соберём для нашего агента четыре инструмента.

Инструмент 1: enrich_lead

Подрабочий процесс, который:

1. Принимает название компании и домен электронной почты на вход.
2. Использует одобренный поисковый инструмент или API данных компаний, условия использования которых разрешают применение.
3. Возвращает структурированные утверждения с каноническими URL источников и датами извлечения; неизвестный размер или идентичность остаются неизвестными.

Описание инструмента (его агент читает, чтобы решить, когда вызывать):

Извлекает разрешённый публичный контекст для компании лида. Вход: название компании и домен электронной почты. Выход: проверенные утверждения с URL источника и датой извлечения, а также информация об неоднозначности/ошибках. Не делайте выводов об идентичности, размере или новостях без указания источника.

Инструмент 2: score_lead

Детерминированный инструмент валидации, который:

• Принимает предложенные оценки и проверяет тип, диапазон, обязательное обоснование и допустимые метки.
• Возвращает ошибки валидации или нормализованный объект оценок.
• Не имеет доступа к базе данных, таблицам, CRM, электронной почте или другим правам на запись.

Сохраняйте данные только после того, как финальный результат агента пройдёт ту же серверную проверку схемы.

Описание инструмента:

Проверяет предложенные оценки лидов без их сохранения. Вход: fit_score, intent_score, urgency_score и обоснование. Выход: {valid, errors, normalized_scores}. Этот инструмент не может записывать записи или отправлять сообщения.

Инструмент 3: draft_response

Вложенный процесс, который берёт контекст лида и оценки и выдаёт персонализированный черновик письма. Внутри этот процесс вызывает ещё одну ИИ-ноду со специальным промптом для черновиков:

Составьте персонализированный ответ на запрос B2B. Входы: исходное сообщение лида, сводка обогащения компании, оценки соответствия/намерения/срочности.

Стиль: тёплый, прямой, без корпоративных клише. Признайте конкретный запрос. Ссылайтесь на данные обогащения только тогда, когда утверждение имеет источник и релевантно; в противном случае опустите его. Завершите предложением следующего шага для проверки человеком.

Длина: 80–120 слов.

Описание инструмента:

Создаёт персонализированный черновик ответа лиду по электронной почте. Входные данные: сообщение лида, сводка обогащения и оценки. Выходные данные: черновик письма.

Инструмент 4: propose_route

Этот инструмент фиксирует одно из трёх предложенных направлений; он не отправляет электронную почту и не записывает данные в CRM:

• review_priority: поместить черновик в очередь приоритетной проверки человеком.
• human_review: поместить черновик в стандартную очередь проверки человеком.
• log_only: зафиксировать результат первичной обработки без подготовки исходящего действия.

Детерминированный узел переключения после проверки схемы обеспечивает соблюдение допустимого перечисления и направляет review_priority и human_review в очередь утверждения. Только отдельный подрабочий процесс, управляемый утверждением, владеет записями, видимыми клиенту.

Реализуйте это как подрабочий процесс без побочных эффектов, возвращающий объект предложения. После завершения узла Agent детерминированный узел проверки схемы и узел переключения решают, какой ветке разрешено сохранить предложение. Ни одна из этих веток не может обратиться к узлу отправки без участия отдельного рабочего процесса утверждения.

Описание инструмента:

Предлагает маршрут. Вход: решение о маршрутизации (review_priority, human_review или log_only), оценки, обоснование и черновик. Выход: объект предложения в памяти для детерминированной проверки схемы. Этот инструмент не может сохранять данные, отправлять электронную почту или обновлять CRM.

Шаг 4: тестируем агента

С настроенным агентом и четырьмя инструментами запустите тест на образце полезной нагрузки.

Что вы должны увидеть в окне выполнения n8n:

1. Вебхук получает полезную нагрузку.
2. Запускается AI Agent.
3. Агент вызывает enrich_lead — вы видите выполнение инструмента и его результат.
4. Агент выбирает следующий шаг (вы можете видеть или не видеть промежуточные трассы в зависимости от модели и настроек).
5. Агент вызывает score_lead.
6. Агент вызывает draft_response.
7. Агент вызывает propose_route с одним из трёх вариантов маршрутизации.
8. Агент возвращает финальный JSON.

Если что-то пошло не так, панель отладки n8n показывает сообщения между агентом и его инструментами. Самые типичные проблемы:

• Описание инструмента недостаточно конкретное. Агент не понимает, когда его вызывать. Сделайте описания конкретнее.
• Несовпадение схемы input/output у инструмента. Агент не может передать правильные аргументы. Опишите схему явно.
• Агент крутится в цикле бесконечно. Он вызывает инструменты, но не приходит к развязке. Установите лимит итераций и пересмотрите системный промпт.

Шаг 5: добавляем ограничители

Голый агент в продакшне небезопасен. Шесть ограничителей, которые стоит добавить до того, как доверять ему реальный трафик:

1. Максимальное число итераций. Установите конечный предел, начиная с наименьшего числа, необходимого для успешных случаев вашей оценки. Проверьте, что достижение предела перенаправляет задачу человеку и не оставляет частичных побочных эффектов.

2. Шлюз одобрения для каждого предлагаемого ответа. review_priority изменяет порядок в очереди; он не авторизует отправку. Поддерживайте коммуникацию с клиентами за шлюзом ручного одобрения с аутентификацией, пока иное не будет утверждено отдельной политикой, и никогда не выводите безопасность из факта прошедших недель.

3. Белый список исходящих действий. Настройте инструменты CRM и почты так, чтобы они работали только с записями, соответствующими ожидаемому шаблону. Это предотвратит отправку письма не туда или создание записей по нелидам.

4. Логирование. Фиксируйте согласованные метаданные для каждого запуска: стабильные идентификаторы лида и воронки, версии рабочего процесса и модели, названия инструментов и их результаты, результат валидации, маршрут, утверждающее лицо, количество повторных попыток и ошибки. Исходные данные лида, результаты обогащения, черновики и аргументы инструментов содержат персональные или конфиденциальные сведения и требуют отдельного решения о цели обработки, обезличивании, доступе и сроке хранения.

5. Лимиты затрат. Установите конечное число итераций агента и таймауты рабочего процесса, настройте оповещения об использовании или лимиты расходов у провайдера модели. Лимиты плана n8n описываются в терминах количества выполнений и доступных функций; не предполагайте, что n8n Cloud устанавливает дневной бюджет для ключа bring-your-own (принеси своего). Отслеживайте использование ресурсов провайдером и тестируйте функцию экстренного отключения.

6. Ответственность за решения. Модель может рекомендовать review_priority, human_review или log_only; рабочий процесс обеспечивает соблюдение финального правила. Храните перечисление маршрутов, пороги оценок и требования к одобрению вне промпта, чтобы они были тестируемыми и видимыми.

Шаг 6: подготовка к продакшну

Несколько паттернов, которые превращают рабочий прототип во что-то, чему можно доверять:

Идемпотентность. Убедитесь, что повторная обработка одного и того же лида — из-за повторной попытки вебхука или ручного перезапуска — не создаст дублирующихся записей или сообщений. Проверка по схеме «сначала прочитать, затем записать» подвержена гонкам данных: атомарно резервируйте уникальный ключ в базе данных и используйте его при каждой последующей записи. Следуйте схеме с атомарным резервированием, арендой, токеном одобрения и шаблоном outbox.

Обработка ошибок. Оборачивайте каждый вызов инструмента в обработчик ошибок. Если сервис обогащения данных недоступен или компания идентифицирована неоднозначно, рабочий процесс должен отметить отсутствующие данные и направить результат на проверку человеку; он не должен выдумывать персонализированные сведения лишь ради завершения черновика.

Наблюдаемость. Отслеживайте ключевые метрики: среднее время запуска, частота вызовов инструментов, процент маршрутизации по каждому пути. Аномалии — это сигналы.

Обзор пилотного запуска. Просматривайте каждый запуск в согласованном, ограниченном пилоте, сверяясь с исходным лидом. Размер пилота должен охватывать типы источников, языки, отсутствующие поля, неоднозначные компании, попытки инъекций и классы приоритетов. Отслеживайте ошибки обогащения, оценки, маршрутизации, сроков выполнения и черновика. Фиксированное количество в 50 не устанавливает уровень надежности.

Исполнимый переключатель экстренного отключения. Блокируйте выполнение и каждый диспетчер побочных эффектов вне модели, чтобы авторизованный оператор мог приостанавливать новые и возобновляемые запуски без повторного развертывания. Проверьте, что отключенное состояние блокирует отправку в очереди и в процессе выполнения; инструкция промпта или значение, которое «проверяет» только агент, не является переключателем экстренного отключения.

Самое важное проектное решение: какие инструменты дать агенту

Качество агента больше всего определяется набором инструментов. Два режима провала:

Слишком мало инструментов. Агент не может выполнять свою работу. Он пытается выкрутиться, обходя недостающие возможности, — часто через галлюцинации.

Слишком много инструментов. Агент путается, выбирает не тот инструмент или тратит итерации на разведку. Качество просаживается.

Хорошее правило: начинайте с минимально жизнеспособного набора инструментов и добавляйте новые, только когда агенту они доказуемо нужны.

Для триажа лидов выбранные нами четыре инструмента — примерно то, что нужно. Можно ещё добавить:

• Инструмент «lookup_existing_customer», чтобы проверить, не является ли лид уже клиентом.
• Инструмент «schedule_meeting», интегрированный с вашим календарём.
• Инструмент «translate», если лиды приходят на нескольких языках.

Но каждый новый инструмент — это новое решение, которое агенту приходится принимать. Каждый должен честно заслужить своё место.

Паттерны, которые обобщаются

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

Сортировка тикетов поддержки. Получите разрешенную историю клиента и предложите категорию/приоритет; держите действия с учетной записью, безопасностью, возвратом средств, правами и сообщениями клиента за шлюзами политики и человека.

Рабочие процессы найма. Не адаптируйте оценку лида в автоматизацию собеседований или отклонений. Решения о трудоустройстве могут создавать юридические риски и риски дискриминации, требуют квалифицированного обзора HR/юридического отдела, контроля доступности, оценки предвзятости, прозрачности для работников и соискателей, а также осмысленного принятия решений человеком.

Обработка запросов от прессы. Замените обогащение на «lookup_publication», а маршрутизацию — на ответы по приоритету.

Маршрутизация обратной связи от клиентов. Замените обогащение на анализ тональности и категоризацию по продуктам.

Заявки на закупки. Замените обогащение на поиск по поставщикам, оценку — на соответствие политике, маршрутизацию — на потоки согласований.

Повторно используемый паттерн для действий с низкими последствиями: проверка входящего события → получение минимально необходимого разрешённого контекста → запрос структурированного предложения → детерминированная проверка → передача права решения уполномоченным правилам или людям → выполнение через идемпотентные инструменты с контрольными шлюзами. Модель предлагает вариант, но не принимает ответственное решение.

Когда НЕ стоит использовать агента

Некоторые рабочие процессы от агента не выигрывают. Если логика полностью детерминирована — «всегда делай A, потом B, потом C» — обычный процесс n8n без агента работает быстрее, дешевле и надёжнее.

Агент оправдывает себя, когда:

• Возможных путей много.
• Правильный путь зависит от суждения, а не от строгих правил.
• Часть решений требует синтеза информации из нескольких источников.

Если ваше дерево решений состоит из нескольких ветвей «если — то — иначе», используйте обычные условные узлы. Подключайте агента только тогда, когда такой граф становится неуправляемым.

Соберите один раз — на реальной задаче

ИИ-агент в n8n — это рабочий процесс, в котором модель может выбирать среди настроенных инструментов. Проектирование для производства ограничивает этот выбор и держит подотчетных людей и детерминированную политику под контролем ответственных решений.

Проектирование завершено только после теста на дублирующую доставку, теста некорректного результата, теста таймаута провайдера, теста отклоненного одобрения и проверки того, что узел отправки недостижим без одобрения. Измеряйте время сборки, задержку, частоту исправлений и затраты на вашем собственном экземпляре; эта статья не обещает время настройки или производственный результат.

Сначала соберите и протестируйте его на синтетических или явно разрешённых непроизводственных данных. Повторно используйте паттерн контроля — узкие инструменты, схемы, идемпотентность, правила остановки и шлюзы проверки, — но для каждого нового рабочего процесса заново проводите анализ предметной области и рисков.