ما هو Agent2Agent (A2A)؟ كيف يتواصل ويتعاون وكلاء الذكاء الاصطناعي

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

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

لماذا يحتاج الوكلاء إلى معيار للاتصالات

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

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

يقوم A2A بتوحيد طبقة الاتصالات مع السماح لكل وكيل بالبقاء كصندوق أسود. تُعرّف مواصفة A2A الحالية الكائنات الأساسية للبروتوكول والتفاعلات.

الأدوار الرئيسية في A2A

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

عادةً ما يتضمن تفاعل A2A دورين منطقيين:

• وكيل العميل: الوكيل أو التطبيق الذي يطلب العمل.
• الوكيل البعيد: الوكيل الذي يتلقى الطلب ويؤدي أو ينسق العمل.

كلمتا “العميل” و“البعيد” تصفان التفاعل الحالي، وليسا هرمية دائمة. يمكن لنفس الوكيل طلب العمل في سياق واحد وخدمة وكيل آخر في سياق مختلف.

بطاقات الوكيل: اكتشاف القدرات

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

يمكن لبطاقة الوكيل أن تصف اسم الوكيل، ونقطة النهاية، والميزات المدعومة للبروتوكول، وتوقعات المصادقة، والمهارات، وأنواع المحتوى المقبولة. المهارة هي مجال قدرة مُعلن، مثل ترجمة مستند، أو مراجعة عقد، أو بحث سوق.

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

الرسائل، المهام، والمخرجات

يمثل A2A التعاون من خلال عدة كائنات أساسية.

الرسائل

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

المهام

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

المخرجات

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

كيف يعمل تفاعل A2A

لنفترض أن وكيل تخطيط السفر يحتاج إلى متخصص للتحقق من متطلبات الدخول.

1. يكتشف العميل وكيلًا عن بُعد ويقرأ بطاقة الوكيل الخاصة به.
2. يتحقق من أن الوكيل يعلن عن القدرة ذات الصلة وطريقة تفاعل متوافقة.
3. يقوم العميل بالمصادقة ويرسل رسالة تصف المهمة والمسافرين والتواريخ والمخرجات المطلوبة.
4. يقوم الوكيل عن بُعد بإنشاء مهمة أو تحديثها ويبدأ العمل.
5. قد يبث الوكيل عن بُعد التقدم أو يطلب تفاصيل مفقودة.
6. يوفر العميل التوضيح مع الحفاظ على سياق المهمة.
7. يكمل الوكيل عن بُعد المهمة ويعيد قطعة منظمة تحتوي على نتيجته.
8. يقيم العميل تلك النتيجة قبل استخدامها في خطة السفر الأوسع.

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

A2A مقابل MCP

يمكن للبروتوكولات أن تتواجد في طبقات مختلفة من نفس البنية. قد يفوض وكيل تخطيط السفر مهمة بحث متخصصة في التأشيرات عبر A2A. ثم يمكن لهذا الوكيل المتخصص استخدام اتصالات MCP للبحث في قواعد البيانات المعتمدة واسترجاع وثائق السياسات. ينسق A2A المسؤولية بين الوكلاء؛ بينما يوحّد MCP الوصول بين مضيف الذكاء الاصطناعي والقدرات.

يحل كل من A2A وبروتوكول سياق النموذج مشكلات تكامل مختلفة.

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

يشبه الفرق استخدام أداة مقابل توظيف متخصص. تعرض الآلة الحاسبة عملية؛ بينما يقبل المحلل هدفًا ويقرر أي العمليات اللازمة. في الأنظمة الحقيقية، قد يستخدم وكيل A2A عن بُعد MCP داخليًا للوصول إلى أدواته وبياناته.

A2A مقابل واجهات برمجة التطبيقات العادية

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

لا يحل A2A محل كل واجهة برمجة تطبيقات. غالبًا ما يستدعي الوكلاء عن بُعد واجهات برمجة التطبيقات العادية لأداء عملهم، وقد تكشف المؤسسات عن خدمات حتمية مباشرة عندما لا تضيف حرية الوكيل قيمة.

لماذا تهم القابلية للتشغيل البيني

ستكون أنظمة الوكلاء متباينة. ستحسّن الفرق المختلفة تخصصاتها لمجالات ونماذج وحدود أمان وبيئات نشر مختلفة. يتيح بروتوكول مشترك للمنظمات الحفاظ على تلك التخصصات مع تمكين التعاون.

يمكن للتشغيل البيني أيضًا تقليل ربط التكامل. يمكن للعميل الاعتماد على مهارة مُعلنة وسلوك بروتوكول بدلاً من استيراد إطار عمل الوكيل البعيد أو تكرار منطقها الداخلي. يصف نظرة مشروع A2A هذا الهدف بأنه تمكين الوكلاء المبنيين على أُطر مختلفة من التواصل كأقران؛ وتُظهر تحديثات المشروع لعام 2026 بشأن الانضمام إلى Agentic AI Foundation الدفع نحو حوكمة محايدة وعابرة للصناعات.

تحديات الأمن والثقة

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

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

تحتاج النشرات القوية إلى ضوابط على عدة طبقات:

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

توافق البروتوكول لا يعني الثقة التنظيمية. قد يتحدث الوكيل بروتوكول A2A بشكل صحيح لكنه لا يزال غير مناسب لمهمة معينة.

متى ينبغي للفرق استخدام A2A؟

يكون A2A أكثر إقناعًا عندما تحتاج الوكلاء المستقلون إلى التعاون عبر حدود المنتج أو البائع أو المنظمة؛ عندما تكون المهمة طويلة الأمد؛ أو عندما يجب على النظام المستلم الاحتفاظ بالحرية في كيفية إنتاج النتيجة.

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

ما يجب تذكره حول ما هو Agent2Agent (A2A)

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

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