OpenAI "فككت وبيعت" Codex

لأنه هذه المرة، قامت شركة OpenAI "بتفكيك وبيع" المخطوطة.

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

الدستور الغذائي كخدمة؟

في الواقع، قامت شركة OpenAI بتفكيك المخطوطة لفترة طويلة.

في وقت مبكر من أبريل 2025، عندما أصدرت OpenAI لأول مرة o3 وo4-mini، كانت مفتوحة المصدر لـ Codex CLI. إنه يشبه إلى حد ما إصدار OpenAI من Claude Code، المثبت مباشرة في المحطة المحلية. كيفية تشغيل الوكيل وكيفية استدعاء الأدوات كلها منشورة بوضوح على GitHub. إذا كنت على استعداد لبذل هذا الجهد، فيمكنك استعادته وتعديله وتشغيله بنفسك.

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

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

بعد بضعة أشهر، في أكتوبر 2025، أصدرت OpenAI حزمة Codex SDK.

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

ومع ذلك، فإن SDK مناسب بشكل أساسي لاستدعاء Codex في البرامج، ولم يفتح بعد إمكانات التفاعل الكاملة لـ Codex. إنه مناسب جدًا لسير العمل في الخلفية والبرامج النصية الآلية والبرامج من جانب الخادم. ولكن إذا كنت تريد إنشاء عميل كامل مثل Codex IDE، فلا يزال الأمر صعبًا بعض الشيء.

لذا، في فبراير 2026، أصدرت OpenAI رسميًا خادم Codex App Server، ولأول مرة شرحت بشكل منهجي الحزام في Codex بوضوح.

أوضح OpenAI بوضوح أن امتدادات Codex Web وCLI وIDE وMac App تبدو وكأنها منتجات مختلفة، ولكنها في الواقع تقوم بتشغيل نفس Codex Harness تحتها، وهي الطبقة المسؤولة عن Agent Loop وThread وتنفيذ الأداة والمصادقة وحالة الإدارة.

يضيف خادم التطبيقات واجهة JSON-RPC ثنائية الاتجاه إلى هذه المجموعة الكاملة من أدوات Harness. لا يحتاج JetBrains أو Xcode أو العملاء الآخرون إلى إعادة إنشاء Agent Loop. يمكنهم تشغيل خادم التطبيقات مباشرة لتشغيل المخطوطة الكاملة.

باستخدام خادم التطبيقات، يمكن توصيل المنتجات الأخرى مباشرةً بأداة Codex Harness الكاملة.

ولكن في هذه المرحلة، هناك مشكلة أخيرة لا تزال بحاجة إلى حل.

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

لإعطاء مثال أكثر تحديدًا، إذا كنت تستخدم App Server لإنشاء موقع Coding Agent الخاص بك، فقد تم توصيل الواجهة الأمامية بـ Codex، ولكن عندما ينقر المستخدم على "إصلاح هذا المستودع"، فستظل بحاجة إلى إيجاد طريقة لحل عدد كبير من مشكلات التشغيل والبنية التحتية اللاحقة.

ثم جاء يوم 19 أغسطس. في هذا اليوم، قامت OpenAI بتوحيد واجهة سطر الأوامر (CLI) وSDK وخادم التطبيقات التي تم فتحها في العام الماضي في سرد ​​النظام الأساسي لـ "Open Codex Harness"، وقامت بترقية Codex بوضوح من منتج إلى منصة.

ثم في 10 سبتمبر (بتوقيت الولايات المتحدة)، وهو يوم أمس، تم فتح واجهة برمجة تطبيقات الوكلاء رسميًا للاختبار العام.

هذه المرة، يحتاج المطورون فقط إلى إخبار واجهة برمجة التطبيقات (API) بأربعة أشياء - المهام والنماذج والأدوات وبيئات التشغيل - لإنشاء وكيل مباشرةً. تتم استضافة Codex Harness، المسؤولة عن ضغط سياق الجلسة الطويلة وجدولة الأدوات وتعاون الوكلاء الفرعيين، وصيانتها بواسطة OpenAI نفسها.

يمكنك أيضًا اختيار الجهاز الذي يعمل عليه الوكيل بالفعل. يمكنك اختيار ما إذا كنت تريد استخدام Sandbox الخاص بـ OpenAI، أو البنية التحتية الخاصة بك، أو بيئات الجهات الخارجية مثل Cloudflare، وE2B، وModal. يتم توفير الأداة بواسطة OpenAI، ويتم تحديد بيئة التنفيذ من قبل المطور.

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

يدفع المطورون بناءً على الرموز المميزة والأدوات المستخدمة فعليًا؛ إذا تم استخدام بيئة الحماية الخاصة باستضافة OpenAI، فسيتم حساب موارد الحوسبة بشكل منفصل.

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

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

الدستور الغذائي كخدمة.

بدأ الحزام أيضًا في الشوكة

وبالطبع فإن OpenAI ليست الشركة الوحيدة التي تتطلع إلى Harness.

عندما تم إصدار DeepSeek Harness (المشار إليه فيما بعد باسم DSH)، تم تقديم معادلة عالية جدًا:

الوكيل = الموديل + Harness.

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

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

إن الشعار "كل شيء عبارة عن مكون إضافي" ليس مجرد مزحة. من الأفضل للجميع كتابة المكونات الإضافية والتكيف مع DSH. في النهاية، بغض النظر عما إذا كان DeepSeek أو نماذج أخرى تعمل في الأعلى، يمكن استخدام نفس مجموعة الحزام في الأسفل.

يعد هذا تناقضًا مثيرًا للاهتمام مع الاتجاه الذي تسلكه OpenAI الآن.

على الرغم من أن OpenAI لديها أيضًا مصدر مفتوح لأداة Codex، فمن الواضح أن Agents API تسير في الاتجاه الآخر: يمكنك استخدام الأداة مفتوحة المصدر، ولكن إذا وجدت أنها مزعجة، فيمكنك تجاهلها والسماح لي بترتيبها لك.

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

بمعنى ما، هناك طريقان غامضان على مستوى الحزام:

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

يمكننا أيضًا أن نعتقد أن أحدهما يريد أن يجعل Harness يشبه Linux أكثر فأكثر، والآخر يريد أن يجعل Harness يشبه AWS أكثر فأكثر.

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

ومن المثير للاهتمام أن Anthropic تتقدم بالفعل بخطوة واحدة على OpenAI في تحويل Harness إلى خدمة.

في وقت مبكر من سبتمبر 2025، أطلقت Anthropic حزمة Claude Agent SDK، وفتحت الأدوات وإدارة السياق ونظام الأذونات وإمكانيات الوكيل الفرعي وراء Claude Code للمطورين، حتى يتمكن الآخرون من استخدام هذه المجموعة من الأشياء كوكلاء.

في أبريل من هذا العام، أطلقت شركة Claude Managed Agents حتى قبل إطلاق OpenAI. يتم تقسيم الجلسة والحزام وصندوق الحماية إلى ثلاث طبقات مستقلة: الأنثروبي مسؤول عن استضافة الحزام والمهام الطويلة. يمكن توفير صندوق الحماية بواسطة Anthropic أو يمكن توصيله ببيئات تنفيذ أخرى. هذه الفكرة في الواقع قريبة جدًا من واجهة برمجة تطبيقات الوكلاء الحالية. تعرفها Anthropic نفسها بأنها "خدمة استضافة لمهام الوكيل طويلة المدى".

وبمعنى ما، تواصل OpenAI المضي قدمًا على طول المسار الذي سلكته الأنثروبيك هذه المرة. الفرق هو أن OpenAI لديه مخطوطة أكثر "منتجة".

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

بالمناسبة، انضمت Google بالفعل إلى هذا المسار. في مؤتمر I/O في مايو من هذا العام، أطلقت Gemini API برنامج Managed Agents، والذي حول أيضًا Antigravity Harness وsandbox إلى خدمات مُدارة. لكن بطاقات جوجل لا تتوقف عند هذا الحد، وهو ما سنتحدث عنه لاحقًا.

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

من هو الرابح الأكبر؟

بعد كل شيء، لماذا بدأت الشركات النموذجية الآن في الاستيلاء على Harness؟

تمامًا مثل المعادلة التي قدمها DSH، Agent = Model + Harness، يمكن للنموذج أن يخبر الوكيل بما يجب فعله بعد ذلك، ولكن لتشغيل مهمة من البداية إلى النهاية، لا يزال يتعين عليه معرفة مكان الملف، والأداة التي يجب استدعاؤها، وكيفية الاسترداد عند حدوث خطأ، ومكان كتابة النتائج أخيرًا.

بعبارة أخرى، يحدد النموذج الحد الأعلى لقدرة العميل، ويحدد Harness بشكل متزايد ما إذا كان يمكنه إكمال المهمة.

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

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

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

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

تحتاج الشركات النموذجية إلى الوصول إلى البوابات التي لا تمتلكها، وتلك الشركات التي كانت تصنع البرامج المكتبية ومنصات الإنترنت لأكثر من عشر سنوات لديها بالفعل هذه البوابات.

بعبارة أخرى،

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

بالنظر إلى هذا الطريق، إذا أردنا العثور على مشغل "مجموعة العائلة" الذي يتمتع بأكبر قدر من المزايا، فمن المحتمل أن يكون Google هو الأكثر مبالغة.

بدءًا من TPU والبنية التحتية السحابية وGemini وحتى Search وWorkspace وChrome وAndroid، تغطي Google تقريبًا جميع الجوانب الرئيسية للذكاء الاصطناعي بدءًا من التكنولوجيا الأساسية ووصولاً إلى المستخدمين النهائيين. من الطبيعي أن يشكل البحث وGmail والتقويم وDrive وYouTube والخرائط وغيرها من المنتجات بيئة رقمية يمكن للوكلاء الاتصال بها. كانت هذه الأصول عبارة عن مداخل مستقلة في الجيل السابق من الإنترنت، ولكن في عصر العميل، يمكن إعادة تنظيمها تحت نفس المهمة.

في الواقع، بدأت Google في دمج إمكانات الوكيل المنتشرة في العديد من المنتجات في نظام التنفيذ نفسه في الأسفل. Gemini Spark والوكلاء المُدارون في Gemini API وحتى بعض تجارب الوكلاء في البحث يتشاركون تدريجيًا في نفس أداة مكافحة الجاذبية وراءهم.

ولكن من ناحية المستخدم، لا تزال الأمور فوضوية بعض الشيء.

اليوم، تمتلك Google أيضًا Gemini Spark، وWorkspace Studio، وAntigravity، وGemini Enterprise، ووكلاء المعلومات في البحث. إنهم يواجهون مستخدمين وسيناريوهات مختلفة، ولكن بالنسبة للأشخاص العاديين، عندما يريدون تسليم مسألة معقدة إلى Google، فإنهم ما زالوا لا يعرفون إلى من يلجأون.

بالنسبة لشركة Google، فهي تتمتع بالفعل بمعظم الشروط اللازمة لإنجاز كل هذا. ما هو مفقود هو إجابة منتج بسيطة بما فيه الكفاية.

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

ومع ذلك، حتى لو قامت Google بوضع "مجموعة العائلة" هذه في وكيل، فمن المرجح أن المستخدمين المحليين لن يتمكنوا من مشاهدتها إلا أولاً.

دعونا نلقي نظرة على حرب العملاء المحليين أولاً ونرى كيف سيتم خوضها بعد ذلك.