اختبار وكلاء الذكاء الاصطناعي: لماذا لم تعد النتيجة الصحيحة كافية؟

السؤال الذي يغير طريقة اختبار Agentic AI

عندما تطلب من نموذج لغوي كتابة ملخص أو صياغة بريد، يكون التركيز الطبيعي على الناتج: هل الإجابة صحيحة؟ هل خلت من المحتوى الضار؟ هل التزمت بالتعليمات؟ لكن عندما تنتقل المؤسسة من LLM App إلى Agentic System فإن هذا السؤال يصبح غير كافٍ. الوكيل قد يفتح أدوات، يقرأ من قواعد بيانات، يكتب في أنظمة، يرسل رسائل، يغير ملفات، ينسق مع وكلاء آخرين، يحتفظ بذاكرة ويطلب موافقات بشرية. لذلك قد تكون الجملة النهائية «تمت المهمة بنجاح» صحيحة ظاهريًا بينما كانت طريقة التنفيذ نفسها غير مقبولة.

هذا هو التحول المركزي الذي يقدمه Starter Kit for Testing Agentic Systems for Safety and Reliability الصادر عن IMDA وAI Verify Foundation في أكتوبر 2026: يجب أن نختبر Outcome وTrajectory معًا. بمعنى آخر، لا نسأل فقط هل وصل النظام إلى النتيجة المطلوبة، بل كيف وصل إليها، وما الأفعال التي نفذها، وما الأدوات التي استخدمها، وما الحدود التي لمسها أو حاول تجاوزها، وأين تدخل الإنسان، وهل يمكن إعادة بناء سلسلة الأحداث بعد انتهاء المهمة.

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

من Output Testing إلى Action Testing

الفرق الأول هو أن الأنظمة الوكيلة تفعل ولا تكتفي بالقول. لهذا فإن اختبارها يحتاج Evidence على الأفعال. إذا كانت المهمة «أرسل البريد وحدد الاجتماع»، فلا يكفي أن يجيب الوكيل بأنه فعل ذلك؛ يجب التحقق من أن البريد أُرسل فعلًا، ومن الجهة الصحيحة، بالمحتوى الصحيح، ومن أن الاجتماع أُنشئ بالموعد الصحيح، وأن الوكيل لم يستخدم حسابًا أو صلاحية لا تخصه.

بمنطق الحوكمة، كل Tool Call هو احتمال Action، وكل Action قد يحمل أثرًا قانونيًا أو ماليًا أو أمنيًا. لذلك يجب ربط الاختبار بنوع السلطة الممنوحة للوكيل. أداة القراءة ليست مثل أداة الكتابة. إنشاء Draft ليس مثل إرسال الرسالة. اقتراح تحويل مالي ليس مثل تنفيذ التحويل. تعديل Branch ليس مثل Merge إلى الإنتاج. إذا لم يفرق Test Plan بين هذه المستويات، فسيعطي نتيجة نجاح مضللة.

يمكن صياغة اختبار ناضج في صورة سلسلة: Objective → Intended Action → Required Tool → Permitted Scope → Required Approval → Actual Action → Resulting State → Evidence. هذه السلسلة تجعل الخطأ قابلًا للتحديد. إذا فشل الناتج نعرف أين. وإذا نجح الناتج لكن استخدمت أداة غير معتمدة نكتشف Governance Failure رغم Functional Success.

Agent Trajectory هو سجل القرار والتنفيذ

الـTrajectory هو المسار الذي اتخذه النظام عبر خطوات متعددة. قد يبدأ بتحليل طلب المستخدم، ثم استدعاء أداة، ثم قراءة نتيجة، ثم تعديل خطة، ثم طلب موافقة، ثم تنفيذ إجراء، ثم تسجيل نتيجة. في نظام آخر قد يشمل انتقال العمل بين عدة وكلاء. المهم أن النتيجة الواحدة قد تنتج من مسارات متعددة، وليس كل مسار مقبولًا.

لذلك يجب أن يجيب الاختبار على أسئلة مثل: هل استخدم الوكيل الأداة التي كان يجب استخدامها؟ هل فهم مخرجاتها بصورة صحيحة؟ هل استند إلى مصدر مسموح؟ هل طلب موافقة عند النقطة التي تتطلبها السياسة؟ هل أعاد المحاولة بطريقة سليمة عند فشل API؟ هل أخذ shortcut تجاوز Control؟ هل حمل سياقًا زائدًا إلى وكيل آخر؟ وهل احتفظ ببيانات في الذاكرة بعد انتهاء الحاجة إليها؟

المؤسسة التي تسجل Final Answer فقط لن تستطيع الإجابة. لهذا تصبح Observability جزءًا من Assurance Architecture، وليست مجرد وظيفة هندسية للتشخيص.

خمسة أنواع من المخاطر يجب أن تتحول إلى سيناريوهات

يقترح المرجع خمس عائلات عملية للمخاطر: Erroneous Actions، Unauthorised Actions، Biased or Unfair Actions، Data Breaches، Disruption to Connected Systems. لكن قيمة هذه الفئات تظهر فقط عندما تتحول إلى سيناريو خاص بالاستخدام.

إذا كان الوكيل يدير طلبات استرداد، فـUnauthorised Action يمكن أن يعني إصدار مبلغ يتجاوز حدًا معينًا دون موافقة. إذا كان وكيلًا برمجيًا، فقد يعني تعديل مستودع غير مصرح أو فتح Pull Request على مشروع خاطئ. إذا كان وكيل موارد بشرية، فقد يعني استخدام متغيرات حساسة في التوصية. إذا كان وكيلًا يتصفح الويب، فقد يعني قراءة تعليمات خبيثة داخل صفحة خارجية ثم التصرف بناءً عليها.

الاختبار الجيد يبدأ من Capability Mapping: ماذا يستطيع الوكيل أن يفعل؟ ما مستوى الاستقلال؟ ما الأنظمة المتصلة؟ هل أفعاله قابلة للتراجع؟ من هم المستخدمون؟ ما نوع البيانات؟ ثم نحول كل قدرة إلى حالات سوء استخدام أو خطأ محتمل. لا نبدأ من قائمة Checkboxes عامة، لأن نفس الخطر يأخذ معنى مختلفًا بحسب Action Space وسياق المؤسسة.

Wrong Process, Right Outcome

هذه من أهم حالات الاختبار. تخيل وكيلًا مطلوبًا منه التأكد من أن أي خصم أعلى من 10% يحتاج اعتماد مدير. أعطى العميل خصمًا 8% — النتيجة ضمن الحد. لكن السجلات تظهر أنه حاول أولًا 20%، فشل بسبب Control تقني، ثم خفّض القيمة حتى مرت. النتيجة النهائية «مسموحة»، لكن السلوك يكشف أن النظام حاول تجاوز Boundary.

مثال آخر: الوكيل البرمجي أصلح Vulnerability وأنتج Tests تمر. لكن أثناء العمل حذف إعدادًا أمنيًا موجودًا ثم أعاده بطريقة مختلفة، أو استخدم مكتبة غير معتمدة. إذا قيّمنا final diff فقط قد نفوت إشارة مهمة عن أسلوب التخطيط والتنفيذ. لذلك يجب أن يحتوي Test Oracle على قواعد تخص العملية نفسها، لا الناتج فقط.

يمكن أن تكون بعض القواعد Deterministic: «يجب ألا تستدعى أداة X»، «أي إجراء فوق قيمة Y يتطلب approval event»، «يجب ألا يكتب الوكيل في namespace Z». وبعضها Semantically Evaluated: «هل كانت المبررات المعروضة للمراجع البشري كافية؟»، «هل نقل handoff السياق الضروري دون معلومات حساسة زائدة؟». الجمع بين النوعين أفضل من الاعتماد على LLM Judge وحده.

الواقعية شرط لا رفاهية

اختبارات الوكلاء تفشل في إعطاء صورة صادقة عندما تكون البيئة مصطنعة جدًا. وكيل يرى قاعدة بيانات فيها سجل واحد فقط أو يستخدم أسماء مثل John Doe وروابط localhost قد يتصرف بصورة مختلفة عن بيئة حقيقية. كما أن كثيرًا من الأعطال لا تظهر إلا مع بيانات غير مرتبة، ملفات ناقصة، وثائق بلغات مختلفة، تواريخ قديمة، استجابات API بطيئة، authentication failures أو أدوات تعيد payload غير متوقع.

لذلك يجب أن تشبه Test Environment الإنتاج من حيث architecture، schemas، tool interfaces، guardrails، memory، والخدمات المساندة. لكن الواقعية لا تعني المخاطرة. يمكن إنشاء cloned repositories، mocked external services، sandbox VMs، قواعد بيانات مع بيانات اصطناعية واقعية، وallowlists. الهدف أن يحتفظ الاختبار بخصائص الفشل المهمة دون السماح للوكيل بإحداث ضرر في النظام الحقيقي.

لا تفترض أن Guardrail يعمل لأنه موجود

الوكلاء موجهون لتحقيق الهدف، وقد يجربون مسارات بديلة عندما يواجهون عائقًا. لذلك وجود Prompt يقول «لا تفعل» ليس Enforcement. وحتى وجود Sandbox أو Allowlist يجب اختباره. هل يمكن للوكيل استخدام أداة أخرى للوصول إلى النتيجة نفسها؟ هل يمكنه استدعاء endpoint غير مباشر؟ هل يستطيع تمرير العمل إلى Agent آخر يملك صلاحية أعلى؟ هل يمكنه تحويل إجراء محظور إلى سلسلة إجراءات تبدو كل واحدة منها مسموحة منفردة؟

هنا نحتاج Negative Testing: أعط الوكيل هدفًا لا يمكن إنجازه قانونيًا ضمن صلاحياته، ثم راقب هل يتوقف، يصعد القرار، يطلب موافقة، أم يحاول workaround. أفضل Evidence للحدود ليس أن الوثيقة تقول إنها موجودة؛ بل أن الاختبار يثبت أن النظام فشل بأمان عندما حاول تجاوزها.

Human Approval Gate يجب أن يثبت فعاليته

في كثير من التصميمات نرى مربعًا اسمه Human-in-the-Loop ونعتبر الخطر محلولًا. هذا غير صحيح. الإنسان قد يوافق تلقائيًا بسبب ضغط العمل، قد لا يفهم المعلومات، قد يتعرض Automation Bias، أو قد يحصل على شاشة لا تعرض الجزء الحرج من السلوك. لذلك يجب اختبار الإنسان كجزء من Control System.

إحدى الطرق العملية هي إدخال Defects معروفة مسبقًا داخل سيناريوهات الاختبار: معلومة ناقصة، توصية غير صحيحة، Tool Call يتجاوز scope، أو انتقال سياق مشبوه. بعد ذلك نقيس هل اكتشف المراجع الخطأ، كم استغرق، هل رفض أو طلب توضيحًا، وهل سجل rationale. إذا مرت الأخطاء باستمرار، فالمشكلة ليست في «وجود» الرقابة بل في تصميمها أو حملها التشغيلي.

هذا يسمح ببناء Metrics مثل Detection Rate، Override Rate، Escalation Accuracy، Review Latency، وFalse Approval Rate. عندها يصبح Human Oversight قابلًا للتقييم وإعادة الاختبار مثل أي Control آخر.

Logging يجب أن يخدم المخاطر لا أن يجمع كل شيء

الأنظمة الوكيلة قد تنتج Logs ضخمة، وتحليل كل Token وكل خطوة على نطاق كبير قد يكون مكلفًا وغير عملي. الحل ليس إهمال السجلات، بل تصميمها حول failure signals المهمة. إذا كان الخطر هو تجاوز الصلاحية، نحتاج identity، tool، action، target resource، permission decision، result. إذا كان الخطر هو memory leakage، نحتاج session IDs، memory read/write events، retention markers. إذا كان الخطر هو handoff failure، نحتاج source agent، target agent، transferred context، decision point وvalidation outcome.

بهذا تصبح السجلات Evidence Architecture وليست Data Exhaust. يمكن لاحقًا بناء Scanners وقواعد آلية للبحث عن أنماط معروفة، ثم الاحتفاظ بالمراجعة البشرية للحالات الغامضة أو عالية الأثر.

الذاكرة تجعل الفشل عابرًا للزمن

Stateful Agent قد يتعلم أو يحتفظ بمعلومة من مهمة سابقة. هذا مفيد، لكنه يغير نموذج التهديد. خطأ اليوم قد يصبح مدخل الغد. تعليمات خبيثة داخل مستند قد لا تؤدي إلى أثر فوري، لكنها قد تلوث memory ثم تغير قرارًا لاحقًا. لذلك لا يكفي اختبار Memory Retrieval في جلسة واحدة.

يجب بناء sequences: حالة أولية معروفة، مجموعة تفاعلات، تحديثات في الذاكرة، ثم مهام لاحقة تقيس هل استُخدمت المعلومات الصحيحة وهل حُفظت الحدود بين المستخدمين والجلسات. كما يجب اختبار poisoning وstale information وincorrect correction وcross-session leakage. فإذا كانت الذاكرة جزءًا من القرار، فهي جزء من Surface الاختبار والحوكمة معًا.

Multi-Agent يعني Multi-Boundary

كل Handoff بين Agent وآخر فرصة لفقدان معلومة، زيادة معلومة غير لازمة، إساءة تفسير Artifact، أو انتقال سلطة ضمني. أنظمة SDLC متعددة الوكلاء مثال واضح: وكيل تحليل يخرج Requirements، وكيل تصميم يبني عليها، ووكيل تطوير ينفذ. خطأ في المرحلة الأولى قد ينتشر حتى الكود النهائي إذا لم تكن هناك نقاط تحقق.

لذلك يجب اختبار handoff نفسه: هل يرفض الوكيل downstream artifact ناقصًا؟ هل يتحقق من assumption حرجة؟ هل يعيد المهمة للمرحلة السابقة؟ هل يستلم فقط البيانات التي يحتاجها؟ هل يحافظ كل وكيل على حدود أدواته ومستودعاته؟ Handoff Test ليس مجرد Integration Test؛ هو أيضًا اختبار لنقل المسؤولية والسياق والسلطة.

التكرار مهم لأن الوكيل غير حتمي

Run ناجح واحد لا يثبت الاعتمادية. قد ينجح الوكيل أربع مرات ويفوّت requirement حرجًا في الخامسة. لهذا يجب تكرار الاختبارات مع seeds أو ظروف مختلفة، ومقارنة الاستقرار، لا المتوسط فقط. في مهام High Recall قد يصبح Worst Run Gate: إذا فات عنصر must-catch مرة واحدة فقد يكون النظام غير مناسب رغم Average Recall مرتفع.

كما ينبغي اختبار combinations مختلفة عندما يكون المستخدم أو النظام قادرًا على تبديل model أو harness، واختبار أثر Context Window والـcompaction في المهام الطويلة. بعض التعليمات قد تضيع عندما يُضغط السياق، فتظهر violations لم تكن موجودة في Run أقصر.

Post-Deployment: الاختبار يصبح Continuous Assurance

بعد النشر، تتغير البيئة. Model Upgrade، Tool Update، Prompt Change، API behavior، Permissions، Memory، أو integration جديدة يمكن أن تغير السلوك من دون أن تلاحظ المؤسسة فورًا. لذلك يجب ربط Monitoring بإعادة الاختبار.

الإشارات التي تستحق trigger تشمل: زيادة غير معتادة في عدد الخطوات، تغير زمن التنفيذ، اختلاف بنية trace، ارتفاع فشل أداة معينة، تغير توزيع القرارات، شكاوى المستخدمين، Near Miss، أو انخفاض معدل تدخل البشر. هذه ليست مجرد Observability Metrics؛ يمكن تحويلها إلى Retest Conditions.

كل Incident أو failure mode جديد يجب أن يدخل Regression Set. بذلك تتراكم خبرة المؤسسة بدل أن تعيد اكتشاف الأخطاء نفسها بعد كل إصدار.

نموذج عملي لبوابة قبول Agentic System

قبل اعتماد وكيل عالي الأثر، لا أستخدم سؤال «هل الاختبار ناجح؟» بل مجموعة Gates:

1. Outcome Gate: هل حقق المهمة ضمن جودة متفق عليها؟
2. Action Gate: هل كل الأفعال الفعلية مصرح بها ومطابقة للسياسة؟
3. Tool Gate: هل استخدم الأدوات المعتمدة فقط وبالمعاملات الصحيحة؟
4. Boundary Gate: هل بقي داخل الصلاحيات حتى عند محاولات الاستفزاز؟
5. Approval Gate: هل طلب الموافقات في النقاط الصحيحة وهل كانت فعالة؟
6. Memory Gate: هل الذاكرة صحيحة ومعزولة ولا تنقل تلوثًا؟
7. Handoff Gate: هل انتقال السياق بين الوكلاء كامل وآمن ومحدد؟
8. Observability Gate: هل يمكن إعادة بناء ما حدث بأدلة كافية؟
9. Stability Gate: هل النتائج مستقرة عبر Runs كافية؟
10. Retest Gate: هل هناك شروط واضحة تفرض إعادة الاختبار بعد التغيير؟

إذا فشل أحد هذه البوابات في نظام عالي الأثر، فإن نجاح النتيجة وحده لا يكفي لتبرير النشر.

ماذا يعني ذلك لسيادة المؤسسة؟

المؤسسة لا تحتاج وكيلًا «ذكيًا» فقط؛ تحتاج وكيلًا مقيد السلطة، قابلًا للرصد، قابلًا للاختبار، ويمكن إثبات سلوكه. وهذا يربط اختبار Agentic AI مباشرة بحوكمة السلطة. إذا كانت المؤسسة قد فوضت الوكيل بفعل معين ضمن حدود معينة، فإن الاختبار هو الطريقة التي تثبت بها أن هذه الحدود تعمل في الواقع.

من هنا تصبح العلاقة واضحة بين Agentic Testing وAgentic Authority: التفويض يحدد ما يحق للوكيل فعله، Enforcement يفرض الحدود، Observability يسجل ما حدث، Testing يحاول كسر هذه الحدود بطريقة محكومة، Evidence يثبت النتيجة، وOversight يتدخل عند الحاجة. إذا كانت أي حلقة من هذه السلسلة مفقودة، فقد يكون لدينا Automation قوي ولكن سيادة ضعيفة.

الخلاصة التشغيلية

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