على مدار العامين الماضيين، اتبعت هندسة الذكاء الاصطناعي سيناريو بسيطاً. امنح الوكيل (agent) أمراً (prompt)، وبعض الأدوات، وطبقة ذاكرة، ثم راقبه وهو يجدول اجتماعاً، أو يلخص عقداً، أو يصحح خطأً في نص برمجِيّ. كان الهدف بأكمله هو جعل الوكيل المنفرد مفيداً بمفرده.
لقد تغير هذا الهدف.
نحن نشهد الآن تحول الصناعة من الوكلاء المنفردين إلى فرق الوكلاء. يقوم بوت فرز خدمة العملاء بتحديد طلب استرداد أموال وتوجيه الحالة إلى وكيل مدفوعات. ويقوم وكيل بحث يقوم بكشط بيانات الويب (scraping) بمواجهة فجوة متخصصة، فيقوم بتفويض المهمة إلى متخصص يعمل على قاعدة بيانات مملوكة. ويحتاج وكيل لوجستي يخطط لشحنة إلى عرض سعر شحن فوري، فيطلب رقماً من وكيل تسعير.
يبدو هذا بسيطاً على الورق، لكنه في الممارسة العملية يتسم بالهشاشة.
التحدي الجديد هو التوافق التشغيلي (interoperability). تبني الفرق وكلاء باستخدام أطر عمل (frameworks) مختلفة. ويوفر موردون مختلفون وكلاء بواجهات مختلفة. وعندما تحتاج شركة ما إلى العمل مع شركة أخرى، تتسع الفجوة. لدينا الآن مشهد مليء بالعمال المهرة الذين يفتقرون إلى لغة مشتركة. لا يمكن للوكيل البحث عن وكيل آخر في دليل، ولا يمكنه قراءة وصف لما يفعله زميله، ولا يمكنه تسليم مهمة حساسة دون المخاطرة بتسرب البيانات، أو فقدان السياق، أو تكرار التنفيذ.
هذه هي بالضبط المشكلة التي صُمم A2A لحلها. فهو يمنح الوكلاء بروتوكولاً مشتركاً للاكتشاف، والتفويض، والتعاون الآمن.
من الوكلاء المنفردين إلى صوامع الوكلاء (Agent Silos)
تعاملت الموجة الأولى من أطر عمل الوكلاء مع حدود النظام على أنها حدود الوكيل. كنت تبني حلقة استدلال (reasoning loop)، وتزودها بحزام أدوات، وتأمل أن تتمكن من التفكير لإنجاز سير العمل. كان ذلك يعمل بشكل جيد بما يكفي عندما يظل الوكيل داخل قاعدة كود واحدة، أو حساب سحابي واحد، أو منصة مورد واحدة.
الشركات الحقيقية لا تعمل داخل أنظمة متجانسة (monoliths). قد يبدأ طلب استرداد الأموال في نظام إدارة علاقات العملاء (CRM)، ثم ينتقل إلى خدمة دفع داخلية مكتوبة بلغة Python، وينتهي بفحص احتيال تستضيفه جهة خارجية. عندما تقوم بنمذجة كل خدمة من هذه الخدمات كوكيل، ستدرك بسرعة أن الوكلاء المبنيين على مجموعات تقنية (stacks) مختلفة لا يفهمون بعضهم البعض بشكل طبيعي. كما أن وكلاء المؤسسات المبنيين على أطر عمل مملوكة لا يعلنون عن قدراتهم للعالم الخارجي.
بدون معيار موحد، يصبح كل تكامل مشروعاً مخصصاً. يكتب المهندسون "أكواد ربط" (glue code) لمرة واحدة فقط. ويضيع السياق أثناء عملية النقل. وتصبح السياسات الأمنية غير متسقة، لأن كل عملية تسليم تتم بشكل مخصص.
بطاقات الوكيل (Agent Cards): سيرة ذاتية عامة
يقدم A2A "بطاقات الوكيل" (Agent Cards) كوسيلة للوكلاء للإعلان عن هويتهم وما يمكنهم القيام به.
فكر في "بطاقة الوكيل" كسيرة ذاتية قابلة للقراءة آلياً. ينشر الوكيل بطاقة تصف مجاله، ومدخلاته المطلوبة، ومخرجاته المتوقعة، وأي قيود على العمل الذي يقبله. قد يعلن وكيل المدفوعات أنه يعالج طلبات استرداد الأموال التي تقل عن مبلغ معين عند تزويده بمعرف الطلب ورمز السبب، وأنه يعيد إما رقم تأكيد أو خطأ. وقد يذكر متخصص البيانات أنه يقبل ملفات منظمة حتى حجم معين ويعيد بيانات سلاسل زمنية (time-series data) نظيفة ضمن نافذة زمنية يمكن التنبؤ بها.
قبل تفويض العمل، يقرأ الوكيل الطالب البطاقة. فيفهم ما إذا كان الوكيل المستهدف قادراً على أداء المهمة أصلاً. ويتعرف على التنسيق الذي تحتاجه الحمولة (payload). ويعرف ما إذا كان يجب أن يتوقع استجابة متزامنة (synchronous) أو مهمة غير متزامنة (asynchronous) ستنتهي لاحقاً.
هذا يزيل التخمين. فبدلاً من كتابة تكاملات ثابتة (hardcoding) لكل شريك محتمل، يمكن للوكيل تصفح القدرات المتاحة واختيار الزميل المناسب ديناميكياً.
المهام: عمل منظم، وليس مجرد استدعاءات API
لا يحتاج الوكلاء إلى الدردشة مثل البشر، بل يحتاجون إلى تسليم المهام بسلاسة. ويقوم A2A بنمذجة هذا التبادل على أنه "مهمة" (Task).
المهمة هي أكثر من