جدول المحتويات
بعد أن أصبح وكلاء الذكاء الاصطناعي أمرًا شائعًا، انتقل التحدي التالي إلى «كيف نجعل الوكلاء يتعاونون فيما بينهم». إذا كان MCP هو المعيار الذي يربط الوكيل بـ«أدواته»، فإن A2A (Agent2Agent) هو المعيار الذي يربط الوكيل بـ«وكيل آخر». فهو يتيح لأنظمة الذكاء الاصطناعي المبنية على مزوّدين وأُطر عمل مختلفة أن تتحدث وتتعاون من خلال اصطلاح مشترك.
تشرح هذه المقالة، للمبتدئين، ما هو A2A، ولماذا نحتاجه، وكيف يختلف عن MCP، وكيف تعمل بطاقات الوكيل (Agent Card) والمهام (Task)، إضافة إلى وضعه الحالي وكيفية تطبيقه.
MCP عمودي (الأدوات)، وA2A أفقي (الأنداد)
— أنظمة الذكاء الاصطناعي تتحدث وتتعاون عبر اصطلاح مشترك
MCP = اتصال عمودي
يربط وكيلًا واحدًا بالأدوات والبيانات.
A2A = تنسيق أفقي
يربط الوكلاء ببعضهم ويفوّض العمل بينهم.
1. ما هو A2A؟
A2A (Agent2Agent) هو معيار مفتوح (بروتوكول) يتيح لوكلاء الذكاء الاصطناعي اكتشاف بعضهم والتواصل والتعاون فيما بينهم بصرف النظر عن أُطر العمل التي بُنوا عليها. أطلقته Google في أبريل 2025، ثم تبرّعت به لمؤسسة Linux Foundation في يونيو من العام نفسه، ووصل إلى الإصدار v1.0 في عام 2026. ويجري تشكيله ليكون «لغة مشتركة» غير مرتبطة بأي شركة بعينها.
تخيّله بوصفه «آداب الشراكة التجارية بين الشركات». إذا كان MCP هو موظفوك يستخدمون الأدوات، فإن A2A هو كتاب القواعد المشترك لـطلب مهمة من شركة أخرى (ذكاء اصطناعي آخر) واستلام النتيجة. فأيًّا كان ما بُني به الطرف الآخر، يمكنك تبادل «أرجو القيام بهذا» و«تم» عبر إجراء ثابت.
💡 في سطر واحد: A2A = «بروتوكول محادثة مشترك بين وكلاء الذكاء الاصطناعي». فحيث يتولّى MCP «الاتصال بالأدوات»، يتولّى A2A «التنسيق مع الأنداد».
2. لماذا نحتاجه: عصر تعاون الوكلاء
في عام 2026، يتّجه الذكاء الاصطناعي نحو نموذج يتم فيه، بدلًا من أن يقوم وكيل واحد بكل شيء، أن يتقاسم العمل ويتعاون عدّة وكلاء لكلٍّ منهم تخصّصه. فعلى سبيل المثال، يُعالَج طلب مثل «رتّب لي رحلة» على هيئة تتابع: وكيل تخطيط ← وكيل حجز فنادق ← وكيل دفع.
لكن عندما يكون كل وكيل مبنيًّا بمزوّد وتقنية مختلفين، يتطلب ربطها عملًا مخصّصًا في كل مرة. وهنا يأتي دور بروتوكول مشترك — A2A. فما دام الجميع يتّبع الاصطلاح المشترك، يمكنك تحويل أنظمة الوكلاء المتعدّدين إلى «أجزاء يمكنك تركيبها معًا». وهو التحوّل ذاته الذي جعل MCP المعيار المشترك لاتصالات الأدوات.
3. كيف يختلف عن MCP (عمودي مقابل أفقي)
A2A وMCP ليسا متنافسين — بل لهما أدوار مختلفة، وكثيرًا ما يُشرحان بعبارة «عمودي مقابل أفقي». والجمع بينهما هو الإعداد القياسي لعام 2026.
الوكيل ↔ الأدوات
يربط وكيلًا واحدًا بـالأدوات والبيانات — قاعدة بيانات، أو واجهة برمجة تطبيقات (API)، أو ملفات. اتصال «يضيف قدرة».
الوكيل ↔ الوكيل
يربط الوكلاء ببعضهم ويفوّض العمل ذهابًا وإيابًا. تنسيق «يتعاون مع الأنداد».
القاعدة المساعدة على التذكّر بسيطة: «الاتصال بالأدوات = MCP؛ الاتصال بالأنداد = A2A». في نظام حقيقي، يحتفظ كل وكيل بأدواته الخاصة عبر MCP بينما ينسّق مع الوكلاء الآخرين عبر A2A — وهذا الإعداد ذو الطبقتين MCP عمودي إضافةً إلى A2A أفقي أصبح المسار الافتراضي لتشغيل وكلاء المؤسسات.
4. كيف يعمل: بطاقات الوكيل (Agent Card) والمهام (Task)
جوهر A2A هو «بطاقة الوكيل» (Agent Card). وهي ملف JSON يشبه «بطاقة العمل» ينشره كل وكيل، يذكر فيه «ما الذي يمكنني فعله»، و«أين تتحدث إليّ»، و«كيف تعمل المصادقة». بل إن موقعها ثابت عند /.well-known/agent-card.json.
الاكتشاف (Agent Card)
اقرأ بطاقة الوكيل الآخر وافهم «ما الذي يستطيع فعله».
الطلب (Task)
أرسِل «مهمة» (Task). وهي تحمل حالات — working وinput-required وcompleted.
النتيجة (Artifact)
استلِم المُخرَج. والمهام الطويلة يمكنها بثّ التقدّم أيضًا.
يُبنى الاتصال على تقنيات واسعة الاستخدام — HTTP وServer-Sent Events (SSE) وJSON-RPC 2.0. والنقطة الأساسية هي أن الوكلاء لا يكشفون عن دواخلهم لبعضهم. فكل وكيل يُبقي محتوياته (الأدوات التي يستخدمها، واستدلاله) خفيّة، ولا يتبادل سوى المهام والنتائج. ولهذا يمكنهم التعاون بأمان حتى عبر الشركات.
⚠️ الأمان يبقى ضرورة: تعاون الوكلاء مريح، لكنك تحتاج إلى تصميم لا يفرط في الثقة بالوكلاء الخارجيين. اجمعه مع الحواجز الوقائية وإدارة الصلاحيات.
5. وضعه الحالي والتطبيق
ينتشر A2A بسرعة. ووفقًا لإعلان Linux Foundation (حتى أبريل 2026)، تستخدمه أكثر من 150 مؤسسة في بيئة الإنتاج، وله 22,000+ نجمة على GitHub، وتتوفّر حِزم تطوير برمجيات (SDK) بخمس لغات (Python وJavaScript وJava وGo و.NET). وتشارك فيه كبرى الشركات مثل Microsoft وSalesforce وSAP وServiceNow، مما يرسّخ مكانته معيارًا في الصناعة.
أما على صعيد التطبيق، فإن حِزم التطوير الخاصة بكل لغة تجعل من السهل نسبيًّا بناء كلٍّ من «الطرف الذي ينشر بطاقة وكيل (الخادم)» و«الطرف الذي يفوّض إلى وكلاء آخرين (العميل)». والترتيب المُوصى به هو أن تبني أولًا وكيلًا واحدًا، ثم — حين تطمئن — تجعله ينسّق مع غيره عبر A2A. وكما هو الحال مع المهارات (Skills) وMCP، فإن الأساس هو فكرة «تحويل الأشياء إلى مكوّنات عبر صيغة مشتركة».
※ الأرقام والمواصفات مقتبسة من إفصاحات متنوعة (حتى يونيو 2026). والبروتوكول في تطوّر مستمر؛ راجِع Linux Foundation / المواصفات الرسمية للاطلاع على الأحدث.
الخلاصة
ثلاث نقاط أساسية حول A2A.
- ما هو: معيار مفتوح يتيح لوكلاء الذكاء الاصطناعي الاكتشاف والتعاون عبر أُطر العمل. وُلد في Google، وتحكمه Linux Foundation.
- الفرق: MCP عمودي (الوكيل ↔ الأدوات)؛ وA2A أفقي (الوكيل ↔ الوكيل). والجمع بينهما هو المعيار.
- كيف يعمل: الاكتشاف عبر بطاقة وكيل (بطاقة عمل) ← مهمة (Task) (طلب) ← نتيجة (Artifact). يتعاونون بأمان مع إبقاء الدواخل خفيّة.
من وكيل واحد إلى «فريق» يتعاون — A2A هو الجسر. اقرأه جنبًا إلى جنب مع MCP وأنظمة الوكلاء المتعدّدين لتفهم الصورة الكاملة لتعاون الوكلاء في عام 2026.
الأسئلة الشائعة
س. هل أستخدم A2A أم MCP؟
ج. ليست مسألة أحدهما أو الآخر. لربط الوكيل بالأدوات والبيانات، استخدم MCP؛ ولجعل الوكلاء ينسّقون فيما بينهم، استخدم A2A. وفي نظام حقيقي تجمع بينهما: «كل وكيل يحتفظ بأدواته عبر MCP ويتعاون عبر A2A».
س. ما هي بطاقة الوكيل (Agent Card)؟
ج. هي «بطاقة عمل» الوكيل. ملف JSON يذكر «ما الذي يستطيع فعله، وأين تتحدث إليه، وكيف تجري المصادقة»، يوضَع عند /.well-known/agent-card.json. يقرؤها الطرف الآخر ليقرّر ما إذا كان بإمكانه التفويض إليه.
س. هل يمكنه التنسيق مع ذكاء اصطناعي تابع لشركة أخرى؟
ج. هذا هو الهدف الكامل من A2A. فلأنه بروتوكول مشترك، يمكن لوكلاء من مزوّدين وأُطر عمل مختلفة أن ينسّقوا فيما بينهم. ويُبقي كلٌّ منهم دواخله خفيّة ولا يتبادل سوى المهام والنتائج.
س. هل يحتاج المطوّرون الأفراد إلى A2A؟
ج. إذا كان لديك وكيل واحد فقط، فلا. ويظهر نفع A2A حين تريد لعدّة وكلاء مستقلّين أن ينسّقوا فيما بينهم. ويكفي أن تبني وكيلًا واحدًا أولًا وتعتمد A2A حين تصبح الحاجة إلى التنسيق ضرورية.
