اليوم، معظم أنظمة الذكاء الاصطناعي هي وكلاء منفردون. نموذج واحد، حلقة موجه واحدة، مجموعة أدوات واحدة. هذا يعمل حتى يصبح العمل أكبر من أن يقوم به وكيل واحد، أو حتى تحتاج إلى وكيل بُني بواسطة فريق آخر للتعامل مع خطوة لا يستطيع وكيلك التعامل معها. حينها تواجه حاجزًا: لا توجد طريقة قياسية لوكيلين مستقلين للعثور على بعضهما البعض، وتبادل العمل، والإبلاغ عن النتائج. Agent2Agent (A2A) هو البروتوكول الذي بُني لإزالة هذا الحاجز.
يشرح هذا الدليل ماهية 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). كانت كل عملية ربط مخصصة. إذا احتاج وكيلك إلى استدعاء وكيل بحث لفريق شريك، كتب شخص ما عميلاً مخصصًا، واختار شكل الحمولة، واخترع مخططًا للمصادقة، وقام بصيانة كل ذلك يدويًا. بدأت عملية الربط التالية من الصفر مرة أخرى.
تنهار هذه الطريقة بسرعة:
- لا يوجد اكتشاف. لم تكن هناك طريقة قياسية للوكيل ليسأل "ماذا يمكنك أن تفعل؟" قبل إرسال العمل.
- لا يوجد نموذج مهمة مشترك. أعاد وكيل سلسلة نصية عادية، وأعاد آخر كتلة JSON مخصصة، وبث ثالث الرموز المميزة. كان على المتصل أن يتعامل مع كل حالة على حدة.
- لا توجد مصادقة مشتركة. أعادت كل عملية تكامل اختراع بيانات الاعتماد والرؤوس.
- لا يوجد قابلية للتشغيل البيني. لم يتمكن وكيل مبني على AutoGen من أن يحل محل وكيل مبني على LangGraph، حتى لو كانا يقومان بنفس المهمة.
يصلح A2A هذا بنفس الطريقة التي أصلح بها OpenAPI تكاملات REST: عقد متفق عليه واحد، بحيث يمكن لأي وكيل متوافق التحدث إلى أي وكيل متوافق آخر.
كيف يعمل A2A
لدى A2A أربعة مفاهيم أساسية. بمجرد أن تعرفها، سيتناسب البروتوكول بأكمله في ذهنك.
بطاقة الوكيل (Agent Card)
بطاقة الوكيل (Agent Card) هي مستند JSON ينشره الوكيل لوصف نفسه. إنها نقطة الدخول للاكتشاف. تسرد اسم الوكيل، ووصفه، وقدراته، ومهاراته المعلنة، وأنواع المدخلات والمخرجات المدعومة، ومتطلبات المصادقة، وإصدار البروتوكول.
وفقًا للاتفاقية، توجد البطاقة في مسار معروف، غالبًا https://your-agent.example.com/.well-known/agent.json. يستدعي الوكيل المتصل هذا العنوان URL أولاً، ويقرأ البطاقة، ويتعلم بالضبط ما يمكنه طلبه قبل إرسال رسالة واحدة.
المهام (Tasks)
المهمة هي وحدة العمل في A2A. عندما يطلب وكيل من آخر القيام بشيء ما، يصبح هذا الطلب مهمة ذات معرّف خاص بها وحالة تتنقل عبر حالات مثل submitted (مقدمة)، working (قيد العمل)، input-required (تتطلب إدخالًا)، و completed (مكتملة). يمكن للمتصل استطلاع حالة المهمة أو الاشتراك في التحديثات. نموذج المهمة المشترك هذا هو ما يجعل وكلاء A2A قابلة للتبديل؛ يتعامل المتصل مع الحالة بنفس الطريقة بغض النظر عمن يقوم بالعمل.
الرسائل والمخرجات (Messages and artifacts)
تحمل الرسالة المحتوى الفعلي بين الوكلاء. تتكون الرسالة من أجزاء: جزء نصي، جزء ملف، بيانات منظمة، أو مزيج. يقرأ الوكيل المستلم الأجزاء التي تحتاجها مهارته.
عندما ينتهي الوكيل، فإنه يُرجع مخرجات (artifacts)؛ وهي المخرجات المنظمة للمهمة. قد يكون المخرج مستندًا تم إنشاؤه، جدول بيانات، ملخصًا، أو مرجع ملف. تُبنى المخرجات أيضًا من أجزاء، لذا يظل التنسيق متسقًا في كلا الاتجاهين.
البث والتحديثات (Streaming and updates)
المهام طويلة الأمد لا تحتاج إلى حظر. يدعم A2A الأحداث المرسلة من الخادم، بحيث يمكن للوكيل بث النتائج الجزئية وتغييرات الحالة مع تقدم العمل. يمكن لوكيل البحث إصدار "تم العثور على 3 مصادر" قبل إصدار التقرير النهائي. يعرض المتصل التقدم بدلاً من التحديق في مؤشر تحميل.
بشكل عام، تبدو عملية تبادل A2A النموذجية كما يلي:
- يجلب الوكيل A بطاقة الوكيل B ويقرأ مهاراته.
- يرسل الوكيل A رسالة تنشئ مهمة.
- يعالج الوكيل B المهمة ويبث تحديثات الحالة.
- يُرجع الوكيل B المخرجات عندما تصل المهمة إلى حالة
completed(مكتملة). - يستهلك الوكيل A المخرجات وينتقل إلى الخطوة التالية.
المحادثة بأكملها هي JSON عبر HTTP. لا شيء غريب.
مقارنة A2A و MCP
يتم الخلط بين A2A وبروتوكول سياق النموذج (MCP) باستمرار لأن كلاهما يتضمن وكلاء وكلاهما بروتوكولات مفتوحة. ومع ذلك، فإنهما يحلان مشكلات مختلفة.
| A2A | MCP | |
|---|---|---|
| يربط | الوكيل بالوكيل | الوكيل بالأدوات والبيانات |
| السؤال الذي يجيب عليه | "هل يمكن لوكيل آخر أن يقوم بهذه الخطوة نيابة عني؟" | "ما هي الأدوات والموارد التي يمكن لهذا الوكيل الوصول إليها؟" |
| الاستخدام النموذجي | سير عمل متعدد الوكلاء عبر الفرق | وكيل واحد يستدعي قاعدة بيانات أو نظام ملفات أو واجهة برمجة تطبيقات (API) |
| وحدة التبادل | المهام، الرسائل، المخرجات | استدعاءات الأدوات، الموارد، الموجهات |
MCP هو كيف يصل الوكيل إلى الأنظمة الخارجية. A2A هو كيف يصل الوكيل إلى وكيل آخر. غالبًا ما يستخدم نظام الإنتاج الحقيقي كليهما: يستخدم الوكيل MCP للاستعلام عن قاعدة بيانات ويستخدم A2A لتسليم مهمة فرعية إلى وكيل متخصص. يغطي تفسير مقارنة خادم MCP و A2A القرار بعمق، ويعرض مصَحِّح عميل MCP الخاص بـ Apidog جانب MCP عمليًا.
التعاون متعدد الوكلاء في الواقع
A2A هو إحدى طرق جعل الوكلاء يتعاونون، ولكنه ليس الوحيد. تستخدم بعض الأنظمة التنسيق المباشر بدلاً من ذلك، حيث يخطط وكيل واحد للعمل ويفوض صراحةً لوكيل آخر.
مثال واضح مفتوح المصدر هو Codex-Claude-Collab، وهي مهارة تنسق سير عمل في الوقت الفعلي بين OpenAI Codex و Claude Code. يخطط Codex للمهمة، ويفوض التنفيذ إلى Claude Code، ثم يراجع الفروقات ويتحقق من النتيجة قبل الإجابة على المستخدم. إنها حلقة محكمة للتخطيط والبناء بين وكيلين مختلفين للبرمجة.
هذا النمط هو تنسيق مبرمج مسبقًا (hard-wired orchestration)؛ يعرف أحد الطرفين بالضبط من هو الطرف الآخر. يعمم A2A نفس الفكرة: بدلاً من أن يعرف Codex أنه يستدعي Claude Code على وجه التحديد، يقرأ المتصل بـ A2A بطاقة وكيل (Agent Card) ويعمل مع أي وكيل متوافق يستجيب. التنسيق ممتاز عندما تتحكم في كلا الطرفين. A2A هو ما تريده عندما يكون الوكلاء مستقلين، أو مملوكين لفرق مختلفة، أو يحتاجون إلى أن يكونوا قابلين للتبديل. تنتهي معظم الأنظمة الناضجة باستخدام كليهما: التنسيق داخل الفريق، و A2A عبر حدود الفرق.
كيفية اختبار وكيل A2A
بمجرد بناء أو استخدام وكيل A2A، تحتاج إلى رؤية حركة المرور. تخفي سجلات وحدة التحكم (Console logs) الحقول المنظمة، وتتدهور نصوص الاختبار المخصصة. هنا يكتسب مصَحِّح A2A المرئي أهميته.
تتضمن Apidog مصَحِّح A2A في عميلها القياسي. تقوم بلصق عنوان URL لبطاقة الوكيل (Agent Card)، والنقر على اتصال (Connect)، ثم يقرأ Apidog البطاقة ويعرض اسم الوكيل وقدراته ومهاراته. يمكنك إرسال رسالة اختبار، وإرفاق ملفات، وإضافة بيانات وصفية، وقراءة الرد في ثلاثة طرق عرض: معاينة قابلة للقراءة، والمحتوى الخام، وحمولة JSON-RPC الكاملة. يتعامل مع رؤوس Bearer Token و Basic Auth و API-key بدون الحاجة إلى curl.
النقطة الأساسية هي العزل. عندما يتصرف وكيل بشكل خاطئ، تريد أن تعرف ما إذا كان النقل (transport) خاطئًا أم أن منطق الوكيل خاطئ. رؤية الحمولة السلكية الدقيقة تجيب على ذلك في ثوانٍ. يرشدك دليل Apidog A2A Debugger عبر حلقة كاملة من الاتصال والإرسال والقراءة، وينطبق المبدأ الأوسع لاختبار وكلاء الذكاء الاصطناعي الذين يستدعون واجهات برمجة تطبيقاتك على نفس مبدأ "تأكيد السلك أولاً".
البدء مع A2A
إذا كنت ترغب في بناء أو ربط وكيل A2A، إليك مسار مختصر:
- اقرأ مواصفات A2A لتتعرف على حقول بطاقة الوكيل المطلوبة ودورة حياة المهمة.
- شغّل أحد الوكلاء النموذجيين المرجعيين محليًا. يبدأ معظمهم في بضع دقائق ويعرضون بطاقة وكيل عاملة.
- وجه مصَحِّح A2A إلى عنوان URL لبطاقة الوكيل للنموذج وأرسل رسالة "مرحبًا". تأكد من أنك ترى الرحلة ذهابًا وإيابًا.
- ابنِ وكيلك الخاص، واعرض بطاقة وكيل صالحة، واختبره بنفس الطريقة قبل ربطه بسير العمل.
- أضف طبقات المصادقة، ومرفقات الملفات، والبث بمجرد أن يعمل المسار النصي العادي.
A2A حديث النشأة، ولكنه مدعوم من قبل مؤسسة محايدة للبائعين وقائمة متزايدة من تكاملات أطر العمل. إن التعامل مع حركة مرور الوكلاء كبروتوكول من الدرجة الأولى الآن يوفر عليك إعادة كتابة الرمز الرابط المخصص لاحقًا. يقدم منشور وكلاء الذكاء الاصطناعي هم مستهلكو واجهات برمجة التطبيقات الجدد الحجة الأطول، ويغطي تصميم واجهات برمجة التطبيقات لوكلاء الذكاء الاصطناعي التغييرات التي تحدث عندما يكون المستهلك وكيلًا بدلاً من إنسان.
أسئلة شائعة
هل A2A من صنع جوجل؟
قدمت جوجل A2A في عام 2025، ثم تبرعت به لمؤسسة لينكس كمشروع مفتوح ومحايد للبائعين. يتم تطوير المواصفات بشكل مفتوح، ويمكن لأي بائع تطبيقها.
هل أحتاج إلى A2A إذا كان لدي وكيل واحد فقط؟
لا. يحل A2A مشكلة التواصل بين الوكلاء. يحتاج الوكيل الواحد المزود بمجموعة أدوات إلى MCP، وليس A2A. تلجأ إلى A2A بمجرد دخول وكيل ثانٍ إلى الصورة.
ما هي أطر العمل التي تدعم A2A؟
A2A مستقل عن أطر العمل بطبيعته. يمكن لأي وكيل ينشر بطاقة وكيل صالحة ويتحدث البروتوكول المشاركة، لذا فإن LangGraph و CrewAI و AutoGen والوكلاء المخصصون جميعهم يعملون. الإطار الداخلي للوكيل غير مرئي للمتصلين.
هل A2A هو نفسه MCP؟
لا. يربط MCP وكيلًا واحدًا بالأدوات ومصادر البيانات. يربط A2A الوكلاء ببعضهم البعض. إنهما مكملان، وتعمل العديد من الأنظمة بكليهما في وقت واحد.
كيف أقوم بتصحيح تكامل A2A؟
استخدم مصَحِّح A2A مرئيًا مثل Apidog A2A Debugger. الصق عنوان URL لبطاقة الوكيل، وأرسل رسائل اختبار، وافحص الطلب والاستجابة الخام لتتمكن من التمييز بين أخطاء النقل وأخطاء منطق الوكيل.
هل يدعم A2A المهام طويلة الأمد؟
نعم. يحتوي نموذج المهام على حالات حالة صريحة، ويدعم البروتوكول الأحداث المرسلة من الخادم (server-sent events) لبث النتائج الجزئية وتحديثات التقدم، لذا فإن المهام الطويلة لا تحظر المتصل.