ورقة PAUSE: إيقاف وكيل البرمجة قبل أول تعديل في الكود وإعطاؤه خطة يحسّن نتائجه على SWE-bench

نشر Viral Patel وBoyin Tan وJason Xue وYoucheng Sun في 21 أكتوبر 2026 ورقة على arXiv بعنوان PAUSE: Search-Free Steering of Coding Agents Before Their First Source-Code Edit. وتنطلق من ملاحظة بسيطة: وكيل البرمجة (coding agent) يصل إلى أول تعديل فعلي في الكود بعد نحو 60% من مساره. وقبل ذلك يستكشف المستودع، ويعيد إنتاج الخلل، ويجرّب.

والفكرة التي جرّبها الباحثون أن يُوقَف أول طلب تعديل، ثم يقرأ نموذج ثانٍ المهمة والمحادثة حتى تلك اللحظة ويكتب خطة إصلاح واحدة. بعدها يكمل الـ agent نفسه بالسياق نفسه وفي المجلد نفسه. وفي التجربة كان Qwen3-coder هو المنفّذ وGPT-5.6 Sol هو المخطِّط.

وجاءت النتيجة تحسنًا بنسبة 16.8% على SWE-bench Verified، و14.7% على النسخة متعددة اللغات. ولا يوضح ملخص الورقة إن كانت هذه فروقًا نسبية أم نقاطًا مئوية، فهي مؤشر على الاتجاه لا رقم دقيق.

وقارنت الورقة الطريقة بطريقتين أخريين. فمقارنة بـ LivePlan، التي تتفعل بقواعد جاهزة، جاءت PAUSE أفضل بـ 3.2% على Verified و3.7% على النسخة متعددة اللغات، بتكلفة مخطِّط متقاربة. ومقارنة بـ SICA، التي تراقب الـ agent على فترات، جاءت النتيجة متقاربة لكن بتكلفة مخطِّط بين 11% و15% فقط.

وفي تجربة ثانية تمكنت الطريقة من إصلاح 35.4% من المهام التي فشل فيها الـ agent تمامًا، باستكمالها من النقطة نفسها، وبتوكنز أقل بين 33% و41% مقارنة بإعادة البدء.

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