بروتوكول جوجل الجديد A2A: كيف ستتحدث وكلاء الذكاء الاصطناعي معًا؟

تأبى شركة جوجل إلا أن تكون من السباقين في عالم الذكاء الاصطناعي. ولمن لا يعرف، فإن عالم الذكاء الاصطناعي بوضعه الحالي في الموجة الثالثة، “الذكاء الاصطناعي التوليدي” (Generative AI)، قد بدأ من شركة جوجل عندما أطلقوا الورقة البحثية “Attention Is All You Need”. في ذلك الوقت، لم يكونوا يعرفون القيمة الحقيقية لتلك الورقة البحثية، والتي استخدمتها شركات أخرى مثل OpenAI لبناء نماذج GPT والثورة العالمية في عالم الذكاء الاصطناعي التي نعيشها اليوم.

وإن تأخرت شركة جوجل في السباق قليلاً، لكنها يومًا عن يوم تعود إلى مقدمة هذا السباق. فقد أطلقت في الأسابيع الماضية نماذج أقوى مثل Gemini 1.5 Pro، وأطلقت أيضًا نموذج Flash قبل أيام. لا يقتصر الأمر على النماذج فحسب، بل يمتد إلى التقييس (Standardization) وشرح كيفية عمل التقنيات للعالم. اليوم، تدخل جوجل بقوة عن طريق “بروتوكول الوكيل إلى الوكيل” (Agent-to-Agent Protocol) أو A2A، وهو موضوع هذا المقال. سنتحدث عنه وسنطبق عليه مثالاً عملياً.

ما هو بروتوكول A2A؟

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

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

• في حالة MCP (Model-Context-Protocol)، كان البروتوكول عبارة عن الأدوات التي يستخدمها الذكاء الاصطناعي للتحدث مع قاعدة بيانات أو واجهات برمجة التطبيقات (APIs).
• في حالة TCP/IP، وهو بروتوكول الإنترنت، فهو يحدد كيف تنتقل حزم البيانات من جهازك إلى خادم يوتيوب مثلاً.

إذًا، البروتوكول دائمًا هو وسيلة للتواصل بين طرفين. وعليه، فإن A2A هو وسيلة للتواصل بين الوكلاء (Agents).

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

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

الخصائص الرئيسية لبروتوكول A2A

تعاونت جوجل مع العديد من الشركات الكبيرة والشركاء مثل Accenture, Deloitte, Oracle, SAP لبناء هذا البروتوكول، والذي يتميز بعدة مواصفات:

• المرونة (Flexibility): تم التركيز على أن تظل الوكلاء مرنة، وليس من الضروري أن يكون لها هيكل واضح. الهدف هو عدم تحويل الوكلاء إلى مجرد أدوات، بل يُفترض أن تمتلك قدرات معالجة اللغة الطبيعية، مثلما يمكنك التحدث مع ChatGPT بأريحية.
• الاتصال القياسي (Standard Communication): استخدموا معايير موجودة مسبقًا مثل HTTPS، SSE، JSON، و gRPC (Remote Procedure Call)، حتى لا يضطر المطورون إلى اختراع شيء جديد.
• الأمان (Security): البروتوكول آمن، ويمكن للوكلاء التحدث مع بعضها البعض بشكل متزامن (synchronously) أو غير متزامن (asynchronously)، وهو ما سنتناوله لاحقًا.
• تعددية الوسائط (Modality): لن تتعامل الوكلاء فقط مع النصوص، بل يمكن أن تكون متعددة الوسائط (multi-modal)، فتتعامل مع الصوت والصور والفيديو، إلخ.

قدرات بروتوكول A2A

يتحدث المقال الرسمي عن قدرات A2A، والتي تشمل:

• اكتشاف القدرات (Capability Discovery): إذا كنت أنا وكيلاً وأبحث عن وكيل آخر، فيمكنني البحث في بيانات وصفية معينة (metadata) عن وكيل متخصص في المبيعات مثلاً، ومن ثم مخاطبته.
• إدارة المهام (Task Management): يتواصل الوكيل مع وكيل آخر عبر توجيه مهمة (task) له.
• التعاون (Collaboration): يمكن أن يطلب الوكيل توضيحات حول المهمة.
• التفاوض حول تجربة المستخدم (User Experience Negotiation): يمكن تحديد تنسيق الرد، كأن يُطلب الجواب في صورة أو نص.

العلاقة مع بروتوكول MCP

لنلقِ نظرة سريعة على البنية الهيكلية لفهم العلاقة بين A2A و MCP. تحدثنا عنه في مقال سابق، MCP هو بروتوكول للتخاطب بين أداة (مثل Claude, Cursor) وخادم MCP، الذي بدوره يتحدث مع قاعدة بيانات أو واجهة برمجة تطبيقات. يمكن استبدال واجهة برمجة التطبيقات هنا بوكيل.

أما في بنية جوجل، فالوكيل نفسه قد يتكون من وكلاء محليين (local agents) ويتحدث مع واجهات برمجة تطبيقات، وعن طريق ما أطلقوا عليه “Agent Development Kit” وباستخدام MCP، يمكنه التحدث مع أدوات مختلفة. فإذا كان هناك وكيل آخر مماثل في جهة أخرى، فكيف سيتخاطب هذان الوكيلان؟ هنا يأتي دور بروتوكول A2A. هذا التوضيح يبين أن A2A و MCP لا يتعارضان.

كيف يعمل تدفق الاتصال في A2A؟

من ناحية تدفق العمل (flow)، تتم العملية كالتالي:

1. الاكتشاف (Discovery): الوكيل الأول يبحث عن الوكيل الثاني.
2. البدء (Initiation): يبدأ الاتصال عبر إرسال مهمة (task) أو اشتراك في مهمة (task subscription).
3. المعالجة (Processing): يقوم الوكيل الخادم بمعالجة الطلب، إما بشكل متدفق (streaming/asynchronous) أو غير متدفق (non-streaming/synchronous).
   • غير المتدفق (Synchronous): ينتظر العميل الخادم، ويرسل الخادم الرسالة كاملة مع النتائج دفعة واحدة.
   • المتدفق (Asynchronous): يحتاج الخادم إلى وقت، فيرسل حالة المهمة (status) فقط إلى العميل حتى ينتهي.
4. الاكتمال (Completion): تنتهي المهمة إما بالنجاح (completed)، أو الفشل (failed)، أو الإلغاء (cancelled).

هذا بشكل عام يوضح كيفية تحدث الوكلاء مع بعضهم البعض.

مثال توضيحي من جوجل

في المثال الذي عرضته جوجل، يبحث المستخدم عن مهندس برمجيات لتوظيفه.

1. يسأل العميل بروتوكول A2A أنه يبحث عن مهندس برمجيات.
2. يبحث البروتوكول في قدرات الوكلاء ويجد أنه بحاجة إلى وكيل توظيف (recruitment agent).
3. يبدأ التعاون، حيث يسأل الوكيل عن الموقع الجغرافي للمرشحين.
4. يجيب المستخدم: “في أي مكان بفارق 3 ساعات عن توقيت المحيط الهادئ الأمريكي (US Pacific Time)”.
5. هنا تأتي ميزة “تجربة المستخدم”، حيث يعرض الوكيل قائمة بالمرشحين داخل إطار (iFrame).
6. بعد أسبوعين، يطلب المستخدم تحديثًا، فيخبره الوكيل بنجاح ثلاثة مرشحين.
7. يطلب المستخدم إجراء فحص خلفية (background check) لهم.
8. يخبره الوكيل أنه تحقق من أحدهم، لكن لا يمكنه التحقق من الاثنين الآخرين لأن وكيل فحص الخلفية ليس لديه صلاحية وصول خارج أمريكا.
9. يطلب المستخدم التحقق منهم، وهنا يعطيه مهمة جديدة، وهي “إدارة المهام”، حيث يبحث الوكيل عن طريقة أخرى لإنجازها.

التطبيق العملي: وكيل تحويل العملات

لننتقل إلى مثال عملي من GitHub. المثال عبارة عن وكيل يمكنه تحويل العملات. العميل يسأل الوكيل عن سعر الصرف بين عملتين، فيقوم وكيل LangGraph بسؤال واجهة برمجة تطبيقات (Frankfurter API) التي تعيد أسعار العملات.

لتجربة المثال، اتبع الخطوات التالية:

1. استنساخ المستودع:

   git clone https://github.com/google/a2a-protocoll
   cd a2a-protocol
   

2. إعداد الخادم (Server):
   • انتقل إلى مجلد المثال:

     cd samples/python/agents/lang_graph_agent
     

   • ستحتاج إلى مفتاح API. يمكنك الحصول عليه من AI Studio.
   • قم بتعيين مفتاح API كمتغير بيئة:

     export GOOGLE_API_KEY='YOUR_API_KEY'
     

   • قم بتشغيل الخادم باستخدام Uvicorn على المنفذ 10000:

     uvicorn main:app --port 10000
     

     الآن الخادم يعمل على المنفذ 10000.

3. إعداد العميل (Client):
   • افتح طرفية (terminal) جديدة.
   • انتقل إلى مجلد samples/python:

     cd samples/python
     

   • قم بتشغيل العميل مع الإشارة إلى الخادم. (ملاحظة: التوثيق الرسمي قد لا يكون واضحًا تمامًا، يجب إضافة المعلمة --agent_http_url).

     python -m client.client_cli --agent_http_url http://localhost:10000
     

4. التفاعل مع الوكيل:
   • عند تشغيل العميل، سيجلب ما يسمى بـ “Agent Card”، والتي تصف قدرات الوكيل (المساعدة في أسعار الصرف).
   • سيطرح عليك العميل السؤال: What do you want to ask the agent?
   • اطرح سؤالك، على سبيل المثال:

     What is the exchange rate from EUR to USD?
     

   • سيتصل العميل بالخادم، وسيقوم الخادم بدوره بالاتصال بواجهة برمجة التطبيقات frankfurter.app للحصول على سعر الصرف، ثم يعيد الجواب.
   • ستظهر النتيجة في العميل، وعلى الخادم ستظهر سجلات الطلب، وستكون النتيجة شيئًا مثل: The exchange rate from EUR to USD is 1.136.

هذا مثال بسيط يوضح كيفية عمل بروتوكول A2A مع عميل وخادم.

الخلاصة

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

أتمنى أن يكون هذا المقال قد نال إعجابكم واستفدتم منه. نراكم في المقال القادم.