Siirry pääsisältöön
OpenAI

23. tammikuuta 2026

Tekniikka

Codex-agenttisilmukan avaaminen

Michael Bolin, teknisen henkilöstön jäsen

Ladataan...

Codex CLI⁠(avautuu uudessa ikkunassa) on monialustainen paikallinen ohjelmistoagentti, joka on suunniteltu tuottamaan korkealaatuisia ja luotettavia ohjelmistomuutoksia sekä toimimaan turvallisesti ja tehokkaasti tietokoneellasi. Olemme oppineet valtavasti maailmanluokan ohjelmistoagentin rakentamisesta sen jälkeen, kun lanseerasimme CLI:n ensimmäisen kerran huhtikuussa⁠. Näiden oivallusten avaamiseksi tämä on ensimmäinen osa jatkuvassa sarjassa, jossa tutkimme Codexin toiminnan eri puolia sekä kovalla työllä opittuja oppeja. (Jos haluat tarkempaa tietoa Codex CLI:n rakenteesta, tutustu avoimen lähdekoodin arkistoomme osoitteessa https://github.com/openai/codex⁠(avautuu uudessa ikkunassa). Monet suunnittelupäätöstemme yksityiskohdat on dokumentoitu GitHub-ongelmiin ja muutospyytöihin, jos haluat lisätietoja.

Aloitamme keskittymällä agenttisilmukkaan, joka on Codex CLI:n ydinlogiikka ja vastaa käyttäjän, mallin ja mallin kutsumien työkalujen välisen vuorovaikutuksen orkestroinnista merkityksellisen ohjelmistotyön suorittamiseksi. Toivomme, että tämä viesti antaa sinulle hyvän käsityksen agenttimme (tai ”harness”) roolista LLM:n käytössä.

Ennen kuin aloitamme, lyhyt huomautus terminologiasta: OpenAI:ssa ”Codex” kattaa joukon ohjelmistoagenttituotteita, mukaan lukien Codex CLI, Codex Cloud ja Codex VS Code -laajennus. Tämä julkaisu keskittyy Codex-ympäristöön, joka tarjoaa keskeisen agenttisilmukan ja suorituksen logiikan, joka on kaikkien Codex-kokemusten taustalla ja tuodaan esiin Codex CLI:n kautta. Selkeyden vuoksi käytämme tässä termejä ”Codex” ja ”Codex CLI” toistensa sijasta.

Agenttisilmukka

Jokaisen tekoälyagentin ytimessä on "agenttisilmukka". Agenttisilmukan yksinkertaistettu esimerkki näyttää tältä:

Kaavio nimeltä ”Agent loop” (Agenttisilmukka), joka havainnollistaa, miten tekoälyjärjestelmä käsittelee käyttäjän pyynnön, kutsuu työkaluja, tarkastelee tuloksia, päivittää suunnitelmansa ja palauttaa tuotokset. Nuolet yhdistävät vaiheita, kuten käyttäjän syöte, mallin päättely, työkalutoiminnot ja lopullinen vastaus.

Aluksi agentti ottaa käyttäjältä syötteen, joka sisällytetään tekstiohjeisiin, joita se valmistelee mallille ja joita kutsutaan kehotteeksi.

Seuraava vaihe on kysyä mallilta lähettämällä sille ohjeemme ja pyytämällä sitä tuottamaan vastauksen, prosessi, joka tunnetaan päättelynä. Päättelyn aikana tekstikehote muunnetaan ensin syötteenä tunnisteiksi⁠(avautuu uudessa ikkunassa)–kokonaisluvuiksi, jotka viittaavat mallin sanastoon. Näitä tunnuksia käytetään sitten mallin näytteenottoon, jolloin syntyy uusi tulostustunnusten sarja.

Tulostetunnukset käännetään takaisin tekstiksi, josta tulee mallin vastaus. Koska tunnukset tuotetaan inkrementaalisesti, tämä käännös voi tapahtua mallin suorituksen aikana, minkä vuoksi monet LLM-pohjaiset sovellukset näyttävät suoratoistettavaa tulostetta. Käytännössä päättely on yleensä kätketty tekstiä käsittelevän API:n taakse, jolloin tokenisoinnin yksityiskohdat jäävät piiloon.

Päättelyvaiheen tuloksena malli joko (1) tuottaa lopullisen vastauksen käyttäjän alkuperäiseen syötteeseen tai (2) pyytää työkalukutsua, jonka agentin odotetaan suorittavan (esim. ”suorita ls ja raportoi tuloste”). Tapauksessa (2) agentti suorittaa työkalukutsun ja lisää sen tulosteen alkuperäiseen kehotteeseen. Tätä tulosta käytetään luomaan uusi syöte, jota käytetään mallin uudelleenkyselyyn; agentti voi sitten ottaa nämä uudet tiedot huomioon ja yrittää uudelleen.

Tämä prosessi toistuu, kunnes malli lakkaa tuottamasta työkalukutsuja ja tuottaa sen sijaan viestin käyttäjälle (OpenAI-malleissa tätä kutsutaan avustajaviestiksi). Monissa tapauksissa tämä viesti vastaa suoraan käyttäjän alkuperäiseen pyyntöön, mutta se voi myös olla jatkokysymys käyttäjälle.

Koska agentti voi suorittaa työkalukutsuja, jotka muokkaavat paikallista ympäristöä, sen “tuotos” ei rajoitu pelkästään avustajan viestiin. Monissa tapauksissa ohjelmistoagentin ensisijainen tuotos on koodi, jonka se kirjoittaa tai muokkaa koneellasi. Siitä huolimatta jokainen vuoro päättyy aina avustajan viestiin – kuten ”Lisäsin pyytämäsi architecture.md -tiedoston” – mikä viestii agenttisilmukan päättymistilasta. Agentin näkökulmasta sen työ on valmis ja hallinta palautuu käyttäjälle.

Kaaviossa esitetty matka käyttäjän syötteestä agentin vastaukseen kutsutaan keskustelun yhdeksi vuoroksi (Codexissa ketjuksi ). Tämä keskusteluvuoro voi kuitenkin sisältää useita iteraatioita mallin päättelyn ja työkalukutsujen välillä. Aina kun lähetät uuden viestin olemassa olevaan keskusteluun, keskusteluhistoria sisältyy osana uuden vuoron kehotetta, joka sisältää aiempien vuorojen viestit ja työkalukutsut:

Kaavio nimeltä ”Multi-turn agent loop”, joka näyttää, miten tekoälyagentti ottaa toistuvasti käyttäjän syötteen, luo toimintoja, käyttää työkaluja, päivittää tilan ja palauttaa tulokset. Sisältää merkityt vaiheet, nuolet ja esimerkkityökalujen tulosteet, jotka havainnollistavat agentin päättelysykliä.

Tämä tarkoittaa, että keskustelun kasvaessa myös mallin näytteenottoon käytettävän kehotteen pituus kasvaa. Tällä pituudella on merkitystä, koska jokaisella mallilla on konteksti-ikkuna, joka on enimmäismäärä tokeneja, joita se voi käyttää yhdessä päättelykutsussa. Huomaa, että tämä ikkuna sisältää sekä syöte- että tuotos-tokenit. Kuten saatat kuvitella, agentti voisi päättää tehdä satoja työkalukutsuja yhdellä vuorolla, mikä saattaisi kuluttaa konteksti-ikkunan loppuun. Tästä syystä konteksti-ikkunan hallinta on yksi agentin monista tehtävistä. Tutustutaan siihen, miten Codex suorittaa agenttisilmukan.

Mallin päätelmä

Codex CLI lähettää HTTP-pyyntöjä Responses API:lle⁠(avautuu uudessa ikkunassa) suorittaakseen mallin päättelyn. Tarkastelemme, miten tieto kulkee Codexissa, joka käyttää Responses API:ta agenttilenkin ohjaamiseen.

Codex CLI:n käyttämä Responses API -päätepiste on mukautettavissa⁠(avautuu uudessa ikkunassa), joten sitä voidaan käyttää minkä tahansa päätepisteen kanssa, joka tukee Responses API:ta⁠(avautuu uudessa ikkunassa):

Tutkitaan, kuinka Codex luo kehotteen keskustelun ensimmäiselle päättelykutsulle.

Alustavan kehotteen rakentaminen

Loppukäyttäjänä et määritä Responses API:lle tehtävää kyselyä varten käytettävää kehotetta, jota käytetään mallin näytteistämiseen sanatarkasti. Sen sijaan määrität erilaisia syötetyyppejä osana kyselyäsi, ja Responses API -palvelin päättää, miten tämä tieto jäsennetään kehotteeksi, jonka malli on suunniteltu käsittelemään. Voit ajatella kehotea "kohdeluettelona". Tässä osiossa selitetään, miten kyselysi muunnetaan kyseiseksi luetteloksi.

Alkuperäisessä kehotteessa jokainen luettelon kohde on yhdistetty rooliin. Rooli ilmaisee, kuinka paljon painoarvoa siihen liittyvällä sisällöllä tulisi olla, ja se on jokin seuraavista arvoista (laskevassa tärkeysjärjestyksessä): järjestelmä, kehittäjä, käyttäjä, avustaja.

Responses API⁠(avautuu uudessa ikkunassa) vastaanottaa JSON-hyötykuorman, jossa on useita parametreja. Keskitymme näihin kolmeen:

Codexissa ohjeet-kenttä luetaan tiedostosta model_instructions_file⁠(avautuu uudessa ikkunassa) polussa ~/.codex/config.toml, jos se on määritetty; muussa tapauksessa käytetään malliin liittyviä base_instructions-ohjeita⁠(avautuu uudessa ikkunassa). Mallikohtaiset ohjeet sijaitsevat Codex-repossa ja ne sisällytetään CLI:hin (esim. gpt-5.2-codex_prompt.md⁠(avautuu uudessa ikkunassa)).

työkalut-kenttä on luettelo työkalumääritelmistä, jotka noudattavat Responses API:n määrittelemää skeemaa. Codexin osalta tämä sisältää Codex CLI:n tarjoamat työkalut, Responses API:n tarjoamat työkalut, jotka tulisi saattaa Codexin saataville, sekä käyttäjän tarjoamat työkalut, yleensä MCP-palvelimien kautta:

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
]

Lopuksi JSON-paketin syöte-kenttä on luettelo kohteista. Codex lisää seuraavat kohteet⁠(avautuu uudessa ikkunassa) syöte-kenttään ennen käyttäjäviestin lisäämistä:

1. Viesti, jossa on rooli=kehittäjä, joka kuvaa hiekkalaatikkoa, joka koskee vain Codexin tarjoamaa shell-työkalua, joka on määritelty työkalut-osiossa. Toisin sanoen muut työkalut, kuten MCP-palvelimien tarjoamat, eivät ole Codexin eristämiä ja niiden on itse huolehdittava omista turvatoimistaan.

Viesti rakennetaan mallipohjasta, jossa keskeiset sisältöosat tulevat Codex CLI:n mukana toimitetuista Markdown-katkelmista, kuten workspace_write.md⁠(avautuu uudessa ikkunassa) ja on_request.md⁠(avautuu uudessa ikkunassa):

Ilmiteksti

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. (Valinnainen) Viesti, jossa on rooli=kehittäjä ja jonka sisältö on developer_instructions-arvo, luettu käyttäjän config.toml-tiedostosta.

3. (Valinnainen) Viesti, jossa rooli=käyttäjä ja jonka sisältö on ”käyttäjäohjeet”, joita ei haeta yhdestä tiedostosta vaan jotka kootaan useista lähteistä⁠(avautuu uudessa ikkunassa). Yleisesti ottaen tarkemmat ohjeet annetaan myöhemmin:

4. Viesti, jossa rooli=käyttäjä ja joka kuvaa paikallista ympäristöä, jossa agentti toimii tällä hetkellä. Tämä määrittää nykyisen työhakemiston ja käyttäjän komentotulkin⁠(avautuu uudessa ikkunassa):

Ilmiteksti

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

Kun Codex on suorittanut kaikki edellä mainitut laskutoimitukset syötteen alustamiseksi, se liittää käyttäjän viestin keskustelun aloittamiseksi.

Aiemmat esimerkit keskittyivät kunkin viestin sisältöön, mutta huomaa, että jokainen syöte-elementti on JSON-objekti, jossa on tyyppi, rooli⁠(avautuu uudessa ikkunassa) ja sisältö seuraavasti:

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
}

Kun Codex on koonnut täydellisen JSON-hyötykuorman Responses API:lle, se tekee HTTP POST -pyynnön Valtuutus-otsikolla sen mukaan, miten Responses API -päätepiste on määritetty tiedostossa ~/.codex/config.toml (lisä-HTTP-otsikot ja kyselyparametrit lisätään, jos ne on määritelty).

Kun OpenAI Responses API -palvelin vastaanottaa pyynnön, se käyttää JSON-tiedostoa mallin kehotteen johtamiseen seuraavasti (tietysti Responses API:n mukautettu toteutus voisi tehdä toisenlaisen valinnan):

Tilannekuvakaavio, joka esittää yhden vaiheen tekoälyagentin silmukassa. Käyttäjän pyyntö saapuu malliin, joka tuottaa ajatuksen, toiminnon työkalun nimen kanssa ja työkalun syötteen. Kaavio korostaa tätä välivaiheen päättelyvaihetta ennen työkalun kutsumista.

Kuten huomaat, kehotteen kolmen ensimmäisen kohteen järjestyksen määrittää palvelin, ei asiakas. Tästä huolimatta näistä kolmesta kohdasta vain järjestelmäviestin sisältöä ohjaa myös palvelin, sillä työkalut ja ohjeet määräytyvät asiakkaan mukaan. Näitä seuraa JSON-paketin syöte, joka täydentää kehotteen.

Nyt kun meillä on kehote, olemme valmiita käyttämään mallia.

Ensimmäinen käännös

Tämä HTTP-pyyntö Responses API:lle käynnistää Codexissa keskustelun ensimmäisen ”vuoron”. Palvelin vastaa Server-Sent Events (SSE⁠(avautuu uudessa ikkunassa)) -virralla. Jokaisen tapahtuman data on JSON-paketin syöte, jossa on "tyyppi", joka alkaa "vastaus"-merkkijonolla. Se voi näyttää esimerkiksi tältä (täydellinen luettelo tapahtumista löytyy API-dokumentaatiostamme⁠(avautuu uudessa ikkunassa)):

Ilmiteksti

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

Codex kuluttaa tapahtumavirran⁠(avautuu uudessa ikkunassa) ja julkaisee sen uudelleen sisäisinä tapahtumaobjekteina, joita asiakas voi käyttää. Tapahtumia, kuten response.output_text.delta, käytetään käyttöliittymässä suoratoiston tukemiseen, kun taas muut tapahtumat, kuten response.output_item.added, muunnetaan objekteiksi, jotka liitetään syötteeseen myöhempiä Responses API -kutsuja varten.

Oletetaan, että ensimmäinen pyyntö Responses API:lle sisältää kaksi response.output_item.done-tapahtumaa: yhden, jossa on type=reasoning, ja toisen, jossa on type=function_call. Nämä tapahtumat on esitettävä JSONin syöte-kentässä, kun kysymme mallilta uudelleen työkalukutsun vastauksella. 

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
]

Tuloksena oleva kehote, jota käytetään mallin näytteenottoon osana seuraavaa kyselyä, näyttäisi tältä:

Kaavio, jossa on otsikko ”Snapshot 2” (Tilannevedos 2) ja joka esittää tekoälyagentin työkalukutsun jälkeen. Malli vastaanottaa työkaluhavainnon ja tuottaa uuden ajatuksen ja toiminnan. Nuolet yhdistävät syötteet, havainnot ja tuotokset havainnollistamaan, miten agentti käy läpi päättelysilmukkaansa.

Kiinnitä erityisesti huomiota siihen, miten vanha kehote on täsmälleen uuden kehotteen etuliite. Tämä on tarkoituksellista, sillä se tekee myöhemmistä pyynnöistä paljon tehokkaampia, koska se mahdollistaa kehotevälimuistin hyödyntämisen (josta keskustelemme seuraavassa suorituskykyä käsittelevässä osiossa).

Kun tarkastelemme ensimmäistä agenttilenkin kaaviota, huomaamme, että päättelyn ja työkalun kutsumisen välillä voi olla useita toistokertoja. Kehote voi jatkaa kasvamistaan, kunnes saamme lopulta avustajan viestin, joka osoittaa vuoron päättymisen:

Ilmiteksti

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

Codex CLI:ssä näytämme käyttäjälle avustajan viestin ja kohdistamme kirjoituskentän, jotta käyttäjä huomaa, että on hänen ”vuoronsa” jatkaa keskustelua. Jos käyttäjä vastaa, sekä avustajan edellisen vuoron viesti että käyttäjän uusi viesti on liitettävä syöte-kenttään Responses API -pyynnössä uuden vuoron aloittamiseksi:

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
]

Jälleen kerran, koska jatkamme keskustelua, input -syötteen pituus, jonka lähetämme Responses API:lle, kasvaa jatkuvasti:

Kaavio, jossa on merkintä ”Snapshot 3” ja joka esittää tekoälyagentin silmukan viimeisen vaiheen. Työkalutulosten vastaanottamisen jälkeen malli luo päätelmän ja käyttäjälle palautettavan lopullisen vastauksen. Nuolet kuvaavat siirtymistä työkalun tuloksesta valmiiseen vastaukseen.

Tarkastellaan, mitä tämä alati kasvava kehote merkitsee suorituskyvylle.

Suorituskykyyn liittyvät seikat

Saatat miettiä: ”Eikö agenttisilmukka ole kvadraattinen sen suhteen, kuinka paljon JSONia lähetetään Responses API:lle keskustelun aikana?” Ja olisit oikeassa. Vaikka Responses API tukee valinnaista previous_response_id⁠(avautuu uudessa ikkunassa)-parametria tämän ongelman lieventämiseksi, Codex ei käytä sitä tällä hetkellä, pääasiassa pitääkseen pyynnöt täysin tilattomina ja tukeakseen tietojen määräaikaista säilyttämistä (ZDR) -määrityksiä.

previous_response_id-kentän välttäminen yksinkertaistaa asioita Responses API:n tarjoajalle, koska se varmistaa, että jokainen pyyntö on tilaton. Tämä helpottaa myös Zero Data Retention (ZDR)⁠(avautuu uudessa ikkunassa) -palvelun valinneiden asiakkaiden tukemista, sillä previous_response_id:n tukemiseen tarvittavien tietojen tallentaminen olisi ristiriidassa ZDR:n kanssa. Huomaa, että ZDR-asiakkaat eivät menetä mahdollisuutta hyötyä aiempien kierrosten yksinoikeudellisista päättelyviesteistä, koska niihin liittyvä encrypted_content voidaan purkaa palvelimella. (OpenAI säilyttää ZDR-asiakkaan salauksen purkuavaimen, mutta ei hänen tietojaan.) Katso PR:t #642⁠(avautuu uudessa ikkunassa) ja #1641⁠(avautuu uudessa ikkunassa) Codexiin liittyviä muutoksia ZDR:n tukemiseksi.

Yleisesti ottaen mallin näytteenoton kustannukset ylittävät verkkoliikenteen kustannukset, mikä tekee näytteenotosta tehokkuustyömme ensisijaisen kohteen. Tämän vuoksi kehotevälimuisti on erittäin tärkeä, koska sen avulla voimme käyttää uudelleen aiemman päättelykutsun laskentaa. Kun saamme välimuistiosumia, mallin näytteenotto on lineaarista eikä kvadraattista. Kehotteiden välimuistidokumentaatiossamme ⁠(avautuu uudessa ikkunassa)selitetään tämä tarkemmin:

Välimuistiosumat ovat mahdollisia vain, jos kehote sisältää täsmällisen etuliitevastaavuuden. Jotta välimuistista saadaan hyötyä, sijoita staattinen sisältö, kuten ohjeet ja esimerkit, kehotteen alkuun ja laita muuttuva sisältö, kuten käyttäjäkohtaiset tiedot, loppuun. Tämä koskee myös kuvia ja työkaluja, joiden on oltava identtisiä pyyntöjen välillä.

Tämä mielessä pitäen tarkastellaan, millaiset toiminnot voisivat aiheuttaa Codexissa ”välimuistin ohituksen”:

  • Mallin käytettävissä olevien työkalujen muuttaminen kesken keskustelun.
  • Vaihdetaan Responses API -pyynnön kohteena oleva malli (käytännössä tämä muuttaa alkuperäisen kehotteen kolmatta kohtaa, koska se sisältää mallikohtaisia ohjeita).
  • Hiekkalaatikkokokoonpanon, hyväksyntätilan tai nykyisen työskentelyhakemiston muuttaminen.

Codex-tiimin on oltava tarkka, kun Codex CLI:hin lisätään uusia ominaisuuksia, jotka saattavat vaarantaa kehotteen välimuistitallennuksen. Esimerkiksi MCP-työkalujen alkuperäinen tukemme aiheutti virheen, jossa emme onnistuneet luettelemaan työkaluja johdonmukaisessa järjestyksessä⁠(avautuu uudessa ikkunassa), mikä aiheutti välimuistin ohituksia. Huomaa, että MCP-työkalut voivat olla erityisen hankalia, koska MCP-palvelimet voivat muuttaa tarjoamiensa työkalujen luetteloa lennossa notifications/tools/list_changed⁠(avautuu uudessa ikkunassa)-ilmoituksen avulla. Tämän ilmoituksen noudattaminen pitkän keskustelun keskellä voi aiheuttaa kalliin välimuistin ohituksen.

Kun mahdollista, käsittelemme kesken keskustelun tapahtuvat määritysmuutokset lisäämällä uuden viestin syötteeseen muutoksen heijastamiseksi sen sijaan, että muokkaisimme aiempaa viestiä:

Näemme paljon vaivaa varmistaaksemme välimuistiosumat suorituskyvyn parantamiseksi. Toinenkin keskeinen resurssi on hallittavana: konteksti-ikkuna.

Yleinen strategiamme konteksti-ikkunan loppumisen välttämiseksi on tiivistää keskustelu, kun tokenien määrä ylittää tietyn rajan. Tarkemmin sanottuna korvaamme syötteen uudella, pienemmällä luettelolla kohteita, joka edustaa keskustelua ja mahdollistaa agentin jatkamisen ymmärtäen, mitä tähän mennessä on tapahtunut. Varhainen tiivistämisen toteutus⁠(avautuu uudessa ikkunassa) vaati käyttäjää manuaalisesti suorittamaan /compact-komennon, joka tekisi kyselyn Responses API:lle käyttäen olemassa olevaa keskustelua ja mukautettuja ohjeita yhteenvedon tekemiseen⁠(avautuu uudessa ikkunassa). Codex käytti tuloksena saatua avustajan viestiä, joka sisälsi yhteenvedon uutena syötteenä⁠(avautuu uudessa ikkunassa) seuraaviin keskusteluvuoroihin.

Sen jälkeen Responses API on kehittynyt tukemaan erityistä /responses/compact endpoint⁠(avautuu uudessa ikkunassa), joka suorittaa kompaktioinnin tehokkaammin. Se palauttaa luettelon kohteista⁠(avautuu uudessa ikkunassa), joita voi käyttää edellisen syötteen sijasta keskustelun jatkamiseksi samalla, kun konteksti-ikkunaa vapautetaan. Tämä luettelo sisältää erityisen tyyppi=tiivistys-kohteen, jossa on läpinäkymätön encrypted_content-kohde, joka säilyttää mallin piilevän ymmärryksen alkuperäisestä keskustelusta. Nyt Codex käyttää automaattisesti tätä päätepistettä keskustelun tiivistämiseen, kun auto_compact_limit⁠(avautuu uudessa ikkunassa) ylittyy.

Tulossa seuraavaksi

Olemme esitelleet Codex-agenttisilmukan ja selittäneet, miten Codex luo ja hallitsee kontekstiaan mallia kysyttäessä. Korostimme myös käytännön näkökohtia ja parhaita käytäntöjä, jotka koskevat kaikkia, jotka rakentavat agenttisilmukkaa Responses API:n päälle.

Vaikka agenttisilmukka luo perustan Codexille, se on vasta alkua. Tulevissa julkaisuissa perehdymme CLI:n arkkitehtuuriin, tutkimme, miten työkalujen käyttö on toteutettu, ja tarkastelemme Codexin hiekkalaatikkomallia tarkemmin.

Tekijä

Michael Bolin

Kiitokset

Erityiskiitos koko tiimille, joka rakensi Codex CLI:n.

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