مرکزی مواد پر جائیں
OpenAI

۴ فروری، ۲۰۲۶

انجینئرنگ

Codex ہارنس کو انلاک کرنا: ہم نے ایپ سرور کیسے بنایا

سیلیا چن، تکنیکی عملے کی رکن

لوڈ ہو رہا ہے…

OpenAI کا کوڈنگ ایجنٹ Codex کئی مختلف سطحوں پر موجود ہے: ویب ایپ(نئی ونڈو میں کھلتا ہے)، CLI(نئی ونڈو میں کھلتا ہے)، IDE ایکسٹینشن(نئی ونڈو میں کھلتا ہے) اور نئی Codex macOS ایپ. پردے کے پیچھے، یہ سب ایک ہی Codex ہارنیس سے چلتے ہیں—ایجنٹ لوپ اور منطق جو تمام Codex تجربات کی بنیاد ہے. ان کے درمیان اہم ربط کیا ہے؟ Codex ایپ سرور(نئی ونڈو میں کھلتا ہے)، ایک کلائنٹ دوست، دو طرفہ JSON-RPC1 API.

اس پوسٹ میں، ہم Codex ایپ سرور کا تعارف کرائیں گے؛ ہم اب تک کے اپنے سیکھے گئے علم کا اشتراک کریں گے کہ آپ کی پروڈکٹ میں Codex کی صلاحیتوں کو لانے کے بہترین طریقے کون سے ہیں تاکہ آپ کے صارفین اپنے ورک فلو کو مزید مؤثر بنا سکیں. ہم ایپ سرور کی آرکیٹیکچر اور پروٹوکول کا احاطہ کریں گے اور یہ کہ یہ مختلف Codex سرفیسز کے ساتھ کیسے مربوط ہوتا ہے، نیز Codex سے فائدہ اٹھانے کے لیے تجاویز بھی فراہم کریں گے، چاہے آپ Codex کو ایک کوڈ جائزہ کار، ایک SRE ایجنٹ یا ایک کوڈنگ اسسٹنٹ میں تبدیل کرنا چاہتے ہوں.

ایپ سرور کی ابتدا

معماری میں غوطہ لگانے سے پہلے، ایپ سرور کی پس منظر کی کہانی جاننا مفید ہے. ابتدائی طور پر، ایپ سرور ایک عملی طریقہ تھا جس کے ذریعے Codex ہارنیس کو مختلف مصنوعات میں دوبارہ استعمال کیا جا سکتا تھا، جو بتدریج ترقی کر کے ہمارے معیاری پروٹوکول میں تبدیل ہو گیا.

Codex CLI نے TUI (ٹرمینل یوزر انٹرفیس) کے طور پر آغاز کیا، یعنی Codex تک رسائی ٹرمینل کے ذریعے ہوتی ہے. جب ہم نے VS Code ایکسٹینشن (Codex ایجنٹس کے ساتھ تعامل کرنے کا ایک زیادہ IDE-دوستانہ طریقہ) بنایا، تو ہمیں اسی ہارنس کو استعمال کرنے کا ایک طریقہ درکار تھا تاکہ اسے دوبارہ نافذ کیے بغیر IDE UI سے اسی ایجنٹ لوپ کو چلایا جا سکے. اس کا مطلب یہ تھا کہ درخواست/جواب سے آگے بڑھ کر بھرپور تعامل کے نمونوں کو سپورٹ کیا جائے، جیسے ورک اسپیس کو دریافت کرنا، ایجنٹ کے استدلال کے دوران پیشرفت کو اسٹریم کرنا اور فرق کو خارج کرنا. ہم نے پہلے Codex کو ایک MCP سرور کے طور پر پیش کرنے(نئی ونڈو میں کھلتا ہے) کے ساتھ تجربہ کیا، لیکن VS Code کے لیے بامعنی انداز میں MCP سیمینٹکس کو برقرار رکھنا مشکل ثابت ہوا. اس کے بجائے، ہم نے ایک JSON-RPC پروٹوکول متعارف کرایا جو TUI لوپ کی عکاسی کرتا تھا، جو ایپ سرور کا غیر سرکاری پہلا ورژن(نئی ونڈو میں کھلتا ہے) بن گیا. اس وقت، ہمیں یہ توقع نہیں تھی کہ دوسرے کلائنٹس ایپ سرور پر انحصار کریں گے، اس لیے اسے ایک مستحکم API کے طور پر ڈیزائن نہیں کیا گیا تھا.

اگلے چند مہینوں میں جیسے جیسے Codex کو اپنانے میں اضافہ ہوا، اندرونی ٹیمیں اور بیرونی شراکت دار یہ صلاحیت چاہتے تھے کہ وہ اپنے صارفین کے سافٹ ویئر ڈویلپمنٹ ورک فلو کو تیز کرنے کے لیے اسی ہارنیس کو اپنی مصنوعات میں شامل کر سکیں. مثال کے طور پر، JetBrains اور Xcode ایک IDE-گریڈ ایجنٹ کا تجربہ چاہتے تھے، جبکہ Codex ڈیسک ٹاپ ایپ کو متعدد Codex ایجنٹس کو متوازی طور پر منظم کرنے کی ضرورت تھی. ان مطالبات نے ہمیں ایک ایسا پلیٹ فارم ڈیزائن کرنے پر مجبور کیا جس پر ہماری مصنوعات اور پارٹنر انضمام وقت کے ساتھ محفوظ طریقے سے انحصار کر سکیں. یہ ضروری تھا کہ اسے انضمام کے لیے آسان اور پسماندہ مطابقت والا بنایا جائے، یعنی ہم موجودہ کلائنٹس کو نقصان پہنچائے بغیر پروٹوکول کو ترقی دے سکیں.

اگلے مرحلے میں، ہم یہ دیکھیں گے کہ ہم نے آرکیٹیکچر اور پروٹوکول کو کیسے ڈیزائن کیا تاکہ مختلف کلائنٹس ایک ہی ہارنس استعمال کر سکیں.

Codex ہارنس کے اندر

سب سے پہلے، آئیے Codex ہارنس کے اندر موجود مواد اور Codex ایپ سرور کے اسے کلائنٹس کے سامنے پیش کرنے کے طریقے پر قریب سے نظر ڈالیں. ہمارے پچھلے Codex بلاگ میں، ہم نے بنیادی ایجنٹ لوپ کی وضاحت کی جو صارف، ماڈل اور ٹولز کے درمیان تعامل کو منظم کرتا ہے. یہ Codex ہارنیس کی بنیادی منطق ہے، لیکن مکمل ایجنٹ کے تجربے میں اس سے بھی زیادہ شامل ہے:

1. تھریڈ کے زندگی کے مراحل اور مستقل مزاجی. ایک تھریڈ صارف اور ایک ایجنٹ کے درمیان Codex گفتگو ہے. Codex تھریڈز کو بناتا، دوبارہ شروع کرتا، فورک اور آرکائیو کرتا ہے اور ایونٹ ہسٹری کو محفوظ رکھتا ہے تاکہ کلائنٹس دوبارہ کنیکٹ ہو سکیں اور ایک مستقل ٹائم لائن پیش کر سکیں.

2. تشکیل کاری اور توثیق کاری. Codex کنفیگریشن لوڈ کرتا ہے، طے شدہ ترتیبات کو منظم کرتا ہے اور "ChatGPT کے ساتھ سائن ان کریں" جیسے توثیقی فلو چلاتا ہے، بشمول اسناد کی حالت.

3. ٹول کے نفاذ اور ایکسٹینشنز. Codex ایک سینڈ باکس میں شیل/فائل ٹولز کو چلاتا ہے اور MCP سرورز اور مہارتوں جیسے انضمامات کو وائر کرتا ہے تاکہ وہ ایک مستقل پالیسی ماڈل کے تحت ایجنٹ لوپ میں شامل ہو سکیں.

ہم نے یہاں جس ایجنٹ منطق کا ذکر کیا ہے، بشمول بنیادی ایجنٹ لوپ، Codex CLI کوڈبیس کے ایک حصے میں موجود ہے جسے "Codex کور(نئی ونڈو میں کھلتا ہے)" کہا جاتا ہے. Codex کور ایک لائبریری ہے جہاں تمام ایجنٹ کوڈ موجود ہوتا ہے اور ایک رن ٹائم ہے جسے ایجنٹ لوپ چلانے اور ایک Codex تھریڈ (گفتگو) کی پائیداری کو منظم کرنے کے لیے شروع کیا جا سکتا ہے.

مفید ہونے کے لیے، Codex ہارنیس کا کلائنٹس کے لیے قابل رسائی ہونا ضروری ہے. یہی وہ مقام ہے جہاں ایپ سرور اپنا کردار ادا کرتا ہے.

ڈایاگرام بعنوان "ایپ سرور پروسیس فلو." ایک کلائنٹ JSON-RPC پیغامات stdio ریڈر کو بھیجتا ہے، جو درخواستوں کو Codex پیغام پروسیسر تک بھیجتا ہے. پروسیسر لک اپ تھریڈز، تھریڈ ہینڈلز، جمع کرائی گئی درخواستوں اور ایونٹس/اپ ڈیٹس کے ذریعے تھریڈ مینیجر اور کور تھریڈ کے ساتھ تعامل کرتا ہے، پھر جوابات کلائنٹ کو واپس بھیجتا ہے.

ایپ سرور کلائنٹ اور سرور کے درمیان JSON-RPC پروٹوکول ہے اور ایک طویل مدتی عمل ہے جو Codex کور تھریڈز کو ہوسٹ کرتا ہے. جیسا کہ ہم اوپر دیئے گئے ڈایاگرام سے دیکھ سکتے ہیں، ایک ایپ سرور پروسیس کے چار بنیادی اجزاء ہوتے ہیں: stdio ریڈر، Codex میسج پروسیسر، تھریڈ مینیجر اور کور تھریڈز. تھریڈ مینیجر ہر تھریڈ کے لیے ایک کور سیشن شروع کرتا ہے اور Codex پیغام پروسیسر پھر ہر کور سیشن کے ساتھ براہ راست رابطہ کرتا ہے تاکہ کلائنٹ ریکوئسٹیں جمع کی جا سکیں اور اپ ڈیٹس وصول کیے جا سکیں.

ایک کلائنٹ ریکوئسٹ کے نتیجے میں کئی ایونٹ اپ ڈیٹس ہو سکتے ہیں اور یہی تفصیلی ایونٹس ہمیں ایپ سرور پر ایک بھرپور UI بنانے کے قابل بناتے ہیں. مزید برآں، stdio ریڈر اور Codex میسج پروسیسر کلائنٹ اور Codex کور تھریڈز کے درمیان ترجمہ کی پرت کے طور پر کام کرتے ہیں. وہ کلائنٹ JSON-RPC درخواستوں کو Codex core آپریشنز میں ترجمہ کرتے ہیں، Codex کور کے اندرونی ایونٹ اسٹریم کو سنتے ہیں اور پھر ان کم سطحی ایونٹس کو مستحکم، UI-ریڈی JSON-RPC نوٹیفیکیشنز کے ایک چھوٹے سیٹ میں تبدیل کرتے ہیں.

کلائنٹ اور ایپ سرور کے درمیان JSON-RPC پروٹوکول مکمل طور پر دو طرفہ ہے. ایک عام تھریڈ میں ایک کلائنٹ ریکوئسٹ اور سرور کی بہت سی اطلاعات ہوتی ہیں. مزید برآں، جب ایجنٹ کو کسی اِن پُٹ کی ضرورت ہو، جیسے منظوری، تو سرور درخواستیں شروع کر سکتا ہے اور پھر کلائنٹ کے جواب دینے تک عمل کو روک سکتا ہے.

گفتگو کے بنیادی اصول

اگلا، ہم گفتگو کے بنیادی اجزاء کو توڑ کر سمجھائیں گے، جو ایپ سرور پروٹوکول کے تعمیراتی بلاکس ہیں. ایجنٹ لوپ کے لیے API ڈیزائن کرنا مشکل ہے کیونکہ صارف/ایجنٹ کا تعامل ایک سادہ درخواست/جواب نہیں ہوتا. ایک صارف کی درخواست ایک منظم سلسلۂ اقدامات میں کھل سکتی ہے جس کی نمائندگی کلائنٹ کو وفاداری سے کرنی ہوتی ہے: صارف کا ان پٹ، ایجنٹ کی بتدریج پیش رفت اور راستے میں تیار ہونے والے آرٹیفیکٹس (مثلاً، diffs). اس تعاملاتی سلسلے کو UIs میں ضم کرنا آسان اور مختلف UIs میں مضبوط رکھنے کے لیے، ہم نے واضح حدود اور زندگی کے مراحل کے ساتھ تین بنیادی اصولوں پر اتفاق کیا:

1. آئٹم: Codex میں آئٹم ان پٹ/آؤٹ پٹ کی بنیادی اکائی ہے. آئٹمز کی اقسام ہوتی ہیں (مثال کے طور پر، صارف کا پیغام، ایجنٹ کا پیغام، ٹول کی عمل درآمد، منظوری کی درخواست، diff) اور ہر ایک کا ایک واضح زندگی کا چکر ہوتا ہے.

  • آئٹم/شروع کیا جب آئٹم شروع ہوتا ہے
  • اختیاری آئٹم/*/ڈیلٹا ایونٹس کو مواد کے سلسلے کے طور پر استعمال کریں (اسٹریمنگ آئٹم اقسام کے لیے)
  • آئٹم/مکمل کردہ جب آئٹم اپنے آخری پے لوڈ کے ساتھ مکمل ہوتا ہے

یہ لائف سائیکل کلائنٹس کو شروع کردہ پر فوراً رینڈرنگ شروع کرنے، ڈیلٹا پر بتدریج اپ ڈیٹس اسٹریم کرنے اور مکمل کردہ پر مکمل کرنے کی اجازت دیتا ہے.

2. باری: باری ایجنٹ کے کام کی ایک اکائی ہے جو صارف کی ان پُٹ سے شروع ہوتی ہے. یہ عمل اس وقت شروع ہوتا ہے جب کلائنٹ ایک اِن پٹ جمع کراتا ہے (مثال کے طور پر، "ٹیسٹ چلائیں اور ناکامیوں کا خلاصہ کریں") اور اس وقت ختم ہوتا ہے جب ایجنٹ اس اِن پٹ کے لیے آؤٹ پٹ تیار کرنا مکمل کر لیتا ہے. ایک ٹرن میں آئٹمز کی ایک ترتیب شامل ہوتی ہے جو راستے میں پیدا ہونے والے درمیانی مراحل اور نتائج کی نمائندگی کرتی ہے.

3. تھریڈ: تھریڈ ایک پائیدار کنٹینر ہے جو صارف اور ایجنٹ کے درمیان جاری Codex سیشن کے لیے ہوتا ہے. اس میں متعدد مراحل شامل ہیں. تھریڈز بنائے جا سکتے ہیں، دوبارہ شروع کیے جا سکتے ہیں، فورک کیے اور محفوظ کیے جا سکتے ہیں. تھریڈ کی تاریخ محفوظ کی جاتی ہے تاکہ صارفین دوبارہ جڑ سکیں اور ایک مستقل ٹائم لائن پیش کر سکیں.

اب، ہم ایک کلائنٹ اور ایک ایجنٹ کے درمیان ایک سادہ گفتگو دیکھیں گے، جہاں گفتگو کو بنیادی عناصر کے ذریعے پیش کیا گیا ہے:

ڈایاگرام بعنوان "کلائنٹ سرور پروٹوکول پیغام کا بہاؤ: ابتدائی مصافحہ." ایک کلائنٹ سرور کو clientInfo کے ساتھ ایک ابتدائی درخواست بھیجتا ہے. سرور userAgent اسٹرنگ "my_client/1.0." پر مشتمل ایک نتیجہ ایونٹ کے ساتھ جواب دیتا ہے.

گفتگو کے آغاز میں، کلائنٹ اور سرور کو شروعاتی ہینڈ شیک قائم کرنا ضروری ہے. کلائنٹ کو کسی بھی دوسرے طریقہ سے پہلے ایک واحد شروعاتی درخواست بھیجنی چاہیے اور سرور جواب کے ساتھ تصدیق کرتا ہے. یہ سرور کو اپنی صلاحیتوں کی تشہیر کرنے کا موقع فراہم کرتا ہے اور دونوں فریقوں کو پروٹوکول ورژننگ، فیچر فلیگز اور ڈیفالٹس پر اتفاق کرنے دیتا ہے، تاکہ اصل کام شروع ہونے سے پہلے سب کچھ طے ہو جائے. یہاں OpenAI کی VS Code ایکسٹینشن سے ایک مثال کا پے لوڈ ہے:

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
}
ڈایاگرام بعنوان "کلائنٹ سرور پروٹوکول میسج فلو: تھریڈ اینڈ ٹرن لائف سائیکل." کلائنٹ سرور کو تھریڈ/شروع کریں اور باری/شروع کریں کی درخواستیں بھیجتا ہے. سرور واقعات کو خارج کرتا ہے—تھریڈ/شروع کیا، باری/شروع کی، آئٹم/شروع کیا اور آئٹم/مکمل کردہ—ایک باری دکھاتا ہے جہاں صارف کا پیغام "ٹیسٹس چلائیں اور ناکامیوں کا خلاصہ کریں" ہوتا ہے.

جب کوئی کلائنٹ نئی درخواست کرتا ہے، تو یہ پہلے ایک تھریڈ بنائے گا اور پھر ایک باری. سرور پیشرفت کے نوٹیفکیشن واپس بھیجے گا (تھریڈ/شروع کردہ اور باری/شروع کردہ). یہ ان پٹس بھی واپس بھیجے گا جنہیں یہ آئٹمز کے طور پر رجسٹر کرتا ہے، جیسے یہاں صارف کا پیغام.

ڈایاگرام بعنوان "کلائنٹ-سرور پروٹوکول پیغام کا فلو: اختیاری منظوری کے ساتھ ٹول کا عمل درآمد." ٹول کال کے دوران، سرور آئٹم/شروع کردہ، پھر کسی وجہ کے ساتھ آئٹم/کمانڈ ایگزیکیوشن/درخواست منظوری کو ایک استدلال ("ٹیسٹ چلائیں") کے ساتھ خارج کرتا ہے. کلائنٹ ایک منظوری کا ایونٹ واپس کرتا ہے (اجازت دیں/انکار کریں). پھر سرور آئٹم/مکمل کردہ خارج کرتا ہے جو کمانڈ کے عملدرآمد کو ظاہر کرتا ہے ("pnpm ٹیسٹ").

ٹول کالز کو بھی آئٹمز کے طور پر کلائنٹ کو واپس بھیجا جاتا ہے. مزید برآں، سرور سرور کی درخواست بھیج کر کسی کارروائی کو چلانے سے پہلے کلائنٹ کی منظوری طلب کر سکتا ہے. منظوری اس وقت تک عمل کو روک دے گی جب تک کہ کلائنٹ "اجازت دیں" یا "انکار کریں" میں سے کسی ایک کے ساتھ جواب نہ دے. VS Code ایکسٹینشن میں منظوری کا عمل کچھ اس طرح نظر آتا ہے:

ڈارک تھیم والے انٹرفیس میں اجازت کی پرامپٹ پوچھ رہی ہے، "کیا آپ چاہتے ہیں کہ میں اس ورک اسپیس کے لیے pnpm ٹیسٹ چلاؤں؟" یہ اختیارات کی فہرست دیتا ہے: 1) ہاں، 2) ہاں اور pnpm ٹیسٹ سے شروع ہونے والے کمانڈز کے بارے میں دوبارہ مت پوچھیں اور 3) نہیں، نیچے جمع کرائیں کے بٹن کے ساتھ.
ڈایاگرام بعنوان "کلائنٹ سرور پروٹوکول میسج فلو: اسٹریمنگ ایجنٹ میسج فلو." سرور ایک اسسٹنٹ پیغام کو حصوں میں اسٹریم کرتا ہے: آئٹم/شروع کیا، دو ایجنٹ میسج/ڈیلٹا ایونٹس ("3 ٹیسٹ چلائے."، "آل پاسڈ")، پھر آئٹم/مکمل کردہ. باری کا اختتام باری/مکمل کردہ پر ہوتا ہے.

آخر میں، سرور ایک ایجنٹ پیغام بھیجتا ہے اور پھر باری/مکمل کردہ کے ساتھ باری کو ختم کرتا ہے. ایجنٹ میسج ڈیلٹا ایونٹس میسج کے حصے واپس بھیجتے رہتے ہیں جب تک کہ میسج آئٹم/مکمل کردہ کے ساتھ مکمل نہ ہو جائے.

ڈایاگرام میں موجود پیغامات کو پڑھنے میں آسانی کے لیے سادہ بنایا گیا ہے. اگر آپ ایک مکمل باری کے لیے JSON دیکھنا چاہتے ہیں، تو آپ Codex CLI ریپو سے ٹیسٹ کلائنٹ چلا سکتے ہیں.

Bash

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

کلائنٹس کے ساتھ انضمام کرنا

اب، آئیے دیکھیں کہ مختلف کلائنٹ سرفیسز ایپ سرور کے ذریعے Codex کو کیسے شامل کرتی ہیں. ہم تین پیٹرنز کا احاطہ کریں گے: مقامی ایپس اور IDEs، Codex ویب رن ٹائم اور TUI.

ڈایاگرام بعنوان "Codex کلائنٹس ایپ سرور کے ذریعے Codex ہارنیس سے انضمام شدہ." فرسٹ پارٹی کلائنٹس (Codex Desktop App, TUI/CLI, Web رن ٹائم) اور تھرڈ پارٹی انٹیگریشنز (JetBrains IDEs, VS Code, Xcode) Codex ہارنیس کے ساتھ JSON-RPC کالز کے ذریعے رابطہ کرتے ہیں.

تینوں میں، ٹرانسپورٹ JSON-RPC اوور stdio (JSONL) ہے. JSON-RPC آپ کی پسند کی زبان میں کلائنٹ بائنڈنگز بنانا سیدھا سادہ بناتا ہے. Codex سرفیسز اور پارٹنر انٹیگریشنز نے Go، Python، TypeScript، Swift اور Kotlin جیسی زبانوں میں ایپ سرور کلائنٹس نافذ کیے ہیں. TypeScript کے لیے، آپ رسٹ پروٹوکول سے براہ راست ڈیفینیشنز تیار کر سکتے ہیں، یہ چلا کر:

Bash

1
codex app-server generate-ts

دیگر زبانوں کے لیے، آپ ایک JSON اسکیما بنڈل تیار کر سکتے ہیں اور اسے اپنے پسندیدہ کوڈ جنریٹر میں فیڈ کرنے کے لیے چلا سکتے ہیں:

Bash

1
codex app-server generate-json-schema
مقامی ایپس اور IDEs
VS Code کا اسکرین شاٹ جس میں Codex ایکسٹینشن چل رہی ہے. ایک رسٹ ٹیسٹ فائل کھلی ہے اور اس کے نیچے Codex پینل صرف fmt اور کارگو ٹیسٹ -p codex-app-server چلانے کی وضاحت کرتا ہے، یہ رپورٹ کرتا ہے کہ فارمیٹنگ اور ٹیسٹ جاری ہیں جبکہ حتمی پاس/فیل کے نتیجے کا انتظار ہے.

مقامی کلائنٹس عموماً پلیٹ فارم کے لحاظ سے مخصوص ایپ سرور بائنری کو بنڈل کرتے ہیں یا حاصل کرتے ہیں، اسے ایک طویل عرصے تک چلنے والے چائلڈ پراسس کے طور پر لانچ کرتے ہیں اور JSON-RPC کے لیے ایک دو طرفہ stdio چینل کھلا رکھتے ہیں. مثال کے طور پر، ہماری VS Code ایکسٹینشن اور ڈیسک ٹاپ ایپ میں، بھیجا گیا آرٹیفیکٹ پلیٹ فارم کے لحاظ سے مخصوص Codex بائنری شامل کرتا ہے اور اسے ایک آزمودہ ورژن پر پن کیا جاتا ہے تاکہ کلائنٹ ہمیشہ بالکل وہی بِٹس چلائے جن کی ہم نے تصدیق کی ہے.

ہر انٹیگریشن کثرت سے کلائنٹ اپ ڈیٹس نہیں بھیج سکتی. کچھ شراکت دار، جیسے Xcode، کلائنٹ کو مستحکم رکھ کر اور ضرورت پڑنے پر اسے نئے ایپ سرور باَنری کی طرف اشارہ کرنے کی اجازت دے کر ریلیز سائیکلز کو الگ کرتے ہیں. اس طرح وہ سرور سائیڈ کی بہتریاں (مثال کے طور پر، Codex کور میں بہتر آٹو-کمپیکشن یا نئی سپورٹ شدہ کنفیگ کلیدیں) اپنا سکتے ہیں اور کلائنٹ ریلیز کا انتظار کیے بغیر بگ فکسز جاری کر سکتے ہیں. ایپ سرور کی JSON-RPC سطح کو پچھلی مطابقت کے ساتھ اس طرح ڈیزائن کیا گیا ہے کہ پرانے کلائنٹس نئے سرورز کے ساتھ محفوظ طریقے سے بات چیت کر سکیں.

Codex ویب
Codex ویب انٹرفیس کا اسکرین شاٹ جس میں 'لاگ اِن کامیابی کے پیغام کو اپ ڈیٹ کریں' کے عنوان سے ایک اپ ڈیٹ دکھایا گیا ہے. بایاں پینل تبدیلیوں، ٹیسٹوں اور ترمیم شدہ فائلوں کا خلاصہ پیش کرتا ہے، جبکہ دایاں پینل login.rs کے لیے کوڈ فرق دکھاتا ہے جس میں لاگ اِن کی کامیابی کے پیغام کی عبارت کو اپ ڈیٹ کیا گیا ہے.

Codex ویب Codex ہارنس استعمال کرتی ہے، لیکن اسے کنٹینر ماحول میں چلاتا ہے. ایک ورکر چیک آؤٹ کردہ ورک اسپیس کے ساتھ ایک کنٹینر تیار کرتا ہے، اس کے اندر ایپ سرور بائنری کو چلاتا ہے اور stdio2 چینل پر ایک طویل مدتی JSON-RPC کو برقرار رکھتا ہے. ویب ایپ (جو صارف کے براؤزر ٹیب میں چل رہی ہے) HTTP اور SSE کے ذریعے Codex بیک اینڈ سے بات کرتی ہے، جو ورکر کے تیار کردہ ٹاسک ایونٹس کو اسٹریم کرتا ہے. یہ براؤزر سائیڈ UI کو ہلکا پھلکا رکھتا ہے جبکہ ڈیسک ٹاپ اور ویب پر ہمیں ایک مستقل رن ٹائم فراہم کرتا ہے.

کیونکہ ویب سیشن عارضی ہوتے ہیں (ٹیبز بند ہو جاتی ہیں، نیٹ ورک ڈراپ ہو جاتے ہیں)، اس لیے ویب ایپ طویل مدتی کاموں کے لیے حقیقت کا ذریعہ نہیں ہو سکتی. سرور پر حالت اور پیش رفت کو برقرار رکھنے کا مطلب یہ ہے کہ کام جاری رہتا ہے چاہے ٹیب غائب ہو جائے. اسٹریمنگ پروٹوکول اور محفوظ کردہ تھریڈ سیشنز نئے سیشن کے لیے دوبارہ جڑنا، وہیں سے دوبارہ شروع کرنا جہاں چھوڑا تھا اور کلائنٹ میں حالت کو دوبارہ بنائے بغیر تیزی سے آگے بڑھنا آسان بناتے ہیں.

TUI/Codex CLI
Codex CLI چلانے والے ٹرمینل کا اسکرین شاٹ. یہ ماڈل gpt-5.2-codex کے ساتھ OpenAI Codex بینر دکھاتا ہے میڈیم، ایک صارف کمانڈ "ایپ سرور کی وضاحت کریں،" اور ایک "ورکنگ" اسٹیٹس. نیچے ایک تجویز ظاہر ہوتی ہے: "@filename کے لیے ٹیسٹ لکھیں،" شارٹ کٹس کے اختیارات کے ساتھ.

تاریخی طور پر، TUI ایک "مقامی" کلائنٹ تھا جو ایجنٹ لوپ کے ساتھ اسی پراسس میں چلتا تھا اور ایپ-سرور پروٹوکول کے بجائے براہِ راست رسٹ کور ٹائپس سے بات کرتا تھا. اس سے ابتدائی تکراری عمل تیز ہو گیا، لیکن اس نے TUI کو ایک خاص کیس سطح بھی بنا دیا.

اب جبکہ ایپ سرور موجود ہے، ہم پلان بنا رہے ہیں کہ TUI کو ریفیکٹر کریں(نئی ونڈو میں کھلتا ہے) تاکہ یہ اسے استعمال کرے اور کسی بھی دوسرے کلائنٹ کی طرح برتاؤ کرے: ایک ایپ سرور چائلڈ پروسیس لانچ کرے، stdio پر JSON-RPC کے ذریعے بات کرے اور وہی اسٹریمنگ ایونٹس اور منظوریوں کو رینڈر کرے. یہ ایسے ورک فلو کو فعال کرتا ہے جہاں TUI کسی دور دراز مشین پر چلنے والے Codex سرور سے جڑ سکتا ہے، ایجنٹ کو کمپیوٹ کے قریب رکھتے ہوئے اور کام کو جاری رکھتے ہوئے چاہے لیپ ٹاپ سلیپ ہو جائے یا منقطع ہو جائے، جبکہ پھر بھی مقامی طور پر لائیو اپ ڈیٹس اور کنٹرولز فراہم کرتا ہے.

صحیح پروٹوکول کا انتخاب

Codex ایپ سرور وہ اولین درجے کا انضمامی طریقہ ہوگا جسے ہم آئندہ برقرار رکھیں گے، لیکن کچھ دیگر طریقے بھی موجود ہیں جن کی فعالیت محدود ہے. پہلے سے طے شدہ طور پر، ہم تجویز کرتے ہیں کہ کلائنٹس Codex کے ساتھ انضمام کے لیے Codex ایپ سرور استعمال کریں، لیکن مختلف انضمامی طریقوں پر غور کرنا اور ان کے فوائد اور نقصانات کو سمجھنا بھی اہم ہے. ذیل میں Codex کو چلانے کے سب سے عام طریقے اور یہ کہ ہر ایک کب موزوں ہو سکتا ہے.

JSON-RPC پروٹوکولز

Codex کو ایک MCP سرور کے طور پر

codex mcp-سرور(نئی ونڈو میں کھلتا ہے) چلائیں اور کسی بھی MCP کلائنٹ سے جڑیں جو stdio سرورز کو سپورٹ کرتا ہو (مثال کے طور پر، OpenAI ایجنٹس SDK(نئی ونڈو میں کھلتا ہے)). یہ ایک اچھا انتخاب ہے اگر آپ کے پاس پہلے سے ہی MCP پر مبنی ورک فلو موجود ہے اور آپ Codex کو ایک قابلِ کال ٹول کے طور پر استعمال کرنا چاہتے ہیں. نقصان یہ ہے کہ آپ کو صرف وہی ملتا ہے جو MCP ظاہر کرتا ہے، لہذا Codex کے مخصوص تعاملات جو زیادہ بھرپور سیشن سیمنٹکس (مثلاً، diff اپڈیٹس) پر انحصار کرتے ہیں، ممکن ہے کہ MCP اینڈپوائنٹس کے ذریعے صاف طور پر میپ نہ ہوں.

کراس-پرووائیڈر ایجنٹ ہارنس پروٹوکولز

کچھ ایکوسسٹمز ایک قابلِ منتقلی انٹرفیس پیش کرتے ہیں جو متعدد ماڈل فراہم کنندگان اور رن ٹائمز کو نشانہ بنا سکتا ہے. اگر آپ ایک ایسی تجرید چاہتے ہیں جو متعدد ایجنٹس کو ہم آہنگ کرے، تو یہ ایک اچھا انتخاب ہو سکتا ہے. سمجھوتہ یہ ہے کہ یہ پروٹوکولز اکثر صلاحیتوں کے مشترکہ ذیلی مجموعے پر متفق ہو جاتے ہیں، جس سے زیادہ بھرپور تعاملات کی نمائندگی کرنا مشکل ہو سکتا ہے، خاص طور پر جب فراہم کنندہ کے مخصوص ٹول اور سیشن سیمنٹکس اہمیت رکھتے ہوں. یہ شعبہ تیزی سے ترقی کر رہا ہے اور ہمیں توقع ہے کہ جیسے جیسے ہم حقیقی دنیا کے ایجنٹ ورک فلو کی نمائندگی کے لیے بہترین بنیادی اجزاء سمجھتے جائیں گے، مزید عام معیارات سامنے آئیں گے (مہارتیں(نئی ونڈو میں کھلتا ہے) اس کی ایک اچھی مثال ہے).

Codex ایپ سرور

جب آپ مکمل Codex ہارنیس کو ایک مستحکم، UI-فرینڈلی ایونٹ اسٹریم کے طور پر ظاہر کرنا چاہتے ہیں تو ایپ سرور کا انتخاب کریں. آپ کو ایجنٹ لوپ کی مکمل فعالیت کے ساتھ ساتھ دیگر معاون خصوصیات بھی ملتی ہیں جیسے ChatGPT کے ساتھ سائن اِن، ماڈل دریافت اور کنفیگریشن مینجمنٹ. اصل لاگت انضمام کے کام کی ہے، کیونکہ آپ کو اپنی زبان میں کلائنٹ سائیڈ JSON-RPC بائنڈنگ بنانی ہوتی ہے. عملی طور پر، تاہم، Codex بہت سا مشکل کام خود کر سکتا ہے اگر آپ اسے JSON اسکیما اور دستاویزات فراہم کریں. ہم نے جن بہت سی ٹیموں کے ساتھ کام کیا، وہ Codex استعمال کرتے ہوئے تیزی سے ایک فعال انضمام بنانے میں کامیاب ہوئیں.

Codex کو شامل کرنے کے دیگر طریقے

ایک ہلکا پھلکا، اسکرپٹ کے قابل CLI موڈ جو ایک بار کے کاموں اور CI رنز کے لیے استعمال ہوتا ہے. یہ آٹومیشن اور پائپ لائنز کے لیے ایک اچھا انتخاب ہے جہاں آپ چاہتے ہیں کہ ایک ہی کمانڈ غیر تعاملی طور پر مکمل ہو، لاگز کے لیے اسٹرکچرڈ آؤٹ پٹس اسٹریم کرے اور واضح کامیابی یا ناکامی کے اشارے کے ساتھ خارج ہو.

آپ کی اپنی ایپلیکیشن کے اندر سے مقامی Codex ایجنٹس کو پروگرام کے ذریعے کنٹرول کرنے کے لیے ایک TypeScript لائبریری. یہ اس وقت بہترین ہے جب آپ سرور سائیڈ ٹولز اور ورک فلو کے لیے ایک مقامی لائبریری انٹرفیس چاہتے ہوں، بغیر ایک علیحدہ JSON-RPC کلائنٹ بنائے. چونکہ یہ ایپ سرور سے پہلے بھیجا گیا تھا، اس لیے فی الحال یہ کم زبانوں اور ایک چھوٹے سطحی دائرہ کار کو سپورٹ کرتا ہے. اگر ڈویلپرز کی دلچسپی ہو، تو ہم اضافی SDKs شامل کر سکتے ہیں جو ایپ سرور پروٹوکول کو ریپ کرتے ہیں تاکہ ٹیمیں JSON-RPC بائنڈنگز لکھے بغیر ہارنس کی سطح کے مزید حصے کو کور کر سکیں.

اسے آگے لے جانا

اس پوسٹ میں، ہم نے یہ بتایا کہ ہم ایجنٹس کے ساتھ تعامل کے لیے ایک نیا معیار کیسے ڈیزائن کرتے ہیں اور Codex ہارنس کو ایک مستحکم، کلائنٹ کے لیے موزوں پروٹوکول میں کیسے تبدیل کرتے ہیں. ہم نے یہ وضاحت کی کہ ایپ سرور کس طرح Codex کور کو ظاہر کرتا ہے، کلائنٹس کو مکمل ایجنٹ لوپ چلانے کی اجازت دیتا ہے اور TUI، مقامی IDE انٹیگریشنز اور ویب رن ٹائم سمیت مختلف سطحوں کو طاقت فراہم کرتا ہے.

اگر اس سے آپ کے اپنے ورک فلو میں Codex کو ضم کرنے کے لیے خیالات پیدا ہوئے ہیں، تو ایپ سرور کو آزمانا فائدہ مند ہوگا. تمام سورس کوڈ Codex CLI اوپن سورس ریپو(نئی ونڈو میں کھلتا ہے) میں موجود ہے. براہ کرم بلا جھجھک اپنا فیڈبیک اور فیچر کی رکوئسٹس کا اشتراک کریں. ہم آپ سے سننے کے لیے پُرجوش ہیں اور ایجنٹس کو ہر ایک کے لیے مزید قابل رسائی بنانے کے لیے کام جاری رکھیں گے.

مصنف

Celia Chen

اظہار تشکر

اس پوسٹ میں تعاون کرنے والے مائیکل بولن، اوون لن، ایرک ٹراٹ اور راسموس رائیگارڈ کا خصوصی شکریہ اور ایپ سرور پر کام کرنے والی پوری Codex ٹیم کا بھی شکریہ.

حاشیہ

  1. 1

    ہم "JSON‑RPC لائٹ" کی ایک قسم استعمال کرتے ہیں: یہ درخواست/جواب/اطلاع کی شکل کو برقرار رکھتا ہے، لیکن "jsonrpc": "2.0" کو خارج کرتا ہے ہیڈر اور اسے stdio پر JSONL کے طور پر فریم کیا گیا ہے، نہ کہ سخت JSON‑RPC 2.0 کے طور پر.

  2. 2

     "stdio" سے مراد کنٹینر کے اندر ایپ-سرور کا stdin/stdout ہے. ہوسٹ شدہ سیٹ اپس میں، وہ اسٹریمز اکثر ایک مستقل نیٹ ورک کنکشن (مثلاً، WebSocket-like) کے ذریعے کنٹینر رن ٹائم تک ٹنل کیے جاتے ہیں—اس لیے یہ stdio کی طرح برتاؤ کرتا ہے چاہے یہ لفظی طور پر کوئی لوکل پائپ نہ ہو.