مقياس موثوقية وكلاء الذكاء الاصطناعي لعام 2026: 65% مرة واحدة، 25% دائماً

ThinkingBox هو معيار لقياس موثوقية وكلاء الذكاء الاصطناعي مفتوح المصدر تم الإعلان عنه في 19 أغسطس 2026. عبر 507 مهام أعمال ذات حالة (stateful) تم تشغيل كل منها 20 مرة، أنهى النموذج الأفضل المهام بشكل صحيح في 65.36% من المحاولات الفردية — لكنه نجح في جميع المحاولات العشرين لـ 25.25% فقط من المهام.¹²

ملخص

الرقم الرئيسي ليس هو رقم الموثوقية. يتصدر GPT-5.4 معيار ThinkingBox-Bench بنسبة نجاح pass@1 بلغت 65.36%. عند تشغيل نفس المهام عشرين مرة، يجد النموذج مساراً ناجحاً واحداً على الأقل في 91.12% منها — لكنه يكرر هذا النجاح في كل مرة لـ 25.25% فقط.¹

هذا الفارق الذي يصل إلى 66 نقطة تقريباً بين "القدرة على التنفيذ" و"التنفيذ الدائم" هو ما يسميه المؤلفون "فجوة الاكتشاف والموثوقية" (discovery–reliability gap).

يقوم المعيار بتقييم الوكلاء بشكل أساسي بناءً على ما تغير في قاعدة البيانات بدلاً من ما قال الوكيل أنه فعله. وبموجب هذه القاعدة، فإن 77.5% من عمليات التشغيل الفاشلة تتوقف عند طبقة الأدوات — استدعاء فاشل، بحث غير ناجح، أو عدم القدرة على التعافي.¹

إذا كنت تختار نموذجاً لوكيل يتعامل مع سجلات إنتاجية فعلية، فإن قائمة متصدري pass@1 تكون عديمة الفائدة تقريباً بمفردها. فنموذجان يتشابهان في pass@1 بفارق ربع نقطة قد يختلفان بنحو 4.4 ضعف من حيث الموثوقية.

ما ستتعلمه

• ما الذي يقيسه معيار ThinkingBox لموثوقية وكلاء الذكاء الاصطناعي فعلياً
• الفرق بين pass@1 و pass@20 و pass^20 — ولماذا تهم علامة الـ caret
• قائمة متصدري ThinkingBox-Bench الكاملة لـ 12 نموذجاً، مع التنبيه الوارد في الحاشية
• لماذا لا يعتبر ترتيب pass@1 ترتيباً للموثوقية
• أين يفشل الوكلاء حقاً: أنماط الفشل الأربعة وحصصها
• من الذي بناه فعلياً، وكيف يشكل ذلك ما يقيسه المعيار
• لماذا لا يعد هذا أول معيار لموثوقية الوكلاء

ما هو معيار ThinkingBox لموثوقية وكلاء الذكاء الاصطناعي؟

ThinkingBox هو بيئة تجريبية (sandbox) للتفاعل بين الأداة والوكيل والمستخدم. يقوم بتشغيل وكيل مقابل جلسات أدوات معزولة ومتوافقة مع MCP، ويسمح لمستخدم محاكى بالإجابة على الأسئلة المتابعة، ثم يفحص الآثار الجانبية التي تركها الوكيل وراءه.¹²

يقترن هذا الإطار بـ ThinkingBox-Bench، وهو مجموعة من 507 سير عمل قابلة للتنفيذ ومشروطة بسياسات عبر خمسة مجالات أعمال. يتم شحنهما بشكل منفصل: مستودع الإطار يضم سيناريو cloud_drive واحداً فقط كاختبار تشغيل أولي (smoke test)، بينما توجد مهام المعيار وخوادم MCP في thinkingbox-data.¹³

يوضح المثال الافتتاحي في تقرير Microsoft التصميم؛ حيث يطلب مسافر من وكيل إضافة تفضيل "غرفة هادئة" إلى حجز فندق. يبحث الوكيل عن الحجز ويؤكد إضافة الطلب. يبدو نص المحادثة وكأنه نجاح تام.

لكن حقل special_requests في الحجز لا يزال فارغاً. "لقد أكد الوكيل القيام بعمل لم يفعله أبداً"، كما ورد في المنشور — وتكتشف ذلك عند تسجيل الوصول في الفندق.²

إذًا، قاعدة التقييم هي: مقارنة الحالة النهائية للخلفية البرمجية (backend) بالحالة النهائية المطلوبة، ورفض أي تأثيرات خاطئة أو مفقودة أو إضافية، والسماح لأي مسار ينتج السجلات الصحيحة بالمرور. التقييم تراكمي — لا تنجح المهمة إلا عندما تتحقق جميع الشروط المطلوبة.¹

ومع ذلك، فإن الحالة ليست هي الحكم النهائي بالكامل. تطبق بعض المهام المحددة أيضًا معايير ثنائية على الاستجابة النهائية، يتم فحصها بواسطة نموذج حكم، للأمور التي ليس لها قيمة واضحة في قاعدة البيانات — مثل ما إذا كان العميل قد أوضح أن تفضيل الغرفة يخضع للتوافر، على سبيل المثال.¹²

من الجدير بالذكر فيما يلي: أن العميل، والمستخدم المحاكي، والحكم جميعهم عبارة عن نماذج LLMs على نقاط نهاية (endpoints) يمكن تكوينها بشكل منفصل.²³ بعض التباين من تشغيل إلى آخر الذي يقيسه المقياس يعود إلى بيئة الاختبار (harness)، وليس إلى العميل الخاضع للاختبار.

أعداد المهام حسب المجال: التجزئة والتجارة الإلكترونية 98، السفر والضيافة 104، تأمين السيارات 100، تكنولوجيا المعلومات الداخلية للبنوك الرقمية (neobank) 104، تكنولوجيا المعلومات والموارد البشرية للاستشارات 101.¹²

pass@20 مقابل pass^20: رقمان، وبينهما 66 نقطة

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

• pass@1 — عدد المرات التي ينهي فيها النموذج المهمة عند تشغيله مرة واحدة.
• pass@20 — "في أي نسبة مئوية من المهام نجحت محاولة واحدة على الأقل من أصل 20 محاولة؟"
• pass^20 — "في أي نسبة مئوية من المهام نجحت جميع المحاولات العشرين؟"

بالنسبة لـ GPT-5.4، كانت النتائج 65.36% و 91.12% و 25.25% على التوالي.¹²

أعداد المهام الأساسية تجعل هذا التقسيم ملموسًا. من بين 507 مهام، لم ينجح GPT-5.4 أبدًا في 45 مهمة — حوالي 8.9% ظلت دون حل حتى مع عشرين محاولة — ونجح في جميع المحاولات العشرين في 128 مهمة.²

كلا الرقمين يتطابقان تمامًا: نجاح 462 من أصل 507 مهام مرة واحدة على الأقل يمثل 91.12%، و 128 من أصل 507 يمثل 25.25%. النسب المئوية المنشورة متسقة داخليًا مع أعداد المهام، وهو أمر يتيح لك التحقق منه أكثر مما تسمح به معظم تقارير المقاييس.

علامة الـ caret ليست خطأ مطبعيًا بدلاً من علامة at. pass@k متفائل (الأفضل من k)؛ بينما pass^k متشائم (الكل من k). إن ذكر 25.25% كدرجة "pass@20" يقلب معنى النتيجة.

لوحة صدارة ThinkingBox-Bench

اثنا عشر نموذجًا، كل مهمة تم تشغيلها عشرين مرة، والنتائج هي متوسطات دقيقة (micro-averaged) عبر التجارب والمهام.¹²

جميع القيم هي نسب مئوية لـ pass@1. الحجم يمثل إجمالي/المعاملات المفعلة لموديلات mixture-of-experts. مرتبة حسب المتوسط؛ ترتيب الورقة البحثية نفسها يضع الموديلات المملوكة أولاً.

هناك حاشية سفلية واحدة في الورقة تستحق اهتماماً أكبر مما نالته: "صف o3-pro يستبعد 636 تجربة حدث بها خطأ في النظام/الأداة؛ وبالتالي تختلف المقامات الصحيحة حسب المجال."¹ هذا الصف لم يتم قياسه بناءً على نفس المقام مثل الصفوف الأخرى.

هناك ثلاثة أنماط تظهر بوضوح في الجدول.

صعوبة المجال تطغى على ترتيب الموديلات. بمتوسط عبر الموديلات المذكورة، تضع الورقة قطاع التجزئة عند حوالي 52% pass@1 وتأمين السيارات عند حوالي 23%، بينما يقع السفر والبنك الرقمي والاستشارات بينهما. داخل الموديل الواحد قد يكون التفاوت أسوأ: يحقق Claude Opus 4.6 نتيجة 74.90 في التجزئة و 14.65 في تأمين السيارات، وهو انهيار بمقدار 60 نقطة.¹

عدد المعاملات (Parameters) لا يتنبأ بالكثير. يحقق Qwen3.6-27B متوسط 32.94 بينما يحقق Mistral-Large-3 الأكبر بكثير متوسط 4.66.

الموديلات ذات الأوزان المفتوحة (Open weights) أقرب مما يوحي به السطر الأول. يحقق DeepSeek-V4-Pro متوسط 43.26، وهي أقوى نتيجة للأوزان المفتوحة هنا وهي قريبة من نتيجة GPT-5.2 البالغة 46.28 — وإن كان بملف تعريف مختلف للمجالات.¹

هناك تعارض بسيط يستحق الإشارة، بما أن كلا المصدرين رسميان. منشور Command Line يقول إن GPT-5.4 "هو الموديل الوحيد الذي تم تقييمه فوق 50% في كل مجال". أما الورقة فتقول إن GPT-5.4 و Claude Sonnet 4.6 حققا ذلك.¹² الجدول المنشور يحسم الأمر: أقل درجة لمجال في Sonnet 4.6 هي 51.14، لذا الورقة صحيحة والمدونة أغفلت واحداً.

"حجم الموديل والدرجة الإجمالية الواحدة لا يخبرانك أين سينجح العميل الذكي (agent)،" كما يختتم منشور Command Line.²

لماذا لا يعتبر ترتيب pass@1 هو ترتيب الموثوقية

إليك النتيجة التي يجب أن تغير طريقة قراءتك لقوائم متصدري العملاء الذكيين (agent leaderboards). هناك فرق ربع نقطة فقط في pass@1 بين Claude Opus 4.6 و Kimi-K2.6 — بنسبة 37.91% مقابل 37.66%.¹²

لكن ملفات الموثوقية الخاصة بهما ليست متقاربة على الإطلاق:²

يجد Kimi-K2.6 مساراً ناجحاً في مهام أكثر بـ 14.2 نقطة مقارنة بـ Opus. لكنه يكرر هذا المسار بنسبة تعادل الربع تقريباً — 3.16% مقابل 13.81%، بفجوة تصل إلى حوالي 4.4 ضعف.

إذا قرأنا هذا كقرار هندسي، فنحن أمام منتجين مختلفين. Kimi هو المستكشف الأفضل؛ بينما Opus هو المنفذ الأفضل. أما قائمة المتصدرين التي تذكر فقط معدلات pass@1 فتصنفهما كمتساويين تقريباً.

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

تنبيه واحد عند قراءة هذه البيانات: التقرير عند الإطلاق يقدم pass@20 و pass^20 لهذه الموديلات الثلاثة فقط، ويعرض كل رقم كتقدير نقطي. تشير الورقة البحثية إلى أن فترات bootstrap لعناقيد المهام موجودة في الملحق، لذا فإن الفجوات بين الموديلات المتجاورة تستحق وزناً أقل من الفجوة بين المقاييس نفسها.¹²

أين يفشل العملاء الذكيون فعلياً: أخطاء الأدوات لا الإجابات السيئة

تم تخصيص بصمة فشل مهيمنة لكل عملية تشغيل فاشلة من خلال التتبع (trace) — الرسائل، استدعاءات الأدوات، استجابات الأدوات، الإجابة النهائية، وعلامة الإنهاء. تحرص الورقة البحثية على تسمية هذه "تشخيصات قابلة للملاحظة بدلاً من تفسيرات سببية فريدة"، ويغطي تحليلها 11 من أصل 12 موديل؛ حيث يغيب Qwen3.5-9B عن هذا الجدول.¹²

تستخدم الورقة تسميات مختلفة لثلاث من نفس الفئات — "Incomplete User Resolution" لجودة الاستجابة، و "No State-Changing Action" لتغيير الحالة المفقود، و "Wrong State Update" لتغيير الحالة الخاطئ — مع أرقام متطابقة.¹

التوزيع هو القصة هنا. 7.9% فقط من حالات الفشل تكون بسبب كتابة العميل الذكي لإجابة نهائية سيئة؛ أما الـ 92.1% الأخرى فتحدث في مرحلة مبكرة، أثناء التنفيذ.

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

تتركز إخفاقات استخدام الأدوات بشكل خاص في GPT-5.4 (89.6% من إخفاقاته)، وGLM-5.1 (88.1%) وKimi-K2.6 (85.2%).¹

هذه توقيعات تشخيصية وليست أسباباً مُشخصة — لكن شكلها لا يزال يشير إلى أين يجب البحث في حلقة عمل العميل: قراءة كل نتيجة أداة، وإعادة التخطيط بعد الإجراء الفاشل، والتحقق من الحالة قبل الإبلاغ عن النجاح. وقد ظهر نفس التأكيد في بيانات اختبار Slack لـ 200 تشغيل للعملاء، ولكن من اتجاه مختلف تماماً.

من الذي بنى ThinkingBox فعلياً

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

تدرج ورقة arXiv اثني عشر مؤلفاً من أربع مؤسسات: جامعة بيتسبرغ، وجامعة نورث وسترن، وجامعة كاليفورنيا في إيرفين، وMicrosoft. يبدو هذا كتعاون أكاديمي — حتى تصل إلى الحاشية السفلية، التي تشير إلى المساهمة المتساوية وتوضح أن العمل "اكتمل خلال فترة تدريب في Microsoft".¹ والجامعات هي المؤسسات الأصلية للمتدربين.

أصل الإطار العملي أكثر تحديداً من ذلك. وفقاً للمستودع، بدأ ThinkingBox "في مستودع خاص وكان مستخدماً على نطاق واسع من قبل مجموعة من المطورين والعلماء الذين يعملون على التعلم التعزيزي للعملاء في Microsoft Copilot Studio قبل أن يصبح مشروعاً مفتوح المصدر"، مع نسب الفضل لـ Nicola Ferri في إطلاقه. ويشكر ملف README قائمة مساهمين مستمدة من "فريق RL في Microsoft Copilot Studio".³

أما ThinkingBox-Bench فقد تم بناؤه "بالشراكة مع Toloka"، وهي شركة متخصصة في تعليق البيانات.²

لذا فإن الإطار الصادق هو: هذا تقييم داخلي وأداة تعلم تعزيزي لفريق تطوير منتج، تم فتحها للعامة — وليس قياساً محايداً للمجال من مختبر مستقل. هذا لا يجعل الأرقام خاطئة، لكنه يعني أن تصميم المهام يجسد ما قرر فريق Copilot Studio أن يكون عليه عمل العملاء في المؤسسات، وأن نفس الأداة تُستخدم للتدريب والتقييم على حد سواء.

تفاصيل الإصدار: رخصة MIT، مستودعان — microsoft/thinkingbox لبيئة التشغيل، و microsoft/thinkingbox-data للمهام وخوادم MCP، حيث تم وضع علامة المعيار كـ ThinkingBox-Bench v1.0. ويذكر ملف README أن المشروع "تم اختباره فقط على Linux"، ويوصي باستخدام Python 3.12، ولا يزال قسم الاستشهادات يقول "ورقة تصف ThinkingBox ستصدر قريباً" عند التحقق في 26 أغسطس — أي بعد ستة أيام من نشر الورقة.²³

هل ThinkingBox هو أول معيار لموثوقية عملاء الذكاء الاصطناعي؟ لا

ليس كذلك — وللحقيقة يُحسب لـ Microsoft أن أحداً من المشاركين لم يدّعِ خلاف ذلك. وبما أن الإطلاقات المجهزة جيداً تميل إلى أن تُذكر كأول محاولة، إليكم الأعمال السابقة.

تم تقديم مقياس pass^k بواسطة τ-bench في يونيو 2024، من قبل Shunyu Yao و Noah Shinn و Pedram Razavi و Karthik Narasimhan. اقترحت تلك الورقة "مقياسًا جديدًا (pass^k) لتقييم موثوقية سلوك العميل (agent) عبر محاولات متعددة" وقامت بالفعل بتصنيف العملاء من خلال مقارنة "حالة قاعدة البيانات في نهاية المحادثة مع حالة الهدف المحددة."⁴

كما اكتشف τ-bench الفجوة بالفعل. يشير ملخصه إلى أن عملاء استدعاء الدوال (function-calling agents) الأكثر تطورًا "مثل gpt-4o" نجحوا في أقل من 50% من المهام وكانوا "غير متسقين تمامًا (pass^8 <25% في قطاع التجزئة)."⁴

لا يمكن مقارنة رقمي الموثوقية بشكل مباشر — قيم k مختلفة، نطاق تجزئة واحد مقابل خمسة، نموذج من عام 2024 مقابل نموذج من عام 2026. ما يتبقى من المقارنة هو النمط: رغم مرور عامين وعدة أجيال من النماذج، يجد كلا المقياسين أن القدرة على التكرار تتخلف عن القدرة العامة بفارق كبير.

يعترف جدول المقارنة الخاص بشركة Microsoft بنقطة الأولوية مباشرة. حيث يصنف كل من tau-bench و tau2-bench على أنهما يستوفيان جميع المتطلبات الأربعة المذكورة لـ ThinkingBox، وينص على أن: "عائلة tau-bench هي أقرب مقارنة لـ ThinkingBox-Bench من حيث أنها توفر أيضًا جميع الخصائص الأربعة."²

ما يضيفه ThinkingBox، وفقًا لكلمات مؤلفيه، هو "دورة حياة قابلة لإعادة الاستخدام حول خوادم MCP و 507 مهمة عبر خمسة نطاقات أعمال، بما في ذلك تأمين السيارات وتكنولوجيا المعلومات الداخلية والموارد البشرية."² وتضع الورقة هذا العمل كـ "متابعة لتقييمات العملاء الموجهة نحو الموثوقية مؤخرًا"، مستشهدة بـ τ-bench.¹

البنية التحتية الأصلية لـ MCP هي الجزء الجديد حقًا — عملية واحدة لكل خادم MCP، وثلاث أدوات دورة حياة محجوزة لا يراها العميل أبدًا، وحالة جديدة لكل محاولة. ومع ترسيخ MCP تحت حوكمة مشتركة جنبًا إلى جنب مع A2A في Agentic AI Foundation، تصبح أدوات التقييم التي تتحدث MCP بشكل أصلي أكثر قابلية لإعادة الاستخدام، وليس العكس.

ماذا يعني هذا إذا كنت تقوم بإطلاق عملاء ذكاء اصطناعي

هناك أربعة استنتاجات من البيانات، لا يتطلب أي منها منك تشغيل المقياس بنفسك.

اطلب من الموردين مقياس pass^k، وليس pass@1. درجة المحاولة الواحدة تخبرك أن النموذج يمكنه إيجاد حل، لكنها لا تخبرك شيئًا عما إذا كان سيجد نفس الحل غدًا.

قم بقياس نطاق عملك الخاص. عندما يتأرجح نموذج واحد من 74.90% إلى 14.65% بين مجموعتين من المهام، لا يمكن للمتوسط العام أن يحل محل الدرجة الخاصة بسير عملك.

قم بتجهيز طبقة الأدوات أولاً. إذا كانت 77.5% من الإخفاقات هي أخطاء أدوات غير مستردة، فهذا هو المكان الذي تحقق فيه منطق إعادة المحاولة (retry logic)، وإظهار الأخطاء، وإعادة التخطيط أكبر قدر من الموثوقية مقابل كل وحدة جهد.

افحص الحالة، وليس النصوص. نمط الفشل الذي بُني عليه المقياس — وهو التأكيد الواثق على عمل لم يحدث أبدًا — يكون غير مرئي لأي مقيم يقرأ الرسالة النهائية فقط. قياس العنصر الخاطئ ينتج أرقامًا خاطئة بثقة، وهو ما شرحناه في قفزة مقياس Muse Code.

الخلاصة

الرقم المثير للاهتمام في هذا الإصدار ليس 65.36%. بل هو المسافة بين 91.12% و 25.25% على نفس النموذج، وفي نفس المهام، وفي نفس الأسبوع.

الوكيل الذي يحل تسع مهام من كل عشر مهام مرة واحدة على الأقل في التقييم، ثم يكرر ذلك في مهمة واحدة فقط من كل أربع مهام، لا يعاني من مشكلة في القدرات. هذه مشكلة تباين (variance) — والتباين هو مشكلة هندسية تعالجها عن طريق إعادة المحاولة، والتحقق، وفحص الحالة، والبوابات البشرية، وليست مشكلة تحلها بانتظار النموذج التالي.

أو كما ورد في الورقة البحثية: "الأداء القوي في استخدام الأدوات لا يترجم بعد إلى إكمال عمل موثوق به".¹