تمر بنية وكلاء الذكاء الاصطناعي اليوم بمرحلة تشبه إلى حد كبير ما شهدته الحوسبة الموزعة في العقود السابقة: تعدد سريع في البروتوكولات، ثم انحسار تدريجي نحو عدد محدود من المعايير التي تثبت عملياً أنها الأكثر بساطة وقابلية للتشغيل البيني. وإذا كان تاريخ الإنترنت قد شهد صعود CORBA وDCOM وRMI وSOAP قبل أن يتفوق REST، فإن مشهد الوكلاء الذكيين يسير على نمط مشابه، لكن بسرعة أكبر وبمخاطر أوضح على فرق الهندسة التي تبني أنظمتها الآن.
خلال الأشهر الثمانية عشر الماضية، ظهرت عدة بروتوكولات تحاول تنظيم طريقة عمل الوكلاء معاً. من بينها بروتوكول سياق النماذج MCP الذي طرحته Anthropic، وبروتوكول Agent Communication Protocol أو ACP من IBM Research، وبروتوكول Agent2Agent المعروف اختصاراً بـA2A من Google، إضافة إلى ANP الذي تعمل عليه مجموعة مستقلة. هذا الزخم ليس دليلاً على الفوضى بقدر ما هو علامة على أن السوق لا يزال يبحث عن الطبقات المناسبة لتقسيم المشكلة الكبيرة إلى أجزاء أصغر وأكثر قابلية للحل.
اللافت أن هذه البروتوكولات لا تتنافس جميعها على المهمة نفسها. كثير من الالتباس يأتي من تسويقها باعتبارها “معيار التواصل بين الوكلاء”، بينما الواقع أكثر تعقيداً. فهناك فرق بين أن يعرف النموذج كيف يستدعي أداة خارجية، وبين أن ينسق مهمة مع وكيل آخر، وبين أن يرسل رسالة خفيفة، وبين أن يكتشف جهة قادرة على تنفيذ خدمة محددة. كل طبقة من هذه الطبقات تعالج جزءاً مختلفاً من السلسلة.
ماذا يحل MCP وماذا لا يحل
يمكن النظر إلى MCP بوصفه واجهة قياسية لاستدعاء الأدوات. فهو يحدد كيف يكتشف النموذج الوظائف المتاحة على الخادم، وكيف يطلب تنفيذها، وكيف يتلقى النتيجة ويفسرها. بمعنى آخر، MCP ليس بروتوكولاً عاماً للتنسيق بين الوكلاء، بل عقد RPC منظم بين عميل ذكي وخادم أدوات. ومن الناحية العملية، يبدو أن هذه الطبقة قد استقرت بالفعل، مع انتشار واسع في الخوادم العامة والتنزيلات البرمجية الخاصة بها.
أهمية MCP تكمن في أنه يحول استدعاء الأداة من تكامل خاص ومفصل إلى عقد واضح يمكن إعادة استخدامه. وهذا يقلل من تكلفة الربط بين النماذج ومصادر البيانات أو الخدمات التشغيلية، سواء كانت قواعد بيانات أو أدوات تحليل أو أنظمة داخلية. لكن MCP، رغم نضجه، لا يجيب عن سؤال أكبر: ماذا يحدث عندما يحتاج وكيل إلى التحدث مع وكيل آخر بدل أن يستدعي أداة ثابتة؟
A2A يملأ فجوة تنسيق المهام
هنا يظهر دور A2A، الذي يركز على تنسيق المهام بين الوكلاء. إذا كان MCP يشرح كيفية استدعاء وظيفة، فإن A2A يشرح كيفية تفويض مهمة كاملة لوكيل آخر، وكيف تتغير حالة المهمة عبر مراحلها المختلفة، وكيف يمكن التعامل مع التفاعل المتزامن أو المتدفق أو غير المتزامن. لهذا السبب، تبنى كثير من فرق الذكاء الاصطناعي في المؤسسات هذا البروتوكول بوصفه طبقة طبيعية فوق MCP لا بديلاً عنه.
تسليم A2A إلى Linux Foundation في منتصف 2025 أشار إلى أن البروتوكول بدأ يخرج من نطاق التجربة إلى نطاق أوسع من التبني المؤسسي. والسبب بسيط: هناك احتياج حقيقي لآلية تسمح للوكيل الأول بأن يسلم مهمة لآخر يملك سياقاً أو خبرة مختلفة، مثل تحليل بيانات سوقية، أو مراجعة ملف قانوني، أو تشغيل سلسلة من الأدوات المتخصصة.
مع ذلك، فإن A2A لا يهدف إلى أن يكون طبقة نقل شبكي كاملة. إنه يحدد منطق التنسيق، لا كيفية الوصول الفيزيائي أو الشبكي المباشر بين الأطراف. وهذا التفريق بالغ الأهمية، لأن كثيراً من فرق التطوير تخلط بين بروتوكول المعنى وبروتوكول الاتصال.
ACP وANP ضمن طبقة أوسع
ACP يقدم نموذجاً أخف وزناً لتبادل الرسائل بين الوكلاء، من دون التعقيد الكامل لدورة حياة المهام في A2A. لذلك قد يكون مناسباً في البيئات التي يكفي فيها الإرسال البسيط أو التبادل القصير للمعلومات، خاصة عندما لا تكون هناك حاجة إلى إدارة حالات مهمة متعددة الخطوات.
أما ANP فيركّز على الاكتشاف والهوية. وهو يعتمد على معرّفات لا مركزية ووصف للقدرات عبر هياكل بيانات قابلة للربط، ما يجعله أقرب إلى قاعدة لبناء أسواق أو شبكات وكلاء لا تعتمد على سجل مركزي واحد. هذه الفكرة مهمة لأن مشكلة الوكلاء ليست فقط في التحدث، بل في العثور على الجهة المناسبة أصلاً.
من هنا، بدأ يتبلور تصور لطبقات متكاملة: الاكتشاف عبر ANP أو سجلات أبسط، تنسيق المهام عبر A2A، استدعاء الأدوات عبر MCP، والتبادل الخفيف عبر ACP عندما لا تكون هناك حاجة إلى دورة حياة كاملة للمهمة. بهذا المعنى، البروتوكولات الحالية ليست بالضرورة متنافسة؛ بل قد تكون أجزاء من بنية واحدة أكبر.
المعضلة المتبقية: النقل الشبكي
على الرغم من هذا التقدم، يبقى سؤال جوهري بلا حل ناضج: كيف تصل الوكلاء إلى بعضها مباشرة عبر الشبكات؟ معظم هذه البروتوكولات تعمل فوق HTTP، وهو خيار طبيعي لأن بيئات التطوير والخوادم السحابية اعتادت عليه. لكن HTTP يفترض عادةً وجود خادم يمكن الوصول إليه مباشرة، وهذه الفرضية تنهار في كثير من حالات الاستخدام الواقعية.
المشكلة تتضخم عندما تكون الأجهزة خلف NAT، وهو وضع شائع جداً في الشبكات الحديثة. في مثل هذه البيئة، لا يمكن للوكيل أن يكون نقطة استقبال مباشرة من دون طبقة وسيطة أو آلية عبور. وإذا كانت البنية تعتمد على relays في كل مرة، فإن ذلك يضيف تأخيراً وتكلفةً ونقطة فشل إضافية. وبالنسبة لأساطيل الوكلاء التي تحتاج إلى التواصل عبر حدود السحابة أو الشبكات المنزلية أو الحوسبة الطرفية، يصبح هذا القيد مؤثراً على التصميم منذ البداية.
الذي لم تحله MCP أو A2A أو ACP أو ANP هو ما يقع في طبقة الجلسة أو النقل الفعلي بين الأطراف. هذه طبقة مختلفة عن المعنى الذي يتبادله الوكلاء، وتتطلب أدوات مثل STUN لعبور NAT، وتقنيات تشفير ومصادقة على مستوى النفق، وبروتوكولات حديثة مثل QUIC أو حلول مخصصة مبنية فوق UDP لتقليل المشكلات المعروفة في TCP، ومنها head-of-line blocking.
المفارقة أن هذه الأدوات ليست جديدة على عالم الشبكات. فهي نفس العائلة التقنية التي تعتمد عليها بنى مثل WireGuard وWebRTC. الجديد فقط هو طريقة توظيفها في سياق الوكلاء، حيث لا يكفي أن يكون الاتصال آمناً وسريعاً؛ بل يجب أن يكون أيضاً قائماً على القدرات، أي أن يعرف النظام أي وكيل يصلح لأي مهمة، ثم يبني الاتصال المناسب إليه.
الاتجاه الأقرب خلال الفترة المقبلة
المسار المرجح خلال العام المقبل يبدو واضحاً نسبياً. من المتوقع أن تستمر طبقات MCP وA2A في النضج السريع، مع تحسينات أمنية ودعم أفضل للتوسعة الأفقية والتشغيل على نطاق أوسع. أما طبقة النقل، فستبقى في مرحلة التجريب والمقارنة بين تنفيذات مختلفة قبل أن تستقر السوق على عدد محدود من الحلول العملية.
الفرق الهندسية التي تبني أنظمة وكلاء اليوم أمامها خياران: إما التعامل مع طبقة النقل بوصفها مكوّناً مؤقتاً يمكن استبداله لاحقاً، أو تصميم الفصل بين المنطق التطبيقي والنقل منذ البداية. الخيار الثاني أكثر كلفة في البداية، لكنه غالباً أوفر على المدى البعيد، لأن إعادة بناء تلك الحدود بعد التوسع أصعب بكثير من تعريفها من اليوم الأول.
ومن هنا يمكن فهم المشهد الحالي بدقة: MCP حسم مشكلة استدعاء الأدوات، وA2A قدّم جواباً عملياً لتنسيق المهام، بينما لا يزال النقل المباشر بين الوكلاء هو الحلقة الأقل نضجاً في السلسلة. وعندما ينضج هذا الجزء، قد نشهد للمرة الأولى بنية وكلاء قادرة على التواصل والتنسيق والتوسع من دون الاعتماد الدائم على جسور وسيطة في كل خطوة.