إضافات وكلاء الذكاء الاصطناعي أصبحت قابلة للنقل.. فهل أصبحت جاهزة للمؤسسات؟

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

في 6 أغسطس 2026 أعلنت Google انضمامها إلى Amazon وCursor وMicrosoft وOpenAI وVercel ضمن المشرفين الأساسيين على معيار Agent Plugins 1.0. يقدّم المعيار صيغة مفتوحة ومحايدة تجاه المورّد لتجميع مهارات الوكيل وخوادم MCP والملفات الداعمة في حزمة قابلة للنقل بين العملاء المتوافقين.

هذه خطوة مهمة نحو قابلية التشغيل البيني، لكنها لا تعني أن أي إضافة متوافقة مع المعيار أصبحت موثوقة أو جاهزة للإنتاج. بالنسبة إلى فرق التقنية العربية، القيمة الحقيقية ستأتي من الجمع بين سهولة النقل وحوكمة الصلاحيات ودورة حياة واضحة للإضافة.

ما الذي يوحّده المعيار الجديد؟

الفكرة بسيطة عمداً: الإضافة مجلد يحتوي ملف تعريف باسم plugin.json. توضع المهارات والتعليمات والموارد في مسار ثابت تحت skills/، وتُعرَّف خوادم MCP في mcp.json، ويمكن لكل عميل إضافة قدراته الخاصة في مساحة أسماء مستقلة تتجاهلها المنصات الأخرى.

هذا التنظيم يحل مشكلة التغليف، لا مشكلة التشغيل كلها. فبدلاً من إنشاء نسخة لمنصة سطر الأوامر وأخرى لبيئة التطوير وثالثة للمنصة المؤسسية، تستطيع الفرق الاحتفاظ بنواة واحدة قابلة للنقل. كما يوضّح النص الرسمي لمعيار Agent Plugins 1.0 أماكن المكونات وطريقة اكتشافها، ويعزل تعطل خادم MCP عن المهارات الأخرى داخل الحزمة.

تشرح وثائق Microsoft Learn العربية أن MCP يتيح للوكيل الوصول إلى الموارد والأدوات والموجّهات المنشورة من خادم متصل. أما شرح IBM باللغة العربية فيصف البروتوكول كطبقة توحيد بين تطبيقات الذكاء الاصطناعي والخدمات الخارجية. ويأتي معيار الإضافات ليضع هذه الاتصالات والمهارات في حزمة يمكن نقلها بصورة أكثر اتساقاً.

لماذا يهم ذلك فرق المنطقة؟

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

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

الحزمة الصحيحة ليست بالضرورة حزمة آمنة

يصرّح المعيار بأنه لا يحدد آلية التثبيت أو التوزيع، ولا نموذج الصلاحيات، ولا متطلبات العزل، ولا إثبات المصدر، ولا سياسة الثقة. هذا الفصل منطقي لأن احتياجات بيئة تطوير محلية تختلف عن احتياجات بنك أو جهة حكومية أو منصة تتعامل مع بيانات شخصية.

لذلك فإن نجاح فحص plugin.json يثبت أن البنية سليمة فقط. ولا يثبت أن السكربت آمن، أو أن خادم MCP يحمي البيانات، أو أن التعليمات لا توسّع نطاق المهمة، أو أن الأداة تحتاج موافقة بشرية قبل تنفيذ إجراء مؤثر.

وتدعم البيانات هذا التحفظ. فقد درست ورقة بحثية قُدّمت في 28 يوليو 2026 ما مجموعه 1,723 تطبيقاً يستخدم MCP. وجدت الدراسة أن التسجيل وخيارات التفعيل والتعطيل شائعة، لكن 37.2% فقط من التطبيقات وضعت موافقة إلزامية توقف التنفيذ قبل استدعاء الأداة. أي إن وجود بروتوكول موحّد لا يضمن وحده وجود رقابة بشرية عند القرار الحساس.

نموذج حوكمة عملي قبل التوسع

1. سجل موحّد للإضافات

أنشئ قائمة معتمدة تتضمن اسم الإضافة ومالكها ومستودع المصدر والإصدار والبصمة الرقمية والترخيص وحالة المراجعة. ثبّت الإصدارات في الإنتاج، ولا تجعل التحديث إلى أحدث نسخة تلقائياً. أي إضافة لمهارة أو سكربت أو تبعية أو خادم جديد يجب أن تعيد فتح المراجعة.

2. مصفوفة صلاحيات بحسب البيئة

افصل بين قبول الحزمة ومنحها السلطة. قد تكون الإضافة مقبولة للاختبار بصلاحية قراءة، لكنها غير مقبولة لتعديل الإنتاج. اربط كل أداة بالبيانات التي تقرؤها والأفعال التي تنفذها والهوية التي تستخدمها. اجعل بيانات الاعتماد قصيرة العمر ومحددة بالمهمة، واطلب موافقة صريحة للحذف والدفع والنشر والتواصل الخارجي والوصول إلى البيانات الشخصية.

3. عزل التنفيذ والاتصالات

شغّل السكربتات وخوادم MCP المحلية في بيئة معزولة بصلاحيات ملفات وشبكة محدودة. اسمح بالوجهات المطلوبة فقط، ولا تخزن الأسرار الدائمة داخل الحزمة. سجّل تشغيل العمليات وطلبات الشبكة واستدعاءات الأدوات في نظام لا تستطيع الإضافة تعديله.

4. اختبار السلوك لا شكل الملفات فقط

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

5. الإيقاف والتراجع السريع

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

ما الذي ينبغي فعله هذا الأسبوع؟

• احصر: المهارات والسكربتات وخوادم MCP الموجودة حالياً في أدوات الفرق المختلفة.
• اختر: سير عمل منخفض المخاطر ومقتصراً على القراءة ليكون تجربة أولى.
• غلّف: مكونات التجربة وفق معيار Agent Plugins واختبرها على عميلين متوافقين.
• قِس: زمن التكامل، وانحراف الإعدادات، ونسب الفشل، ومدة المراجعة قبل التجربة وبعدها.
• احكم: من ينشر الإضافة ومن يعتمدها ومن يثبتها ومن يحدّثها ومن يوقفها.

رؤية قمرة تك

قابلية النقل ليست هدفاً تقنياً منفصلاً؛ إنها وسيلة لتقليل الازدواجية وتسريع تسليم المنتجات والحفاظ على حرية الاختيار. وهي مهمة خصوصاً للمؤسسات الخليجية التي تبني حلولها عبر أكثر من سحابة ومنصة ونموذج.

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