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

هندسة الطوق (Harness Engineering) مصطلح انتشر بسرعة في فبراير 2026. ففي 5 فبراير 2026 أطلقه ميتشل هاشيموتو (مطوّر الطرفية Ghostty والمؤسّس المشارك لـ HashiCorp) على عادة بعينها: كلّما أخطأ الوكيل، تبني حلًّا يمنعه من تكرار هذا الخطأ أبدًا. وبعد ستة أيام وضعته OpenAI في عنوان تقرير لفريق Codex. وكانت Anthropic قد نشرت قبل ذلك تصاميم للآليات المُحيطة بالوكلاء طويلة التشغيل تحت اسم «الطوق». وإذا كان عام 2025 هو عام القول إنّ هندسة السياق تأتي بعد المُوجِّهات، فإنّ هندسة الطوق تتناول الطبقة الأبعد من ذلك.

يستعرض هذا المقال ما تعنيه هندسة الطوق فعلاً، وكيف تختلف عن هندسة المُوجِّهات وهندسة السياق، والمكوّنات الستة التي يتألّف منها الطوق، وأطواقًا حقيقيّة نشرتها OpenAI وAnthropic، وقائمة تحقق عملية للتصميم، ومقارنة بين أبرز الأدوات اليوم — وهو الأساس الذي تحتاجه إن كنت جادًّا في استخدام وكلاء الذكاء الاصطناعي أو بنائهم.

1. ما هي هندسة الطوق (Harness Engineering)؟

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

وعلى وجه التحديد، يشمل ذلك:

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

تصميم كلّ ذلك معًا هو ما نُسمّيه هندسة الطوق. فبدلاً من تدريب نموذج اللغة أو تحسينه، فإنّها حِرفة رفع المنفعة الواقعيّة عبر هندسة كلّ ما يُحيط بالنموذج. إنّ Claude Code وCursor وDevin وCodex CLI تعمل جميعها تقريبًا على نفس النماذج، ومع ذلك يتباعد سلوكها وأداؤها تباعدًا حادًّا بسبب الفرق في أطواقها.

أمّا أين تبدأ كلمة «الطوق» وأين تنتهي، فقد لخّصته جيّدًا بيرغيتا بوكلر من Thoughtworks على موقع martinfowler.com (2 أبريل 2026): الطوق هو كلّ ما في الوكيل عدا النموذج، أي Agent = Model + Harness. وتستخدم Anthropic الكلمة نفسها لخدمتها السحابيّة، إذ تصف Claude Managed Agents بأنّه طوق وكلاء قابل للضبط.

2. هندسة الطوق مقابل هندسة المُوجِّهات (Prompt Engineering)

لم تختفِ هندسة المُوجِّهات — لكنّ النطاق مختلف اختلافًا جوهريًّا.

إن كانت هندسة المُوجِّهات هي حِرفة «ماذا تقول للنموذج»، فإنّ هندسة الطوق هي حِرفة «ماذا تُعطي للنموذج وكيف تُشغِّله». الاثنتان ليستا متنافستين — بل متطبِّقتان. المُوجِّه ليس سوى مكوِّن واحد ضمن الطوق.

والمصطلح الآخر الذي يُخلط به كثيرًا هو هندسة السياق. ففي مقال بتاريخ 29 سبتمبر 2025 وصفتها Anthropic بأنّها الامتداد الطبيعي لهندسة المُوجِّهات. وتصف بوكلر بناء طوق لوكيل برمجة بأنّه شكل مُحدّد من هندسة السياق. ومعًا تتداخل الطبقات هكذا: المُوجِّه (ما تقوله) ⊂ السياق (ما يراه النموذج) ⊂ الطوق (ما يُعطى له، وكيف يُفحص عمله، وكيف يُوقَف). وما يخصّ الطوق وحده هو الجزء الذي يفحص النتائج آليًّا ويُعيد الأخطاء إلى الوكيل، مثل أدوات الفحص (linters) والاختبارات.

3. المكوّنات الستة للطوق

1. استخدام الأدوات (Tool Use)

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

• أسماء فعلية لا لبس فيها (مثل read_file).
• تمييز واضح بين الوسائط المطلوبة والاختياريّة، مع قيم افتراضيّة.
• رسائل خطأ مُهيكَلة عند الفشل (أخبر النموذج بما عليه فعله تاليًا).
• تحذيرات صريحة على العمليّات ذات الآثار الجانبيّة (المُدمِّرة).

2. إدارة السياق

انتباه النموذج محدود — ما تُريه إيّاه يُحدِّد ما يقوله. وعلى وجه التحديد:

• تصفية الصلة: استخرج فقط الأجزاء ذات الصلة بالمهمّة، لا الملفات بكاملها.
• الضغط (Compaction): لخِّص المحادثات الطويلة للاحتفاظ بها.
• تكامل RAG: اجلب ما يلزم عبر البحث المتّجه.
• التخزين المؤقّت (Caching): قلِّل التكلفة على المُوجِّهات النظاميّة المتكرّرة باستخدام أدوات مثل ذاكرة المُوجِّهات لدى Anthropic.

ذو صلة: ما هو RAG؟

3. نظام الذاكرة

الاحتفاظ بالمعرفة عبر الجلسات. ملفّ CLAUDE.md الخاصّ بـ Claude Code، و.cursor/rules الخاصّ بـ Cursor، وAGENTS.md الخاصّ بـ Codex، كلّها أمثلة على ذاكرة المشروع. وفيما عدا ذلك:

• الذاكرة قصيرة المدى: تاريخ المحادثة الأخير.
• الذاكرة طويلة المدى: ملفّ المستخدم، القرارات السابقة.
• المعرفة الواقعيّة: قواعد معرفة خاصّة بمجال محدّد.

4. حلقة الوكيل (Agent Loop)

الجوهر الذي يجعل «وكيل الذكاء الاصطناعي» يعمل فعلاً. الصورة الأساسيّة هي دورة الإدراك ← الاستدلال ← الفعل ← الملاحظة:

1. استقبال هدف المستخدم.
2. تحليل الحالة الراهنة (جمع المعلومات بالأدوات إن لزم الأمر).
3. تخطيط الإجراء التالي.
4. التصرّف عبر أداة.
5. ملاحظة النتيجة؛ التحقّق من تحقّق الهدف.
6. التكرار إن لم يتحقّق، والإنهاء إن تحقّق.

مدى ذكاء وكيلك يعتمد على ما إذا كنتَ قد أدمجت إعادة التخطيط، والنقد الذاتيّ، وتفكيك الأهداف الفرعيّة.

5. الحواجز الواقية (Guardrails)

الآليّات التي تمنع السلوك المنفلت. وكما يُبيِّن مقال لماذا يتجاهل الذكاء الاصطناعي قواعد .md، فإنّ فرض السلوك عبر البيئة أكثر موثوقيّة بكثير من الطلب اللطيف بالنثر:

• وضع الاعتماد: يُؤكّد إنسان قبل تنفيذ العمليّات الخطرة (مثل إعدادات الأذونات في Claude Code وأوضاع الاعتماد في Codex CLI).
• الصندوق الرمليّ (Sandbox): تقييد الوصول إلى نظام الملفات والشبكة.
• Hooks: فحوص اعتباطيّة قبل استدعاءات الأدوات وبعدها.
• تحديد المعدّل: تقليل الضرر إذا انفلت شيء عن المسار.

6. تجربة مستخدم المُخرجات

تقديم النتائج بصورة يستطيع المستخدم فهمها والتحقّق منها. عرض Markdown، الاستشهادات بالمصادر، كتل شيفرة بإبراز التركيب، البثّ المباشر، إظهار الاستدلال (التفكير)، المُخرجات المُهيكَلة (JSON)، وما إلى ذلك. إنتاج «الإجابة الصحيحة» وحده لا يكفي — مهمّة الطوق هي تقديمها بصورة يثق بها المستخدم ويستطيع التحقّق منها.

4. لماذا هندسة الطوق، ولماذا الآن؟

ثلاث قوى تدفع موجة الاهتمام بأعمال الطوق.

1. ثبت أنّ النموذج نفسه يُعطي نتائج مختلفة جدًّا بحسب ما يُحيط به. في تجربة نشرتها Anthropic في 24 مارس 2026، طُلب من نموذج Claude Opus نفسه، بجملة واحدة، بناء أداة لصنع ألعاب رجعيّة ثنائيّة الأبعاد. أنهى وكيل منفرد العمل في 20 دقيقة بتكلفة 9 دولارات، لكنّ المرحلة التي صنعها لم تكن قابلة للّعب. أمّا طوق مُقسَّم إلى مُخطِّط ومُولِّد ومُقيِّم فعمل 6 ساعات بتكلفة 200 دولار، وأنتج لعبة يمكن فيها تحريك الشخصيّة فعلًا (مع بقاء الفيزياء خشنة). كانت التكلفة أعلى بأكثر من 20 ضعفًا، لكنّ الفرق في الجودة كان كبيرًا أيضًا. وصار الاختيار بين الجودة والتكلفة قرارًا يخصّ الطوق بقدر ما يخصّ النموذج.

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

3. بدأ عمل المهندس نفسه يتغيّر. أفاد فريق Codex في OpenAI بأنّه بنى منتجًا داخليًّا خمسة أشهر دون سطر واحد مكتوب يدويًّا، حتّى بلغ نحو مليون سطر ونحو 1,500 طلب دمج (11 فبراير 2026). وخلص إلى أنّ العمل الأساسيّ انتقل من كتابة الشيفرة إلى تصميم البيئات وتحديد المقصد وبناء حلقات التغذية الراجعة. وتتنافس Claude Code وCodex وCursor وDevin وسائر المنتجات الكبرى في التصميم الواقع خارج النموذج.

5. أمثلة منشورة: ثلاثة أطواق حقيقيّة

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

1. فريق Codex في OpenAI: ملف AGENTS.md خريطة، والقواعد تفرضها أدوات الفحص

• أبقوا AGENTS.md فهرسًا من نحو 100 سطر، وجعلوا مجلّد docs/ في المستودع المرجعَ المعتمد للتصميم والخطط وملاحظات الجودة. فالملف الواحد الضخم كان يُزاحم المهمّة في السياق، ويتقادم بسرعة، ولا يمكن فحصه آليًّا.
• ولإبقاء الوثائق حديثة، تفحص أدوات الفحص وCI الروابط المتبادلة والبنية، ويبحث وكيل دوريّ عن الأوصاف التي لم تعد تُطابق الشيفرة ويفتح طلبات تصحيح.
• الطبقات، واتّجاه الاعتماديّات، والسجلّات المُهيكلة، والحدّ الأقصى لحجم الملفّات وغيرها تُفرض بأدوات فحص مُخصّصة واختبارات بنيويّة. ورسائل الخطأ تشرح طريقة الإصلاح صراحةً، ليقرأها الوكيل ويُصلح عمله بنفسه.

2. Anthropic: تصميم التسليم بين جلسات الوكلاء طويلة التشغيل

حين يمتدّ التطوير عبر نوافذ سياق كثيرة، كان الوكلاء يحاولون بناء الكثير دفعة واحدة، أو يُعلنون انتهاء العمل في منتصفه. فعالجت Anthropic (26 نوفمبر 2025) ذلك هكذا:

• الجلسة الأولى وحدها تُشغّل وكيل تهيئة بمُوجِّه خاصّ، يُعدّ قائمة الميزات (feature_list.json)، وسجلّ التقدّم (claude-progress.txt)، وملف init.sh لتشغيل خادم التطوير، وأوّل إيداع في git.
• كلّ جلسة لاحقة تقرأ سجلّ التقدّم وgit log لتفهم الوضع، ثمّ تُنفّذ ميزة واحدة فقط، وتنتهي بإيداع وتحديث للسجلّ.
• قائمة الميزات بصيغة JSON لا Markdown، لأنّ النموذج كان أقلّ ميلًا إلى إعادة كتابتها دون داعٍ. والحقل الوحيد المسموح بتغييره هو حقل النجاح/الإخفاق (passes).
• لا تُعلَّم الميزة منتهيةً إلّا بعد اختبارها من البداية إلى النهاية بأتمتة المتصفّح، كما يفعل المستخدم.

3. ميتشل هاشيموتو: لا يتكرّر الخطأ نفسه مرّتين

صاحب التسمية يعمل على نطاق أصغر. حين يرتكب الوكيل خطأً بسيطًا، يُضيف سطرًا إلى AGENTS.md؛ وفي مشروع طرفيّته Ghostty يُقابل كلّ سطر في هذا الملف سلوكًا سيّئًا سابقًا، وبذلك زالت تلك الأخطاء تقريبًا كلّها. وحين لا يكفي النصّ، يكتب سكربتات حقيقيّة — لالتقاط لقطات الشاشة، ولتشغيل اختبارات مُنتقاة — ويُسلّمها للوكيل.

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

6. قائمة تحقق عملية لتصميم طوق جيّد

7. مقارنة بين أبرز الأطواق

كلّ من هذه الأطواق يعمل على نماذج لغويّة متشابهة إلى حدّ بعيد (Claude / GPT / Gemini)، ومع ذلك تتباعد نقاط قوّتها تباعدًا حادًّا بسبب اختلاف فلسفات تصميم الطوق. «أيّ طوق؟» يهمّ أكثر من «أيّ نموذج لغويّ؟» — تلك هي ساحة المعركة الحقيقيّة في عصر الوكلاء.

8. الأنماط المضادّة (Anti-Patterns)

1. إضافة أدوات كثيرة جدًّا

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

2. حشو كلّ شيء في السياق

«أرِه كلّ شيء فقط، حرصًا على السلامة» نهج عكسيّ المفعول. مرِّر الأشياء عبر مرشّح صلة وأدرج فقط ما يلزم. السياق أداة لإبراز الإشارة المهمّة — لا خِزانة للتخزين.

3. تطبيق الأمان عبر المُوجِّهات وحدها

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

4. عدم مراجعة ما أضفته أبدًا

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

الخلاصة

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

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

الأسئلة الشائعة

س1. إذًا لم نعد بحاجة إلى هندسة المُوجِّهات؟

خطأ. ما زالت ضروريّة — كمكوّن واحد ضمن الطوق. فأوصاف الأدوات، والمُوجِّهات النظاميّة، ورسائل الأخطاء — كلّها أسطح لتصميم المُوجِّهات. ما تجاوزه الزمن هو عقليّة «سأُصلح هذا بمُوجِّه أفضل».

س2. ما الخطوة الأولى لتعلّم هندسة الطوق؟

خذ Claude Code أو Cursor ولا تكتفِ باستخدامه — غيِّر سلوكه بتعديل إعداداته. وإذا حوّلنا طريقة هاشيموتو إلى خطوات، فهي كالتالي:

1. دوِّن كلّ إخفاق للوكيل (عند أيّ تعليمة، وما الذي أخطأ فيه).
2. للإخفاقات البسيطة، أضف سطرًا إلى CLAUDE.md أو AGENTS.md أو .cursor/rules.
3. الإخفاقات المتكرّرة أو المُكلفة أوقفها آليًّا عبر الخطافات (Hooks) أو أدوات الفحص أو الاختبارات — واكتب طريقة الإصلاح في رسالة الخطأ.
4. اطلب من الوكيل المهمّة نفسها مرّة أخرى وتأكّد من زوال الإخفاق.

س3. هل الأطواق نفسها أُطر مثل LangChain؟

قريبة، لكن ليست متطابقة. فـالإطار هو عُدّة تنفيذ؛ بينما الطوق تخصّص تصميم وعقليّة. وLangChain، وLlamaIndex، وClaude Agent SDK، وما شابه، أدوات لبناء الأطواق.

س4. أبني طوقي الخاصّ أم أستخدم طوقًا موجودًا؟

في معظم الحالات، طوق موجود (Claude Code، Cursor، إلخ) مع التخصيص كافٍ. وبناء واحد من الصفر لا يكون منطقيًّا إلّا لمتطلّبات المؤسّسات، أو المجالات النوعيّة، أو التحسين الجذريّ للتكلفة.

س5. هل سيُصبح «مهندس الطوق» مُسمّى وظيفيًّا فعليًّا؟

لا يوجد بعدُ مُسمّى وظيفيّ مستقرّ. فقد كتب هاشيموتو نفسه أنّه لا يعرف إن كان هناك مصطلح مقبول على نطاق الصناعة. لكنّ فريق Codex في OpenAI يُفيد بأنّ العمل الأساسيّ للمهندس انتقل إلى تصميم البيئات وتحديد المقصد وبناء حلقات التغذية الراجعة — فمضمون العمل يتغيّر قبل أن يستقرّ المُسمّى.