هندسة الحاضنة (Harness Engineering): بناء أنظمة حول وكلاء الذكاء الاصطناعي (2026)

ملخص سريع (TL;DR)

ما هي هندسة الحاضنة (Harness Engineering)؟

هندسة الحاضنة هي تخصص بناء الأنظمة، والأدوات، والقيود، وحلقات التغذية الراجعة حول وكلاء البرمجة بالذكاء الاصطناعي لجعلهم موثوقين ومنتجين.

صاغ هذا المصطلح Mitchell Hashimoto (المؤسس المشارك لشركة HashiCorp) واكتسب اهتماماً واسعاً عندما نشرت OpenAI مقالها حول Codex عن هذا الموضوع في أوائل عام 2026.

الفكرة الأساسية بسيطة:

الوكيل = النموذج + الحاضنة

يوفر النموذج الذكاء، بينما تجعل الحاضنة هذا الذكاء مفيداً. وغالباً ما تكون الحاضنة الأفضل أكثر أهمية من النموذج الأفضل.

لماذا تهمنا الآن؟

في عام 2025، تبنت جميع الفرق وكلاء البرمجة بالذكاء الاصطناعي. أما في عام 2026، فالفرق الفائزة هي التي قامت بـ هندسة بيئات الوكلاء الخاصة بها — ولم تكتفِ فقط باختيار أفضل نموذج.

مبدأ Mitchell Hashimoto التوجيهي:

"في كل مرة تجد فيها أن الوكيل يرتكب خطأً، استثمر الوقت لهندسة حل يضمن عدم تكرار الوكيل لهذا الخطأ مرة أخرى."

هذه ليست هندسة أوامر (prompt engineering)، بل هي هندسة أنظمة (systems engineering) للذكاء الاصطناعي.

الدليل: الحاضنة تفوق النموذج أهمية

أجرت LangChain تجربة منضبطة على Terminal Bench 2.0. ودون تغيير النموذج الأساسي، قاموا بتحسين دقة وكيل البرمجة الخاص بهم من 52.8% إلى 66.5% — أي تحسن بنسبة 26% — فقط عبر تحسين الحاضنة.

شملت التغييرات:

• ملفات سياق أفضل (AGENTS.md)


• قيود على المخرجات المهيكلة (Structured output constraints)


• حلقات التحقق الذاتي


• تحسين الأدوات

المكونات السبعة للحاضنة

1. هندسة السياق (Context Engineering)

هندسة السياق هي الأساس. هنا تمنح الوكيل خريطة لقواعد البيانات الخاصة بك، واتفاقياتك، وقيودك.

• ملفات CLAUDE.md / AGENTS.md في جذر المستودع (repo root)
• خرائط المجلدات ونظرة عامة على المعمارية
• قواعد نمط البرمجة واتفاقيات التسمية

# مثال على CLAUDE.md
## Architecture
- src/app/ — Next.js app router pages
- src/lib/ — shared utilities and API clients
- src/components/ — React components (co-located styles)

## Rules
- Use server components by default
- Never import from node_modules directly in components
- All API calls go through src/lib/api.ts

2. القيود المعمارية (Architectural Constraints)

بدلاً من أن تأمل أن يختار الوكيل المعمارية الصحيحة، افرضها عليه.

• معماريات طبقية صارمة يتم التحقق منها بواسطة linters
• اختبارات هيكلية تفشل إذا تم انتهاك الأنماط
• قيود الاستيراد (Import restrictions) عبر قواعد ESLint أو سكربتات مخصصة

3. الأدوات وخوادم MCP

يحتاج الوكلاء إلى أدوات ليكونوا فعالين. أفضل الحاضنات تبرز الأدوات الداخلية عبر:

• أغلفة واجهة السطر البرمجي (CLI wrappers) — فضل استخدام CLI المعروفة (git, docker, npm) على الأدوات المخصصة.
• خوادم MCP (Model Context Protocol) — اسمح للوكلاء باستدعاء APIs الداخلية، وقواعد البيانات، والخدمات الخاصة بك.
• الوصول إلى نظام الملفات — محدد بمجلدات معينة لمنع التلف العرضي.

4. الوكلاء الفرعيون وجدران حماية السياق

جلسات الوكلاء الطويلة تراكم سياقاً يؤدي في النهاية إلى تدهور الأداء — وهذا ما يسمى تعفن السياق (context rot).

الحل: وكلاء فرعيون مع جدران حماية للسياق.

• تقسيم المهام المعقدة إلى مهام فرعية منفصلة.
• تعمل كل مهمة فرعية في جلستها الخاصة بسياق جديد.
• تمرير النتائج المهيكلة فقط بين الوكلاء، وليس المحادثة الخام.

1. وكيل التهيئة (Initializer Agent) — يخطط للعمل، وينشئ قائمة الميزات.
2. وكيل البرمجة (Coding Agent) — ينفذ كل ميزة بشكل منعزل.

5. الخطافات والضغط العكسي (Hooks & Back-Pressure)

حلقات تغذية راجعة تلقائية تصطاد الأخطاء قبل أن تتراكم:

• خطافات ما قبل الالتزام (Pre-commit hooks) — فحص النوع (type-checking)، الـ linting، والتنسيق.
• مشغلات الاختبارات (Test runners) — يجب على الوكلاء تشغيل الاختبارات بعد كل تغيير.
• التحقق من البناء (Build verification) — الفشل السريع عند تعطل البناء.

6. حلقات التحقق الذاتي (Self-Verification Loops)

إجبار الوكلاء على التحقق من عملهم قبل وضع علامة اكتمال المهمة:

• تشغيل حزمة الاختبارات بعد التغييرات.
• التأكد من نجاح عملية البناء (build).
• التحقق من أن المخرجات تطابق المواصفات.
• التقاط لقطة شاشة والمقارنة (لأعمال واجهة المستخدم UI).

7. توثيق التقدم (Progress Documentation)

للمهام التي تستغرق وقتاً طويلاً (أكثر من 30 دقيقة):

• الاحتفاظ بملف تقدم يتتبع الخطوات المكتملة.
• عمل (commit) للعمل بشكل متكرر حتى تتمكن الجلسات اللاحقة من الاستمرار.
• استخدام قوائم مهام مهيكلة، وليس ملاحظات حرة.

نتائج من العالم الحقيقي

فريق OpenAI Codex

أنتج 3 مهندسين مليون سطر من الكود بدون كود مكتوب يدوياً على مدار 5 أشهر. بلغ متوسطهم 3.5 PR مدمج لكل مهندس يومياً — وهي إنتاجية مستحيلة بدون حاضنة ناضجة.

شملت حاضنتهم: اتفاقيات التزام صارمة، اختبارات تلقائية لكل PR، وأنابيب CI/CD مدركة للوكلاء.

"Minions" في Stripe

ينتج نظام Stripe الداخلي أكثر من 1,000 PR مدمج أسبوعياً باستخدام وكلاء الذكاء الاصطناعي. تشمل حاضنتهم:

• تعريفات مهام محددة بدقة.
• مراجعة كود إلزامية من قبل البشر.
• اختبارات تراجع (regression testing) تلقائية.
• أتمتة التراجع عن التغييرات (Rollback automation).

معمارية الوكيلين في Anthropic

نشرت Anthropic نهجها للحاضنات الفعالة للوكلاء الذين يعملون لفترات طويلة:

• قوائم ميزات مهيكلة كصيغة تسليم بين الوكلاء.
• تتبع التقدم المستند إلى Git لكي يتمكن الوكلاء من الاستئناف بعد الانقطاع.
• معايير خروج صريحة لكي يعرف الوكلاء متى يتوقفون.

كيف تبدأ في بناء حاضنتك

الخطوة 1: إنشاء ملف السياق الخاص بك

أضف ملف CLAUDE.md (أو AGENTS.md) إلى جذر مشروعك:

# Project: [اسم مشروعك]

## Stack
[Framework, language, database, hosting]

## Architecture
[هيكل المجلدات مع وصف من سطر واحد]

## Rules
[5-10 قواعد صارمة يجب على الوكيل اتباعها]

## Common Tasks
[كيفية تشغيل الاختبارات، البناء، والنشر]

الخطوة 2: إضافة القيود الهيكلية

# مثال: قاعدة ESLint تمنع استيراد قاعدة البيانات مباشرة في المكونات
# .eslintrc — no-restricted-imports rule

قم بإعداد خطافات ما قبل الالتزام (pre-commit hooks) التي تفرض قواعدك تلقائياً.

الخطوة 3: بناء حلقات التحقق

تأكد من أن وكيلك يمكنه:

1. تشغيل الاختبارات (npm test, pytest, إلخ).


2. فحص الأنواع (tsc --noEmit, mypy).


3. الـ Lint (eslint ., ruff check).

الخطوة 4: تحديد نطاق جلسات الوكيل

لا تعطِ الوكيل كامل قائمة المهام المؤجلة (backlog). بدلاً من ذلك:

• ميزة واحدة لكل جلسة.
• إصلاح خطأ واحد لكل جلسة.
• معايير قبول واضحة لكل مهمة.

الخطوة 5: التكرار والتحسين على الحاضنة

في كل مرة يرتكب فيها الوكيل خطأً:

1. حدد السبب الجذري.
2. أضف قاعدة، أو قيداً، أو خطافاً يمنع حدوث ذلك.
3. اختبر الإصلاح.

هندسة الحاضنة مقابل هندسة الأوامر

هندسة الأوامر لا تزال مفيدة، لكنها جزء صغير من الصورة. هندسة الحاضنة هي المضاعف الحقيقي للقوة.

لا تخلط بينها وبين: Harness.io

إذا كنت تبحث عن "Harness Engineering" ووجدت منصة DevOps — فإن Harness.io هو شيء منفصل تماماً. إنها منصة CI/CD مدعومة بالذكاء الاصطناعي تقدر قيمتها بـ 5.5 مليار دولار (حتى ديسمبر 2025) تقدم التكامل المستمر، والتسليم، وأعلام الميزات (feature flags)، وإدارة تكاليف السحابة، واختبارات الأمان.

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

الخلاصة

النموذج هو المحرك، والحاضنة هي السيارة. لا أحد يفوز بسباق بمحرك فقط.

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

الفرق التي تشحن المنتجات بشكل أسرع لا تستخدم نماذج أفضل؛ بل تستخدم حاضنات أفضل.