Codex ഹാർനെസ് അൺലോക്ക് ചെയ്യുന്നു: ആപ്പ് സെർവർ നിര്മ്മിച്ചത്
സെലിയ ചെൻ, സാങ്കേതിക സ്റ്റാഫിലെ അംഗം
OpenAI-യുടെ കോഡിംഗ് ഏജന്റ് Codex പലവിധ ഉപരിതലങ്ങളിൽ ലഭ്യമാണ്: വെബ് ആപ്പ്(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), CLI(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), IDE എക്സ്റ്റൻഷൻ(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), കൂടാതെ പുതിയ Codex macOS ആപ്പ്. അകത്ത്, അവയെല്ലാം ഒരേ Codex ഹാർനെസ്—എല്ലാ Codex അനുഭവങ്ങൾക്കും അടിസ്ഥാനം നൽകുന്ന ഏജന്റ് ലൂപ്പും ലോജിക്കും—കൊണ്ട് പ്രവർത്തിക്കുന്നു. അവർക്കിടയിലെ നിർണായക ബന്ധം എന്താണ്? Codex ആപ്പ് സെർവർ(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു), ക്ലയന്റ്-സൗഹൃദവും ഇരുദിശയിലുള്ള JSON-RPC1 API.
ഈ പോസ്റ്റിൽ, ഞങ്ങൾ Codex ആപ്പ് സെർവർ അവതരിപ്പിക്കും; നിങ്ങളുടെ ഉപയോക്താക്കൾക്ക് അവരുടെ വർക്ക്ഫ്ലോകൾ കൂടുതൽ ശക്തമാക്കാൻ Codex ന്റെ കഴിവുകൾ നിങ്ങളുടെ ഉൽപ്പന്നത്തിലേക്ക് കൊണ്ടുവരാനുള്ള മികച്ച മാർഗങ്ങളെക്കുറിച്ച് ഇതുവരെ ഞങ്ങൾ പഠിച്ചതെല്ലാം പങ്കുവെക്കും. ഞങ്ങൾ ആപ്പ് സെർവറിന്റെ ആർക്കിടെക്ചറും പ്രോട്ടോക്കോളും, അത് വ്യത്യസ്ത Codex ഉപരിതലങ്ങളുമായി എങ്ങനെ സംയോജിപ്പിക്കപ്പെടുന്നു എന്നതും, കൂടാതെ Codex-നെ എങ്ങനെ പ്രയോജനപ്പെടുത്താം എന്നതിനെക്കുറിച്ചുള്ള ചില നിർദ്ദേശങ്ങളും ഉള്പ്പെടുത്തും —നിങ്ങൾ Codex-നെ ഒരു കോഡ് റിവ്യൂവർ, SRE ഏജന്റ്, അല്ലെങ്കിൽ കോഡിംഗ് അസിസ്റ്റന്റ് ആക്കാൻ ആഗ്രഹിക്കുന്നുവോ എന്നതിനെ ആശ്രയിക്കാതെ.
ആർക്കിടെക്ചറിലേക്ക് പ്രവേശിക്കുന്നതിന് മുമ്പ്, ആപ്പ് സെർവറിന്റെ പശ്ചാത്തലകഥ അറിയുന്നത് ഉപകാരപ്രദമാണ്. ആദ്യമായി, ഉൽപ്പന്നങ്ങളിലുടനീളം Codex ഹാർനെസ് പുനരുഉപയോഗിക്കാൻ ആപ്പ് സെർവർ ഒരു പ്രായോഗിക മാർഗമായിരുന്നു, അത് ക്രമേണ വികസിച്ച് ഞങ്ങളുടെ സ്റ്റാൻഡേർഡ് പ്രോട്ടോക്കോളായി മാറി.
Codex CLI ഒരു TUI (terminal user interface) ആയി ആരംഭിച്ചു, അതായത് Codex ടെർമിനൽ വഴി ആക്സസ് ചെയ്യപ്പെടുന്നു. ഞങ്ങൾ VS Code എക്സ്റ്റൻഷൻ (Codex ഏജന്റുകളുമായി കൂടുതൽ IDE-സൗഹൃദമായ രീതിയിൽ ഇടപഴകാൻ) നിർമ്മിച്ചപ്പോൾ, IDE UI-യിൽ നിന്ന് അതേ ഏജന്റ് ലൂപ്പ് പ്രവർത്തിപ്പിക്കാൻ ഹാർണസ് പിന്നെയും സ്ഥാപിക്കുന്നത് ഒഴിവാക്കി നിലവിലുള്ളത് തന്നെ ഉപയോഗിക്കുന്നതിനുള്ള ഒരു മാർഗം ആവശ്യമുണ്ടായിരുന്നു. വെറും റിക്വസ്റ്റ്/റെസ്പോൺസ് എന്നതിലുപരി, വർക്ക്സ്പേസ് എക്സ്പ്ലോർ ചെയ്യുക, ഏജന്റ് ചിന്തിക്കുന്നതിനനുസരിച്ച് പ്രോഗ്രസ് സ്ട്രീം ചെയ്യുക, മാറ്റങ്ങൾ (diffs) കാണിക്കുക എന്നിങ്ങനെയുള്ള വിപുലമായ ഇന്ററാക്ഷൻ രീതികൾ നൽകുക എന്നതാണ് ഇതിലൂടെ അർത്ഥമാക്കുന്നത്. ഞങ്ങൾ ആദ്യം Codex-നെ ഒരു MCP സെർവറായി എക്സ്പോസ് ചെയ്യുന്ന(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) രീതി പരീക്ഷിച്ചു, പക്ഷേ VS Code-ന് അർത്ഥവത്താകുന്ന രീതിയിൽ MCP സെമാന്റിക്സ് നിലനിർത്തുന്നത് ബുദ്ധിമുട്ടാണെന്ന് തെളിഞ്ഞു. പകരം, TUI ലൂപ്പിനെ പ്രതിഫലിപ്പിക്കുന്ന JSON-RPC പ്രോട്ടോക്കോൾ ഞങ്ങൾ അവതരിപ്പിച്ചു, അത് ആപ്പ് സെർവറിന്റെ അനൗദ്യോഗിക ആദ്യ പതിപ്പ്(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ആയി മാറി. ആ സമയത്ത്, മറ്റ് ക്ലയന്റുകൾ ആപ്പ് സെർവറിനെ ആശ്രയിക്കുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിച്ചിരുന്നില്ല, അതിനാൽ അത് സ്ഥിരതയുള്ള API ആയി രൂപകൽപ്പന ചെയ്തിരുന്നില്ല.
അടുത്ത കുറച്ച് മാസങ്ങളിൽ Codex ഏറ്റെടുക്കല് വർധിച്ചതോടെ, ഉപയോക്താക്കളുടെ സോഫ്റ്റ്വെയർ വികസന വർക്ക്ഫ്ലോകൾ വേഗത്തിലാക്കുന്നതിനായി അതേ ഹാർനെസ് അവരുടെ സ്വന്തം ഉൽപ്പന്നങ്ങളിൽ ഉൾപ്പെടുത്താനുള്ള കഴിവ് ആഭ്യന്തര ടീമുകളും ബാഹ്യ പങ്കാളികളും ആവശ്യപെട്ടു. ഉദാഹരണത്തിന്, JetBrains-ഉം Xcode-ഉം IDE-ഗ്രേഡ് ഏജന്റ് അനുഭവം ആഗ്രഹിച്ചു, അതേസമയം Codex ഡെസ്ക്ടോപ്പ് ആപ്പിന് നിരവധി Codex ഏജന്റുകളെ സമാന്തരമായി ഓർക്കസ്ട്രേറ്റ് ചെയ്യേണ്ടതുണ്ടായിരുന്നു. ആ ആവശ്യങ്ങൾ ഞങ്ങളെ, ഞങ്ങളുടെ ഉൽപ്പന്നങ്ങളും പങ്കാളി സംയോജനങ്ങളും കാലക്രമേണ സുരക്ഷിതമായി ആശ്രയിക്കാനാകുന്ന ഒരു പ്ലാറ്റ്ഫോം ഉപരിതലം രൂപകൽപ്പന ചെയ്യാൻ പ്രേരിപ്പിച്ചു. ഇത് സംയോജിപ്പിക്കാൻ എളുപ്പവും പഴയതിനും അനുയോജ്യമായിരിക്കണം, അങ്ങനെ നിലവിലുള്ള ക്ലയന്റുകളെ തകർക്കാതെ പ്രോട്ടോക്കോൾ വികസിപ്പിക്കാൻ ഞങ്ങൾക്ക് കഴിയും.
അടുത്തതായി, വ്യത്യസ്ത ക്ലയന്റുകൾക്ക് ഒരേ ഹാർനെസ് ഉപയോഗിക്കാനാകുന്ന വിധത്തിൽ ഞങ്ങൾ ആർക്കിടെക്ചറും പ്രോട്ടോക്കോളും എങ്ങനെ രൂപകൽപ്പന ചെയ്തുവെന്ന് നമുക്ക് വിശദമായി പരിശോധിക്കാം.
ആദ്യം, Codex ഹാർനെസിന്റെ ഉള്ളിലുള്ളത് എന്താണെന്ന്, Codex ആപ്പ് സെർവര് അത് ഉപഭോക്താക്കൾക്ക് എങ്ങനെ ലഭ്യമാക്കുന്നുവെന്ന് നമുക്ക് അടുത്തുനിന്നു നോക്കാം. ഞങ്ങളുടെ കഴിഞ്ഞ Codex ബ്ലോഗിൽ, ഉപയോക്താവ്, മോഡൽ, ടൂളുകള് എന്നിവ തമ്മിലുള്ള ഇടപെടൽ ഏകോപിപ്പിക്കുന്ന പ്രധാന ഏജന്റ് ലൂപ്പ് ഞങ്ങൾ വിശദമായി വിശദീകരിച്ചു. ഇത് Codex ഹാർനെസിന്റെ കോർ ലോജിക്കാണ്, പക്ഷേ പൂർണ്ണമായ ഏജന്റ് അനുഭവത്തിൽഇനിയും ഘടകങ്ങള് ഉണ്ട്:
1. ത്രെഡിന്റെ ജീവിതചക്രവും നിലനിൽപ്പും. ഒരു ത്രെഡ് എന്നത് ഉപയോക്താവും ഏജന്റും തമ്മിലുള്ള Codex സംഭാഷണമാണ്. Codex ത്രെഡുകൾ സൃഷ്ടിക്കുകയും പുനരാരംഭിക്കുകയും, ഫോർക്കുകൾ സൃഷ്ടിക്കുകയും, ആർക്കൈവ് ചെയ്യുകയും, ഇവന്റ് ചരിത്രം നിലനിർത്തുകയും ചെയ്യുന്നു, അതുവഴി ക്ലയന്റുകൾക്ക് വീണ്ടും കണക്റ്റ് ചെയ്ത് ഒരു ഏകീകൃത ടൈംലൈൻ റെൻഡർ ചെയ്യാൻ കഴിയും.
2. കോൺഫിഗറേഷൻ ഓതന്റിക്കേഷൻ. Codex കോൺഫിഗറേഷൻ ലോഡ് ചെയ്യുന്നു, ഡിഫോൾട്ടുകൾ മാനേജ് ചെയ്യുന്നു, കൂടാതെ ക്രെഡൻഷ്യൽ സ്റ്റേറ്റ് ഉൾപ്പെടെ “Sign in with ChatGPT” പോലുള്ള ഓതന്റിക്കേഷൻ ഫ്ലോകൾ പ്രവർത്തിപ്പിക്കുന്നു.
3. ടൂള് നിർവഹണവും വിപുലീകരണങ്ങളും. Codex ഷെൽ/ഫയൽ ടൂളുകൾ ഒരു സാൻഡ്ബോക്സിൽ പ്രവർത്തിപ്പിക്കുകയും MCP സെർവറുകളും സ്കിൽസും പോലുള്ള ഇന്റഗ്രേഷനുകൾ ബന്ധിപ്പിക്കുകയും ചെയ്യുന്നു, അതുവഴി അവയ്ക്ക് ഒരു ഏകീകൃത നയ-മോഡലിന്റെ കീഴിൽ ഏജന്റ് ലൂപ്പിൽ പങ്കാളികളാകാൻ കഴിയും.
ഇവിടെ ഞങ്ങൾ പരാമർശിച്ച എല്ലാ ഏജന്റ് ലോജിക്കും, കോർ ഏജന്റ് ലൂപ്പ് ഉൾപ്പെടെ, “Codex കോർ(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)” എന്ന് വിളിക്കുന്ന Codex CLI കോഡ്ബേസിലെ ഒരു ഭാഗത്താണ് സ്ഥിതി ചെയ്യുന്നത്. Codex core എന്നത് എല്ലാ ഏജന്റ് കോഡും നിലനിൽക്കുന്ന ഒരു ലൈബ്രറിയും, ഏജന്റ് ലൂപ്പ് പ്രവർത്തിപ്പിക്കാനും Codex ത്രെഡ് (സംഭാഷണം) ന്റെ സ്ഥിരത കൈകാര്യം ചെയ്യാനും സ്പിൻ അപ്പ് ചെയ്യാവുന്ന ഒരു റൺടൈമും ആണ്.
ഉപയോഗപ്രദമാകാൻ, Codex ഹാർനെസ് ക്ലയന്റുകൾക്ക് ആക്സസ് ചെയ്യാൻ കഴിയുന്ന തരത്തിലായിരിക്കണം. അവിടെയാണ് ആപ്പ് സെർവർ വരുന്നത്.
ആപ്പ് സെർവർ എന്നത് ക്ലയന്റും സെർവറും തമ്മിലുള്ള JSON-RPC പ്രോട്ടോക്കോളും Codex കോർ ത്രെഡുകൾ ഹോസ്റ്റ് ചെയ്യുന്ന ദീർഘകാല പ്രക്രിയയുമാണ്. മുകളിലെ ഡയഗ്രാമിൽ നിന്ന് നമുക്ക് കാണാനാകുന്നതുപോലെ, ഒരു ആപ്പ് സെർവർ പ്രോസസിന് നാല് പ്രധാന ഘടകങ്ങളുണ്ട്: stdio റീഡർ, Codex സന്ദേശ പ്രോസസർ, ത്രെഡ് മാനേജർ, കോർ ത്രെഡുകൾ. ത്രെഡ് മാനേജർ ഓരോ ത്രെഡിനും ഒരു കോർ സെഷൻ ആരംഭിക്കുന്നു, തുടർന്ന് Codex മെസേജ് പ്രോസസർ ഓരോ കോർ സെഷനുമായും നേരിട്ട് ആശയവിനിമയം നടത്തി ക്ലയന്റ് അഭ്യർത്ഥനകൾ സമർപ്പിക്കുകയും അപ്ഡേറ്റുകൾ സ്വീകരിക്കുകയും ചെയ്യുന്നു.
ഒരു ക്ലയന്റ് അഭ്യർത്ഥന പല ഇവന്റ് അപ്ഡേറ്റുകൾക്ക് കാരണമാകാം, കൂടാതെ ഈ വിശദമായ ഇവന്റുകളാണ് ആപ്പ് സെർവറിന്റെ മുകളിൽ സമ്പന്നമായ ഒരു UI നിർമ്മിക്കാൻ ഞങ്ങളെ അനുവദിക്കുന്നത്. കൂടാതെ, stdio റീഡറും കോഡെക്സ് മെസേജ് പ്രോസസറും ക്ലയന്റിനും കോഡെക്സ് കോർ ത്രെഡുകൾക്കും ഇടയിൽ വിവർത്തന ലെയറായി പ്രവർത്തിക്കുന്നു. അവർ ക്ലയന്റ് JSON-RPC അഭ്യർത്ഥനകളെ Codex കോർ പ്രവർത്തനങ്ങളാക്കി വിവർത്തനം ചെയ്യുന്നു, Codex കോറിന്റെ ആന്തരിക ഇവന്റ് സ്ട്രീം കേൾക്കുന്നു, തുടർന്ന് ആ താഴ്ന്ന-നില ഇവന്റുകളെ ചെറിയൊരു സ്ഥിരതയുള്ള, UI-യ്ക്ക് തയ്യാറായ JSON-RPC അറിയിപ്പുകളുടെ ഒരു ചെറിയ സെറ്റായി മാറ്റുന്നു.
ക്ലയന്റിനും ആപ്പ് സെർവറിനും ഇടയിലുള്ള JSON-RPC പ്രോട്ടോക്കോൾ പൂർണ്ണമായും ഇരുവശങ്ങളിലേക്കും പ്രവർത്തിക്കുന്നു. ഒരു സാധാരണ ത്രെഡിൽ ഒരു ക്ലയന്റ് അഭ്യർത്ഥനയും നിരവധി സെർവർ അറിയിപ്പുകളും ഉണ്ടാകും. കൂടാതെ, ഏജന്റിന് അംഗീകാരം പോലുള്ള ഇൻപുട്ട് ആവശ്യമായപ്പോൾ സെർവർ അഭ്യർത്ഥനകൾ ആരംഭിക്കാനും, തുടർന്ന് ക്ലയന്റ് പ്രതികരിക്കുന്നതുവരെ ടേൺ താൽക്കാലികമായി നിർത്തിവെക്കാനും കഴിയും.
അടുത്തതായി, ആപ്പ് സെർവർ പ്രോട്ടോക്കോളിന്റെ നിർമാണഘടകങ്ങളായ സംഭാഷണ പ്രിമിറ്റീവുകൾ ഞങ്ങൾ ഒന്നൊന്നായി വിശദീകരിക്കും. ഏജന്റ് ലൂപ്പിനായി ഒരു API രൂപകൽപ്പന ചെയ്യുന്നത് പ്രയാസകരമാണ്, കാരണം ഉപയോക്താവ്/ഏജന്റ് ഇടപെടൽ ഒരു ലളിതമായ അഭ്യർത്ഥന/പ്രതികരണം അല്ല. ഒരു ഉപയോക്തൃ അഭ്യർത്ഥന ക്ലയന്റ് വിശ്വസ്തമായി പ്രതിനിധീകരിക്കേണ്ട ഘടനാപരമായ പ്രവർത്തനങ്ങളുടെ ഒരു ക്രമമായി വികസിക്കാം: ഉപയോക്താവിന്റെ ഇൻപുട്ട്, ഏജന്റിന്റെ ക്രമാനുഗത പുരോഗതി, വഴിമധ്യേ സൃഷ്ടിക്കപ്പെടുന്ന ആർട്ടിഫാക്റ്റുകൾ (ഉദാ., വ്യത്യാസങ്ങൾ). ആ ഇന്ററാക്ഷൻ സ്ട്രീം UI-കളിലുടനീളം എളുപ്പത്തിൽ സംയോജിപ്പിക്കുകയും പ്രതിരോധശേഷിയുള്ളതാക്കുകയും ചെയ്യാൻ, വ്യക്തമായ അതിർത്തികളും ജീവിതചക്രങ്ങളും ഉള്ള മൂന്ന് പ്രധാന പ്രാഥമിക ഘടകങ്ങളിലേക്ക് ഞങ്ങൾ എത്തിച്ചേർന്നിരിക്കുന്നു:
1. ഇനം: ഒരു ഇനം Codex-ൽ ഇൻപുട്ട്/ഔട്ട്പുട്ടിന്റെ അടിസ്ഥാന ഘടകമാണ്. ഇനങ്ങൾ ടൈപ്പ് ചെയ്തവയാണ് (ഉദാ., ഉപയോക്തൃ സന്ദേശം, ഏജന്റ് സന്ദേശം, ടൂൾ നിർവഹണം, അംഗീകാര അഭ്യർത്ഥന, വ്യത്യാസം) കൂടാതെ ഓരോന്നിനും വ്യക്തമായ ഒരു ജീവിതചക്രം ഉണ്ട്:
item/startedഇനം ആരംഭിക്കുമ്പോൾ- സ്ട്രീമിംഗ് ഇനം തരങ്ങൾക്കായി) ഉള്ളടക്ക സ്ട്രീമുകളായി (വരുമ്പോൾ) ഓപ്ഷണൽ
ഇനം/*/ഡെൽറ്റഇവന്റുകൾ item/completedഇനം അതിന്റെ അന്തിമ പേലോഡോടെ പൂർത്തിയാകുമ്പോൾ
ഈ ലൈഫ്സൈക്കിൾ ഉപഭോക്താക്കൾക്ക് started ൽ ഉടൻ തന്നെ റെൻഡറിംഗ് ആരംഭിക്കാനും, delta ൽ ക്രമാനുഗത അപ്ഡേറ്റുകൾ സ്ട്രീം ചെയ്യാനും, completed ൽ അന്തിമമാക്കാനും അനുവദിക്കുന്നു.
2. ടേൺ: ടേൺ എന്നത് ഒരു യുസര് നല്കുന്ന ഇന്പുട്ടിന്റെ ഫലമായി ഉണ്ടാകുന്ന ഏജന്റ് പ്രവർത്തനത്തിന്റെ അളവാണ്. ക്ലയന്റ് ഒരു ഇൻപുട്ട് സമർപ്പിക്കുമ്പോൾ (ഉദാഹരണത്തിന്, “ടെസ്റ്റുകൾ പ്രവർത്തിപ്പിച്ച് പരാജയങ്ങൾ സംഗ്രഹിക്കുക” എന്നാ ഇന്പുട്ട്) ഈ പ്രക്രിയ ആരംഭിക്കുകയും, ആ ഇൻപുട്ടിനായി ഏജന്റ് ഔട്ട്പുട്ടുകൾ ഉത്പാദിപ്പിച്ചു കഴിയുമ്പോള് പ്രക്രിയ അവസാനിക്കുകയും ചെയ്യുന്നു. ഒരു ടേൺ എന്നത് പൂര്ണമായ ഒരു ഔട്ട് പുട്ടിന് ഇടയ്ക്കുള്ള ഘട്ടങ്ങളും അവ സൃഷ്ടിക്കുന്ന താല്ക്കാലിക ഔട്ട്പുട്ടുകളെയും പ്രതിനിധീകരിക്കുന്ന ഒരു ശ്രേണിയാണ്.
3. ത്രെഡ്: ഒരു ഉപയോക്താവിനും ഏജന്റിനും ഇടയിൽ തുടരുന്ന Codex സെഷനിൽ ദീർഘകാലം നിലനിൽക്കുന്ന കണ്ടെയ്നറാണ് ത്രെഡ്. ഇതിൽ ഒന്നിലധികം ടേൺ അടങ്ങിയിരിക്കുന്നു. ത്രെഡുകൾ സൃഷ്ടിക്കാനും, പുനരാരംഭിക്കാനും, വിഭജിക്കാനും, ആർക്കൈവ് ചെയ്യാനും കഴിയും. ക്ലയന്റുകൾക്ക് വീണ്ടും കണക്റ്റ് ചെയ്ത് സ്ഥിരതയുള്ള ടൈംലൈൻ റെൻഡർ ചെയ്യാൻ കഴിയുന്നതിനായി ത്രെഡ് ചരിത്രം സ്ഥിരമായി സംഭരിക്കുന്നു.
ഇപ്പോൾ, ഒരു ക്ലയന്റും ഒരു ഏജന്റും തമ്മിലുള്ള ലളിതമാക്കിയ സംഭാഷണം നമുക്ക് പരിശോധിക്കാം, അവിടെ സംഭാഷണം പ്രിമിറ്റീവുകൾ ഉപയോഗിച്ച് പ്രതിനിധീകരിച്ചിരിക്കുന്നു:
സംഭാഷണം ആരംഭിക്കുമ്പോൾ, ക്ലയന്റും സെർവറും ആരംഭ ഹാൻഡ്ഷേക്ക് സ്ഥാപിക്കേണ്ടതുണ്ട്. ക്ലയന്റ് ഏറ്റവും ആദ്യം തന്നെ ഒരു ഒറ്റ ആരംഭ അഭ്യർത്ഥന അയയ്ക്കണം, സെർവർ മറുപടിയോടെ അത് അംഗീകരിക്കുന്നു. ഇത് സർവറിന് കഴിവുകൾ പരസ്യപ്പെടുത്താൻ ഒരു അവസരം നൽകുകയും യഥാർത്ഥ ജോലി ആരംഭിക്കുന്നതിന് മുമ്പ് പ്രോട്ടോക്കോൾ വേർഷനിംഗ്, ഫീച്ചർ ഫ്ലാഗുകൾ, ഡീഫോൾട്ടുകൾ എന്നിവയിൽ ഇരുവശവും ധാരണയിലെത്താൻ അനുവദിക്കുകയും ചെയ്യുന്നു. OpenAI-യുടെ VS Code എക്സ്റ്റൻഷനിൽ നിന്നുള്ള ഉദാഹരണ പേലോഡ് ഇതാ:
ഇതാ സെർവർ തിരികെ നൽകുന്നത്:
ഒരു ക്ലയന്റ് ഒരു പുതിയ അഭ്യർത്ഥന നടത്തുമ്പോൾ, ആദ്യം ഒരു ത്രെഡ് സൃഷ്ടിക്കുകയും തുടർന്ന് ഒരു ടേൺ സൃഷ്ടിക്കുകയും ചെയ്യും. സെർവർ പുരോഗതിയുടെ അറിയിപ്പുകൾ തിരികെ അയയ്ക്കും (thread/started ഉം turn/started)ഉം. ഇത് ഇവിടെ ഉള്ള ഉപയോക്തൃ സന്ദേശം പോലെ, ഇനങ്ങളായി രജിസ്റ്റർ ചെയ്യുന്ന ഇൻപുട്ടുകളും തിരികെ അയക്കും.
ടൂള് കോളുകള് ഇനങ്ങളായി ഉപഭോക്താവിന് തിരികെ അയയ്ക്കപ്പെടുന്നു. കൂടാതെ, ഒരു സെർവർ അഭ്യർത്ഥന അയച്ച് ഒരു നടപടി നടത്തുന്നതിന് മുമ്പ് സെർവർ ഉപഭോക്താവിന്റെ അംഗീകാരം തേടാം. അംഗീകാരം ഉപഭോക്താവ് “അനുവദിക്കുക” അല്ലെങ്കിൽ “നിരസിക്കുക” എന്ന് മറുപടി നൽകുന്നതുവരെ ടേൺ താൽക്കാലികമായി നിർത്തിവെക്കും. ഇത് VS Code എക്സ്റ്റൻഷനിൽ അംഗീകാര പ്രവാഹം എങ്ങനെയാണെന്ന് കാണിക്കുന്നു:

അവസാനമായി, സെർവർ ഒരു ഏജന്റ് സന്ദേശം അയയ്ക്കുകയും turn/completed ഉപയോഗിച്ച് ടേൺ അവസാനിപ്പിക്കുകയും ചെയ്യുന്നു. ഏജന്റ് സന്ദേശത്തിന്റെ ഡെൽറ്റ ഇവന്റുകളുടെ സ്ട്രീം സന്ദേശം item/completed ഉപയോഗിച്ച് അന്തിമമാക്കുന്നതുവരെ സന്ദേശത്തിന്റെ ഭാഗങ്ങൾ തിരികെ സ്ട്രീം ചെയ്യുന്നു.
ഡയഗ്രത്തിലെ സന്ദേശങ്ങൾ വായനാസൗകര്യത്തിനായി ലളിതമാക്കിയിരിക്കുന്നു. നിങ്ങൾക്ക് ഒരു പൂർണ്ണ ടേണിനുള്ള JSON കാണണമെങ്കിൽ, Codex CLI റീപോയിൽ നിന്ന് ടെസ്റ്റ് ക്ലയന്റ് പ്രവർത്തിപ്പിച്ച് അത് കാണാം:
ഇപ്പോൾ, വ്യത്യസ്ത ക്ലയന്റ് ഉപരിതലങ്ങൾ ആപ്പ് സെർവർ വഴി Codex എങ്ങനെ ഉൾക്കൊള്ളുന്നു എന്ന് നോക്കാം. ഞങ്ങൾ ഇവിടെ മൂന്ന് പാറ്റേണുകൾ ഉള്പ്പെടുത്തുന്നു: ലോക്കൽ ആപ്പുകളും IDEകളും, Codex വെബ് റൺടൈം, കൂടാതെ TUI.
മൂന്നിലും, ട്രാൻസ്പോർട്ട് JSON-RPC stdio (JSONL) വഴി ആണ്. JSON-RPC നിങ്ങൾക്ക് ഇഷ്ടമുള്ള ഭാഷയിൽ ക്ലയന്റ് ബൈൻഡിംഗുകൾ നിർമ്മിക്കുന്നത് എളുപ്പമാക്കുന്നു. Codex ഉപരിതലങ്ങളും പങ്കാളി ഇന്റഗ്രേഷനുകളും Go, Python, TypeScript, Swift, Kotlin എന്നിവ ഉൾപ്പെടെയുള്ള ഭാഷകളിൽ ആപ്പ് സെർവർ ക്ലയന്റുകൾ നടപ്പിലാക്കി. TypeScript-നായി, റസ്റ്റ് പ്രോട്ടോക്കോളിൽ നിന്ന് നേരിട്ട് നിർവചനങ്ങൾ സൃഷ്ടിക്കാൻ, താഴെ പറയുന്ന കമാൻഡ് പ്രവർത്തിപ്പിക്കുക:
മറ്റ് ഭാഷകൾക്കായി, നിങ്ങൾക്ക് ഒരു JSON സ്കീമ ബണ്ടിൽ സൃഷ്ടിച്ച് നിങ്ങളുടെ ഇഷ്ടപ്പെട്ട കോഡ് ജനറേറ്ററിലേക്ക് നൽകാൻ കഴിയും:

പ്രാദേശിക ക്ലയന്റുകൾ സാധാരണയായി പ്ലാറ്റ്ഫോം-സ്പെസിഫിക് ആപ്പ് സെർവർ ബൈനറി പാക്ക് ചെയ്യുകയോ ഡൗൺലോഡ് ചെയ്യുകയോ ചെയ്യുന്നു, അത് ദീർഘകാലം പ്രവർത്തിക്കുന്ന ഒരു ചൈൽഡ് പ്രോസസായി ആരംഭിക്കുന്നു, കൂടാതെ JSON-RPC-ക്കായി ഒരു ബൈഡിറെക്ഷണൽ stdio ചാനൽ തുറന്ന നിലയിൽ നിലനിർത്തുന്നു. ഉദാഹരണത്തിന്, ഞങ്ങളുടെ VS Code എക്സ്റ്റൻഷനിലും ഡെസ്ക്ടോപ്പ് ആപ്പിലും, ഷിപ്പ് ചെയ്യുന്ന ആർട്ടിഫാക്റ്റിൽ പ്ലാറ്റ്ഫോം-സ്പെസിഫിക് Codex ബൈനറി ഉൾപ്പെടുന്നു, കൂടാതെ അത് ടെസ്റ്റ് ചെയ്ത ഒരു പതിപ്പിലേക്ക് പിന് ചെയ്തിരിക്കുന്നു, അതിനാൽ ഉപഭോക്താവ് ഞങ്ങൾ സാധൂകരിച്ച അതേ ബിറ്റുകൾ തന്നെ എല്ലായ്പ്പോഴും പ്രവർത്തിപ്പിക്കുന്നു.
എല്ലാ സംയോജനങ്ങൾക്കും ക്ലയന്റ് അപ്ഡേറ്റുകൾ പതിവായി അയയ്ക്കാൻ കഴിയില്ല. Xcode പോലുള്ള ചില പങ്കാളികൾ ക്ലയന്റിനെ സ്ഥിരതയോടെ നിലനിർത്തി, ആവശ്യമായപ്പോൾ പുതിയ ആപ്പ് സെർവർ ബൈനറിയിലേക്ക് സൂചിപ്പിക്കാൻ അനുവദിച്ച് റിലീസ് ചക്രങ്ങളെ വേർതിരിക്കുന്നു. അങ്ങനെ അവർക്ക് സെർവർ-സൈഡ് മെച്ചപ്പെടുത്തലുകൾ (ഉദാഹരണത്തിന്, Codex കോറിൽ മികച്ച ഓട്ടോ-കമ്പാക്ഷൻ അല്ലെങ്കിൽ പുതുതായി പിന്തുണയ്ക്കുന്ന കോൺഫിഗറേഷൻ കീകൾ) സ്വീകരിക്കുകയും ക്ലയന്റ് റിലീസിനായി കാത്തിരിക്കാതെ ബഗ് പരിഹാരങ്ങൾ പുറത്തിറക്കുകയും ചെയ്യാം. ആപ്പ് സെർവറിന്റെ JSON-RPC ഉപരിതലം മുന്കാല പൊരുത്തപ്പെടൽ നിലനിർത്തുന്ന രീതിയിലാണ് രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്, അതിനാൽ പഴയ ക്ലയന്റുകൾക്ക് പുതിയ സെർവറുകളുമായി സുരക്ഷിതമായി ആശയവിനിമയം നടത്താൻ കഴിയും.

Codex വെബ് കോഡെക്സ് ഹാർനെസ് ഉപയോഗിക്കുന്നു, പക്ഷേ അത് ഒരു കണ്ടെയ്നർ പരിതസ്ഥിതിയിൽ പ്രവർത്തിക്കുന്നു. ഒരു തൊഴിലാളി ചെക്ക്-ഔട്ട് ചെയ്ത വർക്ക്സ്പേസ് ഉപയോഗിച്ച് ഒരു കണ്ടെയ്നർ സജ്ജീകരിക്കുന്നു, അതിനുള്ളിൽ ആപ്പ് സെർവർ ബൈനറി ആരംഭിക്കുന്നു, കൂടാതെ stdio2 ചാനലിലൂടെ ദീർഘകാല JSON-RPC നിലനിർത്തുന്നു. വെബ് ആപ്പ് (ഉപയോക്താവിന്റെ ബ്രൗസർ ടാബിൽ പ്രവർത്തിക്കുന്നത്) HTTP-യും SSE-യും വഴി Codex ബാക്ക്എൻഡുമായി ആശയവിനിമയം നടത്തുന്നു, ഇത് വർക്കർ നിർമ്മിക്കുന്ന ടാസ്ക് ഇവന്റുകൾ സ്ട്രീം ചെയ്യുന്നു. ഇത് ബ്രൗസർ-സൈഡ് UI ലഘുവായി നിലനിർത്തുന്നതിനൊപ്പം, ഡെസ്ക്ടോപ്പിലും വെബിലും ഒരേപോലുള്ള റൺടൈം നൽകുന്നു.
വെബ് സെഷനുകൾ ക്ഷണികമായതിനാൽ (ടാബുകൾ അടയ്ക്കുന്നു, നെറ്റ്വർക്കുകൾ വിച്ഛേദിക്കുന്നു), ദീർഘകാലം പ്രവർത്തിക്കുന്ന ടാസ്കുകൾക്കായി വെബ് ആപ്പ് വിശ്വസനീയമായ ഉറവിടമാകാൻ കഴിയില്ല. സെർവറിൽ സ്റ്റേറ്റും പുരോഗതിയും നിലനിർത്തുന്നത് ടാബ് അപ്രത്യക്ഷമായാലും പ്രവർത്തനം തുടരാൻ സാധിക്കും. സ്ട്രീമിംഗ് പ്രോട്ടോക്കോളും സേവ് ചെയ്ത ത്രെഡ് സെഷനുകളും പുതിയ സെഷന് വീണ്ടും കണക്റ്റ് ചെയ്യാനും, ഉപേക്ഷിച്ചിടത്ത് നിന്ന് തുടർന്നെടുക്കാനും, ക്ലയന്റിൽ സ്റ്റേറ്റ് പുനർനിർമ്മിക്കാതെ തന്നെ പുനഃസ്ഥാപിക്കാനും എളുപ്പമാക്കുന്നു.

ചരിത്രപരമായി, TUI ഒരു “നേറ്റീവ്” ക്ലയന്റായിരുന്നു, അത് ഏജന്റ് ലൂപ്പിനൊപ്പം അതേ പ്രോസസിൽ പ്രവർത്തിക്കുകയും ആപ്പ്-സെർവർ പ്രോട്ടോക്കോളിനേക്കാൾ റസ്റ്റ് കോർ ടൈപ്പുകളുമായി ആശയവിനിമയം നടത്തുകയും ചെയ്തു. അത് ആദ്യകാല ആവർത്തനത്തെ വേഗത്തിലാക്കി, പക്ഷേ അതിനൊപ്പം TUI ഒരു പ്രത്യേക-കേസ് ഉപരിതലമായി മാറി.
ഇപ്പോൾ ആപ്പ് സെർവർ നിലവില് വന്ന ശേഷം, TUI റീഫാക്ടർ ചെയ്യാൻ(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഞങ്ങൾ പദ്ധതിയിടുന്നു, അതുവഴി അത് മറ്റേതൊരു ക്ലയന്റിനെയും പോലെ പ്രവർത്തിക്കും: ആപ്പ് സെർവർ ചൈൽഡ് പ്രോസസ് ആരംഭിക്കുക, stdio വഴി JSON-RPC സംസാരിക്കുക, അതേ സ്ട്രീമിംഗ് ഇവന്റുകളും അംഗീകാരങ്ങളും റെൻഡർ ചെയ്യുക. ഇത് TUI-ന് ഒരു റിമോട്ട് മെഷീനിൽ പ്രവർത്തിക്കുന്ന Codex സർവറുമായി ബന്ധപ്പെടാൻ കഴിയുന്ന വർക്ക്ഫ്ലോകുകൾ തുറക്കുന്നു, കംപ്യൂട്ടറിനോട് അടുത്തായി ഏജന്റിനെ നിലനിർത്തുകയും ലാപ്ടോപ്പ് സ്ലീപിലായാലും അല്ലെങ്കിൽ ബന്ധം വിച്ഛേദിച്ചാലും പ്രവർത്തനം തുടരുകയും ചെയ്യുന്നു, അതേസമയം പ്രാദേശികമായി തത്സമയ അപ്ഡേറ്റുകളും നിയന്ത്രണങ്ങളും നൽകുന്നു.
Codex ആപ്പ് സെർവർ ഞങ്ങൾ മുന്നോട്ട് പോകുമ്പോൾ പരിപാലിക്കുന്ന പ്രഥമക്ലാസ് ഇന്റഗ്രേഷൻ രീതിയായിരിക്കും, എന്നാൽ കൂടുതൽ പരിമിതമായ പ്രവർത്തനക്ഷമതയുള്ള മറ്റ് രീതികളും ഉണ്ട്. സ്വാഭാവികമായി, ഞങ്ങൾ ക്ലയന്റുകൾക്ക് Codex-നൊപ്പം സംയോജിപ്പിക്കാൻ Codex ആപ്പ് സെർവർ ഉപയോഗിക്കാൻ ശുപാർശ ചെയ്യുന്നു, എന്നാൽ വ്യത്യസ്ത സംയോജനം രീതികൾ പരിശോധിക്കുകയും അവയുടെ ഗുണങ്ങളും ദോഷങ്ങളും മനസ്സിലാക്കുകയും ചെയ്യുന്നത് മൂല്യമുള്ളതാണ്. Codex പ്രവർത്തിപ്പിക്കുന്നതിനുള്ള ഏറ്റവും സാധാരണമായ മാർഗങ്ങളും ഓരോന്നും എപ്പോൾ നല്ല അനുയോജ്യമായിരിക്കാമെന്ന് താഴെ കൊടുത്തിരിക്കുന്നു.
codex mcp-server(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) പ്രവർത്തിപ്പിക്കുക, stdio സെർവറുകൾ പിന്തുണയ്ക്കുന്ന ഏതെങ്കിലും MCP ക്ലയന്റിൽ നിന്ന് കണക്റ്റ് ചെയ്യുക (ഉദാഹരണത്തിന്, OpenAI Agents SDK(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)). നിങ്ങൾക്ക് ഇതിനകം MCP-അടിസ്ഥാനത്തിലുള്ള ഒരു വർക്ക്ഫ്ലോ ഉണ്ടെങ്കിൽ, Codex-നെ വിളിക്കാവുന്ന ഒരു ടൂളായി ഇൻവോക്ക് ചെയ്യാൻ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, ഇത് നല്ലൊരു തിരഞ്ഞെടുപ്പാണ്. നിങ്ങൾക്ക് MCP പുറത്തുവിടുന്നതു മാത്രമേ ദോഷമായി വരികയുള്ളു; അതിനാൽ കൂടുതൽ സമ്പന്നമായ സെഷൻ സെമാന്റിക്സിനെ ആശ്രയിക്കുന്ന Codex-സ്പെസിഫിക് ഇടപെടലുകൾ (ഉദാ., വ്യത്യാസം അപ്ഡേറ്റുകൾ) MCP എൻഡ്പോയിന്റുകൾ വഴി ശുദ്ധമായി മാപ്പ് ചെയ്യപ്പെടണമെന്നില്ല.
ചില ഇക്കോസിസ്റ്റങ്ങൾ പല മോഡൽ ദാതാക്കളെയും റൺടൈമുകളെയും ലക്ഷ്യമിടാൻ കഴിയുന്ന പോർട്ടബിൾ ഇന്റർഫേസ് നൽകുന്നു. നിങ്ങൾക്ക് ഒന്നിലധികം ഏജൻ്റുകളെ ഏകോപിപ്പിക്കുന്ന ഒരു അബ്സ്ട്രാക്ഷൻ വേണമെങ്കിൽ, ഇത് നല്ലൊരു തിരഞ്ഞെടുപ്പായിരിക്കും. പൊതുവായ ഫീച്ചറുകൾക്ക് മാത്രം മുൻഗണന നൽകുന്നതിലൂടെ കൂടുതൽ വിപുലമായ ഇന്ററാക്ഷനുകൾ അവതരിപ്പിക്കുന്നത് പ്രയാസകരമായേക്കാം എന്നതാണ് ഇതിന്റെ പരിമിതി; പ്രത്യേകിച്ചും ഓരോ പ്രൊവൈഡറുടെയും ടൂൾ, സെഷൻ സെമാന്റിക്സ് എന്നിവ പ്രധാനമാകുമ്പോൾ. ഈ മേഖല വേഗത്തിൽ വികസിച്ചുകൊണ്ടിരിക്കുകയാണ്, യഥാർത്ഥ ലോകത്തിലെ ഏജന്റ് പ്രവാഹങ്ങൾ പ്രതിനിധീകരിക്കാൻ ഏറ്റവും മികച്ച അടിസ്ഥാന ഘടകങ്ങൾ കണ്ടെത്തുന്നതിനിടെ കൂടുതൽ പൊതുവായ മാനദണ്ഡങ്ങൾ ഉയർന്നുവരുമെന്ന് ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു (സ്കിൽസ്(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു) ഇതിന് ഒരു നല്ല ഉദാഹരണമാണ്).
നിങ്ങൾക്ക് പൂർണ്ണ Codex ഹാർനെസ് ഒരു സ്ഥിരതയുള്ള, UI-സൗഹൃദ ഇവന്റ് സ്ട്രീമായി എക്സ്പോസ് ചെയ്യണമെങ്കിൽ, ആപ്പ് സെർവർ തിരഞ്ഞെടുക്കുക. നിങ്ങൾക്ക് ഏജന്റ് ലൂപ്പിന്റെ പൂർണ്ണ പ്രവർത്തനക്ഷമതയും Sign in with ChatGPT, മോഡൽ കണ്ടെത്തൽ, കോൺഫിഗറേഷൻ മാനേജ്മെന്റ് എന്നിവ പോലുള്ള മറ്റ് പിന്തുണയ്ക്കുന്ന സവിശേഷതകളും ലഭിക്കും. പ്രധാന ചെലവ് സംയോജനം പ്രാവര്ത്തികമക്കാനാണ്, കാരണം നിങ്ങളുടെ ഭാഷയിൽ ക്ലയന്റ്-സൈഡ് JSON-RPC ബൈൻഡിംഗ് നിർമ്മിക്കേണ്ടതുണ്ട്. എന്നിരുന്നാലും,പ്രായോഗികമായി, നിങ്ങൾ JSON സ്കീമയും ഡോക്യുമെന്റേഷനും നൽകുകയാണെങ്കിൽ, Codex-ന്കഠിനമായ ജോലികളുടെ വലിയൊരു ഭാഗം ചെയ്യാൻ കഴിയും. ഞങ്ങൾ പ്രവർത്തിച്ച പല ടീമുകൾക്കും Codex ഉപയോഗിച്ച് വേഗത്തിൽ പ്രവർത്തനക്ഷമമായ ഒരു ഇന്റഗ്രേഷൻ സൃഷ്ടിക്കാൻ കഴിഞ്ഞു.
ഒറ്റത്തവണ ടാസ്കുകൾക്കും CI റൺസിനുമായി ഉപയോഗിക്കാവുന്ന, ഭാരം കുറഞ്ഞ, സ്ക്രിപ്റ്റ് ചെയ്യാവുന്ന CLI മോഡ്. ഓട്ടോമേഷൻ, പൈപ്പ്ലൈൻ എന്നിവയ്ക്കായി, നിങ്ങൾക്ക് ഒരു കമാൻഡ് നോൺ-ഇന്ററാക്ടീവായി പൂർണ്ണമായി പ്രവർത്തിപ്പിക്കാനും, ലോഗുകൾക്കായി സ്ട്രക്ചേഡ് ഔട്ട്പുട്ടുകൾ സ്ട്രീം ചെയ്യാനും, വ്യക്തമായ വിജയമോ പരാജയമോ സൂചിപ്പിച്ച് എക്സിറ്റ് ചെയ്യാനും ആഗ്രഹിക്കുമ്പോൾ ഇത് ഒരു മികച്ച തിരഞ്ഞെടുപ്പാണ്.
നിങ്ങളുടെ സ്വന്തം ആപ്ലിക്കേഷനിൽ നിന്ന് പ്രോഗ്രാമാറ്റിക്കായി പ്രാദേശിക Codex ഏജൻ്റുകളെ നിയന്ത്രിക്കുന്നതിനുള്ള ഒരു ടൈപ്പ്സ്ക്രിപ്റ്റ് ലൈബ്രറി. നിങ്ങൾക്ക് സെർവർ-സൈഡ് ടൂളുകൾക്കും വർക്ക്ഫ്ലോകൾക്കും വേണ്ടി വേർതിരിച്ച JSON-RPC ക്ലയന്റ് നിർമ്മിക്കാതെ ഒരു നേറ്റീവ് ലൈബ്രറി ഇന്റർഫേസ് ആവശ്യമാണെങ്കിൽ, ഇത് ഏറ്റവും നല്ലതാണ്. ഇത് ആപ്പ് സെർവറിനെക്കാൾ മുമ്പ് ഷിപ്പ് ചെയ്തതിനാൽ, നിലവിൽ ഇത് കുറച്ച് ഭാഷകളും ചെറിയ ഉപരിതല വിസ്തൃതിയും മാത്രമാണ് പിന്തുണയ്ക്കുന്നത്. ഡെവലപ്പർമാരുടെ താൽപ്പര്യം ഉണ്ടെങ്കിൽ, JSON-RPC ബൈൻഡിംഗുകൾ എഴുതാതെ ടീമുകൾക്ക് ഹാർനെസ് സർഫേസിന്റെ കൂടുതൽ ഭാഗങ്ങൾ കവരാൻ കഴിയുന്ന വിധത്തിൽ ആപ്പ് സെർവർ പ്രോട്ടോക്കോൾ റാപ്പ് ചെയ്യുന്ന അധിക SDK-കൾ ഞങ്ങൾ ചേർത്തേക്കാം.
ഈ പോസ്റ്റിൽ, ഏജന്റുകളുമായി ഇടപഴകുന്നതിനുള്ള ഒരു പുതിയ മാനദണ്ഡം രൂപകൽപ്പന ചെയ്യുന്നതിൽ ഞങ്ങൾ എങ്ങനെ സമീപിക്കുന്നു എന്നും Codex ഹാർനെസിനെ സ്ഥിരതയുള്ള, ഉപഭോക്തൃ-സൗഹൃദ പ്രോട്ടോക്കോളാക്കി എങ്ങനെ മാറ്റാം എന്നും ഞങ്ങൾ പങ്കുവച്ചു. ഞങ്ങൾ എങ്ങനെ ആപ്പ് സെർവർ Codex കോര് പുറത്തുകൊണ്ടുവരുന്നു, ക്ലയന്റുകൾക്ക് പൂർണ്ണ ഏജന്റ് ലൂപ്പ് നിയന്ത്രിക്കാൻ അനുവദിക്കുന്നു, കൂടാതെ TUI, ലോക്കൽ IDE ഇന്റഗ്രേഷനുകൾ, വെബ് റൺടൈം എന്നിവ ഉൾപ്പെടുന്ന വിപുലമായ സർഫേസുകൾക്ക് ശക്തി നൽകുന്നു എന്നതിനെക്കുറിച്ച് വിശദീകരിച്ചു.
നിങ്ങളുടെ സ്വന്തം വർക്ക്ഫ്ലോകളിൽ Codex-നെ ഇന്റഗ്രേറ്റ് ചെയ്യാനുള്ള ആശയങ്ങൾ ഇതിലൂടെ ഉണർത്തിയെങ്കിൽ, App സെര്വറിനെ പരീക്ഷിച്ച് നോക്കുന്നത് മൂല്യമുള്ളതാണ്. എല്ലാ സോഴ്സ് കോഡും Codex CLI ഓപ്പൺ സോഴ്സ് repo(പുതിയ വിൻഡോയിൽ തുറക്കുന്നു)യിൽ നിലനിൽക്കുന്നു. നിങ്ങളുടെ ഫീഡ്ബാക്കും ഫീച്ചർ അഭ്യർത്ഥനകളും സ്വതന്ത്രമായി പങ്കിടുക. നിങ്ങളിൽ നിന്ന് കേൾക്കാനും ഏജൻ്റുകളെ എല്ലാവർക്കും കൂടുതൽ ലഭ്യമാക്കുന്നത് തുടർന്നുകൊണ്ടിരിക്കാനും ഞങ്ങൾ ആവേശഭരിതരാണ്.
രചയിതാവ്
അംഗീകാരങ്ങൾ
ഈ പോസ്റ്റിലേക്ക് സംഭാവന നൽകിയ Michael Bolin, Owen Lin, Eric Traut, Rasmus Rygaard എന്നിവർക്കും, ആപ്പ് സെർവറില് പ്രവർത്തിച്ച മുഴുവൻ Codex ടീമിനും പ്രത്യേക നന്ദി.
അടിക്കുറിപ്പുകൾ
- 1
ഞങ്ങൾ “JSON‑RPC lite” എന്നൊരു വകഭേദം ഉപയോഗിക്കുന്നു: ഇത് request/response/notification രൂപം നിലനിർത്തുന്നു, പക്ഷേ
"jsonrpc": "2.0"ഒഴിവാക്കുന്നു ഹെഡറും കർശനമായ JSON‑RPC 2.0-ന് പകരം stdio വഴി JSONL ആയി രൂപപ്പെടുത്തിയിരിക്കുന്നു. - 2
“stdio” എന്നത് കണ്ടെയ്നറിനുള്ളിലെ ആപ്പ്-സെർവറിന്റെ stdin/stdout-നെ സൂചിപ്പിക്കുന്നു. ഹോസ്റ്റഡ് ക്രമീകരണങ്ങളിൽ, ആ സ്ട്രീമുകൾ പലപ്പോഴും സ്ഥിരമായ ഒരു നെറ്റ്വർക്ക് കണക്ഷൻ (ഉദാ., WebSocket-like) വഴി കണ്ടെയ്നർ റൺടൈമിലേക്കു ടണൽ ചെയ്യപ്പെടുന്നു—അതുകൊണ്ട് അത് യഥാർത്ഥ ലോക്കൽ പൈപ്പ് അല്ലെങ്കിലും stdio പോലെ പ്രവർത്തിക്കുന്നു.


