الهارنس مقابل السياق: الفرق بين هندسة الهارنس وهندسة الأوامر وهندسة السياق

باختصار: ثلاث طبقات لمهمة واحدة

هندسة الأوامر تجيب عن سؤال «كيف أطلب؟»، وهندسة السياق عن «ما الذي يحتاج النموذج إلى معرفته الآن؟»، وهندسة الهارنس عن «في أي بيئة يعمل الوكيل، وكيف يعرف أنه أخطأ؟». هذه ليست مناهج متنافسة، بل طبقات متداخلة: الأمر الجيد جزء من السياق الجيد، والسياق المُحكم نظام فرعي من الهارنس.

يحدث الخلط لأن الثلاثة تغيّر سلوك النموذج، لكن أدوات التأثير فيها مختلفة. إذا لم يستطع الوكيل تشغيل الاختبارات، فلن تحل أي صياغة للأمر المشكلة. وإذا نسي الوكيل قرارات الأمس، فالمشكلة ليست في نص الطلب بل في مكان حفظ الحالة. ويوفر فهم الفرق بين harness vs context engineering أسابيع من العمل، لأنك لن تعيد كتابة التعليمات حين يكون المعطوب هو البيئة.

هندسة الأوامر: صياغة الطلب الواحد

تتعامل هندسة الأوامر مع نص الطلب: الدور، والمهمة، وشكل الإخراج، والأمثلة (few-shot)، والقيود، وترتيب الخطوات. وحدة العمل هي استدعاء واحد للنموذج. والنتيجة تُقيَّم من خلال الإجابة: هل هي صحيحة؟ هل بالشكل المطلوب؟ هل انحرف النموذج عن المسار؟

ومن الحيل المعتادة:

• وصف شكل الإخراج بوضوح (مخطط JSON، جدول، قائمة نقطية)؛
• إعطاء مثالين أو ثلاثة بصيغة «مدخل → مخرج صحيح»؛
• طلب الاستدلال خطوة بخطوة قبل الإجابة؛
• فصل التعليمات عن البيانات بفواصل واضحة؛
• سرد ما لا يجب فعله.

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

هندسة السياق: ما الذي يدخل نافذة النموذج

هندسة السياق هي إدارة محتوى نافذة السياق في كل خطوة. النافذة محدودة، والوكيل في الجلسات الطويلة يتراكم لديه مخرجات الأوامر ومحتوى الملفات وسجل المحادثة. والهدف أن يكون في النافذة في كل لحظة ما يلزم، ولا يكون فيها ما لا يلزم.

وتشمل:

• الانتقاء: أي ملفات ووثائق ومقاطع شيفرة تُحمَّل حسب المهمة (البحث، وRAG، والقراءة عند الطلب)؛
• الضغط: تلخيص السجل الطويل، واقتطاع مخرجات الأوامر، وضغط الجلسة؛
• البنية: ملف التعليمات بوصفه فهرسًا، والتفاصيل في وثائق مستقلة يُفتح منها ما يلزم؛
• العزل: إسناد المهام الفرعية إلى وكيل فرعي بسياق خاص ونظيف، حتى لا يتلوث المسار الرئيسي.

مقياس هندسة السياق هو: هل وجد الوكيل القاعدة أو الحقيقة الصحيحة في اللحظة المناسبة، وهل غرق في الضوضاء؟ العَرَض المعتاد للمشكلة أن تكون القاعدة مكتوبة في CLAUDE.md ويخرقها الوكيل، لأن الملف من خمس صفحات، فتضيع القاعدة بين تعليمات النبرة وتفضيلات كبير المطوّرين.

هندسة الهارنس: كل ما يحيط بالنموذج

الهارنس (harness، أي «اللجام») هو بيئة عمل الوكيل. النموذج مكوّن واحد فيها، يدخل الحلقة مرة واحدة. أما الباقي، أي التعليمات والأدوات والبيئة والحالة والتغذية الراجعة، فيصممه المهندس. وهندسة الهارنس مسؤولة عن أن يتمكن الوكيل ليس فقط من كتابة الشيفرة، بل من تشغيلها والتحقق منها ومعرفة أخطائه، ومواصلة العمل في الجلسة التالية من المكان نفسه.

ويمكن تفكيك الهارنس إلى خمسة أنظمة فرعية:

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

جدول المقارنة

لماذا لا تكفي الأوامر والسياق وحدهما

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

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

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

الخلاصة: الأوامر والسياق يؤثران في ما يفكر فيه النموذج. أما الهارنس فيؤثر في ما يستطيع النموذج فعله، وفي ما يعرفه بعد الفعل.

لماذا لا يحل تغيير النموذج المشكلة

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

والهارنس لا يصبح قديمًا مع صدور نماذج جديدة. فالتعليمات والبيئة القابلة للتكرار والفحوصات تحتاج إليها أي نموذج. ما يتغير هو مقدار التوجيه خطوة بخطوة الذي يمكن الاستغناء عنه: النموذج القوي يكفيه الثوابت («البيانات تُتحقَّق منها عند حدود المجال») لا التعليمات الخطوة بخطوة.

كيف تعرف الطبقة التي تحتاج إلى إصلاح

التشخيص من الأعراض أسرع من أي تجربة:

من أين تبدأ في بناء الهارنس

إذا بنيت من الصفر، فالترتيب المعقول هو: التغذية الراجعة ← التعليمات ← الحالة ← البيئة ← الأدوات. تأتي التغذية الراجعة أولًا لأنك بدونها لا تستطيع قياس أثر أي تغيير آخر. فما لم يوجد أمر يجيب بصدق عن سؤال «هل يعمل؟»، ستبقى تقييمات أي تحسين في التعليمات مجرد انطباعات.

وهذه نقطة انطلاق دنيا:

# AGENTS.md (مقتطف)
## كيف نتحقق
- make check   # المدقق، والأنواع، واختبارات الوحدة
- make e2e     # سيناريوهات من طرف إلى طرف
لا تُعتبر الميزة مكتملة إلا إذا انتهى الأمران برمز الخروج 0.

## القواعد
- MUST: كل استعلامات SQL معاملة كمتغيرات
- MUST: شغّل make check قبل الإيداع
- تفاصيل الدفع: docs/payments.md (اقرأها فقط عندما تتعلق المهمة بالدفع)

لاحظ السطر الأخير: هذا هو هندسة السياق داخل الهارنس. ملف الدخول خريطة لا كتاب، والتفاصيل تُحمَّل بشرط «عندما».

كيف تقيس مساهمة كل جزء

للهارنس مقياس لا يملكه الأمر: نسبة المهام التي أعلن الوكيل اكتمالها ولم يؤكدها فحص مستقل. يسمى هذا فجوة التحقق (verification gap). خذ 10 مهام متتالية، وسجّل عند كل منها هل قال الوكيل «اكتمل» وهل اجتاز التحقق، فتحصل على رقم يمكن مقارنة التغييرات به.

ولمعرفة أي نظام فرعي يؤثر فعلًا، تستخدم تحليل الاستئصال (ablation): تثبت النموذج ومجموعة المهام، ثم تعطّل جزءًا واحدًا من الهارنس في كل مرة، وتنظر إلى مقدار الانخفاض. وهناك أمران يجب تذكرهما. الأول أن الاستئصال ليس الخطوة الأولى، بل تبدأ بسجل الإخفاقات لتحديد عنق الزجاجة، ثم يأتي الاستئصال للتأكيد. والثاني أن عدم الانخفاض عند إزالة مكوّن لا يعني أنه غير مفيد، فربما لم تستخدمه مجموعة المهام الحالية.

أخطاء شائعة

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

الخلاصة

هندسة الأوامر تحسّن الصياغة، وهندسة السياق تنتقي المعلومات داخل نافذة النموذج، وهندسة الهارنس تصمم البيئة الكاملة للوكيل، بما فيها الأدوات والبيئة والحالة والفحوصات. وحين يعمل الوكيل فترات طويلة ويعدّل الشيفرة بنفسه، يصبح الهارنس هو الأهم، لأنه يحوّل «قال الوكيل إنه اكتمل» إلى «أكّد النظام أنه يعمل». لذلك ليست المسألة اختيارًا بين harness vs context engineering: السياق جزء من الهارنس، والمطلوب إصلاح الطبقة التي تشير إليها الأعراض. وقد شرحنا هذا الموضوع عمليًا في دورة هندسة الهارنس، على مشروع حقيقي للواجهة الخلفية للدفع.