ما المقصود بدورة حياة تطوير الوكلاء (ADLC)؟

أدت قدرات وكلاء الذكاء الاصطناعي وانتشارهم -وهي أنظمة برمجية تستخدم النماذج اللغوية الكبيرة (LLMs) كمحرك لاتخاذ القرار من أجل تخطيط المهام وتنفيذها ذاتيًا لتحقيق هدف محدد- إلى إحداث تحول متسارع في مهام سير العمل داخل المؤسسات. وقد تجاوزت وتيرة هذا التحول قدرة العديد من المؤسسات على تكييف هياكل تكنولوجيا المعلومات التقليدية بما يتوافق مع المتطلبات الفريدة لدمج الذكاء الاصطناعي الوكيل، ما أدى إلى وجود منظومة عمل مجزأة. وتقدِّم ADLC مواصفات مشتركة وممارسات موحَّدة لتسهيل إنشاء أنظمة وكيلية موثوق بها عبر مختلف الأدوات والمنصات والمورِّدين وبيئات المؤسسات.

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

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

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

تدمج ADLC المبادئ الأساسية لمنهجية DevSecOps لربط تطوير وكلاء الذكاء الاصطناعي عبر سلسلة من المراحل المترابطة والمتداخلة إلى حد كبير. وسيتم لاحقًا في هذا المقال استكشاف الغرض من كل مرحلة وممارساتها، بالإضافة إلى العلاقات التي تربطها بالمراحل الأخرى. وتَرِد التفاصيل الكاملة والتوصيات والمواصفات في دليل IBM الرسمي حول دورة حياة تطوير الوكلاء (ADLC).

لا تتوافق بعض الافتراضات وأفضل الممارسات القياسية في دورة حياة تطوير البرمجيات (SDLC) التقليدية مع متطلبات بناء وكلاء الذكاء الاصطناعي. ولكي تنجح مبادرات وكلاء الذكاء الاصطناعي في المؤسسات، يجب على المؤسسات فهم الفروق الجوهرية بين البرمجيات التقليدية والأنظمة الوكيلة ومراعاتها.

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

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

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

ولعل الأهم من ذلك أن الأنظمة القائمة على الوكلاء والبرمجيات التقليدية تختلف جذريًا في أنماط الإخفاق.

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

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

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

ترسم دورة حياة تطوير الوكلاء (ADLC) عملية بناء وكلاء الذكاء الاصطناعي ونشرهم وتحسينهم وإدارتهم عبر مراحل متميزة، يندمج بعضها لتشكيل حلقات تكرارية.

• التخطيط (Plan): إشراك جميع الأطراف المعنية ذات الصلة للتوافق بشأن حالات الاستخدام والأهداف ومقاييس النجاح والنتائج التجارية المستهدفة (بما يدعم إعداد إطار للتقييم). وتحديد سلوك الوكيل المطلوب وإجراءات التشغيل القياسية وتوثيقها بلغة طبيعية.

• البرمجة والبناء (Code & Build): تطوير الوكلاء، وهو ما يشمل -من بين أمور أخرى- اختيار النموذج، وتصميم المطالبات، والتنسيق. وتحديد الخدمات الخارجية ذات الصلة -مثل الأدوات وقواعد البيانات وواجهات برمجة التطبيقات (APIs)- ودمجها ضمن طبقة مؤسسية باستخدام بروتوكول سياق النموذج (MCP). وفرض ممارسات مدروسة لإدارة الإصدارات، والعزل في بيئات اختبارية، وأنماط البوابات.

• الاختبار والإصدار (Test & Release): تنفيذ عمليات تقييم منظمة استنادًا إلى معايير مرجعية محددة مسبقًا، وفرض فحوصات الامتثال للسياسات، وإجراء اختبارات أمنية وتمارين الفريق الأحمر، واعتماد الوكلاء في كتالوج خاضع للحوكمة. وتكرار مرحلتَي البرمجة والبناء والاختبار والإصدار بصورة دورية حسب الحاجة.

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

• التشغيل (Operate): مراقبة الوكلاء المنشورين وتحسينهم باستمرار، مع تتبُّع المقاييس الفورية مثل الدقة وزمن الانتقال والتكلفة ورضا المستخدمين، والبقاء متيقظين لأي انحراف في النموذج أو تراجع في الأداء. واستخدام حلقات التعليقات هذه لتحسين المطالبات والأدوات والنماذج وسياسات الذاكرة من حيث الأداء والأمان، مع تكرار دورة النشر-التشغيل حسب الحاجة.

• المراقبة (Monitor): بعد التحقق الكامل من النظام وتحسينه، الاستمرار في مراقبته وإجراء عمليات تدقيق مستمرة لضمان العدالة والشفافية والامتثال للمتطلبات التنظيمية. والحفاظ على كتالوج مُحكَم الحوكمة للوكلاء والأدوات لتسهيل قابلية الملاحظة وقابلية إعادة إنتاج النتائج.

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

تبدأ عملية تطوير الوكلاء بمواءمة حالة الاستخدام، ومنها تنطلق جميع اعتبارات التخطيط الأخرى.

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

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

ومع ذلك، يظل القرار الأهم في مرحلة التخطيط هو تحديد إذا ما كان ينبغي بناء وكيل ذكاء اصطناعي من الأساس.

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

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

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

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

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

وقد أفرز التحليل المتعمق لتطبيقات الذكاء الاصطناعي الوكيل في المؤسسات أنماطًا محددة تحقق قيمة متسقة وتنطوي على مخاطر يمكن التحكم فيها، مثل العمليات المعتمدة بكثافة على المستندات، ودعم العملاء (أو خدمة العملاء)، والأعمال المعرفية القابلة للتوثيق. وتُعَد هذه المجالات نقاط انطلاق مثالية.

بمجرد اتفاق جميع الأطراف المعنية على الأهداف والمتطلبات والقيود ومعايير القياس، تنتقل الفِرق إلى عملية بناء وكلاء الذكاء الاصطناعي فعليًا، بما يشمل تنفيذ المطالبات، واستراتيجيات الذاكرة، ومنطق التنسيق، وأطر عمل التقييم.

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

وفي كل مرحلة من مراحل التطوير، يجب على الفِرق تطبيق سياسات صارمة لإدارة الإصدارات لكلٍّ من متغيّرات الوكلاء الفردية ومنطق التنسيق الذي يدير عملهم داخل نظام متعدد الوكلاء، متى كان ذلك مناسبًا.

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

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

ويمكن التعامل مع جميع عمليات التكامل -سواء أكانت مع بيانات المؤسسة أم تطبيقات الجهات الخارجية أم الأنظمة الخارجية- باعتبارها عمليات تكامل للأدوات يتم تفعيلها عبر خوادم MCP. ومن الأفضل أن تُتيح منصة هندسة الأنظمة القائمة على الوكلاء التي تعتمدها المؤسسة إمكانية تخصيص سلوك MCP بما يتوافق مع احتياجات حالة الاستخدام المحددة. كما يجب استخدام نمط MCP Gateway لتأمين جميع هذه الاتصالات وإخضاعها للحوكمة عبر الأنظمة الخلفية للمؤسسة.

وحيثما أمكن، يجب إعطاء الأولوية لقابلية إعادة الإنتاج والمعايير المفتوحة، مثل MCP للأدوات والموارد، وOpenTelemetry لقابلية الملاحظة، والمخططات القابلة لإعادة الاستخدام للمطالبات. وبالمثل، يجب اعتماد أنماط موحَّدة للتخزين والاسترجاع، والوصول إلى الأدوات، وتفويض المهام.

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

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

تُعَد آلية تحديد الوصول (Sandboxing) وممارسات الاحتواء الأخرى أمرًا أساسيًا للحد من المخاطر. ويجب أن تعمل بيئة تنفيذ الوكيل وإمكانية وصوله إلى الشبكة ونظام الملفات دائمًا وفق مبدأ الحد الأدنى من الامتيازات. ويجب منح كل عنصر في النظام القائم على الوكلاء الحد الأدنى فقط من الصلاحيات اللازمة لتنفيذ المهام الموكلة إليه.

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

ويجب اختبار وكلاء الذكاء الاصطناعي استنادًا إلى معايير مرجعية وفحوصات سياسات محددة مسبقًا تعكس السلوكيات المطلوبة وتفرضها بدقة. وقد يتطلب ذلك جمع أو إنشاء مجموعات بيانات حقيقة مرجعية (Ground Truth) توضِّح المسار الذي يجب على الوكيل اتباعه لكل نوع من المدخلات والمواقف. كما يجب استخدام كلٍ من أسلوب النموذج اللغوي الكبير ككقاض ( LLM-as-a-Judge) والمراجعات القائمة على إشراف بشري في العملية، ما يؤدي إلى تحقيق التوازن بين قابلية التوسع التي يوفرها الأول ومستوى الثقة الذي يوفره الثاني.

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

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

ويجب أن يشتمل إطار تقييم الأنظمة القائمة على الوكلاء على أنواع متعددة من المقاييس، من بينها ما يلي:

• مقاييس الجودة، مثل نسبة نجاح المهام والدقة ومعدل نجاح استدعاءات الأدوات.

• مقاييس الأمان، مثل عدد انتهاكات السياسات أو معدل تسرُّب البيانات الحساسة.

• مقاييس العمليات، مثل زمن الاستجابة واستهلاك الرموز المميزة والتكلفة لكل مهمة.

• مقاييس الأعمال، مثل درجات رضا المستخدمين أو التكلفة لكل نتيجة.

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

وبعد إخضاع وكلاء الذكاء الاصطناعي لاختبارات شاملة وتحسينهم والتحقق من أدائهم، يتم نشرهم بأمان داخل بيئات المؤسسات. ويجب النظر إلى مرحلة النشر على أنها عملية تفعيل متعمدة ومتدرجة استراتيجيًا، لا كإجراء واحد يشبه الضغط على زر أحمر كبير يحمل عبارة "DEPLOY". وتضمن ADLC سلامة النظام أثناء التشغيل من خلال آلية تحديد الوصول (Sandboxing) وإدارة الإصدارات واستراتيجيات التراجع وآليات الحماية الاحتياطية.

كما يجب تنفيذ نشر وكلاء الذكاء الاصطناعي تدريجيًا للحد من المخاطر. ويجب دراسة استراتيجيات النشر المختلفة، مثل النشر الأزرق-الأخضر (Blue-Green) أو النشر المتدرج (Rolling) أو النشر الكناري (Canary)، لتحديد الأنسب لأنماط حركة الاستخدام لديكم.وفي بيئة مؤسسية حية وواقعية، يجب أن يظل الاستقرار أولوية قصوى؛ إذ يُتيح تقسيم عملية النشر بعناية إلى مراحل متعددة التحقق من قدرة النظام على تحمُّل التحديثات المهمة.

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

وتشمل الأساليب الشائعة لتطبيق آلية تحديد الوصول ما يلي:

• المحاكاة الافتراضية خفيفة الوزن.

• ملفات تعريف أمان الحاويات.

• ضوابط الشبكات (عادةً من خلال MCP Gateway).

• سياسات الوصول إلى نظام الملفات.

• فرض السياسات على مستوى البوابة.

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

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

تُعَد قابلية الملاحظة للواجهة الأمامية والخلفية للتطبيقات عنصرًا أساسيًا للأنظمة القائمة على الوكلاء التي لا تقتصر على تحقيق مستويات مثالية من الأداء والأمان والموثوقية، بل تستطيع أيضًا الحفاظ عليها بمرور الوقت.

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

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

ولتلبية الاحتياجات الحالية والمستقبلية، يجب على المؤسسات إدارة كتالوج منظم بوضوح للوكلاء والأدوات يتضمن ما يلي:

• الملكية (Ownership)، لتسهيل المساءلة وتصعيد المشكلات.

• الإصدارات (Versions)، لدعم ممارسات منضبطة لإدارة التغييرات.

• مستوى المخاطر (Risk Posture)، لدعم اتخاذ القرارات.

• جميع البيئات ذات الصلة، للحفاظ على رقابة تشغيلية شاملة.

• قابلية التدقيق (Auditability)، لتسريع جمع الأدلة وإجراء التقييمات والحصول على الموافقات وتنفيذ تمارين الفريق الأحمر.