Jäta vahele ja mine põhisisu juurde
OpenAI

23. jaanuar 2026

Inseneriteadus

Codexi agendi tsükli lahtiharutamine

Michael Bolin, tehnilise personali liige

Laadimine…

Codex CLI⁠(avaneb uues aknas) on meie platvormideülene kohalik tarkvaraagent, mis on loodud kvaliteetsete ja usaldusväärsete tarkvaramuudatuste tegemiseks, töötades samal ajal turvaliselt ja tõhusalt sinu masinas. Oleme õppinud tohutult palju selle kohta, kuidas luua maailmatasemel tarkvara agent alates sellest, kui me aprillis CLI esmakordselt käivitasime⁠. Nende tähelepanekute lahtipakkimiseks on see esimene postitus käimasolevas sarjas, kus uurime, kuidas Codex töötab, ning jagame raskelt kätte võidetud õppetunde. (Et saada veelgi detailsema ülevaate sellest, kuidas Codex CLI on ehitatud, vaata meie avatud lähtekoodiga varamut aadressil https://github.com/openai/codex⁠(avaneb uues aknas). Paljud meie disainiotsuste peenemad üksikasjad on talletatud GitHubi issue’ites ja pull request’ides, kui soovid rohkem teada saada.

Alustuseks keskendume agendi tsüklile, mis on Codex CLI-s põhiloogika, vastutades kasutaja, mudeli ja mudeli poolt kutsutud tööriistade vahelise suhtluse orkestreerimise eest, et teha sisukat tarkvaratööd. Loodame, et see postitus annab sulle hea ülevaate rollist, mida meie agent (või „rakendus“) mängib LLM-i kasutamisel.

Enne kui süvitsi läheme, lühike märkus terminoloogia kohta: OpenAI-s hõlmab „Codexi” tarkvaraagentide komplekti, sealhulgas Codex CLI-d, Codex Cloudi ja Codex VS Code'i laiendust. See postitus keskendub Codex harness'ile, mis pakub põhilist agent-tsüklit ja täitmisloogikat, mis on kõigi Codexi kogemuste aluseks ning on kättesaadav Codex CLI kaudu. Lihtsuse huvides kasutame siin termineid “Codex” ja “Codex CLI” vaheldumisi.

Agendi ahel.

Iga AI-agendi südames on midagi, mida kutsutakse „agendi tsükliks.” Agendi tsükli lihtsustatud illustratsioon näeb välja selline:

Diagramm pealkirjaga „Agendi tsükkel”, mis illustreerib, kuidas tehisintellekti süsteem töötleb kasutaja päringut, kutsub tööriistu, jälgib tulemusi, uuendab oma plaani ja tagastab väljundid. Nooled ühendavad etappe, nagu kasutaja sisend, mudeli arutlus, tööriistatoimingud ja lõplik vastus.

Alustuseks võtab agent kasutajalt sisendi, et lisada see tekstiliste juhiste kogumisse, mille ta mudeli jaoks ette valmistab ja mida nimetatakse viibaks.

Järgmine samm on mudelile päringu esitamine, saates talle meie juhised ja paludes tal vastus genereerida – protsess, mida nimetatakse järelduseks. Järeldamise ajal muudetakse tekstiline viip esmalt sisendi tokeniteks⁠(avaneb uues aknas) – täisarvudeks, mis viitavad mudeli sõnavarale. Neid tokeneid kasutatakse seejärel mudeli proovivõtmiseks, mille tulemusel saadakse uus väljundtokenite jada.

Väljundtokenid tõlgitakse tagasi tekstiks, millest saab mudeli vastus. Kuna tokeneid luuakse järk-järgult, saab tõlkimine toimuda mudeli töötamise ajal, mistõttu paljud LLM-põhised rakendused kuvavad voogedastatavat väljundit. Praktikas on järeldamine tavaliselt kapseldatud API taha, mis töötab tekstiga ja peidab tokeniseerimise üksikasjad.

Järeldusetapi tulemusena kas (1) loob mudel lõpliku vastuse kasutaja algsele sisendile või (2) taotleb tööriistakutset, mille agent peaks täitma (nt “käivita ls ja teata väljundist”). Juhul (2) kutsub agent tööriista ja lisab selle väljundi algsele viipale. Seda väljundit kasutatakse uue sisendi loomiseks, mida kasutatakse mudeli uuesti pärimiseks; agent saab seejärel seda uut teavet arvesse võtta ja uuesti proovida.

See protsess kordub seni, kuni mudel lõpetab tööriistakutsete väljastamise ja koostab kasutajale sõnumi (OpenAI mudelites nimetatakse seda assistendi sõnumiks). Paljudel juhtudel vastab see sõnum otse kasutaja algsele päringule, kuid see võib olla ka kasutajale esitatud järelküsimus.

Kuna agent saab teha tööriistakutseid, mis muudavad kohalikku keskkonda, ei piirdu tema “väljund” ainult assistendi sõnumiga. Paljudel juhtudel on tarkvara agenti peamine väljund kood, mida see sinu masinas kirjutab või muudab. Sellegipoolest lõpeb iga voor alati assistendi sõnumiga—näiteks „Lisasin architecture.md, mida sa palusid”—mis annab märku lõpetamise olekust agendi tsüklis. Agendi vaatenurgast on töö lõpetatud ja kontroll naaseb kasutajale.

Diagrammil kujutatud teekonda kasutaja sisendist agendi vastuseni nimetatakse vestluse üheks käiguks (Codexis lõimeks ). Selle jooksul võib vestluskäik sisaldada palju iteratsioone mudeli järeldamise ja tööriistakõnede vahel. Iga kord, kui saadad olemasolevasse vestlusesse uue sõnumi, lisatakse vestluse ajalugu uue käigu viiba osana, mis sisaldab eelmiste käikude sõnumeid ja tööriistakutseid:

Diagramm pealkirjaga „Mitmeastmeline agendi tsükkel“, mis näitab, kuidas AI-agent võtab iteratiivselt kasutaja sisendi, genereerib toiminguid, konsulteerib tööriistadega, värskendab olekut ja tagastab tulemused. Sisaldab sildistatud samme, nooli ja näidistööriistade väljundeid, mis illustreerivad agendi arutlutsüklit.

See tähendab, et vestluse arenedes pikeneb ka mudeli proovivõtmiseks kasutatava viiba pikkus. See pikkus on oluline, sest igal mudelil on kontekstaken, mis on maksimaalne arv tokeneid, mida see saab kasutada ühe järelduskõne jaoks. Pane tähele, et see aken sisaldab nii sisend- kui ka väljundtokenid. Nagu sa võid ette kujutada, võib agent otsustada teha ühe vooru jooksul sadu tööriistakutseid, mis võib konteksti akna potentsiaalselt ammendada. Sel põhjusel on konteksti akna haldamine üks agendi paljudest kohustustest. Nüüd vaatame lähemalt, kuidas Codex käitab agendi tsüklit.

Mudeli järeldus

Codex CLI saadab HTTP-päringuid Responses API⁠(avaneb uues aknas) -le, et käivitada mudeli järelduse. Uurime, kuidas teave Codexi kaudu liigub, mis kasutab agenttsükli käitamiseks Responses API-t.

Responses API lõpp-punkt, mida Codex CLI kasutab, on konfigureeritav⁠(avaneb uues aknas), seega saab seda kasutada mis tahes lõpp-punktiga, mis rakendab Responses API-d⁠(avaneb uues aknas):

Uurime, kuidas Codex loob viipi vestluse esimese järelduskutse jaoks.

Algse viiba koostamine

Lõppkasutajana ei määra sa Responses API-le päringu tegemisel viipa, mida kasutatakse mudeli täpseks valimiseks. Selle asemel määrad oma päringu osana erinevad sisenditüübid ning Responses API server otsustab, kuidas see teave struktureerida viibaks, mida mudel on loodud tarbima. Võid mõelda viip kui „üksuste loendist”; see jaotis selgitab, kuidas sinu päring muudetakse selleks loendiks.

Esialgses viipas on iga loendi element seotud rolliga. role näitab, kui palju kaalu peaks seotud sisu omama, ja on üks järgmistest väärtustest (kahanevas prioriteedijärjekorras): system, developer, user, assistant.

Responses API⁠(avaneb uues aknas) võtab vastu JSON-päringu, millel on palju parameetreid. Keskendume nendele kolmele:

Codexis loetakse instructions väli failist model_instructions_file⁠(avaneb uues aknas) asukohas ~/.codex/config.toml, kui see on määratud; vastasel juhul kasutatakse mudeliga seotud base_instructions ⁠(avaneb uues aknas). Mudelipõhised juhised asuvad Codexi repos ja on komplekteeritud CLI-sse (nt gpt-5.2-codex_prompt.md⁠(avaneb uues aknas)).

Väli tools on tööriistade definitsioonide loend, mis vastavad Responses API-s määratletud skeemile. Codexi puhul hõlmab see tööriistu, mida pakub Codex CLI, tööriistu, mida pakub Responses API, mis tuleks Codexile kättesaadavaks teha, samuti kasutaja pakutavaid tööriistu, tavaliselt MCP serverite kaudu:

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
]

Lõpuks on JSON-päringu input väli üksuste loend. Codex lisab järgmised üksused⁠(avaneb uues aknas) input -i enne kasutaja sõnumi lisamist:

1. Sõnum koos role=developer, mis kirjeldab liivakasti, mis kehtib ainult Codexi pakutud shell tööriistale, mis on määratletud jaotises tools. See tähendab, et teised tööriistad, näiteks MCP-serverite pakutavad, ei ole Codexi poolt liivakastis ja vastutavad ise oma kaitsepiirangute jõustamise eest.

Sõnum koostatakse mallist, kus sisu põhiosad pärinevad Markdowni katkenditest, mis on komplekteeritud Codex CLI-sse, näiteks workspace_write.md⁠(avaneb uues aknas) ja on_request.md⁠(avaneb uues aknas):

Lihtne tekst

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. (Valikuline) Sõnum, mille role=developer ja mille sisu on developer_instructions väärtus, mis on loetud kasutaja config.toml failist.

3. (Valikuline) Sõnum, millel on role=user ja mille sisu on „kasutaja juhised”, mis ei pärine ühest failist, vaid on koondatud mitmest allikast⁠(avaneb uues aknas). Üldiselt ilmuvad täpsemad juhised hiljem:

  • Failide AGENTS.override.md ja AGENTS.md sisu failis $CODEX_HOME
  • Vaikimisi 32 KiB piirangu kohaselt vaata igas kaustas alates Git/projekti juurkaustast cwd (kui see on olemas) kuni cwd endani: lisa mis tahes AGENTS.override.md failide sisu, AGENTS.md või mis tahes failinimi, mis on määratud project_doc_fallback_filenames in config.toml
  • Kui mõni oskus⁠(avaneb uues aknas) on konfigureeritud:

4. Sõnum koos role=user, mis kirjeldab kohalikku keskkonda, kus agent praegu tegutseb. See määrab praeguse töökataloogi ja kasutaja shelli⁠(avaneb uues aknas):

Lihtne tekst

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

Kui Codex on teinud kõik ülaltoodud arvutused input initsialiseerimiseks, lisab ta kasutaja sõnumi vestluse alustamiseks.

Eelmised näited keskendusid iga sõnumi sisule, kuid pane tähele, et iga input element on JSON-objekt, millel on type, role⁠(avaneb uues aknas) ja content järgmiselt:

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
}

Kui Codex on koostanud Responses API-le saatmiseks täieliku JSON-päringu, teeb see seejärel HTTP POST-päringu koos Authorization päisega, sõltuvalt sellest, kuidas Responses API lõpp-punkt on konfigureeritud failis ~/.codex/config.toml (täiendavad HTTP päised ja päringuparameetrid lisatakse, kui need on määratud).

Kui OpenAI Responses API server saab päringu, kasutab see JSON-i, et tuletada mudeli jaoks viip järgmiselt (kindluse mõttes võib Responses API kohandatud teostus teha teistsuguse valiku):

Hetktõmmise diagramm, mis näitab ühte sammu tehisintellekti agendi tsüklis. Kasutaja päring jõuab mudelisse, mis loob mõtte, toimingu koos tööriista nime ja tööriista sisendiga. Diagramm toob esile selle vahepealse arutluse etapi enne tööriista kasutamist.

Nagu näete, määrab viip esimese kolme üksuse järjekorra server, mitte klient. Seda öeldes on neist kolmest üksusest serveri poolt juhitav ainult süsteemisõnumi sisu, kuna tööriistad ja juhised määrab klient. Neile järgneb JSON-päringu input, et viip lõpule viia.

Nüüd, kui meil on viip olemas, oleme valmis mudelit proovima.

Esimene pööre

See HTTP-päring Responses API-le algatab Codexi vestluse esimese „vooru“. Server vastab Server-Sent Events (SSE⁠(avaneb uues aknas)) vooga. Iga sündmuse data on JSON-i payload, mille "type" algab väärtusega "response" ning võib välja näha näiteks nii (sündmuste täieliku loendi leiad meie API dokumentatsioonist⁠(avaneb uues aknas)):

Lihtne tekst

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 tarbib sündmuste voogu⁠(avaneb uues aknas) ja avaldab need uuesti sisemiste sündmuseobjektidena, mida klient saab kasutada. Sündmusi nagu response.output_text.delta kasutatakse kasutajaliideses voogedastuse toetamiseks, samas kui teised sündmused nagu response.output_item.added teisendatakse objektideks, mis lisatakse input järgnevate Responses API kutsete jaoks.

Oletame, et Responses API esimene päring sisaldab kahte response.output_item.done sündmust: ühte type=reasoning ja ühte type=function_call. Need sündmused peavad olema esindatud JSON-i input väljal, kui me pärime mudelit uuesti tööriistakutse vastusega: 

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
]

Järgneva päringu osana mudeli proovimiseks kasutatav viip näeks välja selline:

Diagramm sildiga „Snapshot 2”, mis näitab tehisintellekti agenti pärast tööriistakutset. Mudel võtab vastu tööriista vaatluse ja genereerib uue mõtte ja tegevuse. Nooled ühendavad sisendeid, tähelepanekuid ja väljundeid, et näidata, kuidas agent kordab oma arutlusprotsessi.

Eelkõige pane tähele, kuidas vana viip on uue viiba täpne prefiks. See on tahtlik, kuna see muudab järgnevad päringud palju tõhusamaks, sest see võimaldab meil kasutada viipide vahemälu (mida käsitleme järgmises jaotises jõudluse teemal).

Vaadates tagasi meie esimesele agendi tsükli diagrammile, näeme, et järeldamise ja tööriistade kasutamise vahel võib olla palju iteratsioone. Viip võib jätkuvalt kasvada, kuni lõpuks saame assistendi teate, mis näitab käigu lõppu:

Lihtne tekst

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

Codex CLI-s kuvame kasutajale assistendi sõnumi ja viime koostaja fookusesse, et anda kasutajale märku, et nüüd on tema „kord“ vestlust jätkata. Kui kasutaja vastab, tuleb nii assistendi eelmise käigu sõnum kui ka kasutaja uus sõnum lisada Responses API päringu input -i, et alustada uut käiku:

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
]

Taaskord, kuna jätkame vestlust, suureneb Responses API-le saadetava sisendi pikkus pidevalt:

Diagramm pealkirjaga „Snapshot 3”, mis näitab tehisintellekti agendi tsükli lõppjärku. Pärast tööriista tulemuste saamist loob mudel kokkuvõtva mõtte ja lõpliku vastuse, mis antakse kasutajale tagasi. Nooled näitavad üleminekut tööriista väljundist lõpule viidud vastuseni.

Vaatame, mida see pidevalt kasvav viip jõudluse jaoks tähendab.

Tulemuslikkuse aspektid

Võib-olla küsid endalt: „Oota, kas agendi tsükkel ei ole ruutvõrdeline seoses vestluse jooksul Responses API-le saadetud JSON-i hulgaga?” Ja sul oleks õigus. Kuigi Responses API toetab selle probleemi leevendamiseks valikulist previous_response_id⁠(avaneb uues aknas) parameetrit, ei kasuta Codex seda täna, peamiselt selleks, et hoida päringud täielikult olekuta ja toetada andmeid ei säilitata (ZDR) konfiguratsioone.

previous_response_id vältimine lihtsustab Responses API pakkuja jaoks asju, kuna see tagab, et iga päring on olekuta. See muudab ka lihtsaks klientide toetamise, kes on valinud andmeid ei säilitata (ZDR)⁠(avaneb uues aknas), kuna previous_response_id toetamiseks vajalike andmete salvestamine oleks vastuolus andmeid ei säilitata põhimõttega. Pane tähele, et ZDR kliendid ei kaota võimalust saada kasu varasemate pöörete omandiõiguslikest arutlussõnumitest, kuna seotud encrypted_content saab serveris dekrüpteerida. (OpenAI säilitab ZDR-kliendi dekrüpteerimisvõtme, kuid mitte nende andmeid.) Vaata PR-ide #642⁠(avaneb uues aknas) ja #1641⁠(avaneb uues aknas) Codexi seotud muudatuste jaoks, et toetada ZDR-i.

Üldiselt on mudeli proovivõtu kulu võrgu liikluse kulust suurem, mistõttu on proovivõtt meie tõhususpüüdluste peamine sihtmärk. Seetõttu on viiba vahemällu salvestamine nii oluline, kuna see võimaldab meil taaskasutada arvutust eelmisest järelduskutsest. Kui saame vahemälu tabamusi, on mudeli valimine lineaarne, mitte ruutvõrdeline. Meie viipide vahemälu ⁠(avaneb uues aknas)dokumentatsioon selgitab seda üksikasjalikumalt:

Vahemälu tabamused on võimalikud ainult viibi täpsete prefiksi vastete korral. Vahemällu salvestamise eeliste saavutamiseks paiguta staatiline sisu, nagu juhised ja näited, oma viiba algusesse ning pane muutuv sisu, nagu kasutajaspetsiifiline teave, lõppu. See kehtib ka piltide ja tööriistade kohta, mis peavad olema päringute vahel identsed.

Seda silmas pidades vaatame, millised toimingud võiksid Codexis põhjustada „vahemälu möödalaskmise”:

  • Mudeli jaoks saadaolevate tools muutmine vestluse keskel.
  • Muutes Responses API päringu sihtmärgiks olevat model (praktikas muudab see algse viipe kolmandat elementi, kuna see sisaldab mudelipõhiseid juhiseid).
  • Liivakasti konfiguratsiooni, kinnitamisrežiimi või praeguse töökataloogi muutmine.

Codexi meeskond peab olema hoolas, kui Codex CLI-sse lisatakse uusi funktsioone, mis võivad ohustada viipude vahemälu. Näiteks tõi meie esialgne MCP tööriistade tugi kaasa vea, mille tõttu me ei loetlenud tööriistu järjepidevas järjekorras⁠(avaneb uues aknas), mis põhjustas vahemälu möödalaskmisi. Pane tähele, et MCP tööriistad võivad olla eriti keerulised, sest MCP-serverid saavad nende pakutavate tööriistade loendit jooksvalt muuta notifications/tools/list_changed⁠(avaneb uues aknas) teavituse kaudu. Selle teavituse arvestamine pika vestluse keskel võib põhjustada kuluka vahemälu möödalaskmise.

Kui võimalik, käsitleme vestluse keskel toimuvaid konfiguratsioonimuudatusi, lisades input -ile muudatuse kajastamiseks uue sõnumi, selle asemel et muuta varasemat sõnumit:

  • Kui liivakasti konfiguratsioon või kinnitamisrežiim muutub, sisestame⁠(avaneb uues aknas) uue role=developer sõnumi, mille vorming on sama mis algsel <permissions instructions> üksusel.
  • Kui praegune töökataloog muutub, lisame⁠(avaneb uues aknas) uue role=user sõnumi, mille vorming on sama mis algsel <environment_context>.

Me teeme suuri pingutusi, et tagada vahemälu tabamused jõudluse parandamiseks. On veel üks oluline ressurss, mida peame haldama: konteksti aken.

Meie üldine strateegia, et vältida kontekstiakna täitumist, on vestlust kokku suruda, kui tokenite arv ületab teatud lävendi. Täpsemalt asendame input uue, väiksema üksuste loendiga, mis esindab vestlust, võimaldades agentil jätkata arusaamisega sellest, mis on seni juhtunud. Varajane kompaktsuse rakendamine⁠(avaneb uues aknas) nõudis, et kasutaja käivitaks käsitsi käsu /compact, mis teeks päringu Responses API-le, kasutades olemasolevat vestlust koos kohandatud juhistega kokkuvõtmiseks⁠(avaneb uues aknas). Codex kasutas saadud assistendi teadet, mis sisaldas kokkuvõtet, uue sisendina⁠(avaneb uues aknas) järgnevate vestlusvoorude jaoks.

Sellest ajast alates on Responses API arenenud, et toetada spetsiaalset /responses/compact lõpp-punkti⁠(avaneb uues aknas), mis teostab kompaktimist tõhusamalt. See tagastab üksuste loendi⁠(avaneb uues aknas), mida saab kasutada eelmise input asemel vestluse jätkamiseks, vabastades samal ajal kontekstiaknas ruumi. See loend sisaldab spetsiaalset type=compaction üksust koos läbipaistmatu encrypted_content üksusega, mis säilitab mudeli varjatud arusaama algsest vestlusest. Nüüd kasutab Codex automaatselt seda lõpp-punkti vestluse tihendamiseks, kui auto_compact_limit⁠(avaneb uues aknas) on ületatud.

Järgmine

Tutvustasime Codexi agendi tsüklit ja selgitanud, kuidas Codex koostab ja haldab oma konteksti, kui ta esitab päringu mudelile. Teel tõstsime esile praktilised kaalutlused ja parimad tavad, mis kehtivad kõigile, kes loovad agentide tsükli Responses API peale.

Kuigi agendi tsükkel loob Codexi aluse, on see alles algus. Tulevastes postitustes uurime CLI arhitektuuri, vaatame, kuidas tööriistade kasutamine on rakendatud, ja heidame pilgu Codexi liivakastimudelile.

Autor

Michael Bolin

Tänuavaldused

Erilised tänud kogu meeskonnale, kes Codex CLI lõi.

Jätka lugemist

Vaata kõiki
Tax Agent > Art Card
Enesetäiustuvate maksuagentide loomine Codexiga

Inseneriteadus

codex windows > art card
Turvalise ja tõhusa liivakasti loomine Codexi jaoks Windowsis

Inseneriteadus

MRC 1_1
Supercomputer networking to accelerate large scale AI training

Inseneriteadus