Claude Code مقابل Codex: سبعة اختلافات بروتوكولية صادفناها بعد ربط المحركين في نفس النظام البعيد

إفصاح عن المصلحة: نطوّر PandaNpc — وهو نظام يتيح الوصول عن بُعد والمشاركة الجماعية لعوامل الترميز (agents) مثل Claude Code وCodex. ولأننا نحتاج إلى دعم هذه المحركات في نفس الصفحة ونفس سلسلة الرسائل، اضطررنا إلى مواءمة سلوكها البروتوكولي واحدًا تلو الآخر. يصف هذا المقال الاختلافات التي صادفناها فعلًا خلال هذه العملية، وليست مقارنة أداء (benchmark) — لم نجري اختبارات قياس مرجعية مضبوطة، لذا لن يرد في المقال أي أرقام عن السرعة أو معدل النجاح. نوضح الخطط اللاحقة في نهاية المقال.

ملاحظة: Codex في هذا المقال يقصد به أداة سطر الأوامر OpenAI Codex، وليس أي منتج آخر بنفس الاسم.

خلاصة في جملة واحدة: عند الاستخدام المحلي في الطرفية، يكون الفرق في التجربة بين الاثنين أقل بكثير مما تتوقع؛ أما عندما تريد ربطهما بنظامك الخاص (تحكم عن بُعد، مزامنة متعددة الأطراف، استعادة الجلسات، الموافقة على الأدوات)، فتتركّز الاختلافات كلها تقريبًا في طبقة البروتوكول — وهذه الاختلافات لم نتمكن من معرفتها مسبقًا من الوثائق، بل اكتشفناها بالاصطدام بها.

إذا كنت تبحث عن Codex vs Claude Code لتعرف "أيهما تختار"، فربما ليس هذا المقال المقارنة الشاملة التي تريدها — فهو لا يقارن من يكتب الكود بشكل أفضل، بل يجيب عن سؤال آخر أكثر تحديدًا: ما الذي ستواجهه عندما تريد التعامل معهما كخلفية (backend) قابلة للبرمجة.

لمن هذا المقال

• المطورون الذين يريدون دعم المحركين معًا، أو الانتقال من أحدهما إلى الآخر
• من يريدون بناء أدوات خارجية مثل التحكم عن بُعد / المزامنة متعددة الأطراف / مشاركة الجلسات
• من يريدون معرفة "ما الفرق الجوهري بين نموذجي الجلسات في هذين CLI"

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

أولًا: نقاط التشابه — لماذا "تبدو متشابهة"

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

الاختلاف ليس في طبقة القدرات، بل في طبقة البروتوكول. أي أن السلوك الذي تراه في الطرفية يمكن أن يكون متطابقًا تقريبًا، بينما تختلف الإطارات (frames) التي يرسلانها، وترتيب هذه الإطارات، وطريقة تنظيم الحقول. وهذا هو سبب صعوبة اكتشاف هذه الاختلافات مسبقًا: عند استخدامها على جهازك الخاص، لن تصطدم بها أبدًا.

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

#	البُعد	سلوك Claude Code	سلوك Codex	من سيتأثر بعدم المعالجة
1	معرّف رسالة المساعد	يحمل id مستقرًا	قد لا يحمل id	من يقوم بترسيخ الرسائل / المزامنة متعددة الأطراف
2	فحص بقاء الجلسة	بصيغة دفعة، مجموعة واحدة في كل مرة	يتوقع id جلسة واحدًا	من يقوم بعرض حالة الاتصال
3	ترتيب إعادة تشغيل التاريخ	مطابق للتسلسل الزمني الحقيقي	إطارات النشاط للخيوط الفرعية تُلحق كدفعة في النهاية	من يبني عرضًا للوكلاء الفرعيين / الخيوط المتعددة
4	بنية أمر استدعاء الأداة	كاملة	قد تكون مجزأة	من يبني UI الموافقة على الأدوات
5	اشتراك أحداث القناة	يتولى تنفيذ تبديل الجلسات	لا يمكنه تنفيذ التبديل في نفس الوقت	من يبني ترحيلًا (relay) متعدد المسارات
6	حصة الاتصالات المتزامنة	يتشارك نفس تجمّع العد مع Codex	مطابق للعمود السابق	من يفرض حدود الحصص
7	أداء التاريخ الطويل	خطي	قد يتدهور إلى غير خطي إذا لم يُعالَج جيدًا	من يطوّر للجوال

فيما يلي تفصيل كل بند، بترتيب «الأعراض → طريقة التحديد → طريقة الإصلاح».

أولًا: هل تحمل رسائل المساعد id مستقرًا — يحدد استراتيجية إزالة التكرار لديك

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

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

السبب الجذري: رسائل المساعد في Claude Code تحمل id مستقرًا، وعند وصول إعادة التشغيل أو الدفع الفوري يمكن إزالة التكرار مباشرة حسب id. أما رسائل المساعد في جانب Codex فلا يُضمن أن تحمل مثل هذا id، وعند استخدام نفس منطق «إزالة التكرار حسب id»، تُكتب نفس الرسالة كرسالتين مختلفتين.

طريقة الإصلاح: بالنسبة للرسائل التي لا تحمل id مستقرًا، استخدم طيًا يعتمد على «مرساة الجولة + المحتوى» — المرساة هي تجزئة (hash) لأقرب رسالة مستخدم تسبق هذا الرد.

⚠️ هناك مأزق هنا يستحق الذكر بشكل منفصل: نسختنا الأولى كانت طيًا بالنص المحض، وبعد الإطلاق، عند فحص البيانات التاريخية، اكتشفنا أنها حذفت بالخطأ 691 ردًا مكررًا عبر جولات مختلفة. السبب أن تكرار الردود القصيرة في Codex مرتفع جدًا (مثل "حسنًا." و"تم.")، ومجموعة إزالة التكرار على مستوى الجلسة — بمجرد تسجيل تجزئة جملة ما، فإن أي ظهور لنفس الجملة في أي جولة لاحقة ضمن نفس الجلسة سيُبتلع. تلك خسارة في المحتوى، وهي أخطر من التكرار. لا يمكن الاستغناء عن طبقة المرساة.

ثانيًا: فحص البقاء — أحدهما يتطلب عنصرًا واحدًا، والآخر يتطلب دفعة

الأعراض: الجلسة تعمل بوضوح، لكن الواجهة تعرض أنها غير متصلة.

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

السبب الجذري: للتحقق من «هل الجلسة لا تزال حية»، تختلف بنية الواجهة بين الطرفين. في جانب Claude Code استخدمنا الصيغة الدفعية، حيث تُرسل مجموعة من معرّفات الجلسات دفعة واحدة؛ بينما يتوقع جانب Codex معرّف جلسة واحدًا فقط.

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

ثالثًا: ترتيب إطارات إعادة تشغيل التاريخ مختلف — حالة الوكلاء الفرعيين تعلق

هذا هو الأكثر تعقيدًا في مسار تتبعه.

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

طريقة التحديد: «تحديث الصفحة لا يعيدها» هو المعيار الحاسم. إنه يوضح أن المشكلة ليست في الدفع الفوري، بل في إعادة تشغيل التاريخ نفسها — كل إعادة تشغيل تعيد كتابة الحالة بشكل خاطئ من جديد.

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

طريقة الإصلاح: أضف حارس الحالة النهائية إلى فرع كتابة الحالة — إذا كانت الحالة نهائية بالفعل (مكتملة/فاشلة/متوقفة)، فقط الإطارات الأحدث يمكنها تجاوزها. انتبه إلى أن معيار الحكم يجب أن يشترك في نفس تعيين الحالات مع الأماكن الأخرى، ولا تكتب تعيينًا منفصلًا، وإلا فسوف ينحرف فهم "ما هي الحالة النهائية" بين الموضعين.

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

رابعًا: بنية أوامر استدعاء الأدوات — قد تكون مجزأة

الأعراض: في بطاقات الأدوات بجلسات Codex، تظهر الأوامر كشظايا مثل 1,220p أو /pid=…/ {print}، وأحيانًا يُقطع السكربت بأكمله، بل وقد تظل بطاقات أدوات غير مكتملة معلقة بعد انتهاء الرد.

طريقة التحديد: انظر إلى البنية الفعلية لحقل الأمر في الإطارات الأصلية، وليس إلى نتيجة العرض. إذا حاولت الوصول إلى "الأمر الذي نفّذه المستخدم" عبر مسار الحقول الخاص بـ Claude Code، فستحصل على الأجزاء المقطوعة.

طريقة الإصلاح: اكتب طبقة إعادة تجميع للأوامر خاصة بـ Codex، لإعادة تركيب الشظايا في أمر كامل قبل تمريره إلى UI.

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

خامسًا: نطاق اشتراك أحداث القناة مختلف

الأعراض: مستخدمان يقطع كل منهما اتصال الآخر.

السبب الجذري: إذا اشترك مسارا الترحيل (relay) في أحداث نوع "تبديل الجلسة" ونفّذاها معًا، فسيقطع كل جانب ضحيةً واحدة، مما ينتج طردًا مزدوجًا. يجب أن يكون لحركة التبديل منفذ واحد فقط.

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

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

سادسًا: الحصة وعدّ الاتصالات مدمجان

الأعراض: يعتقد المستخدم أنه ما زال لديه حصة متبقية، بينما تكون قد استُنفدت فعليًا.

السبب الجذري: إذا كنت تفرض حدًا على عدد الاتصالات المتزامنة مثلنا، فانتبه إلى أن اتصالات المحركين تُحتسب في نفس تجمّع العد. عندما يفتح المستخدم جلسات Claude Code وCodex معًا، فإنهما يستهلكان نفس الحصة.

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

طريقة الإصلاح: حدد أولًا أي منهجية تريدها، ثم تأكد من أن الواجهة الأمامية والخلفية تستخدمان نفس المنهجية. خلط المنهجيتين أسوأ من اختيار منهجية خاطئة.

سابعًا: خصائص الأداء مختلفة مع نمو حجم التاريخ

الأعراض: تجمّد عند فتح جلسة ذات تاريخ طويل على الجوال.

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

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

إذن، أيهما تختار

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

الحالات التي يُفضَّل فيها اختيار Codex

1. فريقك موجود بالفعل داخل منظومة OpenAI — الحساب والحصة والفوترة في مكان واحد، مما يلغي مجموعة إضافية من إدارة الحسابات والبيانات الاعتمادية، وهذه الدرجة من التوفير لا ينبغي الاستهانة بها.
2. سير عملك مبني بالفعل حول نموذج الجلسات والمهام الخاص به — إعادة هيكلة الأدوات الخارجية من أجل الانتقال عادةً ما تكون غير مجدية اقتصاديًا، والاختلافات السبعة أعلاه هي نفسها تكلفة الانتقال بالمقلوب.

الحالات التي يُفضَّل فيها اختيار Claude Code

1. تريد بناء أدوات خارجية بنفسك — من تجربتنا في التكامل، فإن الرسائل ذات id المستقر تجعل الترسيخ والمزامنة متعددة الأطراف أسهل بكثير، والاختلافات الأول والثالث والرابع كلها أسهل معالجة في هذا الجانب.
2. تريد بناء تفاعلات من نوع الموافقة على الأدوات — بنية الأوامر كاملة، ولا تحتاج إلى لصق إضافي عند بناء UI الموافقة، وبالتالي لا توجد مخاطر "التوقيع الأعمى".

الحالة التي لا يُختار فيها أي منهما

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

إذا كنت ستنتقل: حجم التعديلات المقابلة للاختلافات السبعة

كثير ممن يبحثون عن هذين الاسمين، هم في الحقيقة يقيّمون "إذا كنت أستخدم أحدهما بالفعل، فكم سأدفع للانتقال إلى الآخر". فيما يلي تحويل الاختلافات السبعة أعلاه إلى تكلفة انتقال.

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

الانتقال من Claude Code إلى Codex، تتركّز التعديلات في هذه المواضع:

• إعادة كتابة منطق إزالة التكرار (البند الأول) — هذا الأكثر عرضة للاستهانة. الكود الأصلي لإزالة التكرار حسب id لا يمكن استخدامه مباشرة، والخطأ فيه لا يظهر كخطأ، بل يؤدي بصمت إلى رسائل زائدة أو رسائل مفقودة. إذا كان لديك ترسيخ للرسائل، فحدد مسبقًا ما هي المرساة التي ستستخدمها قبل الانتقال.
• تغيير صيغة الاستدعاء لفحص حالة الاتصال (البند الثاني) — حجم العمل صغير، لكن إغفاله يؤدي إلى "يعمل لكن يظهر غير متصل"، دون إلقاء أي استثناء.
• إعادة التحقق من كل الميزات التي تعتمد على التسلسل الزمني للتاريخ (البند الثالث) — عرض الوكلاء الفرعيين، وأشرطة التقدم، وأي منطق "يستنتج الحالة الحالية من التاريخ" كلها ضمن هذا البند.
• إضافة طبقة إعادة تجميع الأوامر إلى UI الموافقة على الأدوات (البند الرابع) — إذا كان منتجك يحتوي على ميزة الموافقة، فهذا البند لا يمكن الاستغناء عنه، وإلا فأنت تجبر المستخدم على التوقيع الأعمى.

الاتجاه المعاكس (من Codex إلى Claude Code) عادةً ما يكون أسهل: يمكن تبسيط إزالة التكرار إلى الاعتماد على id مرة أخرى، ولا تحتاج بنية الأوامر إلى طبقة إعادة تجميع. لكن انتبه لا تحذف طبقة التوافق المكتوبة لـ Codex مباشرة — إذا كنت تريد الاحتفاظ بالقدرة على الدعم المتزامن، فهذه الطبقة أصل وليست التزامًا.

ما يجب إعادة التحقق منه في كلا الاتجاهين: منهجية الحصة (البند السادس) وأداء التاريخ الطويل (البند السابع). هذان الأمران علاقتهما بالمحرك أقل مباشرة، لكنهما الأكثر عرضة للنسيان عند إعادة الاختبار بعد تغيير المحرك.

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

منهجنا: لا نختار — بل نربط كلاهما

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

قائمة تحقق للتحقق عند ربط محرك جديد

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

1. معرّف الرسالة — هل تحمل رسائل المساعد id مستقرًا؟ إذا لم يكن، فما هي مرساة إزالة التكرار لديك؟
2. بقاء الجلسة — هل تقبل واجهة فحص البقاء عنصرًا واحدًا أم دفعة؟ هل إرسال البنية الخاطئة يُظهر خطأ أم يعطي إجابة خاطئة بصمت؟
3. ترتيب إعادة تشغيل التاريخ — هل ترتيب الإطارات المعاد تشغيلها مطابق للتسلسل الزمني الحقيقي؟ خاصة عند وجود خيوط فرعية.
4. بنية استدعاء الأداة — هل حقل الأمر يُستخرج كاملًا؟ هل يمكن أن يتجزأ؟
5. نطاق اشتراك الأحداث — ما الأحداث التي يجب أن يكون لها منفذ واحد؟ ماذا يحدث عند التنفيذ المكرر؟
6. منهجية الحصة — هل العد مقسوم حسب المحرك أم مدمج؟ هل الواجهة الأمامية والخلفية متطابقتان؟
7. أداء التاريخ الطويل — عندما يتضاعف عدد الرسائل عشر مرات، هل يزيد زمن المعالجة خطيًا أم أسرع؟

لكل بند، نقترح التحقق أولًا على كمية صغيرة من البيانات، ثم على تاريخ كبير — البندان 3 و7 لا يظهران إلا بعد أن تكبر كمية البيانات.

الرجوع العكسي حسب الأعراض: أي بند اصطدمت به؟

إذا وقعت بالفعل في مشكلة، فإن الاستنتاج العكسي من الأعراض عادةً ما يكون أسرع من قراءة الوثائق كاملة:

العرض الذي تراه	الأرجح أنه	طريقة تحديد الخطوة الواحدة
تزيد ردود المساعد بعد الخروج والدخول مجددًا	البند 1 (معرّف الرسالة)	انظر مباشرة إلى عدد السجلات في ذاكرة التخزين المؤقت للخادم — تعرف فورًا إن كانت المشكلة في طبقة البيانات أم العرض
الجلسة تعمل لكن تظهر غير متصلة	البند 2 (فحص البقاء)	افحص ما إذا كان طلب البقاء يُرسل كعنصر واحد أم كبنية دفعة
حالة الوكلاء الفرعيين عالقة في "قيد التشغيل"، وتحديث الصفحة لا يعيدها	البند 3 (ترتيب إعادة التشغيل)	"تحديث الصفحة لا يعيدها" هو المعيار: المشكلة في إعادة التشغيل وليست في الدفع الفوري
الأوامر في بطاقات الأدوات مقطوعة / بطاقات أدوات معلقة بعد انتهاء الرد	البند 4 (بنية الأمر)	انظر إلى بنية حقل الأمر في الإطارات الأصلية، وليس إلى نتيجة العرض
مستخدمان يقطع كل منهما اتصال الآخر	البند 5 (نطاق الاشتراك)	تحقق مما إذا كان هناك منفذان يعالجان أحداث التبديل في نفس الوقت
الواجهة الأمامية تعرض حصة متبقية بينما الخلفية قد استنفدتها	البند 6 (منهجية الحصة)	تأكد مما إذا كان العد في الواجهة الأمامية والخلفية مقسومًا حسب المحرك أم مدمجًا
تجمّد عند فتح جلسة طويلة على الجوال	البند 7 (التاريخ الطويل)	قارن زمن المعالجة مع جلسات تضاعف عدد رسائلها، ولاحظ ما إذا كان غير خطي

معيار عام: إذا كان العرض يتكرر بثبات مع كل تحديث للصفحة، فالمشكلة غالبًا في إعادة تشغيل التاريخ أو طبقة البيانات؛ إذا كان يظهر عشوائيًا فقط أثناء التفاعل الفوري، فابحث إذن في مسار الدفع. هذا المعيار وفّر علينا الكثير من الوقت — البندان 1 و3 أُسيء تشخيصهما في البداية كمشكلتين من جهة العميل.

الأسئلة الشائعة (FAQ)

هل Codex CLI و OpenAI Codex هما الشيء نفسه؟ Codex في هذا المقال يقصد به أداة الترميز لسطر الأوامر من OpenAI. توجد منتجات أخرى في السوق تسمى أيضًا Codex (بما في ذلك بعض برامج المجال القانوني والامتثال)، ومن السهل الخلط بينها عند البحث، لذا إضافة "CLI" أو "OpenAI" يجعل البحث أكثر دقة.

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

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

الخطوات اللاحقة

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

---

يستند هذا المقال إلى خبرتنا الهندسية الفعلية في ربط Claude Code وOpenAI Codex بنفس نظام الوصول عن بُعد، وآخر تحديث في 2026-08-26. كلا المحركين في تحديث مستمر، وللحصول على السلوكيات المحددة يرجى الرجوع إلى الوثائق الرسمية لكل منهما.