ما ستتعلمه

يغطي هذا الدليل Harness Engineering من المبادئ الأولى إلى التنفيذ العملي. ستفهم ماهيته، ولماذا راهنت OpenAI بأكبر مشروع داخلي لها عليه، والأنماط المعمارية المحددة التي تجعله يعمل، وكيفية تطبيق هذه المبادئ على سير عمل وكلاء AI الخاص بك — سواء كنت تستخدم Codex أو Claude Code أو OpenCode أو أي نظام وكيل آخر.

Harness Engineering: الدليل الكامل لتطوير وكلاء AI في 2026

إذا كان عام 2025 هو العام الذي أثبت فيه وكلاء AI قدرتهم على كتابة الكود، فإن عام 2026 هو العام الذي تعلمنا فيه أن الوكيل ليس هو الجزء الصعب — بل الـ harness هو الصعب.

نشر فريق Codex في OpenAI مقالاً بارزاً في February 2026 يصف كيف بنوا تطبيقاً إنتاجياً يحتوي على ما يقرب من 1,000,000 سطر من الكود حيث لم يكتب البشر أي سطر منها. لم يكن السر في نموذج أفضل أو prompt أذكى. بل كان النظام الذي بنوه حول الوكيل — الـ harness. المصدر

يفكك هذا الدليل كل مبدأ ونمط وتقنية عملية من تلك التجربة وحركة Harness Engineering الأوسع التي ظهرت حولها.

الجزء 1: ما هو Harness Engineering؟

التعريف

Harness engineering هو التخصص المعني بتصميم البيئة الكاملة — السقالات (scaffolding)، حلقات التغذية الراجعة، التوثيق، القيود المعمارية، والمصنوعات القابلة للقراءة آليًا — التي تسمح لوكلاء البرمجة المعتمدين على AI بالقيام بعمل موثوق وعالي الجودة على نطاق واسع بأقل قدر من التدخل البشري.

يأتي مصطلح "harness" من عدة الخيل: الأعنة، السرج، واللجام — المجموعة الكاملة من المعدات لتوجيه حيوان قوي ولكن لا يمكن التنبؤ به في الاتجاه الصحيح. الحصان غير المنضبط خطر. أما الحصان المجهز بـ harness فقد بنى الحضارات. وينطبق الشيء نفسه على وكلاء AI. المصدر

لماذا ظهر الآن

يعكس التحول من Prompt Engineering إلى Harness Engineering نضج مشهد تطوير AI:

المصدر

البصيرة الرئيسية التي دفعت هذا الانتقال: أصبح الوكلاء قادرين بما يكفي بحيث تحولت نقطة الاختناق من جودة النموذج إلى جودة البيئة. إن نموذجاً متطوراً يعمل في مستودع (repository) سيئ التنظيم ينتج نتائج أسوأ من نموذج متوسط يعمل في بيئة جيدة التجهيز بـ harness.

الجزء 2: تجربة OpenAI Codex

النطاق

في تجربة داخلية استمرت 5 أشهر، قام مهندسو OpenAI ببناء وشحن منتج تجريبي يحتوي على ما يقرب من 1,000,000 سطر من الكود. يمتد المستودع ليشمل منطق التطبيق، البنية التحتية، الأدوات، التوثيق، وأدوات المطورين الداخلية. لم يكن هناك كود مكتوب بشرياً مسبقاً لترسيخ النظام. المصدر

الفريق

بدأ المشروع بـ 3 مهندسين فقط يديرون Codex. خلال فترة الـ 5 أشهر، تم فتح ودمج ما يقرب من 1,500 pull request. مع نمو الفريق إلى 7 مهندسين، زادت الإنتاجية — وهي نتيجة غير متوقعة تشير إلى أن الـ harness نفسه كان هو المضاعف الأساسي للإنتاجية، وليس المهارة الفردية.

تُقدر OpenAI أنهم بنوا النظام في حوالي 1/10 من الوقت الذي كان سيستغرقه كتابة الكود يدوياً. المصدر

السقالة الأولية

بدأ المشروع باستخدام Codex CLI لإنشاء السقالة الأولية باستخدام GPT-5، بتوجيه من مجموعة صغيرة من القوالب الموجودة:

• هيكل المستودع واتفاقيات المجلدات
• إعدادات CI/CD
• قواعد تنسيق الكود و linting
• إعداد مدير الحزم
• الهيكل الأساسي لإطار عمل التطبيق

من هذه البذرة، نما كل شيء آخر من خلال التطوير المعتمد على الوكلاء.

مشكلة يوم الجمعة

في وقت مبكر من التجربة، اكتشف الفريق مشكلة حرجة: كانوا يقضون كل يوم جمعة — 20% من وقتهم الهندسي — في تنظيف ما أسموه "AI slop" (الفوضى الناتجة عن AI). شمل ذلك أنماطاً غير متسقة، ومنطقاً مكرراً، ومتغيرات مسماة بشكل خاطئ، وانحرافاً معمارياً.

لم يكن ذلك قابلاً للتوسع. كان الحل هو تشفير معاييرهم في الـ harness نفسه بحيث ينتج الوكلاء مخرجات أنظف منذ البداية، وبناء أنظمة تنظيف مؤتمتة للانحراف المتبقي.

الجزء 3: المبادئ الخمسة الأساسية

المبدأ 1: المعرفة القائمة على المستودع أولاً

من منظور الوكيل، أي شيء لا يمكنه الوصول إليه في السياق (in-context) أثناء التشغيل هو فعلياً غير موجود. المعرفة التي تعيش في Google Docs، أو سلاسل الدردشة، أو رسائل Slack، أو رؤوس الأشخاص غير مرئية للنظام.

هذا يعني أن جميع المعارف يجب أن تعيش كمصنوعات محلية في المستودع ومؤرخة الإصدار:

• الكود — المصنوع الأساسي
• توثيق Markdown — القرارات المعمارية، الاتفاقيات، أدلة التهيئة
• المخططات (Schemas) — عقود API، مخططات قواعد البيانات، تعريفات الأنواع (types)
• الخطط القابلة للتنفيذ — تفاصيل المهام خطوة بخطوة التي يمكن للوكيل اتباعها
• الإعدادات — قواعد linter، مسارات CI، معايير التنسيق

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

التنفيذ العملي:

# ARCHITECTURE.md (lives in repo root)

## Dependency Rules
- UI components may import from Service layer but never from Repo layer
- Service layer may not import from Runtime layer
- All cross-domain communication goes through typed event bus

## Naming Conventions
- React components: PascalCase, suffixed with purpose (UserListPage, UserCard)
- Services: camelCase, suffixed with Service (userService, authService)
- Types: PascalCase, prefixed with domain (UserProfile, OrderItem)

## Testing Requirements
- All Service functions require unit tests
- All API endpoints require integration tests
- Coverage threshold: 80% per package

المبدأ 2: المبادئ الذهبية

المبادئ الذهبية هي قواعد ميكانيكية حازمة مشفرة مباشرة في المستودع تحافظ على كود المشروع مقروءاً ومتسقاً لعمليات تشغيل الوكيل المستقبلية. إنها ليست إرشادات تطلعية — إنها قيود مفروضة.

أمثلة من تجربة OpenAI:

1. تفضيل حزم الأدوات المشتركة على المساعدين المصنوعين يدوياً — لتركيز المتغيرات بحيث عندما يحتاج السلوك إلى التغيير، فإنه يتغير في مكان واحد.
2. عدم فحص البيانات بأسلوب YOLO — التحقق من الحدود أو الاعتماد على SDKs ذات أنواع محددة حتى لا يبني الوكلاء بالصدفة على أشكال بيانات مخمنة.
3. مفهوم واحد، ملف واحد — يجب أن يمثل كل ملف مفهوماً واحداً، مما يسهل على الوكلاء العثور على الموقع الصحيح وتعديله.
4. الوضوح على الضمنية — تجنب السلوك السحري الذي يحتاج الوكيل إلى معرفة قبلية لفهمه.

المصدر

هذه المبادئ ليست مجرد توثيق. يتم فرضها من خلال:

• قواعد Linter — أدوات linter مخصصة (تم إنشاؤها بواسطة Codex نفسه) تنبه إلى المخالفات.
• الاختبارات الهيكلية — اختبارات تتحقق من الامتثال المعماري.
• بوابات CI — يتم رفض pull requests التي تنتهك المبادئ الذهبية تلقائياً.

المبدأ 3: العمارة الطبقية مع الإنفاذ الميكانيكي

تم تقسيم كل مجال عمل في مشروع OpenAI إلى مجموعة ثابتة من الطبقات مع اتجاهات تبعية يتم التحقق منها بدقة:

Types → Config → Repo → Service → Runtime → UI

تتدفق التبعيات في اتجاه واحد فقط. قد يعتمد مكون UI على Runtime و Service، ولكن لا يجوز للـ Service أبداً الاستيراد من UI. قد يعتمد الـ Repo على Config و Types، ولكن أبداً على Service. المصدر

يتم فرض هذه القيود ميكانيكياً:

// structural-test.ts — enforces dependency boundaries
import { analyzeImports } from './tools/import-analyzer';

describe('Dependency Layer Enforcement', () => {
  it('Service layer must not import from Runtime', () => {
    const violations = analyzeImports({
      sourceLayer: 'service',
      forbiddenLayers: ['runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });

  it('Repo layer must not import from Service', () => {
    const violations = analyzeImports({
      sourceLayer: 'repo',
      forbiddenLayers: ['service', 'runtime', 'ui'],
    });
    expect(violations).toEqual([]);
  });
});

تتحقق الاختبارات الهيكلية من الامتثال وتمنع انتهاكات الطبقات المعيارية. هذا ليس اقتراحاً — بل يتم فرضه بواسطة CI. كل pull request، سواء أنشأه بشر أو وكيل، يجب أن يجتاز هذه الاختبارات.

المبدأ 4: جمع القمامة المؤتمت

حتى مع المبادئ الذهبية والإنفاذ الهيكلي، فإن الكود الذي ينشئه الوكلاء ينحرف بمرور الوقت. حل فريق OpenAI ذلك من خلال تنفيذ جمع القمامة (garbage collection) المؤتمت — وهي مهام خلفية دورية تقوم بـ:

1. المسح بحثاً عن الانحرافات عن المبادئ الذهبية عبر قاعدة الكود بأكملها.
2. تحديث درجات الجودة لكل وحدة بناءً على درجات الامتثال.
3. فتح pull requests لإعادة الهيكلة (refactoring) تستهدف إصلاح فئات معينة من الانحراف.

استبدل هذا "تنظيف يوم الجمعة" اليدوي بنظام يعمل باستمرار. يتم تشغيل جامع القمامة نفسه بواسطة وكلاء Codex، مما يخلق حلقة صيانة ذاتية. المصدر

# .github/workflows/garbage-collection.yml
name: Codebase Garbage Collection
on:
  schedule:
    - cron: '0 2 * * *'  # Run nightly at 2 AM

jobs:
  gc-scan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Run golden principle scanner
        run: npx codex-gc scan --principles ./GOLDEN_PRINCIPLES.md
      - name: Generate refactoring PRs
        run: npx codex-gc fix --auto-pr --max-prs 5

المبدأ 5: الخطط القابلة للتنفيذ

قبل أن يكتب الوكلاء الكود، يكتبون الخطط. هذه الخطط ليست ملاحظات غير رسمية — بل هي وثائق منظمة وقابلة للتنفيذ تحدد:

• الهدف: ما الذي تنجزه المهمة.
• الملفات المطلوب تعديلها: قائمة صريحة بالملفات التي سيلمسها الوكيل.
• التبعيات: المهام أو الوحدات الأخرى التي يعتمد عليها هذا العمل.
• معايير القبول: كيفية التحقق من اكتمال العمل.
• القيود: القواعد المعمارية التي يجب عدم انتهاكها.

# Plan: Add user notification preferences

## Objective
Allow users to configure which notification channels (email, SMS, push) they
receive alerts on, with per-category granularity.

## Files to Modify
- src/types/user.ts — Add NotificationPreferences type
- src/repo/userRepo.ts — Add getPreferences/setPreferences methods
- src/service/notificationService.ts — Filter notifications by preferences
- src/ui/pages/SettingsPage.tsx — Add preferences UI section

## Constraints
- Must follow Types → Repo → Service → UI dependency flow
- NotificationPreferences type must be shared, not duplicated
- All new methods require unit tests

## Acceptance Criteria
- [ ] User can toggle email/SMS/push per notification category
- [ ] Preferences persist across sessions
- [ ] Toggling a channel off stops notifications on that channel within 30s

تعيش الخطط في المستودع كملفات markdown، وتخضع للتحكم في الإصدار، ويمكن مراجعتها قبل التنفيذ — مما يمنح البشر نقطة تفتيش بين القصد والتنفيذ.

الجزء 4: حلقة وكيل Codex

إن فهم كيفية عمل حلقة وكيل Codex داخل الـ harness أمر ضروري لـ Harness Engineering الفعال.

بنية الحلقة

نشرت OpenAI تحليلاً مفصلاً لحلقة وكيل Codex في مقالها المصاحب "Unrolling the Codex agent loop". المصدر تتبع الحلقة هذه الدورة:

Read Context → Plan → Execute → Validate → Commit (or Retry)

كل تكرار:

1. قراءة السياق: يقرأ الوكيل الملفات ذات الصلة، التوثيق، المخططات، وخطة المهمة من المستودع.
2. التخطيط: بناءً على السياق، يحدد الوكيل التغييرات التي يجب إجراؤها.
3. التنفيذ: يقوم الوكيل بكتابة أو تعديل الكود.
4. التحقق: يقوم الـ harness بتشغيل الاختبارات و linters والفحوصات الهيكلية ضد التغييرات.
5. الالتزام أو إعادة المحاولة: إذا نجح التحقق، يقوم الوكيل بعمل commit. إذا فشل، يقرأ الوكيل مخرجات الخطأ ويحاول مرة أخرى.

دور الـ harness هو جعل الخطوتين 1 و 4 غنيتين بالمعلومات قدر الإمكان. كلما قرأ الوكيل سياقاً أكثر، كانت خطته أفضل. وكلما كانت ملاحظات التحقق أكثر تحديداً، كان تقاربه مع حل ناجح أسرع.

الـ App Server Harness

في مقالهم "Unlocking the Codex harness: how we built the App Server"، تصف OpenAI البنية التحتية الملموسة التي تدعم حلقة الوكيل. المصدر يوفر App Server:

• بيئات تنفيذ معزولة (Sandboxed) لكل مهمة وكيل.
• وصول مهيأ مسبقاً للأدوات (نظام الملفات، التيرمينال، المتصفح).
• حقن تلقائي للسياق من مصنوعات المستودع.
• ملاحظات تحقق متدفقة (Streaming) حتى يتمكن الوكلاء من رؤية فشل الاختبارات في الوقت الفعلي.

الجزء 5: تطبيق Harness Engineering على فريقك

البداية: الحد الأدنى من الـ Harness القابل للتطبيق

لا تحتاج إلى تكرار كامل بنية OpenAI التحتية للاستفادة من Harness Engineering. ابدأ بهذه العناصر الأساسية:

الخطوة 1: إنشاء ملف ARCHITECTURE.md

قم بتوثيق القواعد المعمارية لمشروعك بتنسيق قابل للقراءة آلياً في جذر المستودع الخاص بك. تشمل:

• حدود الوحدات (modules) والتبعيات المسموح بها.
• اتفاقيات التسمية.
• قواعد تنظيم الملفات.
• متطلبات الاختبار.

هذا الملف الواحد يحسن بشكل كبير من جودة مخرجات الوكيل لأن الوكلاء يقرؤونه قبل إجراء التغييرات.

الخطوة 2: إضافة اختبارات هيكلية

اكتب اختبارات تتحقق من قواعدك المعمارية. لا تتحقق هذه الاختبارات من منطق العمل — بل تتحقق من تنظيم الكود بشكل صحيح:

// No service file should import from a UI module
test('service layer isolation', () => {
  const serviceFiles = glob('src/services/**/*.ts');
  for (const file of serviceFiles) {
    const imports = extractImports(file);
    const uiImports = imports.filter(i => i.startsWith('../ui/'));
    expect(uiImports).toHaveLength(0);
  }
});

الخطوة 3: تهيئة التحقق في CI

تأكد من أن مسار CI الخاص بك يشغل الاختبارات الهيكلية، و linters، وفحوصات الأنواع في كل pull request — بما في ذلك تلك التي أنشأها الوكلاء. يجب أن يرى الوكيل نفس مخرجات التحقق التي يراها المطور البشري.

الخطوة 4: كتابة خطط المهام قبل تنفيذ الوكيل

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

الخطوة 5: إعداد التنظيف المؤتمت

قم بتنفيذ مهمة CI أسبوعية أو ليلية تمسح قاعدة الكود الخاصة بك بحثاً عن انحرافات عن معاييرك الموثقة وتنشئ PRs مركزة لإعادة الهيكلة.

اختيار نظام الوكيل الخاص بك

تنطبق مبادئ Harness Engineering بغض النظر عن الوكيل الذي تستخدمه:

يعيش الـ harness في مستودعك، وليس في وكيلك. هذا يعني أنه يمكنك تبديل الوكلاء دون فقدان استثمارك في الـ harness.

التوسع من وكيل واحد إلى كثيرين

أثبتت تجربة OpenAI أن Harness Engineering يتيح تنفيذ الوكلاء بشكل متوازٍ. نظراً لأن الـ harness يفرض حدوداً معمارية، يمكن لعدة وكلاء العمل على أجزاء مختلفة من قاعدة الكود في وقت واحد دون التسبب في تعارضات.

المتطلبات الأساسية لتنفيذ الوكلاء المتوازي:

1. ملكية واضحة للوحدات — يعمل كل وكيل ضمن حدود محددة.
2. واجهات ذات أنواع محددة بين الوحدات — يمكن للوكلاء كتابة الكود ضد الواجهات دون معرفة تفاصيل التنفيذ.
3. منع تعارض الدمج — يتم تحديد نطاق المهام لتقليل تداخل الملفات.
4. تحقق مركزي — يقدم جميع الوكلاء أعمالهم لنفس مسار CI.

الجزء 6: المزالق الشائعة والأنماط المضادة

النمط المضاد 1: معاملة الوكيل كأنه الـ Harness

الوكيل ليس هو الـ harness. الـ harness هو البيئة التي يعمل فيها الوكيل. طلب نموذج أذكى للتعويض عن مستودع سيئ التنظيم هو النهج الخاطئ. أصلح البيئة، وليس الـ prompt.

النمط المضاد 2: التوثيق في المكان الخاطئ

إذا كانت قراراتك المعمارية تعيش في Confluence أو Notion أو Google Docs، فلن يتمكن الوكلاء من رؤيتها. الحل بسيط ولكنه يتطلب انضباطاً: انقل كل التوثيق المتعلق بالتطوير إلى المستودع.

النمط المضاد 3: التنظيف اليدوي بدلاً من الإنفاذ المؤتمت

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

النمط المضاد 4: الإفراط في التقييد

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

النمط المضاد 5: تجاهل ملاحظات الوكيل

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

الجزء 7: مستقبل Harness Engineering

وجهة نظر Martin Fowler

نشر Martin Fowler تحليلاً لـ Harness Engineering على مدونته، مشيراً إلى أنه يمثل تحولاً جوهرياً في كيفية عمل فرق البرمجيات. يقتبس هذا التخصص من عقود من أفضل ممارسات هندسة البرمجيات — التكامل المستمر، سجلات القرارات المعمارية، حقن التبعية — ولكنه يعيد توظيفها لعالم يقوده الوكلاء. المصدر

إطار عمل HumanLayer

نشر الفريق في HumanLayer تحليلاً يصف Harness Engineering بأنه "skill issue" (مشكلة مهارة) — بحجة أن القدرة على تصميم harnesses فعالة ستصبح التمييز الأساسي بين الفرق الهندسية عالية الأداء والمتعثرة. المصدر

ماذا يعني هذا للمطورين

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

بالنسبة للفرق التي تبني تطبيقات، فإن منصات مثل ZBuild تدمج بالفعل مبادئ Harness Engineering في سير عمل بناء التطبيقات الخاص بها. بدلاً من مطالبة المطورين بتصميم harnesses خاصة بهم من الصفر، توفر ZBuild أنماطاً معمارية مهيأة مسبقاً، وإدارة التبعيات، وأنظمة تحقق توجه وكلاء AI نحو مخرجات عالية الجودة — مما يسمح للمطورين بالتركيز على قرارات المنتج بدلاً من البنية التحتية.

الآفاق الثلاثة

بالنظر إلى المستقبل، من المرجح أن يتطور Harness Engineering عبر 3 مراحل:

1. المدى القريب (2026): تتبنى الفرق التوثيق القائم على المستودع أولاً، والاختبارات الهيكلية، والمبادئ الذهبية. يصبح التطوير بمساعدة الوكيل ممارسة قياسية للمشاريع المجهزة جيداً بـ harness.

2. المدى المتوسط (2027): يصبح إنشاء الـ harness نفسه معتمداً على الوكلاء. يحلل الوكلاء قواعد الكود الحالية ويقترحون إعدادات الـ harness — قواعد linter، الاختبارات الهيكلية، حدود التبعية — بناءً على الأنماط التي يلاحظونها.

3. المدى البعيد (2028+): تصبح الـ harnesses تكيفية. بدلاً من القواعد الثابتة، تتطور بناءً على نتائج الكود الذي أنشأه الوكيل، مما يؤدي تلقائياً إلى تشديد القيود في المناطق التي ينتج فيها الوكلاء أخطاءً بشكل متكرر وتخفيف القيود حيث ينجحون باستمرار.

الجزء 8: قائمة المراجعة العملية

استخدم قائمة المراجعة هذه لتقييم مدى نضج Harness Engineering في فريقك:

التأسيس (ابدأ هنا)

• وجود ملف ARCHITECTURE.md في جذر المستودع.
• تنسيق الكود مؤتمت (Prettier, Black, gofmt).
• تشغيل Linting في كل pull request.
• فرض فحص الأنواع (TypeScript strict, mypy, إلخ).

المستوى المتوسط

• اختبارات هيكلية تتحقق من حدود التبعية.
• المبادئ الذهبية موثقة وقابلة للفرض آلياً.
• كتابة خطط المهام قبل تنفيذ الوكيل.
• تخضع الـ PRs التي ينشئها الوكيل لنفس CI الخاص بـ PRs البشرية.

المستوى المتقدم

• تشغيل جمع القمامة المؤتمت وفق جدول زمني.
• قدرة عدة وكلاء على العمل بالتوازي دون تعارضات.
• تتبع أنماط فشل الوكيل واستخدامها لتحسين الـ harness.
• الـ harness نفسه خاضع للتحكم في الإصدار والمراجعة مثل الكود.

المستوى الخبير

• ينشئ الوكلاء أجزاءً من الـ harness (قواعد linter، اختبارات هيكلية).
• تخصيص درجات جودة تلقائياً لكل وحدة.
• تحسينات الـ harness مدفوعة بالبيانات بناءً على معدلات نجاح الوكيل.
• يشحن الفريق كوداً أكثر لكل مهندس أسبوعياً مقارنة بما قبل اعتماد الوكلاء.

الخاتمة

Harness engineering ليس مجرد صرعة عابرة. إنه التطور الطبيعي لهندسة البرمجيات في عصر أصبح فيه وكلاء AI قادرين بما يكفي لكتابة كود إنتاجي ولكنهم يحتاجون إلى بيئات منظمة للقيام بذلك بشكل جيد. أثبتت تجربة المليون سطر من OpenAI المفهوم على نطاق واسع، والمبادئ التي صاغوها — المعرفة القائمة على المستودع أولاً، المبادئ الذهبية، العمارة الطبقية، جمع القمامة المؤتمت، والخطط القابلة للتنفيذ — قابلة للتطبيق على الفرق من أي حجم.

الفرق التي ستتقن Harness Engineering في 2026 ستشحن بشكل أسرع، وتحافظ على جودة كود أعلى، وتتوسع بشكل أكثر فعالية من تلك التي تعامل وكلاء AI كمجرد إكمال تلقائي مطور. الوكيل هو الحصان. والـ harness هو ما يجعله مفيداً.

المصادر

• Harness Engineering: Leveraging Codex in an Agent-First World — OpenAI
• Unlocking the Codex Harness: How We Built the App Server — OpenAI
• Unrolling the Codex Agent Loop — OpenAI
• OpenAI Introduces Harness Engineering — InfoQ
• Harness Engineering — Martin Fowler
• Skill Issue: Harness Engineering for Coding Agents — HumanLayer
• From Prompt Engineering to Harness Engineering — SoftmaxData
• How to Build an Agent Harness — Study Notes
• Harness Engineering — GTCode
• OpenAI Harness Engineering: Ship 1M Lines of Code — The Neuron
• How OpenAI Built 1M Lines of Code Using Only Agents — TonyLee
• Harness Engineering — The New Discipline — CodeNote