ادعاء OpenAI بشأن «Harness» غير مُثبت.. لكن إدارة السياق ضاعفت نتائج ARC-AGI-3 ثلاث مرات

الحديث عن أن OpenAI أطلقت في 20 أغسطس إطارًا مفتوح المصدر باسم «Harness»، بترخيص Apache 2.0، ليكون منصة التنفيذ الأساسية وراء وكيلها البرمجي Codex، لا تؤكده المواد الرسمية الموثوقة المتاحة هنا. هذا الادعاء ورد في تقرير ثانوي، بينما توثق المصادر الرسمية حلقة الوكيل في Codex، وطرق دمجه، وتجربة منفصلة أظهرت أن إدارة حالة التشغيل يمكن أن تغيّر أداء النموذج بصورة كبيرة .

ما الذي تؤكده الأدلة عن بنية Codex؟

لا يعمل Codex بوصفه نموذجًا يجيب عن طلبات منفصلة فحسب؛ بل يعتمد على حلقة تنفيذ متكررة يمكن تبسيطها على النحو الآتي:

1. التخطيط للمهمة.
2. تعديل الكود.
3. تشغيل أدوات مثل الاختبارات وعمليات البناء وأدوات فحص الصياغة.
4. مراقبة النتائج.
5. إصلاح الأخطاء.
6. تحديث الوثائق أو حالة المهمة.
7. تكرار الدورة عند الحاجة.

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

وتضيف وثيقة Codex App Server مكوّنًا معماريًا مؤكدًا آخر: واجهة API ثنائية الاتجاه مبنية على JSON-RPC، تربط منطق الوكيل المشترك في Codex بواجهات متعددة، من بينها تطبيق الويب، وواجهة سطر الأوامر CLI، وإضافة بيئة التطوير IDE، وتطبيق macOS . كما تصف OpenAI أداة Codex CLI بأنها تطبيق مرجعي مفتوح المصدر، في حين يستطيع المطورون استخدام النموذج مباشرة عبر API أو اللجوء إلى Codex SDK لتبسيط عمليات الدمج .

وتقود هذه المصادر إلى صورة عملية واضحة: بيئة تنفيذ تحيط بالنموذج وتجمع الأدوات، والحالة، والملاحظات، والواجهات اللازمة لتمكين الوكيل من إنجاز عمل متعدد الخطوات. لكنها لا تثبت، بمفردها، أن OpenAI أتاحت في 20 أغسطس حزمة جديدة تحمل رسميًا اسم «Harness» وبترخيص Apache 2.0.

ما الذي لم يُثبت حتى الآن؟

لا تثبت الأدلة المقدمة ما يلي:

• حدوث إطلاق في 20 أغسطس.
• تسمية الإصدار رسميًا باسم «Harness».
• توزيعه بموجب ترخيص Apache 2.0.
• المكونات الدقيقة التي شملتها الحزمة المزعومة.
• الشركات التي تبنتها أو النتائج التي حققتها تلك الشركات.

يرد الادعاء في تقرير ثانوي يذكر

codex exec

كيف أثّر الاحتفاظ بالاستدلال وضغط السياق في ARC-AGI-3؟

تقدم تجربة أخرى من OpenAI أوضح نتيجة مدعومة بالمصادر في هذه القصة. فعند استخدام GPT-5.6 Sol على مجموعة المهام العامة من معيار ARC-AGI-3، سجل النموذج 13.3% باستخدام بيئة التشغيل القياسية. وبعد تفعيل الاحتفاظ بالاستدلال وضغط السياق عبر Responses API، ارتفعت النتيجة إلى 38.3%؛ أي تحسن يقارب ثلاثة أضعاف، مع انخفاض استهلاك رموز الإخراج بنحو ست مرات .

لم تتغير أوزان النموذج في هذه المقارنة. التغيير الأساسي كان في الطريقة التي احتفظت بها بيئة التشغيل بالحالة بين الجولات:

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

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

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

ما الذي يستطيع المطورون استخدامه اليوم؟

الخلاصة المؤكدة للمطورين ليست إعلان Apache 2.0 غير المثبت، بل أن OpenAI توفر عدة طرق لبناء تطبيقات تستفيد من السلوك البرمجي القائم على الوكلاء:

• الاستخدام المباشر عبر API: يقدمه دليل توجيه Codex باعتباره الخيار الأكثر قابلية للتخصيص .
• حزمة Codex SDK: مسار أبسط للمطورين الذين لا يريدون بناء كل الواجهات بأنفسهم .
• واجهة Codex CLI المفتوحة المصدر: تطبيق مرجعي يمكن فحصه وتعديله والاستفادة منه .
• حلقة تنفيذ الوكيل: دورة التخطيط ثم التنفيذ والتحقق والإصلاح، وهي النمط التشغيلي وراء العمل البرمجي طويل الأمد .
• التنفيذ السحابي: يستطيع Codex التعامل مع المستودعات وتشغيل الكود وتنفيذ مهام خلفية متعددة بالتوازي في بيئته السحابية .

تتيح هذه القدرات وضع الوكيل داخل منتج أو سير عمل هندسي، بدل حصره في واجهة محادثة عامة. ويمكن للمطورين إحاطته بتعليمات متخصصة وأدوات وصلاحيات وخطوات تحقق وآليات لإدارة الحالة. هذا اتجاه دمج موثق، أما القول إن إصدارًا واحدًا بترخيص Apache 2.0 جمع كل هذه العناصر رسميًا، فيبقى غير مؤكد وفق المصادر الرسمية المتاحة.

أدلة التبني أضيق من ادعاء الإطلاق

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

لكن توجد مؤشرات أوسع على استخدام Codex لدى عملاء المؤسسات. فقد ذكرت OpenAI أن Codex شكّل، حتى يونيو، 64% من إجمالي رموز الإخراج المشتركة بين Codex وChatGPT لدى عملاء المؤسسات . وتشير هذه النسبة إلى نشاط مؤسسي كبير، لكنها لا تثبت تبني حزمة Harness المزعومة، ولا تحدد شركات بعينها، ولا تثبت أثرًا تجاريًا محددًا.

الدلالة العملية والاستراتيجية

تشير الصورة الموثقة إلى انتقال من المساعدة القائمة على المحادثة إلى تفويض التنفيذ. فـCodex يجمع نموذجًا لغويًا مع أدوات، وحلقة ملاحظات متكررة، وحالة دائمة أو مضغوطة، وبيئات تنفيذ قادرة على إنجاز العمل عبر خطوات متعددة .

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

وهنا تكمن الخلاصة الأهم من تجربة ARC-AGI-3: تغيير «بيئة التشغيل» قد يغير القدرة والكفاءة معًا. لكن بناءً على الأدلة المتاحة، من الأدق الحديث عن بيئة تشغيل Codex ومكونات API الموثقة، لا تقديم إطلاق «Harness» بترخيص Apache 2.0 في 20 أغسطس باعتباره حقيقة ثابتة.