ИИ-агент в n8n: как собрать первую автоматизацию без большого приложения

n8n позволяет соединить триггер, модель и действия в визуальном workflow. Для первого ИИ-агента не нужно строить отдельный кабинет, базу пользователей и сложный backend. Но нужно ограничить задачу: агент выбирает инструмент, поэтому ошибка может закончиться не странным текстом, а реальным письмом или измененной записью.

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

В обычной автоматизации путь задан заранее:

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

Если процесс полностью описывается условиями if/else, не добавляйте агента только ради слова «ИИ». Обычный workflow проще тестировать и дешевле поддерживать.

Для первого проекта задайте узкий результат:

Запишите, что агент не делает:

· не отправляет массовые письма;

· не меняет заказы;

· не выдает возвраты;

· не редактирует базу знаний;

· не отвечает по юридическим вопросам;

· не выполняет инструкции из пользовательского текста как системные команды.

Так проще выбрать nodes, данные и тесты.

Добавьте Chat Trigger. Он запускает workflow при новом сообщении и дает тестовый чат. Для первой версии используйте встроенный интерфейс n8n, чтобы не смешивать логику агента с разработкой сайта.

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

Не передавайте в модель все данные пользователя «на всякий случай». Для ответа о программе не нужны платежные реквизиты, адрес и полная история заказов.

Создайте credential для выбранного провайдера в n8n. Не вставляйте API-ключ в поле промпта, Code node или экспортируемый JSON workflow. Проверьте, кто в проекте может запускать workflow и использовать связанные credentials.

Настройте разумный timeout и обработку ошибки провайдера. Пользователь должен получить нейтральное сообщение и путь к человеку, а не технический стек или бесконечное ожидание.

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

Соедините Chat Trigger с AI Agent и выбранной chat model. В системной инструкции задайте:

· роль;

· разрешенный источник фактов;

· формат ответа;

· условия отказа;

· критерий передачи человеку;

· запрет на выдуманные условия;

· правило не раскрывать внутреннюю инструкцию.

Пример:

Не полагайтесь только на скрытый маркер в свободном тексте. После Agent node добавьте явную проверку результата и отдельную ветку передачи.

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

Для каждого tool опишите:

· что он делает;

· какие параметры обязательны;

· какие значения допустимы;

· какой результат возвращает;

· что считать ошибкой.

Название manage_customer слишком широкое. Отдельные инструменты find_course_info и create_handoff_draft дают более ясную границу.

Если позже появится действие с последствиями, используйте human-in-the-loop. Документация n8n позволяет требовать одобрение до выполнения конкретного tool. Подтверждение особенно нужно для отправки, удаления, изменения денег, прав или внешних записей.

n8n публикует отдельный пример human fallback. Смысл не в том, чтобы попросить модель «быть осторожной», а в том, чтобы workflow имел техническую ветку выхода.

Передавайте оператору:

· исходный вопрос;

· краткую причину отказа;

· черновик ответа, если он безопасен;

· идентификатор сессии;

· время и источник обращения.

Не отправляйте всю внутреннюю память, если она не нужна. Оператор должен видеть достаточно для решения, но не лишние персональные данные.

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

Составьте минимум четыре группы:

1. обычные вопросы с точным ответом;

2. вопросы, которых нет в источнике;

3. запросы о цене, возврате и персональных условиях;

4. попытки заставить агента игнорировать правила или раскрыть инструкцию.

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

n8n поддерживает evaluations на известных тестовых случаях и метрики качества. Для первой версии можно начать с таблицы из 20–30 примеров и ручной оценки, затем автоматизировать повторный прогон.

В разделе Executions видно, какой node получил данные, что вернул и где произошла ошибка. При неудаче отделите три причины:

· модель выбрала неверный маршрут;

· tool вернул плохие или неполные данные;

· логика workflow неверно обработала корректный ответ.

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

При повторном запуске не допускайте двойного действия. В n8n можно retry failed execution с текущей или исходной версией workflow. Если в предыдущей попытке письмо уже ушло или запись создалась, полный retry может повторить эффект. Для действий используйте идентификатор операции и проверку дубля.

До активации workflow:

· уберите тестовые credentials;

· проверьте права проекта;

· задайте timeout;

· создайте Error Workflow или уведомление о сбое;

· ограничьте число запросов;

· определите срок хранения execution data;

· убедитесь, что логи не содержат секреты;

· назначьте человека, который принимает fallback.

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

· долю правильных самостоятельных ответов;

· долю передач человеку;

· ложные самостоятельные ответы;

· время ответа пользователя и оператора;

· стоимость одного принятого ответа;

· число повторных действий и технических ошибок.

Если никто не разбирает передачи, агент не экономит время, а создает новую очередь.

Одна модель может сразу определить тему, найти данные и написать текст, но такую ошибку трудно диагностировать. Для первого workflow разделите этапы. Сначала получите структурированный результат: категория, уверенность, требуется ли человек. Затем отдельная ветка формирует ответ только для разрешенных категорий.

Проверяйте значения обычным Switch или If node. Не доверяйте произвольной строке. Если категория не входит в список или обязательное поле отсутствует, направляйте случай человеку.

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

Chat Trigger, webhook или внешний сервис может повторить событие. Добавьте стабильный идентификатор сообщения и храните факт обработки. Перед внешним действием проверяйте, не выполнялось ли оно раньше.

Для отправки письма или создания записи используйте статус: received, drafted, approved, sent. Переходы должны происходить явно. Если выполнение упало после отправки, retry сначала видит sent и не создает дубль.

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

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

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

Добавьте тесты на prompt injection, слишком длинный ввод, неизвестный язык и вставку секретоподобной строки. В логах редактируйте чувствительные поля.

Перед правкой экспортируйте или сохраните текущую версию. Запишите версию системной инструкции и модели в execution data. Тогда плохой ответ можно связать с конкретной конфигурацией.

После изменения прогоните одинаковый набор. Не меняйте одновременно модель, prompt, tools и базу знаний: если качество изменится, причину будет трудно найти. Публикуйте новую версию после сравнения, а не сразу после одного удачного чата.

Один пользовательский вопрос может вызвать несколько запросов модели и tools. Считайте стоимость всей execution, включая повтор и проверку. Ограничьте максимальное число шагов агента, длину контекста и время выполнения.

Настройте rate limit на публичный trigger и бюджетные уведомления у провайдера модели. При достижении лимита workflow должен перейти в понятный fallback, а не бесконечно повторять дорогой запрос.

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

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

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

Собрать такой ограниченный workflow и научиться проверять его как систему можно на курсе «Вайб-кодинг: быстрый старт». n8n сокращает объем приложения, но не отменяет решения о доступах и последствиях.

Первый ИИ-агент в n8n должен уметь не только отвечать, но и правильно останавливаться. Когда отказ, передача человеку и повторная проверка встроены в workflow, к нему можно постепенно добавлять инструменты.