AWS تشرح بنية مراقبة من طبقتين لأنظمة الوكلاء في الإنتاج

نشرت AWS مقالة تقنية تقول فيها إن أنظمة الوكلاء المتعددة (Multi-agent) في بيئات الإنتاج تتعطل بطرق لا ترصدها المراقبة التقليدية. ومن الأمثلة المذكورة أن الوكيل قد يعجز عن استدعاء النموذج الأساسي (FM) ويعيد استجابة فارغة بسبب صلاحية ناقصة في IAM ضمن دور التنفيذ، من دون أن يظهر خطأ 500. وفي مثال آخر، يوجّه وكيل مشرف بمطالبة سيئة الصياغة 20 بالمئة من الطلبات إلى وكيل متخصص غير مقصود، بينما تبقى مؤشرات البنية التحتية خضراء ومعدلات الأخطاء ثابتة.

سؤالان وطبقتان

تجيب البنية عن سؤالين: هل يعمل الوكيل جيداً؟ وهل البنية التحتية سليمة؟ يقيّم Amazon Bedrock AgentCore Evaluations التفاعلات الحية على أساس الإفادة والصحة وإنجاز المهمة، ويأخذ عينة بنسبة قابلة للضبط من طلبات الإنتاج ويقيّمها في الخلفية. وتأتي كل درجة مصحوبة بتفسير يستند إلى سياق المحادثة والأدوات المستخدمة ومتطلبات المهمة. وعند تراجع الجودة يجري تحليل أنماط عبر الجلسات منخفضة الدرجات، ثم يقدّم توصيات محددة: تعديل المطالبة أو اختيار الأدوات أو منطق التنسيق.

أما AWS DevOps Agent فيراقب المقاييس والسجلات وأنماط الأخطاء. وعند حدوث عطل يسحب سجلات Amazon CloudWatch ذات الصلة، ويبني رسماً طوبولوجياً للموارد المتأثرة، ويربط الأخطاء بين IAM وAmazon Bedrock وبيئة تشغيل الوكيل، ثم يتتبع مسار الفشل ويقدّم توصيات إصلاح، مثل ربط استجابة فارغة بصلاحية IAM ناقصة، أو ارتفاع مهلات الانتظار بتقييد في منطقة معينة.

نظام حجز الطيران

ولعرض البنية كاملة، بنت AWS نظام حجز طيران بأربعة وكلاء متخصصين وفق نمط Swarm. ويتضمن الطلب النموذجي البحث في مسارين ضمن دورة محادثة واحدة، وجلب حالة الولاء وشهادة المرافق من مصدر بيانات آخر، وترتيب الحجوزات، إذ لا يمكن تطبيق الشهادة قبل اختيار الرحلة ومعرفة فئة الأجرة.

التفاصيل في مدونة AWS.