В последних версиях OpenWebUI появились Skills, и я решил сразу применить их на практике. Одной из задач стало валидация ссылок, которые чат-бот техподдержки возвращает в ответах: модель должна корректно формировать URL на документацию и не генерировать несуществующие эндпоинты.

Карта территории: три слоя архитектуры

В экосистеме OpenWebUI выделяют три уровня абстракции:

• System Prompt — инструкция для LLM;
• Skills — пост-обработка ответа;
• MCP Tools — выполнение кода во внешнем мире.

В этой статье разберём, чем они отличаются, как взаимодействуют и как на их основе построить надёжный пайплайн валидации URL. Весь приведённый код — из продакшена, с обработкой ошибок и логированием.

Уровень 1: System Prompt — «Должностная инструкция»

System Prompt — это текстовый контекст, который задаёт поведение модели до генерации ответа. Он использует естественный язык, а не код, и определяет правила: роль, тон, формат ответа, запрет на выдуманные данные.

В нашем случае он:

• определяет, как строить ссылки по бизнес-логике;
• запрещает генерировать код и несуществующие URL.

Чего он не может:

• проверить, существует ли ссылка;
• выполнить HTTP-запрос;
• знать о существовании инструмента url_fetch_mcp — для модели это «магия».

System Prompt — это должностная инструкция сотрудника. Он знает, как писать отчёт, но не может выйти в поле и проверить данные.

Уровень 2: Skills — «Редактор с лупой»

Skills в OpenWebUI — это декларативные скрипты в формате Markdown с YAML-метаданными. Они выполняются после генерации ответа и могут:

• анализировать текст;
• вызывать MCP Tools;
• модифицировать вывод.

Skills не привязаны к одной модели — их можно использовать совместно в разных моделях. Например, мы применяем url-validator-with-mcp в переводчиках, чтобы избежать «битых» ссылок.

Как работает наш Skill:

1. находит URL в ответе;
2. вызывает MCP Tool url_fetch_mcp для каждой ссылки;
3. применяет бизнес-правила: удаляет нерабочие ссылки, форматирует рабочие;
4. возвращает чистый ответ без технических комментариев.

Чего Skill не делает:

• не обучает модель строить ссылки — это задача System Prompt;
• не заменяет бизнес-логику;
• не работает автономно — требует подключённый MCP Tool.

Skill — это редактор, который проверяет черновик. Он не пишет за автора, но исправляет ошибки, удаляет нерабочие ссылки и приводит текст к стандарту.

Уровень 3: MCP Tools — «Курьер с прибором»

MCP Tools (Model Context Protocol) — это внешний исполняемый код (Python/Node.js), выполняющий реальные действия: API-запросы, проверка URL, работа с файлами.

В нашем случае используется специальный сервер mcpo (MCP over HTTP), на котором размещён инструмент check_url(). Это fastmcp-сервер на Python, который:

• выполняет HTTP-запрос по ссылке;
• возвращает структурированный результат: status_code, response_time_ms, error;
• обрабатывает таймауты, SSL-ошибки, редиректы.

Инструмент можно использовать не только в этом Skill, но и в других или напрямую в моделях.

Однако он не знает контекста диалога, не принимает решений «удалять или оставить ссылку» — это логика Skill. Он просто возвращает данные в JSON.

MCP Tool — это курьер с прибором учёта. Он не решает, куда ехать и что писать в отчёте. Он только измеряет: «Доставлено/не доставлено, время в пути, причина сбоя».

Полный цикл: от вопроса до ответа

Рассмотрим реальный сценарий.

Вход: пользователь спрашивает

«Как настроить сетевой интерфейс в панели Invapi?»

Шаг 1: Model + System Prompt

1. LLM получает вопрос и системный промт;
2. находит документ controlpanel@network_interface@ru.md;
3. преобразует имя в URL: https://hostkey.ru/documentation/controlpanel/network_interface/;
4. генерирует черновик:

«Откройте панель Invapi → 'Сеть' → 'Интерфейсы'. Подробнее: [Настройка сетевого интерфейса](https://hostkey.ru/documentation/controlpanel/network_interface/)»

Шаг 2: Skill (url-validator-with-mcp)

1. Skill получает ответ и находит ссылку;
2. вызывает url_fetch_mcp с этим URL;
3. получает ответ:

{"valid": true, "status_code": 200, "response_time_ms": 342}

1. проверяет формат (HTTPS, Markdown, не совпадает с вопросом);
2. возвращает ответ без изменений — всё валидно.

Шаг 3: А если ссылка не валидна?

1. MCP Tool возвращает:

{"valid": false, "error": "HTTP 404"}

1. Skill удаляет конструкцию [текст](ссылка);
2. возвращает:

«Откройте панель Invapi → 'Сеть' → 'Интерфейсы'. Точной инструкции не нашёл. Для помощи: [Техподдержка](https://hostkey.ru/customer-care/)»

Сравнение подходов

Сводная таблица по ключевым критериям:

Компонент	Когда выполняется	Язык реализации	Доступ к сети	Контекст диалога	Основная задача	Уровень абстракции	Сложность поддержки
System Prompt	До генерации ответа	Естественный язык	Нет (только через Tools)	Полный	Поведение, правила	Высокая	Низкая
Skill	После генерации	Markdown + логика	Через MCP Tools	Ответ модели	Пост-обработка, координация	Средняя	Средняя
MCP Tool	По вызову из Skill	Python/JS код	Да	Только параметры	Конкретное действие	Низкая	Высокая

Заключение

Создание надёжного ИИ-ассистента — это не только про «умную модель», но и про правильную архитектуру. Каждый компонент должен выполнять свою задачу:

• System Prompt — задаёт поведение и правила: «Знай, как надо»;
• Skill — отвечает за пост-обработку и координацию: «Проверь, что сделано»;
• MCP Tool — выполняет действия в реальном мире: «Сделай и доложи».

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

Автор: Александр Казанцев, руководитель отдела документации и контента

В последних версиях OpenWebUI появились Skils, и я решил сразу же их «пристроить» в дело. Одной из задач их применения виделась валидация ссылок, которые чат-бот техподдержки отдает в своем ответе: модель должна отвечать на вопросы по документации, строить корректные ссылки на статьи и не выдумывать несуществующие эндпоинты и URL.

AI-платформа

Готовые серверы с LLM и инструментами для ИИ и машинного обучения.Узнать больше

Казалось бы, простая задача — всего лишь нужно написать в системном промте: «Проверяй ссылки перед отправкой». Но модель не умеет делать HTTP-запросы. Она — текстогенератор, а не браузер. Поэтому встал вопрос:

«Как гарантировать, что сгенерированная ссылка действительно работает, а не ведёт на 404?»

В текущей экосистеме OpenWebUI мы имеем три уровня абстракции:

1. System Prompt— инструкция для LLM
2. Skills— пост-процессоры ответа
3. MCP Tools— исполняемый код для действий «в реальном мире»

В этой статье я подробно разберу, чем они отличаются, как взаимодействуют и как на их примере построить надёжный пайплайн валидации URL. Весь код — из продакшена, с обработкой ошибок и логированием.

Карта территории: три слоя архитектуры

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

Каждый слой решает свою задачу. Давайте разберём их по порядку.

Уровень 1: System Prompt — «Должностная инструкция»

System Prompt— это текстовый контекст, который «настраивает» поведение языковой модели до генерации ответа. Это не код, не конфигурация — это естественный язык, который модель интерпретирует как правила поведения. В нашем случае это правила для поиска информации в базе знаний, ее интерпретация, форматирование.

Кратко стартовый блок и блок формирования ссылок выглядят вот так:

Что делает System Prompt в данном случае:

• Задаёт роль, тон и тематику ответов;
• Обучает модель правильно формировать ссылки по бизнес-алгоритму;
• Запрещает нежелательные действия (код, выдуманные URL);

Чего он не делает:

• Не проверяет, существует ли ссылка на самом деле;
• Не делает сетевые запросы;
• Не знает о существовании инструментаurl_fetch_mcp— для модели это «магия».

System Prompt — это должностная инструкция сотрудника. Он знает, как надо писать отчёт, но не может выйти в поле и проверить данные.

Уровень 2: Skills — «Редактор с лупой»

Новый инструментарийSkillsв OpenWebUI — это декларативные скрипты (в формате Markdown с метаданными YAML), которые выполняются после генерации ответа моделью. Они могут:

• Парсить и анализировать текст ответа
• Вызывать внешние инструменты (MCP Tools)
• Модифицировать вывод перед отправкой пользователю

Если системный промт привязан к конкретной модели, то Skills могут вызываться и использоваться различными моделями совместно. Достаточно указать их при создании кастомной модели в Workspace. Мы реиспользуем этот Skills, например, в переводчиках, чтобы не было «битых» ссылок.

В нашем случае нам нужен валидатор ссылок, то есть Skillurl-validator-with-mcp.

Обратите внимание на секцию между ---. В ней вы описываете ваш Skills и задаете, какие Tools он должен использовать. Также не забудьте включить Skills в настройках группы для ваших пользователей.

Разберемся, как же работает наш Skill:

1. Он находит URL в сгенерированном ответе (выполняет его парсинг);
2. Вызывает MCP Toolsurl_fetch_mcpпередавая его последовательно найденные URL;
3. Применяет бизнес-правила: удалять битые ссылки, форматировать рабочие;
4. Возвращает «чистый» ответ без мета комментариев.

Чего не делает наш Skill:

• Не учит модель,какстроить ссылки (это задача системного промта);
• Не заменяет логику бизнес-правил;
• Не работает автономно и требует подключённого MCP Tool, так как сам он не может пройти по ссылке и проверить ответ от сервера.

Skill — это редактор, который проверяет черновик. Он не пишет за автора, но исправляет ошибки, удаляет нерабочие ссылки и приводит текст к стандарту.

Уровень 3: MCP Tools — «Курьер с прибором»

MCP (Model Context Protocol) Tools — это внешний исполняемый код (обычно Python/Node.js), который выполняет конкретные действия: запросы к API, проверка URL, работа с файлами. В OpenWebUI есть три механизма использования: встроенные инструменты, Toos и внешние MCP Tools.

В нашем случае у нас есть ужеспециальный серверmcpo(MCP over HTTP) от тех же разработчиков, на котором расположен инструментарий работы с Invapi, поэтому добавить туда еще один было не проблемой. Но никто не запрещает тот же код реализовать через внутренние Tools OpenWebUI.

По факту сам инструмент — это простой fastmcp-сервер и код на питоне, который и проверяет ссылки. mcpo же в данном случае — это «переводчик» между миром локальных CLI-инструментов (MCP) и миром веб-приложений (OpenWebUI).

Плюсом mcpo будет интерактивная документация в swagger-формате, доступная в /docs.

Наш MCP инструмент носит имяcheck_url()

Что наш валидатор делает:

• Реально «стучится» по ссылке (сетевой запрос);
• Возвращает структурированный результат:status_code,response_time_ms,error;
• Обрабатывает исключения: таймауты, SSL-ошибки, редиректы;

Также его можно использовать не только в нашем конкретном Skill, но и в других, а также напрямую в моделях.

Но так как это просто код на Python, то он не знает контекст диалога (кто пользователь, о чём вопрос), не принимает решений: «удалять ссылку или нет», так как это логика Skill, и не форматирует финальный ответ, а отдает только данные в json формате.

После этого остается только прописать наш MCP Tools в OpenWebUI.

MCP Tool — это курьер с прибором учета. Он не решает, куда ехать и что писать в отчёте. Он только измеряет: «Доставлено/не доставлено, время в пути, причина сбоя».

Полный цикл: от вопроса до ответа

Давайте проследим, как работает вся цепочка на реальном сценарии.

Вход: пользователь спрашивает

«Как настроить сетевой интерфейс в панели Invapi?»

Шаг 1: Model + System Prompt

1. LLM получает вопрос + системный промт;
2. Находит в базе документ:controlpanel@network_interface@ru.md;
3. Применяет алгоритм:"убрать @ru.md" → ["controlpanel","network_interface"] > "https://hostkey.ru/documentation/controlpanel/network_interface/" ;
4. Генерирует черновик:

"Откройте панель Invapi → 'Сеть' → 'Интерфейсы'.

Подробнее: [Настройка сетевого интерфейса]

(https://hostkey.ru/documentation/controlpanel/network_interface/)"

Шаг 2: Skill (url-validator-with-mcp)

1. Skill получает черновик;
2. Парсит текст, находит 1 ссылку;
3. Вызывает MCP Tool:

url_fetch_mcp(url="https://.../network_interface/")

1. Получает результат:

{ "valid": true, "status_code": 200, "response_time_ms": 342 }

1. Проверяет формат: Markdown - Да, HTTPS - Да, текст ≠ вопрос - Да ;
2. Возвращает ответ без изменений (всё валидно).

Шаг 3: А если ссылка не валидна?

1. MCP Tool вернул:

{ "valid": false, "error": "HTTP 404" }

1. Skill удаляет конструкцию "[текст](ссылка)" из ответа;
2. Выдает ответ без ссылки:

"Откройте панель Invapi → 'Сеть' → 'Интерфейсы'.

Точной инструкции не нашёл. Для помощи:

[Техподдержка](https://hostkey.ru/customer-care/)."

Сравнение подходов

Так что-же лучше? System Prompt, Skill или MCP Tools. Свели все основные критерии в такую таблиц, чтобы вы могли выбрать наиболее подходящий вам инструмент.

System Prompt

Когда выполняется

До генерации ответа

После генерации

По вызову из Skill

Язык реализации

Естественный язык

Markdown + логика

Python/JS код

Доступ к сети

Только через Tools

Контекст диалога

Ответ модели

Только параметры

Основная задача

Поведение, правила

Пост-обработка, координация

Конкретное действие

Высокая (текст)

Средняя (шаблон)

Низкая (код)

Сложность поддержки

Заключение

Разработка надёжного ИИ-ассистента — это не только про «умную модель». Это про архитектуру, где составляющие ее компоненты делают своё дело:

• System Prompt —  отвечает за поведение ассистента, правила, бизнес-логику, «Знай, как надо»;
• Skill — на нем пост-обработка и координация, «Проверь, что сделано»;
• MCP Tool — выполняет конкретные действия «в мире», «Сделай и доложи».

Когда каждый компонент знает свою зону ответственности, система становится предсказуемой, тестируемой и легко расширяемой. А пользователь получает то, что ему нужно: в нашем случае это точный ответ с рабочими ссылками.

Полезные ссылки

• Официальная документация OpenWebUI Skills
• Model Context Protocol Specification
• Документация по MCP и mcpo в OpenWebUI

AI-платформа

Готовые серверы с LLM и инструментами для ИИ и машинного обучения.Узнать больше