ما هي هندسة الهارنس (Harness Engineering)؟ كيف تجعل وكيل الذكاء الاصطناعي أداة عملية

ما هي هندسة الهارنس بكلمات بسيطة

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

أقصر صياغة لهذه الفكرة هي:

الوكيل = النموذج + الهارنس

النموذج هو الأوزان نفسها، وقدرته على الاستدلال وكتابة النصوص أو الشيفرة. أما الهارنس فهو كل ما عدا ذلك: تعليمات النظام وملفات مثل CLAUDE.md وAGENTS.md، ومجموعة الأدوات (shell وتحرير الملفات وخوادم MCP)، والبيئة المعزولة (sandbox) التي تُنفَّذ فيها الأوامر، وملفات الحالة التي تبقى بين الجلسات، والاختبارات والمدققات (linters) والخطافات (hooks) التي تنبّه الوكيل إلى الأخطاء. إذا أزلت الهارنس، فلن يبقى سوى نافذة دردشة تجيب بالنص فقط.

لماذا يبدو الوكيل نفسه «خبيرًا» أحيانًا و«مبتدئًا» أحيانًا أخرى

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

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

الأعراض النموذجية للهارنس الضعيف

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

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

من الأخطاء الشائعة اعتبار الهارنس مجرد ملف يحتوي على تعليمات. في الحقيقة هو خمس آليات مختلفة، ولكل منها طريقة مختلفة في التعطل.

التعليمات

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

الأدوات

الوكيل لا يستطيع التحقق إلا مما يملك صلاحية الوصول إليه. إذا لم يستطع تشغيل المدقق (linter)، فلن تنفعه قاعدة تقول «شغّل المدقق قبل الإيداع». تُتاح الأدوات عبر القدرات المدمجة في الوكيل (قراءة الملفات وتعديلها وتنفيذ الأوامر)، وعبر MCP، وهو بروتوكول يمنح الوكيل وصولًا إلى قواعد البيانات والمتصفحات وأنظمة إدارة المهام.

البيئة

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

الحالة

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

التغذية الراجعة

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

الهارنس دورة مغلقة، وليس قائمة

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

التعليمات → النموذج → الأدوات → البيئة → التغييرات
                ↑                           ↓
                └── أحمر ── التحقق ─────────┘
                                ↓ أخضر
                            الحالة → (الجلسة التالية)

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

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

هذه المفاهيم متداخلة، وليست متنافسة.

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

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

يبدو بديهيًا أن نموذجًا ينجح في 95% من خطواته يكاد يكون مثاليًا. لكن مهام الوكيل تتكون من خطوات كثيرة، والأخطاء تتراكم. إذا كانت الخطوات مستقلة، فاحتمال اجتياز كل الخطوات بلا خطأ هو حاصل ضرب احتمالات الخطوات:

0.95 ^ 10 ≈ 0.60
0.95 ^ 20 ≈ 0.36
0.95 ^ 50 ≈ 0.08

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

مثال: الوكيل نفسه في مستودعين

المهمة: إضافة خصم بكوبون إلى الواجهة الخلفية للدفع المبنية على FastAPI.

بدون هارنس

يقرأ الوكيل بضعة ملفات، ويكتب دالة حساب الخصم، واختبار وحدة يختبر تلك الدالة وحدها. ينجح الاختبار، فيعلن الوكيل أن المهمة «اكتملت». لم يكن يعلم أن حساب المجموع النهائي للطلب يقع في وحدة أخرى، ولم يستطع تشغيل قاعدة البيانات ومحاكاة عملية الطلب كاملة. بعد يوم يتبين أن الخصم لا يُطبَّق في السلة.

مع الهارنس

في جذر المستودع ملف AGENTS.md من بضعة عشرات من الأسطر: كيفية تشغيل البيئة، وأوامر التحقق الإلزامية، وأين توجد بنية نظام الدفع. تُشغَّل البيئة بالأمر docker compose up -d. وفي المستودع ملف خطة فيه معيار إنجاز واضح: «سيناريو E2E لإتمام الطلب بكوبون يمر بنجاح». بعد كل تعديل يشغّل خطاف المدقق وفحص الأنواع، وقبل إعلان الاكتمال يجب على الوكيل تشغيل اختبار E2E.

# AGENTS.md (مقتطف)
## التحقق — إلزامي قبل كلمة «اكتمل»
make lint        # ruff + mypy
make test        # pytest، اختبارات الوحدة والتكامل
make e2e         # سيناريو إتمام الطلب

## MUST
- تُحسب المبالغ بالوحدات الصغرى كأعداد صحيحة (int)، ولا تُستخدم float أبدًا
- كل استعلامات SQL معاملة كمتغيرات (parameterized)
- لا تُعدَّل الترحيلات (migrations) المطبّقة في الإنتاج

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

من أين تبدأ

1. صِف كيف يتحقق الوكيل من عمله: حدد أمرًا إلى ثلاثة أوامر يجب عليه تشغيلها. التغذية الراجعة هي الأكثر تأثيرًا، لذا ابدأ بها.
2. اجعل البيئة قابلة للتكرار: تُشغَّل بأمر واحد، ويمكن الرجوع عنها بسرعة.
3. أنشئ ملف الحالة: الهدف، والمنجَز، والقرارات والطرق المسدودة، والخطوة التالية.
4. اختصر التعليمات إلى خريطة: أوامر التحقق، والقيود الصارمة، وروابط للوثائق التفصيلية.
5. سجّل إخفاقات الوكيل: عند كل فشل، دوّن أي نظام فرعي هو السبب. سيوضح لك السجل ما يجب إصلاحه لاحقًا.

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

الخلاصة

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