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

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

الإجابة المباشرة: العرض التجريبي الناجح لا يثبت شيئا عن موثوقية وكيل الذكاء الاصطناعي، لأن المعيار الصحيح ليس هل أنجز المهمة مرة، بل هل يكررها بلا خطأ في كل مرة. في دراسة نشرتها مايكروسوفت في العشرين من أغسطس 2026، سجل أفضل نموذج نسبة نجاح 65.36% عند تشغيل المهمة مرة واحدة، لكن نسبة المهام التي نجح فيها في العشرين محاولة كاملة كانت 25.25% فقط. الفارق بين الرقمين هو تحديدا المسافة بين وكيل يبهرك في الاجتماع ووكيل تثق به على بيانات عملائك.

ما الذي بنته مايكروسوفت بالضبط؟

الأداة اسمها Thinkingbox، وهي بيئة اختبار مفتوحة المصدر برخصة MIT منشورة على GitHub. فكرتها بسيطة وذكية: بدل أن تعرف الأدوات التي يستخدمها الوكيل مباشرة، تعرفها كخوادم متوافقة مع بروتوكول MCP، ثم تشغل الوكيل داخل جلسة معزولة لها قاعدة بيانات خاصة بها، وتسجل مسار التنفيذ كاملا.

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

وفوق البيئة بنى الفريق معيارا اسمه Thinkingbox-bench يضم 507 سيناريو عمل مقيدا بسياسات، موزعة على خمسة مجالات: التجزئة والتجارة الإلكترونية، السفر والضيافة، تأمين المركبات، الدعم التقني الداخلي في بنك رقمي، ودعم تقنية المعلومات والموارد البشرية في شركة استشارات. كل مهمة شغلت عشرين مرة على اثني عشر نموذجا بين مغلق ومفتوح الأوزان.

لماذا هذا الرقم يهم صاحب العمل تحديدا؟

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

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

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

وهذا يفسر سببا شائعا لخيبة الأمل: المشروع يمر في التجربة بنجاح لأن التجربة شغلت المهمة مرة واحدة على حالة نظيفة. أما التشغيل الحقيقي فهو نفس المهمة آلاف المرات على حالات فوضوية متراكمة، وهناك يظهر الفرق بين 65% و25%.

ماذا تفعل عمليا قبل أن تعتمد أي وكيل؟

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

كيف نتعامل مع هذا في أوريجامي

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

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

المصادر

• الورقة البحثية: One Success Isn't Reliability: Thinkingbox, a Sandbox and Benchmark for Agents in Stateful Business Workflows — arXiv (نشرت في 20 أغسطس 2026)
• المستودع مفتوح المصدر: microsoft/thinkingbox على GitHub