OpenAI Codex CLI के आंतरिक कामकाज का विश्लेषण: एजेंट लूप और प्रॉम्प्ट कैशिंग रणनीति

सारांश:

• एजेंट लूप (Agent Loop) की संरचना: यह विस्तार से बताता है कि Codex CLI उपयोगकर्ता इनपुट, मॉडल inference, और tool execution को समन्वित करके वास्तविक काम कैसे पूरा करता है।
• प्रॉम्प्ट संरचना और Responses API: यह विश्लेषण करता है कि system instructions, tool definitions, और local environment context किस तरह Responses API के JSON payload में बदलते हैं और डेटा फ्लो कैसे चलता है।
• परफ़ॉर्मेंस ऑप्टिमाइज़ेशन और state management: इसमें Prompt Caching को अधिकतम करने की रणनीतियाँ, context window सीमा को पार करने के लिए conversation compaction तकनीक, और ZDR (Zero Data Retention) के लिए stateless design principles शामिल हैं।

विस्तृत सारांश:
OpenAI engineering team ने local software agent Codex CLI की core logic, यानी 'Agent Loop', के काम करने के तरीके का गहन तकनीकी विश्लेषण प्रकाशित किया है। यह लेख तकनीकी दृष्टिकोण से पूरे lifecycle को समझाता है, जिसमें उपयोगकर्ता के command को लेना, मॉडल के साथ इंटरैक्ट करना, tools चलाना, और परिणाम लौटाना शामिल है।

1. एजेंट लूप (The Agent Loop)

एजेंट लूप एक cyclical structure है जो उपयोगकर्ता इनपुट लेकर task पूरा होने तक मॉडल के साथ लगातार interaction करता है।

• प्रक्रिया: उपयोगकर्ता इनपुट -> प्रॉम्प्ट निर्माण -> मॉडल inference -> (tool call request -> tool execution -> result attach -> re-inference) दोहराव -> अंतिम response।
• टर्न (Turn): उपयोगकर्ता इनपुट से लेकर मॉडल द्वारा अंततः उपयोगकर्ता को message (Assistant Message) भेजने तक की पूरी प्रक्रिया को एक 'turn' कहा जाता है। इस दौरान एजेंट सैकड़ों tool calls कर सकता है, जैसे ls चलाना या फ़ाइल संपादित करना।

2. मॉडल inference और Responses API

Codex CLI Responses API के माध्यम से मॉडल से संवाद करता है। इस API को https://chatgpt.com/backend-api/codex/responses, https://api.openai.com/v1/responses, या localhost (जैसे Ollama) पर कॉन्फ़िगर किया जा सकता है।

शुरुआती प्रॉम्प्ट बनाना (Building the Initial Prompt)

प्रॉम्प्ट केवल साधारण text नहीं है, बल्कि instructions, tools, input आदि से बना structured data है।

• Instructions: system या developer messages, जो मॉडल के व्यवहार के लिए निर्देश तय करते हैं। (उदाहरण: ~/.codex/config.toml configuration file देखें)
• Tools: उन tools की definition list जिन्हें मॉडल उपयोग कर सकता है। इसमें shell execution, योजना अपडेट (update_plan), web search, और custom MCP (Model Context Protocol) server tools शामिल हैं।
• Input: मॉडल को भेजी जाने वाली वास्तविक data list। इसमें sandbox permission settings, project-specific instructions, और environment context जैसे current working directory (cwd) तथा shell type शामिल हैं।

JSON payload उदाहरण:

{  
  "type": "message",  
  "role": "user",  
  "content": [  
    {  
      "type": "input_text",  
      "text": "README.md에 아키텍처 다이어그램을 추가해줘"  
    }  
  ]  
  // ... पहले से परिभाषित environment context और permission settings भी साथ भेजी जाती हैं  
}  
  

3. tool execution और data flow

जब मॉडल tool call (Function Call) का अनुरोध करता है, तो एजेंट उसे चलाता है, उसका परिणाम conversation history में जोड़ता है, और फिर मॉडल को दोबारा कॉल करता है।

tool execution के बाद re-request JSON उदाहरण:

[  
  /* ... previous input items ... */  
  {  
    "type": "reasoning", // मॉडल की reasoning process (CoT)  
    "summary": [...],  
    "encrypted_content": "gAAAAABpaDW..." // encrypted reasoning content  
  },  
  {  
    "type": "function_call",  
    "name": "shell",  
    "arguments": "{\"command\":\"cat README.md\",\"workdir\":\"/Users/mbolin/code/codex5\"}",  
    "call_id": "call_8675309..."  
  },  
  {  
    "type": "function_call_output", // tool execution result  
    "call_id": "call_8675309...",  
    "output": "<p align=\"center\"><code>npm i -g @openai/codex</code>..."  
  }  
]  
  

यह सुनिश्चित करना महत्वपूर्ण है कि पिछला प्रॉम्प्ट नए प्रॉम्प्ट का सटीक prefix बना रहे। इसी पर आगे बताए गए prompt caching की दक्षता निर्भर करती है।

4. परफ़ॉर्मेंस विचार: caching और ZDR

जैसे-जैसे conversation लंबी होती जाती है, प्रॉम्प्ट का आकार linear रूप से बढ़ता है, जिससे cost और latency दोनों बढ़ते हैं।

• Prompt Caching: OpenAI models तब पहले की computation reuse करके speed बढ़ाते हैं जब प्रॉम्प्ट का शुरुआती हिस्सा मेल खाता हो (Prefix Match)।

• Cache Miss रोकना: अगर tool list या sandbox settings जैसी चीज़ें बातचीत के बीच बदलती हैं, तो cache टूट सकता है। इससे बचने के लिए Codex मौजूदा message को edit करने के बजाय नया message append करने का तरीका अपनाता है।

• Stateless और ZDR: previous_response_id जैसे parameters का उपयोग करने के बजाय हर बार पूरा context भेजा जाता है। इसका उद्देश्य सर्वर पर डेटा स्टोर किए बिना Zero Data Retention (ZDR) नीति का पालन करना है। encrypted reasoning content (encrypted_content) को client द्वारा वापस सर्वर को भेजने की पद्धति के माध्यम से, सर्वर state स्टोर किए बिना भी पिछला reasoning context पुनर्स्थापित कर सकता है।

5. context window प्रबंधन (Compaction)

token limit के भीतर रहने के लिए Codex /responses/compact endpoint का उपयोग करके conversation history को compress करता है। यह केवल साधारण summary नहीं बनाता, बल्कि encrypted_content को संरक्षित रखने वाली compressed item list लौटाता है, जो मॉडल की latent understanding को बचाए रखते हुए पुराने input को replace कर देती है।