Собрали в n8n цепочку: письмо приходит, модель его разбирает, ответ уходит клиенту. Всё работает на тестовом ключе, пока не выясняется, что ключ этот чужой и завтра отключится. Своя карта не проходит, счёт от зарубежного провайдера оплатить нечем, а конвейер уже стал частью процесса. Знакомая развилка.
Разберём, как подключить китайскую модель к n8n так, чтобы это не развалилось через месяц, и где обычно прячутся грабли.
Что n8n берёт на себя, а что остаётся вам
n8n — конструктор рабочих процессов. Он ловит события (вебхук, расписание, письмо, новая строка в таблице), передаёт данные между шагами и вызывает внешние сервисы. Модель для него — просто ещё один внешний сервис.
Из этого следует простая мысль. Вопрос доступа n8n не решает. Он аккуратно вызывает то, что вы ему дали, и так же аккуратно упадёт, если ключ не работает или закончилась квота.
Поэтому порядок такой: сначала рабочий доступ к модели с понятной оплатой, потом узел в n8n. В обратном порядке получается красивая схема, которая не запускается.
Три способа подключить модель
- Готовый узел OpenAI. В n8n есть узлы под популярные сервисы, и у большинства можно переопределить адрес API. Если шлюз совместим с форматом OpenAI, узел работает без правок кода: меняете адрес и ключ.
- Узел HTTP Request. Универсальный вариант. Сами формируете тело запроса, сами разбираете ответ. Больше полей на экране, зато видно каждую деталь.
- Свой код в Code-узле. Нужен, когда ответ надо переложить в нестандартную структуру или склеить несколько вызовов. Держите его коротким, иначе отладка превратится в чтение логов.
На старте берите второй вариант. HTTP Request показывает ровно то, что уходит на сервер, и экономит часы, когда ответ приходит не тот, которого ждали.
Настройка узла: что вписать в поля
Минимум для рабочего вызова: адрес, метод, заголовки, тело. Ключ храните в Credentials или в переменной окружения, а не текстом в узле. Текстом он уедет в экспорт воркфлоу, а оттуда в чей-нибудь ноутбук.
POST /v1/chat/completions
Authorization: Bearer {{ $env.KITAI_KEY }}
Content-Type: application/json
{
"model": "deepseek-chat",
"messages": [
{"role": "system", "content": "Ты помощник поддержки. Отвечай коротко."},
{"role": "user", "content": "{{ $json.text }}"}
],
"temperature": 0.3
}
Три вещи здесь важнее остального. Путь до /chat/completions, а не просто домен. Модель указана явно. Температура низкая, потому что для ответов клиентам нужна предсказуемость, а не творчество.
Где ломается на практике
- Таймаут. Длинный ответ генерируется дольше, чем позволяет дефолтный лимит узла. Ставьте запас и не гоняйте через один вызов простыню на десять тысяч слов.
- Разбор ответа. Модель возвращает JSON строкой внутри JSON. Если сразу обратиться к полю, получите пустоту. Сначала достаньте content, потом разбирайте его.
- Повторы. Без ретраев сетевой сбой роняет всю цепочку. С ретраями без лимита вы платите за один и тот же запрос несколько раз.
- Размер контекста. Пересылка всей истории переписки на каждом шаге быстро превращается в счёт за токены, который никто не планировал.
Правило, которое спасает: вызов модели в конвейере должен быть идемпотентным. Повторный запуск не должен отправлять клиенту второе письмо.
Сценарий, который считается сам
Возьмите обработку входящих заявок с сайта. Сейчас менеджер читает письмо, вытаскивает город, объём и срок, переносит в таблицу. Минуты на каждую заявку, опечатки при копировании, вечером очередь.
В n8n это собирается за вечер: вебхук принимает заявку, узел модели возвращает JSON с нужными полями, дальше ветка — строка в таблице и сообщение менеджеру. Модель здесь не принимает решений, она приводит текст к структуре. Это самая надёжная роль для модели в автоматизации, результат проверяется за секунду.
Второй по окупаемости сценарий — черновики ответов. Модель пишет вариант, человек правит и отправляет. Пока не набралась статистика по качеству, отправлять сгенерированный текст клиенту напрямую не стоит.
Как держать расход под контролем
Стоимость в n8n складывается не из одного вызова, а из числа прогонов, умноженного на длину промпта. Три привычки закрывают большую часть сюрпризов.
- Логируйте в отдельную таблицу модель, число токенов и длительность по каждому вызову. Без этого спорить о расходах бессмысленно.
- Ограничьте историю диалога окном. Последние пять сообщений обычно дают тот же результат, что и вся переписка.
- Поставьте лимит прогонов в час на каждый воркфлоу. Ошибка в цикле без лимита съедает бюджет за ночь.
Чек-лист перед передачей в работу
- Ключ лежит в Credentials, воркфлоу экспортирован без него.
- Ошибка модели обрабатывается отдельной веткой, а не тишиной в логах.
- Есть ограничение по длине входа: слишком длинный текст обрезается или уходит в очередь.
- Результат вызова сохраняется, чтобы разбор инцидента не начинался с нуля.
- Написано, кто и по какому сигналу останавливает процесс.
Список кажется скучным, пока первый раз не придётся объяснять, почему клиент получил три ответа на одно письмо.
Что в итоге
n8n хорошо подходит для подключения китайских моделей: не требует кода, показывает запрос целиком, легко меняет провайдера. Сложность не в узлах, а в доступе и в дисциплине вокруг вызовов. Если ключ живёт в переменных, у вызовов есть лимиты, а ответы логируются, конвейер переживёт смену модели без переписывания.
Если сейчас выбираете, что подключить первым, начните с разбора моделей под задачу. Про безопасное хранение ключа мы писали в статье как получить API-ключ, а ещё один рабочий сценарий разобран в материале про автоматизацию контента.
Китай-API — российский шлюз к китайским моделям: один ключ в формате OpenAI, оплата в рублях, счета для юрлица. Продукт в подготовке, запуск скоро. Заявки на ранний доступ уже принимаем.