من 6.7% إلى 68.3% في معدل نجاح المهام: الـ harness وليس النموذج هو ما صنع فارق الـ 10 أضعاف
ما كشفته نتائج Terminal Bench من LangChain وتجارب تنسيق hashline. السبب في انقلاب ترتيب لوحة المتصدرين مع النموذج ذاته يعود إلى ثلاثة عوامل: الـ prompt، والأدوات، والـ middleware.
بلغ معدل نجاح Grok Code Fast في معيار الترميز 6.7%. ثم جرى استبدال تنسيق التحرير وحده دون تغيير النموذج، فارتفع المعدل إلى 68.3%. لم تُمسّ معاملات النموذج ببت واحد.
خلال فترة العطلة، جربت تشغيل وكلاء الذكاء الاصطناعي بنفسي ومررت بتجربة مماثلة. وتيرة إصدار النماذج مذهلة لكنها مرهقة، غير أن ما أحدث الفارق الجذري في الأداء الفعلي لم يكن النموذج في حد ذاته. بل كان الـ harness المحيط بالنموذج، أي مزيج system prompt وتهيئة الأدوات والـ middleware.
النموذج ذاته، ترتيب مختلف
شغّل فريق LangChain وكيل الترميز الخاص بهم على Terminal Bench 2.0. أبقوا على GPT-5.2-Codex كما هو وعدّلوا فقط system prompt وتهيئة الأدوات والـ middleware. ارتفع الأداء من 52.8 إلى 66.5، وتقدم الترتيب من خارج المرتبة 30 إلى ضمن أفضل 5. تكلفة التدريب: صفر.
كان جوهر التحسين في توزيع ميزانية الاستدلال. استخدام xhigh على جميع المهام بشكل موحد أعطى 53.9% فقط، لكن تقسيم المهام وفق صعوبتها بنمط xhigh-high-xhigh رفع الأداء إلى 66.5%. المشكلات التي كانت تفشل بسبب انتهاء المهلة الزمنية حُلّت بهذه الاستراتيجية في التوزيع. النموذج ذاته، ميزانية التوكن ذاتها، لكن طريقة التخصيص اختلفت.
الكفاءة الحقيقية كانت مختبئة خلف تنسيق التحرير
طوّر أحد مطوري الوكلاء مفتوحي المصدر طريقة تحرير تُعرف بـ hashline. عند قراءة الملف، يُضاف وسم hash مؤلف من 2-3 أحرف لكل سطر، وعند التعديل يستند النموذج إلى تلك الوسوم فقط.
في الطريقة التقليدية، كان على النموذج إعادة إنتاج النص الأصلي حرفاً بحرف. خطأ في مسافة واحدة يعني الفشل. من استخدم وكلاء الترميز يعرف عذاب رسالة “String not found” المتكررة. hashline يتجاوز هذه المشكلة من خلال بنيته الهيكلية.
كانت النتائج لافتة. قفز Grok Code Fast من 6.7% إلى 68.3%، وانخفضت توكنات الإخراج لـ Grok 4 Fast بنسبة 61%. GPT-4 Turbo ارتفع من 26% إلى 59% بمجرد تغيير التنسيق، وتجاوز Gemini 3 Flash أعلى نتائجه السابقة بفارق 5 نقاط مئوية. كل ذلك دون أي تكلفة تدريب، بل بتغيير واجهة التحرير فقط.
بدون حلقة التحقق يتوقف العمل عند الإجابة الأولى
هناك نمط فشل شائع: يكتب الوكيل كوداً، يقرأه من جديد، يحكم بأنه مقبول، ثم ينتهي دون تشغيل أي اختبار.
أضاف فريق LangChain middleware يفرض التحقق من المهمة مقارنةً بالمواصفات قبيل إنهاء الوكيل مباشرة. كما يكشف middleware منفصل “حلقة الدوام” التي يتكرر فيها تحرير الملف ذاته، ليدفع الوكيل نحو إعادة النظر في النهج. لولا هذين العنصرين لكان هامش التحسن أضيق بكثير. إعطاء الوكيل هيكل المجلدات والأدوات المتاحة مسبقاً، وتحذيرات ميزانية الوقت لحثه على الدخول في مرحلة التحقق، كانا أيضاً ذا أثر ملموس.
النماذج الأرخص أكثر حساسية للـ harness
MiniMax M2.5 وKimi K2.5 سريعة وبارعة في استخدام أدوات الوكلاء، وأسعارها أدنى بكثير من النماذج الكبيرة. في المقابل، معرفتها الأساسية أقل مقارنة بالنماذج الأمريكية الكبيرة. MiniMax بدت منذ البداية كأنها مدرّبة بشكل خاص للعمل مع الوكلاء، وهو خيار منطقي حين تكون الموارد محدودة فتختار التخصص على العمومية، وانتشارها يتسارع على منصات مثل Openclaw بفضل سعرها المنخفض.
تُظهر نتائج معيار hashline أن النماذج الأضعف شهدت تذبذباً أكثر حدة في الأداء عند تغيير التنسيق. MiniMax تضاعف معدل نجاحها وأكثر بعد تطبيق hashline. التكلفة الإجمالية للمعيار كانت نحو 300 دولار.
المعيار ليس الواقع الفعلي
ثمة تحفظ جدير بالإشارة. Terminal Bench ومعيار hashline كلاهما قياسات في بيئة محكومة. في الإنتاج الفعلي توجد متغيرات أكثر بكثير: حجم قاعدة الكود، تعارض الاعتمادات، متطلبات غامضة. ما إذا كان الوكيل الذي سجّل 66.5% سيحافظ على أدائه في مشروع legacy يتجاوز 100,000 سطر لم يُتحقق منه بعد. فاعلية تحسين الـ harness واضحة، لكن ترجمة ترتيب المعيار مباشرةً إلى أداء فعلي ينطوي على مخاطرة.
مع ذلك، الاتجاه واضح. ثمة نطاق بالتأكيد يتفوق فيه تصميم الـ harness على اختيار النموذج من حيث العائد على الاستثمار. قدر كبير مما نراه اليوم في ترتيب المعايير لا يعكس قدرة النموذج بقدر ما يعكس جودة الـ harness.
انضم إلى النشرة الإخبارية
احصل على تحديثات حول أحدث مشاريعي ومقالاتي وتجاربي في الذكاء الاصطناعي وتطوير الويب.