OpenWebUI explique comment connecter System Prompt, Skills et MCP Tools pour la validation de liens

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

Три слоя логики Материал HOSTKEY посвящён не новой модели, а архитектуре вокруг неё.

Авторы берут типичную проблему техподдержки: ассистент отвечает по базе знаний, строит ссылки на документацию и должен не просто угадать нужный адрес, а подтвердить, что он реально открывается. Именно здесь и появляется разделение на три уровня. System Prompt задаёт поведение модели, объясняет формат ответов и даже учит собирать URL из внутренних имён документов, но не умеет сам ходить в сеть.

«System Prompt — это должностная инструкция сотрудника».

Дальше в цепочку добавляется Skill — слой постобработки, который получает уже готовый черновик ответа. Он умеет вытащить из текста ссылки, вызвать внешний инструмент, сверить результат с правилами и вернуть пользователю очищенную версию. Третий уровень — MCP Tool, то есть отдельный исполняемый код, который делает реальное действие: в этом кейсе отправляет HTTP-запрос и сообщает, рабочая ссылка или нет. System Prompt отвечает за роль, тон, ограничения и алгоритм построения ссылок. Skill разбирает ответ модели, координирует проверку и меняет итоговый текст. * MCP Tool выполняет сетевой запрос и возвращает структурированный результат: статус, время ответа, ошибку.

• Вместе эти слои дают предсказуемую схему вместо попытки решить всё одним промптом.

Как устроена проверка В статье разбирают живой сценарий: пользователь

спрашивает, как настроить сетевой интерфейс в панели Invapi. Модель с системным промптом находит нужный документ в базе, преобразует внутреннее имя файла в публичный адрес документации и вставляет ссылку в ответ. На этом этапе всё ещё выглядит правдоподобно, но это не гарантия, что страница существует и не ведёт на 404.

После генерации включается Skill url-validator-with-mcp. Он парсит ответ, находит URL и по очереди отправляет их в MCP-инструмент. Сам инструмент реализован как Python-сервис на fastmcp: сначала валидирует формат адреса, потом делает запрос HEAD, умеет следовать редиректам, проверяет SSL и обрабатывает таймауты.

В примере используется стандартный таймаут в пять секунд, а ответ возвращается в виде JSON с полями вроде status_code, response_time_ms, final_url и error. Если инструмент получает корректный ответ сервера, Skill оставляет ссылку в тексте и дополнительно проверяет форматирование. Если же проверка возвращает 404, SSL-ошибку или таймаут, Skill удаляет нерабочую ссылку целиком и не показывает пользователю технический мусор.

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

Почему это важно

Главная мысль статьи в том, что System Prompt, Skills и MCP Tools не конкурируют между собой. Они закрывают разные классы задач. Промпт знает контекст диалога и бизнес-правила, но не имеет прямого доступа к сети.

Skill видит готовый ответ и может организовать проверку, но сам по себе ничего не скачивает. MCP Tool умеет работать с внешним миром, зато не понимает, о чём был разговор с пользователем и как должен выглядеть финальный ответ. Для команд, которые строят прикладных ассистентов, это полезный паттерн.

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

Что это значит

Разбор HOSTKEY хорошо показывает, куда движется экосистема AI-инструментов: ценность всё чаще не в самой LLM, а в связке из правил, проверок и внешних действий. Если продукту нужна надёжность, одного «умного ответа» уже мало — нужен слой, который проверит результат в реальном мире до того, как его увидит пользователь.