لماذا يجب أن تتعلم هندسة الحصان؟ تحليل كامل لـ 5 منتجات، 3 مدارس، و5 مبادئ عالمية

نظام التحليل هندسة Harness: خمسة منتجات، ثلاثة مدارس (OpenAI / Anthropic / ThoughtWorks)، خمسة مبادئ عالمية، ولماذا "تدهور Harness" يجبرك على قطع نصف التصميم كل 6 أشهر. هذا المقال مستوحى من مقال @sairahul1، تم تجميعه وترجمته بواسطة فريق 动區.
(ملخص سابق: مقدمة في هندسة Harness (الهندسة الموجهة للذكاء الاصطناعي): أحدث معايير برمجة OpenAI، تعلم كيف تصل إلى المستوى 1 بسهولة)
(معلومات إضافية: مدير YC التنفيذي يشارك أسرار الذكاء الاصطناعي: المستقبل لمن يبني أنظمة فائدة مركبة للمعلومات)

فهرس المقال

Toggle

    1. تعريف Harness
    1. تشبيه نظام التشغيل
    1. ماذا تغير في 2026
    1. ملفات AGENT.md / CLAUDE.md
    1. قوائم ميزات JSON (متعقب التقدم)
    • لماذا JSON وليس Markdown؟
    1. إجراءات تهيئة الجلسة
    1. عقود السبرينت (Sprint Contracts)
    • لماذا مهمة
    1. قوالب المهام الهيكلية (Structured Task Templates)
    1. مدرسة OpenAI: البيئة أولوية
    • طرقهم
    • الأدلة
    1. مدرسة Anthropic: فصل "العمل" و"المراجعة"
    • حلهم: 3 وكلاء متخصصين
    • النتائج (اختبار A/B)
    1. مدرسة ThoughtWorks: إطار 2×2
    • رؤيتهم: تصنيف كل تحكم في harness بمحورين
    • مصفوفة 2×2
    1. المبدأ 1: السياق يتفوق على التعليمات
    1. المبدأ 2: التخطيط والتنفيذ يجب أن يكونا منفصلين
    1. المبدأ 3: حلقة التغذية الراجعة لا يمكن التنازل عنها
    1. المبدأ 4: تنفيذ مهمة واحدة في كل مرة
    1. المبدأ 5: قاعدة الكود هي الوثيقة
    • المعنى العملي
    1. تدهور Harness (Harness Decay) حقيقي
    • هذا هو تدهور Harness
    1. البناء من أجل الحذف (Build to Delete)
    1. الواقع من حيث التكاليف
    • لكن هذا الجزء غير مذكور عادة
  • ملخص كامل
    • ما هو harness
    • 5 منتجات harness
    • 3 مدارس
    • 5 مبادئ عالمية
    • المفارقة

في فبراير 2026، أنتج فريق صغير من OpenAI مليون سطر من الكود الإنتاجي.

لم يكتبوا سطراً واحداً يدويًا.

الذكاء الاصطناعي هو الذي كتبها.

والتصميم البشري هو النظام الذي يجعل الوكيل موثوقًا.

هذا النظام أصبح له اسم الآن — هندسة Harness.

خلال أسابيع، أصدرت Anthropic 3 أوراق بحثية ذات صلة. و ThoughtWorks نظمته كإطار عمل. و Philipp Schmid من Hugging Face وصفه مباشرة بأنه "أهم تخصص في 2026".

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

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

1. تعريف Harness

أبسط تعريف من ThoughtWorks:

الوكيل = النموذج + Harness

Harness هو كل شيء خارج النموذج.

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

إزالة harness → نموذج لغة عشوائي يخمن داخل قاعدة الكود.

إضافة harness الصحيح → نظام قادر على إنتاج كود إنتاجي.

اسمها مستمد من أدوات الفروسية. Harness هو الحبل، السرج، اللجام — يوجه قوة حيوان قوي لكنه غير متوقع نحو الاتجاه المفيد.

أنت لا تجعل الحصان أذكى، أنت تصمم معدات تجعل قوته مفيدة.

2. تشبيه نظام التشغيل

أفضل تشبيه تقني من Philipp Schmid هو: فكر فيه كأنه حاسوب.

| الدور | المقابل |
| --- | --- |
| النموذج | CPU (القدرة الحاسوبية الأساسية) |
| نافذة السياق | RAM (الذاكرة المؤقتة المحدودة والمتطايرة) |
| Harness | نظام التشغيل (يدير ما يراه CPU ومتى يراه) |
| الوكيل | التطبيق الذي يعمل فوقه |

نموذجك قوي جدًا. لكن بدون نظام تشغيل يدير الذاكرة، الجدولة، القواعد — هو مجرد قطعة من السيليكون.

معظم الناس يشغلون التطبيقات بدون "نظام تشغيل". لذلك، عندما يبدأ الوكيل في الإنتاج، يتعطل.

3. ماذا تغير في 2026

استخدم LangChain نفس النموذج، وشغل على Terminal Bench 2.0 مرتين:

| Harness | النتيجة |
| --- | --- |
| harness القديم | 52.8% |
| harness الجديد | 66.5% |

نفس النموذج. harness مختلف. الفرق 13.7 نقطة مئوية.

Vercel عكس ذلك — قللوا أدوات الوكيل بنسبة 80%. النتيجة؟ أفضل، وليس أسوأ.

أكثر حقيقة غير مريحة في 2026:

  • الوكيل لم يكن أبدًا الجزء الصعب
  • Harness هو

إذا كانت 2025 سنة إثبات قدرة الوكيل على كتابة الكود، فإن 2026 سنة اكتشاف أن "البيئة" أهم من "النموذج".

4. ملفات AGENT.md / CLAUDE.md

أكثر منتجات harness شيوعًا.

ملفات markdown مبعثرة في أجزاء مختلفة من قاعدة الكود. الوكيل يقرأها في بداية كل جلسة — مثل وثائق التوظيف للموظف الجديد.

ماذا تحتوي؟

  • سياق المشروع
  • قواعد البرمجة
  • قرارات الهيكلية
  • إرشادات "كيف نفعل هنا"
  • المهام الحالية قيد التنفيذ

يسميها OpenAI AGENT.md. و Anthropic تسمّيها CLAUDE.md. و Cursor تستخدم .cursorrules.

أسماء مختلفة، نفس المبدأ. كل وحدة رئيسية نسخة، وتُحدث مع تطور المشروع.

بدونها: الوكيل يفتح كل جلسة وهو أعمى. معها: الوكيل يبدأ وهو يحمل المعلومات ويعمل.

5. قوائم ميزات JSON (متعقب التقدم)

عندما يتجاوز الوكيل جلسات متعددة لبناء تطبيق كامل، يكون سياق كل جلسة فارغ. كيف يعرف ما تم إنجازه؟

ملف JSON.

كل إدخال يكتب:

  • ميزة
  • كيف يتحقق من نجاحها
  • حالة النجاح / الفشل

الوكيل يقرأه في بداية كل جلسة — يختار أعلى أولوية للفشل → ينفذ → يضع علامة على النجاح → يلتزم → يتكرر.

لماذا JSON وليس Markdown؟

اكتشفت Anthropic أن: احتمال أن يكتب الوكيل ملف JSON بشكل غير مقصود أقل من Markdown.

التفاصيل صغيرة، لكنها مهمة جدًا في سيناريوهات التشغيل الذاتي لمدة 6 ساعات.

6. إجراءات تهيئة الجلسة

كل جلسة تبدأ بنفس الطريقة. كل مرة.

7 خطوات لبدء التشغيل من Anthropic:

  1. التحقق من مجلد العمل
  2. قراءة سجل git وملف التقدم
  3. اختيار أعلى أولوية من قائمة الميزات غير المكتملة
  4. تشغيل خادم التطوير
  5. إجراء اختبار end-to-end أساسي
  6. تنفيذ ميزة
  7. الالتزام برسالة وصفية وتحديث التقدم

بدونها: الوكيل يقضي أول 20 دقيقة في فهم الحالة الحالية، ويعيد اختراع العجلة في كل جلسة. معها: يبدأ وهو يحمل المعلومات ويبدأ مباشرة.

7. عقود السبرينت (Sprint Contracts)

قبل كتابة أي سطر كود — يجب أن يتفاوض وكيلان.

وكيل المولد (Generator):

  • ماذا يريد أن يفعل
  • كيف يتحقق من النجاح

وكيل المراجعة (Evaluator):

  • هل المقترح كامل؟
  • هل معايير النجاح واضحة؟

إذا وافقا، يبدأ التنفيذ.

هو مراجعة تصميم. لكن كلاهما AI.

لماذا مهمة

في نفس الدورة، عندما يخطط الوكيل وينفذ، تكون النتائج غير موثوقة. خطوة "التخطيط" — حتى لو كانت AI — تعزز جودة المخرجات بشكل كبير.

8. قوالب المهام الهيكلية (Structured Task Templates)

قبل كتابة أي كود، harness يحلل قاعدة الكود الحقيقية.

ينتج خريطة تأثير grounded impact map:

  • مسارات الملفات الحقيقية (وليس وهمية)
  • أسماء الرموز الموجودة
  • الأنماط التي يمكن اتباعها
  • معايير القبول المحددة

ثم يبدأ التنفيذ.

يبدو بديهيًا، لكن معظم الفرق يتخطى هذه الخطوة.

الوكيل يخمن هيكل الملفات، يختتر API غير موجود، يصنع شيئًا لا يتوافق مع قاعدة الكود.

ابدأ بسياق واقعي، ثم نفذ → جودة المخرجات تتفاوت بشكل كبير.

9. مدرسة OpenAI: البيئة أولوية

فريق Codex من OpenAI لديه مشكلة غريبة:

مليون سطر من الكود الإنتاجي، بدون سطر واحد يدوي.

على هذا الحجم، لا يمكنك مراجعة كل سطر يدويًا. لذلك، هم لا يفعلون ذلك.

بدلاً من ذلك — يصممون البيئة بشكل كامل بحيث يكون الوكيل من البداية قادر على إنتاج "مخرجات قابلة للمراجعة".

طرقهم

  • اعتماد صارم على تدفقات الاعتمادية (Types → Config → Repo → Service → Runtime → UI)
  • قاعدة الكود موزعة على ملفات AGENT.md
  • الوكيل يدمج مباشرة في خط أنابيب CI/CD

الفلسفة: صمم البيئة. ثم دع الوكيل يشتغل فيها.

الأدلة

تطبيق Sora Android. 4 مهندسين. 28 يومًا. المرتبة الأولى في Play Store. 99.9% خالي من الأعطال.

Codex يتعامل مع 70% من PRs داخليًا أسبوعيًا.

10. مدرسة Anthropic: فصل "العمل" و"المراجعة"

واجهت Anthropic مشكلة أخرى:

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

التقييم الذاتي غير كافٍ. الوكيل هو طالب ومعلم في آن واحد، ويعطي نفسه تقييم كامل A.

حلهم: 3 وكلاء متخصصين

| الوكيل | الوظيفة |
| --- | --- |
| Planner | يحول طلب مكون من جملتين إلى مواصفات كاملة للمنتج |
| Generator | ينفذ مهمة في سبرينت واحد |
| Evaluator | يستخدم اختبار تلقائي عبر المتصفح، ويتصرف كأنه مستخدم حقيقي |

رؤيتهم: جعل "المُقيم المستقل" أكثر انتقادًا، أسهل بكثير من جعل المُولد ينتقد عمله.

نتائج (اختبار A/B)

| الإعداد | التكلفة | الوقت | النتيجة |
| --- | --- | --- | --- |
| وكيل واحد (بدون harness) | 9 دولارات | 20 دقيقة | تطبيق معطل |
| harness كامل | 200 دولار | 6 ساعات | برنامج يعمل وواجهة مستخدم متقنة |

11. مدرسة ThoughtWorks: إطار 2×2

يقتربون من الأمر من زوايا مختلفة — هم لا يصنعون منتجًا، بل يدرسون فشل أكثر من 50 فريق هندسي في نفس النقاط.

رؤيتهم: تصنيف كل تحكم في harness بمحورين

المحور 1: متى يعمل؟

  • Feedforward = قبل أن يتخذ الوكيل إجراء (إرشادات)
  • Feedback = بعد أن يتخذ الوكيل إجراء (مستشعرات)

المحور 2: كيف يعمل؟

  • حسابي (Deterministic) = دقة عالية، ميلي ثانية (linter، type checker، اختبار)
  • استنتاجي (Inferential) = باستخدام LLM، ثوانٍ (مراجعة الكود، التحليل الدلالي)

مصفوفة 2×2

| |
| --- | --- |
| Feedforward (إرشادات) | Feedback (مستشعرات) |
| Computational | أنظمة النوع، أدوات التحقق، قواعد الهيكلية | اختبارات، تغطية، اختبارات الطفرة |
| Inferential | ملفات المواصفات، أوصاف القيود | مراجعة الكود بواسطة LLM، مدقق السلوك |

لا يمكن الاعتماد على أحدهما بمفرده. كلاهما ضروري.

12. المبدأ 1: السياق يتفوق على التعليمات

مختلف الفرق يكتشفون نفس الشيء:

  • OpenAI: أعطِ خريطة، لا تعطي كتيبًا من 1000 صفحة
  • Anthropic: قائمة ميزات JSON + ملف التقدم، ليعرف الوكيل دائمًا مكانه
  • Red Hat: قبل أي مهمة، يحلل قاعدة الكود الحقيقية
  • ThoughtWorks: يسمونه "Feedforward"

ربط الوكيل بسياق "حالة العالم الحالية" يتفوق دائمًا على إعطائه تعليمات مجردة.

الربط يكون بمسارات الملفات الحقيقية → برمجة تتوافق مع قاعدة الكود. من أوصاف غامضة إلى مسارات API مخترعة.

قبل أن يكتب الوكيل، تأكد من أنه يعرف مكانه.

13. المبدأ 2: التخطيط والتنفيذ يجب أن يكونا منفصلين

  • OpenAI: الإنسان يصمم البيئة، والوكيل ينفذ
  • Anthropic: وكيل المخطط (Planner) يسبق الوكيل المنفذ (Generator)
  • ThoughtWorks: فصل بين التحقق من النقاط (checkpoint) بين التخطيط والتنفيذ
  • Red Hat: بين المرحلة 1 (خريطة التأثير) و المرحلة 2 (التنفيذ) يوجد فصل صارم

كل فريق يكتشف أن: القيام بالتخطيط والتنفيذ في نفس الدورة، يؤدي إلى نتائج غير موثوقة.

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

14. المبدأ 3: حلقات التغذية الراجعة لا يمكن التنازل عنها

  • OpenAI: الوكيل يدمج في CI/CD و مراقبة الأداء
  • Anthropic: وكيل تقييم خاص + اختبار تلقائي عبر المتصفح
  • ThoughtWorks: يُنظر إليها كـ "مستشعر"، ويؤكد أن الاعتماد فقط على feedforward لن يضمن فعالية الإرشادات

ثلاث مدارس تتبع نفس المبدأ بثلاث طرق:

| المدرسة | مصدر التغذية الراجعة |
| --- | --- |
| OpenAI | اختبارات تلقائية + CI |
| Anthropic | LLM آخر |
| ThoughtWorks | استخدام الاثنين معًا |

الاختلاف هو: من أين يأتي التغذية الراجعة. لكن لا خلاف على: ضرورة وجودها.

بدون حلقات تغذية راجعة، harness هو مجرد استدعاء أوامر مع خطوات إضافية.

15. المبدأ 4: تنفيذ مهمة واحدة في كل مرة

  • OpenAI: تقسيم الهدف إلى أجزاء أصغر، أولوية عميقة
  • Anthropic: فرض "مهمة واحدة في كل سبرينت"، والانتهاء ثم الالتزام
  • ThoughtWorks: دورة حياة متعددة المراحل (ما قبل الدمج → بعد الدمج → المراقبة المستمرة)

محاولة إنجاز الكثير من الوكلاء في نفس الوقت تؤدي إلى:

  • استهلاك السياق بسرعة
  • فقدان التماسك
  • إهمال الطلبات بشكل صامت

روتين Anthropic: قراءة التقدم → اختيار ميزة واحدة → التنفيذ → الالتزام → تكرار.

"النهج التدريجي" هو القاسم المشترك بين جميع harness الناجحة.

16. المبدأ 5: قاعدة الكود هي الوثيقة

  • OpenAI: AGENT.md مدمج في المستودع
  • Anthropic: قائمة الميزات، ملفات التقدم، سجل git هو آلية استمرارية الوكيل
  • ThoughtWorks: يقيس "قابلية harness" — مدى قابلية قراءة قاعدة الكود للوكيل

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

إذا لم تكن المبادئ، القيود، قرارات الهيكلية موجودة في قاعدة الكود → الوكيل لن يعرفها.

المعنى العملي

  • الفرق الذي يستثمر في تنظيم الكود، يحصل مجانًا على أداء أفضل للوكيل
  • مستودع غير منظم + وكيل AI = فوضى متزايدة مع النمو

17. تدهور Harness (Harness Decay) حقيقي

عندما انتقلت Anthropic من إصدار Opus 4.5 إلى 4.6 — تحليل السبرينت (الذي كان ضروريًا) أصبح عبئًا.

قدرة النموذج على التخطيط تحسنت، مما جعل تلك الأجزاء زائدة عن الحاجة.

الأجزاء التي كانت تتحمل عبء في مارس، أصبحت عبئًا في أبريل.

ثم إصدار Opus 4.7 — بدأ النموذج في التحقق من مخرجاته الخاصة، وتقلص دور وكيل التقييم مرة أخرى.

هذا هو تدهور Harness

كل مكون في harness يحمل فرضية "ما لا يستطيع النموذج فعله". مع تقدم النموذج، تصبح تلك الفرضيات قديمة، وتتحول المكونات إلى عبء.

| إصدار النموذج | الحالة |
| --- | --- |
| Opus 4.5 | تحليل السبرينت + تقييم كل سبرينت |
| Opus 4.6 | بدون تحليل السبرينت + تقييم واحد شامل (توفير 38%) |
| Opus 4.7 | التحقق الذاتي من النموذج، وتقليل دور التقييم |

البناء من أجل الحذف (Build to Delete)

نصيحة Philipp Schmid: "بناء للحذف".

عند تصميم كل مكون من مكونات harness، صممه ليكون قابلًا للإزالة.

اختبر كل مكون بشكل دوري — قم بإيقافه، وراقب إذا كانت جودة المخرجات تتأثر. إن لم تتأثر → احذفه.

| الفريق | إعادة الهيكلة خلال 6 أشهر |
| --- | --- |
| Manus | أعاد هيكلة harness 5 مرات |
| LangChain | أعاد تنظيمه 3 مرات خلال سنة |
| Vercel | أزال 80% من الأدوات → تحسن الأداء |

هذه ليست علامات على سوء الهندسة. إنها نتيجة طبيعية لـ "بناء أشياء فوق نماذج سريعة التطور".

المكونات التي تتوقف عن العمل تستهلك tokens في كل تشغيل، ولا تقدم قيمة، وتعد مضيعة بحتة.

18. الواقع من حيث التكاليف

الأرقام الصادقة من اختبار A/B لـ Anthropic:

| الإعداد | التكاليف | الوقت | النتيجة |
| --- | --- | --- | --- |
| وكيل واحد (بدون harness) | 9 دولارات | 20 دقيقة | واجهة معطلة، والنظام الأساسي معطل |
| harness كامل (Opus 4.5) | 200 دولار | 6 ساعات | نظام يعمل وواجهة متقنة، ونتائج صحيحة |

22 ضعف التكاليف — مقابل منتج يعمل فعلاً، وليس مجرد عرض توضيحي.

هل يستحق ذلك؟ يعتمد على مدى تكلفة الإصدار المعطل على فريقك.

لكن هذا الجزء غير مذكور عادة

مجموعة harness + النموذج تتطور باستمرار.

حيث أن ترقية نموذج بقيمة 200 دولار، تخفض التكاليف إلى 124 دولارًا.

| الاتجاه |
| --- |
| نموذج أفضل = harness أبسط = تكلفة أقل لكل تشغيل = نتائج أسرع |

الفائز في 2026 ليس من يكتب أفضل كود.

هم من يصمم أفضل "قيود".

وهم مستعدون لترك تلك القيود عندما تتوقف عن جني الأرباح.

ملخص كامل

ما هو harness

  1. الوكيل = النموذج + Harness
  2. النموذج = CPU، وHarness = نظام التشغيل
  3. مع نموذج واحد، harness أفضل → +13% أداء

5 منتجات harness

  1. CLAUDE.md / AGENT.md — وثائق انضمام الوكيل
  2. قائمة ميزات JSON — تتبع التقدم + مجموعة اختبارات موحدة
  3. إجراءات تهيئة الجلسة — نفس 7 خطوات التشغيل
  4. عقد السبرينت — قبل كتابة الكود، تفاوض الوكيل
  5. قالب المهام الهيكلية — مسارات الملفات الحقيقية، الأنماط الحقيقية

3 مدارس

  1. OpenAI: تصميم البيئة، تشغيل الوكيل فيها
  2. Anthropic: فصل "العمل" و"المراجعة"
  3. ThoughtWorks: إطار 2×2 لل feedforward/feedback

5 مبادئ عالمية

  1. السياق يتفوق على التعليمات
  2. التخطيط والتنفيذ يجب أن يكونا منفصلين
  3. حلقات التغذية الراجعة لا يمكن التنازل عنها
  4. تنفيذ مهمة واحدة في كل مرة
  5. قاعدة الكود هي الوثيقة

المفارقة

  1. تدهور Harness — ما كان فعالاً الشهر الماضي، يتراجع الآن
  2. البناء من أجل الحذف — اختبار وإزالة المكونات الميتة
  3. الواقع من حيث التكاليف — نموذج أفضل = harness أبسط = تكلفة أقل لكل تشغيل

الفائز في 2026 ليس من يكتب أفضل كود. هم من يصمم أفضل "قيود" — ومستعدون لتركها عندما تتوقف عن جني الأرباح.

شاهد النسخة الأصلية
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
  • أعجبني
  • تعليق
  • إعادة النشر
  • مشاركة
تعليق
إضافة تعليق
إضافة تعليق
لا توجد تعليقات
  • مُثبت