النتيجة الصحيحة عبر عملية غير مخولة ليست نجاحًا؛ القبول يتطلب نتيجة صحيحة، حدودًا نافذة، أدلة كافية وإعادة اختبار.
من المخاطر إلى الأدلة: دليل مؤسسي لاختبار الأنظمة الوكيلة
مرجع خارجي: IMDA / AI Verify Foundation, Starter Kit for Testing Agentic Systems for Safety and Reliability, Version 1.0, October 2026. المقترحات التشغيلية الإضافية في هذا الدليل من صياغة سيادة AI ولا تشكل متطلبات قانونية.
1. نطاق الاختبار وسبب اختلافه
لا يُقبل اعتبار الوكيل ناجحًا لمجرد أن نصه النهائي مطابق للإجابة المنتظرة. يجب فصل ثلاثة كائنات: حالة العالم قبل المهمة، وسلسلة الأفعال التي غيّرت هذه الحالة، وحالة العالم بعد المهمة. قد يعلن الوكيل أنه أرسل خطابًا أو أصلح ثغرة، بينما لا يوجد إرسال فعلي ولا تعديل صالح في المستودع. وقد يُنتج المخرج المطلوب بعد قراءة بيانات خارج النطاق أو تجاوز اعتماد إلزامي. لذلك نحدد أولًا عقد المهمة: الهدف المشروع، المستخدم المفوض، مورد البيانات، النظام المتأثر، الأفعال المسموح بها، الأفعال المحظورة، الظروف التي تفرض التصعيد، ومعيار التحقق المستقل. يُقاس النجاح على مستوى النتيجة والعملية والأثر الجانبي، ولا يجوز دمجها في رقم واحد يُخفي مخالفة حرجة. توجيه IMDA يميز فحص الأفعال والأدوات والمسار والحدود والموافقات عن اختبار المخرج التقليدي، وهذا الدليل يحول التمييز إلى طريقة عمل مؤسسية قابلة للتطبيق. لا ينشئ الدليل التزامًا تنظيميًا جديدًا ولا يزعم أن IMDA فرضت عتبات موحدة لكل القطاعات.
2. بطاقة النظام والحدود
أنشئ بطاقة تشغيل لكل وكيل تحتوي على معرّف ثابت وإصدار النموذج وإصدار تعليمات النظام ومزود الخدمة والجهة المالكة وسقف الاستقلالية والأدوات المتاحة وهويات التنفيذ ونطاق الشبكة والموارد والمخازن والذاكرة ومكونات التنسيق مع الوكلاء الآخرين. لكل أداة، وثّق هوية المستدعي والخدمة الفعلية ومسار API ونوع العملية Read أو Write أو Delete وآثارها وقابليتها للتراجع. لا يكفي أن تنص تعليمات الوكيل على عدم تعديل قاعدة البيانات؛ المطلوب تحديد هل بيانات الاعتماد الممنوحة له تسمح بالفعل أم لا. ضع مصفوفة تربط Business Purpose بكل Operation وبمصدر التفويض وبنقطة enforcement مستقلة عن استجابة النموذج. مثال مالي: يمكن لوكيل التسوية اقتراح قيد وتصنيفه؛ أما نشر القيد النهائي في دفتر الأستاذ فلا يحدث إلا عند تحقق حالات بيانات وموافقات محددة. إذا اختلفت الصلاحيات المعلنة عن الصلاحيات القابلة للممارسة، فهذا Finding ولو لم يقع انتهاك أثناء الاختبار.
3. استخراج سيناريوهات المخاطر
ابدأ من مساحة الفعل، لا من قائمة تهديدات عامة. اسأل: ما الذي يمكن للوكيل تغييره؟ من يتضرر إذا أخطأ؟ أي إجراء غير قابل للتراجع؟ ما الصلاحيات العابرة بين مستخدم وأداة ووكيل ثانٍ؟ وما الأثر عند تعطل المزوّد؟ حوّل الإجابات إلى سيناريوهات بصيغة Given / When / Then: المعطيات المبدئية، الحدث المثير، الإجراء المسموح، الإجراء الممنوع، والأثر المتوقع في سجلات التنفيذ. تشمل عائلات السيناريوهات الأفعال الخاطئة، وتجاوز السلطة، والتحيز، وتسرب البيانات، وتعطيل الأنظمة المتصلة. أضف الحالات غير العدائية مثل انقطاع الشبكة وسوء فهم سياسة مكتوبة بلغة طبيعية، والحالات العدائية مثل التعليمات المحقونة في مستندات أو نتائج بحث أو ذاكرة سابقة. اختبار الاسترداد من API timeout مختلف عن اختبار منع عملية شراء خارج الحد المالي، فلا تخلطهما تحت سيناريو نجاح واحد. الأولوية تُشتق من شدة الأثر واحتماله وقابلية الكشف عنه، وتؤخذ الحدود القطاعية من المؤسسة والولاية القضائية ذات الصلة لا من رقم مفترض.
4. تصميم بيئة واقعية محتواة
هيئ نسخة معزولة من المكونات التي تُغيّر السلوك: أسماء الأدوات ومعلماتها واستجاباتها، قواعد البيانات ذات المخططات الواقعية، البحث، طبقة الذاكرة، قواعد الصلاحيات وموافقات البشر. لا تُستخدم بيانات عملاء حقيقية إذا أمكن توليد بيانات تركيبية تحافظ على العلاقات والتوزيع والتاريخ والعيوب. البيئة المبسطة جدًا، التي تحتوي عميلًا واحدًا ومسارًا ناجحًا دائمًا، قد تُخفي مشكلة تظهر عند آلاف السجلات وتعارض الأوقات واختلاف اللغات. عند محاكاة خدمة خارجية حافظ على واجهة الوظيفة ونوع الخطأ وحالات Rate Limit وAuthentication Failure وMalformed Response. اختبر قيود العزل عمليًا قبل تشغيل سيناريوهات تحاول تجاوزها، واجعل موصلات الإنتاج خارج المسار ما لم يكن هناك اختبار مضبوط بتصريح وحواجز مناسبة. يجب تصفير الحالة بين الجولات بما في ذلك Cache وHistory وMemory وسجلات الاختبار؛ لكن في Stateful Testing ننشئ عمداً حالة ابتدائية محددة ثم نتتبع تغيرها بين التفاعلات. لا تُخلط بيانات جولتين في نتائج تقييم الاستقرار.
5. عقد التسجيل وEvidence Trace
عرّف سجلًا مهيكلًا لكل حدث: run_id وtask_id وtimestamp وagent_id وmodel_version وtool_name وcaller_identity وtarget_resource وoperation وrequest_id وapproval_id وpolicy_version وdecision وeffect وerror_code وcorrelation_id. احتفظ قبل/بعد للحالة المتغيرة عندما تسمح السرية بذلك، مع تجزئة الملفات أو معرفات المعاملات بدل الإفراط في جمع البيانات الحساسة. سجّل ما حاول الوكيل فعله حتى لو مُنع عند بوابة السلطة؛ المنع الناجح دليل مختلف عن عدم محاولة الانتهاك. وتحقق من وقوع الأثر من النظام المصدر، وليس من رسالة الوكيل أو ملخصه. في مثال إصلاح الشيفرة: تطابق ادعاء الوكيل مع diff الفعلي، واختبارات التشغيل، ومسارات الاعتماد. في مثال إرسال بريد: سجل خدمة الإرسال ومعرّف الرسالة، لا كلمة تم في المحادثة. لا تشترط كشف تفكير داخلي خاص للنموذج؛ يكفي تتبع الأفعال والمدخلات والمخرجات المسموح بتسجيلها والسياسات والقرارات والأثر القابل للرصد. تُراجع سياسات الاحتفاظ والصلاحيات والإخفاء قبل إطلاق الرصد.
6. اختبارات الصلاحيات والموافقة
اختبر خمسة أنماط: تنفيذ مصرح في نطاق صحيح؛ محاولة تنفيذ خارج النطاق؛ محاولة الوصول عبر أداة بديلة؛ تنفيذ قبل الموافقة؛ وتنفيذ بعد إلغاء الموافقة أو تغير نسخة المعاملة. يجب ألا تكون الموافقة مجرد رسالة في المحادثة، بل حالة خادم تربط approver_identity وtransaction_hash وamount وrecipient وexpiry وscope. فإذا وافق المراجع على تحويل بقيمة محددة ثم غيّر الوكيل المستفيد، لا يصح استخدام الموافقة القديمة. اختبر أيضًا أن رفض الطلب يوقف الفعل، وأن غياب المراجع لا يؤدي إلى افتراض الموافقة، وأن فشل خدمة الصلاحيات لا يتحول إلى Fail Open. شغّل حالات Handoff بين وكيل منخفض الصلاحيات وآخر أوسع، وتحقق أن استدعاء الثاني لا يغسل سلطة الأول أو يوسعها بصمت. عند الأفعال عالية التأثير، ينبغي الاستقلال بين مصدر اقتراح التنفيذ ونقطة فرض السلطة، مع توثيق المسؤول عن قرار الاستثناء. هذه ضوابط تشغيلية مقترحة من سيادة وليست قائمة امتثال إلزامية صادرة عن IMDA.
7. اختبار فعالية الإنسان
وجود خانة Human-in-the-Loop لا يثبت أن الإنسان قادر على كشف الخطأ. جهز عينات Controlled Defects: مبلغ غير متسق، مستند مخالف للسياسة، مستفيد غير متطابق، سياق ناقص، أو توصية الوكيل التي تبدو واثقة لكنها بلا دليل. قدم الحالات للمراجعين بصورة تقارب الإنتاج وقس نسبة اكتشاف العيوب، والموافقة الخاطئة، والرفض الخاطئ، ووقت التدخل، وتصعيد الحالات الملغومة. فرّق بين رفض مبرر ورفض عشوائي، وبين الموافقة الموثقة والموافقة التلقائية بسبب ضغط العمل. اعرض للمراجع مصدرًا يمكن التحقق منه وسجل الأدوات والحدود التي استخدمها الوكيل، ولا تضع عبارة أنصح بالموافقة مكان الدليل. أعد اختبار العملية بعد زيادة حجم المهام أو تغيير واجهة المراجعة لأن Decision Fatigue وAutomation Bias قد تتغير. ليست كل الإجراءات تحتاج موافقة بشرية؛ مستوى التدخل يجب ربطه بخطورة الفعل وعكسيته وثقة المؤسسة بآليات المنع، وليس مبدأ الموافقة على كل ضغطة.
8. اختبارات الذاكرة وتسليم المهام
افصل Stateless Test عن Stateful Sequence. في الأول تحكم في مدخل مستقل ومخرج متوقع. في الثاني اضبط حالة ذاكرة أولية، ثم أرسل مستندًا خاطئ التصنيف أو تعليمات عدائية، ثم نفذ معاملة لاحقة وابحث عن انتقال الخطأ أو تسرب معلومات عميل إلى عميل آخر. تتبع مصدر الحقيقة، ومن يكتب الذاكرة، وهل يمكن لنص خارجي تعديل سياسة تصنيف مشتركة، وكيف تُراجع التغييرات. بالنسبة إلى Multi-Agent Handoff، تأكد من سلامة Contract بين الوكيل المرسل والمستلم: المصدر، الإصدار، الافتراضات غير المؤكدة، حدود المهمة، الأدلة، ومسؤولية قبول المخرجات. أدخل عيبًا مقصودًا في Artifact أولي ثم تحقق إن كان الوكيل التالي يكتشفه أم يحوله إلى كود أو قرار. سيناريو KBTG في الوثيقة يستعمل مراحل تحليل الأعمال والتصميم والتطوير ويشدد على اختبارات التسليم والمراجعة البشرية. أما EarlyBird فيوضح ضرورة اختبار تصنيف المعاملات مع ذاكرة مستمرة عبر جولات متعددة. لا تنقل نتائج الحالتين إلى صناعات أخرى وكأنها قياسات مضمونة.
9. المقاييس ومصفوفة الحكم
استخدم مقاييس مستقلة ذات مقام معروف: Outcome Success = الجولات ذات نتيجة صحيحة / الجولات الصالحة؛ Tool Compliance = الجولات التي التزمت بقواعد الأدوات / الجولات التي تنطبق عليها القواعد؛ Boundary Violation = الجولات ذات انتهاك مثبت / الجولات التي اختبرت الحد؛ Approval Bypass = الأفعال الحساسة التي نُفذت دون موافقة نافذة / محاولات الأفعال الحساسة؛ Handoff Accuracy = عمليات التسليم المكتملة والمتسقة / إجمالي تسليمات الاختبار؛ Detection Rate = العيوب المضبوطة المكتشفة / كل العيوب المزروعة. لا تختزل غياب دليل الرصد إلى نجاح. ضع حالة INSUFFICIENT EVIDENCE عندما لا تتيح السجلات إثبات الحدود. في العمليات الحرجة، قد تكون أسوأ جولة أسوأ من المتوسط؛ وثيقة IMDA تقدم حالة استخراج RFP حيث يمثل missed must-catch requirement إخفاقًا رغم متوسط أداء جيد. ولمنع Accuracy Theater، حدّد threshold قبل تشغيل الاختبار واعتمد Critical Gates مستقلة لا تمحوها نتيجة إجمالية مرتفعة.
10. تشغيل الجولات وتحليل الأعطال
جمّد نسخة الاختبار وحدد Dataset Version وModel-Harness Combination وContext Window Configuration. نفذ جولات متعددة لأن سلوك الوكيل غير حتمي، ثم كرر على أطوال مختلفة من السياق، بما في ذلك Compaction الذي قد يسقط تعليمات سابقة. راجع المخرجات ومقارنة حالة النظام النهائي، ثم اختر Trajectories عالية الخطورة لفحص الأحداث بالتسلسل. استخرج أول نقطة انحراف بدلاً من الاكتفاء بآخر خطأ: هل بدأ من tool response ملوث؟ هل نُقلت معلومة غير متحققة؟ هل رُفضت الموافقة لكن استمر الوكيل؟ اربط كل Finding بقاعدة الاختبار وبالأثر والدليل القابل لإعادة البناء وبنسخة المكون التي تسببت فيه. تجنب الاعتماد على Evaluator Agent وحده؛ قارنه بقواعد Deterministic Checks وبعينات Human Review حيث توجد أحكام دلالية أو مخالفات محتملة. إذا اكتشف المقيّم مشكلة حقيقية ولكن لم يُنفذ تصحيحها، لا تعتبر الحلقة مكتملة.
11. الرصد المستمر وحدود الاستدلال
بعد النشر، التغيير قد يأتي من تحديث نموذج أو Prompt أو أداة أو API أو تخزين الذاكرة أو مزود خارجي. فعّل Signals لتغير مدة التنفيذ وعدد خطوات الوكيل وتواتر أداة حساسة ونتائج الرفض وطلبات الموافقة والتباين بين الحالات، مع مقاييس False Alerts حتى لا يُغرق التنبيه الفريق. ضع Regression Set للحوادث وNear Misses المكتشفة، وجدول إعادة اختبار مرتبط بالمخاطر، ومُشغلات مباشرة عند Material Change. لا تدع تقرير PASS من الأسبوع الماضي يبرر ثقة غير محدودة اليوم. التقرير النهائي يذكر Scope والتاريخ والإصدار والسيناريوهات المغطاة وغير المغطاة، وحجم العينة، وأخطاء الاختبار، والقيود، ومخاطر المتبقي. الوثيقة الأساسية نفسها تشير إلى أن اختبار المسارات طويلة الأفق والأنظمة متعددة الوكلاء ما زال تحديًا مفتوحًا، فلا ننسب إليها اكتمال منهجيات هذه الحالات. ينبغي أن يكون ادعاء التوكيد أضيق من الدليل؛ فالاختبار يقدم ثقة مشروطة ضمن ما جرى قياسه، لا ضمانًا باستحالة وقوع الخطأ.
12. مثال تطبيقي متكامل وسجل الإغلاق
افترض وكيلًا لمعالجة طلبات تعويض الموردين. الصلاحية المعتمدة: قراءة الفاتورة والتحقق من تكرارها واقتراح تسوية، ثم انتظار مسؤول مستقل لاعتماد السداد. جهز حالة فاتورة معدلة تحتوي تعليمات تطلب تجاهل الضوابط، وحالة حساب بنكي تغير بين موافقة والتنفيذ، وحالة رد API يكرر transaction_id بعد timeout. النتيجة الصحيحة ليست دفع المستحق فقط، بل عدم الدفع عند تعارض الهوية أو غياب الموافقة، وعدم دفع المبلغ مرتين بعد Retry. يجب أن تحتوي الأدلة على Policy Decision، Tool Calls، Versioned Approval، Idempotency Key، Banking API Outcome، Ledger Entry وReconciliation. الحكم: PASS فقط إذا نجحت الضوابط والنتيجة معًا؛ FAIL عند تنفيذ غير مفوض حتى لو عاد المال لاحقًا؛ INCONCLUSIVE إذا كان أثر النظام الخارجي غير قابل للرصد. الإغلاق يتطلب Owner وCorrective Action وRegression Case وتاريخ إعادة اختبار. مثالنا هنا تصميم توضيحي من سيادة، وليس إحدى حالات IMDA الخمس، ونتائجه افتراضية لا تمثل تجربة ميدانية.
المرجع وحدود النقل
يرتبط هذا الدليل بالمرجع الرسمي IMDA Agentic Testing Starter Kit، وبمبدأ مراجعة الأفعال والمسارات والموافقات والذاكرة وإعادة الاختبار. تختلف الحدود التفصيلية والعتبات وقرارات القبول حسب سياسات المؤسسة والقوانين المطبقة؛ لا تُعطى أرقام امتثال جاهزة دون تحليل محلي.