OpenAI وشركات التكنولوجيا الكبرى توحد تنسيق إضافيات وكلاء الذكاء الاصطناعي

في 6 أغسطس 2026، أطلقت OpenAI وMicrosoft وAmazon وCursor وVercel معًا Agent Plugins 1.0.0، في محاولة لإنشاء تنسيق موحد للإضافات عبر المنتجات لـ AI Agents. يمكن للمطورين وضع مهارات Agent المكونة من تعليمات التشغيل والنصوص والمراجع، جنبًا إلى جنب مع خوادم MCP المتصلة بقواعد البيانات وخدمات السحابة وأدوات التطوير، في نفس الدليل؛ نظريًا، يكفي تغليفها مرة واحدة فقط لاستخدامها في العملاء المتوافقة مثل ChatGPT وCodex وVS Code وCursor وGitHub Copilot وKiro. إنها لا تهدف إلى حل مشكلات قدرات النموذج، بل إلى معالجة تجزئة التنسيقات التي تظهر في بيئة Agent: حاليًا، غالبًا ما يتطلب تنفيذ ميزة واحدة كتابة ملفات قائمة منفصلة، وتعديل هياكل المجلدات، والحفاظ على فروع متعددة. ومع ذلك، لا يزال معيار الإصدار 1.0.0 مصنفًا كـ "مسودة عمل"، وهو حاليًا يوحد طريقة التغليف فقط، دون تحديد متجر إضافات أو بروتوكولات تثبيت أو نماذج صلاحيات أو عزل في بيئة معزولة أو التحقق من المصدر. وبالتالي، فهو أكثر شبهاً بـ "تنسيق الحزمة" لبيئة Agent، وليس متجر تطبيقات ناضج يمكن من خلاله تثبيت أي إضافة بثقة.

مؤلف المقال والمصدر: جوناثان هيفنر، عضو فريق Vercel التقني

على مدار العام الماضي، شكلت بيئة وكلاء الذكاء الاصطناعي نوعين من القدرات التوسعية المهمة.

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

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

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

ما يجب أن توفره إضافات الوكيل هي هذه القدرات داخل علبة عامة خارجية. دورها أقرب إلىpackage.jsonفي بيئة JavaScript أو تنسيق OCI في مجال الحاويات: فهي لا تستبدل الكود والبروتوكولات داخلها، بل تصف بشكل موحد كيف يجب تنظيم هذه الأشياء واكتشافها وتحميلها.

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

إذا كان المكون يحتوي على مهارات، فتُوضع جميعها فيskills/الدليل، وكل مهارة لها ملفSKILL.mdخاص بها، ويمكن أن تأتي مع نصوص برمجية وملفات مرجعية وموارد أخرى. إذا احتاج المكون إلى الاتصال بأدوات خارجية، فضعmcp.jsonفي الدليل الجذري، وحدد خادمًا واحدًا أو أكثر من خوادم MCP.

يُدعم حاليًا ثلاثة أنماط اتصال لجزء MCP: stdio الذي يُشغل العملية محليًا، وStreamable HTTP المُوصى به حاليًا، وHTTP+SSE المُحتفظ به للتوافق مع الأنظمة القديمة. لا يلزم أن تدعم جميع العميلة جميع طرق النقل، لكن يجب أن تدعم على الأقل واحدة من stdio أو Streamable HTTP.

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

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

قائمة التوافق الرسمية الحالية تشمل VS Code وCursor وGitHub Copilot وChatGPT وCodex، بالإضافة إلى Kiro من أمازون. أطلقت Vercel الاقتراح الأولي للمعيار، ثم أسست AWS وAnysphere الشركة الأم لـ Cursor وMicrosoft وOpenAI وVercel لجنة إرشادية تقنية أولية؛ كما شارك GitHub في تحسين المعيار.

أعلنت Google في يوم الإصدار عن انضمامها إلى أعمال الصيانة الأساسية وبدء دعم هذا التنسيق في المنتجات ذات الصلة. تخطط Google لاعتماد مكونات الوكلاء في Agents CLI وData Agent Kit، مما يمكّن المطورين من دمج قدرات البيانات مثل BigQuery وSpanner وCloud SQL في مكونات قابلة للنقل.

تستحق هذه المجموعة من المشاركين الاهتمام، لأنها ليست في نفس المعسكر من حيث النماذج والمنتجات. تمتلك مايكروسوفت VS Code وGitHub Copilot وعلاقتها وثيقة بـ OpenAI؛ بينما يُعد Cursor أداة برمجة AI مستقلة؛ تمتلك AWS Kiro وتتنافس في سوق السحابة مع مايكروسوفت وGoogle؛ وترغب Vercel في أن تصبح منصة لنشر تطبيقات الذكاء الاصطناعي. رغبتهم في التعاون لوضع معايير تغليف تشير إلى أن تجزئة الإضافات بدأت تزيد من تكاليف الصيانة على جميع الشركات.

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

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

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

规范虽然要求插件内的文件路径不能通过../或符号链接逃离插件根目录，但官方特别说明：这种路径约束不等于对插件进程进行沙箱隔离。一个通过stdio启动的MCP服务器仍然可能执行程序；它究竟可以访问哪些文件、环境变量、网络和用户数据，要由客户端的权限体系决定。

يجب استخدام HTTPS لموقع MCP البعيد وفقًا للمبدأ، ولا يجوز للإضافات كتابة كلمات المرور أو الأسرار الأخرى مباشرة في رؤوس الطلبات أو إعدادات البيئة العامة. ومع ذلك، لا توفر الإصدار 1.0.0 تكوين OAuth عام أو آلية مرجعية قابلة للنقل للبيانات الائتمانية، ولا يزال التعامل مع اكتشاف المصادقة، وتسجيل الدخول للمستخدم، وحفظ البيانات الائتمانية مسؤولية العميل.

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

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

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

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

إذا حصل المعيار على دعم كافٍ من العملاء، فلا يحتاج المطورون إلى إعادة بناء جميع المهارات واتصالات الأدوات عند تغيير الفريق من Cursor إلى VS Code، أو من Codex إلى عامل آخر. يمكن لقدرات العامل التي تراكمت على المدى الطويل من قبل الأفراد أو الشركات أن تنتقل مع المستخدم، مما يجعل النماذج الأساسية والعملاء أسهل في الاستبدال.

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

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

بالإضافة إلى ذلك، تم دفع MCP في الأصل من قبل Anthropic، لكن Anthropic لا تظهر حاليًا في قائمة المُحافظين الأساسيين الأوليين أو العملاء الرسميين الأوليين المتوافقين المُعلنة في Agent Plugins. هذا لا يعني أن Claude لن تدعم هذا التنسيق في المستقبل، لكنه يشير إلى أن معيار التغليف الجديد لم يشمل جميع الكتل الرئيسية للعملاء.

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

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

يجب ملاحظة أنصفحة المواصفات الرسميةعلى الرغم من أنها تُشير إلى الإصدار 1.0.0، إلا أن حالتها لا تزال "مسودة قيد العمل"، وقد تُعدّل التفاصيل لاحقًا. حاليًا، الدعم يأتي بشكل رئيسي من الشركات المشاركة في وضع المعيار، ولا يزال غير مثبت كقبول واسع من قبل نظام Agent.