AI-агенты в n8n: LLM, инструменты, память и когда агент не нужен

AI-ноды - то, ради чего многие приходят в n8n сейчас. Инструмент здесь действительно сильнее соседей: модель, инструменты, память и векторное хранилище собираются в одном холсте. Но именно здесь проще всего построить дорогую и непредсказуемую систему там, где хватало одного запроса.

Вызов модели или агент

Разница принципиальная, и её стоит держать в голове до начала сборки.

Обычный вызов модели - один шаг: отправили промпт и данные, получили ответ. Предсказуемо по времени, по цене и по поведению. Этим закрывается большинство задач: классификация обращений, извлечение полей из текста, суммаризация, генерация ответа по шаблону.

Агент - модель, которой дали инструменты и право решать, что вызвать. Он может сходить в поиск, дёрнуть ваш API, посмотреть в базу, потом сделать это ещё раз, а потом ответить. Один запуск агента - это несколько обращений к модели.

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

Инструменты

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

Практика, которая определяет качество работы агента, - описания. Модель выбирает инструмент по его описанию, а не по названию. «Получить данные» - плохое описание; «Найти клиента по email, вернуть статус подписки и дату оплаты» - хорошее. Половина проблем «агент не вызывает нужный инструмент» лечится переписыванием описаний, а не сменой модели.

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

И третье, про безопасность: инструмент - это реальное действие. Агент, у которого есть инструмент «удалить запись», однажды его вызовет. Опасные операции либо не давайте вовсе, либо ставьте между агентом и действием проверку.

Память

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

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

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

Свои документы и RAG

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

Что на практике определяет результат: качество нарезки (слишком мелкие фрагменты теряют контекст, слишком крупные размывают релевантность) и актуальность индекса - документы меняются, а вектора остаются старыми, пока вы не переиндексируете. Второе стоит закладывать сразу как отдельный воркфлоу по расписанию, а не вспоминать через полгода, когда бот начнёт отвечать по устаревшему регламенту.

Расходы

Агент - это переменная стоимость, и это меняет подход к эксплуатации. Один запуск может стоить и цент, и заметно больше, если агент долго ходит по инструментам.

Что стоит сделать до продакшена:

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

Что ломается в продакшене

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

Недетерминированность. Один и тот же вход даёт разные ответы. Это нормально для модели и неприемлемо для процесса, где важна воспроизводимость.

Тихая деградация. Агент продолжает отвечать, но хуже - сменился промпт, устарел индекс, поменялась модель. Падения нет, error workflow молчит. Единственная защита - выборочная проверка ответов человеком, хотя бы раз в неделю.