Как подключить Open WebUI к n8n

Как подключить Open WebUI к n8n: в n8n соберите воркфлоу с узлом Chat в режиме Embedded Chat и Response Mode Streaming, скопируйте Chat URL, оканчивающийся на /chat, а в Open WebUI через Workspace → Functions вставьте n8n_pipeline.py и укажите этот URL в valves MODELS. Ниже — порядок действий, проверка вебхука вне Open WebUI и таблица диагностики.

Какая функция используется

Основной путь описан в README проекта sveneisenschmidt/openwebui-n8n-function. Это упрощённая и оптимизированная n8n-пайплайн-функция для Open WebUI: она стримит ответы из воркфлоу n8n прямо в чат и ведёт учёт сессий. В репозитории лежат n8n_pipeline.py (основной код, рекомендуется для продакшена), n8n_pipeline_remote.py (загрузка кода из GitHub), n8n_workflow.json (пример воркфлоу) и README.

Другие реализации той же задачи устроены иначе. Пулл-реквест owndev/Open-WebUI-Functions описывает настройку через Admin Panel → Functions → N8N Pipeline, а страница colinwheeler/n8n_ai_agent_connector_pipe в каталоге Open WebUI предлагает собственную функцию с иными полями. Если вы возьмёте чужой код, названия valves, путь к меню и формат ответа будут отличаться от инструкции ниже. Держитесь одного README и сверяйте поля по нему.

Функция работает как мост: Open WebUI отвечает за интерфейс чата, n8n — за логику и оркестрацию моделей. Промежуточные сервисы вроде LiteLLM или OpenRouter можно вызывать прямо из воркфлоу n8n, тогда ключи живут в хранилище учётных данных n8n. Каждому чату присваивается уникальный sessionId, поэтому n8n различает беседы.

Настройка узла Chat в n8n

В n8n добавьте узел Chat — он одновременно служит вебхуком и точкой входа. По документации Chat Trigger режим доступа выбирается после включения Make Chat Publicly Available: пока вы собираете воркфлоу, переключатель держат выключенным, а перед публикацией включают. Затем в параметре Mode выберите Embedded Chat: этот режим предполагает собственный интерфейс, который вызывает вебхук из поля Chat URL.

Response Mode поставьте в Streaming. Документация n8n поясняет: режим Streaming response включает потоковую отдачу данных по мере обработки и требует узлов с поддержкой стриминга в воркфлоу, например AI Agent. Режим Using Response Nodes отвечает так, как задано в узле Chat или Respond to Webhook, и заменяет прежний режим Using Respond to Webhook Node из версии 1.2.

Скопируйте полный адрес из поля Chat URL. По README он оканчивается на /chat в пути, и именно этот полный адрес идёт в конфигурацию MODELS. Пример из README: https://n8n.example.com/webhook/abc123/chat. Если скопировать адрес без сегмента /chat, функция обратится не туда.

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

Подключение AI Agent и памяти

К узлу Chat подключите AI Agent и включите у него опцию Enable Streaming — без неё потоковая отдача из Chat Trigger не заработает. Документация n8n называет AI Agent примером узла с поддержкой стриминга, который нужен режиму Streaming response.

Память добавляется отдельным саб-узлом. По документации Chat Trigger при выборе любого варианта Load Previous Session кроме Off нужно соединить и триггер, и агента с одним и тем же саб-узлом памяти: так у обоих узлов будет единый источник состояния. README рекомендует Memory Tool вроде Simple Memory с настройками по умолчанию: sessionId из chat_id Open WebUI подставляется автоматически, и n8n удерживает контекст между сообщениями.

Что уходит в n8n. README перечисляет поля payload: systemPrompt, currentMessage, chatInput, sessionId, userId, userEmail, userName. При включённом SEND_CONVERSATION_HISTORY добавляется массив messages с ролями user и assistant. По умолчанию история не отправляется — только текущее сообщение, а контекст ведёт память n8n по sessionId.

Тестовый и рабочий адрес вебхука

Документация n8n различает два адреса вебхука. Тестовый регистрируется, когда вы выбираете Listen for Test Event или Execute workflow при неактивном воркфлоу: при вызове адреса n8n показывает данные прямо в редакторе. Рабочий регистрируется при публикации воркфлоу, данные в редакторе он не показывает — прогоны смотрите на вкладке Executions.

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

Проверка вне Open WebUI. Отправьте POST на Chat URL с полями из README — chatInput и sessionId — и посмотрите, приходят ли потоковые чанки вида {«content»: «…»}. Так вы отделяете проблемы n8n от проблем функции: если чанки идут, воркфлоу и адрес рабочие, и дальше проверяем сторону Open WebUI.

Установка функции в Open WebUI

В Open WebUI перейдите в Workspace → Functions, нажмите + для добавления новой функции и вставьте код n8n_pipeline.py. README называет этот способ прямым и рекомендует его для продакшена. Альтернатива — remote import: вставьте n8n_pipeline_remote.py, и функция сама подтянет свежую версию из репозитория при перезапуске Open WebUI. Для этого серверу Open WebUI нужен доступ в интернет; надёжнее держать файл на своём сервере и указать его адрес в коде.

Дальше заполните valves. MODELS — обязательное поле: JSON-объект, где ключ — имя модели, значение — полный Chat URL. Пример из README:

{
  "GPT-4 Agent": "https://n8n.example.com/webhook/gpt4-agent/chat",
  "Claude Agent": "https://n8n.example.com/webhook/claude-agent/chat",
  "Research Assistant": "https://n8n.example.com/webhook/research-bot/chat"
}

Каждая запись появится отдельной моделью в селекторе Open WebUI. BEARER_TOKEN нужен, только если вебхук требует авторизацию; по умолчанию пустая строка. RESPONSE_FIELD задаёт имя поля ответа и по умолчанию равно output. SEND_CONVERSATION_HISTORY по умолчанию false, TIMEOUT берёт системное значение, SHOW_STATUS_MESSAGES включает отладочные сообщения.

Выбор модели и первое сообщение

После сохранения функции выберите её модель в селекторе чата и отправьте сообщение. Функция упакует запрос в payload с chatInput и sessionId, отправит его на Chat URL и вернёт поток чанков в интерфейс. Ответ появляется по мере генерации.

Если ответа нет, включите SHOW_STATUS_MESSAGES и посмотрите, что происходит. README советует проверить корректность адресов в MODELS, активность воркфлоу n8n, валидность JSON в MODELS и логи Open WebUI. Отдельно протестируйте вебхук напрямую через curl или Postman: так видно, на чьей стороне сбой.

Проверка на стороне Open WebUI: убедитесь, что функция сохранена без ошибок и её модель видна в селекторе. Если модель не появилась, дело в коде функции или в невалидном JSON внутри MODELS — README относит неверный формат JSON к типовым причинам сбоя.

Второй путь: Webhook и Respond to Webhook

Если вы строите собственный воркфлоу без AI Agent, используйте связку Webhook и Respond to Webhook. По документации n8n узел Webhook создаёт адрес, принимающий данные от внешних сервисов, и запускает воркфлоу. В его параметре Respond выберите Using ‘Respond to Webhook’ Node, тогда ответ формируется отдельным узлом.

В узле Respond to Webhook задайте параметр Respond With. Вариант First Incoming Item отвечает JSON первого входящего элемента, а параметр Put Response in Field задаёт имя поля, в котором лежит ответ. README функции называет полем по умолчанию output: верните JSON вида {«output»: «текст ответа»} — иначе функция не найдёт текст. Опция Enable Streaming в этом узле требует триггер в режиме Streaming.

Учтите поведение узла: Respond to Webhook срабатывает один раз по первому входящему элементу. Если воркфлоу завершится, не дойдя до этого узла, вернётся стандартное сообщение со статусом 200; ошибка до первого Respond to Webhook даёт статус 500.

Безопасность и диагностика

Pipe Functions исполняют произвольный Python-код на вашем сервере. Документация Open WebUI предупреждает: создание функций доступно только администраторам, устанавливать код следует из доверенных источников и просматривать его перед импортом, поскольку вредоносная функция способна получить доступ к файловой системе, вынести данные или скомпрометировать систему. Ставьте только проверенный код.

Таблица типовых сбоев:

Отдельно про сетевой доступ: localhost внутри контейнера Open WebUI указывает на сам контейнер. Хост с n8n по этому адресу недоступен. Указывайте адрес, по которому n8n действительно доступен из среды, где запущен Open WebUI.

Частые вопросы

Почему модель функции не появляется в селекторе чата?
Проверьте JSON в valves MODELS: ключ — имя модели, значение — полный адрес вебхука. Невалидный JSON ломает разбор конфигурации. Также убедитесь, что функция сохранена без ошибок в Workspace → Functions.

Ответ приходит целиком, хотя стриминг нужен по частям.
Проверьте два места: Response Mode у узла Chat должен стоять в Streaming, а у AI Agent должна быть включена опция Enable Streaming. Документация n8n связывает потоковую отдачу с узлами, поддерживающими стриминг.

Воркфлоу работает в редакторе, но не отвечает в чате.
Скорее всего, вы используете тестовый адрес, который живёт только при активном Listen for Test Event. Опубликуйте воркфлоу и возьмите рабочий адрес; прогоны смотрите на вкладке Executions.

Зачем нужен BEARER_TOKEN в valves?
Токен нужен, если ваш вебхук требует авторизацию. По умолчанию поле пустое. Заполняйте его, только когда вебхук настроен на проверку токена.

Можно ли обойтись без узла AI Agent?
Да, для собственного воркфлоу подойдёт связка Webhook и Respond to Webhook. В узле Webhook выберите Using ‘Respond to Webhook’ Node, а в ответе верните JSON с полем, указанным в RESPONSE_FIELD, по умолчанию output.