هندسة التسخير: الدليل الشامل لبناء الأنظمة التي تجعل وكلاء الذكاء الاصطناعي يعملون حقاً
مارس 2026 — إذا كان عام 2025 هو العام الذي أثبت فيه وكلاء الذكاء الاصطناعي قدرتهم على كتابة الكود، فإن عام 2026 هو العام الذي تعلمنا فيه أن الوكيل ليس هو الجزء الصعب — بل نظام التسخير (The Harness).
قام فريق Codex في OpenAI للتو ببناء تطبيق إنتاجي يضم أكثر من مليون سطر من الكود حيث تم كتابة صفر سطر بواسطة أيدٍ بشرية. لم يكتب المهندسون كوداً، بل صمموا النظام الذي سمح للذكاء الاصطناعي بكتابة الكود بشكل موثوق. هذا النظام — القيود، حلقات التغذية الراجعة، التوثيق، أدوات الفحص، وإدارة دورة الحياة — هو ما تسميه الصناعة الآن نظام التسخير (Harness).
هندسة التسخير (Harness engineering) هي التخصص الجديد لتصميم هذه الأنظمة، وهي تغير مفهوم ما يعنيه أن تكون مهندس برمجيات.
ما هي هندسة التسخير؟
استعارة الحصان
يأتي مصطلح "Harness" (التسخير أو العدة) من عتاد الخيول — الأرسنة، السرج، اللجام — وهي المجموعة الكاملة من المعدات لتوجيه حيوان قوي ولكن لا يمكن التنبؤ بتصرفاته في الاتجاه الصحيح. هذه الاستعارة مقصودة:
- الحصان هو نموذج الذكاء الاصطناعي — قوي وسريع، لكنه لا يعرف إلى أين يذهب بمفرده.
- نظام التسخير (Harness) هو البنية التحتية — القيود، حواجز الحماية، وحلقات التغذية الراجعة التي توجه قوة النموذج بشكل إنتاجي.
- الفارس هو المهندس البشري — الذي يقدم التوجيه، وليس هو من يقوم بالركض.
بدون نظام تسخير، يكون وكيل الذكاء الاصطناعي مثل حصان أصيل في حقل مفتوح؛ سريع ومبهر، لكنه عديم الفائدة تماماً لإنجاز أي عمل محدد.
التعريف الرسمي
هندسة التسخير هي تصميم وتنفيذ الأنظمة التي تقوم بـ:
- تقييد (Constrain) ما يمكن لوكيل الذكاء الاصطناعي فعله (الحدود المعمارية، قواعد الاعتمادية).
- إبلاغ (Inform) الوكيل بما يجب عليه فعله (هندسة السياق، التوثيق).
- التحقق (Verify) من أن الوكيل قام بالمهمة بشكل صحيح (الاختبار، الفحص، التحقق من CI).
- تصحيح (Correct) الوكيل عندما يخطئ (حلقات التغذية الراجعة، آليات الإصلاح الذاتي).
يصفها مارتن فاولر بأنها "الأدوات والممارسات التي يمكننا استخدامها لإبقاء وكلاء الذكاء الاصطناعي تحت السيطرة" — لكنها أكثر من مجرد سلامة. نظام التسخير الجيد يجعل الوكلاء أكثر قدرة، وليس فقط أكثر انضباطاً.
لماذا تهم هندسة التسخير الآن؟
النموذج سلعة.. ونظام التسخير هو الميزة التنافسية
إليك الحقيقة المزعجة التي تواجهها صناعة الذكاء الاصطناعي الآن: النموذج الأساسي يقل أهمية عن النظام المحيط به.
أثبتت LangChain ذلك بشكل قاطع. فقد تحسن وكيل البرمجة الخاص بهم من 52.8% إلى 66.5% في اختبار Terminal Bench 2.0 — قافزاً من أفضل 30 إلى أفضل 5 — دون تغيير أي شيء في النموذج. لقد قاموا فقط بتغيير نظام التسخير:
| التغيير | ماذا فعلوا | التأثير |
|---|---|---|
| حلقة التحقق الذاتي | إضافة برمجيات وسيطة لقائمة التحقق قبل الإكمال | اكتشاف الأخطاء قبل الإرسال |
| هندسة السياق | رسم خرائط لهياكل المجلدات عند التشغيل | فهم الوكيل لقاعدة الكود منذ البداية |
| اكتشاف التكرار | تتبع تعديلات الملفات المتكررة | منع "حلقات الهلاك" (doom loops) |
| شطيرة التفكير (Reasoning sandwich) | تفكير عالٍ للتخطيط/التحقق، ومتوسط للتنفيذ | جودة أفضل ضمن ميزانيات الوقت |
نفس النموذج. نظام تسخير مختلف. نتائج أفضل بكثير.
دليل المليون سطر من OpenAI
تجربة OpenAI هي الدليل الأكثر إقناعاً حتى الآن:
- 5 أشهر من التطوير.
- أكثر من مليون سطر كود في المنتج النهائي.
- صفر سطر مكتوب يدوياً — كل سطر أنتجه وكلاء Codex.
- بني في حوالي 1/10 من الوقت الذي كان سيستغرقه البشر.
- المنتج لديه مستخدمون داخليون يوميون ومختبرون خارجيون للنسخة التجريبية.
- المنتج يشحن، وينتشر، ويتعطل، ويتم إصلاحه — كل ذلك بواسطة الوكلاء داخل نظام التسخير.
وظيفة المهندسين؟ تصميم نظام التسخير، تحديد الأهداف، وتقديم التغذية الراجعة. وليس كتابة الكود.
الركائز الثلاث لهندسة التسخير
ينظم إطار عمل OpenAI هندسة التسخير في ثلاث فئات أساسية:
1. هندسة السياق (Context Engineering)
تتعلق هندسة السياق بضمان حصول الوكيل على المعلومات الصحيحة في الوقت الصحيح.
السياق الثابت:
- التوثيق المحلي للمستودع (مواصفات المعمارية، عقود API، أدلة الأنماط).
- ملفات
AGENTS.mdأوCLAUDE.mdالتي تشفر القواعد الخاصة بالمشروع. - مستندات التصميم المترابطة التي يتم التحقق منها بواسطة أدوات الفحص.
السياق الديناميكي:
- بيانات المراقبة (السجلات، المقاييس، التتبعات) التي يمكن للوكلاء الوصول إليها.
- رسم خرائط هيكل المجلدات عند بدء تشغيل الوكيل.
- حالة خط أنابيب CI/CD ونتائج الاختبارات.
القاعدة الحاسمة: من وجهة نظر الوكيل، أي شيء لا يمكنه الوصول إليه في السياق فهو غير موجود. المعرفة الموجودة في Google Docs أو محادثات Slack أو رؤوس الأشخاص غير مرئية للنظام. يجب أن يكون المستودع هو المصدر الوحيد للحقيقة.
2. القيود المعمارية (Architectural Constraints)
هذا هو المكان الذي تختلف فيه هندسة التسخير بشكل صارخ عن هندسة الأوامر التقليدية. بدلاً من إخبار الوكيل بـ "اكتب كوداً جيداً"، أنت تفرض آلياً كيف يبدو الكود الجيد.
طبقات الاعتمادية:
Types → Config → Repo → Service → Runtime → UI
يمكن لكل طبقة فقط استيراد الملفات من الطبقات الموجودة على يسارها. هذا ليس اقتراحاً — بل يتم فرضه من خلال الاختبارات الهيكلية والتحقق من CI.
أدوات فرض القيود:
- أدوات فحص حتمية (Deterministic linters) — قواعد مخصصة تكتشف الانتهاكات تلقائياً.
- مدققون يعتمدون على نماذج اللغة (LLM-based auditors) — وكلاء يراجعون كود الوكلاء الآخرين للامتثال المعماري.
- اختبارات هيكلية — مثل ArchUnit، ولكن للكود الذي تم إنشاؤه بواسطة الذكاء الاصطناعي.
- خطافات ما قبل الالتزام (Pre-commit hooks) — فحوصات تلقائية قبل التزام بأي كود.
لماذا تحسن القيود المخرجات: للمفارقة، فإن تقييد مساحة الحل يجعل الوكلاء أكثر إنتاجية، وليس أقل. عندما يتمكن الوكيل من إنشاء أي شيء، فإنه يضيع الرموز (tokens) في استكشاف طرق مسدودة. عندما يحدد نظام التسخير حدوداً واضحة، يتقارب الوكيل بشكل أسرع نحو الحلول الصحيحة.
3. إدارة الإنتروبيا (إزالة "القمامة")
هذا هو المكون الأكثر إغفالاً. بمرور الوقت، تتراكم الإنتروبيا في قواعد الكود المنشأة بواسطة الذكاء الاصطناعي — حيث ينحرف التوثيق عن الواقع، وتتباعد اصطلاحات التسمية، ويتراكم الكود الميت.
تعالج هندسة التسخير ذلك من خلال وكلاء تنظيف دوريين:
- وكلاء اتساق التوثيق — للتحقق من مطابقة المستندات للكود الحالي.
- ماسحات انتهاك القيود — للعثور على الكود الذي أفلت من الفحوصات السابقة.
- وكلاء فرض الأنماط — لتحديد وإصلاح الانحرافات عن الأنماط المعمول بها.
- مدققو الاعتماديات — لتتبع وحل التبعيات الدائرية أو غير الضرورية.
يعمل هؤلاء الوكلاء وفق جداول زمنية — يومية أو أسبوعية أو بناءً على أحداث معينة — مما يحافظ على صحة قاعدة الكود للمراجعين البشريين ووكلاء الذكاء الاصطناعي المستقبليين.
هندسة التسخير في الممارسة: كيف تفعل الفرق ذلك؟
نهج OpenAI: صفر كود بشري
هيكل فريق OpenAI لهندسة التسخير:
| الدور | التقليدي | هندسة التسخير |
|---|---|---|
| كتابة الكود | المهمة الأساسية | أبداً |
| تصميم المعمارية | جزء من الوظيفة | المهمة الأساسية |
| كتابة التوثيق | فكرة ثانوية | بنية تحتية حيوية |
| مراجعة طلبات السحب (PRs) | مراجعة الكود | مراجعة مخرجات الوكيل + فعالية نظام التسخير |
| تصحيح الأخطاء | قراءة الكود | تحليل أنماط سلوك الوكيل |
| الاختبار | كتابة الاختبارات | تصميم استراتيجيات الاختبار التي ينفذها الوكلاء |
نهج Stripe: التابعون (Minions) على نطاق واسع
تنتج وكلاء البرمجة الداخليين في Stripe، الملقبون بـ Minions، الآن أكثر من 1000 طلب سحب (PR) مدمج أسبوعياً:
- ينشر المطور مهمة في Slack.
- يقوم الـ Minion بكتابة الكود.
- يجتاز الـ Minion اختبارات CI.
- يفتح الـ Minion طلب سحب (PR).
- يقوم الإنسان بالمراجعة والدمج.
لا يوجد تفاعل للمطور بين الخطوة 1 والخطوة 5. يتولى نظام التسخير كل شيء — تنفيذ الاختبارات، التحقق من CI، الامتثال للنمط، وتحديثات التوثيق.
نهج LangChain: البرمجيات الوسيطة أولاً
تنظم LangChain نظام التسخير الخاص بها كطبقات برمجيات وسيطة قابلة للتركيب:
Agent Request
→ LocalContextMiddleware (يرسم خرائط قاعدة الكود)
→ LoopDetectionMiddleware (يمنع التكرار)
→ ReasoningSandwichMiddleware (يحسن الحوسبة)
→ PreCompletionChecklistMiddleware (يفرض التحقق)
→ Agent Response
تضيف كل طبقة برمجية وسيطة قدرة محددة دون تعديل المنطق الأساسي للوكيل. هذا النهج المعياري يجعل نظام التسخير قابلاً للاختبار والتطوير.
بناء أول نظام تسخير لك: إطار عمل عملي
المستوى 1: نظام تسخير أساسي (مطور واحد)
إذا كنت تستخدم Claude Code أو Cursor أو Codex لمشاريع فردية:
ما يجب إعداده:
- ملف
CLAUDE.mdأو.cursorrulesمع اصطلاحات المشروع. - خطافات ما قبل الالتزام (Pre-commit hooks) للفحص والتنسيق.
- مجموعة اختبارات يمكن للوكيل تشغيلها للتحقق الذاتي.
- هيكل مجلدات واضح مع تسميات متسقة.
وقت الإعداد: 1-2 ساعة. التأثير: يمنع أخطاء الوكيل الأكثر شيوعاً.
المستوى 2: نظام تسخير للفريق (فريق صغير)
للفرق التي تضم 3-10 مطورين يتشاركون قاعدة كود واحدة:
أضف إلى المستوى 1:
- ملف
AGENTS.mdمع اصطلاحات الفريق بالكامل. - قيود معمارية مفروضة بواسطة CI.
- قوالب أوامر (prompts) مشتركة للمهام الشائعة.
- التوثيق ككود يتم التحقق منه بواسطة أدوات الفحص.
- قوائم مراجعة الكود خصيصاً لطلبات السحب المنشأة بواسطة الوكيل.
وقت الإعداد: 1-2 يوم. التأثير: سلوك وكيل متسق عبر الفريق.
المستوى 3: نظام تسخير للإنتاج (منظمة هندسية)
للمنظمات التي تدير عشرات الوكلاء المتزامنين:
أضف إلى المستوى 2:
- طبقات برمجيات وسيطة مخصصة (اكتشاف التكرار، تحسين التفكير).
- تكامل أدوات المراقبة (الوكلاء يقرؤون السجلات والمقاييس).
- وكلاء إدارة الإنتروبيا في جولات مجدولة.
- إصدار نظام التسخير واختبار A/B.
- لوحات تحكم لمراقبة أداء الوكلاء.
- سياسات التصعيد عند تعثر الوكلاء.
وقت الإعداد: 1-2 أسبوع. التأثير: الوكلاء يعملون كمسهمين مستقلين.
أخطاء شائعة في هندسة التسخير
1. الإفراط في هندسة تدفق التحكم
"إذا أفرطت في هندسة تدفق التحكم، فإن تحديث النموذج القادم سيكسر نظامك."
تتحسن النماذج بسرعة. القدرات التي كانت تتطلب خطوط أنابيب معقدة في عام 2024 يتم التعامل معها الآن بواسطة أمر بسيط في نافذة السياق. ابنِ نظام التسخير الخاص بك ليكون قابلاً للتفكيك (rippable) — يجب أن تكون قادراً على إزالة المنطق "الذكي" عندما يصبح النموذج ذكياً بما يكفي لعدم الحاجة إليه.
2. معاملة نظام التسخير كشيء ثابت
يحتاج نظام التسخير إلى التطور مع النموذج. عندما يحسن إصدار نموذج جديد من قدرات التفكير، قد تصبح البرمجيات الوسيطة لتحسين التفكير بنتائج عكسية. راجع وحدث مكونات نظام التسخير مع كل تحديث رئيسي للنموذج.
3. تجاهل طبقة التوثيق
غالباً ما يكون أبسط تحسين لنظام التسخير هو الأكثر تأثيراً: توثيق أفضل. إذا كان ملف AGENTS.md الخاص بك غامضاً، فستكون مخرجات الوكيل غامضة. استثمر في توثيق دقيق وقابل للقراءة آلياً ليكون بمثابة الحقيقة المطلقة للوكيل.
4. غياب حلقة التغذية الراجعة
نظام التسخير بدون تغذية راجعة هو قفص وليس دليلاً. يحتاج الوكيل إلى معرفة متى ينجح ومتى يفشل. قم ببناء:
- خطوات التحقق الذاتي قبل إكمال المهمة.
- تنفيذ الاختبارات كجزء من سير عمل الوكيل.
- مقاييس لمعدلات نجاح الوكيل حسب نوع المهمة.
5. التوثيق الموجه للبشر فقط
إذا كانت قراراتك المعمارية تعيش فقط في رؤوس الأشخاص أو في صفحات Confluence التي لا يمكن للوكيل الوصول إليها، فهناك فجوة في نظام التسخير. يجب أن يكون كل ما يحتاجه الوكيل موجوداً داخل المستودع.
هندسة التسخير مقابل المفاهيم ذات الصلة
| المفهوم | النطاق | التركيز |
|---|---|---|
| هندسة الأوامر (Prompt Engineering) | تفاعل واحد | صياغة أوامر فعالة |
| هندسة السياق (Context Engineering) | نافذة سياق النموذج | ما هي المعلومات التي يراها النموذج |
| هندسة التسخير (Harness Engineering) | نظام الوكيل بالكامل | البيئة، القيود، التغذية الراجعة، دورة الحياة |
| هندسة الوكلاء (Agent Engineering) | معمارية الوكيل | التصميم الداخلي للوكيل وتوجيهه |
| هندسة المنصات (Platform Engineering) | البنية التحتية | النشر، التوسع، العمليات |
هندسة التسخير تتضمن هندسة السياق وتستمد من هندسة الأوامر، لكنها تعمل على مستوى أعلى — فهي تتعلق بالنظام الكامل الذي يجعل الوكلاء موثوقين، وليس مجرد مدخلات تفاعل واحد.
ماذا يعني هذا لمهندسي البرمجيات؟
الوظيفة تتغير
تمثل هندسة التسخير تطوراً حقيقياً في ما يفعله مهندسو البرمجيات:
| من قبل | الآن |
|---|---|
| كتابة الكود | تصميم البيئات التي يكتب فيها الذكاء الاصطناعي الكود |
| تصحيح الكود | تصحيح سلوك الوكيل |
| مراجعة الكود | مراجعة مخرجات الوكيل + فعالية نظام التسخير |
| كتابة الاختبارات | تصميم استراتيجيات الاختبار |
| صيانة التوثيق | بناء التوثيق كبنية تحتية قابلة للقراءة آلياً |
هذا لا يعني أن المهندسين سيصبحون أقل تقنية. بل على العكس، تتطلب هندسة التسخير تفكيراً معمارياً أعمق — فأنت تصمم أنظمة يجب أن تعمل دون تدخلك المستمر.
المهارات التي تهم
بناءً على ما رأيناه في بناء المنتجات المدعومة بالذكاء الاصطناعي في NxCode:
- تفكير النظم — فهم كيفية تفاعل القيود وحلقات التغذية الراجعة والتوثيق.
- تصميم المعمارية — تحديد الحدود التي تكون قابلة للفرض ومنتجة.
- كتابة المواصفات — صياغة الأهداف بدقة كافية ليقوم الوكلاء بتنفيذها.
- المراقبة (Observability) — بناء مراقبة تكشف عن أنماط سلوك الوكيل.
- سرعة التكرار — اختبار وتحسين تكوينات نظام التسخير بسرعة.
تجربتنا: ما الذي ينجح في الممارسة العملية؟
لقد قمنا ببناء تطبيقات ويب مدعومة بالذكاء الاصطناعي باستخدام أنظمة وكلاء متعددة (Claude Code, Codex, Cursor). الأنماط التي أحدثت أكبر فرق بالنسبة لنا هي:
- التوثيق المعتمد على المستودع أولاً: كل قرار معماري، واصطلاح تسمية، وعملية نشر موجودة في المستودع. لا شيء يعيش في Slack أو Google Docs.
- بناء القيود التدريجي: ابدأ بالفحص الأساسي، وأضف القيود المعمارية مع ظهور الأنماط، ولا تحاول تصميم نظام تسخير مثالي من البداية.
- قوائم مراجعة خاصة بالوكلاء: الكود المنشأ بواسطة الذكاء الاصطناعي له أنماط فشل مختلفة عن الكود البشري. عملية المراجعة لدينا تأخذ في الاعتبار أنماط الوكلاء الشائعة (الإفراط في التجريد، معالجة الأخطاء غير الضرورية، انحراف التوثيق).
- تصميم نظام تسخير متعدد المزودين: يعمل نظام التسخير لدينا مع نماذج Claude و GPT و Gemini. التصميم المحايد للمزود يعني أنه يمكننا تبديل النماذج دون إعادة بناء النظام بالكامل.
النقاط الرئيسية
- هندسة التسخير هي التخصص الجديد لتصميم الأنظمة التي تجعل وكلاء الذكاء الاصطناعي موثوقين — القيود، وحلقات التغذية الراجعة، والتوثيق، وإدارة دورة الحياة.
- النموذج سلعة؛ ونظام التسخير هو الميزة التنافسية — قفزت LangChain من قائمة أفضل 30 إلى أفضل 5 في الاختبارات فقط من خلال تغيير نظام التسخير.
- OpenAI بنت أكثر من مليون سطر كود بدون تدخل بشري — مما يثبت أن هندسة التسخير تعمل على نطاق الإنتاج.
- الركائز الثلاث: هندسة السياق، القيود المعمارية، وإدارة الإنتروبيا.
- ابدأ ببساطة: ملف
AGENTS.mdجيد وخطافات ما قبل الالتزام أكثر تأثيراً من البرمجيات الوسيطة المعقدة. - وظيفة المهندس تتطور — من كتابة الكود إلى تصميم البيئات التي يكتب فيها الذكاء الاصطناعي الكود.
- ابنِ أنظمة تسخير قابلة للتفكيك — الإفراط في الهندسة يؤدي إلى الفشل عند تحسن النماذج؛ حافظ على مرونتها.
موارد ذات صلة
- شرح الويب الوكيلي (Agentic Web): AGENTS.md و MCP مقابل A2A — طبقة البروتوكول التي تبنى عليها هندسة التسخير.
- وكلاء Cursor السحابيون: البرمجة الذاتية على الأجهزة الافتراضية — أنظمة تسخير الوكلاء السحابية في الممارسة العملية.
- التحكم عن بعد في Claude Code: دليل تسليم التيرمينال — إدارة جلسات الوكيل عن بعد.
- ابنِ موقعك مع NxCode — تطوير الويب المدعوم بالذكاء الاصطناعي مع معمارية تسخير متعددة المزودين.
