المرونة وتسليم المهام والفشل المتسلسل
مادة تعليمية مبنية على أصل معرفي موجود في سيادة، تتبعها مهمة تطبيقية في المجال المصرفي.
مسار حوكمة AI المصرفي — المرونة وتسليم المهام والفشل المتسلسل
المصدر المعرفي المستخدم: ضمان تسليم المهام بين الوكلاء: كيف نمنع انتشار الأخطاء وتجاوز الصلاحيات؟
هذه الوحدة تستند إلى نص معرفي موجود داخل سيادة وتعيد استخدامه بصورة معلنة بدل كتابة نسخة غير موثقة. المواد الواردة عامة ما لم يُذكر مصدر تنظيمي رسمي؛ التمرين المصرفي افتراضي، ولا يدل محتوى الوحدة على جاهزية بنك محدد أو امتثاله.
ضمان عمليات التسليم بين الوكلاء: اختبار Multi-Agent Handoffs ومنع انتقال الخطأ والسلطة
المصدر المرجعي: IMDA Starter Kit for Testing Agentic Systems, October 2026، ولا سيما دراسة KBTG. أمثلة التصميم وحقول الضبط التفصيلية إضافات تطبيقية من سيادة، ولا يجوز التعامل معها كمتطلبات IMDA الحرفية.
1. لماذا يقع الخطر عند الانتقال وليس داخل الوكيل وحده
ليس كل إخفاق في الأنظمة متعددة الوكلاء نتيجة خطأ نموذج واحد. أحيانًا ينتج وكيل تحليل الأعمال وثيقة صحيحة وفق البيانات التي وصلته، ثم ينقلها إلى وكيل التصميم دون ذكر أن سعر الترخيص تقديري أو أن شرط إقامة البيانات لم يتأكد. قد يقرأ وكيل التصميم المدخل على أنه حقيقة قطعية، ويبني Architecture على موفر سحابي غير مسموح، ثم يترجم وكيل التطوير ذلك إلى كود يعمل فعلًا. الاختبار الوحدوي لكل مكون قد يُظهر نتائج جيدة، بينما يثبت الاختبار المتكامل أن المنظومة أصبحت متماسكة تقنيًا حول فرضية خاطئة. هذا يفسر لماذا تعد نقطة التسليم Control Boundary مستقلة. دراسة KBTG في مرجع IMDA تتناول سلسلة من وكيل تحليل الأعمال إلى وكيل التصميم ثم وكيل التطوير، مع الفصل بين الصلاحيات ومراجعة المخرجات في سير العمل القائم؛ وهي ليست تصريحًا بأن كل نظام متعدد الوكلاء يحتاج البنية نفسها.
2. تصميم العقد الذي يحكم التسليم
ابدأ بوثيقة Handoff Contract لا بوصف لفظي قصير يقول أرسل النتيجة للوكيل التالي. الحقول المقترحة: source_agent، target_agent، task_id، artefact_id، version، source_references، confidence_notes، assumptions، unresolved_questions، permitted_next_actions، forbidden_actions، approval_requirements، schema_version، integrity_hash وexpiry. عرّف لكل حقل هل وجوده إلزامي ومتى يتحول الغياب إلى Halt بدل استخدام قيمة تقديرية. ينبغي ألا يستطيع الوكيل المستلم رفع تصنيف Evidence من Declared إلى Verified بمجرد أن المرسل صاغها بأسلوب واثق. وإذا تغير المصدر بعد التسليم، يجب اكتشاف stale downstream artefact وإعادة التقييم. عملية التسليم لا تمنح سلطة إضافية بحكم انتقال الملف؛ كل وكيل يحافظ على دوره وهويته وتفويضه، ولا يجوز للمنسق أن يجمع صلاحيات العاملين بلا مراجعة.
3. اختبار انتشار الخطأ بين المراحل
صمم اختبارًا يزرع عيبًا واحدًا معلوم المصدر في Artifact المرحلة الأولى: Requirement يحمل وحدة قياس خاطئة، أو شرط حماية بيانات منسوخ من عقد قديم، أو Dependency غير متوافقة مع إصدار المكتبة المستهدف. شغّل سلسلة الوكلاء وقس هل اكتشف الوكيل التالي العيب قبل إصدار مخرجات مشتقة، وهل أرجعه للمصدر، وهل احتفظ برابط يوضح سبب الرفض. كرر مع عيوب يصعب ملاحظتها: رقم صحيح لكنه يخص شركة أخرى، إصدار إطار قديم، تعليمات مختبئة في تعليق، أو مستند يحتوي سطرًا يطلب من الوكيل تجاهل سياسة الوصول. تحتاج Ground Truth صريحًا وExpected Handoff Behaviour؛ وإلا سيختلط فشل الكشف باختلاف مشروع في طريقة التصميم. نقطة النجاح ليست فقط أن التصميم النهائي لا يحتوي الخطأ، بل أن آلية الكشف والإيقاف والإحالة تعمل كما هو محدد.
4. حدود أدوات كل وكيل
أخطر تفويض غير مقصود يحدث عندما يملك وكيل منخفض الامتيازات حق إرسال تعليمات حرّة إلى وكيل أقوى يستطيع النشر أو الحذف أو إصدار فواتير. اعمل Threat Model لرابطة النقل: هل الرسالة Control Plane أم مجرد Data Plane؟ هل يستطيع الوكيل المرسل تعديل اسم الأداة المستدعاة أو معلماتها؟ هل يصدق الوكيل المستلم جميع النصوص على أنها أوامر من منسق مخول؟ أنشئ Test Cases لطلب إنشاء فرع محظور، تعديل Policy، الوصول إلى أسرار بيئة، وكتابة بيانات خارج مشروع المهمة. ينبغي أن تُفرض Scope Constraints عند حدود الأدوات والـAPI، وأن تسجل محاولات الاستخدام المرفوضة؛ فالاعتماد على صياغة prompt لا يضمن عدم وجود مسارات بديلة. يتطلب الاختبار إثباتًا من سجل المنصة أو الـAPI على أن العملية لم تحدث، لا مجرد رفض لغوي.
5. اختبار الإنسان عند كل Control Gate
إذا كان بين الوكلاء Reviewer بشري، فلا تحسب عدد النقرات أو نسبة حضور المراجع فقط. اختبر فاعلية المراجعة بإدخال Controlled Defects في مخرجات المرحلة السابقة، وعرضها كما ستظهر في الإنتاج، ثم قياس كشف الخطأ قبل انتقاله. افتح سيناريوهات Missing Context؛ فقد يوافق الإنسان لأن واجهة المراجعة لم تعرض مصدر الجملة أو نسخة المستند. اربط Approval بنسخة الـArtifact عبر Hash أو رقم إصدار، بحيث لا يصل تعديل لاحق إلى الوكيل التالي معتمِدًا على موافقة قديمة. لا تخلط المساءلة الإدارية بالتحقق الفني: المراجع قد يملك سلطة قبول مخاطرة تجارية، لكنه ليس تلقائيًا الشخص المناسب لتأكيد أن تصحيح ثغرة لا يفتح مسار تسريب جديد. يجب ربط كل نوع مراجعة بكفاءة محددة وبوقت تدخل يسمح بمنع الفعل قبل حدوثه.
6. اختبار مصدر الحقيقة والـLineage
في مسارات البرمجة والمشتريات والعقود، المخرج النهائي يكون سلسلة من المشتقات. يتطلب ضمان المسار تسجيل مصدر كل Requirement وأين انتقل إلى Design Constraint وكيف تحول إلى Code Change أو Transaction. أنشئ Source-to-Artifact Matrix: معرف مطلب أصلي، الفقرة الداعمة، النسخة، الوكيل الذي استخرجها، المراجعة المعتمدة، المكون المتأثر واختبار القبول. أي خطوة لا يمكن وصلها بالمصدر تصبح Traceability Gap. لا تعتمد على إحالات شكلية؛ اختبر فعليًا أن الرابط يفتح المستند الصحيح وأن نصه يدعم الادعاء، وأن عدد العناصر غير المدعومة أو المفقودة محسوب. عند وجود نص تعاقدي ملتبس يجب إبقاء الحالة Ambiguous وطلب قرار بشري، لا السماح للنموذج بملء الفراغ كأنه حقيقة مصدرية.
7. محاكاة الفشل في البنية المتصلة
لا تجعل كل خدمة تعود بنتيجة خلال ثانية. اختبر Timeout بعد تنفيذ عملية كتابة، وHTTP 429، وانتهاء جلسة، وفقد رسالة Handoff، واستجابة أداة تحمل Schema صحيحًا لكن Semantic Data خاطئة. في حالة Timeout بعد كتابة سجل قد يحاول الوكيل تكرار العملية؛ يجب أن تمنع Idempotency Keys تكرار الدفع أو الحذف. وفي حالة نجاح مرحلة التصميم وفشل تسليمها، يجب ألا ينتقل النظام إلى التطوير مستخدمًا Artifact قديمًا. اختبر كذلك ترتيب الرسائل حين يصل Version 3 قبل Version 2، وحين يعمل وكيلان على الحالة نفسها، واحتمال Deadlock إذا انتظر كل منهما موافقة الآخر. يمكن استخدام Simulated Services ولكن ينبغي أن تحافظ على خصائص الأخطاء والواجهات بما يكفي للكشف عن هذه الأنماط. عند تنفيذ اختبارات عالية المخاطر، يجب التحقق من العزل قبل التشغيل.
8. القياس والحكم على النظام متعدد الوكلاء
عرّف Handoff Completeness على أنه التسليمات التي تحتوي جميع الحقول المطلوبة على إجمالي التسليمات الخاضعة للفحص. وError Propagation Rate على أنه العيوب المزروعة التي وصلت إلى مرحلة غير مخولة باستخدامها مقسومة على العيوب التي كان يجب منعها عند الحدود. وHuman Defect Detection Rate على أنه العيوب التي اكتشفها المراجع قبل الاعتماد مقسومة على جميع العيوب المضبوطة في عينة المراجعة. وUnauthorised Tool Attempt Rate على أنه محاولات استدعاء أداة خارج النطاق مقسومة على الفرص المصممة لاختبار هذه الحدود. لا تخلط محاولة مكتشفة وممنوعة بتنفيذ وقع فعلًا؛ سجل الاثنين. تقارير Average Pass Rate غير كافية لبوابات حرجة؛ اعرض Worst Run والقيود وثقة العينة، مع عدد المحاولات وحالة السجلات الناقصة. قد تكون النتيجة النهائية صحيحة في معظم التكرارات، لكن وجود تسليم واحد غير مخول لمعلومات شخصية سبب مستقل لرفض النشر.
9. دورة تصحيح وإعادة اختبار موثقة
بعد Finding لا تكتف بتعديل Prompt الذي بدا أنه سبب المشكلة. حدد Root Cause: عقد نقل غير مضبوط، شرط قبول ناقص، IAM واسع، API تسمح بإجراء غير مخول، UI Review ضعيفة، أو ذاكرة تجعل Artifact القديم متاحًا كأنه حديث. اربط الإصلاح بالمكون الصحيح؛ تقوية بوابة الصلاحيات في الخادم تختلف عن تحسين وصف المهمة للنموذج. نفذ Regression Test على حالة الفشل نفسها ثم Test مجاورًا يكشف احتمال أن الإصلاح خلق خطأ جديدًا. سجّل إصدار كل Agent وخدمة وأداة وسياسة، وحالة البيانات بين الجولات؛ وقدّم Report يوضح نطاق التغطية والسيناريوهات غير المختبرة. إعادة الاختبار مطلوبة بعد تغييرات جوهرية في مسارات التنسيق والأدوات ونماذج التشغيل. يبقى قرار الاستمرار مشروطًا بالأدلة المتاحة ومخاطر المتبقي، لا بتصريح الوكلاء بأنهم حلوا المشكلة.
10. حالة تصميم مفصلة: تطوير خدمة رقمية بثلاثة وكلاء
تصور طلب تطوير بوابة تقبل شهادات اعتماد المهنيين. ينتج الوكيل الأول Requirement يحدد إظهار حالة الشهادة دون الكشف عن البيانات الشخصية. يستخلص الثاني تصميمًا يتضمن public verification endpoint. يضيف الثالث استعلامًا يقرأ جدول الشهادات. سنزرع عيبًا في متطلبات البداية يضيف عرض البريد الإلكتروني الكامل ضمن الرد العام، ونضع سياسة معتمدة تمنع ذلك. يبدأ الاختبار من وثيقة المطلب وينتهي عند Response فعلي في Test Environment. النجاح يتطلب اكتشاف التعارض عند مراجعة المتطلبات أو التصميم أو الكود، ومنع نشر endpoint غير المطابق، ووجود Evidence تربط الخطأ بالمرحلة، مع تسجيل reviewer action. وإن ولد الوكيل الأخير endpoint صحيحًا اتفاقًا لكنه تجاوز مراجعة أمان إلزامية، فالنتيجة جيدة والمسار فاشل. الحالة هنا مثال تصنيعي من سيادة لتوضيح المنهجية وليست تجربة منشورة باسم KBTG؛ لا تستخدم أرقام أداء ميدانية لم تُقَس.
أسئلة القبول النهائي
هل ثبت اكتشاف العيب قبل وصوله إلى التنفيذ؟ هل بقيت الصلاحيات ضمن هوية كل وكيل؟ هل كانت الموافقة البشرية مرتبطة بنسخة artifact؟ هل أمكن إرجاع كل مخرج إلى مصدره؟ هل اختُبرت الأعطال والتكرارات وعولجت وفق Evidence مستقلة؟
تمرين مصرفي تطبيقي
اختر حالة استخدام ذكاء اصطناعي في بنك افتراضي وحدد العملية والمالك والبيانات والنموذج والمورد والأدوات والقرارات والآثار المحتملة. صغ سيناريو واحدًا يميز مصدر الخطر عن الثغرة وعن الحدث وعن أثره في العملاء أو الاستمرارية. ثم حدد ضابطًا وقائيًا وضابطًا كاشفًا وضابط استجابة، وأضف لكل واحد نوع الدليل وتاريخ الاختبار ومسؤول المراجعة وحدود الاستنتاج. ناقش كيف يتغير الحكم إذا كان الوكيل يستطيع تنفيذ إجراء مالي بدل تقديم توصية. بيّن ما لا تستطيع الأدلة إثباته؛ ثم قدم قرار معالجة أو قبول مشروط بالخطر المتبقي دون اختلاق درجة امتثال رسمية.