2026. gada 4. februāris

Codex potenciāla atraisīšana: kā mēs izveidojām Lietotņu serveri

Celia Chen, tehniskā personāla locekle

Notiek ielāde…

OpenAI kodēšanas aģents Codex ir pieejams daudzās dažādās platformās: tīmekļa lietotnē⁠(atveras jaunā logā), CLI⁠(atveras jaunā logā), IDE paplašinājumā⁠(atveras jaunā logā) un jaunajā Codex macOS lietotnē. Aizkulisēs tos visus darbina viens un tas pats Codex ietvars – aģenta cikls un loģika, kas ir visu Codex pakalpojumu pamatā. Kritiskā saikne starp tiem? Codex App Server⁠(atveras jaunā logā), klientiem draudzīgs divvirzienu JSON-RPC¹ API.

Šajā ierakstā mēs iepazīstināsim ar Codex App Server un dalīsimies ar līdz šim gūtajām atziņām par labākajiem veidiem, kā ieviest Codex iespējas jūsu produktā, lai palīdzētu lietotājiem būtiski uzlabot savas darbplūsmas. Apskatīsim App Server arhitektūru un protokolu un to, kā tas integrējas ar dažādām Codex saskarnēm, kā arī sniegsim padomus, kā izmantot Codex neatkarīgi no tā, vai vēlies pārvērst Codex par koda pārskatītāju, SRE aģentu vai programmēšanas palīgu.

App Server izcelsme

Pirms iedziļināmies arhitektūrā, ir noderīgi zināt App Server vēsturi. Sākotnēji App Server bija praktisks veids, kā atkārtoti izmantot Codex ietvaru dažādos produktos, kas pakāpeniski attīstījās par mūsu standarta protokolu.

Codex CLI sākās kā TUI (termināļa lietotāja saskarne), kas nozīmē, ka Codex ir pieejams caur termināli. Izstrādājot VS Code paplašinājumu (IDE draudzīgāku veidu, kā mijiedarboties ar Codex aģentiem), mums bija nepieciešams izmantot to pašu mehānismu, lai no IDE lietotāja saskarnes vadītu to pašu aģenta ciklu, to nepārrakstot no jauna. Tas nozīmēja, ka jāatbalsta bagātīgāki mijiedarbības scenāriji par vienkāršu pieprasījuma/atbildes modeli – piemēram, darbvietas izpēte, izpildes gaitas straumēšana aģenta domāšanas laikā un izmaiņu (diff) ģenerēšana. Vispirms mēs eksperimentējām ar Codex kā MCP serveri⁠(atveras jaunā logā), taču MCP semantikas uzturēšana tādā veidā, kas būtu piemērots VS Code, izrādījās sarežģīta. Tā vietā mēs ieviesām JSON-RPC protokolu, kas reproducēja TUI ciklu un kļuva par App Server neoficiālo pirmo versiju⁠(atveras jaunā logā). Tobrīd mēs negaidījām, ka citi klienti būs atkarīgi no App Server, tāpēc tas netika veidots kā stabils API.

Tā kā Codex ieviešana nākamo dažu mēnešu laikā pieauga, iekšējās komandas un ārējie partneri vēlējās iespēju integrēt to pašu ietvaru savos produktos, lai paātrinātu savu lietotāju programmatūras izstrādes darbplūsmas. Piemēram, JetBrains un Xcode vēlējās IDE līmeņa aģenta pakalpojumu, savukārt Codex darbvirsmas lietotnei bija nepieciešams orķestrēt daudzus Codex aģentus paralēli. Šīs prasības mudināja mūs izstrādāt platformas virsmu, uz kuru gan mūsu produkti, gan partneru integrācijas varētu droši paļauties ilgtermiņā. Tai vajadzēja būt viegli integrējamai un atpakaļsaderīgai, lai mēs varētu protokolu pilnveidot, saglabājot saderību ar esošajiem klientiem.

Tālāk mēs izskaidrosim, kā mēs izstrādājām arhitektūru un protokolu, lai dažādi klienti varētu izmantot vienu un to pašu sistēmu.

Codex ietvarā

Vispirms aplūkosim, kas atrodas Codex ietvarā un kā Codex App Server to padara pieejamu klientiem. Savā pēdējā Codex bloga ierakstā mēs detalizēti izskaidrojām, kā darbojas aģenta pamatcikls, kas organizē mijiedarbību starp lietotāju, modeli un rīkiem. Šī ir Codex ietvara pamatloģika, taču visa aģenta pieredzei ir plašāka:

1. Pavediena dzīves cikls un noturība. Pavediens ir Codex saruna starp lietotāju un aģentu. Codex izveido, atsāk, sazaro un arhivē pavedienus, kā arī saglabā notikumu vēsturi, lai klienti varētu atkārtoti izveidot savienojumu un veidot konsekventu laika skalu.

2. Konfigurācija un autentifikācija. Codex ielādē konfigurāciju, pārvalda noklusējumus un izpilda autentifikācijas plūsmas, piemēram, “Pierakstīties ar ChatGPT”, ietverot akreditācijas datu stāvokli.

3. Rīku izpilde un paplašinājumi. Codex izpilda čaulas/failu rīkus smilškastē un savieno integrācijas, piemēram, MCP serverus un prasmes, lai tie varētu piedalīties aģenta ciklā saskaņā ar konsekventu politikas modeli.

Visa šeit minētā aģenta loģika, tostarp pamata aģenta cikls, atrodas Codex CLI koda bāzes daļā ar nosaukumu “Codex kodols⁠(atveras jaunā logā)”. Codex kodols ir gan bibliotēka, kurā atrodas viss aģenta kods, gan izpildlaiks, ko var palaist, lai darbinātu aģenta ciklu un pārvaldītu viena Codex pavediena (sarunas) noturību.

Lai Codex ietvars būtu noderīgs, tam jābūt pieejamam klientiem. Lai to nodrošinātu, tiek izmantots App Server.

Diagramma ar nosaukumu “App server procesa plūsma”. Klients sūta JSON-RPC ziņojumus stdio lasītājam, kas pārsūta pieprasījumus Codex ziņojumu apstrādātājam. Procesors mijiedarbojas ar pavedienu pārvaldnieku un kodola pavedienu, izmantojot uzmeklēšanas pavedienus, pavedienu identifikatorus, iesniegtos pieprasījumus un notikumus/atjauninājumus, pēc tam atgriež atbildes klientam.

App Server ir gan JSON-RPC protokols starp klientu un serveri, gan ilgstošs process, kurā atrodas Codex kodola pavedieni. Kā redzams diagrammā augstāk, App Server procesam ir četras galvenās sastāvdaļas: stdio lasītājs, Codex ziņojumu apstrādātājs, pavedienu pārvaldnieks un kodola pavedieni.. Pavedienu pārvaldnieks izveido vienu kodola sesiju katram pavedienam, un Codex ziņojumu apstrādātājs pēc tam tieši sazinās ar katru kodola sesiju, lai iesniegtu klientu pieprasījumus un saņemtu atjauninājumus.

Viena klienta pieprasījuma rezultātā var tikt veikti daudzi notikumu atjauninājumi, un tieši šie detalizētie notikumi ļauj mums izveidot bagātīgu lietotāja saskarni virs App Server. Turklāt stdio lasītājs un Codex ziņojumu apstrādātājs kalpo kā tulkošanas slānis starp klientu un Codex kodola pavedieniem. Tie pārvērš klienta JSON-RPC pieprasījumus Codex kodola operācijās, klausās Codex kodola iekšējo notikumu straumi un pēc tam pārveido šos zema līmeņa notikumus nelielā stabilu, lietotāja saskarnei gatavu JSON-RPC paziņojumu kopā.

JSON-RPC protokols starp klientu un App Server ir pilnībā divvirzienu. Tipiskā pavedienā ir klienta pieprasījums un daudzi servera paziņojumi. Turklāt serveris var uzsākt pieprasījumus, kad aģentam nepieciešama ievade, piemēram, apstiprinājums, un pēc tam apturēt darbību, līdz klients atbild.

Sarunu primitīvi

Tālāk mēs izskaidrosim sarunas primitīvus, kas ir App Server protokola pamatelementi. API izstrāde aģenta ciklam ir sarežģīta, jo lietotāja un aģenta mijiedarbība nav vienkārša pieprasījuma un atbildes forma. Viens lietotāja pieprasījums var izvērsties strukturētā darbību virknē, kas klientam ir precīzi jāatspoguļo: lietotāja ievade, aģenta pakāpeniskā izpildes gaita, pa ceļam izveidotie artefakti (piemēram, izmaiņas). Lai šo mijiedarbības plūsmu būtu viegli integrēt un tā būtu noturīga dažādās lietotāja saskarnēs, mēs nonācām pie trim pamatprimitīviem ar skaidri noteiktām robežām un dzīves cikliem:

1. Vienums: vienums ir Codex ievades/izvades pamatvienība. Vienumi ir tipizēti (piemēram, lietotāja ziņojums, aģenta ziņojums, rīka izpilde, apstiprinājuma pieprasījums, diff), un katram ir skaidri noteikts dzīves cikls:

item/started, kad vienums sākas
neobligāti item/*/delta notikumi kā satura straumes (straumēšanas vienumu veidiem)
item/completed, kad vienums tiek pabeigts ar tā galīgo datu saturu

Šis dzīves cikls ļauj klientiem sākt renderēšanu uzreiz pēc started, straumēt pakāpeniskus atjauninājumus uz delta un pabeigt pie completed.

2. Kārta: kārta ir viena lietotāja ievades ierosināta aģenta darba vienība. Tā sākas, kad klients iesniedz ievadi (piemēram, “palaid testus un sniedz kopsavilkumu par kļūmēm”), un beidzas, kad aģents pabeidz ģenerēt izvades atbildē uz šo ievadi. Kārta ietver vienumu virkni, kas attēlo starpposmus un procesa gaitā radītos izvades rezultātus.

3. Pavediens: pavediens ir noturīgs konteiners Codex sesijai starp lietotāju un aģentu. Tas ietver vairākas kārtas. Pavedienus var izveidot, atsākt, atzarot un arhivēt. Pavediena vēsture tiek saglabāta, lai klienti varētu atkārtoti izveidot savienojumu un veidot konsekventu laika līniju.

Tagad aplūkosim vienkāršotu sarunu starp klientu un aģentu, kur saruna ir attēlota ar primitīviem:

Diagramma ar nosaukumu “Klienta-servera protokola ziņojumu plūsma: inicializācijas handshake.” Klients nosūta serverim inicializācijas pieprasījumu ar klienta informāciju. Serveris atbild ar rezultāta notikumu, kas satur userAgent virkni “my_client/1.0.”

Sarunas sākumā klientam un serverim ir jāizveido initialize sākotnējā saskaņošana (handshake). Klientam ir jānosūta viens initialize pieprasījums pirms jebkuras citas metodes, un serveris to apstiprina ar atbildi. Tas dod serverim iespēju paziņot par savām iespējām un ļauj abām pusēm vienoties par protokola versijām, funkciju karogiem un noklusējuma iestatījumiem pirms īstā darba sākuma. Šeit ir piemēra datu kopums no OpenAI VS Code paplašinājuma:

JSON

1{
2  "method": "initialize",
3  "id": 0,
4  "params": {
5    "clientInfo": {
6      "name": "codex_vscode",
7      "title": "Codex VS Code Extension",
8      "version": "0.1.0"
9    }
10  }
11}

Lūk, ko serveris atgriež:

JSON

1{
2  "id": 0,
3  "result": {
4    "userAgent": "codex_vscode/0.94.0-alpha.7 (Mac OS 26.2.0; arm64) vscode/2.4.22 (codex_vscode; 0.1.0)"
5  }
6}

Diagramma ar nosaukumu “Klienta-servera protokola ziņojumu plūsma: pavediena un kārtas dzīves cikls.” Klients nosūta thread/start un turn/start pieprasījumus serverim. Serveris raida notikumus – thread/started, turn/started, item/started un item/completed – un parāda kārtu, kurā lietotāja ziņojums ir "palaist testus un apkopot kļūdas".

Kad klients veic jaunu pieprasījumu, tas vispirms izveidos pavedienu un pēc tam sarunas kārtu. Serveris nosūtīs atpakaļ paziņojumus par izpildes gaitu (thread/started un turn/started). Tas arī nosūtīs atpakaļ ievades, kuras tas reģistrē kā vienumus, piemēram, lietotāja ziņojumu šajā gadījumā.

Diagramma ar nosaukumu “Klienta-servera protokola ziņojumu plūsma: rīka izpilde ar izvēles apstiprinājumu.” Rīka izsaukuma laikā serveris izsūta item/started, pēc tam item/commandExecution/requestApproval ar iemeslu (“palaist testus”). Klients atgriež apstiprinājuma notikumu (allow/deny). Serveris pēc tam izvada item/completed, norādot komandas izpildi ("pnpm test").

Rīku izsaukumi tiek nosūtīti atpakaļ klientam arī kā vienumi. Turklāt serveris var pieprasīt klienta apstiprinājumu, pirms tas var izpildīt darbību, nosūtot servera pieprasījumu. Apstiprinājums pārtrauks kārtu, līdz klients atbildēs ar “atļaut” vai “noraidīt.” Šādi izskatās apstiprināšanas plūsma VS Code paplašinājumā:

Atļaujas uzvedne tumša dizaina saskarnē, kurā tiek jautāts: “Vai vēlies atļaut man palaist pnpm test šajā darbvietā?” Tajā ir uzskaitītas opcijas: 1) Jā, 2) Jā un vairs nejautāt komandām, kas sākas ar pnpm test, un 3) Nē, ar pogu 'Iesniegt' apakšā.

Diagramma ar nosaukumu “Klienta-servera protokola ziņojumu plūsma: straumēšanas aģenta ziņojumu plūsma”. Serveris straumē palīgziņojumu pa daļām: item/started, divi agentMessage/delta notikumi (“veica 3 testus”, “visi sekmīgi”), tad item/completed. Kārta beidzas ar turn/completed.

Beigās serveris nosūta aģenta ziņojumu un pēc tam pabeidz kārtu ar turn/completed. Aģenta ziņojuma delta notikumu straume pa daļām atgriež ziņojuma fragmentus, līdz ziņojums tiek pabeigts ar item/completed.

Diagrammā esošie ziņojumi ir vienkāršoti, lai būtu vieglāk lasāmi. Ja vēlies redzēt JSON pilnai kārtai, vari palaist testa klientu no Codex CLI repozitorija:

Bash

1codex debug app-server send-message-v2 "run tests and summarize failures"

Integrācija ar klientiem

Tagad aplūkosim, kā dažādas klienta saskarnes integrē Codex, izmantojot App Server. Mēs aplūkosim trīs modeļus: lokālās lietotnes un IDE, Codex tīmekļa izpildlaiks un TUI.

Diagramma ar nosaukumu “Codex klienti integrēti ar Codex ietvaru, izmantojot app server.” Pirmās puses klienti (Codex darbvirsmas lietotne, TUI/CLI, Web Runtime) un trešo pušu integrācijas (JetBrains IDEs, VS Code, Xcode) sazinās ar Codex ietvaru, izmantojot JSON-RPC izsaukumus.

Visos trijos gadījumos datu pārraide notiek, izmantojot JSON-RPC caur stdio (JSONL). JSON-RPC padara klienta saistījumu izveidi vienkāršu jūsu izvēlētajā valodā. Codex lietošanas saskarnes un partneru integrācijas ir ieviesušas App Server klientus tādās programmēšanas valodās kā Go, Python, TypeScript, Swift un Kotlin. TypeScript gadījumā jūs varat ģenerēt definīcijas tieši no Rust protokola, izpildot:

Bash

1codex app-server generate-ts

Citu valodu gadījumā var ģenerēt JSON shēmas komplektu un ievadīt to izvēlētā koda ģeneratorā, izpildot:

Bash

1codex app-server generate-json-schema

Vietējās lietotnes un IDE.

VS Code ekrānuzņēmums ar Codex paplašinājumu, kas darbojas. Ir atvērts Rust testa fails, un zem tā Codex panelis apraksta tikai fmt un cargo test -p codex-app-server palaišanu, ziņojot, ka formatēšana un testi tiek veikti, kamēr tiek gaidīts galīgais sekmīgs/nesekmīgs rezultāts.

Lokālie klienti parasti iekļauj komplektā vai ielādē platformai specifisku App Server bināro failu, palaiž to kā ilgstoši darbojošos pakārtotu procesu un uztur atvērtu divvirzienu stdio kanālu JSON-RPC saziņai. Piemēram, mūsu VS Code paplašinājumā un darbvirsmas lietotnē piegādātajā artefaktā ir iekļauts platformai specifiskais Codex binārais fails, un tas ir piesaistīts testētajai versijai, lai klients vienmēr darbotos tieši ar apstiprinātajiem bitiem.

Ne katra integrācija var bieži piegādāt klientu atjauninājumus. Daži partneri, piemēram, Xcode, atdala laidienu ciklus, saglabājot klientu stabilu un ļaujot tam vajadzības gadījumā norādīt uz jaunāku App Server bināro failu. Tādējādi tie var ieviest servera puses uzlabojumus (piemēram, labāku automātisko sablīvēšanu Codex kodolā vai jaunatbalstītas konfigurācijas atslēgas) un izlaist kļūdu labojumus, negaidot klienta laidienu. Lietotnes servera JSON-RPC saskarne ir veidota tā, lai nodrošinātu atpakaļsaderību, tādējādi vecāki klienti var droši sazināties ar jaunākiem serveriem.

Codex Web

Ekrānuzņēmums no Codex tīmekļa saskarnes, kurā redzams atjauninājums ar nosaukumu “Atjaunināt pieteikšanās sekmīgas darbības ziņojumu”. Kreisajā panelī ir apkopotas izmaiņas, testi un modificētie faili, savukārt labajā panelī attēlots koda diff fails login.rs ar atjauninātu pieteikšanās sekmīga ziņojuma formulējumu.

Codex Web vietne izmanto Codex ietvaru, bet to darbina konteineru vidē. Darbinieks nodrošina konteineru ar izrakstīto darbvietu, palaiž tajā App Server bināro failu un uztur ilgstošu JSON-RPC kanālu caur stdio². Tīmekļa lietotne (darbojas lietotāja pārlūkprogrammas cilnē) sazinās ar Codex aizmugursistēmu, izmantojot HTTP un SSE, kas straumē uzdevumu notikumus, ko rada darbinieks. Tas saglabā pārlūka puses lietotāja saskarni vieglu, vienlaikus nodrošinot konsekventu izpildlaiku gan darbvirsmā, gan tīmeklī.

Tā kā tīmekļa sesijas ir īslaicīgas (cilnes tiek aizvērtas, tīkli pārtrūkst), tīmekļa lietotne nevar būt uzticams avots ilgstoši veicamiem uzdevumiem. Stāvokļa un izpildes gaitas saglabāšana serverī nozīmē, ka darbs turpinās pat tad, ja cilne pazūd. Straumēšanas protokols un saglabātās pavedienu sesijas ļauj jaunai sesijai viegli atkārtoti pieslēgties, turpināt no vietas, kur tā tika pārtraukta, un panākt aktuālo stāvokli, nepārbūvējot stāvokli klientā.

TUI/Codex CLI

Ekrānuzņēmums no termināļa, kurā darbojas Codex CLI. Tas parāda OpenAI Codex karogu ar modeli gpt-5.2-codex medium, lietotāja komandu “izskaidro man app serveri” un statusu “Strādā”. Zemāk parādās ieteikums: “raksti testus failam @filename,” ar īsinājumtaustiņu opcijām.

Vēsturiski TUI bija “iebūvēts” klients, kas darbojās tajā pašā procesā kā aģenta cikls un sazinājās tieši ar Rust kodola tipiem, nevis izmantoja app-server protokolu. Tas padarīja agrīno iterāciju ātru, bet arī padarīja TUI par īpaša gadījuma saskarni.

Tagad, kad pastāv App Server, mēs plānojam pārstrukturēt TUI⁠(atveras jaunā logā), lai to izmantotu tā, lai tas darbotos kā jebkurš cits klients: palaistu App Server pakārtotu procesu, sazinātos, izmantojot JSON-RPC ar stdio starpniecību, un attēlotu tos pašus straumētos notikumus un apstiprinājumus. Tas nodrošina darbplūsmas, kurās TUI var izveidot savienojumu ar Codex serveri, kas darbojas attālinātā datorā, saglabājot aģentu tuvu skaitļošanas procesam un turpinot darbu pat tad, ja klēpjdators guļ vai ir atvienots, vienlaikus nodrošinot tiešos atjauninājumus un vadību lokāli.

Pareizā protokola izvēle

Codex App Server būs pirmās klases integrācijas metode, ko turpmāk uzturēsim, taču ir arī citas metodes ar ierobežotāku funkcionalitāti. Pēc noklusējuma mēs iesakām klientiem izmantot Codex App Server, lai integrētos ar Codex, taču ir vērts apsvērt dažādas integrācijas metodes un izprast to priekšrocības un trūkumus. Tālāk ir visbiežākie veidi, kā izmantot Codex, un kad katrs no tiem varētu būt piemērots.

JSON-RPC protokoli

Codex kā MCP serveris

Palaidiet codex mcp-server⁠(atveras jaunā logā) un pieslēdzieties no jebkura MCP klienta, kas atbalsta stdio serverus (piemēram, OpenAI Agents SDK⁠(atveras jaunā logā)). Tas ir labs risinājums, ja jums jau ir uz MCP balstīta darbplūsma un vēlaties izmantot Codex kā izsaucamu rīku. Trūkums ir tas, ka jūs saņemat tikai to, ko MCP atklāj, tāpēc Codex specifiskās mijiedarbības, kas paļaujas uz bagātīgāku sesijas semantiku (piemēram, diff atjauninājumi), var netikt tīri kartētas caur MCP galapunktiem.

Starpnodrošinātāju aģentu ietvaru protokoli

Dažas ekosistēmas piedāvā pārnesamu saskarni, kas var darboties ar vairākiem modeļu nodrošinātājiem un izpildlaikiem. Tas var būt labs risinājums, ja vēlaties vienu abstrakciju, kas koordinē vairākus aģentus. Kompromiss ir tāds, ka šie protokoli bieži vien konverģē uz kopīgu spēju apakškopu, kas var apgrūtināt bagātīgāku mijiedarbību attēlošanu, īpaši tad, ja nozīme ir pakalpojumu sniedzējam specifiskām rīku un sesiju semantikām. Šī joma strauji attīstās, un mēs paredzam, ka, noskaidrojot labākos primitīvus reālās pasaules aģentu darbplūsmu attēlošanai, parādīsies plašāk izplatīti standarti (skills⁠(atveras jaunā logā) ir labs piemērs tam).

Codex App Server

Izvēlieties App Server, ja vēlaties, lai pilnais Codex ietvars būtu pieejams kā stabila, lietotājam draudzīga notikumu straume. Jūs iegūstat gan pilnu aģenta cikla funkcionalitāti, gan citas atbalsta funkcijas, piemēram, pierakstīšanos ar ChatGPT, modeļu atklāšanu un konfigurācijas pārvaldību. Galvenās izmaksas ir integrācijas darbs, jo jums ir jāizveido klienta puses JSON-RPC saistījums savā valodā. Tomēr praksē Codex spēj paveikt lielu daļu smagā darba, ja tam iesniedz JSON shēmu un dokumentāciju. Daudzas komandas, ar kurām mēs strādājām, spēja ātri izveidot funkcionējošu integrāciju, izmantojot Codex.

Citi veidi, kā integrēt Codex

Codex Exec⁠(atveras jaunā logā)

Viegls, skriptējams CLI režīms vienreizējiem uzdevumiem un CI izpildēm. Tas ir labi piemērots automatizācijai un izpildes procesiem, kur vēlaties, lai viena komanda tiktu izpildīta līdz galam bez lietotāja iejaukšanās, straumētu strukturētus rezultātus žurnāliem un beigtu darbu ar skaidru izdošanās vai neizdošanās signālu.

Codex SDK⁠(atveras jaunā logā)

TypeScript bibliotēka vietējo Codex aģentu programmātiskai vadībai no jūsu pašu lietojumprogrammas. Tā ir vispiemērotākā gadījumos, kad servera puses rīkiem un darbplūsmām nepieciešama iebūvēta bibliotēkas saskarne, neveidojot atsevišķu JSON-RPC klientu. Tā kā tā tika izlaista agrāk nekā App Server, pašlaik tā atbalsta mazāk valodu un mazāku funkcionalitātes apjomu. Ja būs izstrādātāju interese, mēs varam pievienot papildu SDK, kas aptver App Server protokolu, lai komandas varētu aptvert lielāku daļu no testēšanas ietvara, nerakstot JSON-RPC saistījumus.

Virzoties tālāk

Šajā ierakstā mēs dalījāmies ar to, kāda ir mūsu pieeja jauna standarta izstrādei mijiedarbībai ar aģentiem un kā Codex ietvaru pārvērst par stabilu, klientiem draudzīgu protokolu. Mēs apskatījām, kā App Server nodrošina piekļuvi Codex kodolam, ļauj klientiem vadīt pilnu aģenta ciklu un nodrošina plašu saskarņu klāstu, tostarp TUI, lokālās IDE integrācijas un tīmekļa izpildlaiku.

Ja tas rosināja idejas par Codex integrēšanu jūsu darbplūsmās, ir vērts izmēģināt App Server. Viss pirmkods atrodas Codex CLI atvērtā pirmkoda repozitorijā⁠(atveras jaunā logā). Droši dalieties ar savām atsauksmēm un funkciju pieprasījumiem. Esam priecīgi uzklausīt jūs un turpināt padarīt aģentus pieejamākus ikvienam.

Autors

Celia Chen

Pateicības

Īpaša pateicība Michael Bolin, Owen Lin, Eric Traut un Rasmus Rygaard, kuri sniedza ieguldījumu šajā ierakstā, un visai Codex komandai, kas strādāja pie App Server.

Zemsvītras piezīmes

1
Mēs izmantojam “JSON‑RPC lite” variantu: tas saglabā pieprasījuma/atbildes/paziņojuma formu, bet izlaiž "jsonrpc": "2.0" galveni un ir veidots kā JSONL, izmantojot stdio, nevis stingru JSON‑RPC 2.0.
2
“stdio” attiecas uz app-server stdin/stdout konteinerā. Mitinātās konfigurācijās šīs straumes bieži tiek tunelētas caur pastāvīgu tīkla savienojumu (piemēram, līdzīgi WebSocket) uz konteineru izpildvidi – tādējādi tā uzvedas kā stdio, pat ja tā nav burtiski vietējs procesu savienojums.

Turpināt lasīt

Skatīt visu

Pašuzlabojošu nodokļu aģentu veidošana ar Codex

Inženierija2026. g. 27. maijs

Drošas un efektīvas smilškastes izveide, lai iespējotu Codex lietošanu Windows vidē

Inženierija2026. g. 13. maijs

No kurienes radās goblini

Inženierija2026. g. 5. maijs