ప్రధాన కంటెంట్‌కి దాటండి
OpenAI

23 జనవరి, 2026

ఇంజనీరింగ్

Codex ఏజెంట్ లూప్‌ను అన్‌రోల్ చేయడం

మైఖేల్ బోలిన్, సాంకేతిక సిబ్బంది సభ్యుడు

లోడ్ అవుతోంది…

Codex CLI⁠(కొత్త విండోలో తెరుచుకుంటుంది) మా క్రాస్-ప్లాట్‌ఫారం లోకల్ సాఫ్ట్‌వేర్ ఏజెంట్, ఇది మీ యంత్రంపై సురక్షితంగా మరియు సమర్థవంతంగా పనిచేస్తూ, అధిక నాణ్యత గల, నమ్మకమైన సాఫ్ట్‌వేర్ మార్పులను ఉత్పత్తి చేసేందుకు రూపొందించబడింది. మేం ఏప్రిల్‌లో CLI ని మొదట ప్రారంభించినప్పటి నుండి⁠, ప్రపంచ స్థాయి సాఫ్ట్‌వేర్ ఏజెంట్‌ను ఎలా నిర్మించాలనేది మేం చాలా నేర్చుకున్నాం. ఆ అవలోకనాలను విప్పడానికి, Codex ఎలా పనిచేస్తుందనే దాని గురించి వివిధ అంశాలను, అలాగే కష్టపడి సంపాదించిన పాఠాలను అన్వేషిస్తున్న కొనసాగుతున్న సిరీస్‌లో ఇది మొదటి పోస్ట్. (Codex CLI ఎలా నిర్మించబడిందనే దానిపై మరింత వివరణాత్మక వీక్షణ కోసం, మా రిపోజిటరీని https://github.com/openai/codex⁠(కొత్త విండోలో తెరుచుకుంటుంది) వద్ద చూడండి. మా డిజైన్ నిర్ణయాల చాలా సూక్ష్మ వివరాలు GitHub సంచికలలో జ్ఞాపకం చేయబడ్డాయి మరియు మీరు మరింత తెలుసుకోవాలనుకుంటే అభ్యర్థనలను చూడండి.)

ముందుగా, మనం ఏజెంట్ లూప్‌పై దృష్టి పెడదాం, ఇది కోడెక్స్ CLIలోని ప్రధాన తర్కం, ఇది వినియోగదారు, మోడల్ మరియు అర్థవంతమైన సాఫ్ట్‌వేర్ పనిని నిర్వహించడానికి మోడల్ ఉపయోగించే సాధనాల మధ్య పరస్పర చర్యను సమన్వయం చేయడానికి బాధ్యత వహిస్తుంది. LLMని ఉపయోగించడంలో మా ఏజెంట్ (లేదా "హార్నెస్") పోషించే పాత్ర గురించి ఈ పోస్ట్ మీకు మంచి అవగాహన కల్పిస్తుందని మేం ఆశిస్తున్నాం.

మనం లోతుగా ప్రవేశించే ముందు, పదజాలంపై ఒక చిన్న గమనిక: OpenAIలో, “Codex” అనేది Codex CLI, Codex Cloud, మరియు Codex VS Code ఎక్స్‌టెన్షన్ వంటి సాఫ్ట్‌వేర్ ఏజెంట్ ఆఫరింగ్‌ల సూట్‌ను సూచిస్తుంది. ఈ పోస్ట్ Codex హార్నెస్‌పై దృష్టి పెడుతుంది, ఇది అన్ని Codex అనుభవాలకు ఆధారం అయ్యే మరియు కోడెక్స్ CLI ద్వారా కనిపించే కోర్ ఏజెంట్ లూప్ మరియు ఎగ్జిక్యూషన్ లాజిక్ అందిస్తుంది. ఇక్కడ సౌలభ్యం కోసం, “Codex” మరియు “Codex CLI” అనే పదాలను పరస్పర మార్పిడి చేసుకుని ఉపయోగిస్తాం.

ఏజెంట్ లూప్

ప్రతి AI ఏజెంట్ కేంద్రంలో “ఏజెంట్ లూప్” అని పిలవబడేది ఉంటుంది. ఏజెంట్ లూప్ సరళీకృత దృశ్యం ఇలా ఉంటుంది:

“ఏజెంట్ లూప్” అనే శీర్షిక ఉన్న డయాగ్రామ్, AI సిస్టమ్ యూజర్ అభ్యర్థనను ఎలా ప్రాసెస్ చేస్తుంది, టూల్స్‌ను ఎలా కాల్ చేస్తుంది, ఫలితాలను ఎలా పరిశీలిస్తుంది, తన ప్లాన్‌ను ఎలా అప్‌డేట్ చేస్తుంది, అవుట్‌పుట్‌ను ఎలా తిరిగి ఇస్తుందో చూపిస్తుంది. బాణాలు యూజర్ ఇన్‌పుట్, మోడల్ రీజనింగ్, సాధన చర్యలు, మరియు తుది ప్రతిస్పందన వంటి దశలు అనుసంధానిస్తాయి.

ప్రారంభించడానికి, ఏజెంట్ మోడల్ కోసం సిద్ధం చేసే టెక్ట్సువల్ సూచనల సమితిలో చేర్చడానికి యూజర్ నుండి ఇన్‌పుట్‌ను తీసుకుంటుంది, దీనిని ప్రాంప్ట్ అని పిలుస్తారు.

తదుపరి దశ ఏమిటంటే, మన సూచనలను పంపడం ద్వారా మోడల్‌ను ప్రశ్నించడం మరియు ప్రతిస్పందనను రూపొందించమని అడగడం, ఈ ప్రక్రియను ఇన్‌ఫరెన్స్ అని అంటారు. ఇన్‌ఫరెన్స్ సమయంలో, టెక్ట్యువల్ ప్రాంప్ట్‌ను ముందుగా ఇన్‌పుట్ టోకెన్‌లు⁠(కొత్త విండోలో తెరుచుకుంటుంది)గా అనువదిస్తారు—ఇవి మోడల్ పదకోశంలో ఇండెక్స్ చేసే పూర్ణసంఖ్యల శ్రేణి. ఈ టోకెన్‌లను తరువాత మోడల్‌ను శాంపిల్ చేయడానికి ఉపయోగిస్తారు, తద్వారా కొత్త అవుట్‌పుట్ టోకెన్‌ల క్రమాన్ని ఉత్పత్తి చేస్తారు.

అవుట్‌పుట్ టోకెన్‌లు మళ్లీ టెక్ట్స్‌గా అనువదించబడతాయి, అవి మోడల్ ప్రతిస్పందనగా మారుతుంది. టోకెన్‌లు క్రమంగా ఉత్పత్తి అవుతాయి కాబట్టి, మోడల్ రన్ అయ్యేటప్పుడు ఈ అనువాదం జరగవచ్చు, అందువల్ల అనేక LLM ఆధారిత అప్లికేషన్‌లు స్ట్రీమింగ్ అవుట్‌పుట్‌ను ప్రదర్శిస్తాయి. ప్రయోగంలో, ఇన్‌ఫరెన్స్ సాధారణంగా టెక్ట్స్‌పై పనిచేసే API వెనుక సంగ్రహించబడుతుంది, టోకనైజేషన్ వివరాలను దాచిపెడుతుంది.

ఇన్‌ఫరెన్స్ దశ ఫలితంగా, మోడల్ (1) యూజర్ అసలు ఇన్‌పుట్‌కు తుది ప్రతిస్పందనను ఇస్తుంది, లేదా (2) ఏజెంట్ చేయాల్సిందిగా భావించే టూల్ కాల్ను అభ్యర్థిస్తుంది (ఉదాహరణకు, “ls రన్ చేయండి మరియు అవుట్‌పుట్‌ను నివేదించండి”). (2) విషయంలో, ఏజెంట్ టూల్ కాల్‌ను అమలు చేసి, దాని అవుట్‌పుట్‌ను అసలు ప్రాంప్ట్‌కు జోడిస్తుంది. ఈ అవుట్‌పుట్‌ను కొత్త ఇన్‌పుట్‌ను సృష్టించడానికి ఉపయోగిస్తారు, ఇది మోడల్‌ను మళ్లీ ప్రశ్నించడానికి ఉపయోగించబడుతుంది; ఆ తర్వాత ఏజెంట్ ఈ కొత్త సమాచారాన్ని పరిగణనలోకి తీసుకుని మళ్లీ ప్రయత్నించవచ్చు.

ఈ ప్రక్రియ మోడల్ టూల్ కాల్స్‌ను విడుదల చేయడం ఆపి, బదులుగా వినియోగదారునికి ఒక సందేశాన్ని సృష్టించే వరకు పునరావృతమవుతుంది (OpenAI మోడల్స్‌లో దీనిని అసిస్టెంట్ సందేశం అని పిలుస్తారు). చాలా సందర్భాల్లో, ఈ సందేశం వినియోగదారుడి అసలు అభ్యర్థనకు నేరుగా సమాధానం ఇస్తుంది, కానీ ఇది వినియోగదారుడికి ఒక ఫాలోప్ ప్రశ్న కూడా కావచ్చు.

ఏజెంట్ లోకల్ ఎన్విరాన్‌మెంట్‌ను మార్చే టూల్ కాల్స్‌ను అమలు చేయగలిగే కారణంగా, దాని “అవుట్‌పుట్” అసిస్టెంట్ మెసేజ్‌కే పరిమితం కాదు. చాలా సందర్భాల్లో, సాఫ్ట్‌వేర్ ఏజెంట్ ప్రధాన అవుట్‌పుట్ మీ కంప్యూటర్‌పై అది రాసే లేదా సవరించే కోడ్. అయినప్పటికీ, ప్రతి టర్న్ ఎప్పుడూ ఒక అసిస్టెంట్ సందేశంతో ముగుస్తుంది—ఉదాహరణకు “మీరు అడిగిన architecture.md ను నేను జోడించాను”—ఇది ఏజెంట్ లూప్‌లో ఒక ముగింపు స్థితిని సూచిస్తుంది. ఏజెంట్ దృష్టికోణం నుండి, దాని పని పూర్తయింది మరియు నియంత్రణ వినియోగదారునికి తిరిగి వస్తుంది.

డయాగ్రామ్‌లో చూపించినట్లుగా యూజర్ ఇన్‌పుట్ నుండి ఏజెంట్ రెస్పాన్స్ వరకు ఉన్న ప్రయాణాన్ని సంభాషణలో ఒక టర్న్గా (Codex‌లో ఒక థ్రెడ్) పిలుస్తారు. ఈ సంభాషణ టర్న్ అనేక సార్లు మోడల్ ఇన్‌ఫరెన్స్ మరియు టూల్ కాల్స్ మధ్య పునరావృతం కావచ్చు. మీరు ఇప్పటికే ఉన్న సంభాషణకు ప్రతి సారి కొత్త సందేశం పంపినప్పుడు, ఆ సంభాషణ చరిత్ర కొత్త టర్న్ కోసం ప్రాంప్ట్‌లో భాగంగా చేర్చబడుతుంది, ఇందులో గత టర్న్‌ల నుండి సందేశాలు మరియు టూల్ కాల్స్ ఉంటాయి:

“మల్టీ-టర్న్ ఏజెంట్ లూప్” అనే శీర్షికతో ఉన్న డయాగ్రామ్: AI ఏజెంట్ యూజర్ ఇన్‌పుట్‌ను పునరావృతంగా తీసుకుని, చర్యలను రూపొందించి, సాధనాలను సంప్రదించి, స్థితిని అప్‌డేట్ చేసి, ఫలితాలను తిరిగి ఇస్తుందని చూపిస్తుంది. ఏజెంట్ రీజనింగ్ సైకిల్‌ను వివరించే లేబుల్ చేసిన దశలు, బాణాలు, ఉదాహరణ టూల్ అవుట్‌పుట్‌లు ఉంటాయి.

అంటే సంభాషణ పెరుగుతున్న కొద్దీ, మోడల్‌ను నమూనా చేయడానికి ఉపయోగించే ప్రాంప్ట్ పొడవు కూడా పెరుగుతుందని దీని అర్థం. ఈ పొడవు ముఖ్యం ఎందుకంటే ప్రతి మోడల్‌కు కాంటెక్స్ట్ విండో ఉంటుంది, ఇది ఒక ఇన్‌ఫరెన్స్ కాల్ కోసం ఉపయోగించగల గరిష్ట టోకెన్‌ల సంఖ్య. గమనిక: ఈ విండోలో ఇన్‌పుట్ మరియు అవుట్‌పుట్ టోకెన్లు రెండూ ఉంటాయి. మీరు ఊహించినట్లుగా, ఒక ఏజెంట్ ఒకే టర్న్‌లో వందలాది టూల్ కాల్స్ చేయాలని నిర్ణయించవచ్చు, దాంతో కాంటెక్ట్స్ విండో పూర్తిగా ఖాళీ కావచ్చు. ఈ కారణంగా, కాంటెక్ట్స్ విండో నిర్వహణ ఏజెంట్ అనేక బాధ్యతల్లో ఒకటి. ఇప్పుడు, Codex ఏజెంట్ లూప్‌ను ఎలా రన్ చేస్తుందో లోతుగా పరిశీలిద్దాం.

మోడల్ ఇన్‌ఫరెన్స్

మోడల్ ఇన్‌ఫెరన్స్‌ను అమలు చేయడానికి Codex CLI ప్రతిస్పందనల API⁠(కొత్త విండోలో తెరుచుకుంటుంది) కి HTTP అభ్యర్థనలను పంపుతుంది. మేం Codex ద్వారా సమాచారం ఎలా ప్రవహిస్తుందో పరిశీలిస్తాం, ఇది ఏజెంట్ లూప్‌ను నడిపించడానికి ప్రతిస్పందనల APIని ఉపయోగిస్తుంది.

Codex CLI ఉపయోగించే ప్రతిస్పందనల API ఎండ్‌పాయింట్ కాన్ఫిగర్ చేయవచ్చు⁠(కొత్త విండోలో తెరుచుకుంటుంది), కాబట్టి ప్రతిస్పందనల APIని అమలు చేసే⁠(కొత్త విండోలో తెరుచుకుంటుంది) ఏ ఎండ్‌పాయింట్‌తోనైనా దీన్ని ఉపయోగించవచ్చు:

Codex సంభాషణలో మొదటి ఇన్‌ఫరెన్స్ కాల్ కోసం ప్రాంప్ట్‌ను ఎలా సృష్టిస్తుందనేది చూద్దాం.

ప్రారంభ ప్రాంప్ట్‌ను సృష్టించడం

తుది వినియోగదారుగా, మీరు ప్రతిస్పందనల APIని ప్రశ్నించినప్పుడు మోడల్‌ను యథాతథంగా నమూనా చేయడానికి ఉపయోగించే ప్రాంప్ట్‌ను మీరు పేర్కొనరు. బదులుగా, మీరు మీ క్వెరీలో వివిధ ఇన్‌పుట్ రకాల్ని పేర్కొంటారు, మరియు Responses API సర్వర్ ఈ సమాచారాన్ని మోడల్ వినియోగించడానికి రూపొందించిన ప్రాంప్ట్‌గా ఎలా నిర్మించాలో నిర్ణయిస్తుంది. నువ్వు ప్రాంప్ట్‌ను “అంశాల జాబితా”గా ఊహించవచ్చు; ఈ విభాగం మీ ప్రశ్న ఆ జాబితాగా ఎలా మారుతుందని వివరిస్తుంది.

ప్రారంభ ప్రాంప్ట్‌లో, జాబితాలోని ప్రతి అంశం ఒక పాత్రతో అనుబంధించి ఉంటుంది. రోల్ సంబంధిత కంటెంట్‌కు ఎంత ప్రాముఖ్యత ఉండాలనేది సూచిస్తుంది మరియు ఇది క్రింది విలువల్లో ఒకటి (ప్రాధాన్యత తగ్గే క్రమంలో): సిస్టమ్, డెవలపర్r, యూజర్, అసిస్టెంట్.

ప్రతిస్పందనల API⁠(కొత్త విండోలో తెరుచుకుంటుంది) అనేక పరామితులతో కూడిన JSON పేలోడ్‌ను తీసుకుంటుంది. మనం ఈ మూడు విషయాలపై దృష్టి సారిస్తాం:

Codexలో, instructions ఫీల్డ్‌ను, అది పేర్కొనబడినట్లయితే, model_instructions_file⁠(కొత్త విండోలో తెరుచుకుంటుంది) లోని ~/.codex/config.toml నుండి చదవబడుతుంది; లేకపోతే, మోడల్‌కు అనుబంధంగా ఉన్న base_instructions ఉపయోగించబడతాయి⁠(కొత్త విండోలో తెరుచుకుంటుంది). మోడల్-స్పెసిఫిక్ సూచనలు Codex repoలో ఉంటాయి మరియు CLIలో బండిల్ చేయబడతాయి (ఉదా., gpt-5.2-codex_prompt.md⁠(కొత్త విండోలో తెరుచుకుంటుంది)).

టూల్స్ ఫీల్డ్ అనేది ప్రతిస్పందనల API ద్వారా నిర్వచించబడిన స్కీమాకు అనుగుణంగా ఉండే టూల్ నిర్వచనాల జాబితా. Codex కోసం, ఇందులో Codex CLI ద్వారా అందించే సాధనాలు, Codex కు అందుబాటులో చేయాల్సిన Responses API ద్వారా అందించబడే సాధనాలు, అలాగే యూజర్ అందించే సాధనాలు (సాధారణంగా 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 పేలోడ్‌లోని input ఫీల్డ్ ఐటమ్‌ల జాబితాగా ఉంటుంది. వినియోగదారు సందేశాన్ని జోడించే ముందు కోడెక్స్ కింది అంశాలను⁠(కొత్త విండోలో తెరుచుకుంటుంది) ఇన్‌పుట్ చొప్పిస్తుంది:

1. tools విభాగంలో నిర్వచించిన కోడెక్స్ అందించిన shell టూల్‌కు మాత్రమే వర్తించే శాండ్‌బాక్స్‌ను వివరించే role=developer తో కూడిన సందేశం. అంటే, MCP సర్వర్ల నుండి అందించబడే ఇతర సాధనాలు Codex ద్వారా సాండ్‌బాక్స్ చేయబడవు మరియు తమ స్వంత గార్డ్‌రైల్స్‌ను అమలు చేయడానికి బాధ్యత వహిస్తాయి.

సందేశం ఒక టెంప్లేట్ నుండి రూపొందించబడింది, ఇందులో ముఖ్యమైన కంటెంట్ భాగాలు Codex CLIలో బండిల్ చేయబడిన Markdown స్నిపెట్‌ల నుండి వస్తాయి, ఉదాహరణకు 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 విలువ కలిగిన role=developerతో ఒక సందేశం.

3. (ఐచ్ఛికం) role=user తో ఉన్న ఒక సందేశం, దాని కంటెంట్ “యూజర్ సూచనలు,” ఇవి ఒకే ఫైల్ నుండి తీసుకోబడినవి కాదు, కానీ అనేక మూలాల నుండి సమీకరించబడినవి⁠(కొత్త విండోలో తెరుచుకుంటుంది). సాధారణంగా, మరింత నిర్ధిష్టమైన సూచనలు తరువాత కనిపిస్తాయి:

4. ఏజెంట్ ప్రస్తుతం పనిచేస్తున్న స్థానిక వాతావరణాన్ని వివరిస్తున్న role=user తో ఒక సందేశం. ఇది ప్రస్తుత వర్కింగ్ డైరెక్టరీ మరియు వినియోగదారుని షెల్‌ను నిర్దేశిస్తుంది⁠(కొత్త విండోలో తెరుచుకుంటుంది):

ప్లెయిన్ టెక్స్ట్

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 ప్రతిస్పందనల APIకి పంపడానికి పూర్తి JSON పేలోడ్‌ను నిర్మించిన తర్వాత, అది ~/.codex/config.toml లో ప్రతిస్పందనల API ఎండ్‌పాయింట్ ఎలా కాన్ఫిగర్ చేయబడిందనే దానిపై ఆధారపడి ఆథరైజేషన్ హెడ్డర్‌తో HTTP పోస్ట్ అభ్యర్ధిస్తుంది (పేర్కొంటే అదనపు HTTP హెడర్‌లు మరియు ప్రశ్న పరామితులు జోడించబడతాయి).

OpenAI ప్రతిస్పందనల API సర్వర్ అభ్యర్థనను స్వీకరించినప్పుడు, అది మోడల్ కోసం ప్రాంప్ట్‌ను ఈ క్రింది విధంగా పొందేందుకు JSONని ఉపయోగిస్తుంది (ఖచ్చితంగా, ప్రతిస్పందనల API కస్టమ్ అమలు వేరే ఎంపిక చేయవచ్చు):

AI ఏజెంట్ లూప్‌లో ఒకే దశను చూపించే స్నాప్‌షాట్ డయాగ్రామ్. ఒక వినియోగదారు అభ్యర్థన మోడల్‌లోకి ప్రవేశిస్తుంది, ఇది ఒక ఆలోచన, సాధన పేరుతో చర్య, సాధన ఇన్‌పుట్‌ను ఉత్పత్తి చేస్తుంది. టూల్‌ను పిలిచే ముందు ఈ మధ్యంతర రిజనింగ్ దశను డయాగ్రామ్ హైలైట్ చేస్తుంది.

మీరు చూసినట్లయితే, ప్రాంప్ట్‌లోని మొదటి మూడు అంశాల క్రమం క్లయింట్ ద్వారా కాకుండా సర్వర్ ద్వారా నిర్ణయించబడుతుంది. అయితే, ఆ మూడు అంశాలలో, సిస్టమ్ సందేశం యొక్క కంటెంట్ మాత్రమే సర్వర్ ద్వారా నియంత్రించబడుతుంది, ఎందుకంటే టూల్స్ మరియు సూచనలు క్లయింట్ ద్వారా నిర్ణయించబడతాయి. ప్రాంప్ట్‌ను పూర్తి చేయడానికి వీటి తరువాత JSON పేలోడ్ నుండి ఇన్‌పుట్ వస్తుంది.

ఇప్పుడు మనకు ప్రాంప్ట్ ఉన్నందున, మోడల్‌ను నమూనా చేయడానికి మేం సిద్ధంగా ఉన్నాం.

మొదటి మలుపు

ఈ HTTP అభ్యర్థన ప్రతిస్పందనలు APIకి Codexలో సంభాషణ మొదటి “మలుపు” ప్రారంభిస్తుంది. సర్వర్ ఒక సర్వర్ పంపిన ఈవెంట్‌లు (SSE⁠(కొత్త విండోలో తెరుచుకుంటుంది)) స్ట్రీమ్‌తో ప్రతిస్పందిస్తుంది. ప్రతి ఈవెంట్ డేటా అనేది "టైప్‌"తో ప్రారంభమయ్యే JSON పేలోడ్, ఇది "ప్రతిస్పందన"తో మొదలవుతుంది, ఇది ఇలాంటిదిగా ఉండవచ్చు (ఈవెంట్‌ల పూర్తి జాబితా మా 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 వంటి ఇతర ఈవెంట్‌లు ఆబ్జెక్టులుగా మార్చబడి, తదుపరి ప్రతిస్పందనలు API కాల్స్ కోసం ఇన్‌పుట్‌కు జోడించబడతాయి.

ప్రతిస్పందనల APIకి మొదటి అభ్యర్థనలో రెండు response.output_item.done ఈవెంట్‌లు ఉన్నాయని అనుకుందాం: ఒకటి టైప్=రీజనింగ్తో మరియు ఒకటి type=function_callతో. మేం టూల్ కాల్‌కు ప్రతిస్పందనతో మోడల్‌ను మళ్లీ క్వెరీ చేసినప్పుడు, ఈ ఈవెంట్స్ JSON input ఫీల్డ్‌లో ప్రాతినిధ్యం వహించాలి: 

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
]

తదుపరి ప్రశ్నలో భాగంగా మోడల్‌ను నమూనా చేయడానికి ఉపయోగించే ఫలిత ప్రాంప్ట్ ఇలా ఉంటుంది:

టూల్ కాల్ తర్వాత AI ఏజెంట్‌ను చూపించే “స్నాప్‌షాట్ 2” అని లేబుల్ చేసిన డయాగ్రామ్. మోడల్ ఒక సాధన పరిశీలనను స్వీకరించి, కొత్త ఆలోచన మరియు చర్యను సృష్టిస్తుంది. ఏజెంట్ తన రిజనింగ్ లూప్‌ను ఎలా పునరావృతం చేస్తుందో చూపించడానికి బాణాలు ఇన్‌పుట్‌లు, పరిశీలనలు, మరియు అవుట్‌పుట్‌లను కలుపుతాయి.

ప్రత్యేకంగా, పాత ప్రాంప్ట్ కొత్త ప్రాంప్ట్‌కు ఖచ్చితమైన ముందుమాట ఎలా ఉందో గమనించు. ఇది ఉద్దేశపూర్వకంగా చేయబడింది, ఎందుకంటే ఇది తరువాతి అభ్యర్థనలను మరింత సమర్థవంతంగా చేస్తుంది, ఎందుకంటే ఇది మాకు ప్రాంప్ట్ క్యాషింగ్ ప్రయోజనాన్ని పొందడానికి అనుమతిస్తుంది (దీని గురించి పనితీరుపై వచ్చే విభాగంలో చర్చిస్తాము).

ఏజెంట్ లూప్ మొదటి డయాగ్రామ్‌ను తిరిగి చూసినప్పుడు, ఇన్‌ఫరెన్స్ మరియు టూల్ కాలింగ్ మధ్య అనేక పునరావృతులు ఉండవచ్చని మనం గమనిస్తాంవ. మనం చివరకు ఒక అసిస్టెంట్ సందేశాన్ని స్వీకరించే వరకు ప్రాంప్ట్ పెరుగుతూనే ఉండవచ్చు, ఇది టర్న్ ముగింపును సూచిస్తుంది:

ప్లెయిన్ టెక్స్ట్

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

Codex CLIలో, మేం అసిస్టెంట్ సందేశాన్ని వినియోగదారుకు ప్రదర్శిస్తాం మరియు సంభాషణను కొనసాగించడానికి వారి “వంతు” అని వినియోగదారుకు సూచించడానికి స్వరకర్తపై దృష్టి పెడతాం. యూజర్ స్పందిస్తే, కొత్త టర్న్‌ను ప్రారంభించడానికి ప్రతిస్పందనల 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కి పంపే ఇన్‌పుట్ పొడవు పెరుగుతూనే ఉంది:

“Snapshot 3” అని లేబుల్ చేసిన డయాగ్రామ్ AI ఏజెంట్ లూప్ క తుది దశను చూపిస్తుంది. టూల్ ఫలితాలను స్వీకరించిన తర్వాత, మోడల్ ఒక ముగింపు ఆలోచన రూపొందించి, యూజర్‌కు తిరిగి పంపే తుది సమాధానాన్ని సృష్టిస్తుంది. సాధన అవుట్‌పుట్ నుండి పూర్తయిన ప్రతిస్పందనకు పరివర్తనను బాణాలు వివరిస్తాయి.

పనితీరుకు ఈ నిరంతరం పెరుగుతున్న ప్రాంప్ట్ అంటే ఏమిటో పరిశీలిద్దాం.

పనితీరు పరిగణనలు

“ఆగండి, సంభాషణ సమయంలో ప్రతిస్పందనల API కి పంపిన JSON మొత్తం పరంగా ఏజెంట్ లూప్ క్వాడ్రాటిక్ కాదా?” అని మీరు మిమ్మల్ని మీరు ప్రశ్నించుకోవచ్చు. మరియు నువ్వు సరైనవాడివి. ప్రతిస్పందనల API ఒక ఐచ్ఛిక previous_response_id⁠(కొత్త విండోలో తెరుచుకుంటుంది) పరామీటర్‌ను ఈ సమస్యను తగ్గించడానికి సపోర్ట్ చేసినప్పటికీ, Codex ఈరోజు దాన్ని ఉపయోగించదు, మరిముఖ్యంగా రిక్వెస్ట్‌లను పూర్తిగా స్టేట్‌లెస్‌గా ఉంచడానికి మరియు జీరో డేటా రిటెన్షన్ (ZDR) కాన్ఫిగరేషన్‌లకు మద్దతు ఇవ్వడానికి.

previous_response_id ఉపయోగించకుండా ఉండటం ప్రతిస్పందనలు API ప్రొవైడర్‌కు పనులను సులభతరం చేస్తుంది, ఎందుకంటే ఇది ప్రతి అభ్యర్థనను స్థితిలేనిదిగా వలే ఉంచుతుంది. జీరో డేటా రిటెన్షన్ (ZDR)⁠(కొత్త విండోలో తెరుచుకుంటుంది) ఎంచుకున్న కస్టమర్‌లకు మద్దతు ఇవ్వడం కూడా సులభం, ఎందుకంటే previous_response_id కు మద్దతు ఇవ్వడానికి అవసరమైన డేటాను నిల్వ చేయడం ZDR కు విరుద్ధంగా ఉంటుంది. ZDR కస్టమర్‌లు గత టర్న్‌ల నుండి ప్రొప్రైటరీ రిజనింగ్ సందేశాల ప్రయోజనాన్ని కోల్పోరని గమనించండి, ఎందుకంటే సంబంధిత encrypted_content ను సర్వర్‌లో డీక్రిప్ట్ చేయవచ్చు. (OpenAI ఒక ZDR కస్టమర్ యొక్క డిక్రిప్షన్ కీని నిల్వ చేస్తుంది, కానీ వారి డేటాను కాదు.) ZDRకు మద్దతు ఇవ్వడానికి Codexలో చేసిన సంబంధిత మార్పుల కోసం PRs #642⁠(కొత్త విండోలో తెరుచుకుంటుంది) మరియు #1641⁠(కొత్త విండోలో తెరుచుకుంటుంది) చూడండి.

సాధారణంగా, మోడల్‌ను నమూనా చేయడానికి అయ్యే ఖర్చు నెట్‌వర్క్ ట్రాఫిక్ ఖర్చు మించిపోతుంది, అందువల్ల శాంపులింగ్ మా సమర్థత ప్రయత్నాల ప్రధాన లక్ష్యంగా మారుతుంది. ఇదే కారణంగా ప్రాంప్ట్ క్యాషింగ్ చాలా ముఖ్యమైనది, ఎందుకంటే ఇది మునుపటి ఇన్‌ఫరెన్స్ కాల్ నుండి లెక్కింపును మళ్లీ ఉపయోగించుకునేలా చేస్తుంది. మాకు క్యాష్ హిట్స్ వచ్చినప్పుడు, మోడల్‌ను శాంపిల్ చేయడం క్వాడ్రాటిక్ కాకుండా లీనియర్‌గా ఉంటుంది. మా ప్రాంప్ట్ క్యాషింగ్ ⁠(కొత్త విండోలో తెరుచుకుంటుంది)డాక్యుమెంటేషన్ దీనిని మరింత వివరంగా వివరిస్తుంది:

క్యాష్ హిట్స్ కేవలం ప్రాంప్ట్‌లో ఖచ్చితమైన ప్రిఫిక్స్ మ్యాచ్‌లకు మాత్రమే సాధ్యమవుతాయి. క్యాషింగ్ ప్రయోజనాలను పొందడానికి, సూచనలు మరియు ఉదాహరణలు వంటి స్థిర కంటెంట్‌ను మీ ప్రాంప్ట్ ప్రారంభంలో ఉంచండి, యూజర్-నిర్ధిష్ట సమాచారం వంటి మారే కంటెంట్‌ను చివరలో ఉంచండి. ఇది చిత్రాలు మరియు సాధనాలకు కూడా వర్తిస్తుంది, ఇవి అభ్యర్థనల మధ్య ఒకేలా ఉండాలి.

ఇది దృష్టిలో ఉంచుకుని, Codexలో “cache miss” కు కారణమయ్యే ఆపరేషన్‌ల రకాలను పరిశీలిద్దాం:

  • సంభాషణ మధ్యలో మోడల్‌కు అందుబాటులో ఉన్న టూల్స్ మార్చడం.
  • ప్రతిస్పందనలు API అభ్యర్థనకు లక్ష్యంగా ఉన్న మోడల్ మార్చడం (ప్రయోగంలో, ఇది అసలు ప్రాంప్ట్‌లోని మూడవ అంశాన్ని మార్చుతుంది, ఎందుకంటే అందులో మోడల్-నిర్ధిష్ట సూచనలు ఉంటాయి).
  • సాండ్‌బాక్స్ కాన్ఫిగరేషన్, ఆమోద మోడ్, లేదా ప్రస్తుత వర్కింగ్ డైరెక్టరీని మార్చడం.

Codex CLIలో ప్రాంప్ట్ క్యాషింగ్‌ను రాజీ చేసే అవకాశం ఉన్న కొత్త ఫీచర్‌లను పరిచయం చేస్తున్నప్పుడు Codex టీమ్ జాగ్రత్త వహించాలి. ఉదాహరణకు, మా MCP టూల్స్‌కు ప్రారంభ మద్దతు టూల్స్‌ను స్థిరమైన క్రమంలో ఎన్యూమరేట్ చేయడంలో విఫలమైన బగ్⁠(కొత్త విండోలో తెరుచుకుంటుంది)ను పరిచయం చేసింది, ఇది కాష్ మిస్‌లకు కారణమైంది. MCP టూల్స్ ప్రత్యేకంగా క్లిష్టంగా ఉండవచ్చని గమనించండి, ఎందుకంటే MCP సర్వర్‌లు notifications/tools/list_changed⁠(కొత్త విండోలో తెరుచుకుంటుంది) నోటిఫికేషన్ ద్వారా వారు అందించే టూల్స్ జాబితాను తక్షణమే మార్చగలవు. పొడవైన సంభాషణ మధ్యలో ఈ నోటిఫికేషన్‌ను గౌరవించడం ఖరీదైన కాష్ మిస్‌కు దారితీయవచ్చు.

సాధ్యమైనప్పుడల్లా, సంభాషణ మధ్యలో జరిగే కాన్ఫిగరేషన్ మార్పులను మేం మునుపటి సందేశాన్ని ఇన్‌పుట్ సవరించడం కంటే మార్పును ప్రతిబింబించేలా కొత్త సందేశాన్ని జోడించడం ద్వారా నిర్వహిస్తాం:

పనితీరు కోసం కాష్ హిట్‌లను నిర్ధారించడానికి మేం చాలా కష్టపడతాం. మనం నిర్వహించాల్సిన మరో ముఖ్య వనరు ఉంది: కాంటెక్ట్స్ విండో.

సందర్భోచిత విండో అయిపోకుండా ఉండటానికి మా సాధారణ వ్యూహం ఏమిటంటే, టోకెన్‌ల సంఖ్య కొంత పరిమితిని దాటిన తర్వాత సంభాషణను కుదించడం . ప్రత్యేకంగా, మేం ఇన్‌పుట్ సంభాషణను సూచించే కొత్త, చిన్న అంశాల జాబితాతో భర్తీ చేస్తాం, ఇప్పటివరకు ఏమి జరిగిందో అర్థం చేసుకోవడంలో ఏజెంట్‌కు వీలు కల్పిస్తుంది. కంపాక్షన్ ముందస్తు అమలుకు⁠(కొత్త విండోలో తెరుచుకుంటుంది) వినియోగదారు /compact కమాండ్‌ను మాన్యువల్‌గా అమలు చేయాల్సి ఉంటుంది, ఇది ఇప్పటికే ఉన్న సంభాషణతో పాటు సారాంశం⁠(కొత్త విండోలో తెరుచుకుంటుంది) కోసం అనుకూల సూచనలను ఉపయోగించి ప్రతిస్పందనల APIని ప్రశ్నిస్తుంది. Codex ఫలితంగా వచ్చిన అసిస్టెంట్ సందేశంలోని సారాంశాన్ని కొత్త ఇన్‌పుట్⁠(కొత్త విండోలో తెరుచుకుంటుంది) గా తదుపరి సంభాషణ టర్న్‌ల కోసం ఉపయోగించింది.

అప్పటి నుండి, ప్రతిస్పందనలు API మరింత సమర్థవంతంగా కంపాక్షన్ చేయడానికి మద్దతిచ్చే ప్రత్యేక /responses/compact ఎండ్‌పాయింట్⁠(కొత్త విండోలో తెరుచుకుంటుంది) గా అభివృద్ధి చెందింది. ఇది అంశాల జాబితాను⁠(కొత్త విండోలో తెరుచుకుంటుంది) తిరిగి ఇస్తుంది, ఇది మునుపటి ఇన్‌పుట్ స్థానంలో ఉపయోగించి, కాంటెక్ట్స్ విండోను ఖాళీ చేస్తూ సంభాషణను కొనసాగించడానికి ఉపయోగపడుతుంది. ఈ జాబితాలో ప్రత్యేక type=compaction అంశం ఉంది, ఇందులో అసలు సంభాషణపై మోడల్ అంతర్గత అవగాహనను కాపాడే అపారదర్శక encrypted_content అంశం ఉంటుంది. ఇప్పుడు, auto_compact_limit⁠(కొత్త విండోలో తెరుచుకుంటుంది) మించిపోయినప్పుడు సంభాషణను కుదించడానికి Codex ఆటోమేటిక్‌గా ఈ ఎండ్‌పాయింట్‌ను ఉపయోగిస్తుంది.

తర్వాత వస్తుంది

మేం Codex ఏజెంట్ లూప్‌ను పరిచయం చేసి, మోడల్‌ను క్వెరీ చేస్తున్నప్పుడు Codex తన సందర్భాన్ని ఎలా రూపొందిస్తుంది మరియు నిర్వహిస్తుందనేది వివరించాం. మార్గమధ్యంలో, ప్రతిస్పందనలు APIపై ఏజెంట్ లూప్‌ను నిర్మించే ఎవరికైనా వర్తించే ఆచరణాత్మక అంశాలు మరియు ఉత్తమ పద్ధతులకు మేం ప్రాముఖ్యత ఇచ్చాం.

Codex కోసం ఏజెంట్ లూప్ పునాదిని అందించినప్పటికీ, ఇది కేవలం ఆరంభం మాత్రమే. రాబోయే పోస్టుల్లో, మేం CLI నిర్మాణాన్ని లోతుగా పరిశీలిస్తాం, సాధనాల వినియోగం ఎలా అమలు చేయబడిందనేది అన్వేషిస్తాం, Codex సాండ్‌బాక్సింగ్ మోడల్ సమీక్షిస్తాం.

రచయిత

Michael Bolin

కృతజ్ఞతలు

Codex CLI నిర్మించిన మొత్తం బృందానికి ప్రత్యేక ధన్యవాదాలు.

చదవడం కొనసాగించండి

అన్నీ చూడండి
Tax Agent > Art Card
Codex‌తో స్వీయ-మెరుగుదల పన్ను ఏజెంట్‌ల నిర్మాణం

ఇంజనీరింగ్

codex windows > art card
Windows లో Codex ను ప్రారంభించడానికి సురక్షితమైన, ప్రభావవంతమైన sandbox నిర్మాణం

ఇంజనీరింగ్

MRC 1_1
గాబ్లిన్లు ఎక్కడి నుంచి వచ్చాయి

ఇంజనీరింగ్