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

جرّب Apidog اليوم

في هذا الدليل ستتعرف على A2A عمليًا: ما هو، متى تحتاجه، كيف يعمل داخليًا، وكيف يختلف عن MCP. وإذا أردت اختبار وكيل A2A بعد ذلك، فراجع دليل Apidog A2A Debugger.

ما هو Agent2Agent (A2A)؟

Agent2Agent أو A2A هو بروتوكول مفتوح للتواصل بين وكلاء الذكاء الاصطناعي. يحدد البروتوكول:

• كيف يعلن الوكيل عن قدراته.
• كيف يكتشفه وكيل آخر.
• كيف يتبادل الوكيلان الرسائل والملفات.
• كيف تُدار حالة المهمة حتى اكتمالها.
• كيف تُعاد النتائج إلى المتصل.

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

فكر فيه كأنه HTTP لحركة مرور الوكلاء. كما يسمح HTTP للمتصفح بالتحدث إلى أي خادم ويب دون معرفة اللغة أو الإطار المستخدم في الخادم، يسمح A2A لوكيل مبني على LangGraph بالتحدث إلى وكيل مبني على CrewAI دون معرفة بنيته الداخلية. يتفق الطرفان على العقد الخارجي فقط.

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

المشكلة التي يحلها A2A

قبل A2A، كان ربط وكيلين يعني كتابة glue code مخصص لكل تكامل.

مثال عملي:

1. لديك وكيل رئيسي يدير سير العمل.
2. تحتاج إلى وكيل بحث يملكه فريق آخر.
3. تكتب عميل HTTP مخصصًا.
4. تتفقان يدويًا على شكل الطلب والاستجابة.
5. تضيفان آلية مصادقة مخصصة.
6. تعيدان تكرار نفس العمل مع كل وكيل جديد.

هذا الأسلوب لا يتوسع جيدًا، لأنه يسبب مشكلات متكررة:

• لا يوجد اكتشاف موحد: لا يستطيع الوكيل سؤال وكيل آخر بطريقة قياسية: "ماذا تستطيع أن تفعل؟"
• لا يوجد نموذج مهمة مشترك: وكيل يعيد نصًا عاديًا، وآخر يعيد JSON مخصصًا، وثالث يبث الرموز تدريجيًا.
• لا توجد مصادقة موحدة: كل تكامل يعيد اختراع الرؤوس وبيانات الاعتماد.
• لا توجد قابلية استبدال: لا يمكنك استبدال وكيل AutoGen بوكيل LangGraph بسهولة حتى لو كانا ينفذان نفس المهمة.

يعالج A2A هذه الفجوة بالطريقة نفسها التي حسّن بها OpenAPI تكاملات REST: عقد موحد يمكن لأي طرف متوافق الالتزام به.

كيف يعمل A2A؟

لفهم A2A عمليًا، ركز على أربعة مفاهيم أساسية:

1. بطاقة الوكيل.
2. المهام.
3. الرسائل والمخرجات.
4. البث والتحديثات.

بطاقة الوكيل Agent Card

بطاقة الوكيل هي مستند JSON ينشره الوكيل لتعريف نفسه. وهي نقطة البداية للاكتشاف.

تتضمن البطاقة عادةً:

• اسم الوكيل.
• الوصف.
• القدرات.
• المهارات المعلنة.
• أنواع المدخلات والمخرجات المدعومة.
• متطلبات المصادقة.
• إصدار البروتوكول.

عادةً تُنشر البطاقة في مسار معروف مثل:

https://your-agent.example.com/.well-known/agent.json

قبل إرسال أي مهمة، يجلب الوكيل المتصل هذه البطاقة ويقرأ ما يمكن للوكيل الآخر تنفيذه.

مثال مبسط لبطاقة وكيل:

{
  "name": "research-agent",
  "description": "وكيل متخصص في البحث وتجميع المصادر",
  "protocolVersion": "0.2.0",
  "skills": [
    {
      "id": "web-research",
      "name": "بحث الويب",
      "description": "يجمع مصادر ويب ويلخصها"
    }
  ],
  "capabilities": {
    "streaming": true
  },
  "authentication": {
    "schemes": ["bearer"]
  }
}

الفكرة ليست حفظ هذه الحقول، بل اعتماد نمط واضح: اكتشف قدرات الوكيل أولًا، ثم أرسل له العمل المناسب.

المهام Tasks

المهمة هي وحدة العمل الأساسية في A2A.

عندما يطلب وكيل من وكيل آخر تنفيذ شيء، يتحول الطلب إلى مهمة لها:

• معرّف.
• حالة.
• رسائل مرتبطة.
• نتائج أو مخرجات عند الانتهاء.

تمر المهمة بحالات مثل:

submitted
working
input-required
completed

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

الرسائل والمخرجات Messages and Artifacts

الرسالة تحمل المحتوى الفعلي بين الوكلاء. ويمكن أن تتكون من أجزاء متعددة، مثل:

• نص.
• ملف.
• بيانات منظمة.
• مزيج من الأنواع السابقة.

مثال منطقي لرسالة إلى وكيل بحث:

{
  "message": {
    "role": "user",
    "parts": [
      {
        "type": "text",
        "text": "ابحث عن أحدث المواصفات المفتوحة لبروتوكول A2A ولخصها."
      }
    ]
  }
}

عند انتهاء المهمة، يعيد الوكيل مخرجات تسمى artifacts. قد تكون:

• تقريرًا.
• مستندًا.
• جدول بيانات.
• ملخصًا.
• مرجع ملف.

تُبنى المخرجات أيضًا من أجزاء، لذلك يبقى شكل البيانات ثابتًا في الاتجاهين.

البث والتحديثات Streaming and Updates

ليست كل المهام قصيرة. قد يستغرق وكيل البحث أو التحليل أو توليد التقارير وقتًا.

يدعم A2A الأحداث المرسلة من الخادم Server-Sent Events، بحيث يمكن للوكيل إرسال تحديثات أثناء العمل، مثل:

submitted -> working -> found 3 sources -> generating summary -> completed

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

تدفق A2A عمليًا

التبادل النموذجي بين وكيلين يكون كالتالي:

1. يجلب الوكيل A بطاقة الوكيل B.
2. يقرأ المهارات والقدرات والمصادقة المطلوبة.
3. يرسل رسالة تنشئ مهمة.
4. يبدأ الوكيل B تنفيذ المهمة.
5. يرسل الوكيل B تحديثات حالة أو بثًا جزئيًا.
6. يعيد الوكيل B المخرجات عند الوصول إلى completed.
7. يستهلك الوكيل A النتيجة وينتقل إلى الخطوة التالية.

على مستوى النقل، المحادثة هي JSON عبر HTTP. لا تحتاج إلى نموذج اتصال غريب أو بنية خاصة.

مقارنة A2A و MCP

يحدث خلط كثير بين A2A و MCP لأن كليهما بروتوكولات مفتوحة مرتبطة بالوكلاء. لكنهما يحلان مشكلتين مختلفتين.

بصيغة أبسط:

• MCP يربط الوكيل بالأنظمة الخارجية.
• A2A يربط الوكيل بوكلاء آخرين.

في نظام إنتاج حقيقي، قد تستخدم الاثنين معًا. مثلًا:

1. وكيل رئيسي يستقبل طلب المستخدم.
2. يستخدم MCP للاستعلام عن قاعدة بيانات داخلية.
3. يستخدم A2A لتفويض مهمة تحليل إلى وكيل متخصص.
4. يجمع النتائج ويعيد الرد النهائي.

للتعمق أكثر في الفرق، راجع تفسير مقارنة خادم MCP و A2A، ولتجربة جانب MCP عمليًا راجع مصَحِّح عميل MCP الخاص بـ Apidog.

التعاون متعدد الوكلاء في الواقع

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

مثال مفتوح المصدر هو Codex-Claude-Collab. ينسق هذا المشروع سير عمل بين OpenAI Codex و Claude Code:

1. يخطط Codex للمهمة.
2. يفوض التنفيذ إلى Claude Code.
3. يراجع Codex الفروقات.
4. يتحقق من النتيجة قبل الرد على المستخدم.

هذا نمط تنسيق مبرمج مسبقًا hard-wired orchestration. أحد الطرفين يعرف بالضبط من سيستدعي وكيف.

أما A2A فيعمم الفكرة. بدل أن يعرف المتصل أنه سيستدعي وكيلًا محددًا بالاسم، يقرأ بطاقة الوكيل ويتعامل مع أي وكيل متوافق.

استخدم التنسيق المباشر عندما:

• تتحكم في الطرفين.
• تعرف الوكلاء مسبقًا.
• تريد سير عمل ثابتًا ومحكمًا.

استخدم A2A عندما:

• الوكلاء مستقلون.
• الفرق مختلفة.
• تحتاج إلى استبدال الوكلاء بدون إعادة كتابة التكامل.
• تريد عقدًا قياسيًا بين الوكلاء.

غالبًا ستستخدم الأنظمة الناضجة النمطين معًا: تنسيق مباشر داخل الفريق، و A2A عبر حدود الفرق أو المنتجات.

كيفية اختبار وكيل A2A

بعد بناء أو استخدام وكيل A2A، تحتاج إلى رؤية ما يحدث على السلك. سجلات Console وحدها لا تكفي غالبًا، لأنك تحتاج إلى فحص:

• بطاقة الوكيل.
• الطلبات الخام.
• الرؤوس.
• حالة المهمة.
• الرسائل.
• المخرجات.
• حمولة JSON-RPC الكاملة.

تتضمن Apidog مصحح A2A داخل العميل القياسي. سير العمل العملي يكون كالتالي:

1. الصق عنوان URL الخاص ببطاقة الوكيل.
2. اضغط Connect.
3. يقرأ Apidog البطاقة ويعرض اسم الوكيل وقدراته ومهاراته.
4. أرسل رسالة اختبار.
5. أرفق ملفات إذا كانت المهارة تحتاج ذلك.
6. أضف metadata عند الحاجة.
7. افحص الرد بثلاث طرق عرض:
   • معاينة قابلة للقراءة.
   • المحتوى الخام.
   • حمولة JSON-RPC الكاملة.

يدعم Apidog أيضًا رؤوس Bearer Token و Basic Auth و API-key بدون الحاجة إلى كتابة أوامر curl يدويًا.

القيمة الأساسية هنا هي العزل. عندما يفشل التكامل، تريد الإجابة بسرعة:

• هل المشكلة في النقل؟
• هل البطاقة غير صحيحة؟
• هل المصادقة مفقودة؟
• هل منطق الوكيل نفسه هو المشكلة؟

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

البدء مع A2A

إذا أردت بناء أو ربط وكيل A2A، استخدم هذا المسار المختصر:

1. اقرأ مواصفات A2A لفهم حقول بطاقة الوكيل ودورة حياة المهمة.
2. شغّل أحد الوكلاء النموذجيين المرجعيين محليًا.
3. افتح عنوان بطاقة الوكيل في المتصفح وتأكد من أنها JSON صالح.
4. استخدم مصحح A2A وأرسل رسالة اختبار بسيطة مثل: مرحبًا.
5. تحقق من أن المهمة تنتقل بين الحالات المتوقعة.
6. ابنِ وكيلك الخاص وانشر بطاقة وكيل صالحة.
7. اختبر المسار النصي أولًا.
8. أضف المصادقة.
9. أضف مرفقات الملفات.
10. أضف البث بعد أن يعمل المسار الأساسي.

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

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

للمزيد حول هذا الاتجاه، راجع وكلاء الذكاء الاصطناعي هم مستهلكو واجهات برمجة التطبيقات الجدد، وراجع أيضًا تصميم واجهات برمجة التطبيقات لوكلاء الذكاء الاصطناعي.

أسئلة شائعة

هل A2A من صنع جوجل؟

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

هل أحتاج إلى A2A إذا كان لدي وكيل واحد فقط؟

لا. A2A يحل مشكلة التواصل بين الوكلاء. إذا كان لديك وكيل واحد يحتاج إلى أدوات أو مصادر بيانات، فغالبًا تحتاج إلى MCP. تحتاج إلى A2A عندما يدخل وكيل ثانٍ إلى سير العمل.

ما أطر العمل التي تدعم A2A؟

A2A مستقل عن أطر العمل. يمكن لأي وكيل نشر بطاقة وكيل صالحة والتحدث بالبروتوكول أن يشارك. لذلك يمكن استخدامه مع LangGraph و CrewAI و AutoGen أو وكلاء مخصصين. الإطار الداخلي غير مهم للمتصل.

هل A2A هو نفسه MCP؟

لا. MCP يربط الوكيل بالأدوات ومصادر البيانات. A2A يربط الوكلاء ببعضهم. البروتوكولان مكملان، وكثير من الأنظمة يمكن أن تستخدمهما معًا.

كيف أصحح تكامل A2A؟

استخدم مصحح A2A مرئيًا مثل Apidog A2A Debugger. الصق عنوان بطاقة الوكيل، أرسل رسائل اختبار، ثم افحص الطلب والاستجابة الخام لتحديد هل الخطأ في النقل أم في منطق الوكيل.

هل يدعم A2A المهام طويلة الأمد؟

نعم. يحتوي نموذج المهام على حالات صريحة، ويدعم البروتوكول Server-Sent Events لبث النتائج الجزئية وتحديثات التقدم. لذلك لا تحتاج المهام الطويلة إلى حظر المتصل حتى تنتهي.