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

أظهرت نظام OpenWebUI في الممارسة العملية لماذا الموجه النظامي الواحد ليس كافياً لمساعد ذكاء اصطناعي موثوق. باستخدام روبوت دعم تقني كمثال، شرح المؤلفون كيفية تقسيم الأدوار بين النموذج والمعالجة اللاحقة والأدوات الخارجية حتى لا يسلم الروبوت للمستخدمين عناوين 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 جيداً إلى أين يتجه نظام أدوات الذكاء الاصطناعي: القيمة لا تكمن بشكل متزايد في LLM نفسها، بل في مزيج من القواعد والفحوصات والإجراءات الخارجية. إذا احتاج المنتج إلى موثوقية، فإن "الإجابة الذكية" الواحدة لم تعد كافية — تحتاج إلى طبقة تتحقق من النتيجة في العالم الحقيقي قبل أن يراها المستخدم.