بروتوكول التواصل بين العملاء (Agent-to-Agent Protocol - A2A)

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

ما هو A2A بالضبط؟

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

لماذا نحتاج A2A رغم وجود MCP؟

يُوحّد هذان البروتوكولان علاقتين مختلفتين تمامًا. يحل MCP علاقة "العميل بالأداة/البيانات" (اتصال عميل بقاعدة بيانات أو واجهة برمجية). ويحل A2A علاقة "العميل بعميل آخر" — أي أن الطرف الآخر هو نفسه صانع قرار مستقل له منطقه وأهدافه الخاصة، وليس مجرد أداة سلبية.

Agent Card

كل عميل يدعم A2A ينشر مستند JSON عامًا يُسمى Agent Card — شيء أشبه ببطاقة عمل قابلة للقراءة الآلية. تتضمّن هذه البطاقة اسم العميل، ووصف قدراته (Skills)، وعنوان نقطة النهاية، ومتطلبات المصادقة. من الناحية المفاهيمية، تلعب هذا البطاقة تمامًا نفس الدور الذي يلعبه ملف ucp.json بالنسبة لمتجر ما؛ إلا أن "المتجر" هذه المرة هو عميل آخر.

اكتشاف العميل (Discovery)

قبل أي تفاعل، يحتاج العميل المصدر لمعرفة ما يستطيع العميل الهدف فعله أصلًا. وفقًا لمواصفات A2A، ينشر كل عميل بطاقة Agent Card الخاصة به على عنوان معياري ومعروف: /.well-known/agent.json. هذا يعني أن اكتشاف قدرات عميل مجهول ممكن بمجرد معرفة نطاقه (domain) فقط — دون الحاجة لتوثيق يدوي أو تنسيق مسبق بين فريقي تطوير.

دورة حياة Task

وحدة العمل الأساسية في A2A هي Task، وتمر بمراحل محددة:

1. submitted — يرسل العميل المصدر المهمة
2. working — العميل الهدف قيد المعالجة (قد يرسل رسائل/حالات وسيطة)
3. input-required — إذا لزم مزيد من المعلومات، يسأل العميل المصدر
4. completed / failed — تنتهي المهمة بنتيجة نهائية (Artifact) أو بخطأ

الرسائل وArtifact

يتواصل العملاء أثناء Task عبر تبادل الرسائل (Messages) (نص أو ملف أو بيانات مهيكلة)، وتُسلَّم النتيجة النهائية على شكل واحد أو أكثر من Artifact (مثل مستند أو صورة أو سجل JSON).

التحديثات التدفقية وإشعارات الدفع

لا تنتهي العديد من المهام فورًا — فمثلًا "حجز شحنة" قد يستغرق دقائق أو حتى ساعات. يوفّر A2A لهذه الحالة آليتين:

• البث عبر SSE (Server-Sent Events) — عندما يبقى العميلان متصلَين عبر الإنترنت، يمكن للعميل الهدف بث حالات Task الوسيطة فور توليدها عبر اتصال مفتوح.
• إشعارات الدفع (Webhook) — بالنسبة للمهام طويلة الأمد التي لا يكون فيها إبقاء اتصال حي منطقيًا، يوفّر العميل المصدر عنوان Webhook، ويرسل العميل الهدف طلب HTTP إليه كلما تغيّرت حالة Task (مثلًا من working إلى completed).

يعتمد الاختيار بين الآليتين على ما إذا كان بإمكان العميلين الحفاظ على اتصال مفتوح طوال تنفيذ Task أم لا.

A2A مقابل MCP

مثال: Agent Card بسيط

{
  "name": "LogisticsAgent",
  "description": "تتبّع وحجز الشحنات للمتاجر الإلكترونية",
  "url": "https://logistics.example.com/a2a",
  "skills": [
    { "id": "create_shipment", "description": "تسجيل شحنة جديدة" },
    { "id": "track_shipment", "description": "تتبّع حالة الشحنة" }
  ],
  "authentication": { "schemes": ["bearer"] }
}

الأسئلة الشائعة