A2A protocol: متى تحتاجه لربط وكلاء الذكاء الاصطناعي؟

استخدم بروتوكول A2A (A2A protocol) عندما يحتاج وكيلك إلى تفويض العمل إلى وكيل تديره جهة مستقلة. واستخدم Model Context Protocol (MCP) عندما يحتاج إلى الوصول إلى أدوات أو بيانات. يغيّر الإصدار A2A v1.0 متطلبات التكامل المتفق عليها، لذا يتوقف الاختيار على طبيعة الاتصال بين النظامين، وعلى الإصدارات التي تدعمها نقاط النهاية لديك.

ما الفرق بين MCP وA2A في الوصول إلى الأدوات وتفويض العمل؟

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

يوحّد Model Context Protocol (MCP) طريقة اتصال تطبيق الذكاء الاصطناعي بالأنظمة الخارجية، بما فيها الأدوات ومصادر البيانات. أما Agent2Agent (A2A) فيوحّد التواصل بين الوكلاء المستقلين. وتصفهما الوثائق الرسمية بأنهما متكاملان. مقدمة عن MCP، العلاقة بين A2A وMCP.

مثال على MCP: الاستعلام عن طلب

تخيّل وكيلًا لخدمة العملاء يجيب عن سؤال حول توصيل طلب. يتيح خادم MCP أداة للاستعلام عن الطلبات. يرسل الوكيل معرّف الطلب، ويتلقى بياناته، ثم يصوغ الرد للعميل.

الفائدة العملية هنا هي اتصال بنظام الطلبات يمكن إعادة استخدامه. ولا حاجة إلى إدخال وكيل آخر لمجرد استرجاع سجل. يتناول دليل خوادم MCP جانب ربط الأدوات في هذا القرار.

مثال على بروتوكول A2A: تفويض إعداد قائمة مختصرة بالموردين

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

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

ويمكن لوكيل التوريد أن يستخدم MCP داخليًا لاسترجاع بيانات الكتالوج. في هذا التصميم، يتولى A2A نقل العمل المفوّض، ويوفّر MCP الوصول إلى البيانات.

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

ما هو بروتوكول A2A (A2A protocol)؟

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

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

من طوّر A2A ومن يدير المشروع؟

صياغة الموقع الرسمي دقيقة: «طوّرت Google بروتوكول A2A في الأصل وتبرعت به إلى Linux Foundation». ويذكر أن لجنة توجيه فنية تتولى صيانة المشروع. وبذلك أصبح للمشروع هيكل حوكمة يتجاوز الجهة التي طوّرته أولًا. الحوكمة والمصدر المفتوح.

يمثّل مستودع a2aproject/A2A نقطة البداية للوصول إلى المواصفة وروابط حزم SDK والأمثلة. أما A2A نفسه فهو بروتوكول؛ وتبقى مسؤولية اختيار البرمجيات التي تبني وكلاءك وتشغّلهم لديك.

مواصفة بروتوكول A2A: المفاهيم التي تحتاج إلى فهمها

التمييز الأساسي هنا هو بين المحادثة، والعمل الذي يجري تتبعه، والمخرج الذي يسلّمه. الفصل بين هذه العناصر يسهّل تصميم نظامك وفقًا للبروتوكول.

بطاقة الوكيل: كيف يعرف العميل ما يقدّمه الوكيل؟

بطاقة الوكيل (Agent Card) هي وثيقة بيانات وصفية بصيغة JSON تصف هوية الوكيل ومهاراته وقدراته ومعلومات الاتصال به ومتطلبات المصادقة. وتساعد العميل على تقرير ما إذا كان سيتصل بذلك الوكيل وكيف سيفعل ذلك. المفاهيم الأساسية.

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

المسار القياسي الموثّق لاكتشاف البطاقة هو /.well-known/agent-card.json. ويمكن أيضًا الحصول على البطاقات عبر إعداد مباشر أو سجل منتقى. ولا يفرض A2A واجهة API معيارية لتلك السجلات. اكتشاف الوكلاء.

المهام والرسائل والأجزاء والمخرجات

المهمة (task) هي وحدة عمل تحتفظ بحالتها، ولها معرّف ودورة حياة. والرسالة (message) هي دور في التواصل. أما الجزء (Part) فيحمل النص الفعلي، أو محتوى ملف أو مرجعًا إليه، أو بيانات منظّمة. والمخرج (artifact) هو ناتج ملموس يُنتَج أثناء المهمة. المفاهيم الأساسية.

في مثال الموردين، يُعد سؤال «ما منطقة التوصيل؟» جزءًا من التواصل. وعملية البحث عن الموردين التي يجري تتبعها هي المهمة. أما القائمة المختصرة المكتملة فهي المخرج. وينبغي لسير عمل المشتريات أن يتعامل مع القائمة بوصفها نتيجة مسلّمة، بدلًا من البحث في سجل المحادثة عمّا يبدو أنه نتيجة مكتملة.

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

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

آليات النقل: كيف يُنفَّذ اتفاق التواصل نفسه عبر الاتصال؟

تحدّد آلية النقل، أو ربط البروتوكول بآلية نقل، كيفية تمرير العمليات عبر الاتصال. وتعرّف المواصفة آليات ربط تستخدم JSON-RPC وgRPC وHTTP+JSON/REST. وتحدّد الواجهات المدرجة في بطاقة الوكيل نقطة النهاية وآلية الربط وإصدار البروتوكول. مواصفة A2A.

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

ما الذي تغيّر في A2A v1.0؟

تحتاج عمليات التكامل القائمة إلى مراجعة توافق؛ ولا يكفي تغيير النص الذي يحدّد الإصدار. التغييرات التالية هي التي تعرضها الصفحة الرسمية للمستجدات عند المقارنة بين v0.3.0 وv1.0:

• تعريف مشترك: يصبح a2a.proto المرجع المعتمد لتعريف البروتوكول، مع مواصفات رسمية لآليات ربطه بالنقل.
• صيغ مختلفة للبيانات المتبادلة: يحلّ Part موحّد محل أنواع المحتوى المنفصلة؛ وتحل أسماء الحقول محل محدّدات النوع kind، وتستخدم قيم التعداد صيغة SCREAMING_SNAKE_CASE.
• إعادة تنظيم بطاقات الوكلاء: يجمع supportedInterfaces تفاصيل الاتصال، مع تحديد إصدار البروتوكول لكل واجهة.
• تحديث العمليات: تصبح message/send هي SendMessage؛ وتضيف ListTasks إمكانية عرض قوائم مُرشَّحة مع تقسيم النتائج إلى صفحات باستخدام مؤشر.
• تغييرات تخص المؤسسات: تؤثر حقول المستأجرين وقواعد التحقق من توقيعات بطاقات الوكلاء وتحديثات تدفقات OAuth في تصميم التكامل.

جرى التحقق من هذه التغييرات بالرجوع إلى صفحة مستجدات v1.0 التابعة للمشروع في 12 أكتوبر 2026.

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

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

توجد تطبيقات موثّقة للبروتوكول، لكن الإصدارات والميزات التي تغطيها تختلف. اختر وفقًا للسلوك الذي يحتاجه سير عملك. جرى التحقق من الدعم والقيود التالية بالرجوع إلى الوثائق العامة لكل جهة مطوّرة في 12 أكتوبر 2026؛ ولم يُجرَ اختبار للمنتجات من داخل حساب مسجّل الدخول.

Google Agent Development Kit

Google Agent Development Kit (ADK) هو إطار عمل لبناء الوكلاء. وتوثّق أدلته استخدام to_a2a لإتاحة وكيل عبر A2A وتوليد بطاقة الوكيل الخاصة به. ويحمل تكامله مع A2A في Python وصف تجريبي. تدعم الوثائق a2a-sdk بالإصدارين 0.3.x و1.x.x، وتوجّه عمليات التكامل الجديدة نحو 1.x.x. دليل إتاحة الوكلاء في ADK.

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

LangGraph عبر LangSmith Agent Server

يتيح LangSmith Agent Server، وهو طبقة تقديم الخدمة الموثّقة لنشر LangGraph، نقطة نهاية لـA2A على المسار /a2a/{assistant_id}. وتنص وثائقه على استخدام ربط JSON-RPC للإصدار v1.0، مع قبول أسماء الأساليب من v0.3. ويحتاج الرسم البياني إلى حقل messages في حالته. وثائق A2A في LangSmith.

وتذكر الصفحة نفسها قيودًا: لم تُنفَّذ آليتا gRPC وHTTP+JSON، ولا يتوفر بعد دعم SubscribeToTask أو إعداد إشعارات الدفع. بث الرسائل مدعوم، لكن ذلك لا يعني توافر كل عمليات الاشتراك أو الإشعارات. وهذا سبب عملي لفحص تغطية العمليات قبل اختيار تصميم للمهام التي تعمل في الخلفية.

CrewAI وCrewAI AMP

CrewAI هو إطار عمل لتنسيق الوكلاء، وتوثّق أدلته استخدام A2AClientConfig للتفويض إلى وكلاء بعيدين، وA2AServerConfig لإتاحة الوكلاء. ويمكن إعداد الوكيل لأداء الدورين معًا. وثائق التفويض في CrewAI.

تصف CrewAI AMP، منصة النشر التابعة له، وكلاء خادم A2A بأنهم في إصدار مبكر، وتذكر دعم إصداري البروتوكول 0.2 و0.3. وتصف أيضًا استخدام تخزين موزّع دائم بدلًا من حفظ الحالة في الذاكرة كما في التنفيذ المفتوح المصدر. فلا تفترض أن نقطة نهاية على AMP تدعم v1.0 لمجرد أن CrewAI يدعم A2A. A2A على AMP.

Microsoft Foundry Agent Service

Microsoft Foundry Agent Service منصة مُدارة للوكلاء. وتوثّق نوع الأداة a2a المتاح عمومًا لدعم البروتوكول 1.0. أما نوع الأداة الأقدم a2a_preview فيدعم 0.3، ولا يزال في مرحلة المعاينة. وتوصي Microsoft بالنوع المتاح عمومًا لعمليات التكامل الجديدة. وثائق A2A في Foundry.

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

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

ماذا يعني ذلك للمطوّرين وفرق التشغيل والمشترين؟

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

المطوّرون: حدّدوا ما ستفوّضونه قبل إضافة آلية نقل. «أعدّ قائمة مختصرة بالمصادر والمبررات» يحدّد مسؤولية خدمة، بينما «نفّذ هذا الاستعلام في قاعدة البيانات» يحدّد وظيفة أداة. حافظوا على هذا الفرق حتى لو انتهى المساران إلى استدعاء نماذج.

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

المشترون ومؤسسو الشركات: اطلبوا تحديد إصدار البروتوكول المدعوم، وآلية الربط، والعمليات، وأنواع المحتوى، وحالة الإتاحة للنشر. وقارنوا هذه التفاصيل بمتطلبات سير عملكم. ادّعاء التوافق دون هذه التفاصيل لا يكفي للالتزام بتكامل.

كيف تقدّر ميزانية نشر A2A؟

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

استخدم معادلة التخطيط التالية مع احتساب جميع البنود ضمن الفترة المالية نفسها:

صافي فائدة التكامل = تكاليف الموصّلات التي جرى تجنّبها ناقص تكاليف الانتقال، وتكاليف البنية التحتية الإضافية، وتكاليف التشغيل المستمرة.

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

أين تكمن المبالغة في الوعود حول A2A؟

البروتوكول المشترك لا يجعل الوكلاء غير المعروفين جديرين بالثقة، ولا يضمن تلقائيًا موثوقية العمل الموزّع. فهو يقدّم توحيدًا مفيدًا، لكن قرارات التطبيق تبقى مسؤوليتك.

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

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

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

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

هل أحتاج إلى A2A أم MCP أم كليهما؟

ابدأ بطبيعة الاتصال التي يحتاجها منتجك اليوم.

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

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

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

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

ما الخطوة التالية في البناء؟

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

1. 1

   حدّد مواصفات المخرج المقبول

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

2. 2

   طابق الواجهات الموثّقة

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

3. 3

   صمّم التعامل مع الحالات غير المحسومة

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

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

أسئلة قبل إضافة A2A

هل يمكن استخدام A2A دون MCP؟

نعم. لا يفرض A2A طريقة وصول الوكيل البعيد إلى أدواته وبياناته. ويفيد MCP عندما تحتاج أيضًا إلى اتصالات موحّدة بالأدوات. كيف يعملان معًا.

هل يجب أن يستخدم الوكيلان إطار العمل نفسه؟

لا. قابلية التشغيل البيني بين أطر العمل المختلفة من الأهداف الأساسية لـA2A. وما يجب أن يتوافق هو الواجهة المتاحة والميزات التي يحتاجها التفاعل، لا طريقة التنفيذ الداخلية للوكلاء. نظرة عامة على A2A.

للحصول على أدلة عملية لبناء أنظمة وكلاء مفيدة، اشترك في النشرة البريدية.