Готовые ИИ-агенты в n8n: разборы сценариев

Агентные ноды в n8n позволяют собрать рабочего агента без кода, и на этом же ломаются: агентом делают то, что должно быть обычным воркфлоу. Разберём три сценария, где связка оправдана.

Общее правило перед сценариями

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

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

Сценарий 1. Агент поддержки первой линии

Задача. Входящее обращение превращается в ответ либо в передачу человеку.

Как собирается. Триггер на входящее сообщение, нода агента с двумя инструментами: поиск по базе знаний и поиск заказа по номеру. Дальше ветвление: если агент уверен - отправка ответа, если нет - создание задачи для человека.

Что здесь устроено правильно:

• Отправка ответа вынесена за пределы агента. Он готовит текст, а отправляет отдельная нода. Это позволяет проверить результат до отправки и логировать то, что реально ушло.
• Инструментов два, а не десять. Агент не путается в выборе.
• Есть явный выход «не знаю». Без него агент будет придумывать ответ вместо признания, что данных нет.

Что ломается на практике. Агент отвечает уверенно на вопросы, которых нет в базе знаний. Лечится не промптом, а порогом: если поиск ничего не нашёл, ветка идёт к человеку независимо от того, что написал агент.

Сценарий 2. Агент-классификатор

Задача. Входящие письма разложить по категориям и назначить приоритет.

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

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

Как правильно: нода модели со схемой ответа, затем ветвление по категории обычными нодами. Если категория не определилась - отдельная ветка, а не попытка угадать.

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

Сценарий 3. Агент с доступом к базе

Задача. Отвечать на вопросы по данным: остатки, статусы, сводки.

Как собирается. Агент с инструментом «выполнить запрос к базе» - и вот здесь начинается самое важное.

Что обязательно:

• Права только на чтение. Отдельный пользователь базы, доступ к нужным таблицам. Не потому что агент злонамерен, а потому что он ошибается.
• Лимит на объём ответа. Запрос без ограничения вернёт тысячи строк, они попадут в контекст, и следующий шаг станет дороже и хуже.
• Готовые инструменты вместо произвольного SQL. Инструмент «остаток по товару» надёжнее инструмента «выполни любой запрос»: агент не ошибётся в структуре и не соберёт тяжёлый join.
• Расчёты на стороне базы. Агент, получивший тысячу строк, чтобы посчитать сумму, потратит контекст и ошибётся в арифметике.

Подробно про права и границы - в статье про безопасность MCP; принципы те же, независимо от того, как подключён доступ.

Что вынести из агента

Короткий список, который улучшает почти любой агентный воркфлоу:

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

После этого у агента остаётся ровно то, ради чего он нужен: разбор неструктурированного и решение в неоднозначных случаях.

Базовая настройка агентных нод - в статье AI-агенты в n8n. Как подключать внешние инструменты - MCP в n8n. Общая теория - гид по ИИ-агентам. Обзор n8n - пиллар гида.