انتشر رسم بياني يوضح مسار عمل الهندسة الداخلية لـ OpenAI بشكل شبه واسع على X هذا الأسبوع. أظهر عشرة مربعات، بدءًا من "مُنشئ البرامج يحدد النتيجة" وصولاً إلى وكيل يراقب رسوم بيانية الإنتاج ويقدم تقارير الحوادث الخاصة به. المصدر هو النشرة الإخبارية لـ Gergely Orosz بعنوان The Pragmatic Engineer، في مقال بعنوان "مصنع برامج OpenAI المعتمد على الوكلاء"، وقد انتشر الرسم البياني نفسه بسرعة على X.
تجاهلت معظم ردود الفعل تفصيلاً مهماً: عدة من تلك المربعات العشرة تصف الإعداد الهندسي الداخلي لـ OpenAI، وليس منتج Codex الذي يمكنك تثبيته اليوم. الخلط بين الاثنين هو الخطأ الأكثر شيوعاً في النقاش حول هذا الرسم البياني. يتناول هذا المقال كل مربع على حدة ويتوقف عند المرحلة الوحيدة التي يمكن للفرق الخارجية نسخها بالفعل: CI.
المراحل العشر، بالترتيب
يُقرأ الرسم البياني من اليسار إلى اليمين كحلقة: يحدد الإنسان هدفًا، ويكتب الوكيل الكود، وتتحقق بوابات آلية منه، ويستمر الوكيل في التكرار حتى تمر هذه البوابات. إليك التسلسل الكامل مع تحديد خط "داخلي فقط مقابل مشحون" لكل مرحلة.
| # | المرحلة | ماذا يحدث | داخلي فقط أم مشحون في Codex |
|---|---|---|---|
| 1 | مُنشئ البرمجيات | يقوم مهندس أو مدير منتج بتحديد النتيجة | خطوة بشرية، وليست برمجيات |
| 2 | Codex يكتب/يعدل الكود | يسحب السياق من المصدر، الوثائق، GitHub، Slack، Notion، المهارات الداخلية، وأنظمة البيانات مثل Databricks وDatadog | Codex المشحون يكتب الكود؛ الرسم البياني للسياق الداخلي (Slack، Notion، البيانات الداخلية) هو داخلي فقط |
| 3 | التكامل المستمر (CI): البناء + الاختبار | مسار عمل (pipeline) يتم إعادة بنائه لتحميل على نطاق الوكيل، بالإضافة إلى "Perf Harness" | مشحون (التكامل المستمر الخاص بك)؛ عمل OpenAI المحدد للتحجيم هو داخلي |
| 4 | مراجعة الكود بواسطة وكلاء | مراجعة متوازية من وكلاء متخصصين في البيانات، والبنية التحتية، والسحابة، والأمن، بالإضافة إلى تصنيف المخاطر | داخلي فقط |
| 5 | قرار منخفض المخاطر | التغييرات منخفضة المخاطر تستمر؛ التغييرات عالية المخاطر تحصل على مراجعة إضافية من مهندس بشري | داخلي فقط |
| 6 | نشر بواسطة وكلاء | وكيل "يراقب" التغيير في الإنتاج، بما في ذلك طرح ميزات جديدة، ويبني لوحات معلومات خاصة به | داخلي فقط |
| 7 | مراقبة الإنتاج | يراقب الوكيل الرسوم البيانية والإشارات والتنبيهات على مكدس المراقبة الداخلي لـ OpenAI | داخلي فقط |
| 8 | اكتشاف انقطاع -> Sevbot | يحقق في الحادث، يقترح حلولاً تخفيفية، يجيب على الأسئلة | داخلي فقط |
| 9 | مصنع الأداء (Perf Factory) | يصفي التنبيهات المكررة، يجد تراجعات في زمن الاستجابة، يقترح إصلاحات | داخلي فقط |
| 10 | العودة للحلقة | يصلح الوكيل المشكلات حتى تمر اختبارات التكامل المستمر والمراجعات، ثم يتلقى المُنشئ الإصلاحات المقترحة | يصف الحلقة الداخلية |
مرحلة واحدة بالضبط، وهي خطوة CI، بالإضافة إلى جزء من المرحلة الثانية، هي شيء يمكن لفريق خارجي أن يشير إليه ويقول "لدينا ذلك أيضًا". كل شيء بدءًا من المراجعة بواسطة الوكلاء وحتى Sevbot هو بناء داخلي لـ OpenAI.
هذا العمود "داخلي فقط" يمثل أيضًا مشكلة في تحديد المصادر. الأجزاء التي تحتفظ بها OpenAI خلف جدارها الناري، التنسيق، بوابة المراجعة، الموافقة البشرية، هي بالضبط الطبقة التي لا يملكها معظم الفرق. Sharkly هو مكان محايد للموفرين لبناء ذلك: يحدد المُنشئ النتيجة كـ Task (مهمة)، ويعينها لوكيل (Agent)، ويعمل الوكيل على جهاز كمبيوتر (Computer) باستخدام أي بيئة تشغيل (Runtime) لديك بالفعل، Claude Code أو Codex. "جاهز للإصدار" (Ready for Release) هي الحالة التي يجب أن يحركها الإنسان قبل أن يصل أي شيء إلى "تم" (Done)، لذلك تظل الموافقة مهمة الشخص، وليس مهمة مسار العمل (pipeline). Sharkly لا يحل محل Codex أو يكتب الكود بنفسه؛ بل يقوم بتشغيل بيئة التشغيل التي تدفع ثمنها بالفعل ويوفر للحلقة المحيطة مكانًا للعيش.
المرحلة 1-2: لا يزال الإنسان يحدد الهدف، ولا يزال Codex يكتب الكود
يحدد مُنشئ البرامج، أي مهندس أو مدير منتج، النتيجة التي يريدونها. ثم يقوم Codex بإجراء سلسلة من تغييرات الكود حتى يصل إلى هذا الهدف ويتحقق من أن النتيجة تعمل. حلقة التحقق هذه هي جزء من Codex الذي يُشحن اليوم: تطبيق سطح المكتب (Mac في فبراير 2026، Windows في مارس)، وتكامل ChatGPT Work اعتبارًا من يوليو 2026، والمكونات الإضافية والمهارات المستندة إلى الأدوار، وأمر /goal للمهام التي تستغرق فترة طويلة. إذا أردت معرفة آليات هذا الأمر، فقد غطينا /goal لتشغيل الوكلاء المستقلين بشكل منفصل.
ما لم يتم شحنه هو رسم بياني السياق الذي يغذي Codex داخليًا: تقريبًا كل نظام من أنظمة OpenAI، من سلاسل محادثات Slack إلى لوحات معلومات Databricks. يذكر مقال Orosz ذلك مباشرة: إن Codex الداخلي لـ OpenAI "أكثر تطورًا بكثير من نظيره الخارجي لأنه متصل بكل أنظمة OpenAI تقريبًا". هذه الفجوة بين Codex الداخلي والخارجي هي الأطروحة الحقيقية للمقال.
المرحلة 3: التكامل المستمر (CI) هو المكان الذي تُفرض فيه الحلقة بالفعل
هذه هي المرحلة التي تستحق التباطؤ عندها، لأنها المربع الوحيد في مسار العمل بأكمله الذي يمتلكه أي فريق بالفعل، وليس OpenAI فقط. يشير المقال إلى أن CI في OpenAI يتم إعادة بنائه لزيادة في الحمل حوالي 10 أضعاف على مدى ستة أشهر تقريبًا، لأن الوكلاء الآن يدفعون تغييرات أكبر بكثير عبر مسار العمل مما فعله البشر وحدهم على الإطلاق. يعمل "Perf Harness" بجانب ذلك لاكتشاف تراجعات الأداء قبل وصولها إلى المراجعة.
إليك الجزء الذي يتم تفويته: الوكيل الذي "يصلح المشكلات حتى تمر اختبارات CI والمراجعات" لا يكون موثوقًا به إلا بقدر ما يتحقق CI بالفعل. إذا كانت مجموعة اختباراتك تغطي منطق الوحدة ولكن ليس عقد API، يمكن للوكيل أن يتكرر لبناء أخضر لا يزال يشحن تغييرًا مُضرًا. رموز الحالة، شكل المخطط (schema shape)، سلوك المصادقة، وميزانيات وقت الاستجابة تحت الحمل هي بالضبط فئة الفحوصات التي تستثمر فيها معظم الفرق أقل مما ينبغي مقارنة باختبارات الوحدة. هذا هو المربع الذي يناسب Apidog: تشغيل سيناريوهات اختبار Apidog عبر Apidog CLI داخل خطوة CI الخاصة بك يمنح الوكيل بوابة أصعب ليُرضيها من "تم تجميع الكود". لقد كتبنا عن كيفية ربط ذلك في Apidog CLI داخل Codex. هذا هو الدور الوحيد الذي يلعبه Apidog في مسار العمل هذا. إنه ليس الوكيل، ولا يتدخل في النشر أو المراجعة أو الاستجابة للحوادث.
المرحلة 4-5: وكلاء المراجعة المتخصصون وقرار المخاطر
بعد اجتياز اختبارات CI، يقوم الإعداد الداخلي لـ OpenAI بتوجيه التغيير عبر مراجعة متوازية من وكلاء متخصصين في البيانات، والبنية التحتية، والسحابة، والأمن. يصف Orosz ذلك بأنه "المعادل لوجود خبير بشري في كل مجال ذي صلة من فرق البنية التحتية يراجع كل تغيير"، وهو معيار مراجعة أثقل مما يمكن لمعظم الفرق البشرية توفيره لكل طلب سحب. ميزة مراجعة الكود التي يوفرها Codex والتي يتم شحنها هي شيء مختلف وأخف من هؤلاء الوكلاء المتخصصين الداخليين؛ إذا كنت تقرر ما يمكن أن يفعله مراجع وكيل للأغراض العامة لـ "مكدسك" الخاص بك، فإن ملخصنا لأدوات مراجعة الكود بالذكاء الاصطناعي هو نقطة بداية عادلة، ومقالنا المصاحب حول مراجعة وكلاء OpenAI وتصميم بوابة المخاطر يتعمق أكثر في هذا المربع (أيها الزميل، تأكد من تفعيله قبل الربط).
ثم يحدد تصنيف المخاطر ما سيحدث بعد ذلك. يمكن للمناطق منخفضة المخاطر في قاعدة الكود أن تسمح للوكيل بالموافقة التلقائية على طلبات السحب الخاصة به، مما يزيل الموافقة البشرية تمامًا من الحلقة لهذا النوع من التغيير. تحصل التغييرات عالية المخاطر على المزيد من جولات مراجعة الذكاء الاصطناعي، أو مراجعة بشرية إلزامية، أو كليهما. لم تنشر OpenAI القاعدة الدقيقة لما يعتبر مخاطر منخفضة، ولن نخمن ذلك هنا. فكرة واحدة تعمم ما يتجاوز إعداد OpenAI المحدد: لا ينبغي أبدًا تصنيف التغيير الذي يكسر عقد API عام على أنه منخفض المخاطر، بغض النظر عن مدى صغر التغيير الظاهر. الأدوات التي تعتمد على المواصفات أولاً والتي تحتفظ بتعريف OpenAPI واختباراتك في نفس المكان تجعل هذا التمييز أسهل في التنفيذ تلقائيًا، نظرًا لأن اختلاف المخطط (schema diff) هو إشارة مخاطر أنظف بكثير من اختلاف عدد الأسطر.
المرحلة 6-8: النشر والمراقبة والاستجابة، دون تدخل بشري أولاً
إذا اجتاز التغيير المراجعة، يقوم وكيل داخلي "بمراقبته" في الإنتاج، بما في ذلك طرح الميزات، ويبني لوحات معلومات المراقبة الخاصة به لهذا التغيير المحدد. بمجرد أن يصبح التغيير مباشرًا، يراقب نفس الوكيل (أو وكيل ذو صلة) الرسوم البيانية والتنبيهات على مكدس المراقبة الداخلي لـ OpenAI. عندما يحدث خلل ما، يتولى Sevbot الأمر: يحقق في الحادث، ويقترح حلولًا تخفيفية، ويجيب على أسئلة المطورين في Slack. من المهم أن نكون دقيقين بشأن ما لا يفعله Sevbot. إنه يقترح؛ ولا ينفذ. لا يزال الإنسان هو من يصرح بالحل التخفيفي ويظل مسؤولاً عن الاستجابة عند الطلب. وكما يذكر المقال بوضوح، "واجب الاستجابة عند الطلب ليس شيئًا من الماضي". لا توجد أي من المراحل 6 إلى 8 في منتج Codex الذي يمكنك شراؤه.
المرحلة 9-10: تراجعات الأداء والعودة للحلقة
يعمل Perf Factory جنبًا إلى جنب مع مسار الحوادث. يقوم بفرز التنبيهات ولوحات المعلومات، ويصفّي الإشارات المكررة، ويكشف عن تراجعات زمن الاستجابة الحقيقية، ويقترح حلولًا، والتي تعود بعد ذلك إلى المُنشئ الأصلي. بالتعاون مع Sevbot، هذا هو رد OpenAI على إرهاق التنبيهات: فبدلاً من أن يقوم مهندس الاستجابة عند الطلب بفرز كل إشعار، يقوم الوكيل بالفلترة المسبقة والتشخيص المسبق أولاً. تُغلق الحلقة بالمرحلة 10: يستمر الوكيل في المراجعة حتى تمر اختبارات CI وكل طبقة مراجعة.
لماذا يهم الخط الفاصل بين الداخلي والخارجي لفريقك
إذا كنت تقيّم ما إذا كانت الهندسة المعتمدة على الوكلاء "على طريقة OpenAI" هي شيء يمكن لفريقك اعتماده هذا الربع، فإن الإجابة الصادقة هي: يمكنك اعتماد المراحل 1 إلى 3 اليوم، والمراحل 4 إلى 9 تصف اتجاهًا، وليست ميزة قابلة للشراء. هذا ليس انتقادًا لـ OpenAI؛ فالأدوات الداخلية بهذا الحجم تستغرق سنوات. مشروع مفتوح المصدر واحد، orchflows، هو محاولة علنية لتقريب هذه الحلقة باستخدام أمر /software-factory لـ Claude Code وCodex؛ ويذكر ملف README الخاص به صراحةً الهدف، حيث يجادل بأنك تحتاج فقط إلى مهارتين بدلاً من مكتبة منها. إنه مشروع مبكر وغير تابع، وليس إصدارًا من OpenAI، لذا تعامل معه كتطبيق مرجعي بدلاً من مصنع جاهز للاستخدام.
لقد تحرك الاعتماد داخل OpenAI نفسها بسرعة في الأجزاء التي لا تحتاج إلى سباكة داخلية مخصصة: ارتفع استخدام Codex في الفرق غير الهندسية من حوالي 0% إلى 90% في أربعة أشهر، من فبراير إلى مايو 2026. هذه إشارة أوضح من الرسم البياني لخط الأنابيب وحده، لأنها تقول إن الجزء السهل (وكيل يكتب الكود نحو هدف محدد) أصبح طبيعيًا بالفعل في OpenAI، بينما الجزء الصعب (النشر بواسطة الوكيل، المراجعة، والاستجابة للحوادث الموصولة بكل نظام داخلي) لا يزال مخصصًا.
ما يبقى بشرياً
المقال حريص على ما لا يتغير. لا يزال البناؤون يحددون النتائج. لا يزال البشر يوافقون على التغييرات عالية المخاطر ويصرحون بتخفيف الحوادث. لا يزال شخص ما يراجع ما فعله Sevbot بعد الحادث، ولا تزال دورات الاستجابة عند الطلب موجودة. يجسد السطر الذي يختتم به المقال التحول بشكل أفضل من أي إحصائية: "أصبحت القدرة على الحكم، وتحديد الأولويات، والذوق أكثر أهمية". هناك تحذيران يحافظان على هذا الأمر راسخًا أيضًا: لا تزال مراجعة متاجر تطبيقات الهاتف المحمول عنق زجاجة يدوي لا يمكن لأي وكيل تجاوزها، وتوسيع البنية التحتية هو صراع شهري، وليس مشكلة تم حلها.
إذا كنت تبني نسختك الخاصة من المراحل 1 إلى 3 بدلاً من انتظار مورد لشحن المراحل 4 إلى 9، فابدأ بالبوابة الموجودة بالفعل في مسار عملك: CI. مقالنا المصاحب حول بناء مصنع برمجيات خفيف الوزن حول Codex يوضح هذا البناء (أيها الزميل، تأكد من تفعيله قبل الربط)، ويحظى تصميم Sevbot/Perf Factory بمعاملة خاصة في مقالنا حول مصنع أداء OpenAI وSevbot (أيها الزميل، تأكد من تفعيله قبل الربط). الوكيل الذي يتكرر حتى تمر الاختبارات هو فكرة جيدة فقط إذا كانت الاختبارات التي يتكرر عليها تؤكد شيئًا بالفعل. يحافظ Apidog على اختبارات عقد API بجانب المواصفات حتى تظل تلك البوابة صادقة بينما يبدأ الوكلاء، وليس البشر فقط، في دفع التغييرات من خلالها.