Siirry pääsisältöön
OpenAI

4. helmikuuta 2026

Tekniikka

Codex-valikoiman avaaminen: miten rakensimme sovelluspalvelimen

Celia Chen, teknisen henkilöstön jäsen

Ladataan...

OpenAI:n koodausagentti Codex on saatavilla monilla eri alustoilla: verkkosovelluksessa⁠(avautuu uudessa ikkunassa), CLI:ssä⁠(avautuu uudessa ikkunassa), IDE-laajennuksessa⁠(avautuu uudessa ikkunassa) ja uudessa Codex macOS -sovelluksessa. Ne kaikki toimivat saman Codex-välineen varassa – agenttisilmukan ja logiikan, joka on kaikkien Codex-kokemusten taustalla. Mikä on kriittinen yhteys niiden välillä? Codex App Server⁠(avautuu uudessa ikkunassa), asiakasystävällinen ja kaksisuuntainen JSON-RPC1-API.

Tässä julkaisussa esittelemme Codex App Serverin ja jaamme tähänastiset oppimme parhaista tavoista tuoda Codexin ominaisuudet tuotteeseesi, jotta käyttäjäsi voivat tehostaa työnkulkujaan. Käsittelemme App Serverin arkkitehtuuria ja protokollaa sekä sitä, miten se integroituu eri Codex-pintoihin. Lisäksi annamme vinkkejä Codexin hyödyntämiseen, halusitpa sitten tehdä Codexista koodintarkistajan, SRE-agentin tai koodausavustajan.

App Serverin alkuperä

Ennen kuin sukellamme arkkitehtuuriin, on hyödyllistä tuntea App Serverin taustatarina. Aluksi App Server oli käytännöllinen tapa käyttää Codex-välinettä uudelleen eri tuotteissa, ja se kehittyi vähitellen vakioprotokollaksemme.

Codex CLI alkoi TUI:na (terminaalikäyttöliittymänä), mikä tarkoittaa, että Codexia käytetään terminaalin kautta. Kun rakensimme VS Code -laajennuksen (IDE-ystävällisemmän tavan olla vuorovaikutuksessa Codex-agenttien kanssa), tarvitsimme tavan käyttää samaa kehystä, jotta voisimme ajaa saman agenttisilmukan IDE:n käyttöliittymästä ilman, että se täytyy toteuttaa uudelleen. Se tarkoitti monipuolisten vuorovaikutusmallien tukemista pelkän pyyntö/vastaus-mallin lisäksi, kuten työtilan tutkimista, edistymisen suoratoistoa agentin päättelyn aikana ja erojen tuottamista. Aluksi kokeilimme Codexin esittämistä MCP-palvelimena⁠(avautuu uudessa ikkunassa), mutta MCP-semanttiikan säilyttäminen tavalla, joka olisi järkevä VS Codelle, osoittautui vaikeaksi. Sen sijaan otimme käyttöön JSON-RPC-protokollan, joka peilasi TUI-silmukkaa ja josta tuli App Serverin epävirallinen ensimmäinen versio⁠(avautuu uudessa ikkunassa). Tuolloin emme odottaneet muiden asiakkaiden olevan riippuvaisia App Serveristä, joten sitä ei suunniteltu vakaaksi rajapinnaksi.

Kun Codexin käyttöönotto kasvoi seuraavien kuukausien aikana, sisäiset tiimit ja ulkoiset kumppanit halusivat mahdollisuuden integroida saman työkalun omiin tuotteisiinsa nopeuttaakseen käyttäjiensä ohjelmistokehityksen työnkulkuja. Esimerkiksi JetBrains ja Xcode halusivat IDE-tason agenttikokemuksen, kun taas Codex-työpöytäsovelluksen piti koordinoida useita Codex-agentteja rinnakkain. Nämä vaatimukset saivat meidät suunnittelemaan alustan, johon sekä omat tuotteemme että kumppaneidemme integroinnit voivat luottaa pitkällä aikavälillä. Sen piti olla helppo integroida ja taaksepäin yhteensopiva, eli voisimme kehittää protokollaa rikkomatta olemassa olevia asiakasjärjestelmiä.

Seuraavaksi käymme läpi, miten suunnittelimme arkkitehtuurin ja protokollan, jotta eri asiakkaat voivat käyttää samaa välinettä.

Codex-valikoiman sisällä

Ensinnäkin, tarkastellaan tarkemmin Codex-välineen sisältöä ja sitä, miten Codex-sovelluspalvelin tarjoaa sen asiakkaille. Viimeisimmässä Codex-blogissamme esittelimme ydintoiminnon, joka koordinoi käyttäjän, mallin ja työkalujen välistä vuorovaikutusta. Tämä on Codex-välineen ydinlogiikka, mutta agentin kokemukseen kuuluu paljon muutakin:

1. Viestiketjun elinkaari ja pysyvyys Ketju on Codex-keskustelu käyttäjän ja Codex-agentin välillä. Codex luo, jatkaa, haaroittaa ja arkistoi ketjuja sekä tallentaa tapahtumahistorian, jotta asiakkaat voivat muodostaa yhteyden uudelleen ja luoda yhtenäisen aikajanan.

2. Määritykset ja todennus Codex lataa kokoonpanon, hallinnoi oletusasetuksia ja suorittaa todennustyönkulkuja, kuten ”Kirjaudu sisään ChatGPT:llä”, mukaan lukien tunnistetietojen tila.

3. Työkalun suoritus ja laajennukset Codex suorittaa shell- ja tiedostotyökaluja hiekkalaatikossa ja yhdistää integrointeja, kuten MCP-palvelimet ja taidot, jotta ne voivat osallistua agenttisilmukkaan yhdenmukaisen käytäntömallin mukaisesti.

Kaikki tässä mainitsemamme agenttilogiikka, mukaan lukien keskeinen agenttisilmukka, sijaitsee Codex CLI -koodikannan osassa nimeltä ”Codex core⁠(avautuu uudessa ikkunassa).” Codex core on sekä kirjasto, jossa kaikki agenttikoodi sijaitsee, että ajonaikainen ympäristö, joka voidaan käynnistää agenttisilmukan suorittamiseen ja yhden Codex-ketjun (keskustelun) pysyvyyden hallintaan.

Jotta Codex-väline olisi hyödyllinen, sen on oltava asiakkaiden käytettävissä. Siinä vaiheessa App Server astuu kuvaan.

Kaavio nimeltä ”App Serverin prosessivirta”. Asiakas lähettää JSON-RPC-viestejä stdio-lukijalle, joka ohjaa pyynnöt Codex-viestinkäsittelijälle. Käsittelijä on vuorovaikutuksessa säikeiden hallinnan ja ydinsäikeen kanssa hakusäikeiden, säiekahvojen, lähetettyjen pyyntöjen sekä tapahtumien/päivitysten kautta ja palauttaa vastaukset asiakkaalle.

Sovelluspalvelin toimii sekä JSON-RPC-protokollana asiakkaan ja palvelimen välillä että pitkäkestoisena prosessina, joka isännöi Codexin pääketjuja. Kuten yllä olevasta kaaviosta voidaan nähdä, App Server -prosessilla on neljä pääkomponenttia: stdio-lukija, Codex-viestinkäsittelijä, ketjujen hallinta ja pääsäikeet. Ketjujen hallinta käynnistää yhden pääistunnon jokaista ketjua kohden, ja Codex-viestinkäsittelijä kommunikoi suoraan kunkin pääistunnon kanssa asiakaspyyntöjen lähettämiseksi ja päivitysten vastaanottamiseksi.

Yksi asiakaspyyntö voi johtaa moniin tapahtumapäivityksiin, ja nämä yksityiskohtaiset tapahtumat mahdollistavat monipuolisen käyttöliittymän rakentamisen App Serverin päälle. Lisäksi stdio-lukija ja Codex-viestinkäsittelijä toimivat käännöskerroksena asiakkaan ja Codex-pääsäikeiden välillä. Ne muuttavat asiakkaan JSON-RPC-pyynnöt Codex-päätoiminnoiksi, kuuntelevat Codex coren sisäistä tapahtumavirtaa ja muuntavat sitten nämä matalan tason tapahtumat pieneksi joukoksi vakaita, käyttöliittymävalmiita JSON-RPC-ilmoituksia.

JSON-RPC-protokolla asiakkaan ja App Serverin välillä on täysin kaksisuuntainen. Tyypillisessä säikeessä on asiakaspyyntö ja useita palvelimen ilmoituksia. Lisäksi palvelin voi aloittaa pyyntöjä, kun agentti tarvitsee syötettä, kuten hyväksynnän, ja sitten keskeyttää vuoron, kunnes asiakas vastaa.

Keskustelun perustekijät

Seuraavaksi tarkastelemme keskustelun perustekijöitä, jotka ovat App Server -protokollan rakennuspalikoita. Agenttisilmukkaa varten API:n suunnittelu on haastavaa, koska käyttäjän ja agentin välinen vuorovaikutus ei ole yksinkertainen pyyntö/vastaus. Yksi käyttäjän pyyntö voi avautua jäsennellyksi toimintojen sarjaksi, jonka asiakkaan on esitettävä uskollisesti: käyttäjän syöte, agentin asteittainen eteneminen ja matkan varrella tuotetut artefaktit (esim. erot). Jotta tämä vuorovaikutusvirta olisi helppo integroida ja joustava eri käyttöliittymissä, päädyimme kolmeen ydinalkeeseen, joilla on selkeät rajat ja elinkaaret:

1. Kohde: kohde on Codexin syötteen ja tulosteen atominen yksikkö. Kohteet ovat tyypitettyjä (esim. käyttäjän viesti, agentin viesti, työkalun suoritus, hyväksyntäpyyntö, ero) ja jokaisella on selkeä elinkaari:

  • kohde/aloitettu kun kohde alkaa
  • valinnaiset kohde/*/delta -tapahtumat sisältövirtoina (suoratoistettaville kohdetyypeille)
  • kohde/suoritettu kun kohde valmistuu lopullisen hyötykuormansa kanssa

Tämän elinkaaren ansiosta asiakkaat voivat aloittaa renderöinnin heti tilassa aloitettu, suoratoistaa inkrementaalisia päivityksiä tilassa delta ja viimeistellä tilassa suoritettu.

2. Vuoro: Vuoro on yksi agentin työyksikkö, joka alkaa käyttäjän syötteestä. Se alkaa, kun asiakas lähettää syötteen (esimerkiksi ”suorita testit ja tee yhteenveto virheistä”) ja päättyy, kun agentti lopettaa kyseisen syötteen tulosten tuottamisen. Vuoro sisältää sarjan kohteita, jotka kuvaavat välivaiheita ja matkan varrella syntyneitä tuloksia.

3. Viestiketju: ketju on kestävä säiliö jatkuvalle Codex-istunnolle käyttäjän ja agentin välillä. Se sisältää useita vuoroja. Ketjuja voidaan luoda, jatkaa, haarauttaa ja arkistoida. Ketjun historia säilytetään, jotta asiakkaat voivat yhdistää uudelleen ja näyttää yhtenäisen aikajanan.

Seuraavaksi tarkastelemme yksinkertaistettua keskustelua asiakkaan ja asiakaspalvelijan välillä, jossa keskustelu on esitetty perustekijöillä:

Kaavio otsikolla ”Asiakas–palvelinprotokollan viestivirta: yhteyden muodostamisen alustus.” Asiakas lähettää alustamispyynnön, jossa on asiakastiedot, palvelimelle. Palvelin vastaa tulostapahtumalla, joka sisältää userAgent-merkkijonon ”my_client/1.0”.

Keskustelun alussa asiakkaan ja palvelimen on luotava yhteyden muodostamisen alustus. Asiakkaan täytyy lähettää yksi initialize -pyyntö ennen muita metodeja, ja palvelin vahvistaa sen vastauksella. Tämä antaa palvelimelle mahdollisuuden mainostaa ominaisuuksiaan ja antaa molemmille osapuolille mahdollisuuden sopia protokollaversioista, ominaisuuslipuista ja oletusasetuksista ennen varsinaisen työn aloittamista. Tässä on esimerkki OpenAI:n VS Code -laajennuksen hyötykuormasta:

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
}

Palvelin palauttaa seuraavan vastauksen:

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
}
Kaavio otsikolla ”Asiakas-palvelinprotokollan viestivirta: ketjun ja vuoron elinkaari.” Asiakas lähettää palvelimelle ketjun/aloitus- ja vuoron/aloitus-pyyntöjä. Palvelin lähettää tapahtumia–ketju/aloitettu, vuoro/aloitettu, kohde/aloitettu ja kohde/suoritettu–jotka osoittavat vuoron, jossa käyttäjän viesti on ”suorita testit ja tiivistä virheet.”

Kun asiakas tekee uuden pyynnön, se luo ensin ketjun ja sitten vuoron. Palvelin lähettää ilmoituksia edistymisestä (ketju/aloitettu ja vuoro/aloitettu). Se lähettää myös takaisin syötteet, jotka se rekisteröi kohteiksi, kuten käyttäjäviestin tässä.

Kaavio otsikolla ”Asiakas-palvelin-protokollan viestien kulku: Työkalun suoritus valinnaisella hyväksynnällä.” Työkalukutsun aikana palvelin lähettää kohteen kohde/aloitettu ja sitten kohde/komennonSuoritus/pyynnönHyväksyntä syyllä (“suorita testit”). Asiakas palauttaa hyväksyntätapahtuman (hyväksy/hylkää). Palvelin lähettää sitten kohteen kohde/suoritettu, joka osoittaa komennon suorituksen (”pnpm-testi”).

Työkalukutsut lähetetään myös asiakkaalle kohteina. Lisäksi palvelin voi pyytää asiakkaalta hyväksynnän ennen kuin se voi suorittaa toiminnon lähettämällä palvelinpyynnön. Hyväksyntä keskeyttää vuoron, kunnes asiakas vastaa joko ”salli” tai ”kiellä”. Tältä hyväksyntäprosessi näyttää VS Code -laajennuksessa:

Näytölle ilmestyy tummateemainen kehote: ”Haluatko sallia pnpm-testin suorittamisen tässä työtilassa?” Siinä luetellaan vaihtoehdot: 1) Kyllä, 2) Kyllä, äläkä kysy uudelleen komennoista, jotka alkavat pnpm-testillä, ja 3) Ei. Alareunassa on Lähetä-painike.
Kaavio otsikolla ”Asiakas–palvelinprotokollan viestivirta: Suoratoistoagentin viestivirta.” Palvelin lähettää avustajan viestin osissa: kohde/aloitettu, kaksi agentMessage/delta-tapahtumaa (”suoritti 3 testiä”, "kaikki läpäisseet"), sitten kohde/suoritettu. Vuoro päättyy tilaan vuoro/suoritettu.

Lopuksi palvelin lähettää agenttiviestin ja päättää sitten vuoron komennolla vuoro/suoritettu. Agenttiviestien delta-tapahtumat välittävät viestin osia takaisin, kunnes viesti viimeistellään tapahtumalla kohde/suoritettu.

Kaavion viestit on yksinkertaistettu, jotta ne olisivat helpommin luettavissa. Jos haluat nähdä JSON:n koko vuoron osalta, voit suorittaa testiasiakkaan Codex CLI -repositoriosta:

Bash

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

Integrointi asiakkaiden kanssa

Katsotaan seuraavaksi, miten eri asiakasrajapinnat upottavat Codexin App Serverin kautta. Käsittelemme kolme mallia: paikalliset sovellukset ja IDE:t, Codex-verkkoympäristö ja TUI.

Kaavio otsikolla “Codex-asiakkaat integroitu Codex-välineeseen sovelluspalvelimen kautta.” Ensimmäisen osapuolen asiakkaat (Codex Desktop App, TUI/CLI, Web Runtime) ja kolmannen osapuolen integraatiot (JetBrains IDEt, VS Code, Xcode) kommunikoivat Codex-ympäristön kanssa JSON-RPC-kutsujen kautta.

Kaikissa kolmessa tapauksessa siirtotapa on JSON-RPC stdio:n kautta (JSONL). JSON-RPC tekee asiakassidosten rakentamisesta helppoa valitsemallasi ohjelmointikielellä. Codex-pinnat ja kumppani-integroinnit ovat toteuttaneet App Server -asiakkaita kielillä, kuten Go, Python, TypeScript, Swift ja Kotlin. TypeScriptin osalta voit luoda määritelmät suoraan Rust-protokollasta suorittamalla seuraavan komennon:

Bash

1
codex app-server generate-ts

Muiden kielten osalta voit luoda JSON-skeemapaketin ja syöttää sen haluamaasi koodigeneraattoriin suorittamalla seuraavan komennon:

Bash

1
codex app-server generate-json-schema
Paikalliset sovellukset ja IDE:t
Kuvakaappaus VS Codesta, jossa Codex-laajennus on käynnissä. Rust-testitiedosto on auki, ja sen alapuolella Codex-paneeli kuvailee, että ajetaan vain fmt ja cargo test -p codex-app-server, ja se raportoi, että muotoilu ja testit ovat käynnissä odottaen lopullista läpäisy/hylkäys-tulosta.

Paikalliset asiakkaat yleensä niputtavat tai hakevat alustakohtaisen App Server -binäärin, käynnistävät sen pitkäkestoisena aliprosessina ja pitävät kaksisuuntaisen stdio-kanavan auki JSON-RPC:tä varten. VS Code -laajennuksessamme ja työpöytäsovelluksessamme toimitettu artefakti sisältää alustakohtaisen Codex-binaarin ja on kiinnitetty testattuun versioon, jotta asiakasohjelma suorittaa aina tarkalleen niitä osia, jotka olemme validoineet.

Kaikki integroinnit eivät voi lähettää asiakaspäivityksiä usein. Jotkut kumppanit, kuten Xcode, erottavat julkaisusyklit pitämällä asiakasohjelman vakaana ja sallimalla sen osoittaa uudempaan App Server -binaariin tarvittaessa. Näin he voivat ottaa käyttöön palvelinpuolen parannuksia (esimerkiksi paremman automaattisen tiivistyksen Codex-ytimessä tai äskettäin tuetut määritysavaimet) ja julkaista virhekorjauksia odottamatta asiakkaan julkaisua. App Serverin JSON-RPC-rajapinta on suunniteltu taaksepäin yhteensopivaksi, joten vanhemmat asiakkaat voivat kommunikoida uusien palvelimien kanssa turvallisesti.

Codex Web
Kuvakaappaus Codex-verkkokäyttöliittymästä, jossa näkyy päivitys otsikolla ”Päivitä kirjautumisen onnistumisviesti.” Vasen paneeli tiivistää muutokset, testit ja muokatut tiedostot, kun taas oikea paneeli näyttää koodieron tiedostolle login.rs, jossa on päivitetty kirjautumisen onnistumisviestin sanamuoto.

Codex Web käyttää Codex-välinettä, mutta suorittaa sen säilöympäristössä. Työntekijä varustaa säilön uloskuitatulla työtilalla, käynnistää App Server -binäärin sen sisällä ja ylläpitää pitkäkestoista JSON-RPC-yhteyttä stdio2-kanavan kautta. Web-sovellus (käynnissä käyttäjän selaimen välilehdessä) kommunikoi Codex-taustajärjestelmän kanssa HTTP:n ja SSE:n kautta, jotka suoratoistavat työntekijän tuottamia tehtävätapahtumia. Tämä pitää selainpuolen käyttöliittymän kevyenä ja tarjoaa silti meille yhdenmukaisen ajoympäristön sekä työpöydällä että verkossa.

Koska verkkoistunnot ovat lyhytkestoisia (välilehdet sulkeutuvat, verkot katkeavat), verkkosovellus ei voi olla pitkäaikaisten tehtävien luotettava tietolähde. Kun tila ja edistyminen säilytetään palvelimella, työ jatkuu, vaikka välilehti katoaisi. Suoratoistoprotokolla ja tallennetut säiesessiot helpottavat uuden istunnon uudelleenliittämistä, jatkamista siitä, mihin se jäi, ja tilanteen päivittämistä ilman, että tilaa tarvitsee rakentaa uudelleen asiakasohjelmassa.

TUI/Codex CLI
Kuvakaappaus terminaalista, jossa Codex CLI on käynnissä. Se näyttää OpenAI Codex -bannerin, jossa on malli GPT-5.2-Codex. medium, käyttäjäkomento “selitä minulle sovelluspalvelin” ja “Työskentely”-tila. Alla näkyy ehdotus: “kirjoita testit tiedostolle @filename”, ja vaihtoehdot pikanäppäimille.

Historiallisesti TUI oli "natiivi" asiakasohjelma, joka toimi samassa prosessissa kuin agenttisilmukka ja kommunikoi suoraan Rustin ydintyyppien kanssa, eikä sovelluspalvelinprotokollan kautta. Se teki varhaisen iteroinnin nopeaksi, mutta teki myös TUI:sta erityistapauksen.

Nyt kun App Server on olemassa, aiomme uudistaa TUI:n⁠(avautuu uudessa ikkunassa) käyttämään sitä, jotta se toimisi kuten mikä tahansa muu asiakas: käynnistää App Serverin aliprosessin, käyttää JSON-RPC:tä stdio:n kautta ja renderöi samat suoratoistotapahtumat ja hyväksynnät. Tämä mahdollistaa työnkulut, joissa TUI voi yhdistää etäkoneella toimivaan Codex-palvelimeen, pitäen agentin lähellä laskentaa ja jatkaen työtä, vaikka kannettava tietokone menisi lepotilaan tai yhteys katkeaisi, samalla kun se toimittaa paikallisesti reaaliaikaisia päivityksiä ja ohjauksia paikallisesti.

Sopivan protokollan valinta

Codex App Server tulee olemaan ensisijainen integrointimenetelmä, jota ylläpidämme jatkossa, mutta on myös muita menetelmiä, joiden toiminnallisuus on rajallisempi. Oletusarvoisesti suosittelemme, että asiakkaat käyttävät Codex App Serveriä Codexin integrointiin, mutta on hyödyllistä tarkastella eri integrointimenetelmiä ja ymmärtää niiden edut ja haitat. Alla ovat yleisimmät tavat käyttää Codexia ja tilanteet, joissa kukin niistä sopii parhaiten.

JSON-RPC-protokollat

Codex MCP-palvelimena

Suorita codex mcp-server⁠(avautuu uudessa ikkunassa) ja yhdistä mihin tahansa MCP-asiakasohjelmaan, joka tukee stdio-palvelimia (esim. OpenAI Agents SDK⁠(avautuu uudessa ikkunassa)). Tämä sopii hyvin, jos sinulla on jo MCP-pohjainen työnkulku ja haluat käyttää Codexia kutsuttavana työkaluna. Haittapuolena on, että saat vain sen, mitä MCP paljastaa, joten Codex-kohtaiset vuorovaikutukset, jotka nojaavat rikkaampaan istuntosemantiikkaan (esim. diff-päivitykset), eivät välttämättä välity siististi MCP-päätepisteiden kautta.

Toimittajien välisten agenttien välineprotokollat

Jotkin ekosysteemit tarjoavat siirrettävän käyttöliittymän, joka voi kohdistua useisiin mallitoimittajiin ja ajonaikaisiin ympäristöihin. Tämä voi olla hyvä valinta, jos haluat yhden abstraktion, joka koordinoi useita agentteja. Kompromissina on, että nämä protokollat usein lähentyvät yhteiseen ominaisuuksien osajoukkoon, mikä voi vaikeuttaa rikkaampien vuorovaikutusten esittämistä, erityisesti silloin, kun palveluntarjoajakohtaisilla työkalujen ja istuntojen semantiikoilla on merkitystä. Tämä ala kehittyy nopeasti, ja odotamme, että yleisempiä standardeja syntyy lisää, kun löydämme parhaat perusrakenteet todellisten agenttien työnkulkujen kuvaamiseen (taidot⁠(avautuu uudessa ikkunassa) on tästä hyvä esimerkki).

Codex App Server

Valitse App Server, kun haluat, että koko Codex-väline on käytettävissä vakaana ja käyttöliittymäystävällisenä tapahtumavirtana. Saat sekä agenttisilmukan täyden toiminnallisuuden että muita tukevia ominaisuuksia, kuten Kirjautuminen ChatGPT:llä, mallien löytämisen ja määritysten hallinnan. Pääasiallinen kustannus on integraatiotyö, koska asiakaspuolen JSON-RPC-sidonta täytyy rakentaa omalla kielellä. Käytännössä Codex pystyy kuitenkin tekemään suuren osan raskaasta työstä, jos sille syötetään JSON-skeema ja dokumentaatio. Monet tiimit, joiden kanssa työskentelimme, pystyivät nopeasti luomaan toimivan integroinnin Codexin avulla.

Muita tapoja upottaa Codex.

Codex Exec⁠(avautuu uudessa ikkunassa)

Kevyt ja skriptattava CLI-tila kertaluonteisille tehtäville ja CI-ajoille. Se sopii hyvin automaatioon ja putkistoihin, joissa haluat yhden komennon suorittavan tehtävän loppuun asti ei-vuorovaikutteisesti, lähettämään jäsenneltyä tulostetta lokiin ja lopettamaan selkeällä onnistumis- tai epäonnistumissignaalilla.

Codex SDK⁠(avautuu uudessa ikkunassa)

TypeScript-kirjasto, jonka avulla voit ohjelmallisesti hallita paikallisia Codex-agentteja omasta sovelluksestasi käsin. Se on paras ratkaisu, kun haluat natiivin kirjastoliittymän palvelinpuolen työkaluille ja työnkulkuille ilman erillisen JSON-RPC-asiakkaan rakentamista. Koska se toimitettiin aiemmin kuin App Server, se tukee tällä hetkellä vähemmän kieliä ja sen kattavuus on pienempi. Jos kehittäjät ovat kiinnostuneita, voimme lisätä uusia SDK:ita, jotka kääriytyvät App Server -protokollan ympärille, jotta tiimit voivat kattaa suuremman osan välineestä ilman JSON-RPC-sidosten kirjoittamista.

Asian vieminen eteenpäin

Tässä julkaisussa jaoimme, miten lähestymme agenttien kanssa vuorovaikuttamisen uuden standardin suunnittelua ja miten Codex-harness muutetaan vakaaksi ja asiakasystävälliseksi protokollaksi. Käsittelimme, kuinka App Server paljastaa Codexin ytimen, antaa asiakkaille mahdollisuuden ohjata koko agentin silmukkaa ja tukee laajaa valikoimaa käyttöliittymiä, mukaan lukien TUI, paikalliset IDE-integraatiot ja web-ajoympäristö.

Jos tämä herätti ideoita Codexin integroimiseksi omiin työnkulkuihisi, kannattaa kokeilla App Serveriä. Kaikki lähdekoodi on Codex CLI:n avoimen lähdekoodin repositoriossa⁠(avautuu uudessa ikkunassa). Voit vapaasti jakaa palautteesi ja ominaisuuspyyntösi. Odotamme innolla yhteydenottoasi ja jatkamme työtä, jotta agentit ovat entistä helpommin kaikkien saatavilla.

Tekijä

Celia Chen

Kiitokset

Erityiskiitokset Michael Bolinille, Owen Linille, Eric Trautille ja Rasmus Rygaardille, jotka osallistuivat tähän julkaisuun, sekä koko Codex-tiimille, joka työskenteli App Serverin parissa.

Alaviitteet

  1. 1

    Käytämme ”JSON‑RPC lite” -varianttia: se säilyttää kohteen pyyntö/vastaus/ilmoitus-muoto, mutta jättää pois "jsonrpc": "2.0" -otsikon ja se on kehystetty JSONL-muotoon stdio:n kautta eikä tiukaksi JSON‑RPC 2.0:ksi.

  2. 2

     “stdio” viittaa sovelluspalvelimen kohteeseen stdin/stdout säilön sisällä. Isännöidyissä kokoonpanoissa nämä virrat usein tunnelointaan pysyvän verkkoyhteyden (esim. WebSocket-tyyppinen) yli säilöajonaikaan – joten se käyttäytyy kuin stdio, vaikka se ei olisikaan kirjaimellisesti paikallinen putki.

Jatka lukemista

Näytä kaikki
Tax Agent > Art Card
Itseään parantavien veroagenttien rakentaminen Codexilla

Tekniikka

codex windows > art card
Turvallisen ja tehokkaan hiekkalaatikon rakentaminen Codexia varten Windowsissa

Tekniikka

MRC 1_1
Supercomputer networking to accelerate large scale AI training

Tekniikka