Harness الشركة الأصلية ليس دائماً الإجابة الفائزة: في عصر النماذج المفتوحة، اختر النموذج والـHarness كل واحد على حدة

نُشرت الفكرة الأساسية أول مرة على X، وهذه المقالة هي النسخة الكاملة من الحجة، مع خريطة تحديد مواقع لخمسة Harnesses.

ردّ فعل معظم الناس الأول عند اختيار Coding Agent طبيعي تماماً: تستخدم Claude فتركب Claude Code؛ تستخدم GPT فتركب Codex؛ تستخدم GLM فتركب ZCode؛ وتستخدم DeepSeek فطبعاً تعطي الأولوية للـHarness الخاص بـDeepSeek نفسه.

هذا التفكير منطقي تماماً في الحقيقة. أكبر ميزة للشركة الأصلية أنها الأكثر دراية بنموذجها.

ميزة الشركة الأصلية حقيقية

ما نوع الـPrompt الذي يحبه النموذج، وأي تصميم للـTool Schema هو الأكثر استقراراً، وكيف تنظّم السياق الطويل، وما القدرات التي يضيفها الإصدار الجديد، وأين يتعثر بسهولة أكبر — الشركة الأصلية تعرف كل ذلك عادةً قبل أي طرف ثالث.

لذا في منتجات مثل Claude Code وCodex، حيث يتحسن النموذج والـHarness معاً على المدى الطويل، غالباً ما يكون الجمع الأصلي هو الإجابة الأقوى للإصدار الحالي. ولن أنازع في ذلك.

لكن تدريب النموذج وبناء الـHarness هندسان مختلفتان تماماً

عندما نصل إلى نماذج مفتوحة مثل DeepSeek وGLM، تبدأ الأمور في أن تصبح مثيرة — لأن تدريب نموذج جيد وبناء Harness جيد هما في الواقع هندسان مختلفتان تماماً.

وحين يبدأ Coding Agent بالعمل فعلياً، تظهر كومة من المشكلات التي تتجاوز النموذج نفسه:

• كيف تُقرأ الملفات وكيف يُعدَّل الكود
• كيف يُضبط الـAgent Loop وكيف يُضغط الـContext
• كيف يُستثمر الـCache وكيف يُتعافى بعد خطأ الـTool Call
• كيف تُجدول الـSubagents وكيف تُدار الصلاحيات

جودة هذه الجوانب تؤثر مباشرة في مدى جودة استخدام النموذج نفسه في النهاية. النموذج نفسه في Harness آخر قد تكون التجربة فيه فرقاً بين سماء وأرض.

المشكلة الأكبر: النماذج تتحدّث بسرعة كبيرة

اليوم GLM قوي، والشهر القادم قد يطلق DeepSeek نموذج Flash أقوى، وبعد فترة يلحق به نموذج جديد.

إذا كان سير عمل البرمجة كله مرتبطاً بمنتج شركة أصلية واحدة، فتبديل النموذج يعني غالباً تبديل الأدوات والعادات معه. الإعدادات والذاكرات وسير العمل الذي ضبطته لأشهر — كلها تُهدم من جديد.

هنا تكمن قيمة Harnesses الطرف الثالث: يمكنك تثبيت أدواتك وSkills وMCP والصلاحيات وسير العمل المألوفة لديك، واستبدال النموذج تحتها فقط. اليوم تجري DeepSeek، غداً تستبدل بـGLM، وبعده غيّر لغيرها — بيئة عملك لا تُهدم من الصفر.

خريطة مواقع خمسة Harnesses

لنوضح مواقع الخمسة الرئيسيين (بحسب تجربة استخدامي حتى أواخر أغسطس 2026):

Pi: فلسفة متبسطة؛ الـHarness يتدخل في النموذج بأقل قدر ممكن. خفيف، سريع، تكلفة Token منخفضة، وقابلية تشكيل عالية جداً. مناسب ليكون أساس Agent طويل الأمد خاص بك — بسيط، نظيف، قابل للتعديل كما تشاء.

OMP: يواصل إضافة قدرات برمجة ثقيلة فوق Pi مثل LSP وDebugger وBrowser وAST، وكأنه يلبس الـAgent بيئة IDE كاملة. مناسب لمن يكتب كوداً بكثافة حقيقية ويحتاج تنقلاً معقداً داخل الـRepo.

DeepSeek Harness: الأبعد في هذا الطريق، فلسفة Everything is Plugin؛ الـAgent Loop والأدوات والصلاحيات والـPreset والواجهة كلها تُفكَّك وتُعاد بربطها. مناسب لمن يعبث بمعمارية الـAgent والـPreset وأنظمة الـMulti-Agent وRuntime الجيل القادم. جرّب وضع PTC أكثر — أسرع وأكثر توفيراً للـToken.

OpenCode: الأكثر توازناً حالياً؛ مفتوح المصدر، Providers كثيرة، منظومة كبيرة، والـClient/Server وتطبيق سطح المكتب والـSubagent ناضجة. مناسب لمن يريد مجموعة Coding Agent عامة ومتعددة النماذج ناضجة.

Command Code: طريق مختلف تماماً — يحب أن يغطي نقاط ضعف النموذج. معاملات الـTool Call المكتوبة خطأ تُصلَّح محلياً؛ قراءة الملفات المكررة تُزال تكرارها؛ الجلسات الطويلة تحافظ على Stable Prefix لرفع الـCache Hit؛ وحين يوشك الـContext على الانفجار تُجرى Compaction. هذه الفكرة تحقق أقصى قيمة مع نماذج الشغل الشاقة مثل DeepSeek V4 Flash وGLM-5.3 Flash: النموذج أضعف قليلاً؟ الـHarness يعوّض عنه.

اختياري

إذا كان المعيار الوحيد هو القابلية للتشكيل على المدى الطويل، فما زلت أفضل Pi. لكن لو طُلب مني اليوم أن أشغل DeepSeek V4 Flash أو GLM-5.3 في عمل جاد، لجرّبت Command Code حقاً — اقتران النموذج والـHarness يُضبط حسب المهمة، لا حسب المعسكر.

في عصر النماذج المفتوحة، أصبح اختيار النموذج والـHarness منفصلَين تماماً. توقف عن السؤال «بأدوات مَن تُشغّل نموذج مَن؟»، وابدأ بالسؤال «في أي Harness يعطي هذا النموذج أفضل أداء؟».