ИИ-агент в n8n: как собрать рабочий процесс и проверить результат

На демонстрации агент прочитал заявку, ответил клиенту и сообщил, что создал сделку. Заказчик доволен. А сделка точно появилась в CRM? С тем телефоном, у нужного менеджера, один раз? Именно с этих вопросов начинается рабочая автоматизация.

n8n связывает шаги процесса: получение сообщения, обращение к языковой модели, вызов внешней системы и дальнейшие действия. В этой статье разберём учебный пример обработки заявки. Его можно использовать как основу задания разработчику. Готового универсального workflow здесь нет: поля CRM, способы авторизации и правила обработки обращений у каждой компании свои.

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

Начните с одного результата, который можно показать

Формулировка «нужен ИИ-агент для продаж» оставляет слишком много свободы. Хорошее первое задание звучит так: из входящего сообщения подготовить карточку заявки, проверить обязательные поля, создать запись в CRM и сохранить её идентификатор. Если данных не хватает, передать обращение менеджеру с понятной причиной.

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

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

Где нужен агент, а где достаточно обычного узла

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

В официальном репозитории n8n описано различие между AI Agent, одиночным вызовом модели через Basic LLM Chain и специализированным Text Classifier. У AI Agent есть подключения модели, инструментов и памяти. Выбор узла стоит делать по задаче.

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

Красивая схема с одним большим агентом плохо показывает, где произошла ошибка. Разделённые шаги позволяют увидеть: модель неверно извлекла номер, проверка пропустила пустое поле или CRM отказала при записи.

Соберите цепочку от входа до подтверждения записи

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

После разбора сообщения нужна проверка. В учебном примере пустой телефон отправляет заявку на ручной разбор. Обещание клиента «номер пришлю позже» не превращается в фиктивный номер, лишь бы пройти дальше. Исходное сообщение сохраняется рядом с результатом разбора, чтобы менеджер видел, что именно написали.

Следующий шаг записывает карточку в CRM. Полученный идентификатор сохраняется в журнале процесса. Для приёмки полезно выполнить отдельное чтение созданной записи и сравнить обязательные поля. Ответ клиенту «заявка принята» разрешается только после подтверждённого результата записи; если CRM недоступна, текст ответа должен отражать это состояние.

Так вы получаете след операции: входящее обращение → подготовленные поля → ответ CRM → проверенная карточка. Этот след пригодится и для расследования, и для оценки качества автоматизации. Одной зелёной галочки запуска недостаточно.

Дайте инструментам узкие полномочия

Инструмент — действие, которое агент может вызвать: найти заявку, прочитать справочник или подготовить запись. Описание инструмента должно говорить, какие параметры он принимает и что возвращает. Название «работа с CRM» слишком широкое: из него неясно, разрешены ли чтение, запись и удаление.

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

Перед отправкой письма или изменением существующей сделки можно поставить согласование с человеком. В официальных материалах n8n описан контроль вызова инструментов. Наличие такого механизма в платформе ещё не означает, что он включён в вашем процессе.

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

Разделите память разговоров между пользователями

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

В руководстве n8n о памяти агентов объясняются история разговора и внешнее хранение. Для queue mode, где задания выполняют разные workers, авторы рекомендуют Postgres или Redis Chat Memory вместо Simple Memory. Выбор хранилища нужно согласовать с режимом размещения.

Учебный тест простой. Пользователь А называет устройство «насос А», пользователь Б — «компрессор Б». После нескольких сообщений оба спрашивают, что они указали раньше. Затем повторите проверку после перезапуска и при параллельных обращениях. Ожидаемое поведение после сброса истории также должно быть определено заранее.

Хранить всё бесконечно необязательно. Выпишите, какие факты нужны для продолжения заявки, когда разговор считается завершённым и кто может удалить историю. Данные карточки в CRM и память чата имеют разные задачи; потерю одной нельзя незаметно компенсировать другой.

Повтор заявки не должен создавать вторую сделку

Клиент дважды нажал кнопку. Канал повторно доставил событие. После таймаута workflow запустили ещё раз. Все три ситуации способны привести к повторному созданию записи, если процесс не различает новое обращение и повтор уже принятого.

Для защиты нужен ключ операции. В учебном варианте он строится из идентификатора события канала и имени операции. Ключ сохраняется в надёжном хранилище с ограничением уникальности. Проверка «есть ли запись» и последующая вставка без защиты от параллельного выполнения оставляют гонку: оба запуска успевают решить, что записи нет.

Особенно неприятен таймаут после записи. CRM уже создала сделку, но подтверждение не дошло. Бездумный повтор создаёт дубль. Сначала выясните, поддерживает ли конкретная CRM ключ идемпотентности или поиск по внешнему идентификатору. Если надёжного способа нет, спорный результат следует отправлять на сверку.

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

Ограничьте время и число попыток

У агента, API и всего workflow должны быть понятные пределы выполнения. Количество итераций ограничивает агентский цикл, но не является самостоятельным месячным бюджетом. Одна итерация способна включать дорогой запрос или обращение к медленному сервису.

В справке конфигурации AI Agent описан параметр maxIterations. Его значение и доступные настройки проверяйте в установленной версии. Увеличивать предел при каждом зависании — плохой способ выяснить причину сбоя.

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

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

Проверьте процесс на неудобных входных данных

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

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

Что подготовить перед первым пилотом

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

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

Результат первого этапа — схема, которую можно объяснить и повторно проверить на ваших примерах. Для общего контроля передачи бота пригодится приёмочная ведомость. Если нужна помощь с процессом в n8n, опишите задачу студии: откуда приходит событие, какой результат должен появиться и какую ошибку вы считаете недопустимой.