ربط نماذج الذكاء الاصطناعي المحلية مثل DeepSeek
📚 تنقل السلسلة: المقال السابق 04 · الاشتراك والفوترة أوضح تفاصيل الفوترة لـ Codex — أيهما أفضل الاشتراك أم الدفع حسب الاستهلاك. هذا المقال يستكمل مسار «توفير التكاليف» ويناقش مسارًا بديلاً وأكثر مرونة: استبدال النموذج الأساسي لـ Codex بنماذج محلية مثل DeepSeek.
⚠️ تنبيه هام ومسبق (ميزة تجريبية وقابلة للتغيير): يعد Codex منتجًا تابعًا لـ OpenAI، ولم تكن الوثائق الرسمية تخطط لدعم ربطه بـ DeepSeek إطلاقًا. وربط Codex بنماذج الطرف الثالث هو مسار ابتكره مجتمع المطورين بالاعتماد على خيار رسمي مدمج — وهو تخصيص مزودي النماذج (
model_providers). وتعتمد جاهزية واستقرار هذا المسار بالكامل على نوع بروتوكول واجهة التطبيق المدعوم من الطرف الثالث، وهذا هو موضع المشاكل الشائعة (وسنفصل ذلك في القسم 03). وتعتمد تفاصيل خيارات الإعدادات والسلوكيات الافتراضية المذكورة في هذا المقال على الوثائق الرسمية؛ بينما تعتمد تفاصيل DeepSeek على التجارب العملية والحلول المجتمعية، وقد تتغير مسارات الواجهات وأسماء النماذج والبروتوكولات، والفيصل هو الوثائق الرسمية لـ DeepSeek و Codex.
أيها الأصدقاء، دعوني أشارككم حوارًا حقيقيًا دار بيني وبين أحد زملائي مؤخرًا.
زميلي: «ألم تقم بربط Claude Code بـ DeepSeek وتوفير الكثير من التكاليف؟ دعنا نطبق نفس الأمر مع Codex إذن.» أنا: «كنت أظن أن الأمر متطابق وسهل... ولكنني قضيت ساعتين متتاليتين مع إعدادات صحيحة بالكامل، وكل طلب أرسله ينتهي بخطأ 400 مباشرة.» زميلي: «ماذا؟ أليس الأمر مجرد تعديل لـ base_url فقط؟» أنا: «لا يعمل Codex بنفس أسلوب Claude Code. يبدوان متشابهين ظاهريًا، ولكنهما يختلفان جوهريًا في الخلفية.»
وبكل صراحة، هذا المقال هو الأكثر أهمية لتنبيهك وتوفير وقتك في سلسلة Codex بالكامل. فعند البحث على الويب عن «ربط Codex بـ DeepSeek»، ستجد الكثير من الشروحات، ولكن غالبها يغفل توضيح نقطة جوهرية: يختلف الأساس التقني تمامًا لربط Codex بنماذج الطرف الثالث مقارنة بـ Claude Code، ومحاكاة تجربة Claude Code ستنتهي غالبًا بالتعطل بسبب البروتوكولات. وسنكشف لك تفاصيل هذه المشكلة بالكامل هنا.
بعد قراءة هذا المقال، ستحصل على:
- توضيح مبسط في جملة واحدة للفارق الجوهري لربط نماذج الطرف الثالث بين Codex و Claude Code (ليوفر عليك ساعات من البحث).
- جدول مقارنة لمساعدتك في اتخاذ القرار حول «هل يستحق Codex ربطه بنماذج الطرف الثالث أم لا».
- مقارنة بين مساري الربط (تعديل ملف
config.tomlيدويًا، أو استخدام أدوات الوكيل الخارجية) وتحديد الأنسب لك. - نموذج جاهز لتهيئة إعدادات
model_providersوطرق التحقق وحل المشاكل الشائعة.
01 أولاً: تغيير النموذج في Codex يختلف تمامًا عن Claude Code
الخلاصة أولاً وهي الأهم في المقال: يعتمد تغيير النموذج في Claude Code على تعديل متغيرات البيئة، بينما يعتمد في Codex على تعديل «مزود النموذج» في ملف الإعدادات؛ والأهم من ذلك، يفرض Codex شروطًا صارمة على بروتوكولات واجهات الطرف الثالث، ولا يقبل أي واجهة متوافقة عشوائيًا.
دعنا نوضح التفاصيل خطوة بخطوة:
أداة Codex المثبتة لديك هي تطبيق عميل يعمل داخل الطرفية — يقوم بقراءة الأكواد، استدعاء الأدوات، وإدارة السياق، ولكنه لا يفكر ذاتيًا، ويتعين عليه إرسال المتطلبات لنموذج ضخم في كل خطوة لمعالجتها. والنموذج الافتراضي هو GPT التابع لـ OpenAI (يوصى حاليًا بـ gpt-5.5؛ راجع وثائق النماذج لـ Codex).
ويعني «ربط الطرف الثالث» تغيير وجهة إرسال هذه الطلبات من خوادم OpenAI لخوادم شركات أخرى. وتوفر الوثائق الرسمية خيارًا مدمجًا لذلك قائلة:
«يمكنك توجيه Codex لأي نموذج أو مزود يدعم واجهات [Chat Completions] أو [Responses API]، ليتوافق مع سيناريوهات عملك الخاصة.»（Codex 官方《Models》文档）
تشبيه: مقابس الكهرباء. يشبه Claude Code الشاحن متعدد المنافذ، ويكفي توفر واجهة «متوافقة مع بروتوكول Anthropic» ليعمل معها مباشرة. بينما يشبه Codex جهازًا كهربائيًا يبحث عن مقبس محدد — فهو لا يقبل سوى مقبسي OpenAI المعتمدين (Chat Completions و Responses API). وتوفر نماذج مثل DeepSeek واجهات «متوافقة مع OpenAI»، وهو ما يعادل مقبس OpenAI، لذا يمكن ربطهما نظريًا. ولكن هناك مشكلة خفية:
تنص وثائق Codex صراحة على — إلغاء دعم واجهة Chat Completions وتخطيطها لحذفها في الإصدارات القادمة. وهذا يعني أن Codex يعتمد بالكامل على بروتوكول Responses API الحديث نسبيًا والخاص بـ OpenAI، بينما لم تقم غالبية منصات نماذج الطرف الثالث بدعم هذا البروتوكول بالكامل بعد.
هذا هو السبب الفعلي لضياع ساعتين من وقتي في البداية: ظننت أن توفر «توافق DeepSeek مع OpenAI» كافٍ لتشغيله مباشرة، ليتم حظري بسبب عدم توافق البروتوكولات.
💡 الخلاصة في جملة واحدة: تغيير نموذج Claude Code يعتمد على متغيرات البيئة وبروتوكول Anthropic؛ وتغيير نموذج Codex يعتمد على تعديل مزود النموذج في ملف
config.tomlوبروتوكول OpenAI (وبالتحديد Responses API) — وتجنب محاكاة تجربة Claude Code مع Codex.
02 هل يستحق Codex ربطه بنماذج الطرف الثالث؟
من الشروحات المتاحة، يبدو أن توفر خيارات التوفير المالي مغري للغاية. ولكن وبكل صراحة، ربط نماذج الطرف الثالث بـ Codex لا يستحق العناء مقارنة بـ Claude Code. وهذا حكم مبني على التجارب العملية.
والأسباب ثلاثة:
- نسبة نجاح الربط في Codex أقل مقارنة بـ Claude Code — لاعتماده على بروتوكولات محددة قد تتعارض مع الطرف الثالث.
- تتميز نماذج GPT-5.5 المضمنة في Codex بقدرات برمجية فائقة، خاصة للمهام المعقدة وإعادة الهيكلة الشاملة، وقد لا تتمكن النماذج المحلية من تقديم نفس جودة العمل البرمجي.
- تشمله اشتراكات ChatGPT (Plus / Pro) حصص استخدام Codex بالفعل (وفقًا لحسابات المقال 04). فإذا كنت مشتركًا في الباقات بالفعل، فإن الدفع لمزود خارجي يمثل هدرًا للمال وتكرارًا للدفع.
| البعد | نماذج GPT الرسمية (الافتراضية لـ Codex) | نماذج الطرف الثالث (مثل DeepSeek) |
|---|---|---|
| التكلفة | مرتفعة عند الاستخدام الكثيف لمفتاح API key | ✅ منخفضة واقتصادية للغاية |
| الاتصال المحلي | يتطلب استخدام VPN في بعض المناطق | ✅ اتصال محلي مباشر وسريع دون قيود |
| سهولة الربط | جاهزة بمجرد تسجيل الدخول | ⚠️ قد تتعارض البروتوكولات ولا ينجح الربط |
| القدرة البرمجية والوكالة | ✅ ممتازة ومستقرة للمهام الطويلة والمعقدة | كافية للمهام اليومية وتتعطل في المسارات المركبة |
| الدعم الرسمي | ✅ مدعومة رسميًا بالكامل | ❌ ميزة تجريبية ولا تتوفر لها حلول رسمية |
| استقرار الإعدادات | مستقرة وتتبع التحديثات الرسمية | ⚠️ تتطلب إعادة التهيئة عند تعديل الأسماء أو الواجهات |
هل اتضحت الفكرة؟ خلافًا لخلاصة مقال Claude Code التي اعتبرت الطرف الثالث خيارًا أساسيًا لتوفير المال — يواجه Codex مشكلة عدم استقرار وتوافق بروتوكولات واجهات الطرف الثالث، مما يقلل من فاعلية هذا الخيار.
من يناسبه تجربة هذا الخيار إذن؟ إليك توصياتنا:
- ✅ يمكنك تجربتها: المطورون الذين يستهلكون حصصًا ضخمة ويرغبون في تقليل الفواتير المرتفعة لمفتاح API key، مع حصر المهام في التعديلات البرمجية اليومية المعتادة؛ أو لمن يواجه مشاكل حظر الاتصال بخدمات OpenAI؛ أو لمن يفضل التعلم وتجربة الربط والتهيئة البرمجية.
- ❌ تجنبها: من يمتلك اشتراكًا صالحًا في باقات ChatGPT بالفعل؛ من يركز عمله على المهام المعقدة وتصميم المعماريات البرمجية وحل المشاكل التقنية الصعبة؛ ومن يفضل سهولة العمل المباشر وتفادي عناء إعداد وتعديل ملفات التهيئة البرمجية.
خلاصتي الشخصية هي: أنا أعتمد على DeepSeek كنموذج أساسي لـ Claude Code للمهام اليومية السريعة، بينما ألتزم بنماذج OpenAI الرسمية لـ Codex. فالأمر لا يرجع لضعف DeepSeek، بل يرجع لعدم استقرار مسار الربط في Codex، ويفضل استغلال الوقت في رفع كفاءة الاستخدام مع النماذج الرسمية.
💡 الخلاصة في جملة واحدة: يواجه ربط الطرف الثالث بـ Codex مخاطر تعارض البروتوكولات، وتجنب تجربته إذا كنت مشتركًا في الباقات، أو تعمل على مهام معقدة، أو تفضل سهولة العمل المباشر؛ واعتبره خيارًا تجريبيًا عند رغبتك في اختباره.
03 مسارا الربط: التعديل اليدوي أم أدوات الوكيل
إذا قررت البدء بالتجربة، فحدد أولاً المسار المناسب للربط لتفادي ضياع الوقت:
يوضح المخطط مسار العمل: يتطابق مسارا الربط في النتيجة، ولكن كلاهما يتعين عليه تجاوز عقبة «البروتوكول» لضمان استقرار العمل.
路线一：手改 config.toml（官方留的口子）
تُخزن جميع إعدادات Codex في ملف موحد تحت مسار: ~/.codex/config.toml (ملف التكوين الخاص بالمستخدم؛ راجع مرجع الإعدادات الرسمي). ويدعم الخيار المدمج إضافة تعريف لـ «مزودي النماذج» المخصصين.
تشبيه: إضافة جهة اتصال جديدة في الهاتف. تحتوي قائمة جهات الاتصال افتراضيًا على رقم OpenAI فقط، وللاتصال بـ DeepSeek، يتعين عليك إضافة جهة اتصال جديدة: تضم الاسم، العنوان المخصص (base_url)، ومفتاح المرور للتوثيق (جلب مفتاح API key من متغير البيئة المحدد). بعد الحفظ، توجه Codex للاتصال بجهة الاتصال الجديدة هذه.
وتشمل الإعدادات الأساسية ما يلي (تتوفر بالتفصيل في مرجع الإعدادات؛ وتتبع المتغيرات الأربعة الأولى قسم model_providers الفرعي، ويتبع المتغيران الأخيران المستوى الرئيسي للملف):
| خيار الإعداد | الوصف والمفهوم |
|---|---|
model_providers.<id>.name | الاسم المعروض لمزود النموذج المخصص |
model_providers.<id>.base_url | عنوان واجهة التطبيق (API base URL) للمزود |
model_providers.<id>.env_key | متغير البيئة الذي يتم جلب مفتاح API key منه |
model_providers.<id>.wire_api | نوع البروتوكول المستخدم，ولا يدعم النظام سوى قيمة responses كخيار وحيد وافتراضي |
model_provider (رئيسي) | تحديد اسم المزود النشط حاليًا، والافتراضي هو openai |
model (رئيسي) | تحديد اسم النموذج المستخدم حاليًا |
تحقق من خيار wire_api — تنص الوثائق الرسمية بوضوح: أن قيمة responses هي الخيار الوحيد المدعوم (responses is the only supported value). وهذه هي العقبة الكبرى للمسار الأول: فإذا كانت واجهة الطرف الثالث تدعم بروتوكول Chat Completions فقط وتفتقر لدعم Responses API，那这条官方路线可能直接走不通。
⚠️ توفر DeepSeek واجهة «متوافقة مع OpenAI» بالاعتماد على بروتوكول Chat Completions بالدرجة الأولى. ويعتمد مدى توافقها مع بروتوكول
responsesلـ Codex على التحديثات البرمجية الحالية لكلا الطرفين، ويتعين عليك التحقق منها بنفسك. وفي حال فشل الربط فهذا هو السلوك المتوقع للتعارض التقني.
路线二：装个第三方代理工具（社区方案）
لحل مشكلة توافق البروتوكولات، ابتكر مجتمع المطورين حلاً: تشغيل خادم وكيل محلي (local proxy) على جهازك يتولى «ترجمة البروتوكولات» — فيرسل Codex الطلبات للوكيل المحلي بصيغة OpenAI، ويقوم الوكيل بترجمتها وإعادة إرسالها لـ DeepSeek، ثم يترجم الإجابات الواردة ويعيد توجيهها لـ Codex. ويوفر هذا الخداع إمكانية تشغيل الأداة دون تعارض.
وتعد أداة CC Switch (أداة رسومية مفتوحة المصدر تدعم مختلف الأنظمة؛ مستودع GitHub في github.com/farion1231/cc-switch) أحد أبرز الحلول في هذا المسار: حيث تنشئ وكيلاً محليًا لتوجيه الطلبات، وتوفر إعدادات جاهزة لربط نماذج مثل DeepSeek لتفادي التهيئة اليدوية للمسارات والبروتوكولات.
بعد تثبيت أداة CC Switch وتشغيلها، اضغط على زر «Add Provider» أو رمز «+」 لفتح صفحة إعدادات مزود الخدمة:
توضح الصورة واجهة ربط مزودي الخدمة. حدد الأداة التي ترغب في ربطها من القائمة اليسرى (اختر Codex)، وستظهر إعدادات مزود الخدمة «Provider» المقابلة على اليمين — حدد النموذج المستهدف (مثل DeepSeek)، وأدخل مفتاح API key الخاص بك، واحفظ الإعدادات ليقوم التطبيق بالترجمة وتوجيه العمليات تلقائيًا.
توضح الصورة قائمة النماذج والواجهات المدعومة مسبقًا — مثل DeepSeek و OpenRouter وغيرها، وتكتفي باختيار الاسم وإدخال مفتاح التوثيق دون الحصول على كتابة عناوين الواجهات والبروتوكولات يدويًا.
تشبيه: المترجم الفوري. يتحدث Codex باللغة الإنجليزية فقط (بروتوكول OpenAI)، ويتحدث DeepSeek باللغة الصينية فقط. الخيار الأول يعتمد على تعلم الطرف الآخر للإنجليزية (دعم المنصة لبروتوكول Responses API)؛ والخيار الثاني يعتمد على استئجار مترجم (أداة الوكيل) يقف في المنتصف لترجمة وتمرير الحديث بين الطرفين. ووجود مترجم خبير يضمن دقة وسلاسة العمل.
| مقارنة الجوانب | المسار الأول: التعديل اليدوي لـ config.toml | المسار الثاني: أدوات الوكيل (مثل CC Switch) |
|---|---|---|
| الرسمية | ✅ يعتمد على خيارات التكوين الرسمية المدمجة | ❌ أداة خارجية من مجتمع المطورين |
| توافق البروتوكول | ⚠️ يعتمد على دعم المنصة لبروتوكول responses | ✅ يتولى الوكيل ترجمة البروتوكولات لضمان النجاح |
| سهولة التهيئة | تتطلب كتابة نصوص TOML يدوية وحظر الأخطاء | واجهة رسومية بسيطة تضمن الجاهزية |
| الشفافية | جميع التهيئة واضحة ومقروءة أمامك | ميزة مغلقة (صندوق أسود) يصعب فحص أخطائها |
| التنقل بين النماذج | يتطلب تعديل ملف الإعدادات في كل مرة | التبديل المباشر بضغطة زر بين النماذج |
| الفئة المستهدفة | من يفضل فهم التفاصيل البرمجية ومعالجة التهيئة | من يرغب في تشغيل سريع للمنصات وتفادي عناء كتابة النصوص |
توصيتي: لفهم آلية تهيئة Codex مع الطرف الثالث بعمق، اختر المسار الأول، فالتجربة تطلعك على المفاهيم الهامة؛ وعند الرغبة في التشغيل المباشر والسرعة، اختر المسار الثاني ودع الأداة تتولى إعداد البروتوكولات.
💡 الخلاصة في جملة واحدة: المسار الأول يعتمد على التهيئة المدمجة (شفاف ولكنه يخضع للتوافق التقني)، والمسار الثاني يعتمد على أدوات مجتمعية (واجهة مبسطة ونسبة نجاح أعلى) — واختر أدوات الوكيل للسرعة، والتهيئة اليدوية للتعلم وعمق الفهم。
04 تمرين عملي: تهيئة ملف config.toml يدويًا
يوضح هذا القسم الهيكل الأساسي للتهيئة البرمجية للمسار الأول. وتمت كتابته كـ «هيكل أساسي» لتفادي مشاكل توافق البروتوكولات — فصيغة TOML المذكورة صحيحة ومعتمدة رسمياً؛ ولكن نجاح اتصالها بـ DeepSeek يتطلب التحقق العملي منك。
الفروق بين أنظمة التشغيل للمسار: يقع الملف تحت مسار ~/.codex/ على أنظمة Mac / Linux، وتحت مسار C:\Users\Username\.codex\ على نظام Windows (حيث يمثل ~ دليل المستخدم الرئيسي). وقم بإنشاء الملف عند عدم توفره.
第一步：拿一把 DeepSeek API Key
- افتح منصة DeepSeek للمطورين وسجل الدخول لحسابك.
- أنشئ مفتاح API Key جديد، وانسخه واحفظه في مكان آمن (يظهر بصيغة
sk-xxxxxxxx).
🔑 يعادل مفتاح API Key كلمة المرور لحسابك المالي. تجنب رفعه لـ Git أو كتابته صراحة داخل ملف الإعدادات. وسنقوم بحفظه في متغير البيئة لضمان سرية البيانات وحمايتها.
第二步：把 Key 放进环境变量
سنقوم بحفظ المفتاح في متغير بيئة (يمكنك اختيار أي اسم، وسنسميه هنا DEEPSEEK_API_KEY)، لنشير للاسم فقط داخل ملف الإعدادات دون كتابة المفتاح صراحة.
أنظمة Mac / Linux:
export DEEPSEEK_API_KEY=<مفتاح DeepSeek API Key الخاص بك>Windows（PowerShell）：
$env:DEEPSEEK_API_KEY="<مفتاح DeepSeek API Key الخاص بك>"تشغيل هذا الأمر يفعله لـ النافذة الحالية للطرفية فقط، وسيزول بإغلاقها. ولتفعيله بشكل دائم، أضف السطر لملف ~/.zshrc على Mac، وملف ~/.bashrc على Linux مع تشغيل أمر source للتحديث؛ وعلى نظام Windows أضفه كمتغير بيئة للمستخدم من إعدادات النظام.
第三步：在 config.toml 里建一个提供商
افتح ملف ~/.codex/config.toml للتحرير، وأضف النص التالي (تلتزم الأسطر بالصيغة الرسمية المعتمدة):
# المستوى الرئيسي: توجيه Codex لاستخدام المزود والنموذج المخصصين
model_provider = "deepseek"
model = "<اسم نموذج DeepSeek المستهدف، راجع المستندات للتأكيد>"
# تعريف تفاصيل مزود الخدمة المخصص باسم deepseek
[model_providers.deepseek]
name = "DeepSeek"
base_url = "<عنوان واجهة DeepSeek المستهدفة، راجع المستندات للتأكيد>"
env_key = "DEEPSEEK_API_KEY" # الإشارة لاسم متغير البيئة الذي تم إعداده في الخطوة الثانية
# خيار wire_api يترك فارغًا ليعتمد على القيمة الافتراضية المعتمدة responsesنوضح الأسطر لتفادي الخلط:
model_provider = "deepseek"—— توجيه الأداة لعدم استخدام المزود الافتراضيopenaiوالاعتماد على المزود المعرف أدناهdeepseek.model = "..."—— اسم النموذج المحدد. ويرجى فحص أسماء النماذج من مستندات DeepSeek الرسمية لتفادي كتابة أسماء قديمة طالها التعديل.[model_providers.deepseek]—— قسم تعريف جهة اتصال جديدة، ويمثلdeepseekالمعرف المخصص له ويجب أن يطابق القيمة المحددة أعلاه فيmodel_provider.base_url—— عنوان واجهة التطبيق لـ DeepSeek، ويتم جلبه من الوثائق الرسمية للمنصة.env_key = "DEEPSEEK_API_KEY"—— يوجه Codex لجلب مفتاح التوثيق من متغير البيئة الذي قمنا بتهيئته في الخطوة الثانية.
⚠️ تم كتابة قيم
modelوbase_urlكعلامات مكانية (placeholders) لسببين: الأول يرجع لتغير العناوين والأسماء من DeepSeek باستمرار؛ والثاني — للتأكيد مجددًا — على أن نجاح ربط التهيئة يعتمد بالكامل على توافق بروتوكولresponses، ويتعين عليك التحقق منه عمليًا.
تنبيه هام: معرفات مزودي الخدمة المدمجة مثل (
openaiوollamaوlmstudio) هي معرفات محجوزة للنظام ولا يمكن تعديلها أو استخدامها كمعرفات مخصصة (راجع مرجع الإعدادات)، لذا يرجى تجنب استخدامها كاسم للمعرف المخصص。
💡 الخلاصة في جملة واحدة: تعتمد التهيئة اليدوية على = تهيئة متغير البيئة لحفظ المفتاح + تعريف قسم المزود المخصص
model_providersفي ملفconfig.toml+ وتوجيه متغيرات المستويات الرئيسيةmodel_providerوmodelله؛ والصيغة ثابتة ويحكمها توافق البروتوكولات التقنية.
05 التحقق: تأكيد نجاح الربط
بعد حفظ التعديلات، تحقق من نجاح الربط وتأكيد تشغيل النموذج لتفادي هدر الوقت والمجهود. وينقسم التحقق لخطوتين:
看一眼：当前用的是哪个模型
شغل Codex واكتب الأمر المائل /model داخل الجلسة لتعديل النموذج المستخدم (راجع وثائق النماذج لـ Codex). وتحقق من قراءة الأداة للنموذج المخصص المعرف وتجاوزها لنموذج GPT الافتراضي.
codex进去之后敲：
/modelكما يمكنك تحديد اسم النموذج مباشرة عند بدء تشغيل الأداة باستخدام المعامل
-m، مثل:codex -m <اسم النموذج>.
真一刀：发个最小请求试水
التحقق من اسم النموذج وحده غير كافٍ، والفيصل هو إرسال توجيه مبسط ومراجعة ردود النموذج للتأكد من استقرار العمل。وجه له هذا التوجيه المعتاد:
مرحبًا، أرسل ردًا مبسطًا في جملة واحدة لتأكيد عملك بشكل سليم.وستواجه أحد الاحتمالات الثلاثة التالية:
| السلوك والنتيجة المعروضة | السبب الفعلي | كيفية التصرف |
|---|---|---|
| استجابة واضحة وسليمة باللغة العربية | ✅ نجاح الاتصال والربط | تهانينا، الأداة جاهزة للعمل |
| ظهور خطأ 401 / فشل التوثيق | خطأ في مفتاح API key أو عدم تهيئة متغير البيئة | تحقق من اسم env_key وأعد كتابة متغير البيئة وشغل الطرفية مجددًا |
| ظهور خطأ 400 / خطأ في الصيغة أو البروتوكول | تعارض في البروتوكول (Responses API) | تعذر تشغيل هذا المزود في المسار اليدوي، ويرجى استخدام خيار أدوات الوكيل (المسار الثاني) |
| تنبيه يفيد بعدم توفر النموذج | خطأ في كتابة اسم النموذج أو قيام المنصة بتعديل الأسماء | تحقق من اسم النموذج المحدث من مستندات DeepSeek الرسمية |
التركيز على خطأ 400 / خطأ البروتوكول — فعند مواجهته، لا تقلق وتظن أنك أخطأت في الإعدادات. فهذا يؤكد تعارض بروتوكول responses لـ Codex مع الواجهة الخارجية المستخدمة. واجهت هذا الخلل شخصيًا لساعتين في البداية وتأكدت من عدم وجود خطأ في كتابة الإعدادات بل كان المشكل في تعارض البروتوكولات.
والتصرف السليم عند مواجهة هذا التعارض هو: الانتقال لاستخدام أدوات الوكيل (المسار الثاني لتتولى ترجمة البروتوكولات)، أو تأكيد تعارض المنصة حاليًا مع Codex وتفادي هدر الوقت في محاولات تعديل TOML دون جدوى。
💡 الخلاصة في جملة واحدة: تحقق من اسم النموذج بـ
/modelأولاً، ثم أرسل توجيهًا مبسطًا لمراجعة الاستجابة؛ وأخطاء 401 ترجع لـ Key، وأخطاء 400 ترجع للبروتوكولات؛ وعند تعارض البروتوكول انتقل لاستخدام أدوات الوكيل وتجنب التعديلات اليدوية الجافة.
06 بعد نجاح الربط: ضبط عمق التفكير لتوفير الاستهلاك
بعد نجاح الربط، نوضح ميزة هامة: يدعم Codex تعديل «عمق تفكير النموذج» لموازنة جودة العمل مع استهلاك الرموز:
توفر الإعدادات خيار model_reasoning_effort لدعم مستويات تفكير متعددة تشمل minimal / low / medium / high / xhigh (حيث يعتمد xhigh على دعم النموذج المستخدم؛ راجع مرجع الإعدادات). وتهيئته في ملف config.toml كالتالي:
model_reasoning_effort = "medium"تشبيه: استراتيجية حل الامتحانات. يشبه خيار low الإجابة على الأسئلة السريعة حيث يقترح الحلول فورًا بسرعة وبأقل دقة؛ بينما يشبه خيار high أو xhigh حل المسائل المعقدة حيث يوجه النموذج للتفكير العميق وتفصيل التحليل مما يبطئ العمل ويزيد من دقته. وتفعيل الخيار الأقصى طوال الوقت يمنح نتائج ممتازة ولكنه يبطئ العمل ويسرع استهلاك الرموز。
عادتي الشخصية: أعتمد على وضع medium للمهام اليومية لسرعته وتوفيره؛ وعند العمل على مهام برمجية صعبة تتطلب قراءة عدة ملفات والربط بينها، أحوله مؤقتًا لـ high。وتثبيته على الحد الأقصى يضيع التوفير المالي لزيادة استهلاك الرموز دون مبرر.
تنبيه إضافي: عند ربط نماذج الطرف الثالث، قد تختلف سلوكيات بعض الميزات المدمجة لـ Codex أو تتعطف بالكامل — مثل البحث في الويب (حيث توضح إعدادات ميزة web_search اعتمادها على الفهرس السحابي المدار بواسطة OpenAI). ويوضح هذا الفكرة المذكورة في القسم 02 حول طبيعة الميزات التجريبية وضرورة التحقق منها عند الحاجة.
💡 الخلاصة في جملة واحدة: استخدم خيار
model_reasoning_effortلضبط عمق تفكير النموذج — واجعلmediumللمهام اليومية، وhighللمشاكل المعقدة لتوفير الاستهلاك؛ وتذكر احتمالية تعطل بعض الميزات المدمجة لـ OpenAI عند استخدام الطرف الثالث.
07 ملخص
ركز هذا المقال على فكرة أساسية: ربط نماذج الطرف الثالث مثل DeepSeek بـ Codex يوفر التكاليف، ولكنه يظل مسارًا تجريبيًا ويواجه مشاكل عدم استقرار مقارنة بـ Claude Code.
ونلخص النقاط الهامة في التالي:
| الخطوة | المفهوم والإجراء المطلوب |
|---|---|
| فهم الفروق | يعتمد Codex على بروتوكولات OpenAI (وتحديدًا Responses API) ويختلف عن Claude Code تمامًا |
| تقييم الجدوى | تجنب الربط اليدوي إذا كنت تمتلك اشتراك باقات ChatGPT، أو تركز على مهام معقدة |
| اختيار المسار | التهيئة اليدوية لملف config.toml للتعلم، وأدوات الوكيل (مثل CC Switch) للسرعة والجاهزية |
| تهيئة الملف | إعداد قسم model_providers والمتغيرات الرئيسية وحفظ مفتاح API key في متغير البيئة env_key |
| التحقق | تشغيل أمر /model لتأكيد قراءة النموذج، وإرسال توجيه مبسط؛ وأخطاء 400 تعني تعارض البروتوكولات |
| الاستخدام اللاحق | ضبط عمق التفكير بمتغير model_reasoning_effort وتجنب الحد الأقصى للمهام المعتادة |
يجب أن تكون قادرًا الآن على: تقييم مدى حاجتك لربط الطرف الثالث بـ Codex، اختيار المسار المناسب، إعداد قسم model_providers يدويًا بصيغة TOML الصحيحة، والتعرف على المشاكل الشائعة لتعارض البروتوكولات وحلها.
ونذكرك بالقاعدة الذهبية: العقبة الكبرى لربط الطرف الثالث بـ Codex ليست مهاراتك في كتابة الإعدادات، بل هي توافق بروتوكول الطرف الآخر مع شروط Codex. وتذكر هذا يوفر عليك عناء تكرار المحاولات دون فائدة.
المقال التالي 06 · تشغيل المهمة الأولى — تنتهي هنا أقسام التكوين والإعدادات، وسنبدأ من المقال القادم التطبيق العملي الفعلي. وسنوجه Codex لتعديل الأكواد وتشغيل أول مهمة بالكامل عمليًا، لتشعر بالفارق الجوهري بينه وبين الأدوات التقليدية. وسؤال للتفكير: ما هي أول مهمة ترغب في تكليف Codex بها — حل مشكلة برمجية (bug)، كتابة دالة جديدة، أم توجيهه لقراءة وفهم هيكل مشروعك بالكامل أولاً؟