Pāriet uz galveno saturu
OpenAI

2026. gada 23. janvāris

Inženierija

Codex aģenta cikla atritināšana

Autors: Michael Bolin, tehniskā personāla loceklis

Notiek ielāde…

Codex CLI⁠(atveras jaunā logā) ir mūsu starpplatformu lokālais programmatūras aģents, kas izstrādāts, lai veiktu augstas kvalitātes un uzticamas programmatūras izmaiņas, vienlaikus droši un efektīvi darbojoties tavā datorā. Mēs esam apguvuši ļoti daudz par to, kā izveidot pasaules klases programmatūras aģentu, kopš aprīlī palaidām CLI⁠. Lai pastāstītu par šīm atziņām, šis ir pirmais raksts sērijā, kurā mēs apskatīsim dažādus Codex darbības aspektus, kā arī smagi gūtas mācības. (Lai iegūtu vēl detalizētāku skatījumu uz to, kā tiek veidots Codex CLI, apskati mūsu atvērtā koda repozitoriju vietnē https://github.com/openai/codex⁠(atveras jaunā logā). Ja vēlies uzzināt vēl vairāk, daudzas sīkākas detaļas par mūsu projektēšanas lēmumiem ir pieminētas GitHub jautājumos un atgādāšanas pieprasījumos.)

Sākumā pievērsīsimies aģenta ciklam, kas ir Codex CLI loģikas kodols, kurš ir atbildīgs par mijiedarbības organizēšanu starp lietotāju, modeli un rīkiem, kurus modelis izsauc, lai veiktu nozīmīgu programmatūras darbu. Mēs ceram, ka šis ieraksts sniegs tev labu ieskatu par to, kāda ir mūsu aģenta (jeb vadības ietvara) loma lielo valodas modeļu (LVM) izmantošanā.

Pirms iedziļināmies, īsa piezīme par terminoloģiju: OpenAI “Codex” aptver programmatūras aģentu piedāvājumu kopumu, tostarp Codex CLI, Codex Cloud un Codex VS Code paplašinājumu. Šis ieraksts koncentrējas uz Codex vadības ietvaru jeb “harness”, kas nodrošina pamata aģenta ciklu un izpildes loģiku, kas ir visu Codex pieredžu pamatā un ir pieejama, izmantojot Codex CLI. Vienkāršības labad šeit terminus "Codex" un "Codex CLI" lietosim savstarpēji aizvietojami.

Aģenta cikls

Katra mākslīgā intelekta aģenta pamatā ir process, ko dēvē par “aģenta ciklu”. Vienkāršota aģenta cikla ilustrācija izskatās šādi:

Diagramma ar nosaukumu “Aģenta cikls”, kas ilustrē, kā mākslīgā intelekta sistēma apstrādā lietotāja pieprasījumu, izsauc rīkus, novēro rezultātus, atjaunina plānu un atgriež izvades. Bultas savieno tādus soļus kā lietotāja ievade, modeļa spriešana, rīku darbības un galīgā atbilde.

Vispirms aģents no lietotāja saņem ievadi, ko iekļaut teksta instrukciju kopā, kuru tas sagatavo modelim – to dēvē par uzvedni.

Nākamais solis ir vaicāt modelim, nosūtot tam mūsu norādījumus un prasot ģenerēt atbildi – šo procesu dēvē par inferenci. Inferencē teksta uzvedne vispirms tiek pārvērsta par ievades tekstvienībām⁠(atveras jaunā logā) jeb tokeniem – tie ir veselu skaitļu identifikatori, kas indeksē modeļa vārdnīcu. Pēc tam šīs tekstvienības tiek izmantotas modeļa izvades ģenerēšanai, radot jaunu izvades tekstvienību virkni.

Izvades tekstvienības tiek pārveidotas atpakaļ tekstā, kas kļūst par modeļa atbildi. Tā kā tekstvienības tiek ģenerētas pakāpeniski, šī pārveidošana var notikt, kamēr modelis darbojas, tāpēc daudzas uz LVM balstītas lietojumprogrammas rāda straumētu izvadi. Praksē inference parasti ir slēpta aiz API, kas darbojas ar tekstu, abstrahējot detaļas par dalīšanu tekstvienībās.

Inferences soļa rezultātā modelis vai nu (1) sniedz galīgo atbildi uz lietotāja sākotnējo ievadi, vai (2) prasa rīka izsaukumu, ko aģentam ir paredzēts veikt (piemēram, “palaid ls un ziņo par izvadi”). (2) gadījumā aģents izpilda rīka izsaukumu un pievieno tā izvadi sākotnējai uzvednei. Šī izvade tiek izmantota, lai ģenerētu jaunu ievadi, kas tiek izmantota, lai atkārtoti vaicātu modelim; aģents pēc tam var ņemt vērā šo jauno informāciju un mēģināt vēlreiz.

Šis process atkārtojas, līdz modelis pārstāj veikt rīku izsaukumus un tā vietā izveido ziņojumu lietotājam (OpenAI modeļos to sauc par palīgziņojumu). Daudzos gadījumos šis ziņojums tieši atbild uz lietotāja sākotnējo pieprasījumu, bet tas var būt arī papildu jautājums lietotājam.

Tā kā aģents var izpildīt rīku izsaukumus, kas maina lokālo vidi, tā “izvade” neaprobežojas tikai ar palīgziņojumu. Daudzos gadījumos programmatūras aģenta galvenā izvade ir kods, ko tas raksta vai rediģē tavā datorā. Tomēr katrs solis vienmēr beidzas ar palīgziņojumu – piemēram, “Es pievienoju architecture.md, ko tu prasīji” – kas norāda uz izbeigšanas stāvokli aģenta ciklā. No aģenta skatpunkta tā darbs ir pabeigts, un vadība atgriežas pie lietotāja.

Ceļojums no lietotāja ievades līdz aģenta atbildei, kas parādīts diagrammā, tiek saukts par vienu sarunas kārtu (Codex sistēmā – par pavedienu ). Taču šī sarunas kārta var ietvert daudzas iterācijas starp modeļa inferenci un rīku izsaukumiem. Katru reizi, kad tu nosūti jaunu ziņojumu esošai sarunai, sarunas vēsture tiek iekļauta kā daļa no uzvednes jaunajai kārtai, kas ietver ziņojumus un rīku izsaukumus no iepriekšējām kārtām:

Diagramma ar nosaukumu “Vairāksoļu aģenta cikls”, kurā parādīts, kā mākslīgā intelketa aģents iteratīvi saņem lietotāja ievadi, ģenerē darbības, konsultējas ar rīkiem, atjaunina stāvokli un atgriež rezultātus. Ietver apzīmētus soļus, bultiņas un rīku izvades piemērus, kas ilustrē aģenta spriešanas ciklu.

Tas nozīmē, ka, sarunai augot, palielinās arī uzvednes garums, ko izmanto modeļa izvades ģenerēšanai. Šis garums ir svarīgs, jo katram modelim ir konteksta logs, kas ir maksimālais tekstvienību skaits, ko tas var izmantot vienā inferencē. Ņem vērā, ka šajā logā ir iekļautas ievades un izvades tekstvienības. Kā tu droši vien vari iedomāties, aģents varētu izlemt veikt simtiem rīku izsaukumu vienā kārtā, kas varētu izsmelt konteksta logu. Šī iemesla dēļ konteksta loga pārvaldība ir viena no daudzajām aģenta atbildībām. Tagad iedziļināsimies, lai redzētu, kā Codex darbina aģenta ciklu.

Modeļa inference

Codex CLI sūta HTTP pieprasījumus uz Responses API⁠(atveras jaunā logā), lai veiktu modeļa inferenci. Mēs apskatīsim, kā informācija plūst caur Codex, kas izmanto Responses API, lai darbinātu aģenta ciklu.

Responses API galapunkts, ko izmanto Codex CLI, ir konfigurējams⁠(atveras jaunā logā), tāpēc to var izmantot ar jebkuru galapunktu, kas realizē Responses API⁠(atveras jaunā logā):

Izpētīsim, kā Codex izveido uzvedni pirmajam inferenču izsaukumam sarunā.

Sākotnējās uzvednes veidošana

Kā galalietotājs tu burtiski nenorādi uzvedni, kas tiek izmantota modeļa izvades ģenerēšanai, kad tu sniedz vaicājumu Responses API. Tā vietā tu savā vaicājumā norādi dažādus ievades tipus, un Responses API serveris izlemj, kā šo informāciju strukturēt uzvednē, ko modelim ir paredzēts izmantot. Tu vari uztvert uzvedni kā “elementu sarakstu”; šajā sadaļā tiks izskaidrots, kā tavs vaicājums tiek pārveidots par šo sarakstu.

Sākotnējā uzvednē katrs saraksta elements ir saistīts ar kādu lomu. role norāda, cik liels svars ir jāpiešķir saistītajam saturam, un tā ir viena no šādām vērtībām (prioritātes dilstošā secībā): system, developer, user, assistant.

Responses API⁠(atveras jaunā logā) pieņem JSON datu kopu ar daudziem parametriem. Mēs pievērsīsimies šiem trim:

Codex vidē lauks instructions tiek nolasīts no model_instructions_file⁠(atveras jaunā logā), kas atrodas ~/.codex/config.toml, ja tas ir norādīts; pretējā gadījumā tiek izmantotas instrukcijas base_instructions, kas saistītas ar modeli⁠(atveras jaunā logā). Konkrētā modeļa instrukcijas atrodas Codex repozitorijā un ir iekļautas CLI (piemēram, gpt-5.2-codex_prompt.md⁠(atveras jaunā logā)).

Lauks tools ir rīku definīciju saraksts, kas atbilst Responses API definētajai shēmai. Codex gadījumā tas ietver rīkus, ko nodrošina Codex CLI; rīkus, ko nodrošina Responses API, kuriem jābūt pieejamiem Codex; kā arī lietotāja nodrošinātus rīkus, parasti izmantojot MCP serverus:

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
]

Visbeidzot, JSON datu kopas input lauks ir vienumu saraksts. Codex ievieto šādus vienumus⁠(atveras jaunā logā) sarakstā input pirms lietotāja ziņojuma pievienošanas:

1. Ziņojums ar role=developer, kas apraksta smilškasti, kas attiecas tikai uz Codex nodrošināto shell rīku, kas definēts tools sadaļā. Tas nozīmē, ka citi rīki, piemēram, MCP serveru nodrošinātie rīki, nav Codex smilškastē un ir paši atbildīgi par savu aizsargmehānismu ieviešanu.

Ziņojums ir veidots no veidnes, kur galvenās satura daļas nāk no Markdown fragmentiem, kas ir iekļauti Codex CLI, piemēram, workspace_write.md⁠(atveras jaunā logā) un on_request.md⁠(atveras jaunā logā):

Vienkāršs teksts

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. (Neobligāti) Ziņojums ar role=developer, kura saturs ir developer_instructions vērtība, kas nolasīta no lietotāja config.toml faila.

3. (Neobligāti) Ziņojums ar role=user, kura saturs ir “lietotāja norādījumi”, kas nav iegūti no viena faila, bet ir apkopoti no vairākiem avotiem⁠(atveras jaunā logā). Parasti konkrētāki norādījumi parādās vēlāk:

4. Ziņojums ar role=user, kas apraksta vietējo vidi, kurā aģents pašlaik darbojas. Tas norāda pašreizējo darba direktoriju un lietotāja čaulu⁠(atveras jaunā logā):

Vienkāršs teksts

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

Kad Codex ir veicis visus iepriekš minētos aprēķinus, lai inicializētu input, tas pievieno lietotāja ziņojumu, lai sāktu sarunu.

Iepriekšējie piemēri koncentrējās uz katra ziņojuma saturu, bet ņem vērā, ka katrs input elements ir JSON objekts ar type, role⁠(atveras jaunā logā) un content, kā aprakstīts tālāk:

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
}

Kad Codex ir izveidojis pilnu JSON datu kopu, ko nosūtīt Responses API, tas veic HTTP POST pieprasījumu ar Authorization galveni atkarībā no tā, kā Responses API galapunkts ir konfigurēts failā ~/.codex/config.toml (ja norādīts, tiek pievienotas papildu HTTP galvenes un vaicājuma parametri).

Kad OpenAI Responses API serveris saņem pieprasījumu, tas izmanto JSON, lai iegūtu uzvedni modelim šādā veidā (taču pielāgota Responses API implementācija varētu izdarīt citādu izvēli):

Momentuzņēmuma diagramma, kas attēlo vienu soli mākslīgā intelekta aģenta ciklā. Lietotāja pieprasījums nonāk modelī, kas ģenerē domu, darbību ar rīka nosaukumu un rīka ievadi. Diagramma izceļ šo starpposma spriešanas soli pirms rīka izsaukšanas.

Kā redzi, uzvednē pirmo trīs elementu secību nosaka serveris, nevis klients. No šiem trim elementiem tikai sistēmas ziņojuma saturu nosaka arī serveris, jo tools un instructions nosaka klients. Tiem seko input no JSON datu kopas, lai pabeigtu uzvedni.

Tagad, kad mums ir uzvedne, mēs esam gatavi modeļa izvades ģenerēšanai.

Pirmā kārta

Šis HTTP pieprasījums uz Responses API uzsāk pirmo sarunas “kārtu” Codex sistēmā. Serveris atbild ar servera sūtīto notikumu (SSE⁠(atveras jaunā logā)) straumi. Katra notikuma data ir JSON datu kopa ar "type", kas sākas ar "response", un tas varētu izskatīties apmēram šādi (pilns notikumu saraksts ir pieejams mūsu API dokumentācijā⁠(atveras jaunā logā)):

Vienkāršs teksts

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 uzņem notikumu straumi⁠(atveras jaunā logā) un pārpublicē tos kā iekšējos notikumu objektus, ko var izmantot klients. Tādi notikumi kā response.output_text.delta tiek izmantoti, lai atbalstītu straumēšanu lietotāja saskarnē, savukārt citi notikumi, piemēram, response.output_item.added, tiek pārveidoti par objektiem, kas tiek pievienoti input nākamajiem Responses API izsaukumiem.

Pieņemsim, ka pirmajā pieprasījumā uz Responses API ir iekļauti divi response.output_item.done notikumi: viens ar type=reasoning un viens ar type=function_call. Šie notikumi ir jāatspoguļo JSON laukā input, kad mēs vēlreiz vaicājam modelim ar atbildi uz rīka izsaukumu: 

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
]

Iegūtā uzvedne, kas tiks izmantota modeļa izvades ģenerēšanai turpmākā vaicājuma ietvaros, izskatīsies šādi:

Diagramma ar apzīmējumu “Momentuzņēmums 2”, kurā redzams mākslīgā intelekta aģents pēc rīka izsaukuma. Modelis saņem rīka novērojumu un ģenerē jaunu domu un darbību. Bultiņas savieno ievades, novērojumus un izvades, lai parādītu, kā aģents atkārto savu spriešanas ciklu.

Ievēro, kā vecā uzvedne ir precīzs jaunās uzvednes prefikss. Tas ir apzināti, jo tas padara turpmākos pieprasījumus daudz efektīvākus, ļaujot mums izmantot uzvedņu kešdarbi (par ko runāsim nākamajā sadaļā par veiktspēju).

Atskatoties uz mūsu pirmo aģenta cikla diagrammu, mēs redzam, ka starp inferenci un rīku izsaukšanu varētu būt daudz iterāciju. Uzvedne var turpināt pieaugt, līdz beidzot saņemam palīgziņojumu, kas norāda uz kārtas beigām:

Vienkāršs teksts

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

Codex CLI sistēmā mēs parādām lietotājam palīgziņojumu un fokusējam komponētāju, lai norādītu lietotājam, ka ir viņa “kārta” turpināt sarunu. Ja lietotājs atbild, gan palīgziņojums no iepriekšējās kārtas, gan lietotāja jaunais ziņojums jāpievieno input Responses API pieprasījumā sākt jauno kārtu:

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ēlreiz, tā kā mēs turpinām sarunu, uz Responses API nosūtītā input garums turpina pieaugt:

Diagramma ar nosaukumu “Momentuzņēmums 3”, kas attēlo mākslīgā intelekta aģenta cikla pēdējo posmu. Pēc rīka rezultātu saņemšanas modelis ģenerē noslēdzošu domu un galīgo atbildi, kas tiek sniegta lietotājam. Bultiņas parāda pāreju no rīka rezultāta uz pabeigtu atbildi.

Apskatīsim, ko šī arvien pieaugošā uzvedne nozīmē veiktspējai.

Veiktspējas apsvērumi

Iespējams, tu sev jautā: “Paga, vai aģenta cikls nav kvadrātisks attiecībā uz to, cik daudz JSON tiek nosūtīts uz Responses API sarunas laikā?” Un tev būtu taisnība. Lai gan Responses API atbalsta neobligātu previous_response_id⁠(atveras jaunā logā) parametru, lai mazinātu šo problēmu, Codex to šodien neizmanto, galvenokārt, lai pieprasījumi būtu pilnībā bez stāvokļa un lai atbalstītu nulles datu saglabāšanas (ZDR) konfigurācijas.

Izvairīšanās no previous_response_id vienkāršo Responses API nodrošinātāja darbu, jo tas nodrošina, ka katrs pieprasījums ir bez stāvokļa. Tas arī padara vienkāršu atbalsta sniegšanu klientiem, kuri ir izvēlējušies nulles datu saglabāšanu (ZDR)⁠(atveras jaunā logā), jo datu glabāšana, kas nepieciešama, lai atbalstītu previous_response_id, būtu pretrunā ar ZDR. Ņem vērā, ka ZDR klienti nezaudē iespēju gūt labumu no iepriekšējo kārtu spriešanas ziņojumiem, jo saistīto encrypted_content var atšifrēt serverī. (OpenAI saglabā ZDR klienta atšifrēšanas atslēgu, bet ne tā datus.) Skatiet atgādāšanas pieprasījumus #642⁠(atveras jaunā logā) un #1641⁠(atveras jaunā logā) saistītajām Codex izmaiņām, lai atbalstītu ZDR.

Parasti modeļa izvades ģenerēšanas izmaksas ievērojami pārsniedz tīkla trafika izmaksas, padarot to par mūsu efektivitātes centienu galveno mērķi. Tāpēc uzvedņu kešdarbe ir tik svarīga, jo tā ļauj mums atkārtoti izmantot skaitļošanu no iepriekšējā inferences izsaukuma. Kad mēs iegūstam kešatmiņas trāpījumus, modeļa izvades ģenerēšana ir lineāra, nevis kvadrātiska. Mūsu uzvedņu kešdarbes ⁠(atveras jaunā logā)dokumentācija to izskaidro sīkāk:

Kešatmiņas trāpījumi ir iespējami tikai tad, ja uzvednē ir precīza prefiksa atbilstība. Lai izmantotu kešdarbes priekšrocības, novieto statisko saturu, piemēram, instrukcijas un piemērus, uzvednes sākumā, bet mainīgo saturu, piemēram, lietotājam specifisku informāciju, beigās. Tas attiecas arī uz attēliem un rīkiem, kuriem jābūt identiskiem starp pieprasījumiem.

Ņemot to vērā, apskatīsim, kāda veida darbības varētu izraisīt kešatmiņas neatbilstību Codex sistēmā:

  • Modelim pieejamo tools maiņa sarunas vidū.
  • model, kas ir Responses API pieprasījuma mērķis, maiņa (praktiski tas maina trešo elementu sākotnējā uzvednē, jo tajā ir modelim specifiski norādījumi).
  • Smilškastes konfigurācijas, apstiprināšanas režīma vai pašreizējā darba direktorija maiņa.

Codex komandai jābūt uzmanīgai, ieviešot jaunas funkcijas Codex CLI, kas varētu apdraudēt uzvedņu kešdarbi. Piemēram, mūsu sākotnējais atbalsts MCP rīkiem ieviesa kļūdu, jo mēs nebijām uzskaitījuši rīkus konsekventā secībā⁠(atveras jaunā logā), tādējādi izraisot kešatmiņas neatbilstības. Ņem vērā, ka MCP rīki var būt īpaši sarežģīti, jo MCP serveri var dinamiski mainīt nodrošināto rīku sarakstu, izmantojot notifications/tools/list_changed⁠(atveras jaunā logā) paziņojumu. Šī paziņojuma apstrāde garas sarunas vidū var izraisīt resursietilpīgu kešatmiņas neatbilstību.

Kad vien iespējams, mēs apstrādājam konfigurācijas izmaiņas, kas notiek sarunas laikā, pievienojot jaunu ziņojumu pie input, lai atspoguļotu izmaiņas, nevis mainot agrāku ziņojumu:

  • Ja mainās smilškastes konfigurācija vai apstiprināšanas režīms, mēs ievietojam⁠(atveras jaunā logā) jaunu role=developer ziņojumu ar tādu pašu formātu kā sākotnējam <permissions instructions> elementam.
  • Ja mainās pašreizējais darba direktorijs, mēs ievietojam⁠(atveras jaunā logā) jaunu role=user ziņojumu, kura formāts ir tāds pats kā sākotnējam <environment_context>.

Mēs pieliekam lielas pūles, lai nodrošinātu kešatmiņas atbilstības veiktspējas uzlabošanai. Ir vēl viens svarīgs resurss, kas mums jāpārvalda: konteksta logs.

Mūsu vispārējā stratēģija, lai izvairītos no konteksta loga izsmelšanas, ir sablīvēt sarunu, kad tekstvienību skaits pārsniedz noteiktu slieksni. Konkrēti, mēs aizstājam input ar jaunu, mazāku elementu sarakstu, kas atspoguļo sarunu, ļaujot aģentam turpināt ar izpratni par to, kas līdz šim ir noticis. Agrīnai sablīvēšanas ieviešanai⁠(atveras jaunā logā) bija nepieciešams, lai lietotājs manuāli izsauktu /compact komandu, kas veiktu vaicājumu Responses API, izmantojot esošo sarunu plus pielāgotas instrukcijas kopsavilkumam⁠(atveras jaunā logā). Codex izmantoja iegūto palīgziņojumu, kas saturēja kopsavilkumu, kā jaunu ievadi⁠(atveras jaunā logā) turpmākajās sarunas kārtās.

Kopš tā laika Responses API ir papildināts, lai atbalstītu īpašu /responses/compact galapunktu⁠(atveras jaunā logā), kas veic sablīvēšanu efektīvāk. Tas atgriež elementu sarakstu⁠(atveras jaunā logā), ko var izmantot iepriekšējā input vietā, lai turpinātu sarunu, vienlaikus atbrīvojot konteksta logu. Šajā sarakstā ir iekļauts īpašs type=compaction elements ar necaurspīdīgu encrypted_content elementu, kas saglabā modeļa latento izpratni par sākotnējo sarunu. Tagad Codex automātiski izmanto šo galapunktu, lai sablīvētu sarunu, kad tiek pārsniegts auto_compact_limit⁠(atveras jaunā logā).

Kas gaidāms tālāk

Mēs esam iepazīstinājuši ar Codex aģenta ciklu un izskaidrojuši, kā Codex veido un pārvalda savu kontekstu, veicot vaicājumus modelim. Šajā procesā mēs izcēlām praktiskus apsvērumus un labāko praksi, kas attiecas uz ikvienu, kurš veido aģenta ciklu uz Responses API bāzes.

Lai gan aģenta cikls nodrošina Codex pamatu, tas ir tikai sākums. Turpmākajos ierakstos mēs iedziļināsimies CLI arhitektūrā, izpētīsim, kā tiek ieviesta rīku izmantošana, un aplūkosim tuvāk Codex smilškastes modeli.

Autors

Michael Bolin

Pateicības

Īpaša pateicība visai komandai, kas izveidoja Codex CLI.

Turpināt lasīt

Skatīt visu
Tax Agent > Art Card
Pašuzlabojošu nodokļu aģentu veidošana ar Codex

Inženierija

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

Inženierija

MRC 1_1
No kurienes radās goblini

Inženierija