وكيل بنافذة 16K يحقق 70.2% في SWE-bench Verified مع إعادة تعيين السياق في كل خطوة

اعتاد الجميع أن الوكيل الذي ينفذ مهمة طويلة يحتاج إلى نافذة سياق ضخمة: كلما اتسعت كان ذلك أفضل. لكن ورقة جديدة بعنوان «You don't need long context» (بيلتشاك ومولتشانوف وآخرون) تؤكد العكس: تكفي نافذة قصيرة إذا بُني الإطار التشغيلي (harness) بشكل صحيح.

ما الذي اقترحه المؤلفون

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

هناك وضعان. يقوم End-of-Conversation Compaction (EoCC) بضغط الحوار عند بلوغ حد معين من الرموز. أما Single-Action Compaction (SAC) فهو أكثر جذرية ويعيد تعيين السياق بعد كل إجراء.

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

النتائج

في اختبارات الأفق الطويل والمستندات الكبيرة، تحافظ النافذة القصيرة على الدقة، بل تحسّنها أحيانًا. وتنخفض تكلفة فك الترميز على GPU بما يصل إلى 7 مرات عند الانتقال من 256K إلى 16K رمز. وحتى في الوضع الصارم SAC، يحل Claude Opus 4.5 نسبة 70.2% من مهام SWE-bench Verified.

ومن الجيد أيضًا أن المؤلفين وصفوا صيغة الملخص. إنها handoff brief من ست أجزاء: الهدف، والحقائق المتحقَّق منها منفصلة عن الفرضيات، والتغييرات المنفَّذة، والاختبارات التي أُجريت، والمآزق، وخطة الخطوات التالية. ويحمي الفصل بين الحقائق والفرضيات من أن يتحول التخمين، بعد إعادة روايته، إلى «حقيقة ثابتة».

مهارة (skill) لـ Claude Code

لا توجد شيفرة مرفقة بالورقة، لذلك طلب جمال حميدون من gonzo-obzory من Claude بناء مهارة تعيد إنتاج النهج. وهي موجودة في مستودع short-context-agent. تعلّم المهارة الوكيل ألا يحمّل الملفات الكبيرة في السياق، بل يبحث فيها ويقرأها ضمن نوافذ، وأن يحتفظ بذلك الـ brief في المهام الطويلة متعددة الخطوات.

ما زال Claude Code هو من يتحكم في إعادة تعيين السياق: ضغط تلقائي عند حد معين، أو /compact أو /clear يدويًا. ويعيد hook في الإضافة وضع الـ brief، فيواصل الوكيل من حيث توقف. وهذا هو وضع EoCC. أما وضع SAC فلا يمكن إعادة إنتاجه في Claude Code، وهو موجود فقط في الإطار المرجعي ضمن المستودع، إلى جانب EoCC وbaseline بلا ضغط. ويحذّر المؤلف بصراحة بأنه لم يختبر بعناية، وأن الأخطاء واردة، والـ PR مرحَّب بها.

القيود

أولًا: إعادة تعيين السياق تكسر ذاكرة المطالبات المؤقتة (prompt cache). فكل جلسة جديدة تبدأ ببادئة باردة، لذا قد لا توفّر المال حتى لو كان وفر GPU في فك الترميز حقيقيًا. والمكسب بمقدار 7 مرات يخص تكلفة فك الترميز، لا فاتورتك لدى المزوّد.

ثانيًا: قد تنهار النماذج المفتوحة الضعيفة. فإذا كان النموذج مسهبًا، فإنه يستنفد ميزانية النافذة الصارمة قبل أن ينهي المهمة. ولا يمكن نقل نتائج Opus 4.5 تلقائيًا إلى أي نموذج.

ثالثًا: المهارة غير رسمية وخام، وليست تنفيذًا موثّقًا من المؤلفين.

ماذا تفعل عمليًا

إذا كنت تبني وكلاء، فتحقق من ثلاثة أمور. لا تجبر الوكيل على قراءة الملفات الكبيرة كاملة، بل دعه يبحث ويقرأ ضمن نوافذ. وأنشئ ملخصًا صريحًا يفصل بين الحقائق والفرضيات. واحسب التكلفة الفعلية مع احتساب فقدان الذاكرة المؤقتة، لا حجم النافذة وحده. وبالنسبة إلى النماذج المستضافة ذاتيًا، تبدو الفكرة أكثر إثارة: فتدريب نموذج بنافذة 16K–50K وتشغيله أرخص بكثير من السعي وراء مليون رمز.