Pereiti prie pagrindinio turinio
OpenAI

2026 m. sausio 23 d.

Inžinerija

„Codex“ agento ciklo išskleidimas

Autorius: Michael Bolin, techninio personalo narys

Įkeliama...

Codex CLI⁠(atsidaro naujame lange) yra mūsų daugiaplatformis vietinis programinės įrangos agentas, sukurtas kurti aukštos kokybės, patikimus programinės įrangos pakeitimus, veikiantis saugiai ir efektyviai jūsų kompiuteryje. Sužinojome labai daug apie tai, kaip sukurti pasaulinio lygio programinės įrangos agentą, nuo tada, kai balandžio mėnesį pirmą kartą pristatėme CLI⁠. Norėdami atskleisti šias įžvalgas, pradedame tęstinę įrašų seriją, kurioje nagrinėsime įvairius „Codex“ veikimo aspektus, taip pat sunkiai išmoktas pamokas. (Norėdami dar detaliau susipažinti su tuo, kaip sukurtas „Codex CLI“, peržiūrėkite mūsų atvirojo kodo saugyklą adresu https://github.com/openai/codex⁠(atsidaro naujame lange). Daugelis smulkesnių mūsų dizaino sprendimų detalių yra užfiksuotos „GitHub“ problemų aprašymuose ir išsiuntimo užklausose, jei norėtumėte sužinoti daugiau.)

Pradžiai sutelksime dėmesį į agento ciklą, kuris yra pagrindinė „Codex CLI“ logika, atsakinga už sąveikos tarp naudotojo, modelio ir įrankių, kuriuos modelis iškviečia prasmingam programinės įrangos darbui atlikti, orkestravimą. Tikimės, kad šis įrašas suteiks jums gerą supratimą apie tai, kokį vaidmenį atlieka mūsų agentas (arba „sąsaja“), naudodamas LLM.

Prieš pasineriant giliau, trumpa pastaba dėl terminijos: „OpenAI“ kontekste „Codex“ apima programinės įrangos agentų rinkinį, įskaitant „Codex CLI“, „Codex Cloud“ ir „Codex VS Code“ plėtinį. Šiame įraše dėmesys sutelkiamas į „Codex“ sąsają, kuri suteikia pagrindinį agento ciklą ir vykdymo logiką, kuria grindžiama visa „Codex“ patirtis ir kuri pateikiama per „Codex CLI“. Patogumo dėlei terminus „Codex“ ir „Codex CLI“ vartosime pakaitomis.

Agento ciklas

Kiekvieno DI agento šerdis yra vadinamasis „agento ciklas“. Supaprastinta agento ciklo iliustracija atrodo taip:

Diagrama pavadinimu „Agent loop“, iliustruojanti, kaip DI sistema apdoroja naudotojo užklausą, iškviečia įrankius, stebi rezultatus, atnaujina planą ir grąžina išvestis. Rodyklės jungia tokius žingsnius kaip naudotojo įvestis, modelio protavimas, įrankių veiksmai ir galutinis atsakymas.

Pirmiausia agentas paima naudotojo įvestį, kad įtrauktų ją į tekstinių instrukcijų rinkinį, kurį jis parengia modeliui, vadinamą užklausa.

Kitas žingsnis – pateikti užklausą modeliui, nusiunčiant jam mūsų instrukcijas ir paprašant sugeneruoti atsakymą; šis procesas vadinamas modelio vykdymu. Modelio vykdymo metu tekstinė užklausa pirmiausia išverčiama į įvesties žetonų⁠(atsidaro naujame lange) seką – sveikuosius skaičius, kurie nurodo modelio žodyno indeksus. Šie žetonai tada naudojami imčiai iš modelio gauti, sukuriant naują išvesties žetonų seką.

Išvesties žetonai išverčiami atgal į tekstą, kuris tampa modelio atsakymu. Kadangi žetonai kuriami laipsniškai, šis vertimas gali vykti modeliui veikiant, todėl daugelis LLM pagrįstų programų rodo srautinę išvestį. Praktikoje modelio vykdymas paprastai yra inkapsuliuotas už API, veikiančio su tekstu, abstrahuojant skaidymo į žetonus detales.

Kaip modelio vykdymo žingsnio rezultatas, modelis arba (1) sukuria galutinį atsakymą į pradinę naudotojo įvestį, arba (2) paprašo įrankio kvietimo, kurį agentas turi atlikti (pvz., „paleisti ls ir pranešti apie išvestį“). (2) atveju agentas įvykdo įrankio kvietimą ir prideda jo išvestį prie pradinės užklausos. Ši išvestis naudojama kuriant naują įvestį, kuri naudojama pakartotinai kreipiantis į modelį; tada agentas gali atsižvelgti į šią naują informaciją ir bandyti dar kartą.

Šis procesas kartojasi tol, kol modelis nustoja siųsti įrankių kvietimus ir vietoj to sukuria pranešimą naudotojui (vadinamą asistento pranešimu „OpenAI“ modeliuose). Daugeliu atvejų šis pranešimas tiesiogiai atsako į pradinę naudotojo užklausą, tačiau tai gali būti ir papildomas klausimas naudotojui.

Kadangi agentas gali vykdyti įrankių kvietimus, kurie keičia vietinę aplinką, jo „išvestis“ neapsiriboja asistento pranešimu. Daugeliu atvejų pagrindinė programinės įrangos agento išvestis yra kodas, kurį jis parašo arba redaguoja jūsų kompiuteryje. Vis dėlto kiekvienas etapas visada baigiasi asistento pranešimu – pavyzdžiui, „Pridėjau architecture.md, kurio prašėte“, – kuris signalizuoja agento ciklo pabaigos būseną. Agento požiūriu jo darbas baigtas ir valdymas grąžinamas naudotojui.

Diagramoje pavaizduotas procesas nuo naudotojo įvesties iki agento atsakymo vadinamas vienu pokalbio etapu (sistemoje „Codex“ – gija). Vis dėlto šis pokalbio etapas gali apimti daugybę iteracijų tarp modelio vykdymo ir įrankių kvietimų. Kaskart siunčiant naują žinutę į esamą pokalbį, pokalbio istorija įtraukiama kaip naujo etapo užklausos dalis, kurią sudaro ankstesnių etapų žinutės ir įrankių kvietimai:

Diagrama pavadinimu „Multi-turn agent loop“, rodanti, kaip DI agentas iteratyviai priima naudotojo įvestį, generuoja veiksmus, konsultuojasi su įrankiais, atnaujina būseną ir grąžina rezultatus. Apima pažymėtus žingsnius, rodykles ir pavyzdines įrankių išvestis, iliustruojančias agento protavimo ciklą.

Tai reiškia, kad pokalbiui plečiantis, ilgėja ir užklausa, naudojama imčiai iš modelio gauti. Šis ilgis yra svarbus, nes kiekvienas modelis turi konteksto langą, kuris yra didžiausias žetonų skaičius, kurį jis gali naudoti vienam modelio vykdymo kvietimui. Atkreipkite dėmesį, kad šis langas apima tiek įvesties, tiek išvesties žetonus. Kaip galite įsivaizduoti, agentas gali nuspręsti atlikti šimtus įrankių kvietimų per vieną etapą, potencialiai išnaudodamas konteksto langą. Dėl šios priežasties konteksto lango valdymas yra viena iš daugelio agento atsakomybių. Dabar pasinerkime giliau ir pažiūrėkime, kaip „Codex“ vykdo agento ciklą

Modelio vykdymas

„Codex CLI“ siunčia HTTP užklausas į „Responses“ API⁠(atsidaro naujame lange), kad paleistų modelio vykdymą. Išnagrinėsime, kaip informacija teka per „Codex“, kuri naudoja „Responses“ API agento ciklui valdyti.

„Responses“ API prieigos taškas, kurį naudoja „Codex CLI“, yra konfigūruojamas⁠(atsidaro naujame lange), todėl jį galima naudoti su bet kuriuo prieigos tašku, kuris įgyvendina „Responses“ API⁠(atsidaro naujame lange):

Panagrinėkime, kaip „Codex“ sukuria užklausą pirmajam modelio vykdymo kvietimui pokalbyje.

Pradinės užklausos kūrimas

Kaip galutinis naudotojas, jūs nenurodote užklausos, naudojamos imčiai iš modelio gauti, pažodžiui, kai kreipiatės į „Responses“ API. Vietoj to, kaip savo užklausos dalį nurodote įvairius įvesties tipus, o „Responses“ API serveris nusprendžia, kaip susisteminti šią informaciją į užklausą, kurią modelis sukurtas priimti. Galite įsivaizduoti užklausą kaip „elementų sąrašą“; šiame skyriuje paaiškinsime, kaip jūsų užklausa paverčiama tuo sąrašu.

Pradinėje užklausoje kiekvienas sąrašo elementas yra susietas su vaidmeniu. role nurodo, kokį svorį turėtų turėti susijęs turinys, ir yra viena iš šių reikšmių (mažėjančia prioriteto tvarka): system, developer, user, assistant.

„Responses“ API⁠(atsidaro naujame lange) priima JSON duomenų rinkinį su daugybe parametrų. Mes sutelksime dėmesį į šiuos tris:

„Codex“ kalboje instructions laukas nuskaitomas iš model_instructions_file⁠(atsidaro naujame lange) , esančio faile ~/.codex/config.toml, jei nurodyta; kitu atveju naudojamos su modeliu susietos base_instructions“⁠(atsidaro naujame lange) . Modeliui skirtos instrukcijos yra „Codex“ saugykloje ir yra įtrauktos į CLI (pvz., gpt-5.2-codex_prompt.md⁠(atsidaro naujame lange)).

Laukas tools yra įrankių apibrėžimų, atitinkančių „Responses“ API apibrėžtą schemą, sąrašas. „Codex“ atveju tai apima įrankius, kuriuos teikia „Codex CLI“, įrankius, kuriuos teikia „Responses“ API ir kurie turėtų būti prieinami „Codex“, taip pat įrankius, kuriuos pateikia naudotojas, paprastai per MCP serverius:

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
]

Galiausiai, JSON duomenų rinkinio laukas input yra elementų sąrašas. „Codex“ įterpia šiuos elementus⁠(atsidaro naujame lange) į input prieš pridėdamas naudotojo pranešimą:

1. Pranešimas su role=developer, apibūdinantis smėliadėžę, kuri taikoma tik „Codex“ teikiamam shell įrankiui, apibrėžtam tools skyriuje. Tai reiškia, kad kiti įrankiai, pvz., teikiami MCP serverių, nėra apriboti „Codex“ smėliadėžės ir patys yra atsakingi už savo saugos priemonių taikymą.

Pranešimas sukuriamas pagal šabloną, kurio pagrindinės turinio dalys gaunamos iš „Codex CLI“ įtrauktų „Markdown“ fragmentų, tokių kaip workspace_write.md⁠(atsidaro naujame lange) ir on_request.md⁠(atsidaro naujame lange):

Paprastas tekstas

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>

(Neprivaloma) Pranešimas su role=developer, kurio turinys yra developer_instructions reikšmė, nuskaityta iš naudotojo config.toml failo.

(Neprivaloma) Pranešimas su role=user, kurio turinys yra „naudotojo instrukcijos“, gaunamos ne iš vieno failo, bet surinktos iš kelių šaltinių⁠(atsidaro naujame lange). Paprastai konkretesnės instrukcijos pateikiamos vėliau.

Pranešimas su role=user, apibūdinantis vietinę aplinką, kurioje šiuo metu veikia agentas. Čia nurodomas esamas darbinis katalogas ir naudotojo apvalkalas⁠(atsidaro naujame lange).

Paprastas tekstas

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

Kai „Codex“ atlieka visus pirmiau minėtus skaičiavimus, kad inicijuotų input, jis prideda naudotojo pranešimą pokalbiui pradėti.

Ankstesniuose pavyzdžiuose dėmesys buvo sutelktas į kiekvieno pranešimo turinį, tačiau atkreipkite dėmesį, kad kiekvienas input elementas yra JSON objektas su type, role⁠(atsidaro naujame lange) ir content, kaip nurodyta toliau.

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
}

Kai „Codex“ sukuria visą JSON duomenų rinkinį, skirtą siųsti į „Responses“ API, jis atlieka HTTP POST užklausą su Authorization antrašte, priklausomai nuo to, kaip „Responses“ API prieigos taškas sukonfigūruotas ~/.codex/config.toml (papildomos HTTP antraštės ir užklausos parametrai pridedami, jei nurodyta).

Kai „OpenAI“ „Responses“ API serveris gauna užklausą, jis naudoja JSON, kad išvestų modelio užklausą toliau nurodyta tvarka (žinoma, pasirinktinis „Responses“ API įgyvendinimas galėtų pasirinkti kitaip).

Momentinės nuotraukos diagrama, rodanti vieną DI agento ciklo žingsnį. Naudotojo užklausa patenka į modelį, kuris sukuria mintį, veiksmą su įrankio pavadinimu ir įrankio įvestį. Diagrama pabrėžia šį tarpinį protavimo žingsnį prieš iškviečiant įrankį.

Kaip matote, pirmųjų trijų užklausos elementų tvarką nustato serveris, o ne klientas. Vis dėlto iš tų trijų elementų serveris valdo tik sistemos pranešimo turinį, nes tools ir instructions nustato klientas. Po jų eina input iš JSON duomenų rinkinio, užbaigiantis užklausą.

Dabar, kai turime užklausą, esame pasirengę gauti imtį iš modelio.

Pirmasis etapas

Ši HTTP užklausa į „Responses“ API inicijuoja pirmąjį pokalbio „etapą“ „Codex“ sistemoje. Serveris atsako serverio siunčiamų įvykių (SSE⁠(atsidaro naujame lange)) srautu. Kiekvieno įvykio data yra JSON duomenų rinkinys su "type", prasidedančiu "response", kuris gali atrodyti maždaug taip, kaip nurodyta toliau (visą įvykių sąrašą rasite mūsų API dokumentuose⁠(atsidaro naujame lange)).

Paprastas tekstas

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“ sunaudoja įvykių srautą⁠(atsidaro naujame lange) ir persiunčia juos kaip vidinius įvykių objektus, kuriuos gali naudoti klientas. Tokie įvykiai kaip response.output_text.delta naudojami srautiniam perdavimui vartotojo sąsajoje palaikyti, o kiti įvykiai, pvz., response.output_item.added, paverčiami objektais, kurie pridedami prie input vėlesniems „Responses“ API kvietimams.

Tarkime, pirmoji užklausa „Responses“ API apima du response.output_item.done įvykius: vieną su type=reasoning ir vieną su type=function_call. Šie įvykiai turi būti atvaizduoti JSON lauke input, kai vėl kreipiamės į modelį su atsakymu į įrankio kvietimą: 

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
]

Gauta užklausa, naudojama imčiai iš modelio gauti kaip vėlesnės užklausos dalis, atrodytų taip:

Diagrama, pažymėta „Snapshot 2“, rodanti DI agentą po įrankio kvietimo. Modelis gauna įrankio stebėjimą ir sukuria naują mintį bei veiksmą. Rodyklės jungia įvestis, stebėjimus ir išvestis, iliustruodamos, kaip agentas kartoja savo protavimo ciklą.

Ypač atkreipkite dėmesį, kad senoji užklausa yra tikslus naujos užklausos priešdėlis. Tai daroma sąmoningai, nes taip vėlesnės užklausos tampa daug efektyvesnės, kadangi galime pasinaudoti užklausų kaupimu talpykloje (apie tai kalbėsime kitame skyriuje apie našumą).

Žvelgdami į mūsų pirmąją agento ciklo diagramą, matome, kad tarp modelio vykdymo ir įrankio kvietimo gali būti daug iteracijų. Užklausa gali augti tol, kol galiausiai gausime asistento pranešimą, reiškiantį etapo pabaigą:

Paprastas tekstas

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

„Codex CLI“ pateikiame asistento pranešimą naudotojui ir sufokusuojame rengyklę, nurodydami naudotojui, kad atėjo jo „eilė“ tęsti pokalbį. Jei naudotojas atsako, tiek asistento pranešimas iš ankstesnio etapo, tiek naujas naudotojo pranešimas turi būti pridėti prie input „Responses“ API užklausoje, kad prasidėtų naujas etapas:

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
]

Vėlgi, kadangi tęsiame pokalbį, į „Responses“ API siunčiamos input ilgis nuolat didėja.

Diagrama, pažymėta „Snapshot 3“, rodanti galutinį DI agento ciklo etapą. Gavęs įrankių rezultatus, modelis sukuria baigiamąją mintį ir galutinį atsakymą, grąžinamą naudotojui. Rodyklės iliustruoja perėjimą nuo įrankio išvesties prie užbaigto atsakymo.

Panagrinėkime, ką ši nuolat auganti užklausa reiškia našumui.

Našumo aspektai

Galbūt klausiate savęs: „Palaukite, ar agento ciklas nėra kvadratinis pagal JSON kiekį, siunčiamą į „Responses“ API pokalbio metu?“ Ir jūs būtumėte teisūs. Nors „Responses“ API palaiko neprivalomą parametrą previous_response_id⁠(atsidaro naujame lange) šiai problemai sušvelninti, šiandien „Codex“ jo nenaudoja, visų pirma tam, kad užklausos būtų visiškai be būsenos ir palaikytų nulinio duomenų saugojimo (ZDR) konfigūracijas.

Vengiant previous_response_id, viskas tampa paprasčiau „Responses“ API teikėjui, nes užtikrinama, kad kiekviena užklausa būtų be būsenos. Tai taip pat palengvina palaikymą klientams, pasirinkusiems nulinį duomenų saugojimą (ZDR)⁠(atsidaro naujame lange), nes duomenų, reikalingų previous_response_id palaikyti, saugojimas prieštarautų ZDR. Atkreipkite dėmesį, kad ZDR klientai neaukoja galimybės pasinaudoti patentuotomis protavimo žinutėmis iš ankstesnių etapų, nes susijęs encrypted_content gali būti iššifruotas serveryje. („OpenAI“ saugo ZDR kliento iššifravimo raktą, bet ne jo duomenis.) Susijusius „Codex“ pakeitimus, skirtus ZDR palaikyti, žr. PR #642⁠(atsidaro naujame lange) ir #1641⁠(atsidaro naujame lange).

Paprastai modelio imties kaina viršija tinklo srauto kainą, todėl imtis tampa pagrindiniu mūsų efektyvumo didinimo tikslu. Štai kodėl užklausų kaupimas talpykloje yra toks svarbus, nes tai leidžia pakartotinai panaudoti skaičiavimus iš ankstesnio modelio vykdymo kvietimo. Kai gauname atitiktis talpykloje, modelio imtis yra linijinė, o ne kvadratinė. Mūsų dokumentacijoje apie užklausų kaupimą talpykloje⁠(atsidaro naujame lange) tai paaiškinta išsamiau.

Atitiktys talpykloje galimos tik esant tiksliems priešdėlių sutapimams užklausoje. Norėdami pasinaudoti kaupimo talpykloje privalumais, statinį turinį, pvz., instrukcijas ir pavyzdžius, dėkite užklausos pradžioje, o kintamą turinį, pvz., specifinę naudotojo informaciją, – pabaigoje. Tai taip pat taikoma vaizdams ir įrankiams, kurie tarp užklausų turi būti identiški.

Atsižvelgdami į tai, apsvarstykite, kokios operacijos gali sukelti „talpyklos neatitikimą“ „Codex“ sistemoje.

  • Modeliui prieinamų tools keitimas pokalbio viduryje.
  • model, kuris yra „Responses“ API užklausos tikslas, keitimas (praktiškai tai pakeičia trečiąjį elementą pradinėje užklausoje, nes jame yra konkretaus modelio instrukcijos).
  • Smėliadėžės konfigūracijos, patvirtinimo režimo arba esamo darbinio katalogo keitimas.

„Codex“ komanda turi būti atidi, diegdama naujas funkcijas „Codex CLI“, kurios galėtų pakenkti užklausų kaupimui talpykloje. Pavyzdžiui, pradinis mūsų MCP įrankių palaikymas turėjo klaidą: mes nesugebėjome išvardyti įrankių nuoseklia tvarka⁠(atsidaro naujame lange), o tai sukėlė talpyklos neatitikimus. Atkreipkite dėmesį, kad MCP įrankiai gali būti ypač sudėtingi, nes MCP serveriai gali keisti teikiamų įrankių sąrašą eigoje per notifications/tools/list_changed⁠(atsidaro naujame lange) pranešimą. Šio pranešimo paisymas ilgo pokalbio viduryje gali sukelti brangų talpyklos neatitikimą.

Kai įmanoma, konfigūracijos pakeitimus, įvykstančius pokalbio viduryje, tvarkome prie input pridėdami naują pranešimą, atspindintį pakeitimą, o ne modifikuodami ankstesnį pranešimą.

  • Jei pasikeičia smėliadėžės konfigūracija arba patvirtinimo režimas, įterpiame⁠(atsidaro naujame lange) naują role=developer pranešimą, kurio formatas toks pat kaip pradinio <permissions instructions> elemento.
  • Jei pasikeičia esamas darbinis katalogas, įterpiame⁠(atsidaro naujame lange) naują role=user pranešimą, kurio formatas toks pat kaip pradinio <environment_context>.

Dedame daug pastangų, kad užtikrintume atitiktis talpykloje dėl našumo. Yra dar vienas svarbus išteklius, kurį turime valdyti: konteksto langas.

Mūsų bendroji strategija, siekiant išvengti konteksto lango išnaudojimo, yra sutraukti pokalbį, kai žetonų skaičius viršija tam tikrą ribą. Konkrečiai, input pakeičiame nauju, mažesniu elementų sąrašu, kuris reprezentuoja pokalbį, leisdami agentui tęsti darbą suprantant, kas įvyko iki šiol. Ankstyvas sutraukimo įgyvendinimas⁠(atsidaro naujame lange) reikalavo, kad naudotojas rankiniu būdu iškviestų komandą /compact, kuri kreiptųsi į „Responses“ API naudodama esamą pokalbį ir pasirinktines instrukcijas santraukai⁠(atsidaro naujame lange). „Codex“ naudojo gautą asistento pranešimą su santrauka kaip naują input⁠(atsidaro naujame lange) vėlesniems pokalbio etapams.

Nuo to laiko „Responses“ API patobulėjo ir palaiko specialų /responses/compact prieigos tašką⁠(atsidaro naujame lange) , kuris sutraukimą atlieka efektyviau. Jis grąžina elementų sąrašą⁠(atsidaro naujame lange), kurį galima naudoti vietoj ankstesnio input pokalbiui tęsti, atlaisvinant konteksto langą. Šiame sąraše yra specialus type=compaction elementas su nepermatomu encrypted_content elementu, kuris išsaugo latentinį modelio supratimą apie pradinį pokalbį. Dabar „Codex“ automatiškai naudoja šį prieigos tašką pokalbiui sutraukti, kai viršijamas auto_compact_limit⁠(atsidaro naujame lange).

Kas toliau

Pristatėme „Codex“ agento ciklą ir aptarėme, kaip „Codex“ kuria ir valdo savo kontekstą kreipiantis į modelį. Pakeliui pabrėžėme praktinius aspektus ir geriausią praktiką, taikomą visiems, kuriantiems agento ciklą ant „Responses“ API.

Nors agento ciklas sudaro „Codex“ pagrindą, tai tik pradžia. Būsimuose įrašuose gilinsimės į CLI architektūrą, nagrinėsime, kaip įgyvendinamas įrankių naudojimas, ir atidžiau pažvelgsime į „Codex“ smėliadėžės modelį.

Autorius

Michael Bolin

Padėkos

Ypatingas ačiū visai komandai, sukūrusiai „Codex CLI“.

Skaityti toliau

Peržiūrėti viską
Tax Agent > Art Card
Kaip su „Codex“ kurti save tobulinančius mokesčių agentus

Inžinerija

codex windows > art card
Saugios, veiksmingos smėliadėžės kūrimas, kad „Windows“ sistemoje veiktų „Codex“

Inžinerija

MRC 1_1
Iš kur atsirado goblinai

Inžinerija