كيف أنشأت OpenAI مليون سطر برمجي باستخدام الوكلاء فقط: 5 مبادئ لهندسة الـ Harness

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

الـ Harness هو الغلاف الأداتي الذي يمكّن وكيل الذكاء الاصطناعي من التأثير في العالم الحقيقي. إذا كان نموذج الاستدلال هو الدماغ، فالـ Harness هو اليدان والقدمان. قراءة الملفات، تعديل الشيفرة، تشغيل الاختبارات، النشر في بيئة الإنتاج, كل ذلك يحدث داخل الـ Harness.

بدأ فريق داخلي في OpenAI من مستودع فارغ في نهاية أغسطس 2025، وبنى منتجاً من مليون سطر باستخدام وكلاء Codex فقط. الشرط كان بسيطاً: لا شيفرة مكتوبة بشرياً. أفادوا بأن الوقت المطلوب كان عُشر الوقت مقارنة بالتطوير اليدوي. المبادئ الخمسة التي اكتشفوها خلال هذه العملية مفصّلة أدناه.

المعرفة التي لا يراها الوكيل غير موجودة

من منظور Codex، المعلومات التي لا يمكن الوصول إليها أثناء التشغيل هي كأنها غير موجودة. مستندات التخطيط في Google Docs، قرارات البنية المتفق عليها في Slack، المعرفة الضمنية المخزنة في رأس شخص ما, لا شيء من ذلك مرئي. إنه نفس الوضع الذي سيواجهه موظف جديد ينضم بعد ثلاثة أشهر.

لذلك نقل الفريق كل قرار إلى المستودع على شكل ملفات Markdown، ومخططات Schema، وخطط تنفيذ (ExecPlans).

• ExecPlan هو مستند تصميم مكتفٍ ذاتياً معرّف في PLANS.md
• معيار القبول: أن يتمكن مبتدئ من قراءته وتنفيذ الميزة من البداية للنهاية
• هناك حالات عمل فيها Codex بشكل متواصل لأكثر من 7 ساعات بأمر واحد
• البنية توسّع مفهوم ARCHITECTURE.md من matklad لاستخدام الوكلاء

اسأل “ما القدرة المفقودة” بدلاً من “حاول أكثر”

في البداية، كانت سرعة الوكيل أقل من المتوقع. السبب لم يكن أداء النموذج بل بيئة غير مجهزة بالكامل. في كل مرة يفشل شيء، كان الفريق يسأل: “ما القدرة المفقودة، وكيف نجعلها قابلة للقراءة والتحقق من قبل الوكيل؟”

• بناء أدوات تزامن داخلية بدلاً من المكتبات الخارجية، مع تكامل 100% مع OpenTelemetry
• ما يُسمى “التقنية المملة” يتبيّن أنها مناسبة للوكلاء (بسبب استقرار الـ API وتمثيلها العالي في بيانات التدريب)

الإنفاذ الآلي وليس التوثيق هو ما يحافظ على اتساق الشيفرة

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

• طبقات ثابتة لكل نطاق عمل: Providers → Service → Runtime → UI
• بنية اهتمامات مشتركة حيث يتم مشاركة Types وConfig وRepo في المستويات الأدنى
• أدوات Lint مخصصة واختبارات هيكلية تُفشل البناء فوراً عند أي مخالفة
• أدوات الـ Lint نفسها كتبها Codex أيضاً

امنح الوكيل عيوناً وسيعمل وحده 6 ساعات

ربط الفريق Chrome DevTools Protocol ببيئة تشغيل الوكيل، مما أعطى Codex إمكانية الوصول إلى لقطات DOM، لقطات الشاشة، وإمكانيات التنقل. البنية تقارن اللقطات قبل وبعد المهمة، تراقب أحداث وقت التشغيل، ثم تطبّق الإصلاحات في حلقة حتى يصبح كل شيء نظيفاً.

أدوات المراقبة رُبطت بنفس الطريقة. تُطلق حزمة مراقبة مؤقتة لكل git worktree وتختفي عند انتهاء العمل.

• Victoria Logs (LogQL) وVictoria Metrics (PromQL) تتيح للوكيل الاستعلام عن السجلات والمقاييس مباشرة
• أوامر مثل “اجعل الخدمة تبدأ في أقل من 800 مللي ثانية” أصبحت قابلة للتنفيذ
• تشغيلات Codex فردية تحافظ بانتظام على التركيز في مهمة واحدة لأكثر من 6 ساعات

قدّم خريطة، لا دليلاً من 1000 صفحة

إدارة السياق تحدد فعالية الوكيل. في البداية حاول الفريق حشر كل شيء في ملف AGENTS.md ضخم واحد, وفشل. مفهوم ARCHITECTURE.md الذي كتبه matklad عام 2021 أثبت قيمته هنا. المبدأ: تقديم نظرة شاملة موجزة لبنية المشروع، تتضمن فقط ما نادراً ما يتغير. نفس المبدأ ينطبق على الوكلاء.

• ARCHITECTURE.md هو خريطة للشيفرة، وليس أطلساً للشيفرة
• الثوابت المعمارية غالباً ما تُعبَّر بصيغة “شيء ما غير موجود”
• تحديد الحدود (boundaries) بشكل صريح يقيّد كل التنفيذ اللاحق

أسئلة لا تزال مفتوحة

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

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