LEASH يُسند الخطوات المعقدة إلى الوكيل القوي ويوفّر 19,2% على Opus 5

يقترح فريق LEASH طريقة تتيح تجنّب تشغيل النموذج المكلف في كل خطوة من خطوات وكيل computer-use. يعمل نموذج مفتوح ضعيف افتراضياً، ولا يتدخل النموذج القوي إلا حين «يتردد» الأول، ويبقى بعد تسلّمه زمام الأمر تحت المراقبة. على OSWorld حققت المنظومة المبنية على Qwen3.5-35B-A3B نسبة 73,66% من المهام الناجحة بتكلفة $0,4117 للمهمة الواحدة. أما Claude Opus 5 العامل بشكل دائم فسجّل 72,90%. وهذا يعني أن LEASH لا يقلّ عنه جودة، ويكلّف أقل بنسبة 19,2%.

المشكلة: مهام طويلة واستدلال مكلف

تتعامل الوكلاء التي تتحكم بالحاسوب مع مهام من عشرات الخطوات: فتح تطبيق، والبحث عن ملف، وتعديل الإعدادات، والتحقق من النتيجة. ويؤدي استخدام نموذج حدّي (frontier) في كل خطوة إلى تضخّم الفاتورة بسرعة. في المقابل، كثيراً ما يعجز نموذج open-weight صغير عن إنهاء المهمة بمفرده. يَعِد التصعيد من الضعيف إلى القوي بحل وسط، لكنه يصطدم بسؤال: متى تحديداً يجب استدعاء النموذج القوي؟ والإجابة تتطلب إشارة يمكن فحصها في كل خطوة بتكلفة شبه معدومة.

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

كيف تعمل طبقات LEASH الثلاث

يعمل الإطار دون تدريب، ويعتمد على الحالات المخفية للنموذج الضعيف. يقارن المؤلفون هذه الحالات بحالات من مسارات سابقة ناجحة وأخرى فاشلة. وكلما زاد تشابه الحالة الراهنة مع الحالات الفاشلة، ارتفع تقدير عدم اليقين. ويعيد المُقيِّم استخدام التنشيطات التي يحسبها النموذج أصلاً أثناء توليد الإجراء. ولا حاجة إلى forward pass إضافية ولا إلى مراقب مدرَّب منفصل.

تغذّي هذه الإشارة ثلاث طبقات:

• عدم اليقين الأولي بشأن المهمة: توجيه مبكر لتحديد ما إذا كانت هناك حاجة إلى النموذج القوي منذ الخطوة الأولى؛
• عدم اليقين على مستوى الخطوة: تصعيد أثناء التنفيذ حين يبدأ الوكيل الضعيف بالتخبّط؛
• المراقب الظلّي: يواصل مراقبة الوكيل القوي (black-box) بعد تسليمه زمام الأمر.

ويصف اسم LEASH («المقود») الفكرة بدقة: يُطلَق الوكيل القوي من مقوده عند الحاجة، ثم لا يُترك طليقاً تماماً بعد ذلك.

ما أظهره OSWorld

أُجريت التجارب على OSWorld مع أربعة نماذج أساسية (backbones) حديثة. النتائج بحسب نص الورقة البحثية:

• يتفوق LEASH باستمرار على الوكلاء الضعفاء العاملين بمفردهم؛
• عند نسبة التصعيد نفسها، يتقدم على التصعيد العشوائي بما يتراوح بين 6,55 و11,94 نقطة؛
• Qwen3.5-35B-A3B + LEASH: نسبة نجاح 73,66% وتكلفة $0,4117 للمهمة؛
• Claude Opus 5 في وضع always-on: 72,90%؛
• التوفير في الاستدلال مقارنةً بوضع always-on: 19,2%.

من البند الأخير يمكن تقدير أن التشغيل الكامل على Opus 5 يكلّف نحو $0,51 للمهمة. هذا حسابنا نحن، ولا ترد هذه الرقم في ملخص الورقة البحثية. أما فارق الدقة البالغ 0,76 نقطة على معيار واحد فمن الأفضل عدم المبالغة في تفسيره. لكن الاتجاه واضح: التوجيه الذكي يلحق بالنموذج الرائد في الجودة ويتفوق عليه في التكلفة.

أين يفيد هذا وأين العقبة

بالنسبة إلى الفرق التي تبني وكلاء فوق API لنماذج حدّية، يبدو هذا المخطط عملياً. يتولى نموذج open-weight محلي أو منخفض التكلفة الجزء الأكبر من العمل، ويُحتفظ بالاستدعاء المكلف للمواضع الصعبة. وكلما طالت السيناريوهات ظهر الأثر بوضوح أكبر: فالفاتورة تنمو مع عدد الخطوات، بينما لا يُفعَّل التصعيد إلا نادراً.

وهناك قيود أيضاً. فالطريقة تتطلب الوصول إلى الحالات المخفية للنموذج الضعيف، ولذلك لا تناسب إلا الخيار المستضاف ذاتياً (self-hosted) أو open-weight. كما تحتاج إلى قاعدة من المسارات السابقة موسومة بالنجاح والفشل، وإن لم يكن مطلوباً تدريب أي شيء. والتحقق مقتصر حتى الآن على OSWorld، ولا يُعرف كيف ستتصرف الإشارة على واجهات أخرى وفي تطبيقات غير معتادة. وقبل نقل LEASH إلى بيئة الإنتاج، يُستحسن بناء مجموعة مسارات خاصة بكم، ومعرفة مدى اتساق إشارة عدم اليقين مع حالات الفشل الفعلية في مهامكم.