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

۲۳ جنوری، ۲۰۲۶

انجینئرنگ

Codex ایجنٹ لوپ کو کھولنا

بطرف مائیکل بولن، تکنیکی عملے کا رکن

لوڈ ہو رہا ہے…

Codex CLI⁠(نئی ونڈو میں کھلتا ہے) ہمارا کراس-پلیٹ فارم مقامی سافٹ ویئر ایجنٹ ہے، جو آپ کی مشین پر محفوظ اور مؤثر طریقے سے کام کرتے ہوئے اعلٰی معیار کی، قابلِ اعتماد سافٹ ویئر تبدیلیاں پیدا کرنے کے لیے ڈیزائن کیا گیا ہے. جب سے ہم نے اپریل میں پہلی بار CLI لانچ کیا⁠ ہم نے عالمی معیار کا سافٹ ویئر ایجنٹ بنانے کے بارے میں بہت کچھ سیکھا ہے. ان بصیرتوں کو واضح کرنے کے لیے، یہ ایک جاری سلسلے کی پہلی پوسٹ ہے جس میں ہم Codex کے کام کرنے کے مختلف پہلوؤں اور محنت سے حاصل کردہ اسباق کو دریافت کریں گے. (Codex CLI کی تعمیر کے بارے میں مزید تفصیلی معلومات کے لیے، ہماری اوپن سورس ریپوزٹری https://github.com/openai/codex⁠(نئی ونڈو میں کھلتا ہے) پر دیکھیں. اگر آپ مزید جاننا چاہیں تو ہمارے ڈیزائن کے فیصلوں کی بہت سی نفیس تفصیلات GitHub کے مسائل اور پل درخواستوں میں محفوظ ہیں.

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

شروع کرنے سے پہلے، اصطلاحات کے بارے میں ایک مختصر نوٹ: OpenAI میں، "Codex" سافٹ ویئر ایجنٹ کی پیشکشوں کے ایک مجموعے کو شامل کرتا ہے، جس میں Codex CLI، Codex Cloud اور Codex VS Code ایکسٹینشن شامل ہیں. یہ پوسٹ Codex ہارنیس پر مرکوز ہے، جو بنیادی ایجنٹ لوپ اور عمل درآمد کی منطق فراہم کرتا ہے جو تمام Codex تجربات کی بنیاد ہے اور Codex CLI کے ذریعے ظاہر ہوتی ہے. آسانی کے لیے، ہم یہاں "Codex" اور "Codex CLI" کی اصطلاحات کو ایک دوسرے کے متبادل کے طور پر استعمال کریں گے.

ایجنٹ کا لوپ

ہر AI ایجنٹ کے مرکز میں ایک چیز ہوتی ہے جسے "ایجنٹ لوپ" کہا جاتا ہے. ایجنٹ لوپ کی ایک سادہ مثال کچھ ایسی دکھائی دیتی ہے:

"ایجنٹ لوپ" کے عنوان والا خاکہ، جو دکھاتا ہے کہ ایک AI سسٹم صارف کی درخواست کو کیسے پروسیس کرتا ہے، ٹولز کو کال کرتا ہے، نتائج کا مشاہدہ کرتا ہے، اپنے پلان کو اپ ڈیٹ کرتا ہے اور نتائج واپس کرتا ہے. تیر مراحل کو جوڑتے ہیں جیسے صارف کی ان پُٹ، ماڈل کی استدلال، ٹول کی کارروائیاں اور حتمی جواب.

شروع میں، ایجنٹ صارف سے ان پُٹ لیتا ہے تاکہ اسے ان متنی ہدایات کے مجموعے میں شامل کیا جا سکے جو وہ ماڈل کے لیے تیار کرتا ہے، جسے پرامپٹ کہا جاتا ہے.

اگلا مرحلہ یہ ہے کہ ماڈل سے استفسار کریں، اسے ہماری ہدایات بھیجیں اور اس سے جواب تیار کرنے کو کہیں، ایک عمل جسے استنباط کہا جاتا ہے. استنباط کے دوران، متنی پرامپٹ کو پہلے ان پُٹ ٹوکنز⁠(نئی ونڈو میں کھلتا ہے)کی ایک ترتیب میں تبدیل کیا جاتا ہے—ایسے اعداد جو ماڈل کی لغت میں انڈیکس کرتے ہیں. ان ٹوکنز کو ماڈل سے نمونہ لینے کے لیے استعمال کیا جاتا ہے، جس کے نتیجے میں آؤٹ پٹ ٹوکنز کی ایک نئی ترتیب پیدا ہوتی ہے.

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

استنباط مرحلے کے نتیجے کے طور پر، ماڈل یا تو (1) صارف کے اصل اِن پٹ کے لیے ایک حتمی جواب تیار کرتا ہے، یا (2) ایک ٹول کال کی درخواستیں کرتا ہے جسے ایجنٹ سے انجام دینے کی توقع کی جاتی ہے (مثال کے طور پر، "ls کو چلائیں اور آؤٹ پٹ رپورٹ کریں"). (2) کی صورت میں، ایجنٹ ٹول کال کو انجام دیتا ہے اور اس کے نتیجے کو اصل پرامپٹ کے ساتھ جوڑ دیتا ہے. یہ آؤٹ پٹ ایک نئی ان پُٹ تیار کرنے کے لیے استعمال ہوتا ہے جو ماڈل سے دوبارہ استفسار کرنے کے لیے استعمال ہوتی ہے؛ پھر ایجنٹ اس نئی معلومات کو مدنظر رکھ سکتا ہے اور دوبارہ کوشش کر سکتا ہے.

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

کیونکہ ایجنٹ ٹول کالز انجام دے سکتا ہے جو مقامی ماحول میں ترمیم کرتی ہیں، اس کا "آؤٹ پٹ" صرف معاون پیغام تک محدود نہیں ہے. بہت سے معاملات میں، سافٹ ویئر ایجنٹ کا بنیادی نتیجہ وہ کوڈ ہوتا ہے جو وہ آپ کی مشین پر لکھتا یا ترمیم کرتا ہے. اس کے باوجود، ہر باری ہمیشہ ایک معاون پیغام پر ختم ہوتی ہے—مثلاً "میں نے آپ کے کہنے پر architecture.md شامل کر دیا"—جو ایجنٹ لوپ میں اختتامی حالت کا اشارہ دیتا ہے. ایجنٹ کے نقطۂ نظر سے، اس کا کام مکمل ہو چکا ہے اور کنٹرول واپس صارف کے پاس آ جاتا ہے.

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

"ملٹی ٹرن ایجنٹ لوپ" کے عنوان والی ڈایاگرام یہ دکھاتا ہے کہ ایک AI ایجنٹ کس طرح بار بار صارف کی ان پُٹ لیتا ہے، کارروائیاں تیار کرتا ہے، ٹولز سے مشورہ کرتا ہے، حالت کو اپ ڈیٹ کرتا ہے اور نتائج واپس کرتا ہے. ایجنٹ کے استدلال چکر کی وضاحت کے لیے لیبل شدہ مراحل، تیر اور مثال کے طور پر ٹول کے نتائج شامل ہیں.

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

ماڈل انفیرنس

Codex CLI ماڈل استنباط کو چلانے کے لیے HTTP درخواستیں Responses API⁠(نئی ونڈو میں کھلتا ہے) کو بھیجتا ہے. ہم یہ دیکھیں گے کہ معلومات Codex کے ذریعے کیسے منتقل ہوتی ہیں، جو ایجنٹ لوپ کو چلانے کے لیے Responses API کا استعمال کرتا ہے.

Codex CLI جس Responses API اینڈپوائنٹ کو استعمال کرتا ہے وہ قابل ترتیب⁠(نئی ونڈو میں کھلتا ہے) ہے، اس لیے اسے کسی بھی ایسے اینڈپوائنٹ کے ساتھ استعمال کیا جا سکتا ہے جو Responses API کو نافذ کرتا ہے⁠(نئی ونڈو میں کھلتا ہے):

آئیے دریافت کریں کہ Codex گفتگو میں پہلی انفیرنس کال کے لیے پرامپٹ کیسے تیار کرتا ہے.

ابتدائی پرامپٹ بنانا

ایک حتمی صارف کے طور پر، جب آپ Responses API کو کوئری دیتے ہیں تو آپ ماڈل کو نمونہ کرنے کے لیے استعمال ہونے والی پرامپٹ کو لفظ بہ لفظ متعین نہیں کرتے ہیں. اس کے بجائے، آپ اپنی کوئری کے حصے کے طور پر مختلف ان پُٹ اقسام کی وضاحت کرتے ہیں اور Responses API سرور یہ فیصلہ کرتا ہے کہ اس معلومات کو ایک ایسی پرامپٹ میں کیسے ترتیب دیا جائے جسے ماڈل استعمال کرنے کے لیے ڈیزائن کیا گیا ہے. آپ پرامپٹ کو "اشیاء کی فہرست" کے طور پر تصور کر سکتے ہیں؛ یہ سیکشن وضاحت کرے گا کہ آپ کی کوئری اس فہرست میں کیسے تبدیل ہو جاتی ہے.

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

Responses API⁠(نئی ونڈو میں کھلتا ہے) ایک JSON پے لوڈ لیتا ہے جس میں کئی پیرامیٹرز شامل ہوتے ہیں. ہم ان تین پر توجہ مرکوز کریں گے:

Codex میں، ہدایات فیلڈ کو model_instructions_file⁠(نئی ونڈو میں کھلتا ہے) میں ~/.codex/config.toml سے پڑھا جاتا ہے، اگر مخصوص کیا جائے؛ بصورت دیگر، ماڈل کے ساتھ وابستہ base_instructions استعمال کیے جاتے ہیں⁠(نئی ونڈو میں کھلتا ہے). ماڈل کے لیے مخصوص ہدایات Codex ریپو میں موجود ہیں اور CLI میں شامل کی جاتی ہیں (مثال کے طور پر، gpt-5.2-codex_prompt.md⁠(نئی ونڈو میں کھلتا ہے)).

ٹولز فیلڈ ان ٹول تعریفوں کی ایک فہرست ہے جو Responses API کے ذریعے متعین کردہ اسکیما کے مطابق ہوتی ہیں. Codex کے لیے، اس میں وہ ٹولز شامل ہیں جو Codex CLI کے ذریعے فراہم کیے جاتے ہیں، وہ ٹولز جو Responses API کے ذریعے فراہم کیے جاتے ہیں جنہیں Codex کے لیے دستیاب ہونا چاہیے، نیز وہ ٹولز جو صارف فراہم کرتا ہے، عموماً MCP سرورز کے ذریعے:

JavaScript

1
[
2
  // Codex's default shell tool for spawning new processes locally.
3
  {
4
    "type": "function",
5
    "name": "shell",
6
    "description": "Runs a shell command and returns its output...",
7
    "strict": false,
8
    "parameters": {
9
      "type": "object",
10
      "properties": {
11
        "command": {"type": "array", "description": "The command to execute", ...},
12
        "workdir": {"description": "The working directory...", ...},
13
        "timeout_ms": {"description": "The timeout for the command...", ...},
14
        ...
15
      },
16
      "required": ["command"],
17
    }
18
  }
19

20
  // Codex's built-in plan tool.
21
  {
22
    "type": "function",
23
    "name": "update_plan",
24
    "description": "Updates the task plan...",
25
    "strict": false,
26
    "parameters": {
27
      "type": "object",
28
      "properties": {"plan":..., "explanation":...},
29
      "required": ["plan"]
30
    }
31
  },
32

33
  // Web search tool provided by the Responses API.
34
  {
35
    "type": "web_search",
36
    "external_web_access": false
37
  },
38

39
  // MCP server for getting weather as configured in the
40
  // user's ~/.codex/config.toml.
41
  {
42
    "type": "function",
43
    "name": "mcp__weather__get-forecast",
44
    "description": "Get weather alerts for a US state",
45
    "strict": false,
46
    "parameters": {
47
      "type": "object",
48
      "properties": {"latitude": {...}, "longitude": {...}},
49
      "required": ["latitude", "longitude"]
50
    }
51
  }
52
]

آخر میں، JSON پے لوڈ کی ان پُٹ فیلڈ آئٹمز کی ایک فہرست ہے. Codex درج ذیل آئٹمز داخل کرتا ہے⁠(نئی ونڈو میں کھلتا ہے) ان پُٹ میں صارف کا پیغام شامل کرنے سے پہلے:

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

یہ پیغام ایک ٹیمپلیٹ سے تیار کیا گیا ہے جہاں مواد کے کلیدی حصے Codex CLI میں شامل مارک ڈاؤن کے ٹکڑوں سے آتے ہیں، جیسے workspace_write.md⁠(نئی ونڈو میں کھلتا ہے) اور on_request.md⁠(نئی ونڈو میں کھلتا ہے):

سادہ متن

1
<permissions instructions>
2
  - description of the sandbox explaining file permissions and network access
3
  - instructions for when to ask the user for permissions to run a shell command
4
  - list of folders writable by Codex, if any
5
</permissions instructions>

2. (اختیاری) رول=ڈویلپر کے ساتھ ایک پیغام جس کے مواد صارف کی config.toml فائل سے پڑھی گئی developer_instructions کی قدر ہوں.

3. (اختیاری) کردار=صارف کے ساتھ ایک پیغام جس کے مندرجات "صارف کی ہدایات" ہیں، جو کسی ایک فائل سے ماخوذ نہیں ہیں بلکہ متعدد ذرائع سے یکجا کیے گئے ہیں⁠(نئی ونڈو میں کھلتا ہے). عمومی طور پر، زیادہ مخصوص ہدایات بعد میں آتی ہیں:

4. ایک پیغام جس میں کردار=صارف شامل ہو جو اس مقامی ماحول کی وضاحت کرتا ہے جس میں ایجنٹ اس وقت کام کر رہا ہے. یہ موجودہ ورکنگ ڈائریکٹری اور صارف کے شیل کی وضاحت کرتا ہے⁠(نئی ونڈو میں کھلتا ہے):

سادہ متن

1
<environment_context>
2
  <cwd>/Users/mbolin/code/codex5</cwd>
3
  <shell>zsh</shell>
4
</environment_context>

جب Codex ان پُٹ کو شروع کرنے کے لیے تمام مذکورہ حسابات مکمل کر لیتا ہے، تو یہ گفتگو کا آغاز کرنے کے لیے صارف کا پیغام شامل کرتا ہے.

پچھلی مثالیں ہر پیغام کے مواد پر مرکوز تھیں، لیکن نوٹ کریں کہ ان پُٹ کا ہر عنصر ایک JSON اوبجیکٹ ہے جس میں ٹائپ، رول⁠(نئی ونڈو میں کھلتا ہے) اور مندرجات درج ذیل ہیں:

JSON

1
{
2
  "type": "message",
3
  "role": "user",
4
  "content": [
5
    {
6
      "type": "input_text",
7
      "text": "Add an architecture diagram to the README.md"
8
    }
9
  ]
10
}

جب Codex مکمل JSON پے لوڈ تیار کر لیتا ہے تاکہ Responses API کو بھیجا جا سکے، تو یہ مجاز دہی ہیڈر کے ساتھ HTTP POST درخواست کرتا ہے، جو اس بات پر منحصر ہے کہ ~/.codex/config.toml میں Responses API اینڈپوائنٹ کو کیسے ترتیب دیا گیا ہے (اگر مخصوص کیا گیا ہو تو اضافی HTTP ہیڈرز اور کوئری پیرامیٹرز شامل کیے جاتے ہیں).

جب OpenAI Responses API سرور درخواست وصول کرتا ہے، تو وہ JSON کا استعمال کرتے ہوئے ماڈل کے لیے پرامپٹ کو درج ذیل طریقے سے اخذ کرتا ہے (یقیناً، Responses API کی ایک حسب ضرورت عمل درآمد مختلف انتخاب کر سکتی ہے):

AI ایجنٹ لوپ میں ایک واحد قدم دکھانے والا اسنیپ شاٹ ڈایاگرام. ایک صارف کی درخواست ماڈل میں داخل ہوتی ہے، جو ایک سوچ، ایک ٹول کے نام کے ساتھ ایک عمل اور ایک ٹول ان پُٹ پیدا کرتا ہے. ڈایاگرام ٹول کال ہونے سے پہلے اس درمیانی استدلال مرحلے کو نمایاں کرتا ہے.

جیسا کہ آپ دیکھ سکتے ہیں، پرامپٹ میں پہلے تین آئٹمز کی ترتیب کا تعین کلائنٹ نہیں بلکہ سرور کرتا ہے. اس کے باوجود، ان تین آئٹمز میں سے، صرف سسٹم میسج کا مواد سرور کے ذریعے کنٹرول کیا جاتا ہے، کیونکہ ٹولز اور ہدایات کا تعین کلائنٹ کرتا ہے. اس کے بعد JSON پے لوڈ سے ان پُٹ آتا ہے تاکہ پرامپٹ مکمل ہو سکے.

اب جب کہ ہمارے پاس اپنا پرامپٹ موجود ہے، ہم ماڈل کو نمونہ لینے کے لیے تیار ہیں.

پہلی باری

یہ HTTP درخواست Responses API کو Codex میں گفتگو کی پہلی "باری" کا آغاز کرتی ہے. سرور، سرور کے-بھیجے گئے ایونٹس (SSE⁠(نئی ونڈو میں کھلتا ہے)) اسٹریم کے ساتھ ردعمل/جواب دیتا ہے. ہر ایونٹ کا ڈیٹا ایک JSON پے لوڈ ہوتا ہے جس میں "type" شامل ہوتا ہے جو "ردعمل" سے شروع ہوتا ہے، جو کچھ اس طرح ہو سکتا ہے (ایونٹس کی مکمل فہرست ہماری API docs⁠(نئی ونڈو میں کھلتا ہے) میں دستیاب ہے):

سادہ متن

1
data: {"type":"response.reasoning_summary_text.delta","delta":"ah ", ...}
2
data: {"type":"response.reasoning_summary_text.delta","delta":"ha!", ...}
3
data: {"type":"response.reasoning_summary_text.done", "item_id":...}
4
data: {"type":"response.output_item.added", "item":{...}}
5
data: {"type":"response.output_text.delta", "delta":"forty-", ...}
6
data: {"type":"response.output_text.delta", "delta":"two!", ...}
7
data: {"type":"response.completed","response":{...}}

Codex ایونٹس کے سلسلے کو استعمال کرتا ہے⁠(نئی ونڈو میں کھلتا ہے) اور انہیں اندرونی ایونٹ آبجیکٹس کے طور پر دوبارہ شائع کرتا ہے جنہیں ایک کلائنٹ استعمال کر سکتا ہے. response.output_text.delta جیسے ایونٹس UI میں اسٹریمنگ کی سپورٹ کے لیے استعمال ہوتے ہیں، جبکہ response.output_item.added جیسے دیگر ایونٹس کو آبجیکٹس میں تبدیل کیا جاتا ہے جو بعد کی Responses API کالز کے لیے ان پُٹ میں شامل کیے جاتے ہیں.

فرض کریں کہ Responses API کی پہلی درخواست میں دو response.output_item.done ایونٹس شامل ہیں: ایک ٹائپ=استدلال کے ساتھ اور ایک type=function_call کے ساتھ. جب ہم ٹول کال کے جواب کے ساتھ ماڈل کو دوبارہ کوئری کرتے ہیں تو ان ایونٹس کو JSON کے ان پُٹ فیلڈ میں ظاہر کرنا ضروری ہے: 

JavaScript

1
[
2
  /* ... original 5 items from the input array ... */
3
  {
4
    "type": "reasoning",
5
    "summary": [
6
      "type": "summary_text",
7
      "text": "**Adding an architecture diagram for README.md**\n\nI need to..."
8
    ],
9
    "encrypted_content": "gAAAAABpaDWNMxMeLw..."
10
  },
11
  {
12
    "type": "function_call",
13
    "name": "shell",
14
    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",
15
    "call_id": "call_8675309..."
16
  },
17
  {
18
    "type": "function_call_output",
19
    "call_id": "call_8675309...",
20
    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."
21
  }
22
]

بعد کی کوئری کے حصے کے طور پر ماڈل سے نمونے لینے کے لیے استعمال ہونے والا نتیجہ خیز پرامپٹ کچھ اس طرح نظر آئے گا:

"سنیپ شاٹ 2" کے لیبل والا ڈایاگرام جو ایک ٹول کال کے بعد ایک AI ایجنٹ کو دکھا رہا ہے. ماڈل ایک آلہ کا مشاہدہ وصول کرتا ہے اور ایک نیا خیال اور عمل پیدا کرتا ہے. تیر ان پُٹس، مشاہدات اور آؤٹ پٹس کو جوڑتے ہیں تاکہ یہ دکھایا جا سکے کہ ایجنٹ اپنے استدلال لوپ میں کیسے تکرار کرتا ہے.

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

ایجنٹ لوپ کی پہلی ڈایاگرام پر نظر ڈالنے پر، ہم دیکھتے ہیں کہ انفیرنس اور ٹول کالنگ کے درمیان کئی تکرار ہو سکتی ہیں. پرامپٹ بڑھنا جاری رکھ سکتی ہے جب تک کہ ہمیں آخرکار ایک معاون پیغام موصول نہ ہو جائے، جو باری کے اختتام کی نشاندہی کرتا ہے:

سادہ متن

1
data: {"type":"response.output_text.done","text": "I added a diagram to explain...", ...}
2
data: {"type":"response.completed","response":{...}}

Codex CLI میں، ہم صارف کو اسسٹنٹ کا پیغام دکھاتے ہیں اور کمپوزر کو فوکس کرتے ہیں تاکہ صارف کو یہ نشاندہی کر سکیں کہ گفتگو جاری رکھنے کے لیے اب ان کی باری ہے. اگر صارف جواب دیتا ہے، تو پچھلی باری سے اسسٹنٹ کا پیغام اور صارف کا نیا پیغام دونوں کو Responses API درخواست میں ان پُٹ کے ساتھ نئی باری شروع کرنے کے لیے لازمی طور پر شامل کیا جانا چاہیے:

JavaScript

1
[
2
  /* ... all items from the last Responses API request ... */
3
  {
4
    "type": "message",
5
    "role": "assistant",
6
    "content": [
7
      {
8
        "type": "output_text",
9
        "text": "I added a diagram to explain the client/server architecture."
10
      }
11
    ]
12
  },
13
  {
14
    "type": "message",
15
    "role": "user",
16
    "content": [
17
      {
18
        "type": "input_text",
19
        "text": "That's not bad, but the diagram is missing the bike shed."
20
      }
21
    ]
22
  }
23
]

ایک بار پھر، چونکہ ہم گفتگو جاری رکھے ہوئے ہیں، جوابات API کو بھیجی جانے والی ان پُٹ طویل ہوتی جا رہی ہے:

"سنیپ شاٹ 3" کے لیبل والا ڈایاگرام جو AI ایجنٹ لوپ کے آخری مرحلے کو دکھا رہا ہے. ٹول کے نتائج موصول ہونے کے بعد، ماڈل ایک اختتامی خیال اور ایک حتمی جواب تیار کرتا ہے جو صارف کو واپس بھیجا جاتا ہے. تیر ٹول کے نتائج سے مکمل جواب تک منتقلی کی وضاحت کرتے ہیں.

آئیے دیکھتے ہیں کہ یہ مسلسل بڑھتی ہوئی پرامپٹ کارکردگی کے لحاظ سے کیا معنی رکھتی ہے.

کارکردگی کے تحفظات

آپ شاید اپنے آپ سے پوچھ رہے ہوں، "رکیں، کیا گفتگو کے دوران Responses API کو بھیجے گئے JSON کی مقدار کے لحاظ سے ایجنٹ لوپ کواڈریٹک نہیں ہے؟" اور آپ صحیح ہوں گے. اگرچہ Responses API اس مسئلے کو کم کرنے کے لیے ایک اختیاری previous_response_id⁠(نئی ونڈو میں کھلتا ہے) پیرامیٹر کی حمایت کرتا ہے، Codex آج اسے استعمال نہیں کرتا، بنیادی طور پر درخواستوں کو مکمل طور پر اسٹیٹ لیس رکھنے اور زیرو ڈیٹا ریٹینشن (ZDR) تشکیل کاریوں کی حمایت کرنے کے لیے.

previous_response_id سے گریز کرنا Responses API کے فراہم کنندہ کے لیے چیزوں کو آسان بناتا ہے کیونکہ یہ یقینی بناتا ہے کہ ہر درخواست بے حالت ہو. یہ بھی ان صارفین کی معاونت کو آسان بناتا ہے جنہوں نے زیرو ڈیٹا ریٹینشن (ZDR)⁠(نئی ونڈو میں کھلتا ہے) کا انتخاب کیا ہے، کیونکہ previous_response_id کی معاونت کے لیے درکار ڈیٹا کو محفوظ کرنا ZDR کے خلاف ہوگا. نوٹ کریں کہ ZDR کے صارفین پچھلے مراحل سے ملکیتی استدلال پیغامات سے فائدہ اٹھانے کی صلاحیت قربان نہیں کرتے، کیونکہ متعلقہ encrypted_content کو سرور پر ڈیکرپٹ کیا جا سکتا ہے. (OpenAI ایک ZDR کسٹمر کی ڈی کرپشن کلید محفوظ رکھتا ہے، لیکن ان کا ڈیٹا نہیں رکھتا.) ZDR کی حمایت کے لیے Codex میں متعلقہ تبدیلیوں کے لیے PRs #642⁠(نئی ونڈو میں کھلتا ہے) اور #1641⁠(نئی ونڈو میں کھلتا ہے) دیکھیں.

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

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

یہ بات ذہن میں رکھتے ہوئے، آئیے غور کریں کہ Codex میں کون سی کارروائیاں "کیشے مس" کا سبب بن سکتی ہیں:

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

Codex ٹیم کو Codex CLI میں نئی خصوصیات متعارف کراتے وقت مستعد رہنا چاہیے جو پرامپٹ کیشنگ کو متاثر کر سکتی ہیں. مثال کے طور پر، MCP ٹولز کے لیے ہماری ابتدائی سپورٹ میں ایک بگ سامنے آیا جہاں ہم ٹولز کو مستقل ترتیب میں شمار کرنے میں ناکام رہے⁠(نئی ونڈو میں کھلتا ہے)، جس کی وجہ سے کیشے مسز ہوئیں. نوٹ کریں کہ MCP ٹولز خاص طور پر مشکل ہو سکتے ہیں کیونکہ MCP سرورز notifications/tools/list_changed⁠(نئی ونڈو میں کھلتا ہے) نوٹیفکیشن کے ذریعے فوری طور پر اپنے فراہم کردہ ٹولز کی فہرست تبدیل کر سکتے ہیں. ایک طویل گفتگو کے دوران اس نوٹیفکیشن کی تعمیل کرنا مہنگے کیشے مس کا سبب بن سکتا ہے.

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

  • اگر سینڈ باکس کنفیگریشن یا منظوری موڈ تبدیل ہو جائے، تو ہم ⁠(نئی ونڈو میں کھلتا ہے) ایک نیا role=developer پیغام داخل کریں گے جو اسی فارمیٹ میں ہو گا جیسے کہ <permissions instructions> آئٹم تھا.
  • اگر موجودہ ورکنگ ڈائریکٹری تبدیل ہو جائے، تو ہم درج کرتے ہیں⁠(نئی ونڈو میں کھلتا ہے) ایک نیا role=user پیغام اسی فارمیٹ کے ساتھ جیسے اصل <environment_context>.

ہم کارکردگی کے لیے کیشے ہٹس کو یقینی بنانے کے لیے بہت زیادہ محنت کرتے ہیں. ایک اور کلیدی وسیلہ ہے جسے ہمیں منظم کرنا ہے: سیاق و سباق ونڈو.

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

تب سے، Responses API نے ایک خاص /responses/compact اینڈپوائنٹ⁠(نئی ونڈو میں کھلتا ہے) کی حمایت کرنے کے لیے ترقی کی ہے جو کمپیکشن کو زیادہ مؤثر طریقے سے انجام دیتا ہے. یہ آئٹمز کی ایک فہرست⁠(نئی ونڈو میں کھلتا ہے) واپس کرتا ہے جسے پچھلی ان پُٹ کی جگہ استعمال کیا جا سکتا ہے تاکہ سیاق و سباق ونڈو کو خالی کرتے ہوئے گفتگو جاری رکھی جا سکے. اس فہرست میں ایک خاص ٹائپ=کمپیکشن آئٹم شامل ہے جس میں ایک غیر شفاف encrypted_content آئٹم ہے جو اصل گفتگو کے بارے میں ماڈل کی پوشیدہ سمجھ کو محفوظ رکھتا ہے. اب، Codex خود بخود اس اینڈپوائنٹ کا استعمال کرتا ہے تاکہ گفتگو کو مختصر کر سکے جب auto_compact_limit⁠(نئی ونڈو میں کھلتا ہے) سے تجاوز ہو جائے.

کیا آنے والا ہے

ہم نے Codex ایجنٹ لوپ کا تعارف کرایا ہے اور یہ وضاحت کی ہے کہ Codex ماڈل سے استفسار کرتے وقت اپنے سیاق و سباق کو کیسے تیار کرتا اور منظم کرتا ہے. راستے میں، ہم نے عملی پہلوؤں اور بہترین عملی طریقوں کو اجاگر کیا جو Responses API کے اوپر ایک ایجنٹ لوپ بنانے والے ہر شخص پر لاگو ہوتے ہیں.

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

مصنف

Michael Bolin

تسلیمات

Codex CLI بنانے والی پوری ٹیم کا خصوصی شکریہ.

پڑھتے رہیں

سب دیکھیں
Tax Agent > Art Card
Codex کے ساتھ خود بہتر ہونے والے ٹیکس ایجنٹس بنانا

انجینئرنگ

codex windows > art card
Windows پر Codex کو فعال کرنے کے لیے ایک محفوظ, مؤثر سینڈ باکس بنانا

انجینئرنگ

MRC 1_1
گوبلنز کہاں سے آئے

انجینئرنگ