Agent2Agent Protocol

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

آلية عمل بروتوكول Agent2Agent#

يحدد الاستعراض الرسمي لبروتوكول A2A التفاعلات بين وكيل عميل يطلب تنفيذ العمل ووكيل بعيد ينفذه. ويستخدم الاتصال واجهات تستند إلى HTTP وكائنات بروتوكول منظمة بدلًا من الرسائل غير الرسمية الخاصة بتطبيق معين. (a2a-protocol.org)

يتضمن التفاعل المعتاد العناصر التالية:

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

يتبع تنسيق الطلبات الأساسي مواصفة JSON-RPC 2.0، ما يمنح عمليات التنفيذ بنية متسقة للطرائق والمعلمات والاستجابات والأخطاء.

مقارنة A2A بتقنيات الوكلاء ذات الصلة#

يعالج A2A الاتصال بين الوكلاء، لكنه لا يحدد كل جوانب النظام القائم على الوكلاء.

• بروتوكول سياق النموذج: يربط MCP الوكيلَ أساسًا بالأدوات ومصادر البيانات والموارد. أما A2A فيربط وكيلًا مستقلًا بوكيل آخر. ويوضح الدليل الرسمي لاستخدام A2A وMCP كيفية استخدام البروتوكولين معًا بدلًا من التعامل معهما على أنهما متنافسان. (a2a-protocol.org)
• مهارات الوكلاء: تجمع المهارة تعليمات وإجراءات قابلة لإعادة الاستخدام تساعد الوكيل على إنجاز أعمال متخصصة. وتعلن بطاقة الوكيل عن إمكاناته للتعاون عن بُعد، بينما توجّه مهارات الوكلاء من Ultralytics وكلاء البرمجة المتوافقين خلال تدفقات عمل الرؤية الحاسوبية الموثقة.
• تنسيق عمل وكلاء الذكاء الاصطناعي: يحدد التنسيق الوكيل الذي ينبغي أن يتصرف، والترتيب الذي يتبعه، والقيود التي يعمل ضمنها. ويوفر A2A طبقة الاتصال التي يمكن لمنسّق العمل استخدامها.
• استدعاء الدوال واستخدام الأدوات: يستدعي استدعاء الدالة عملية محددة. ويمكن لطلب A2A تفويض هدف أوسع يخطط الوكيل البعيد لإنجازه بشكل مستقل.

تطبيقات الذكاء الاصطناعي والرؤية الحاسوبية في العالم الحقيقي#

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

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

في تدفقات العمل هذه، يمكن للفرق استخدام منصة Ultralytics لتعليق مجموعات البيانات المرئية، وتدريب النماذج، ونشر نقاط نهاية الاستدلال، ومراقبة خدمة الإدراك التي يستدعيها الوكيل.

مثال على وكيل للرؤية الحاسوبية#

يمثل تدفق عمل التنبؤ باستخدام Ultralytics YOLO الموثق التالي خطوة الإدراك داخل وكيل رؤية بعيد:

from pathlib import Path

from ultralytics import YOLO

source = "https://ultralytics.com/images/bus.jpg"
output_path = Path("vision_artifact.jpg")

# ⁨إجراء التحليل المرئي للوكيل البعيد⁩
model = YOLO("yolo26n.pt")
results = model(source)

result = results[0]
result.save(filename=str(output_path))

print(output_path)

هنا، يُجري Ultralytics YOLO26 استدلالًا مرئيًا وينشئ صورة مشروحة. ويمكن لخادم A2A إعادة تلك الصورة بوصفها منتجًا، مع إرجاع عمليات الكشف القابلة للقراءة آليًا بشكل منفصل. وينقل البروتوكول النتيجة ويتتبعها؛ لكنه لا يحل محل نموذج الرؤية.

اعتبارات التصميم والأمان#

لا تجعل قابلية التشغيل البيني في A2A النظام متعدد الوكلاء آمنًا أو موثوقًا تلقائيًا. ينبغي للمطورين التحقق من بطاقات الوكلاء، ومصادقة كل جهة مستدعية، وتفويض الوصول لكل مهارة، والحد من الأذونات المفوضة، والتعامل مع المخرجات البعيدة بوصفها مدخلات غير موثوقة. وتوصي إرشادات تنفيذ A2A للمؤسسات باستخدام ضوابط الويب المعتمدة، مثل HTTPS والمصادقة المستندة إلى OAuth والتفويض وفق مبدأ الحد الأدنى من الامتيازات والتسجيل والتتبع وتقليل البيانات. (a2a-protocol.org)

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