Codex హార్నెస్ అన్లాక్ చేయడం: మేం యాప్ సర్వర్ను ఎలా నిర్మించాం
సాంకేతిక సిబ్బంది సభ్యురాలు సెలియా చెన్ ద్వారా
OpenAI కోడింగ్ ఏజెంట్ Codex అనేక విభిన్న ఉపరితలాలలో ఉంది: వెబ్ యాప్(కొత్త విండోలో తెరుచుకుంటుంది), CLI(కొత్త విండోలో తెరుచుకుంటుంది), IDE ఎక్స్టెన్షన్(కొత్త విండోలో తెరుచుకుంటుంది), మరియు కొత్త Codex macOS యాప్. అంతర్గతంగా, అవన్నీ ఒకే Codex హార్నెస్ ద్వారా నడపబడతాయి—అన్ని Codex అనుభవాలకు ఆధారం అయ్యే ఏజెంట్ లూప్ మరియు లాజిక్. వాటి మధ్య కీలకమైన సంబంధం ఏమిటి? Codex యాప్ సర్వర్(కొత్త విండోలో తెరుచుకుంటుంది), వినియోగదారులకు అనుకూలమైన, ద్విదిశ JSON-RPC1 API.
ఈ పోస్ట్లో, మేం Codex యాప్ సర్వర్ను పరిచయం చేస్తాం; మీ వినియోగదారులు తమ వర్క్ఫ్లోలను మరింత శక్తివంతంగా చేసుకునేందుకు Codex సామర్థ్యాలను మీ ఉత్పత్తిలోకి తీసుకురావడానికి ఉత్తమ మార్గాలపై ఇప్పటివరకు మేం నేర్చుకున్న విషయాలను పంచుకుంటాం. మేం యాప్ సర్వర్ ఆర్కిటెక్చర్ మరియు ప్రోటోకాల్ను, అలాగే అది వివిధ Codex ఉపరితలాలతో ఎలా ఇంటిగ్రేట్ అవుతుందనేది చర్చిస్తాం. మీరు Codexను కోడ్ సమీక్షకుడిగా, SRE ఏజెంట్గా, లేదా కోడింగ్ సహాయకుడిగా మార్చాలనుకుంటే, Codexను ఎలా ఉపయోగించాలని సూచనలు కూడా ఇస్తాం.
ఆర్కిటెక్చర్లోకి ప్రవేశించే ముందు, యాప్ సర్వర్ నేపథ్య కథను తెలుసుకోవడం ఉపయోగకరంగా ఉంటుంది. మొదట, యాప్ సర్వర్ ఉత్పత్తుల అంతటా Codex హార్నెస్ను తిరిగి ఉపయోగించడానికి ఒక ఆచరణాత్మక మార్గంగా ఉండేది, ఇది క్రమంగా అభివృద్ధి చెంది మా ప్రామాణిక ప్రోటోకాల్గా మారింది.
Codex CLI ఒక TUI (టెర్మినల్ యూజర్ ఇంటర్ఫేస్)గా ప్రారంభమైంది, అంటే Codex ని టెర్మినల్ ద్వారా యాక్సెస్ చేస్తారు. మేం VS Code ఎక్స్టెన్షన్ను (Codex ఏజెంట్లతో ఇంటరాక్ట్ చేయడానికి మరింత IDE-ఫ్రెండ్లీ విధానం) నిర్మించినప్పుడు, IDE UI నుండి అదే ఏజెంట్ లూప్ను మళ్లీ అమలు చేయకుండా నడిపించడానికి అదే హార్నెస్ను ఉపయోగించే మార్గం మాకు అవసరమైంది. అంటే అభ్యర్థన/ప్రతిస్పందనకు మించి గొప్ప ఇంటరాక్షన్ ప్యాట్రన్లు చర్యల నమూనాలకు మద్దతు ఇవ్వడం, అంటే కార్యస్థలాన్ని అన్వేషించడం, ఏజెంట్ కారణాల వల్ల పురోగతిని ప్రసారం చేయడం మరియు తేడాలను విడుదల చేయడం వంటివి. మేం మొదట Codex ను MCP సర్వర్గా ఎక్స్పోజ్ చేయడం(కొత్త విండోలో తెరుచుకుంటుంది)తో ప్రయోగాలు చేశాం, అయితే VS కోడ్ను అర్థవంతంగా ఉండే విధంగా 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 core(కొత్త విండోలో తెరుచుకుంటుంది)” అని పిలిచే Codex CLI కోడ్బేస్లోని ఒక భాగంలో ఉంటుంది. Codex core మొత్తం ఏజెంట్ కోడ్ ఉండే లైబ్రరీ మరియు ఏజెంట్ లూప్ను రన్ చేయడానికి మరియు Codex థ్రెడ్ (సంభాషణ) నిలకడను నిర్వహించడానికి ఉపయోగించే రన్టైమ్.
ఉపయోగకరంగా ఉండాలంటే, Codex హార్నెస్ క్లయింట్లకు అందుబాటులో ఉండాలి. అక్కడే యాప్ సర్వర్ ప్రవేశిస్తుంది.
యాప్ సర్వర్ క్లయింట్ మరియు సర్వర్ మధ్య JSON-RPC ప్రోటోకాల్ మరియు Codex కోర్ థ్రెడ్లను హోస్ట్ చేసే దీర్ఘకాలిక ప్రాసెస్. పై డయాగ్రామ్ నుండి మనం చూసినట్లుగా, యాప్ సర్వర్ ప్రాసెస్కు నాలుగు ప్రధాన భాగాలు ఉన్నాయి: stdio రీడర్, Codex మెసేజ్ ప్రాసెసర్, థ్రెడ్ మేనేజర్, మరియు కోర్ థ్రెడ్లు. థ్రెడ్ మేనేజర్ ప్రతి థ్రెడ్ కోసం ఒక కోర్ సెషన్ను ప్రారంభిస్తుంది, ఆపై Codex సందేశ ప్రాసెసర్ ప్రతి కోర్ సెషన్తో నేరుగా కమ్యూనికేట్ చేసి క్లయింట్ అభ్యర్థనలను సమర్పించడానికి మరియు అప్డేట్లను స్వీకరించడానికి పనిచేస్తుంది.
క్లయింట్ అభ్యర్థన అనేక ఈవెంట్ అప్డేట్లకు దారితీయవచ్చు, ఈ సవిస్తరమైన ఈవెంట్లు యాప్ సర్వర్పై సమృద్ధమైన UIని నిర్మించడానికి మమ్మల్ని అనుమతిస్తాయి. అదనంగా, stdio రీడర్ మరియు Codex సందేశ ప్రాసెసర్ క్లయింట్ మరియు Codex కోర్ థ్రెడ్ల మధ్య అనువాద పొరగా పనిచేస్తాయి. వారు క్లయింట్ JSON-RPC అభ్యర్థనలను Codex కోర్ ఆపరేషన్లుగా అనువదిస్తారు, Codex కోర్ అంతర్గత ఈవెంట్ స్ట్రీమ్ను వింటారు, ఆపై ఆ తక్కువ-స్థాయి ఈవెంట్లను స్థిరమైన, UIకి సిద్ధమైన JSON-RPC నోటిఫికేషన్లుగా మారుస్తారు.
క్లయింట్ మరియు యాప్ సర్వర్ మధ్య JSON-RPC ప్రోటోకాల్ పూర్తిగా బైడైరెక్షనల్గా ఉంటుంది. ఒక సాధారణ థ్రెడ్లో ఒక క్లయింట్ అభ్యర్థన మరియు అనేక సర్వర్ నోటిఫికేషన్లు ఉంటాయి. అదనంగా, ఏజెంట్కు అనుమతి వంటి ఇన్పుట్ అవసరమైనప్పుడు సర్వర్ అభ్యర్థనలను ప్రారంభించగలదు, ఆపై క్లయింట్ స్పందించే వరకు ఆ టర్న్ను నిలిపివేయవచ్చు.
తరువాత, మేం యాప్ సర్వర్ ప్రోటోకాల్ యొక్క సంభాషణ ప్రాథమిక అంశాలను, అంటే నిర్మాణ బ్లాక్లను విభజించి వివరిస్తాం. ఏజెంట్ లూప్ కోసం APIని డిజైన్ చేయడం కష్టం, ఎందుకంటే యూజర్/ఏజెంట్ ఇంటరాక్షన్ ఒక సాధారణ రిక్వెస్ట్/రెస్పాన్స్ కాదు. యూజర్ అభ్యర్థన క్లయింట్ నమ్మకంగా ప్రాతినిధ్యం వహించాల్సిన నిర్మాణబద్ధమైన చర్యల క్రమంగా విస్తరించవచ్చు: యూజర్ ఇన్పుట్, ఏజెంట్ క్రమానుగత పురోగతి, మార్గమధ్యంలో ఉత్పత్తి అయ్యే ఆర్టిఫాక్ట్స్ (ఉదా: డిఫ్లు). ఆ ఇంటరాక్షన్ స్ట్రీమ్ను సులభంగా ఇంటిగ్రేట్ చేయడం మరియు అన్ని UIలలో స్థితిస్థాపకంగా ఉండేలా చేయడానికి, మేం స్పష్టమైన సరిహద్దులు మరియు జీవన చక్రాలతో మూడు ప్రధాన ప్రాథమిక అంశాలను ఎంచుకున్నాం:
1. ఐటమ్: ఒక ఐటమ్ Codexలో ఇన్పుట్/అవుట్పుట్ ప్రాథమిక యూనిట్. ఐటమ్లు టైప్ చేయబడతాయి (ఉదా., యూజర్ సందేశం, ఏజెంట్ సందేశం, టూల్ ఎగ్జిక్యూషన్, ఆమోద అభ్యర్థన, డిఫ్) మరియు ప్రతి దానికి ఒక స్పష్టమైన లైఫ్ సైకిల్ ఉంటుంది:
item/startedఐటమ్ ప్రారంభమైనప్పుడు- ఐచ్ఛిక
item/*/deltaఈవెంట్లను కంటెంట్ స్ట్రీమ్లుగా (స్ట్రీమింగ్ ఐటమ్ రకాల కోసం) item/completedఐటమ్ దాని తుది లోడ్తో పూర్తవుతుంది
ఈ జీవితచక్రం క్లయింట్లు స్టార్డెడ్ వెంటనే రెండరింగ్ను ప్రారంభించడానికి, delta ఇంక్రిమెంటల్ అప్డేట్లను స్ట్రీమ్ చేయడానికి మరియు కంప్లీటెడ్ తర్వాత ఖరారు చేయడానికి అనుమతిస్తుంది.
2. టర్న్: టర్న్ యూజర్ ఇన్పుట్ ద్వారా ప్రారంభించబడే ఏజెంట్ పనిలో ఒక యూనిట్. క్లయింట్ ఇన్పుట్ను సమర్పించినప్పుడు (ఉదాహరణకు, “టెస్ట్లు నిర్వహించి వైఫల్యాలను సారాంశం చేయండి”) ఇది ప్రారంభమవుతుంది మరియు ఆ ఇన్పుట్ కోసం ఏజెంట్ అవుట్పుట్లను ఉత్పత్తి చేయడం పూర్తి చేసినప్పుడు ఇది ముగుస్తుంది. ఒక టర్న్లో మార్గమధ్య దశలు మరియు అవుట్పుట్లను సూచించే అంశాల క్రమం ఉంటుంది.
3. థ్రెడ్: థ్రెడ్ అనేది యూజర్ మరియు ఏజెంట్ మధ్య జరుగుతున్న Codex సెషన్కు డ్యూరబుల్ కంటైనర్గా పనిచేస్తుంది. దీనిలో అనేక టర్న్లు ఉంటాయి. థ్రెడ్లను సృష్టించవచ్చు, తిరిగి ప్రారంభించవచ్చు, విడగొట్టవచ్చు, మరియు భద్రపరచవచ్చు. థ్రెడ్ చరిత్ర నిల్వ చేయబడుతుంది, కాబట్టి క్లయింట్లు మళ్లీ కనెక్ట్ అయి స్థిరమైన టైమ్లైన్ను రెండర్ చేయగలరు.
ఇప్పుడు, ప్రిమిటివ్ల ద్వారా సంభాషణను ప్రాతినిధ్యం వహించే, క్లయింట్ మరియు ఏజెంట్ మధ్య సరళీకృత సంభాషణను చూద్దాం:
సంభాషణ ప్రారంభంలో, క్లయింట్ మరియు సర్వర్ initialize హ్యాండ్షేక్ను ఏర్పాటు చేయాలి. క్లయింట్ ఏ ఇతర పద్ధతికి ముందు ఒకే initialize అభ్యర్థనను పంపాలి, సర్వర్ ప్రతిస్పందనతో అంగీకరిస్తుంది. ఇది సర్వర్కు సామర్థ్యాలను ప్రకటించే అవకాశం ఇస్తుంది, నిజమైన పని ప్రారంభమయ్యే ముందు ప్రోటోకాల్ వెర్షనింగ్, ఫీచర్ ఫ్లాగ్లు, డిఫాల్ట్లపై ఇరుపక్షాలు ఏకాభిప్రాయానికి రావడానికి సాయపడుతుంది. ఇది OpenAI VS Code ఎక్స్టెన్షన్ నుండి ఒక ఉదాహరణ పేలోడ్:
సర్వీర్ దీనిని రిటర్న్ చేస్తుంది:
క్లయింట్ కొత్తగా అభ్యర్థించినప్పుడు, అది ముందుగా ఒక థ్రెడ్ని సృష్టించి, తర్వాత ఒక టర్న్ని సృష్టిస్తుంది. సర్వర్ పురోగతికి సంబంధించిన నోటిఫికేషన్లను తిరిగి పంపుతుంది (thread/started మరియు turn/started). ఇది నమోదు చేసిన ఇన్పుట్లను ఐటమ్లుగా కూడా తిరిగి పంపుతుంది, ఇక్కడ ఉన్న యూజర్ సందేశం వలె.
టూల్ కాల్స్ కూడా అంశాలుగా క్లయింట్కు తిరిగి పంపబడతాయి. అదనంగా, సర్వర్ అభ్యర్థనను పంపడం ద్వారా ఒక చర్యను అమలు చేయడానికి ముందు సర్వర్ క్లయింట్ ఆమోదాన్ని అడగవచ్చు. క్లయింట్ "అనుమతించు" లేదా "తిరస్కరించు" అని క్లయింట్ స్పందించే వరకు అప్రూవల్ ఆ టర్న్ను పాజ్ చేస్తుంది. VS కోడ్ ఎక్స్టెన్షన్లో ఆమోద ప్రక్రియ ఇలా ఉంటుంది:

చివరికి, సర్వర్ ఒక ఏజెంట్ సందేశాన్ని పంపి, ఆ తర్వాత turn/completed తో టర్న్ను ముగిస్తుంది. ఏజెంట్ మెసేజ్ డెల్టా ఈవెంట్స్ స్ట్రీమ్ మెసేజ్ను item/completedతో ఫైనలైజ్ చేసే వరకు మెసేజ్ భాగాలను తిరిగి స్ట్రీమ్ చేస్తుంది.
డయాగ్రామ్లోని సందేశాలు చదవడానికి సులభంగా ఉండేందుకు సరళీకరించబడ్డాయి. మీరు పూర్తి టర్న్కు సంబంధించిన JSON చూడాలనుకుంటే, Codex CLI repo నుండి టెస్ట్ క్లయింట్ను నడపవచ్చు:
ఇప్పుడు, వివిధ క్లయింట్ సర్ఫేస్లు యాప్ సర్వర్ ద్వారా Codexను ఎలా ఎంబెడ్ చేస్తాయనేది చూద్దాం. మేం మూడు నమూనాలను కవర్ చేస్తాం: లోకల్ యాప్లు మరియు IDEలు, Codex వెబ్ రన్టైమ్, మరియు TUI.
మూడింటిలోనూ, ట్రాన్స్పోర్ట్ JSON-RPC stdio (JSONL)పై ఉంటుంది. JSON-RPC మీకు నచ్చిన భాషలో క్లయింట్ బైండింగ్లను నిర్మించడం సులభంగా చేస్తుంది. Codex సర్ఫేస్లు మరియు భాగస్వామి ఇంటిగ్రేషన్లు Go, Python, TypeScript, Swift, మరియు Kotlin వంటి భాషల్లో App Server క్లయింట్లను అమలు చేశాయి. టైప్స్క్రిప్ట్ కోసం, మీరు వీటిని రన్ చేయడం ద్వారా రస్ట్ ప్రోటోకాల్ నుండి నేరుగా నిర్వచనాలను రూపొందించవచ్చు:
ఇతర భాషల కోసం, మీరు JSON స్కీమా బండిల్ను రూపొందించి, మీకు నచ్చిన కోడ్ జనరేటర్లోకి ఫీడ్ చేయడానికి దీన్ని నడపవచ్చు:

లోకల్ క్లయింట్లు సాధారణంగా ప్లాట్ఫారం-నిర్ధిష్ట యాప్ సర్వర్ బైనరీని బండిల్ చేస్తాయి లేదా పొందుతాయి, దీర్ఘకాలిక చైల్డ్ ప్రాసెస్గా ప్రారంభించి, JSON-RPC కోసం బై డైరెక్షనల్ stdio ఛానల్ను తెరిచి ఉంచుతాయి. ఉదాహరణకు, మా VS Code ఎక్స్టెన్షన్ మరియు డెస్క్టాప్ యాప్లో, పంపిన ఆర్టిఫాక్ట్లో ప్లాట్ఫారం-నిర్ధిష్ట Codex బైనరీ ఉంటుంది మరియు అది పరీక్షించిన వెర్షన్కు పిన్ చేయబడుతుంది, కాబట్టి క్లయింట్ ఎల్లప్పుడూ మేం ధృవీకరించిన ఖచ్చితమైన బిట్స్ను నడుపుతుంది.
ప్రతి ఇంటిగ్రేషన్ తరచుగా క్లయింట్ అప్డేట్లను పంపిణీ చేయలేరు. Xcode వంటి కొన్ని భాగస్వాములు రిలీజ్ సైకిల్స్ను వేరు చేస్తారు, క్లయింట్ను స్థిరంగా ఉంచి, అవసరమైనప్పుడు దాన్ని కొత్త App Server బైనరీ వైపు సూచించడానికి అనుమతిస్తారు. అలా చేస్తే వారు సర్వర్-సైడ్ మెరుగుదలలను (ఉదాహరణకు, Codex కోర్లో మెరుగైన ఆటో-కంపాక్షన్ లేదా కొత్తగా సపోర్ట్ అయ్యే కాన్ఫిగరేషన్ కీస్) స్వీకరించగలరు, క్లయింట్ రిలీజ్ కోసం వేచి ఉండకుండా బగ్ ఫిక్స్లను విడుదల చేయగలరు. యాప్ సర్వర్ JSON-RPC ఉపరితలం వెనుకకు అనుకూలంగా రూపొందించబడింది, కాబట్టి పాత క్లయింట్లు కొత్త సర్వర్లతో సురక్షితంగా మాట్లాడవచ్చు.

Codex వెబ్ Codex హార్నెస్ను ఉపయోగిస్తుంది, కానీ దాన్ని కంటైనర్ వాతావరణంలో రన్ అవుతుంది. ఒక వర్కర్ చెక్-అవుట్ చేసిన వర్క్స్పేస్తో కంటైనర్ను ప్రొవిజన్ చేసి, దాని లోపల App Server బైనరీని ప్రారంభించి, stdio2 ఛానల్పై దీర్ఘకాలిక JSON-RPCని నిర్వహిస్తుంది. వెబ్ యాప్ (వినియోగదారి బ్రౌజర్ ట్యాబ్లో నడుస్తుంది) HTTP మరియు SSE ద్వారా Codex బ్యాక్ఎండ్తో మాట్లాడుతుంది, ఇది వర్కర్ ఉత్పత్తి చేసిన టాస్క్ ఈవెంట్లను ప్రసారం చేస్తుంది. ఇది డెస్క్టాప్ మరియు వెబ్ అంతటా స్థిరమైన రన్టైమ్ను అందిస్తూనే బ్రౌజర్-సైడ్ UIని తేలికగా ఉంచుతుంది.
వెబ్ సెషన్లు తాత్కాలికమైనవి (ట్యాబ్లు మూసివేయబడతాయి, నెట్వర్క్లు డ్రాప్ అవుతాయి) కాబట్టి, దీర్ఘకాలం నడిచే టాస్క్ల కోసం వెబ్ యాప్ నిజమైన ఆధారంగా ఉండకూడదు. సర్వర్పై స్థితి మరియు పురోగతిని ఉంచడం వల్ల ట్యాబ్ కనిపించకపోయినా పని కొనసాగుతుంది. స్ట్రీమింగ్ ప్రోటోకాల్ మరియు సేవ్ చేసిన థ్రెడ్ సెషన్లు కొత్త సెషన్కు మళ్లీ కనెక్ట్ అవ్వడం, ఆపిన చోట నుండి కొనసాగించడం, క్లయింట్లో స్థితిని పునర్నిర్మించకుండానే కొనసాగించడాన్ని సులభతరం చేస్తాయి.

చరిత్రాత్మకంగా, TUI “నేటివ్” క్లయింట్, ఇది ఏజెంట్ లూప్తో అదే ప్రాసెస్లో నడిచేది మరియు యాప్-సర్వర్ ప్రోటోకాల్కు బదులుగా నేరుగా Rust కోర్ టైప్లతో మాట్లాడేది. అది ప్రారంభ ఇటరేషన్ను వేగవంతం చేసింది, కానీ అది TUIని ప్రత్యేక సందర్భ ఉపరితలంగా మార్చింది.
ఇప్పుడు యాప్ సర్వర్ లభ్యం కావడంతో, మేం TUIని రీఫ్యాక్టర్ చేయాలని(కొత్త విండోలో తెరుచుకుంటుంది) ప్లాన్ చేస్తున్నాం, తద్వారా అది ఇతర క్లయింట్ల మాదిరిగా ప్రవర్తిస్తుంది: యాప్ సర్వర్ చైల్డ్ ప్రాసెస్ను ప్రారంభించడం, stdio ద్వారా JSON-RPC మాట్లాడడం, మరియు అదే స్ట్రీమింగ్ ఈవెంట్లు మరియు ఆమోదాలను రెండర్ చేయడం. ఇది TUI రిమోట్ మెషీన్లో నడుస్తున్న Codex సర్వర్కు కనెక్ట్ అయ్యే వర్క్ఫ్లోలను అన్లాక్ చేస్తుంది, ఏజెంట్ను కంప్యూట్కు దగ్గరగా ఉంచి, ల్యాప్టాప్ స్లీప్లోకి వెళ్లినా లేదా డిస్కనెక్ట్ అయినా కూడా పని కొనసాగించగలదు, అదే సమయంలో లోకల్గా లైవ్ అప్డేట్లు మరియు కంట్రోల్స్ను అందిస్తుంది.
Codex యాప్ సర్వర్ మేం నిర్వహించే ఫస్ట్ క్లాస్ ఇంటిగ్రేషన్ పద్ధతిగా ఉంటుంది, అయితే పరిమిత ఫంక్షనాలిటీతో ఇతర పద్ధతులు కూడా ఉన్నాయి. మామూలుగా, Codexతో ఇంటిగ్రేట్ చేయడానికి కస్టమర్లు Codex App Serverను ఉపయోగించాలని మేం సిఫారసు చేస్తాము, కానీ వేర్వేరు ఇంటిగ్రేషన్ పద్ధతులను పరిశీలించి వాటి లాభాలు మరియు నష్టాలను అర్థం చేసుకోవడం మంచిది. Codex నడిపించడానికి సాధారణ మార్గాలు మరియు వాటి ఉపయోగం ఎప్పుడు సరిపోతుందో క్రింద ఉన్నాయి.
codex mcp-server(కొత్త విండోలో తెరుచుకుంటుంది) రన్ చేయండి మరియు stdio సర్వర్లకు మద్దతు ఇచ్చే ఏ MCP క్లయింట్ నుండి అయినా కనెక్ట్ అవ్వండి (ఉదాహరణకు, OpenAI ఏజెంట్స్ SDK(కొత్త విండోలో తెరుచుకుంటుంది)). మీకు ఇప్పటికే MCP ఆధారిత వర్క్ఫ్లో ఉంటే మరియు Codex ను కాల్ చేయగల టూల్గా ఉపయోగించాలని అనుకుంటే, ఇది మంచి ఎంపిక. లోపం ఏమిటంటే, మీరు MCP బహిర్గతం చేసే దానినే పొందుతారు, అందువల్ల మరింత సమృద్ధమైన సెషన్ సెమాంటిక్స్ (ఉదా., డిఫ్ అప్డేట్స్)పై ఆధారపడే Codex-నిర్దిష్ట పరస్పర చర్యలు MCP ఎండ్పాయింట్ల ద్వారా సులభంగా మ్యాప్ కాకపోవచ్చు.
కొన్ని ఎకోసిస్టమ్లు అనేక మోడల్ ప్రొవైడర్లు మరియు రన్టైమ్లను లక్ష్యంగా చేసుకునే పోర్టబుల్ ఇంటర్ఫేస్ను అందిస్తాయి. మీరు అనేక ఏజెంట్లను సమన్వయం చేసే ఒకే అబ్స్ట్రాక్షన్ను కోరుకుంటే, ఇది సరైన ఎంపిక కావొచ్చు. ట్రేడ్ఆఫ్ ఏమిటంటే, ఈ ప్రోటోకాల్లు తరచుగా సామర్థ్యాల సాధారణ ఉపసమితిపై సమీకృతమవుతాయి, ఇది మరింత సమృద్ధమైన పరస్పర చర్యలను ప్రతినిధ్యం చేయడం కష్టతరం చేస్తుంది, ముఖ్యంగా ప్రొవైడర్-స్పెసిఫిక్ టూల్ మరియు సెషన్ సెమాంటిక్స్ ముఖ్యమైనప్పుడు. ఈ స్థలం వేగంగా అభివృద్ధి చెందుతోంది, మరియు మేం నిజ-ప్రపంచ ఏజెంట్ వర్క్ఫ్లోలను ప్రాతినిధ్యం చేయడానికి ఉత్తమ ప్రిమిటివ్లను కనుగొనడం కొలదీ మరింత సాధారణ ప్రమాణాలు వెలువడతాయని ఆశిస్తున్నాము (స్కిల్స్(కొత్త విండోలో తెరుచుకుంటుంది) దీనికి మంచి ఉదాహరణ).
మీరు పూర్తి Codex హార్నెస్ను స్థిరమైన, UI-స్నేహపూర్వక ఈవెంట్ స్ట్రీమ్గా బహిర్గతం చేయాలనుకుంటే, యాప్ సర్వర్ను ఎంచుకోండి. నువ్వు ఏజెంట్ లూప్ పూర్తి ఫంక్షనాలిటీతో పాటు ChatGPT తో సైన్ ఇన్, మోడల్ డిస్కవరీ, మరియు కాన్ఫిగరేషన్ మేనేజ్మెంట్ వంటి ఇతర సహాయక ఫీచర్లను కూడా పొందుతారు. మీరు మీ భాషలో క్లయింట్-సైడ్ JSON-RPC బైండింగ్ను నిర్మించాల్సిన అవసరం కావడం వల్ల, ప్రధాన ఖర్చు ఇంటిగ్రేషన్ పని. అయితే, ఆచరణలో, మీరు JSON స్కీమా మరియు డాక్యుమెంటేషన్ను అందిస్తే Codex చాలా కష్టమైన పనిని చేయగలదు. మేం కలిసి పనిచేసిన అనేక జట్లు Codex ను ఉపయోగించి త్వరగా పనిచేసే ఇంటిగ్రేషన్ను రూపొందించగలిగాయి.
ఒకసారి చేసే పనులు మరియు CI రన్ల కోసం తేలికైన, స్క్రిప్ట్ చేయగల CLI మోడ్. ఇది ఆటోమేషన్ మరియు పైప్లైన్లకు బాగా సరిపోతుంది, ఇక్కడ మీరు ఒకే కమాండ్ ఇంటరాక్టివ్గా లేకుండా పూర్తి అయ్యేలా అమలు చేయాలని అనుకుంటున్నారు, లాగ్ల కోసం స్ట్రక్చర్డ్ అవుట్పుట్ను స్ట్రీమ్ చేయాలి మరియు స్పష్టమైన విజయం లేదా వైఫల్య సంకేతంతో నిష్క్రమించాలి.
మీ స్వంత అప్లికేషన్లో ప్రోగ్రామాటిక్గా స్థానిక Codex ఏజెంట్లను నియంత్రించడానికి TypeScript లైబ్రరీ. మీకు సర్వర్-సైడ్ టూల్స్ మరియు వర్క్ఫ్లోల కోసం వేరే JSON-RPC క్లయింట్ను నిర్మించకుండా నేటివ్ లైబ్రరీ ఇంటర్ఫేస్ కావాలనిపిస్తే, ఇది ఉత్తమం. ఇది App Server కంటే ముందే పంపబడినందున, ప్రస్తుతం ఇది తక్కువ భాషలకు మరియు చిన్న పరిధికి మద్దతు ఇస్తోంది. డెవలపర్ ఆసక్తి ఉంటే, యాప్ సర్వర్ ప్రోటోకాల్ను చుట్టే అదనపు SDKలను మేం జోడించవచ్చు, తద్వారా జట్లు JSON-RPC బైండింగ్లను రాయకుండానే ఎక్కువ హార్నెస్ ఉపరితలాన్ని కవర్ చేయగలవు.
ఈ పోస్ట్లో, మేం ఏజెంట్లతో ఇంటరాక్ట్ అయ్యేందుకు కొత్త ప్రమాణాన్ని డిజైన్ చేయడాన్ని ఎలా అప్రోచ్ చేసామో, అలాగే Codex హార్నెస్ను స్థిరమైన, యూజర్లకు అనుకూలమైన ప్రోటోకాల్గా ఎలా మార్చామో పంచుకున్నాము. మేం App Server Codex coreను ఎలా ఎక్స్పోజ్ చేస్తుందో, క్లయింట్లు పూర్తి ఏజెంట్ లూప్ను ఎలా నడిపించగలరో, మరియు TUI, స్థానిక IDE ఇంటిగ్రేషన్లు, వెబ్ రన్టైమ్ వంటి విస్తృత శ్రేణి ఉపరితలాలకు ఎలా శక్తిని అందిస్తుందనేది కవర్ చేశాం.
ఇది మీ స్వంత వర్క్ఫ్లోలలో కోడెక్స్ను ఏకీకృతం చేయాలనే ఆలోచనలను రేకెత్తిస్తే, యాప్ సర్వర్ను ప్రయత్నించడం విలువైనదే. అన్ని సోర్స్ కోడ్ Codex CLI ఓపెన్-సోర్స్ రిపో(కొత్త విండోలో తెరుచుకుంటుంది)లో ఉంటుంది. మీ ఫీడ్బ్యాక్ మరియు ఫీచర్ రిక్వెస్ట్లను స్వేచ్ఛగా పంచుకోండి. మీ నుండి వినడానికి మేం ఉత్సాహంగా ఉన్నాము మరియు ఏజెంట్లను అందరికీ మరింత సులభంగా అందుబాటులోకి తీసుకురావడానికి మేం కొనసాగిస్తాము.
రచయిత
కృతజ్ఞతలు
ఈ పోస్ట్కు సహకరించిన మైఖేల్ బోలిన్, ఓవెన్ లిన్, ఎరిక్ ట్రాట్ మరియు రాస్మస్ రైగార్డ్లకు మరియు యాప్ సర్వర్లో పనిచేసిన మొత్తం Codex బృందానికి ప్రత్యేక ధన్యవాదాలు.
ఫుట్ నోట్స్
- 1
మేం “JSON‑RPC lite” వేరియంట్ను ఉపయోగిస్తున్నాము: ఇది request/response/notification ఆకారాన్ని అలాగే ఉంచుతుంది, కానీ
"jsonrpc": "2.0"ను వదిలేస్తుంది హెడర్ మరియు ఇది strict JSON‑RPC 2.0 కంటే stdio పై JSONL గా రూపొందించబడింది. - 2
“stdio” అనేది కంటైనర్ లోపల యాప్-సర్వర్ యొక్క stdin/stdout ను సూచిస్తుంది హోస్టెడ్ సెటప్లలో, ఆ స్ట్రీమ్లు తరచుగా స్థిరమైన నెట్వర్క్ కనెక్షన్ (ఉదా., WebSocket వంటి) ద్వారా కంటైనర్ రన్టైమ్కు టన్నెల్ చేయబడతాయి—కాబట్టి అది అక్షరార్థమైన లోకల్ పైప్ కాకపోయినా stdio లాగా ప్రవర్తిస్తుంది.


