ما هذا المرجع؟
أصدر Infocomm Media Development Authority (IMDA) بالتعاون مع AI Verify Foundation الإصدار الأول من Starter Kit for Testing Agentic Systems for Safety and Reliability في أكتوبر 2026. وظيفة هذا المرجع ليست تقديم قانون جديد أو معيار إلزامي، بل تحويل جزء مهم من حوكمة الذكاء الاصطناعي الوكيلي إلى ممارسة اختبار قابلة للتنفيذ داخل المؤسسات. يركز الدليل على السلامة والموثوقية، ويشرح كيف تختلف عملية اختبار الأنظمة الوكيلة عن اختبار تطبيقات النماذج اللغوية التقليدية، لأن الوكيل لا ينتج نصًا فقط؛ بل قد يخطط، يستخدم أدوات، يقرأ ويكتب في أنظمة خارجية، يحتفظ بذاكرة، ينسق مع وكلاء آخرين، يطلب موافقة بشرية، وينفذ سلسلة أفعال عبر زمن أطول.
القيمة العملية للدليل تظهر في انتقاله من سؤال ضيق مثل: «هل أعطى النموذج إجابة جيدة؟» إلى سؤال أوسع: هل تصرف النظام الوكيلي بطريقة صحيحة ومصرح بها وقابلة للتتبع خلال كامل مسار التنفيذ؟ هذا الفرق جوهري للمؤسسات؛ فقد يصل الوكيل إلى نتيجة تبدو صحيحة بينما يكون قد استخدم أداة غير مسموحة، تجاوز حدًا تشغيليًا، قرأ بيانات لم يكن ينبغي أن يراها، أخفق في طلب موافقة بشرية، أو نقل خطأ من وكيل إلى آخر. لذلك لا يعتبر الدليل النتيجة النهائية وحدها دليلًا كافيًا على موثوقية النظام.
لماذا يختلف اختبار Agentic AI؟
تظل مبادئ اختبار البرمجيات وتطبيقات LLM مهمة: اختبارات الوحدة والتكامل، بيانات اختبار ممثلة، مقاييس واضحة، ومقارنة النتائج بمعايير متفق عليها. لكن الأنظمة الوكيلة تضيف عدة طبقات جديدة. أولها الأفعال؛ فالوكيل قد ينفذ أمرًا أو يحدث قاعدة بيانات أو يفتح طلبًا أو يرسل رسالة أو يشغّل أداة. ثانيها مسار التنفيذ أو Agent Trajectory؛ أي السلسلة التي مر بها النظام من الهدف الأول حتى النتيجة. ثالثها الحدود؛ هل ظل الوكيل داخل الصلاحيات والقيود؟ رابعها التنسيق والتسليم؛ هل نقل السياق الصحيح بين الوكلاء؟ خامسها الإشراف البشري؛ هل طلب الموافقة في النقطة الصحيحة وهل كانت الموافقة البشرية فعالة فعلًا؟
الوثيقة تتعامل مع النظام الوكيلي بوصفه منظومة مكوّنة من نموذج، تعليمات ومهارات، ذاكرة، أدوات، طبقات تخطيط واستدلال، ضوابط مثل الوصول والحواجز والموافقات البشرية، ثم التسجيل والمراقبة. هذه المكونات ليست متساوية من ناحية المخاطر. أداة متصلة بنظام مالي، مثلًا، تخلق سطح خطر مختلفًا عن أداة قراءة فقط. ذاكرة مستمرة قد تحسن جودة التصنيف، لكنها قد تحفظ خطأ أو تلوثًا ويظهر أثره في مهمة لاحقة. انتقال السياق بين وكيل تحليل ووكيل تصميم ووكيل تطوير قد يخلق سلسلة أخطاء حتى لو كان كل وكيل منفردًا يبدو مقبولًا.
الخطوة الأولى: تحديد المخاطر القابلة للاختبار
يقترح المرجع البدء من خصائص الاستخدام الفعلي، لا من قائمة مخاطر عامة. يجب فهم الهدف المقصود للوكيل، ما يستطيع فعله، مستوى استقلاليته، الأدوات والأنظمة التي يتصل بها، نوع المستخدمين، حساسية البيانات، وقابلية التراجع عن الأفعال. بعد ذلك تتحول المخاطر العامة إلى سيناريوهات فشل محددة يمكن اختبارها. الفئات الأساسية التي يبرزها الدليل تشمل الأفعال الخاطئة، الأفعال غير المصرح بها، النتائج المتحيزة أو غير العادلة، خروقات البيانات، وتعطيل الأنظمة المتصلة.
المهم هنا أن الخطر لا يُصاغ بصيغة فضفاضة مثل «قد يتصرف الوكيل بشكل غير آمن»، بل بصيغة عملية: «الوكيل قد يصدر استردادًا أعلى من الحد المسموح دون موافقة»، «قد يبحث في الويب عن بيانات عميل رغم منعه»، «قد يغير سجلًا ماليًا قبل اكتمال المراجعة»، «قد يستمر في مهمة بعد نقطة كان يجب أن يتوقف عندها»، أو «قد يقرأ تعليمات خبيثة مزروعة داخل مستند ويرسل أثرها إلى الذاكرة». عند هذه الدرجة من التحديد يصبح من الممكن بناء Test Case حقيقي ومعيار نجاح أو فشل واضح.
الخطوة الثانية: بناء اختبارات واقعية ولكن محكومة
يوصي الدليل ببيئات اختبار قريبة من الواقع بقدر يكفي لإظهار سلوك النظام الحقيقي، ولكن دون السماح بإحداث ضرر فعلي. لا تكفي بيئة تجريبية مبسطة جدًا فيها عميل واحد أو أدوات وهمية لا تشبه أدوات الإنتاج؛ لأن الوكيل قد يتصرف بشكل مختلف عندما يواجه أحجامًا واقعية، بيانات فوضوية، تواريخ طويلة، سجلات ناقصة، أخطاء API، مشاكل مصادقة، خدمات غير متاحة، أو مخرجات أدوات سيئة التكوين.
في المقابل، لا ينبغي ربط الوكيل مباشرة بأنظمة الإنتاج في اختبارات تجاوز الحدود أو jailbreaks عالية الخطورة. المسار الموصى به تدريجي: بيئة محاكاة أو sandbox واقعية، ثم اقتراب مدروس من أنظمة حقيقية مع ضوابط ومراقبة أقوى كلما زادت الثقة. عند استخدام أدوات أو MCP servers يمكن محاكاة الاستجابات مع الحفاظ على شكل الأدوات وتعريفاتها ومعاملاتها، حتى لا يصبح الاختبار مصطنعًا لدرجة يفقد معها قيمته.
Observability: تسجيل ما حدث فعلًا
أحد محاور الدليل الأساسية هو أن اختبار النظام الوكيلي يحتاج Observability أعمق من تسجيل المدخل والمخرج. يجب التقاط مسار التنفيذ بما في ذلك الأفعال، Tool Calls، تفاعلات الوكلاء، تغييرات الحالة، محاولات الموافقة البشرية، النتائج والأخطاء. تصميم التسجيل يجب أن ينطلق من المخاطر التي نحاول اختبارها، حتى يكون من الممكن لاحقًا إعادة بناء ما حدث والإجابة عن سؤال: لماذا وصل الوكيل إلى هذه النتيجة، وهل وصل إليها بطريقة مقبولة؟
هذه النقطة تمنع أحد أخطر أخطاء التقييم: الاعتماد على تقرير الوكيل عن نفسه. قد يكتب الوكيل ملخصًا مقنعًا بأنه أصلح المشكلة أو اتبع السياسة، بينما تكشف السجلات أو الـgit diff أو قاعدة البيانات أنه لم يفعل ذلك أو نفذ تغييرات ناقصة. لذلك يفضل اختبار الواقع النظامي: ما الذي حدث في المستودع؟ ما الحقول التي تغيرت؟ ما الأداة التي استُدعيت؟ ما الصلاحية المستخدمة؟ وأين كانت نقطة الموافقة؟
المقاييس لا يجب أن تقتصر على جودة الناتج
في Agentic AI نحتاج مقاييس سلوكية إضافة إلى مقاييس النتيجة. يذكر المرجع أمثلة مثل دقة استخدام الأدوات ودقة التسليم بين الوكلاء. دراسات الحالة توسع ذلك عمليًا؛ ففي استخراج متطلبات RFP مثلًا يمكن قياس Recall وPrecision ودقة الاستشهادات والالتزام بالأدوات المطلوبة وثبات الأداء عبر عدة Runs. الفكرة المهمة أن المتوسط وحده قد يكون مضللًا، خصوصًا في مهام يجب ألا تفوّت عنصرًا حرجًا؛ فقد يكون Worst Run أهم من Average Performance.
يجب أيضًا فصل مقاييس مختلفة لا ينبغي دمجها في رقم واحد. نجاح مرحلة تقييم ما في التشغيل لا يعني أنها اكتشفت المشكلة فعلًا. وجود Human Review لا يعني أن المراجع البشري التقط الخلل. التزام الوكيل بخطوات workflow في خمس محاولات لا يثبت أنه لن يتجاوزها تحت ضغط سياقي مختلف. لذلك تحتاج المؤسسة بوابات قبول متعددة بدل «درجة جودة» واحدة تخلق دقة زائفة.
اختبار Human Oversight نفسه
من أكثر نقاط الدليل أهمية أن الإشراف البشري Control يجب اختباره. وضع خطوة موافقة بشرية داخل الرسم المعماري لا يثبت أنها فعالة. يجب التحقق من أن المراجع يحصل على معلومات صحيحة وكافية، أن وقت التدخل مناسب، وأن المراجعين يكتشفون العيوب المقصودة عندما تزرع في سيناريوهات اختبار. كما ينبغي البحث عن Automation Bias، Decision Fatigue، أو حالات يقدم فيها الوكيل تفسيرًا واثقًا يدفع الإنسان للموافقة دون فحص كافٍ.
عمليًا، يمكن اختبار ذلك بإدخال أخطاء مضبوطة ومعروفة مسبقًا ثم قياس نسبة اكتشافها، وقت التدخل، نوع القرار، ومبرراته. إذا لم يلتقط البشر العيوب المتوقعة فلا يجوز اعتبار وجود approval gate دليلًا على السيطرة. بهذا يتحول Human-in-the-Loop من شعار معماري إلى ضابط له Evidence واختبارات فعالية.
الذاكرة والاختبارات ذات الحالة Stateful Testing
الذاكرة المستمرة تغير طبيعة الاختبار لأن الخطأ قد لا يظهر في نفس اللحظة التي دخل فيها إلى النظام. قد تخزن ذاكرة الوكيل تصنيفًا خاطئًا أو تعليمة خبيثة أو علاقة غير صحيحة، ثم تعيد استخدامها في معاملات لاحقة. لذلك تتطلب اختبارات الذاكرة إعداد حالة أولية، ثم تشغيل سلسلة مهام ومراقبة كيفية القراءة والتحديث وإعادة الاستخدام عبر الزمن.
دراسة حالة الوكيل المالي توضح هذا النمط بوضوح: الذاكرة التاريخية استُخدمت لتحسين التصنيف، ولذلك اختُبرت سيناريوهات Stateless وStateful وAdversarial. القيمة هنا ليست في قطاع المحاسبة بحد ذاته؛ بل في قاعدة عامة: أي مكوّن Stateful يحتاج اختبارًا عبر تسلسل زمني، لا اختبار لقطة واحدة. كما يجب اختبار قنوات دخول التلوث: مستندات، أدوات، وكلاء آخرون، أو حتى تفاعل بشري، لأن أثر الحقن قد يظهر لاحقًا وليس فورًا.
Multi-Agent Handoffs كحدود حوكمة
في الأنظمة متعددة الوكلاء، كل نقطة تسليم تمثل Boundary يمكن عندها أن ينتقل خطأ أو يضيع سياق أو تتغير الصلاحيات. توضح دراسة KBTG أن فصل الوكلاء المتخصصين إلى مراحل تحليل أعمال، تصميم، وتطوير يمكن أن يحسن وضوح المسؤوليات، لكنه يخلق حاجة لاختبار handoff risks. الاختبار لا يقتصر على أن الوكيل التالي تلقى ملفًا؛ بل هل تحقق من الفرضيات الحرجة؟ هل اكتشف العيب القادم من المرحلة السابقة؟ هل أعاد العمل للمرحلة الصحيحة بدل البناء فوق خطأ؟ وهل كانت صلاحيات كل وكيل محصورة في الأدوات والمستودعات التي يحتاجها؟
هذا يجعل Handoff Accuracy مفهومًا حوكميًا بقدر ما هو تقني. المؤسسة تحتاج تحديد ما هو الحد الأدنى من السياق المطلوب نقله، أي قرارات يجب توثيقها، متى يجب التوقف والعودة upstream، وما الذي يمنع وكيلًا منخفض الصلاحية من الاستفادة من وكيل آخر أعلى صلاحية للحصول على نتيجة لم يكن مخولًا بها.
إعادة الاختبار بعد النشر
لا ينتهي Agentic Assurance عند Pre-Deployment Testing. الأنظمة الوكيلة تتغير حتى لو لم يتغير الكود الرئيسي: نموذج جديد، تحديث Tool API، تعديل Prompt، إضافة أداة، تغير سلوك خدمة خارجية، توسع في الصلاحيات، تغير محتوى الذاكرة، أو زيادة طول المهام. لذلك يوصي الدليل بالمراقبة المستمرة وإعادة الاختبار دوريًا وعند التغييرات الجوهرية.
ينبغي أن تلتقط المراقبة مؤشرات مثل تغير غير معتاد في زمن التنفيذ، عدد الخطوات، شكل traces، التوزيع الإحصائي للنتائج، شكاوى المستخدمين، الفشل المرصود، والحوادث القريبة Near Misses. هذه الإشارات يمكن أن تتحول إلى triggers لإعادة الاختبار. كما ينبغي تحويل الحوادث المكتشفة إلى Regression Sets حتى لا تعود المشكلة في إصدار لاحق.
حدود الدليل وما لا يدعيه
المرجع نفسه لا يدعي أنه يغطي جميع مخاطر الأمن السيبراني أو جميع أشكال Agentic AI المستقبلية. يقر بأن تحليل المسارات على نطاق واسع ما يزال صعبًا، وأن التكلفة تزيد مع طول المسار وتعدد النماذج والأدوات، وأن منهجيات اختبار Multi-Agent ما تزال ناشئة. كما يقر بحدود الإشراف البشري ومشكلات bottlenecks وdecision fatigue، وبأن الوكلاء الأكثر استقلالية واتساعًا في Action Space سيجعلون التغطية الشاملة أصعب.
لذلك يجب التعامل معه كبداية عملية قوية لا كإطار نهائي مكتمل. قيمته الأكبر هي ترسيخ قاعدة تشغيلية: اختبر الواقع وليس ادعاء الوكيل، اختبر المسار وليس النتيجة فقط، اختبر الحدود والموافقات بدل افتراض أنها تعمل، واعتبر المراقبة وإعادة الاختبار جزءًا من دورة حياة النظام لا نشاطًا قبل الإطلاق فقط.
موضعه داخل سيادة AI
داخل سيادة AI يصنف هذا المرجع ضمن AI Assurance / Agentic AI / Testing & Reliability، ويرتبط بسنغافورة باعتباره Guidance صادرًا عن IMDA وAI Verify Foundation، وليس تشريعًا أو التزامًا تنظيميًا عامًا. كما يشكل مرجعًا خارجيًا مهمًا لمفاهيم حوكمة السلطة الوكيلة؛ لأن اختبار الأدوات والحدود والموافقات ومسارات التنفيذ هو الطريقة العملية لإثبات أن السلطة المفوضة للوكيل بقيت داخل حدودها التشغيلية.