AWS تربط ثلاثة وكلاء ذكاء اصطناعي في حسابين عبر بروتوكول A2A

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

نشرت AWS مثالًا على هذا الربط عبر Agent-to-Agent، أو A2A. يعمل فيه ثلاثة وكلاء في حسابين على AWS، ويتبادلون المهام ويطلب كل منهم من الآخر السياق. تكمن القيمة العملية للمادة في مخطط محدد للتفاعل بين الشركات: أطر عمل مختلفة، وأنظمة هوية منفصلة، واستدعاء عكسي إلى العميل.

كيف يعرف الوكيل الخارجي قواعد الشركة

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

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

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

في العرض التجريبي، بيانات المخالفات اصطناعية. ويصف المؤلفون الربط الفعلي بـ AWS Config وSecurity Hub وGuardDuty بأنه الخطوة التالية لنظام إنتاجي. لذلك يُظهر المثال تنظيم التفاعل، لكنه لا يثبت جودة التدقيق الأمني الآلي.

ما الذي يوحّده A2A تحديدًا

عند التشغيل، يحمّل المنسّق بطاقة الوكيل (Agent Card) الخاصة بالوكيل الخارجي، وهي وصف لقدراته. وبناءً على المهارات المنشورة ينشئ أدوات LangChain، ويختار النموذج الأداة المناسبة وفقًا لسؤال المستخدم. ولا حاجة في هذا المخطط إلى تحديد مسار منفصل لكل سؤال.

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

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

وفي هذه البنية يؤدي A2A دورًا منفصلًا عن MCP. فعبر MCP يمكن للوكيل ربط أدواته ومصادر بياناته الخاصة، وعبر A2A يمرر العمل إلى وكيل آخر. ويمكن للخدمة الواحدة استخدام البروتوكولين معًا: MCP في الداخل وA2A للتفاعل مع العميل.

أين ينتهي المثال الجاهز

يستخدم كل طرف مجموعة مستخدمين خاصة به في Amazon Cognito. وعند الربط تتبادل الشركات معاملات عامة: العناوين ومعرّفات العملاء ونطاقات الوصول. ولا تُنقل الأسرار بينهما، مع أن لدى كل طرف داخليًا أسرارًا للحصول على الرموز تُخزَّن في Secrets Manager.

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

يتوزع النشر على ثلاثة دفاتر Jupyter. وتبلغ تقديرات المؤلفين لمدة المراحل نحو 3 و5 و20 دقيقة؛ وسيتطلب إعداد الحسابات والصلاحيات وقتًا إضافيًا. والبنية التحتية مدفوعة، وبعض الموارد تعمل بشكل دائم، ومنها بوابة NAT ومهام Fargate وموازن الأحمال.

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