23 ஜனவரி, 2026

Codex ஏஜென்ட் லூப்பை விரிவாக்குதல்

Michael Bolin, தொழில்நுட்ப ஊழியர் உறுப்பினர் எழுதியது

ஏற்றுகிறது…

Codex CLI⁠(புதிய சாளரத்தில் திறக்கும்) என்பது எங்களின் குறுக்குவெளி தள உள்ளூர் மென்பொருள் ஏஜென்ட் ஆகும், இது உங்கள் கணினியில் பாதுகாப்பாகவும் திறமையாகவும் இயங்கிக்கொண்டே, உயர்தரமான, நம்பகமான மென்பொருள் மாற்றங்களை உருவாக்க வடிவமைக்கப்பட்டுள்ளது. நாங்கள் ஏப்ரலில் முதன்முதலில் CLI ஐ அறிமுகப்படுத்தியதிலிருந்து⁠ உலகத் தரமான மென்பொருள் ஏஜென்டை எவ்வாறு உருவாக்குவது பற்றி மிகப் பெருமளவு கற்றுக்கொண்டுள்ளோம். அந்த நுண்ணறிவுகளை விரிவாகப் புரிந்துகொள்ள, Codex எவ்வாறு செயல்படுகிறது என்பதற்கான பல்வேறு அம்சங்களையும், கடினமாகக் கற்றுக்கொண்ட பாடங்களையும் ஆராயும் தொடர்ச்சியான தொடர்களின் முதல் பதிவாக இது உள்ளது. (Codex CLI எவ்வாறு உருவாக்கப்பட்டுள்ளதெனப் பற்றி மேலும் விரிவான பார்வை பெற, எங்கள் ஓபன் சோர்ஸ் ரிபாசிட்டரி https://github.com/openai/codex⁠(புதிய சாளரத்தில் திறக்கும்) ஐ பார்வையிடுங்கள். நீங்கள் மேலும் அறிய விரும்பினால், எங்கள் வடிவமைப்பு முடிவுகளின் நுணுக்கமான விவரங்கள் GitHub issues மற்றும் புல் ரிக்வெஸ்ட்களில் பதிவாக உள்ளன.)

தொடங்குவதற்கு, பயனர், மாடல் மற்றும் அர்த்தமுள்ள மென்பொருள் வேலைகளைச் செய்ய மாடல் செயல்படுத்தும் கருவிகளுக்கு இடையிலான தொடர்புகளை ஒழுங்கமைப்பதற்குப் பொறுப்பான Codex CLI இல் உள்ள முக்கிய தர்க்கமான ஏஜென்ட் லூப் கவனம் செலுத்துவோம். இந்த பதிவில் இருந்து எங்கள் ஏஜென்ட் (அல்லது “harness”) LLM-ஐ பயன்படுத்துவதில் வகிக்கும் பங்கைப் பற்றி நீங்கள் நல்ல பார்வையைப் பெறுவீர்கள் என்று நாங்கள் நம்புகிறோம்.

நாம் தொடங்குவதற்கு முன், சொற்களஞ்சியம் குறித்த ஒரு சுருக்கமான குறிப்பு: OpenAI இல், “Codex” என்பது Codex CLI, Codex Cloud, மற்றும் Codex VS Code விரிவாக்கம் உட்பட, மென்பொருள் ஏஜென்ட் வழங்கல்களின் ஒரு தொகுப்பை உள்ளடக்குகிறது. இந்த பதிவு Codex harness மீது கவனம் செலுத்துகிறது, இது அனைத்து Codex அனுபவங்களுக்கும் அடிப்படையாக இருக்கும் மைய ஏஜென்ட் லூப் மற்றும் செயல்படுத்தல் தர்க்கத்தை வழங்குகிறது மற்றும் Codex CLI மூலம் வெளிப்படுத்தப்படுகிறது. இங்கே எளிமைக்காக, “Codex” மற்றும் “Codex CLI” என்ற சொற்களை ஒன்றுக்கொன்று மாற்றாகப் பயன்படுத்துவோம்.

ஏஜென்ட் லூப்

ஒவ்வொரு AI ஏஜென்ட் இன் மையத்திலும் “ஏஜென்ட் லூப்” என்று அழைக்கப்படும் ஒன்று உள்ளது. ஏஜென்ட் லூப்பின் எளிமைப்படுத்தப்பட்ட விளக்கப்படம் பின்வருமாறு இருக்கும்:

“Agent loop” என்ற தலைப்புடைய வரைபடம், AI அமைப்பு பயனர் கோரிக்கையை எவ்வாறு செயலாக்குகிறது, கருவிகளை அழைக்கிறது, முடிவுகளை கவனிக்கிறது, தனது திட்டத்தை புதுப்பிக்கிறது, மற்றும் வெளியீடுகளை திருப்பி வழங்குகிறது என்பதை விளக்குகிறது. அம்புகள் பயனர் உள்ளீடு, மாடல் ரீஸனிங், கருவி செயல்கள், மற்றும் இறுதி பதில் போன்ற படிகளை இணைக்கின்றன.

தொடங்குவதற்கு, ஏஜென்ட் பயனரிடமிருந்து input ஐ எடுத்து, மாடலுக்காக அது தயாரிக்கும் உரை வழிமுறைகளின் தொகுப்பில் சேர்க்கிறது; இது ப்ராம்ப்ட் என அழைக்கப்படுகிறது.

அடுத்த படியாக, எங்கள் அறிவுறுத்தல்களை மாடலுக்கு அனுப்பி, பதிலை உருவாக்குமாறு கேட்பது, இது இன்ஃபெரன்ஸ் எனப்படும் செயல்முறை ஆகும். முன்னறிவிப்பு செயல்பாட்டின் போது, உரை ப்ராம்ப்ட் முதலில் உள்ளீட்டு டோக்கன்கள்⁠(புதிய சாளரத்தில் திறக்கும்) வரிசையாக மாற்றப்படுகிறது—மாடலின் சொற்களஞ்சியத்தில் குறியிடும் முழு எண்கள். இந்த டோக்கன்கள் பின்னர் மாடலை மாதிரி எடுக்க பயன்படுத்தப்படுகின்றன, இதன் மூலம் புதிய வெளியீட்டு டோக்கன்களின் தொடரை உருவாக்குகின்றன.

வெளியீட்டு டோக்கன்கள் மீண்டும் உரையாக மொழிபெயர்க்கப்படுகின்றன, அவை மாடலின் பதிலாக மாறுகின்றன. டோக்கன்கள் படிப்படியாக உருவாக்கப்படுவதால், மாடல் இயங்கும் போதே இந்த மொழிபெயர்ப்பு நடைபெற முடியும், அதனால்தான் பல LLM அடிப்படையிலான பயன்பாடுகள் ஸ்ட்ரீமிங் வெளியீட்டை காட்டுகின்றன. நடைமுறையில், அனுமானம் பொதுவாக உரையில் செயல்படும் ஒரு API-க்குப் பின்னால் இணைக்கப்பட்டு, டோக்கனாக்குதலின் விவரங்களைச் சுருக்கிக் கொள்கிறது.

இன்ஃபரன்ஸ் படியின் விளைவாக, மாடல் (1) பயனரின் அசல் உள்ளீட்டிற்கு ஒரு இறுதி பதிலை உருவாக்குகிறது அல்லது (2) ஏஜென்ட் செய்ய வேண்டும் என்று எதிர்பார்க்கப்படும் ஒரு டூல் கால் ஐ கோருகிறது (எ.கா., “ls ஐ இயக்கி, வெளியீட்டை அறிக்கையிடுங்கள்”). (2) என்ற நிலையில், ஏஜென்ட் கருவி அழைப்பை இயக்கி, அதன் வெளியீட்டை அசல் ப்ராம்ப்டில் இணைக்கிறது. இந்த வெளியீடு புதிய உள்ளீட்டை உருவாக்க பயன்படுத்தப்படுகிறது, இது மாடலை மீண்டும் வினவ பயன்படுத்தப்படுகிறது; பின்னர் ஏஜென்ட் இந்த புதிய தகவலை கருத்தில் கொண்டு மீண்டும் முயற்சிக்கலாம்.

இந்த செயல்முறை மாடல் டூல் அழைப்புகளை நிறுத்தி, அதற்கு பதிலாக பயனருக்கான ஒரு செய்தியை உருவாக்கும் வரை (OpenAI மாடல்களில் assistant message என அழைக்கப்படுகிறது) தொடர்ச்சியாக நடைபெறும். பல சந்தர்ப்பங்களில், இந்தச் செய்தி பயனரின் அசல் கோரிக்கைக்கு நேரடியாகப் பதிலளிக்கிறது, ஆனால் இது பயனருக்கான பின்தொடர்புக் கேள்வியாகவும் இருக்கலாம்.

ஏஜென்ட் உள்ளூர் சூழலை மாற்றும் கருவி அழைப்புகளை இயக்க முடிவதால், அதன் “output” என்பது உதவியாளர் செய்தியுடன் மட்டுமே வரையறுக்கப்படவில்லை. பல சந்தர்ப்பங்களில், ஒரு மென்பொருள் ஏஜென்டின் முதன்மை வெளியீடு உங்கள் கணினியில் அது எழுதும் அல்லது திருத்தும் குறியீடாகும். எனினும், ஒவ்வொரு சுற்றும் எப்போதும் ஒரு உதவியாளர் செய்தியுடன் முடிகிறது—உதாரணமாக, ‘நீங்கள் கேட்ட architecture.md கோப்பை நான் சேர்த்துள்ளேன்’—இது ஏஜென்ட் லூப்பில் முடிவு நிலையை குறிக்கிறது. ஏஜென்டின் பார்வையில், அதன் வேலை முடிந்துவிட்டது, மேலும் கட்டுப்பாடு பயனரிடம் திரும்புகிறது.

வரைபடத்தில் காட்டப்பட்டுள்ளபடி பயனர் உள்ளீட்டிலிருந்து ஏஜென்ட் பதிலுக்கான பயணம் ஒரு உரையாடலின் ஒரு திருப்பம் (Codex இல் ஒரு த்ரட் ) என்று குறிப்பிடப்படுகிறது. இந்த உரையாடல் திருப்பத்தில் மாடல் அனுமானத்திற்கும் கருவி அழைப்புகளுக்கும் இடையில் பல மறு செய்கைகள் இருக்கலாம். நீங்கள் ஏற்கனவே உள்ள உரையாடலுக்கு ஒவ்வொரு முறையும் புதிய செய்தியை அனுப்பும் போது, அந்த உரையாடல் வரலாறு புதிய சுற்றுக்கான ப்ராம்ப்ட்டின் ஒரு பகுதியாக சேர்க்கப்படும், இதில் முந்தைய சுற்றுகளிலிருந்து செய்திகள் மற்றும் கருவி அழைப்புகள் அடங்கும்:

“மல்டி-டர்ன் ஏஜென்ட் லூப்” என்ற தலைப்புடைய வரைபடம், ஒரு AI ஏஜென்ட் பயனர் உள்ளீட்டை மீண்டும் மீண்டும் எடுத்து, செயல்களை உருவாக்கி, கருவிகளை ஆலோசித்து, நிலையை புதுப்பித்து, முடிவுகளை திருப்பி வழங்குவது எப்படி என்பதை காட்டுகிறது. ரீஸனிங் சுழற்சியை விளக்கும் ஏஜென்டின் லேபிள் செய்யப்பட்ட படிகள், அம்புகள் மற்றும் உதாரண கருவி வெளியீடுகள் அடங்கும்.

இதன் பொருள், உரையாடல் வளரும்போது, மாடல் எடுத்துக்கொள்ள பயன்படுத்தப்படும் ப்ராம்ப்ட் என்ற சொல் நீளமும் அதிகரிக்கும். இந்த நீளம் முக்கியமானது, ஏனெனில் ஒவ்வொரு மாடலுக்கும் ஒரு context window உள்ளது, இது ஒரு inference அழைப்பிற்கு அது பயன்படுத்தக்கூடிய அதிகபட்ச டோக்கன்களின் எண்ணிக்கையாகும். இந்த சாளரத்தில் உள்ளீட்டு மற்றும் வெளியீட்டு டோக்கன் இரண்டும் அடங்கும் என்பதை கவனிக்கவும். நீங்கள் கற்பனை செய்யக்கூடியபடி, ஒரு ஏஜென்ட் ஒரே முறையில் நூற்றுக்கணக்கான கருவி அழைப்புகளைச் செய்ய முடிவு செய்யலாம், இதனால் சூழல் சாளரம் சாத்தியமாக தீர்ந்து போகலாம். இந்த காரணத்திற்காக, context window management என்பது ஏஜென்டின் பல பொறுப்புகளில் ஒன்றாகும். இப்போது, Codex எப்படி ஏஜென்ட் லூப்பை இயக்குகிறது என்பதைப் பார்க்க உள்ளே செல்வோம்.

மாடல் ஊகம்

Codex CLI HTTP கோரிக்கைகளை Responses API⁠(புதிய சாளரத்தில் திறக்கும்) க்கு அனுப்பி மாடல் இன்ஃபரன்ஸை இயக்குகிறது. Responses API-ஐ பயன்படுத்தி ஏஜென்ட் லூப்பை இயக்கும் Codex வழியாக தகவல் எவ்வாறு பாய்கிறது என்பதை நாம் ஆராய்வோம்.

Codex CLI பயன்படுத்தும் Responses API எண்ட்பாயிண்ட் கட்டமைக்கக்கூடியது⁠(புதிய சாளரத்தில் திறக்கும்), எனவே Responses API ஐ செயல்படுத்தும்⁠(புதிய சாளரத்தில் திறக்கும்) எந்த எண்ட்பாயிண்ட்டுடனும் இதைப் பயன்படுத்தலாம்:

ChatGPT உள்நுழைவைப் பயன்படுத்தும் போது⁠(புதிய சாளரத்தில் திறக்கும்) Codex CLI உடன், இது https://chatgpt.com/backend-api/codex/responses ஐப் பயன்படுத்துகிறது. எண்ட்பாயிண்ட் ஆக
OpenAI ஹோஸ்ட் செய்யப்பட்ட மாடல்களுடன் API-கீ அங்கீகாரம் பயன்படுத்தும் போது⁠(புதிய சாளரத்தில் திறக்கும்), இது https://api.openai.com/v1/responses ஐப் பயன்படுத்துகிறது எண்ட்பாயிண்ட் ஆக
Codex CLI ஐ --oss மூலம் இயக்கும்போது, gpt-oss⁠ ஐ ollama 0.13.4+⁠(புதிய சாளரத்தில் திறக்கும்) அல்லது LM Studio 0.3.39+⁠(புதிய சாளரத்தில் திறக்கும்) உடன் பயன்படுத்த, அது உங்கள் கணினியில் உள்ளூர் முறையில் இயங்கும் http://localhost:11434/v1/responses க்கு இயல்புநிலையாக அமைக்கப்படும்
Codex CLI ஐ Azure போன்ற கிளவுட் வழங்குநரால் ஹோஸ்ட் செய்யப்படும் Responses API-யுடன் பயன்படுத்தலாம்

ஒரு உரையாடலில் முதல் இன்ஃபரன்ஸ் அழைப்புக்கான ப்ராம்ப்டை Codex எவ்வாறு உருவாக்குகிறது என்பதை நம்மால் ஆராயலாம்.

ஆரம்ப ப்ராம்ப்ட்டை உருவாக்குதல்

ஒரு இறுதி பயனராக, நீங்கள் Responses API-ஐ வினவும்போது மாடலை மாதிரி எடுக்க பயன்படுத்தப்படும் ப்ராம்ப்ட்டை சொல்லாக குறிப்பிடுவதில்லை. அதற்குப் பதிலாக, நீங்கள் உங்கள் வினவலின் ஒரு பகுதியாக பல்வேறு உள்ளீட்டு வகைகளை குறிப்பிடுகிறீர்கள், மேலும் Responses API சர்வர், மாடல் பயன்படுத்துவதற்காக வடிவமைக்கப்பட்ட ப்ராம்ப்ட்டாக இந்த தகவலை எவ்வாறு அமைக்க வேண்டும் என்பதை தீர்மானிக்கிறது. நீங்கள் அந்த வரியை "உருப்படிகளின் பட்டியல்" என்று நினைக்கலாம்; உங்கள் வினவல் அந்த பட்டியலாக எவ்வாறு மாற்றப்படுகிறது என்பதை இந்தப் பகுதி விளக்கும்.

ஆரம்ப ப்ராம்ப்டில், பட்டியலில் உள்ள ஒவ்வொரு உருப்படியும் ஒரு பங்குடன் தொடர்புபடுத்தப்பட்டுள்ளது. தொடர்புடைய உள்ளடக்கம் எவ்வளவு எடையைக் கொண்டிருக்க வேண்டும் என்பதை இந்தப் role குறிக்கிறது மற்றும் பின்வரும் மதிப்புகளில் ஒன்றாகும் (முன்னுரிமையின் இறங்கு வரிசையில்): system, developer, user, assistant.

Responses API⁠(புதிய சாளரத்தில் திறக்கும்) பல அளவுருக்களுடன் கூடிய JSON payload ஐ ஏற்கிறது. இந்த மூன்றில் கவனம் செலுத்துவோம்:

வழிமுறைகள்⁠(புதிய சாளரத்தில் திறக்கும்): மாடலின் சூழலில் சேர்க்கப்பட்ட முறைமை (அல்லது டெவலப்பர்) செய்தி
tools⁠(புதிய சாளரத்தில் திறக்கும்): பதிலை உருவாக்கும் போது மாடல் அழைக்கக்கூடிய கருவிகளின் பட்டியல்
input⁠(புதிய சாளரத்தில் திறக்கும்): மாடலுக்கான உரை, படம் அல்லது கோப்பு உள்ளீடுகளின் பட்டியல்

Codex இல், instructions என்ற புலம் ~/.codex/config.toml கோப்பில் குறிப்பிடப்பட்டிருந்தால் அதில் உள்ள model_instructions_file⁠(புதிய சாளரத்தில் திறக்கும்) இலிருந்து படிக்கப்படும். அது குறிப்பிடப்படவில்லை என்றால் அந்த மாடலுடன் தொடர்புடைய base_instructions⁠(புதிய சாளரத்தில் திறக்கும்) பயன்படுத்தப்படும். மாடல்-குறிப்பிட்ட வழிமுறைகள் Codex ரெபோவில் உள்ளன மற்றும் CLI-யில் தொகுக்கப்பட்டுள்ளன (உதாரணமாக, gpt-5.2-codex_prompt.md⁠(புதிய சாளரத்தில் திறக்கும்) உள்ளன).

tools புலம் என்பது Responses API வரையறுத்த ஒரு ஸ்கீமாவுக்கு (schema) இணங்கும் கருவி வரையறைகளின் பட்டியலாகும். 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 payload இன் input புலம் உருப்படிகளின் பட்டியலாகும். Codex பின்வரும் உருப்படிகளைச் சேர்க்கிறது⁠(புதிய சாளரத்தில் திறக்கும்) பயனர் செய்தியைச் சேர்ப்பதற்கு முன் input இல்:

1. role=developer உடன் ஒரு செய்தி, tools பிரிவில் வரையறுக்கப்பட்ட Codex வழங்கிய shell tool க்கு மட்டும் பொருந்தும் சாண்ட்பாக்ஸை விவரிக்கிறது. அதாவது, 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 கொண்ட ஒரு செய்தி, அதன் உள்ளடக்கம் “பயனர் வழிமுறைகள்” ஆகும், அவை ஒரு ஒற்றை கோப்பிலிருந்து பெறப்படுவதல்ல, ஆனால் பல மூலங்களிலிருந்து ஒருங்கிணைக்கப்பட்டவை⁠(புதிய சாளரத்தில் திறக்கும்). பொதுவாக, மேலும் குறிப்பான வழிமுறைகள் பின்னர் வரும்:

$CODEX_HOME இல் உள்ள AGENTS.override.md மற்றும் AGENTS.md கோப்புகளின் உள்ளடக்கங்கள்
ஒரு வரம்பிற்கு உட்பட்டு (இயல்பாக, 32 KiB), cwd இன் Git/திட்டத்தின் root இலிருந்து cwd வரை, ஒவ்வொரு கோப்புறையிலும் (அது இருந்தால்) தேடவும்: AGENTS.override.md இன் உள்ளடக்கங்களைச் சேர்க்கவும், AGENTS.md, அல்லது config.toml இல் குறிப்பிடப்பட்ட project_doc_fallback_filenames மூலம் குறிப்பிடப்பட்ட எந்த கோப்புப் பெயரும்
ஏதேனும் திறன்கள்⁠(புதிய சாளரத்தில் திறக்கும்) அமைக்கப்பட்டிருந்தால்:
- திறன்களைப் பற்றிய சுருக்கமான முன்னுரை
- ஒவ்வொரு திறனுக்கான திறன் மெட்டாடேட்டா⁠(புதிய சாளரத்தில் திறக்கும்)
- திறன்களை எவ்வாறு பயன்படுத்துவது⁠(புதிய சாளரத்தில் திறக்கும்)பற்றிய பகுதி

4. ஏஜென்ட் தற்போது செயல்படும் உள்ளூர் சூழலை விவரிக்கும் role=user கொண்ட ஒரு செய்தி. இது தற்போதைய பணிக் கோப்பகத்தையும் பயனரின் ஷெல்-ஐயும் குறிப்பிடுகிறது⁠(புதிய சாளரத்தில் திறக்கும்):

எளிய உரை

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

Codex மேலே உள்ள அனைத்து கணக்கீடுகளையும் செய்து input ஐ துவக்கி முடித்தவுடன், உரையாடலைத் தொடங்க பயனர் செய்தியைச் சேர்க்கிறது.

முந்தைய உதாரணங்கள் ஒவ்வொரு செய்தியின் உள்ளடக்கத்தில் கவனம் செலுத்தின, ஆனால் input இன் ஒவ்வொரு கூறும் type, role⁠(புதிய சாளரத்தில் திறக்கும்), மற்றும் content ஆகியவற்றைக் கொண்ட ஒரு 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 payload ஐ Responses API க்கு அனுப்பிய பிறகு, ~/.codex/config.toml இல் Responses API எண்ட்பாயிண்ட் எவ்வாறு அமைக்கப்பட்டுள்ளது என்பதனைப் பொறுத்து Authorization header உடன் HTTP POST கோரிக்கையை செய்கிறது (குறிப்பிட்டிருந்தால் கூடுதல் HTTP headers மற்றும் query parameters சேர்க்கப்படும்).

ஒரு OpenAI Responses API சர்வர் கோரிக்கையைப் பெறும் போது, அது JSON-ஐப் பயன்படுத்தி மாடலுக்கான ப்ராம்ப்டை பின்வருமாறு உருவாக்குகிறது (உறுதியாகச் சொல்ல வேண்டுமெனில், Responses API-யின் தனிப்பயன் செயலாக்கம் வேறொரு தேர்வைச் செய்யக்கூடும்):

AI ஏஜென்ட் சுழற்சியில் ஒரு தனி படியைக் காட்டும் ஸ்னாப்ஷாட் வரைபடம். ஒரு பயனர் கோரிக்கை மாடலுக்குள் நுழைகிறது, இது ஒரு சிந்தனை, ஒரு கருவி பெயருடன் ஒரு செயல், மற்றும் ஒரு கருவி உள்ளீட்டை உருவாக்குகிறது. கருவி அழைக்கப்படும் முன் இந்த இடைநிலை ரீஸனிங் படியை வரைபடம் சிறப்பாகக் காட்டுகிறது.

நீங்கள் காண்பது போல, ப்ராம்ப்ட்-இல் உள்ள முதல் மூன்று உருப்படிகளின் வரிசை கிளையண்டால் அல்ல, சர்வரால் தீர்மானிக்கப்படுகிறது. அதுபோல, அந்த மூன்று உருப்படிகளில்,tools மற்றும் instructions கிளையண்டால் தீர்மானிக்கப்படுவதால்,system message இன் உள்ளடக்கம் மட்டுமே சர்வர் மூலம் கட்டுப்படுத்தப்படுகிறது. ப்ராம்ப்ட்டை நிறைவு செய்ய, இவற்றைத் தொடர்ந்து JSON payload இலிருந்து input சேர்க்கப்படுகிறது.

இப்போது நமக்கு எங்கள் ப்ராம்ப்ட் இருப்பதால், நாங்கள் மாடலை மாதிரி எடுக்கத் தயாராக உள்ளோம்.

முதல் திருப்பம்

Responses API க்கு செய்யப்படும் இந்த HTTP கோரிக்கை Codex இல் ஒரு உரையாடலின் முதல் “முறை” ஐ தொடங்குகிறது. சர்வர் Server-Sent Events (SSE⁠(புதிய சாளரத்தில் திறக்கும்)) ஸ்ட்ரீம் மூலம் பதிலளிக்கிறது. ஒவ்வொரு நிகழ்வின் data என்பது "response" எனத் தொடங்கும் "type" கொண்ட ஒரு JSON payload ஆகும்; இது கீழே காட்டப்பட்டது போன்றதாக இருக்கலாம் (நிகழ்வுகளின் முழுப் பட்டியலை எங்கள் API docs⁠(புதிய சாளரத்தில் திறக்கும்) இல் காணலாம்):

எளிய உரை

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

Codex நிகழ்வுகளின் ஸ்ட்ரீமைக் கையாண்டு⁠(புதிய சாளரத்தில் திறக்கும்) அவற்றை வாடிக்கையாளர் பயன்படுத்தக்கூடிய உள்நாட்டு நிகழ்வு பொருட்களாக மீண்டும் வெளியிடுகிறது. response.output_text.delta போன்ற நிகழ்வுகள் UI-இல் ஸ்ட்ரீமிங்கை ஆதரிக்கப் பயன்படுத்தப்படுகின்றன, ஆனால் response.output_item.added போன்ற பிற நிகழ்வுகள் பொருட்களாக மாற்றப்பட்டு, அடுத்தடுத்த Responses API அழைப்புகளுக்காக input இல் சேர்க்கப்படுகின்றன.

Responses API-க்கு முதல் கோரிக்கையில் இரண்டு response.output_item.done நிகழ்வுகள் உள்ளன என்று கருதுங்கள்: ஒன்று type=reasoning உடன் மற்றும் ஒன்று 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 ஏஜென்ட்டைக் காட்டும் “Snapshot 2” என லேபிளிடப்பட்ட வரைபடம். மாடல் ஒரு கருவி பார்வையைக் கண்டு புதிய சிந்தனை மற்றும் நடவடிக்கையை உருவாக்குகிறது. ஏஜென்ட் தனது ரீஸனிங் சுழற்சியை எவ்வாறு மறு செய்கை செய்கிறது என்பதை விளக்க, அம்புக்குறிகள் உள்ளீடுகள், பார்வைகள், மற்றும் வெளியீடுகளை இணைக்கின்றன.

குறிப்பாக, பழைய ப்ராம்ட் புதிய ப்ராம்ட்டின் சரியான முன்னொட்டாக இருப்பதைக் கவனியுங்கள். இது திட்டமிட்டதே, ஏனெனில் இது அடுத்தடுத்த கோரிக்கைகளை மிகவும் திறமையானதாக மாற்றுகிறது; காரணம், இது ப்ராம்ப்ட் சேமிப்பு ஐப் பயன்படுத்திக் கொள்ள எங்களுக்கு உதவுகிறது (செயல்திறன் குறித்த அடுத்த பகுதியில் இதைப் பற்றி விவாதிப்போம்).

ஏஜென்ட் லூப்பின் எங்கள் முதல் விளக்கப்படத்தை மீண்டும் பார்த்தால், இன்ஃபரன்ஸ் மற்றும் கருவி அழைப்புகளுக்கு இடையில் பல முறை திருப்பங்கள் இருக்கக்கூடும் என்பதை நாம் காண்கிறோம். உதவியாளர் செய்தி கிடைக்கும் வரை ப்ராம்ப்ட் வளர்ந்து கொண்டே இருக்கும், இது முறை முடிவை குறிக்கிறது:

எளிய உரை

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

Codex CLI-இல், நாங்கள் உதவியாளர் செய்தியை பயனருக்கு காட்டி, உரையாடலைத் தொடர அவர்களின் “முறை” என்பதை பயனருக்கு தெரிவிக்க composer மீது கவனம் செலுத்துகிறோம். பயனர் பதிலளித்தால், புதிய முறையைத் தொடங்க Responses API கோரிக்கையில் உள்ள input க்கு முந்தைய முறையிலிருந்த உதவியாளர் செய்தியும், பயனரின் புதிய செய்தியும் இரண்டும் சேர்க்கப்பட வேண்டும்:

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]

மீண்டும் ஒருமுறை, நாம் உரையாடலைத் தொடர்ந்து கொண்டிருப்பதால், Responses API-க்கு அனுப்பும் input இன் நீளம் தொடர்ந்து அதிகரிக்கிறது:

“Snapshot 3” என்று பெயரிடப்பட்ட வரைபடம், AI ஏஜென்ட் சுழற்சியின் இறுதி நிலையை காட்டுகிறது. கருவியின் முடிவுகளைப் பெற்ற பிறகு, மாடல் ஒரு முடிவுரைக் கருத்தையும் பயனருக்கு திருப்பி வழங்கப்படும் இறுதி பதிலையும் உருவாக்குகிறது. கருவி வெளியீட்டிலிருந்து முடிக்கப்பட்ட பதிலாக மாறுதலை அம்புக்குறிகள் விளக்குகின்றன.

இந்த எப்போதும் வளர்ந்து வரும் ப்ராம்ப்ட் செயல்திறனுக்கு என்ன அர்த்தம் என்பதைக் கவனமாக ஆராய்வோம்.

செயல்திறன் கவனிக்க வேண்டிய விஷயங்கள்

“காத்திருங்கள், உரையாடல் முழுவதும் Responses API-க்கு அனுப்பப்படும் JSON அளவின் அடிப்படையில், ஏஜென்ட் லூப் quadratic அல்லவா?” என நீங்கள் உங்களுக்குள் கேட்கலாம். நீங்கள் சொல்வது சரிதான். Responses API ஒரு விருப்பமான previous_response_id⁠(புதிய சாளரத்தில் திறக்கும்) அளவுருவை இந்த சிக்கலைத் தணிக்க ஆதரிக்கிறது, ஆனால் கோரிக்கைகளை முழுமையாக நிலைமையற்றதாகவும், ஜீரோ டேட்டா ரிடென்ஷன் (ZDR) கட்டமைப்புகளை ஆதரிக்கவும் Codex இன்று அதை பயன்படுத்துவதில்லை.

previous_response_id ஐ தவிர்ப்பது Responses API வழங்குநருக்கு செயல்முறைகளை எளிதாக்குகிறது, ஏனெனில் இது ஒவ்வொரு கோரிக்கையும் stateless ஆக இருப்பதை உறுதிசெய்கிறது. ஜீரோ டேட்டா ரிடென்ஷன் (ZDR)⁠(புதிய சாளரத்தில் திறக்கும்) என்பதைத் தேர்வு செய்துள்ள வாடிக்கையாளர்களுக்கு ஆதரவளிப்பது எளிதாகிறது, ஏனெனில் previous_response_id ஐ ஆதரிக்கத் தேவையான தரவைச் சேமிப்பது ZDR-க்கு முரணாக இருக்கும். ZDR வாடிக்கையாளர்கள் முந்தைய திருப்பங்களிலிருந்து சொந்தமான ரீஸனிங் செய்திகளால் கிடைக்கும் நன்மைகளை இழக்கவில்லை என்பதை கவனிக்கவும், ஏனெனில் தொடர்புடைய encrypted_content சேவையகத்தில் குறிவிலக்கம் செய்யப்படலாம். (OpenAI ஒரு ZDR வாடிக்கையாளரின் குறிவிலக்க கீயை தக்கவைத்துக் கொள்கிறது, ஆனால் அவர்களின் தரவை தக்கவைக்கவில்லை.) Codex-இல் ZDR-ஐ ஆதரிக்க தொடர்புடைய மாற்றங்களைப் பார்க்க PRs #642⁠(புதிய சாளரத்தில் திறக்கும்) மற்றும் #1641⁠(புதிய சாளரத்தில் திறக்கும்) ஐப் பார்க்கவும்.

பொதுவாக, மாடலை மாதிரிப்பதற்கான செலவு நெட்வொர்க் போக்குவரத்தின் செலவை விட அதிகமாக இருக்கும், எனவே எங்கள் திறன் மேம்பாட்டு முயற்சிகளின் முதன்மை இலக்காக மாடல் மாதிரிப்பது அமைகிறது. இதனால்தான் ப்ராம்ப்ட் கேச்சிங் மிகவும் முக்கியமானது, ஏனெனில் இது முந்தைய inference அழைப்பிலிருந்து கணக்கீட்டை மீண்டும் பயன்படுத்த எங்களுக்கு அனுமதிக்கிறது. நாங்கள் கேச் ஹிட்களைப் பெறும்போது, மாடலை மாதிரியாக்குவது இருபடிக்கு பதிலாக நேர்கோட்டாக இருக்கும். எங்கள் ப்ராம்ப்ட் சேமிப்பு ⁠(புதிய சாளரத்தில் திறக்கும்)ஆவணங்கள் இதை மேலும் விரிவாக விளக்குகின்றன:

ஒரு ப்ராம்ப்ட்-இல் துல்லியமான முன்னொட்டு பொருத்தங்களுக்கு மட்டுமே கேச் ஹிட்கள் சாத்தியமாகும். கேஷிங் நன்மைகளைப் பெற, வழிமுறைகள் மற்றும் எடுத்துக்காட்டுகள் போன்ற நிலையான உள்ளடக்கத்தை உங்கள் ப்ராம்ப்ட் இன் தொடக்கத்தில் வைக்கவும், மேலும் பயனர்-குறிப்பிட்ட தகவல் போன்ற மாறும் உள்ளடக்கத்தை இறுதியில் வைக்கவும். இது படங்கள் மற்றும் கருவிகளுக்கும் பொருந்தும், அவை கோரிக்கைகளுக்கு இடையில் ஒரே மாதிரியாக இருக்க வேண்டும்.

இதைக் கருத்தில் கொண்டு, Codex-இல் “cache miss” ஏற்படக் காரணமாக இருக்கக்கூடிய செயல்பாடுகள் என்ன என்பதைப் பார்ப்போம்:

உரையாடலின் நடுவில் மாடலுக்கு கிடைக்கக்கூடிய tools ஐ மாற்றுவது.
Responses API கோரிக்கையின் இலக்காக இருக்கும் மாடல் -ஐ மாற்றுவது (நடைமுறையில், இது அசல் ப்ராம்ப்ட்டில் உள்ள மூன்றாவது உருப்படியை மாற்றுகிறது, ஏனெனில் அதில் மாடல்-சார்ந்த வழிமுறைகள் உள்ளன).
சாண்ட்பாக்ஸ் உள்ளமைவு, ஒப்புதல் முறை அல்லது தற்போதைய செயல்பாட்டு கோப்பகத்தை மாற்றுதல்.

Codex CLI இல் ப்ராம்ப்ட் கேஷிங்கை பாதிக்கக்கூடிய புதிய அம்சங்களை அறிமுகப்படுத்தும் போது Codex குழு மிகுந்த கவனத்துடன் இருக்க வேண்டும். உதாரணமாக, எங்கள் ஆரம்ப MCP கருவி ஆதரவு கருவிகளை ஒரே மாதிரியான வரிசையில் பட்டியலிடத் தவறிய பிழையை⁠(புதிய சாளரத்தில் திறக்கும்) அறிமுகப்படுத்தியது, இதனால் கேஷ் தவறுகள் ஏற்பட்டன. MCP கருவிகள் குறிப்பாக சிக்கலாக இருக்கக்கூடும், ஏனெனில் MCP சர்வர்கள் notifications/tools/list_changed⁠(புதிய சாளரத்தில் திறக்கும்) அறிவிப்பின் மூலம் அவர்கள் வழங்கும் கருவிகளின் பட்டியலை உடனுக்குடன் மாற்ற முடியும். நீண்ட உரையாடலின் நடுவில் இந்த அறிவிப்பை மதிப்பது விலையுயர்ந்த கேச் மிஸ்ஸை ஏற்படுத்தக்கூடும்.

சாத்தியமானபோது, உரையாடலின் நடுவில் நிகழும் கட்டமைப்பு மாற்றங்களை, முந்தைய செய்தியை மாற்றுவதற்குப் பதிலாக, அந்த மாற்றத்தை பிரதிபலிக்க input இல் ஒரு புதிய செய்தியைச் சேர்ப்பதன் மூலம் நாங்கள் கையாளுகிறோம்:

Sandbox அமைப்பு அல்லது அனுமதி முறை மாற்றப்பட்டால், மூல உருப்படியின் அதே வடிவில் ஒரு புதிய role=developer செய்தியை<permissions instructions> இல் நாங்கள் சேர்க்கிறோம்.⁠(புதிய சாளரத்தில் திறக்கும்)
தற்போதைய செயல்பாட்டு கோப்பகம் மாறினால், நாங்கள் அசல் போலவே அதே வடிவமைப்பில் ஒரு புதிய role=user <environment_context> செய்தியை செருகுகிறோம்.⁠(புதிய சாளரத்தில் திறக்கும்)

செயல்திறனை மேம்படுத்த கேச் ஹிட்களை உறுதிப்படுத்த நாங்கள் மிகுந்த முயற்சி செய்கிறோம். நாம் நிர்வகிக்க வேண்டிய மற்றொரு முக்கியமான வளம்: சூழல் சாளரம்.

சூழல் சாளரத்தை தீர்ந்து போகாமல் தடுக்க எங்களின் பொதுவான உத்தி, டோக்கன்களின் எண்ணிக்கை ஒரு குறிப்பிட்ட வரம்பை மீறும்போது உரையாடலை சுருக்குவது ஆகும். குறிப்பாக, உரையாடலை பிரதிநிதித்துவப்படுத்தும் புதிய, சிறிய உருப்படிகளின் பட்டியலுடன் input -ஐ நாங்கள் மாற்றுகிறோம், இதன் மூலம் இதுவரை என்ன நடந்துள்ளது என்பதைப் புரிந்துகொண்டு ஏஜென்ட் தொடர முடியும். ஆரம்ப காம்பாக்ஷனின் ⁠(புதிய சாளரத்தில் திறக்கும்)இயக்கத்திறன் பயனரை கைமுறையாக /compact கட்டளையை இயக்க வேண்டியதாக இருந்தது, இது ஏற்கனவே உள்ள உரையாடலுடன் கூடுதலாக சுருக்கம்⁠(புதிய சாளரத்தில் திறக்கும்) செய்வதற்கான தனிப்பயன் வழிமுறைகளைப் பயன்படுத்தி Responses API ஐ வினவியது. Codex, சுருக்கத்தைக் கொண்டிருந்த பெறப்பட்ட உதவியாளர் செய்தியை புதிய உள்ளீடாக⁠(புதிய சாளரத்தில் திறக்கும்) அடுத்தடுத்த உரையாடல் திருப்பங்களுக்கு பயன்படுத்தியது.

அதன் பின்னர், Responses API ஒரு சிறப்பு /responses/compact எண்ட்பாயிண்ட்⁠(புதிய சாளரத்தில் திறக்கும்) ஐ ஆதரிக்குமாறு வளர்ந்துள்ளது, இது சுருக்கத்தை மேலும் திறமையாகச் செய்கிறது. இது முந்தைய பயன்படுத்தக்கூடிய உருப்படிகளின் பட்டியலை⁠(புதிய சாளரத்தில் திறக்கும்) input க்கு பதிலாக திருப்பி அளிக்கிறது, இதன் மூலம் சூழல் சாளரத்தை காலியாக வைத்தபடியே உரையாடலைத் தொடர முடியும். இந்த பட்டியலில், அசல் உரையாடலைப் பற்றிய மாடலின் மறைமுகப் புரிதலைப் பாதுகாக்கும், தெளிவாகப் புரியாத encrypted_content உருப்படியுடன் கூடிய ஒரு சிறப்பு type=compaction உருப்படி அடங்கியுள்ளது. இப்போது, auto_compact_limit⁠(புதிய சாளரத்தில் திறக்கும்) மீறப்படும்போது, உரையாடலை சுருக்க Codex தானாகவே இந்த எண்ட்பாயிண்ட் பயன்படுத்துகிறது.

அடுத்ததாக வரும்

Codex ஏஜென்ட் லூப்பை நாங்கள் அறிமுகப்படுத்தியுள்ளோம் மற்றும் Codex ஒரு மாடலை வினவும்போது எவ்வாறு தனது சூழலை உருவாக்கி நிர்வகிக்கிறது என்பதை விளக்கியுள்ளோம். பயணத்தின் போக்கில், Responses API மீது ஏஜென்ட் லூப்பை உருவாக்கும் எவருக்கும் பொருந்தக்கூடிய நடைமுறை பரிந்துரைகள் மற்றும் சிறந்த நடைமுறைகளை நாங்கள் முன்னிறுத்தினோம்.

ஏஜென்ட் லூப் Codexக்கு அடித்தளத்தை வழங்கினாலும், இது தொடக்கம் மட்டுமே. வரவிருக்கும் பதிவுகளில், CLI-யின் கட்டமைப்பை ஆழமாக ஆராய்வோம், கருவி பயன்பாடு எவ்வாறு செயல்படுத்தப்படுகிறது என்பதை ஆராய்வோம், மேலும் Codex-ன் சாண்ட்பாக்சிங் மாடலை நெருக்கமாக கவனிப்போம்.

ஆசிரியர்

Michael Bolin

நன்றியுரை

Codex CLI-ஐ உருவாக்கிய முழு குழுவிற்கு சிறப்பு நன்றி.

தொடர்ந்து படிக்க

அனைத்தையும் பார்க்கவும்

Codex உடன் சுயமாக மேம்படும் வரி ஏஜென்ட்களை உருவாக்குதல்

என்ஜினியரிங்27 மே, 2026

Windows-இல் Codex-ஐ செயல்படுத்த பாதுகாப்பான, பயனுள்ள சாண்ட்பாக்ஸ் உருவாக்குதல்

என்ஜினியரிங்13 மே, 2026

Supercomputer networking to accelerate large scale AI training

என்ஜினியரிங்5 மே, 2026