OpenWebUI: كيف تربط System Prompt وSkills وMCP Tools للتحقق من الروابط

أوضحت تجربة عملية في منظومة OpenWebUI لماذا لا يكفي موجّه نظام واحد (System Prompt) لبناء مساعد ذكاء اصطناعي موثوق. وعلى مثال بوت دعم فني، شرح المؤلفون كيف تُوزَّع الأدوار بين النموذج ومرحلة المعالجة اللاحقة وأداة خارجية، حتى لا يعيد البوت إلى المستخدم عناوين 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) مع نماذج مختلفة، وربط الأداة الخارجية لا بهذا السيناريو وحده بل بمسارات معالجة أخرى. ويؤكد المقال تحديدًا أن Skill نفسه يُستخدم فعلًا في المترجمات أيضًا، كي لا تظهر روابط معطوبة في المخرجات.

وهذا يجعل البنية عملية في بيئة الإنتاج، لا مجرد مخطط أنيق: يصبح اختبار الطبقات كلًا على حدة أسهل، وكذلك تسجيل الأخطاء، وتغيير مكوّن بعينه دون إعادة كتابة المساعد بأكمله.

ما معنى ذلك

يبيّن تحليل HOSTKEY بوضوح الاتجاه الذي تسير نحوه منظومة أدوات الذكاء الاصطناعي: لم تعد القيمة تكمن في نموذج LLM نفسه بقدر ما تكمن في الجمع بين القواعد وعمليات التحقق والإجراءات الخارجية. وإذا احتاج المنتج إلى الموثوقية، فلم تعد «الإجابة الذكية» وحدها كافية، بل يلزم طبقة تتحقق من النتيجة في العالم الحقيقي قبل أن يراها المستخدم.