StopLoss يقطع تشغيلات وكلاء البرمجة المحكوم عليها بالفشل ويوفر ما يصل إلى 48% من التكاليف

يواصل وكلاء البرمجة بإصرار تحسين حلول ستفشل في التحقق على أي حال، وكل خطوة زائدة تُدفع كلفتها رموزًا (tokens). وإسناد هذه المراقبة إلى نموذج رائد يصطدم بالمشكلة نفسها: فالمراقب ذاته مكلف. يقترح مؤلفو ورقة StopLoss مراقبًا خارجيًا صغيرًا يقرأ الخطوات الأخيرة للوكيل ويوقف التشغيل في الوقت المناسب. وعلى SWE-bench Verified يخفض المراقب تكلفة كل حل محفوظ بنسبة 4,5% مع الإبقاء على 99% من التشغيلات الناجحة. أما على المجموعة الفرعية الأعلى كلفة من SWE-bench Pro فيبلغ التوفير 31%، ويصل إلى 48% عند استخدام Qwen3-8B نموذجًا أساسيًا.

كيف يعمل المراقب

اسم المشروع مأخوذ من أمر وقف الخسارة (stop-loss) في البورصة: يُغلق المركز تلقائيًا حين تصبح الخسارة أرجح من الربح. و«المركز» هنا هو تشغيل الوكيل. يقرر المراقب الإيقاف عندما يتجاوز تقدير خطر الفشل العتبة المحددة.

يقوم التدريب على مسارات مكتملة سابقًا وعلى أحكام المُتحقِّق. تُسنَد نتيجة التشغيل بأكمله، نجاحًا أو فشلًا، إلى نوافذ محلية أسبق منه، أي إلى آخر عدة استدعاءات للأدوات. وبذلك تتكوّن عينة تدريب دون أي تأشير يدوي. ويقيّم نموذج لغوي جرى ضبطه هذه النافذة في تمريرة أمامية واحدة، دون استدلال طويل ودون توليد نص. وتُضبط العتبة على التشغيلات الناجحة كي لا يقطع المراقب تلك التي كانت ستصل إلى حل. ويبقى الوكيل المنفِّذ على حاله: يُوصَل المراقب من الخارج، ولا يتطلب تغيير الوكيل أو تعليماته (prompts).

دُرّب النموذج على مسارات من عائلة GPT في SWE-rebench. واختُبر على SWE-bench Verified وعلى مجموعة فرعية من SWE-bench Pro، وكان الوكلاء المنفِّذون من GPT ومن Claude على حد سواء. وكانت أساس المقارنة ستة قضاة LLM عامّي الغرض، أُعطوا النوافذ نفسها تمامًا.

ماذا أظهرت القياسات

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

• تكلفة كل حل محفوظ على Verified: −4,5% مقارنة بتشغيل جميع المهام حتى النهاية، مع الإبقاء على 99% من التشغيلات الناجحة.
• على المجموعة الفرعية Pro: حتى −31%، ومع أساس Qwen3-8B حتى −48%.
• تكلفة الفحص: أقل بمقدار رتبة إلى رتبتين من حيث الحجم مقارنة بأي من القضاة الستة.
• في جميع التكوينات الأربعة تكون تكلفة الحل المحفوظ مع StopLoss أقل منها مع أي سياسة قائمة على القضاة.
• الوكيل المنفِّذ لا يتغير، وتُضبط العتبة على التشغيلات الناجحة.

الفرق بين المعيارين دالّ. على Verified المهام أرخص ولا يوجد ما يُوفَّر تقريبًا: 4,5% رقم متواضع. أما على Pro، حيث يكلّف كل تشغيل فاشل أكثر بوضوح، فإن قطع الإخفاقات يعوّض كلفته بقدر أكبر. ويزداد الأثر مع ارتفاع ثمن الخطأ.

أين يفيد ذلك عمليًا

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

لا يتطلب هذا النهج الوصول إلى دواخل الوكيل المنفِّذ، ويعتمد على بيانات تملكها أغلب الفرق أصلًا: سجلات المسارات ونتائج الاختبارات. ويمكن إعادة تدريب مراقب صغير على تشغيلات الفريق نفسه واختيار عتبة تناسب نسبة مقبولة من النجاحات الضائعة. وفي الورقة تبلغ هذه النسبة 1% على Verified.

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