بروتوكول A2A: كيف توحّد Google معايير تنسيق أنظمة الذكاء الاصطناعي متعددة الوكلاء

كثيرًا ما تتعطل أنظمة الذكاء الاصطناعي متعددة الوكلاء، لا بسبب «غباء» النماذج، بل لغياب تنسيق (orchestration) سليم. ويمثّل بروتوكول A2A من Google وامتداده AGP محاولة لحل هذه المشكلة على مستوى المعيار القياسي، لا عبر حلول ترقيعية.

لماذا تتعطل الوكلاء

تبدو الأنظمة متعددة الوكلاء مغرية: وكيل يحلل البيانات، وآخر يكتب الشيفرة، وثالث يتحقق من النتائج، وكل ذلك بالتوازي وبكفاءة. لكن حين يتجاوز عدد الوكلاء اثنين أو ثلاثة، تبدأ الفوضى. ويصف المطورون الإخفاقات نفسها مرة تلو أخرى: يفقد الوكلاء سياق المهمة عند تمريرها فيما بينهم، وتدخل في حلقات تفاوض لا تنتهي، وتحرق ميزانية الرموز (tokens) دون نتيجة. أما المنسّق (orchestrator) فلا يعرف عند أي خطوة تعثّر النظام، ولا إن كان من المناسب التدخل.

يكمن أصل المشكلة لا في جودة نماذج LLM، بل في غياب البنية التحتية:

• لا يوجد معيار للإعلان عن قدرات الوكيل
• لا يوجد صيغة موحدة لتمرير المهام بين الوكلاء
• لا توجد آلية للإبلاغ عن حالة التنفيذ
• لا يوجد بروتوكول لمعالجة الأخطاء واستئناف المهام

وقد عالج كل فريق هذه المشكلة بطريقته، وأمضى أسابيع في «لصق» الوكلاء بدلًا من تطوير المنطق الفعلي.

كيف يعمل بروتوكول A2A

A2A (Agent-to-Agent) بروتوكول مفتوح من Google تدعمه Microsoft وIBM. هدفه توحيد معايير تفاعل الوكلاء على ثلاثة مستويات: الاكتشاف، والتواصل، وإدارة الحالة.

المفهوم المحوري هو Agent Card. ينشر كل وكيل بطاقة تصف قدراته: ما المهام التي يقبلها، وبأي صيغة، وما الذي يعيده. يقرأ المنسّق هذه البطاقات ويوجّه المهام دون ترميز ثابت (hardcode). وإذا تغيرت كفاءات الوكيل، حدّث بطاقته فيأخذ المنسّق ذلك في الحسبان فورًا.

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

«يرفع A2A عن كاهل المطورين مهمة ابتكار بروتوكول. وأصبح بإمكانهم الآن

التركيز على ما يفعله الوكلاء، لا على كيفية تواصلهم».

AGP: النظام بدل الفوضى

يعالج A2A مسألة التواصل، لكنه لا يتحكم في ترتيب التنفيذ. أما AGP (Agent Gateway Protocol) فيضيف طبقة الإدارة هذه تحديدًا: من يتحدث، ومتى، وبأي ترتيب.

يُدخل AGP جلسات مُدارة وطوابير رسائل. وهذا يزيل حالة التسابق (race condition)، أي الوضع الذي يحاول فيه وكيلان في الوقت نفسه تعديل مورد واحد أو الرد على طلب واحد. ومع AGP، يتعين على الوكيل أن يشير صراحةً إلى إتمام الجزء الخاص به قبل أن يسلّم المنسّق المهمة إلى الوكيل التالي.

يغطي A2A وAGP معًا دورة الحياة الكاملة للتفاعل متعدد الوكلاء: من اكتشاف الوكيل المطلوب حتى الإنهاء المنضبط بحالة نهائية يمكن التنبؤ بها. وبذلك تتحول الأنظمة الفوضوية متعددة الوكلاء إلى خطوط معالجة (pipelines) قابلة للإدارة.

ماذا يعني ذلك

تدمج Google وMicrosoft وIBM بروتوكول A2A بالفعل في منصاتها للذكاء الاصطناعي، وهو ما ينقل البروتوكول من خانة «التجريبي» إلى «معيار صناعي آخذ في التشكل». وبالنسبة للمطورين الذين يبنون أنظمة متعددة الوكلاء اليوم، فإن الإلمام بـA2A ليس سبقًا للزمن، بل هو «نظافة معمارية» أساسية. فمن الأفضل إرساء الأساس الصحيح الآن بدلًا من إعادة كتابة طبقة التنسيق بعد أن «تدخل الوكلاء في حلقة مفرغة وتحرق الميزانية» مرة أخرى.