4 فبراير 2026

إطلاق قدرات محرك Codex الأساسي: كيف قمنا ببناء خادم App Server

إعداد: سيليا تشين، أحد أعضاء الفريق التقني

جاري التحميل...

يتوفر Codex، وهو وكيل البرمجة الخاص بـ OpenAI، على منصات متعددة ومتنوعة تشمل: تطبيق الويب⁠(يفتح في نافذة جديدة)، وواجهة CLI⁠(يفتح في نافذة جديدة)، وملحق بيئة التطوير المتكاملة (IDE)⁠(يفتح في نافذة جديدة)، وتطبيق Codex الجديد لنظام التشغيل macOS. أما من حيث البنية الجوهرية، فجميع هذه المنصات تعتمد على محرك Codex الأساسي نفسه، والمتمثل في الحلقة التشغيلية للوكيل والمنطق الذي تقوم عليه كافة تجارب استخدام Codex. ويبرز هنا خادم Codex App Server⁠(يفتح في نافذة جديدة) بوصفه الرابط الأساسي بين كل هذه المنصات، حيث يعمل كواجهة API تعتمد بروتوكول JSON-RPC¹ وتتميز بكونها ثنائية الاتجاه وسلسةً جدًّا في التعامل من جهة العميل.

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

نشأة خادم App Server

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

كانت بداية Codex CLI عبر واجهة مستخدم طرفية (TUI)، حيث كان التعامل مع Codex يتم من خلال سطر الأوامر. ومع تطوير ملحق VS Code لتوفير تجربة تفاعل أكثر سلاسةً مع وكلاء Codex داخل بيئات التطوير، ظهرت الحاجة إلى توظيف محرك Codex الأساسي ذاته لتشغيل الحلقة التشغيلية للوكيل من داخل واجهة IDE مباشرةً دون تكرار البناء البرمجي. وقد استلزم هذا التوجه دعم أنماط تفاعلية متطورة تتخطى مجرد إرسال الطلبات واستلام الاستجابات، مثل تصفح مساحة العمل، ومتابعة خطوات تفكير الوكيل لحظةً بلحظة، وعرض الاختلافات في الأكواد البرمجية. فكرنا أولًا في تقديم Codex كخادم MCP⁠(يفتح في نافذة جديدة)، إلا أن ضبط معايير MCP لتلائم متطلبات VS Code كان تحديًا فنيًّا كبيرًا. لذا، اعتمدنا بروتوكول JSON-RPC الذي يعكس حلقة تشغيل واجهة TUI، ليكون بمثابة الإصدار الأول غير الرسمي⁠(يفتح في نافذة جديدة) لخادم App Server، والذي لم يكن مخططًا له حينها أن يكون واجهة API ثابتةً لاعتقادنا بعدم حاجة عملاء آخرين لاستخدامه.

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

سننتقل الآن لشرح الكيفية التي صممنا بها المعمارية الهندسية والبروتوكول بحيث يستطيع مختلف العملاء الاستفادة من محرك Codex الأساسي نفسه.

المكونات الداخلية لمحرك Codex الأساسي

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

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

2. الإعداد والمصادقة. يتولى Codex مسؤولية تحميل ملفات الإعداد وإدارة الخيارات الافتراضية، فضلًا عن تنفيذ إجراءات المصادقة مثل 'تسجيل الدخول باستخدام ChatGPT'، مع تتبع حالة بيانات الدخول والتحقق منها تتبعًا دقيقًا لضمان استمرارية الوصول.

3. تشغيل الأدوات والملحقات. يتولى Codex مهمة تشغيل أدوات الملفات والأوامر البرمجية (shell) ضمن بيئة برمجية آمنة ومعزولة تمامًا، ويربط بين مختلف عمليات التكامل مثل خوادم MCP والمهارات التقنية لضمان مساهمتها الفعالة في الحلقة التشغيلية للوكيل في إطار نموذج سياسات ثابت ومستقر.

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

ولكي يحقق محرك Codex الأساسي الغاية المرجوة منه، يجب منح العملاء إمكانية الوصول إليه؛ وهنا يبرز دور خادم App Server بوضوحٍ تامٍّ.

مخطط بعنوان 'تدفق عمليات خادم التطبيق'. يرسل العميل رسائل JSON-RPC إلى قارئ stdio، والذي يتولى توزيع الطلبات إلى معالج رسائل Codex. ويتفاعل المعالج مع مدير السلاسل والسلسلة الأساسية عبر سلاسل البحث، ومقابض السلاسل، والطلبات المُقدَّمة، والأحداث/التحديثات، ثم يقوم بإعادة الاستجابات مجددًا إلى العميل.

يعتبر خادم App Server بمثابة بروتوكول JSON-RPC للربط بين العميل والخادم، كما أنه يمثل عمليةً برمجيةً مستمرة تستضيف سلاسل محادثات Codex core. وكما يتضح من المخطط السابق، يتألف نظام خادم App Server من أربعة أجزاء أساسية هي: قارئ stdio، ومعالج لرسائل Codex، ومدير لسلاسل المحادثات، وسلاسل المحادثات الأساسية. ويعمل مدير سلاسل المحادثات على تفعيل جلسة أساسية لكل سلسلة، ليتولى بعد ذلك معالج رسائل Codex التواصل مع هذه الجلسات تواصلًا مباشرًا من أجل تقديم طلبات المستخدمين وتلقي كافة التحديثات اللازمة.

قد يؤدي طلبٌ واحدٌ من جانب المستخدم إلى توليد سلسلةٍ من التحديثات، وهذه التفاصيل هي السر وراء قدرتنا على بناء واجهة مستخدم متميزة عبر خادم App Server. وبشكلٍ أساسي، يعمل قارئ stdio ومعالج رسائل Codex كطبقة وسيطة للترجمة بين العميل وسلاسل محادثات Codex core؛ حيث يقومان بترجمة طلبات JSON-RPC إلى مهام ينفذها Codex core، والاستماع المستمر للأحداث التي تجري بداخله، ثم تحويل تلك التفاصيل التقنية المعقدة إلى مجموعةٍ محددةٍ من تنبيهات JSON-RPC المستقرة والمناسبة تمامًا للعرض على واجهات المستخدم.

ويتميز بروتوكول JSON-RPC بين العميل وخادم App Server بنظام اتصالٍ ثنائي الاتجاه بالكامل. وعادةً ما تحتوي سلسلة المحادثات الواحدة طلبًا من العميل متبوعًا بإخطارات كثيرة من جهة الخادم. وبخلاف ذلك، يملك الخادم صلاحية إصدار طلبات إذا ما احتاج الوكيل إلى إدخالات إضافية، كالحصول على موافقة، ليتوقف الدور مؤقتًا بانتظار رد العميل.

اللبنات الأساسية للمحادثات

سننتقل الآن لشرح اللبنات الأساسية للمحادثة، وهي العناصر الأولية التي يُبنى عليها بروتوكول خادم App Server. والحقيقة أن بناء واجهة API تدعم الحلقة التشغيلية للوكيل يمثل تحديًا فنيًّا كبيرً؛ نظرًا لأن التفاعل بين المستخدم والوكيل ليس تبادلًا بسيطًا للمعلومات (تقديم طلب واستلام رد). فمن الممكن أن يفتح طلب المستخدم الباب أمام مجموعة مرتبة من المهام التي ينبغي للعميل إظهارها بوضوحٍ تامٍّ، بدءًا من إدخالات المستخدم، ومرورًا بمراحل إنجاز الوكيل، ثم وصولًا إلى المخرجات البرمجية التي يتم إنتاجها أثناء العمل (مثل الفوارق البرمجية diffs). ولتيسير دمج هذا التدفق وتعزيز مرونته في واجهات الاستخدام المتنوعة، انتهينا إلى تحديد ثلاثة عناصر أولية محورية تعمل وفق ضوابط وفترات زمنية محددة:

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

item/started عند بدء العنصر
أحداث item/*/delta الاختيارية مع تدفق المحتوى (لأنواع العناصر التي تدعم البث)
item/completed عندما ينتهي العنصر من إرسال بياناته النهائية

تسمح دورة العمل هذه للعملاء ببدء العرض فورًا عند الحدث started، وبث التحديثات التدريجية عند الحدث delta، وإتمام العملية عند الحدث completed.

2. الدورة: الدورة هي وحدة العمل الأساسية للوكيل، وتبدأ بطلبٍ من المستخدم. وتبدأ هذه الدورة لحظة تقديم العميل مطالبة معينة (مثل: "run tests and summarize failures")، وتنتهي بانتهاء الوكيل من تقديم الردود والنتائج المطلوبة. وتتألف الدورة من سلسلة من العناصر التي تمثل الخطوات الانتقالية والنتائج النهائية التي تم التوصل إليها خلال خطوات العمل.

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

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

مخطط بعنوان 'تدفق رسائل بروتوكول العميل والخادم: مصافحة التهيئة'. يرسل العميل طلب initialize مع بيانات clientInfo إلى الخادم؛ وبدوره يرد الخادم بحدث result يحتوي على سلسلة userAgent النصية 'my_client/1.0'."

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

JSON

1{
2  "method": "initialize",
3  "id": 0,
4  "params": {
5    "clientInfo": {
6      "name": "codex_vscode",
7      "title": "Codex VS Code Extension",
8      "version": "0.1.0"
9    }
10  }
11}

وهذا هو رد الخادم:

JSON

1{
2  "id": 0,
3  "result": {
4    "userAgent": "codex_vscode/0.94.0-alpha.7 (Mac OS 26.2.0; arm64) vscode/2.4.22 (codex_vscode; 0.1.0)"
5  }
6}

مخطط بعنوان 'تدفق رسائل بروتوكول العميل والخادم: خطوات عمل سلسلة المحادثات والدورة'. يرسل العميل طلبي thread/start وturn/start إلى الخادم؛ وبدوره يُصدر الخادم مجموعةً من الأحداث تشمل: thread/started، وturn/started، وitem/started، وitem/completed. يوضح هذا المخطط نوبة عمل تكون فيها رسالة المستخدم هي: 'run tests and summarize failures'.

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

مخطط بعنوان "تدفق رسائل بروتوكول العميل-الخادم: تنفيذ الأداة مع موافقة اختيارية." أثناء استدعاء أداة، يُصدر الخادم item/started، ثم item/commandExecution/requestApproval مع سبب (“run tests”). يرسل العميل حدث موافقة (سماح/رفض). ثم يقوم الخادم بإصدار item/completed الذي يُظهر تنفيذ الأمر ("pnpm test").

تُرسل استدعاءات الأدوات أيضًا إلى العميل على شكل عناصر. بالإضافة إلى ذلك، قد يطلب الخادم موافقة العميل قبل أن يتمكن من تنفيذ إجراءٍ ما عن طريق إرسال طلب من الخادم. وستعمل هذه الموافقة على إيقاف الدورة مؤقتًا إلى أن يرد العميل بـ 'سماح' (allow) أو 'رفض' (deny). ويوضح المثال التالي كيف تبدو آلية الموافقة في إضافة VS Code:

مطالبة إذن في واجهة ذات طابع داكن تتضمن السؤال: 'هل تود السماح لي بتشغيل pnpm test لمساحة العمل هذه؟' وتستعرض الخيارات التالية: 1) نعم، 2) نعم ولا تسألني ثانيةً بشأن الأوامر التي تبدأ بـ pnpm test، و3) لا، مع وجود زر Submit (إرسال) في الأسفل."

مخطط بعنوان 'تدفق رسائل بروتوكول العميل والخادم: تدفق بث رسالة الوكيل'. يقوم الخادم ببث رسالة المساعد على أجزاء: تبدأ بالحدث item/started، يليه حدثا دلتا (agentMessage/delta) يحملان النصوص التالية: ("ran 3 tests."، و**"all passed"**)، ثم يكتمل العنصر بالحدث item/completed. وتختتم نوبة العمل بصدور الحدث turn/completed.

في النهاية، يرسل الخادم رسالة الوكيل ثم ينهي الدور باستخدام turn/completed. وتتولى أحداث الدلتا الخاصة برسالة الوكيل بث أجزاء الرسالة تباعًا إلى أن يكتمل العنصر تمامًا عبر الحدث item/completed.

تظهر المطالبات في المخطط بشكلٍ مبسطٍ لضمان سهولة القراءة؛ وفي حال أردت الاطلاع على بيانات JSON التفصيلية لدورة كاملة، فبإمكانك تشغيل عميل الاختبار الملحق بمستودع Codex CLI‏:

Bash

1codex debug app-server send-message-v2 "run tests and summarize failures"

التكامل مع العملاء

لننتقل الآن إلى استعراض السبل التي تتبعها منصات العملاء المتنوعة لتضمين تقنيات Codex من خلال خادم App Server. حيث سنتناول ثلاثة أنماط: التطبيقات على الأجهزة، وبيئات IDE، وبيئة التشغيل الشبكية Codex web runtime، بالإضافة إلى واجهة TUI.

مخطط بعنوان “عملاء Codex مدمجون مع Codex harness عبر خادم التطبيق.” يتواصل عملاء الطرف الأول (Codex Desktop App، TUI/CLI، Web Runtime) وعمليات التكامل التابعة لجهات خارجية (JetBrains IDEs، VS Code، Xcode) مع لمحرك Codex الأساسي عبر استدعاءات JSON-RPC.

تستخدم الأنماط الثلاثة جميعها بروتوكول JSON-RPC كطريقةٍ للنقل عبر واجهة stdio (بتنسيق JSONL). ويسهل هذا البروتوكول عملية بناء الروابط البرمجية للعميل باستخدام اللغة التي تناسبك. وقد نجحت منصات Codex وتكاملات الشركاء في توفير عملاء لخادم App Server بلغاتٍ متنوعةٍ مثل Go وPython وTypeScript وSwift وKotlin. وللحصول على تعريفات لغة TypeScript، يمكنك إنتاجها مباشرةً من بروتوكول Rust بتشغيل الأمر التالي:

Bash

1codex app-server generate-ts

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

Bash

1codex app-server generate-json-schema

التطبيقات على الأجهزة وبيئات IDE

لقطة شاشة لبرنامج VS Code مع تشغيل ملحق Codex. يظهر ملف اختبار بلغة Rust مفتوحًا، وتحته لوحة Codex التي تصف تشغيل أمرين هما fmt و cargo test -p codex-app-server؛ حيث تفيد اللوحة بأن عمليات التنسيق والاختبارات قيد التنفيذ حالياً بانتظار نتيجة النجاح أو الفشل النهائية.

يعتمد العملاء الموجودون على الأجهزة في العادة على دمج أو استدعاء ملف خادم App Server ثنائي يتوافق مع نظام التشغيل المعني، حيث يتم إطلاقه كعمليةٍ تابعة مستمرة، مع الحفاظ على اتصالٍ متبادل عبر قناة stdio لدعم بروتوكول JSON-RPC. وفي ملحق VS Code وتطبيق الحاسوب، تشتمل العناصر المرفقة على ملف Codex الثنائي المخصص، والذي يتم تثبيته على إصدارٍ خضع للاختبار المسبق؛ وذلك ليتسنى للعميل تشغيل ذات البيانات التقنية التي اعتمدناها وأجرينا عليها عمليات التحقق إجراءً دقيقًا.

ولا تكون كل عمليات الدمج قادرةً على توفير تحديثات للعملاء بشكل دوري ومستمر. ويعمد بعض الشركاء، ومنهم Xcode، إلى فصل مسارات الإصدار من خلال الحفاظ على ثبات العميل مع تمكينه من الاعتماد على ملف خادم App Server ثنائي أكثر حداثةً كلما اقتضت الضرورة. وتسمح هذه الاستراتيجية بالاستفادة من تحسينات الخادم (مثل تطوير آليات الضغط التلقائي في Codex core أو دعم خيارات إعداد جديدة) ونشر إصلاحات الأخطاء البرمجية دون التقيد بمواعيد إطلاق تحديثات العميل. كما روعي في تصميم بروتوكول JSON-RPC لخادم App Server دعم التوافقية الرجعية، بحيث يمكن للنسخ القديمة من العملاء التعامل مع الخوادم الحديثة تعاملًا آمنًا ومستقرًا.

Codex Web

يستخدم Codex Web محرك Codex الأساسي، غير أنه يشغله في بيئة حاويات برمجية معزولة. ويقوم برنامج عامل بتخصيص حاوية تشتمل على مساحة العمل المطلوبة، ويطلق داخلها ملف خادم App Server الثنائي، مع استمرار عمل قناة JSON-RPC طويلة الأمد عبر stdio². ومن ثم يتواصل تطبيق الويب (عبر متصفح المستخدم) مع خلفية Codex باستخدام تقنيات HTTP وSSE التي تتولى تدفق أحداث المهام الصادرة برنامج العامل. تهدف هذه البنية إلى إبقاء واجهة المتصفح بسيطةً وغير مستهلكةٍ للموارد، مع الحفاظ على تماثل بيئة التشغيل وتوافقها بين الويب وتطبيقات الحاسوب توافقًا شاملًا.

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

واجهة TUI/Codex CLI

لقطة شاشة لواجهة طرفية تقوم بتشغيل Codex CLI. يعرض لافتة OpenAI Codex مع وسيط النموذج gpt-5.2-codex وأمر مستخدم “explain app server to me”، وحالة “Working”. في الأسفل، يظهر اقتراح: “اكتب اختبارات لـ @filename”، مع خيارات للاختصارات.

في السابق، كانت واجهة TUI تعمل كعميل مدمجٍ داخل نفس عملية الحلقة التشغيلية للوكيل، وتتعامل مباشرةً مع كائنات Rust الأساسية بدلًا من الاعتماد على بروتوكول خادم App Server. وقد ساعد هذا الأسلوب على تسريع مراحل التطوير المبكرة، لكنه أدى في النهاية إلى جعل TUI واجهة منفصلة تتسم بخصائص فنية فريدة تختلف عن بقية المنصات.

بما أن خادم App Server بات متاحًا الآن، فإننا نخطط لإعادة هيكلة واجهة TUI⁠(يفتح في نافذة جديدة) لاستخدامها بحيث تعمل كأي عميل آخر: من خلال إطلاق عملية فرعية لخادم App Server، والتواصل عبر بروتوكول JSON-RPC من خلال واجهة stdio، وعرض نفس أحداث البث وعمليات الموافقة. يفتح هذا الأمر آفاقًا لخطوات العمل حيث يمكن لواجهة TUI الاتصال بخادم Codex يعمل على جهاز عن بعد، مما يُبقي الوكيل قريبًا من موارد المعالجة الحوسبية ويضمن استمرار العمل حتى في حال سكون الكمبيوتر المحمول أو انقطاع الاتصال، مع الاستمرار في تقديم التحديثات الحية وأدوات التحكم الموجودة على الجهاز.

اختيار البروتوكول الصحيح

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

بروتوكولات JSON-RPC

Codex كخادم MCP

نفذ الأمر codex mcp-server⁠(يفتح في نافذة جديدة) مع الربط بأي عميل MCP يتوافق مع خوادم stdio (على سبيل المثال: OpenAI Agents SDK⁠(يفتح في نافذة جديدة)). ويُعتبر هذا النهج خيارًا مثاليًا إذا كنت تمتلك نظام عمل قائمًا على MCP وتود استخدام Codex كأداة استدعاء برمجية. وتتمثل السلبية هنا في تقيد الإمكانات بما يوفره إطار عمل MCP حصرًا؛ فالتفاعلات الخاصة بنظام Codex والتي ترتكز على مفاهيم جلسات أكثر تعقيدًا (مثل تحديثات الفروقات البرمجية diff) قد لا تجد لها تمثيلًا متوافقًا تمامًا عبر نقاط النهاية في MCP.

بروتوكولات أدوات الوكلاء المشتركة بين مقدمي الخدمات

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

خادم Codex App Server

يُعد خدم App Server الخيار الأمثل لمن يتطلعون إلى استغلال إمكانات محرك Codex الأساسي الشاملة عبر دفق بيانات متسق ومناسب لواجهات الاستخدام. فمن خلاله، تحصل على الفعالية الكاملة للحلقة التشغيلية للوكيل، بالإضافة إلى خصائص إضافيةٍ كخاصية "تسجيل الدخول باستخدام ChatGPT"، واستكشاف النماذج، وضبط التهيئة. ورغم أن عبء التكامل البرمجي يقع على عاتق المطور لبناء مكتبات الربط الخاصة بـ JSON-RPC باللغة التي يختارها، إلا أن Codex أثبت قدرته على تولي الجانب الأكبر من هذه الأعباء التقنية عند إمداده بمخطط JSON والمستندات الفنية. وقد نجحت أفرقة برمجية كثيرة تعاونّا معها في الوصول إلى مرحلة التشغيل الفعلي للتكامل خلال وقت قصير بفضل قدرات Codex.

طرق أخرى لدمج Codex

Codex Exec⁠(يفتح في نافذة جديدة)

وضع CLI يمتاز بخفة الموارد ويدعم البرمجة النصية لتنفيذ المهام التي تُجرى لمرة واحدة وجلسات CI. ويناسب هذا الوضع بيئات الأتمتة وسلاسل التدفق البرمجي حيث ترغب في تنفيذ أمر وحيد حتى النهاية دون تدخل بشري، مع ضمان تدفق مخرجات منظَّمة لأرشفة السجلات، والخروج برمز استجابة يحدد النجاح أو الإخفاق.

Codex SDK⁠(يفتح في نافذة جديدة)

مكتبة برمجية بلغة TypeScript تتيح التحكم برمجيًا في وكلاء Codex الموجودين على الأجهزة من قلب تطبيقك. ويبرز تميزها حينما تحتاج إلى واجهة مكتبة مدمجة لإدارة الأدوات ومسارات العمل في جانب الخادم بمعزلٍ عن بناء عميل JSON-RPC مستقل. وباعتبارها أُطلقت قبل توفر خادم App Server، فإن دعمها يقتصر حاليًا على لغات برمجية محدودة وتوفر واجهة تقنية أضيق نطاقًا. وفي حال أبدى المطورون اهتمامًا بذلك، فقد نتوسع في تقديم حزم SDK إضافية تعمل كغطاءٍ لبروتوكول خادم App Server، مما يُمكّن الأفرقة التقنية من استغلال إمكانات محرك Codex الأساسي بشكل أوسع دون الانشغال بكتابة أكواد ربط JSON-RPC.

الخطوات القادمة

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

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

المؤلف

Celia Chen

الشكر والتقدير

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

الهوامش

1
نستخدم نوعًا من “JSON‑RPC lite”: يحتفظ بشكل الطلب/الاستجابة/الإشعار، لكنه يحذف "jsonrpc": "2.0" العنوان ويتم تأطيره كـ JSONL عبر stdio بدلاً من JSON‑RPC 2.0 الصارم.
يشير مصطلح 'stdio' هنا إلى مدخلات ومخرجات خادم التطبيق القياسية (stdin/stdout) داخل الحاوية. وفي الإعدادات المستضافة، غالبًا ما يتم تمرير هذه التدفقات عبر نفق اتصالٍ شبكيٍّ مستمرٍ (يشبه WebSocket) وصولاً إلى بيئة تشغيل الحاوية؛ وبذلك، هي تعمل وكأنها واجهة stdio تمامًا، حتى وإن لم تكن أنبوبًا محليًا بمعناه الحرفي.

متابعة القراءة

عرض الكل

بناء وكلاء ضرائب يتحسنون ذاتيًا باستخدام Codex

الهندسة27 مايو 2026

بناء صندوق حماية آمن وفعّال لتمكين Codex على Windows

الهندسة13 مايو 2026

من أين جاءت العفاريت

الهندسة5 مايو 2026