Автоматизация с LLM внутри устроена иначе, чем обычный воркфлоу. Обычная нода детерминирована: одинаковый вход даёт одинаковый выход. Модель детерминирована не полностью, и это меняет то, как строить вокруг неё процесс.
Как модель попадает в воркфлоу
Два пути. Первый: нода HTTP Request с ручной настройкой запроса под нужный формат API. Второй: встроенные AI-ноды n8n, где провайдер и модель выбираются из списка, а тело запроса собирается автоматически.
Для простых сценариев готовая нода быстрее. Для нестандартных, где нужен специфический системный промпт, кастомная схема инструмента или тонкий контроль над параметрами вроде температуры, HTTP Request даёт больше свободы и не зависит от того, добавили ли разработчики n8n нужную опцию в интерфейс ноды.
Пример тела запроса через HTTP Request на эндпоинт Claudexia:
{
"model": "claude-sonnet-4.6",
"max_tokens": 500,
"messages": [
{ "role": "user", "content": "={{ $json.customerMessage }}" }
]
}
Заголовок x-api-key с ключом sk_cdx_... настраивается один раз через n8n credentials и переиспользуется во всех нодах воркфлоу.
Практические паттерны
Классификация входящих сообщений. Письмо, заявка из формы или сообщение в чате разбирается на категорию, дальше воркфлоу ветвится по результату. Здесь модель выступает заменой ручного правила, которое пришлось бы держать в десятках условных операторов.
Извлечение полей из свободного текста. Из письма клиента вытащить сумму, дату и товар, из резюме вытащить стек технологий и опыт. Просите модель отвечать строго в JSON и валидируйте результат следующей нодой, свободный текст в автоматизации без ручной проверки не годится.
Суммаризация перед уведомлением. Длинный тред переписки сжимается в три строки перед тем, как уйти в Slack или Telegram. Это снижает шум для человека, который принимает решение по итогу воркфлоу, но не должен читать всю историю.
Роутинг тикетов и заявок. Комбинация классификации и извлечения: определить приоритет, отдел и главные факты одним запросом, а не тремя последовательными нодами.
Обработка ошибок в воркфлоу
Модель может вернуть невалидный JSON, обрезанный ответ из-за низкого max_tokens или ошибку самого API. В n8n на это отвечает нода Error Trigger или встроенная опция Continue On Fail у ноды с запросом, чтобы один сбой не остановил весь воркфлоу для всех проходящих через него заявок.
Практика, которая экономит часы отладки: добавляйте отдельную ветку валидации сразу после запроса к модели. Проверяйте структуру ответа кодом на JavaScript-ноде, и только если проверка прошла, пускайте результат дальше. Невалидный ответ уходит в лог или в отдельный канал для ручного разбора, а не ломает основной путь.
Контроль расходов по нодам
Не каждая нода в воркфлоу требует одинаковой модели. Классификация из трёх категорий и генерация текста для рассылки это разные по сложности задачи, и разумно назначить им разные модели прямо в настройках соответствующей ноды.
Практический подход: держите классификацию и извлечение полей на младшей модели, а финальную генерацию текста, который увидит клиент, на модели посильнее. В n8n это делается сменой значения в поле model конкретной ноды, без правки остальной логики воркфлоу.
Ещё один рычаг: ограничивайте max_tokens под задачу. Классификатору, который должен вернуть одно слово, не нужен лимит в тысячу токенов, а типичная ошибка это скопировать значение по умолчанию из примера и не подумать, действительно ли ответ настолько длинный.
Отдельный ключ на автоматизацию
Воркфлоу в n8n работают по расписанию или по вебхуку и могут запускаться сотни раз в день без участия человека. Держать их на общем ключе с ручной работой команды неудобно: сложно понять, кто именно съел лимит, и сложно ограничить автоматику отдельно от людей.
У Claudexia на каждый ключ настраиваются свои лимиты и своя статистика запросов, поэтому под n8n разумно завести отдельный ключ. Тогда видно расход конкретно автоматизации, а при аномальном всплеске, например зацикленном воркфлоу, ключ можно ограничить или отключить, не трогая ключи живых пользователей.
Коротко
LLM в n8n добавляют в воркфлоу непредсказуемость там, где раньше была детерминированная логика, поэтому валидация ответа и обработка ошибок обязательны, а не опциональны. Разводите модели по нодам под сложность задачи и держите разные max_tokens под разные роли. Отдельный ключ под автоматизацию с собственным лимитом избавляет от гадания, откуда взялся неожиданный счёт.