AWS تقترح بنية من سبع طبقات لوكلاء الذكاء الاصطناعي: من النموذج الأولي إلى الإنتاج

يبدو النموذج الأولي للوكيل مقنعًا في الغالب. فهو يجيب عن الأسئلة، ويستدعي الأدوات، ويبدو رائعًا في العرض التجريبي. ثم تأتي حركة المرور الحقيقية، وفاتورة الرموز (التوكنات)، وتدقيق فريق الأمان، فيتعثر المشروع. وبحسب AWS، نادرًا ما يكون النموذج هو السبب. السبب هو البنية المحيطة التي تكتبها كل فريق من الصفر، وغالبًا بعد الإطلاق لا قبله.

نشرت مدونة AWS Machine Learning تحليلًا لإطار Pluggable Agentic AI Framework. وهو بنية مرجعية للتطبيقات متعددة الوكلاء تتألف من سبع طبقات. لكل طبقة مجال مسؤوليتها وعقد مستقر مع الطبقات المجاورة. أما الخدمات المحددة في المخطط فهي مجرد مثال على التنفيذ، وليست خيارًا إلزاميًا.

سبع طبقات بلا سحر

الطبقة الأولى هي البيانات والمعرفة. تستقبل الطلب وتعيد السياق المناسب للوكيل. وفي المثال تُستخدم Bedrock Knowledge Base وOpenSearch Serverless وS3 Vectors وDynamoDB.

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

الطبقة الثالثة هي التنسيق. للمهمة البسيطة يكفي وكيل واحد. أما للسيناريوهات المعقدة العابرة للمجالات فيلزم مشرف (supervisor) ومتخصصون محددون، لكل منهم مجموعة أدواته. أما الوكيل العام الواحد فيتراكم عليه مع الوقت المزيد من التعليمات والأدوات، فيتضخم السياق وتزداد التأخيرات وتنخفض الدقة. يُسجَّل المتخصصون في سجل موحد، ويعثر عليهم المشرف ويستدعيهم عبر بروتوكولي MCP وA2A القياسيين. والسجل الذي يصف أدوات كل وكيل ومهاراته ومالكه ضروري أيضًا للحوكمة (governance) ولتفادي كتابة الشيء نفسه مرتين.

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

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

الطبقة السادسة هي قابلية المراقبة. التتبع الشامل، والتكلفة والرموز لكل طلب، والزمن حتى أول رمز، ولوحات متابعة التأخير والأخطاء، كلها مطلوبة قبل الإطلاق لا بعد أول حادثة. والطبقة السابعة هي العمليات: تقييم مستمر لكل جلسة إنتاجية من حيث الاستناد إلى المصادر والدقة والأمان. إضافة إلى بوابة انحدار (regression gate) تمنع وصول إصدار تراجعت جودته إلى العملاء.

كيف يبدو ذلك في مثال

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

ما الذي يمكن استخلاصه

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

وينبغي أيضًا الانتباه إلى القيود. المقالة كتبها مزوّد، وهي موجهة إلى منظومة AWS: AgentCore وBedrock وCloudWatch. إمكانية استبدال المكونات معلنة، لكن التحقق منها على بنيتكم التحتية سيكون عليكم. ويشير المؤلفون أنفسهم إلى أن المثال لا يغني عن التقوية الأمنية والاختبار والمراجعة.

الخلاصة العملية بسيطة. حتى لو لم تستخدموا AWS، فإن قائمة الطبقات السبع تعمل كقائمة مراجعة للتخطيط. هل لديكم سجل للوكلاء؟ هل تُفحص الصلاحيات قبل استدعاء الأداة أم بعده؟ هل تستطيعون إثبات أن الوكيل يعمل بالجودة نفسها كما في يوم الإطلاق؟ إذا كانت الإجابة «لا» عن سؤال واحد على الأقل، فقد وجدتم الموضع الذي قد يتعثر فيه مشروعكم بين النموذج الأولي والإنتاج.