صراع وكلاء الذكاء الاصطناعي: هل يتفوق ADK من جوجل على بروتوكول MCP؟

مقدمة تحليلية

في الثلاثين من أبريل، أطلقت جوجل قنبلة تقنية جديدة بإعلانها عن برنامج GEAR، وهو المظلة التي تحتضن ADK أو (Agent Development Kit). هذا الإطلاق لم يكن مجرد إضافة عابرة لمكتبة أدوات المطورين، بل هو اعتراف صريح بأن المستقبل لا يكمن في 'الدردشة' مع الذكاء الاصطناعي، بل في تحويله إلى 'وكيل' (Agent) قادر على تنفيذ مهام برمجية وهندسية معقدة في العالم الحقيقي. يأتي هذا في وقت بدأ فيه المطورون بالفعل في تبني بروتوكول MCP (Model Context Protocol) الذي تروج له Anthropic، مما يضعنا أمام مواجهة تقنية كبرى بين مدرستين: مدرسة إطارات العمل الشاملة (ADK) ومدرسة البروتوكولات المرنة المفتوحة (MCP).

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

التحليل التقني

يعتمد كلا النظامين على فلسفة 'استدعاء الأدوات' (Tool Calling). في MCP، يتم التعامل مع الأمر كبروتوكول اتصال بين خادم وعميل. يقوم المطور بإنشاء خادم MCP (باستخدام TypeScript أو Python، أو كما في حالتنا .NET عبر مكتبات مجتمعية)، حيث يتم تعريف 'الأدوات' كمصفوفة من الوظائف البرمجية. كل أداة تحتوي على:

• اسم الأداة: مثل ScaleDeployment.
• الوصف: شرح نصي دقيق يقرأه النموذج اللغوي (LLM) ليقرر اختيارها.
• مخطط المدخلات (Schema): تعريف دقيق للمتغيرات المطلوبة (مثل اسم الـ Namespace وعدد النسخ Replicas).

أما ADK من جوجل، فهو يتجاوز كونه بروتوكولاً ليصبح إطار عمل متكاملاً (Framework). يدعم ADK لغات مثل Java وGo وTypeScript وPython بشكل رسمي. الميزة التقنية الفارقة في ADK هي دعمه الأصلي للأنظمة متعددة الوكلاء (Multi-agent systems)، حيث يمكن لعميل واحد أن يدير مجموعة من الوكلاء المتخصصين، ويوزع المهام بينهم بناءً على تخصص كل وكيل.

في تجربة بناء مدير Kubernetes باستخدام .NET، يبرز التحدي في 'وصف الأداة'. اكتشفنا تقنياً أن النموذج اللغوي (مثل Claude 3.5 Sonnet) قد يخلط بين أداة 'إعادة التشغيل' وأداة 'تغيير الحجم' (Scaling) إذا لم تكن الأوصاف دقيقة للغاية. في .NET، تم استخدام Attributes لتمرير هذه الأوصاف مباشرة إلى خادم MCP، مما يجعل الكود هو 'كتيب التعليمات' للذكاء الاصطناعي.

السياق وتأثير السوق

تاريخياً، كانت جوجل تسيطر على البنية التحتية للسحاب عبر Google Cloud، وإطلاق ADK هو محاولة لإحكام القبضة على سوق الوكلاء عبر دمجهم مباشرة في بيئة Vertex AI. في المقابل، يمثل MCP حركة 'التحرر من المنصة'، حيث يمكن تشغيل خادم MCP واحد ليعمل مع Claude Desktop أو Cursor أو أي عميل يدعم البروتوكول. هذا التنوع يخلق سوقاً ثنائية القطب:

• سوق المؤسسات (Enterprise): التي قد تميل لـ ADK بسبب ميزات المراقبة (Observability) المدمجة، والواجهة الرسومية (Dev UI) التي تسمح برؤية 'تسلسل أفكار' العميل (Chain of Thought).
• سوق المطورين الأفراد والأدوات المرنة: التي تفضل MCP لخفته وسهولة دمجه في سير العمل المحلي دون الحاجة للارتباط بسحابة معينة.

الأرقام تشير إلى نمو هائل في مستودعات GitHub التي تدعم MCP، خاصة مع ظهور مكتبات لـ .NET و Rust، مما يعوض نقص الدعم الرسمي من Anthropic لهذه اللغات حالياً. جوجل من جهتها تراهن على لغات المؤسسات مثل Java لضمان اختراق القطاعات المالية والتقنية الكبرى.

رؤية Glitch4Techs

من منظور نقدي، نرى في Glitch4Techs أن الوهم الأكبر الذي قد يقع فيه المطورون هو الاعتقاد بأن هذه الأدوات ستعمل بـ 'سحر' محض. الواقع التقني يثبت أن جودة الوكيل تعتمد بنسبة 80% على جودة 'الأوصاف' (Descriptions) وليس على جودة الكود نفسه. نحن ننتقل من عصر 'هندسة الأوامر' (Prompt Engineering) إلى عصر 'هندسة واجهات الوكلاء' (Agent Interface Engineering).

هناك مخاوف أمنية حقيقية؛ فمنح وكيل ذكاء اصطناعي صلاحيات للتحكم في عنقود Kubernetes (مثل حذف الـ Pods أو تغيير الإعدادات) هو مغامرة محفوفة بالمخاطر إذا لم تكن هناك طبقة تحكم بشرية (Human-in-the-loop). بينما يوفر ADK ميزات للتدقيق، يبقى MCP مسؤولية المطور بالكامل. نصيحتنا للمطورين: ابدأ بـ MCP لاستكشاف الإمكانيات محلياً، ولكن لا تنتقل إلى ADK إلا إذا كنت تحتاج حقاً إلى أوركسترا من الوكلاء المتعددين وإدارة الجلسات المعقدة في بيئة إنتاجية صارمة.