Անցնել հիմնական բովանդակությանը
OpenAI

23 հունվարի, 2026 թ.

Ճարտարագիտություն

Codex ագենտի ցիկլի բացահայտում

Մայքլ Բոլին, տեխնիկական անձնակազմի անդամ

Բեռնվում է…

Codex CLI⁠(բացվում է նոր պատուհանում) -ը մեր բազմապլատֆորմային տեղական ծրագրային ագենտն է, որը նախատեսված է բարձրորակ և հուսալի ծրագրային փոփոխություններ կատարելու համար՝ ձեր համակարգչի վրա աշխատելով անվտանգ և արդյունավետ եղանակով։ Մենք ահռելի շատ բան ենք սովորել այն մասին, թե ինչպես կառուցել համաշխարհային մակարդակի ծրագրային ագենտ ապրիլին CLI-ի առաջին գործարկումից ի վեր⁠։ Այդ դիտարկումները բացահայտելու համար սա շարունակական շարքի առաջին գրառումն է, որտեղ մենք կուսումնասիրենք Codex-ի աշխատանքի տարբեր կողմերը, ինչպես նաև դժվարությամբ ձեռք բերված դասերը։ (Եթե ցանկանում եք ավելի մանրամասն պատկերացում կազմել, թե ինչպես է կառուցված Codex CLI-ն, այցելեք մեր բաց կոդով պահոցը՝ https://github.com/openai/codex⁠(բացվում է նոր պատուհանում)հասցեով։ Մեր դիզայնի որոշումների մանրամասների նրբություններից շատերը փաստագրված են GitHub-ի խնդիրներում և կոդի փոփոխությունների վերահանման հարցումներում, եթե կցանկանաք ավելին իմանալ)։

Սկսելու համար մենք կկենտրոնանանք ագենտի ցիկլի վրա, որը Codex CLI-ի հիմնական տրամաբանությունն է և պատասխանատու է օգտատիրոջ, մոդելի և մոդելի կանչած գործիքների միջև փոխազդեցության կազմակերպման համար՝ իմաստալից ծրագրային աշխատանք կատարելու նպատակով։ Հուսով ենք, որ այս գրառումը ձեզ լավ պատկերացում կտա այն դերի մասին, որը մեր ագենտը (կամ «հարնես»-ը) ունի LLM-ի օգտագործման գործում։

Մինչ կանցնենք հիմնականին, մի կարճ նշում տերմինաբանության վերաբերյալ. OpenAI-ում «Codex»-ը ներառում է ծրագրային ագենտների առաջարկների մի շարք, այդ թվում՝ Codex CLI, Codex Cloud և Codex VS Code ընդլայնումը։ Այս գրառումը կենտրոնանում է Codex հարնես-ի վրա, որը տրամադրում է հիմնական ագենտի ցիկլը և կատարման տրամաբանությունը, որը հիմք է հանդիսանում Codex-ի բոլոր փորձառությունների համար և հասանելի է Codex CLI-ի միջոցով։ Հարմարության համար այստեղ մենք «Codex» և «Codex CLI» տերմինները կօգտագործենք փոխարինելիորեն։

Ագենտի ցիկլը

Յուրաքանչյուր ԱԲ ագենտի հիմքում կա մի հասկացություն, որը կոչվում է «ագենտի ցիկլ»։ Ագենտի ցիկլի պարզեցված նկարագրությունը այսպես է երևում․

«Ագենտի ցիկլ» վերնագրով դիագրամ, որը ցույց է տալիս, թե ինչպես է ԱԲ համակարգը մշակում օգտատիրոջ հարցումը, կանչի գործիքները, դիտարկում արդյունքները, թարմացնում իր պլանը և վերադարձնում արդյունքները։ Սլաքները կապում են այնպիսի քայլեր, ինչպիսիք են օգտատիրոջ մուտքագրումը, մոդելի հիմնավորումը, գործիքների գործողությունները և վերջնական պատասխանը։

Սկսելու համար, ագենտն օգտատիրոջից վերցնում է ներածում-ը, որպեսզի այն ներառի տեքստային հրահանգների հավաքածուում, որը պատրաստում է մոդելի համար և հայտնի է որպես հարցում։

Հաջորդ քայլը մոդելին հարցում ուղարկելն է՝ նրան ուղարկելով մեր հրահանգները և խնդրելով, որ այն ստեղծի պատասխան․ գործընթաց, որը հայտնի է ինֆերենս անվանումով։ Ինֆերենսի ընթացքում տեքստային հարցումը նախ վերափոխվում է մուտքային թոքենների⁠(բացվում է նոր պատուհանում)հաջորդականության՝ ամբողջ թվերի, որոնք ինդեքսավորում են մոդելի բառապաշարը։ Այնուհետև այս թոքեններն օգտագործվում են մոդելի նմուշառման համար՝ ստեղծելով արտածման թոքենների նոր հաջորդականություն։

Արտածման թոքենները վերափոխվում են տեքստի, որը դառնում է մոդելի պատասխանը։ Քանի որ թոքեններն աստիճանաբար են արտադրվում, այս վերափոխումը կարող է տեղի ունենալ մոդելի աշխատանքի ընթացքում, ինչի արդյունքում LLM-ների վրա հիմնված շատ հավելվածներ ցուցադրում են հոսքային ելք։ Գործնականում, ինֆերենսը սովորաբար API-ի միջոցով է իրականացվում, որը տեքստի վրա է աշխատում՝ թաքցնելով թոքենիզացիայի մանրամասները։

Ինֆերենսի քայլի արդյունքում մոդելը կա՛մ (1) ստեղծում է վերջնական պատասխան օգտատիրոջ սկզբնական մուտքագրմանը, կա՛մ (2) պահանջում է գործիքային կանչ, որը պետք է կատարի ագենտը (օրինակ՝ «run ls և ներկայացրեք արդյունքը»)։ (2)-ի դեպքում ագենտը կատարում է գործիքի կանչը և դրա արդյունքը կցում է սկզբնական հարցմանը։ Այս արդյունքն օգտագործվում է նոր մուտք ստեղծելու համար, որը կրկին հարցում է կատարում մոդելին. այնուհետև ագենտը կարող է հաշվի առնել այս նոր տեղեկատվությունը և նորից փորձել։

Այս գործընթացը կրկնվում է, մինչև մոդելը դադարի գործիքների կանչեր արտածել և դրա փոխարեն օգտատիրոջ համար հաղորդագրություն ստեղծի (OpenAI մոդելներում այն կոչվում է օգնականի հաղորդագրություն)։ Շատ դեպքերում այս հաղորդագրությունն անմիջապես պատասխանում է օգտատիրոջ սկզբնական հարցմանը, բայց այն կարող է նաև լինել օգտատիրոջ համար լրացուցիչ հարց։

Քանի որ ագենտը կարող է կատարել գործիքների կանչեր, որոնք փոփոխում են տեղական միջավայրը, դրա «արդյունքը» չի սահմանափակվում օգնականի հաղորդագրությամբ։ Շատ դեպքերում ծրագրային ագենտի հիմնական արդյունքը ձեր համակարգչի վրա նրա գրած կամ խմբագրած կոդն է։ Այնուամենայնիվ, յուրաքանչյուր հերթափոխ միշտ ավարտվում է օգնականի հաղորդագրությամբ՝ օրինակ՝ «Ես ավելացրեցի ձեր խնդրած architecture.md ֆայլը», որն ազդարարում է ագենտի ցիկլի ավարտը։ Ագենտի տեսանկյունից, իր աշխատանքն ավարտված է, և վերահսկողությունը վերադառնում է օգտատիրոջը։

Օգտատիրոջ մուտքագրումից մինչև ագենտի պատասխան գծապատկերում ցուցադրված ճանապարհը կոչվում է զրույցի մեկ պտույտ (Codex-ում՝ շարոց )։ Թեև այս զրույցի պտույտը կարող է ներառել բազմաթիվ կրկնություններ մոդելի ինֆերենսի և գործիքների կանչերի միջև։ Ամեն անգամ, երբ նոր հաղորդագրություն եք ուղարկում արդեն գոյություն ունեցող զրույցին, զրույցի պատմությունը ներառվում է որպես նոր պտույտի հարցման մաս, որը ներառում է նախորդ պտույտների հաղորդագրություններն ու գործիքների կանչերը․

«Բազմափուլ ագենտի ցիկլ» վերնագրով դիագրամ, որը ցույց է տալիս, թե ինչպես է ԱԲ ագենտը հերթականությամբ ընդունում օգտատիրոջ մուտքագրումը, ստեղծում գործողություններ, խորհրդակցում գործիքների հետ, թարմացնում վիճակը և վերադարձնում արդյունքները։ Ներառում է պիտակավորված քայլեր, սլաքներ և գործիքի արդյունքների օրինակներ, որոնք պատկերազարդում են ագենտի հիմնավորման ցիկլը։

Սա նշանակում է, որ զրույցի աճին զուգընթաց աճում է նաև մոդելը նմուշառելու համար օգտագործվող հարցման երկարությունը։ Այս երկարությունը կարևոր է, քանի որ յուրաքանչյուր մոդել ունի համատեքստային պատուհան, որը թոքենների առավելագույն քանակն է, որ կարող է օգտագործվել մեկ ինֆերենսի կանչի ընթացքում։ Նկատի ունեցեք, որ այս պատուհանը ներառում է և՛ մուտքային, և՛ ելքային թոքեններ։ Ինչպես կարող եք պատկերացնել, ագենտը կարող է որոշել մեկ հերթափոխում կատարել հարյուրավոր գործիքային կանչեր՝ հնարավոր է սպառելով համատեքստային պատուհանը։ Այս պատճառով, համատեքստային պատուհանի կառավարումը ագենտի բազմաթիվ պարտականություններից մեկն է։ Հիմա եկեք առաջ գնանք՝ տեսնելու, թե ինչպես է Codex-ը գործարկում ագենտի ցիկլը։

Մոդելի ինֆերենս

Codex CLI-ն HTTP հարցումներ է ուղարկում Պատասխանների API⁠(բացվում է նոր պատուհանում) ՝ մոդելի ինֆերենսը գործարկելու համար։ Մենք կուսումնասիրենք, թե ինչպես է տեղեկատվությունն անցնում Codex-ի միջոցով, որն օգտագործում է Պատասխանների API-ն՝ ագենտի ցիկլը կառավարելու համար։

Codex CLI-ի օգտագործած Պատասխանների API-ի վերջնակետը կարգավորելի է⁠(բացվում է նոր պատուհանում), ուստի այն կարող է օգտագործվել ցանկացած վերջնակետի հետ, որը իրականացնում է Պատասխանների API-ն⁠(բացվում է նոր պատուհանում):

Եկեք ուսումնասիրենք, թե ինչպես է Codex-ը ստեղծում հարցումը զրույցի առաջին ինֆերենս կանչի համար։

Սկզբնական հարցման ստեղծում

Որպես վերջնական օգտատեր՝ դուք չեք նշում մոդելի նմուշառման համար օգտագործվող հարցումը բառացիորեն, երբ հարցում եք կատարում Պատասխանների API-ին։ Փոխարենը, դուք ձեր հարցման մեջ նշում եք մուտքագրման տարբեր տեսակներ, և Պատասխանների API սերվերը որոշում է, թե ինչպես կառուցել այս տեղեկատվությունը մոդելի համար նախատեսված հարցման մեջ։ Դուք կարող եք հարցումը դիտարկել որպես «տարրերի ցանկ»․ այս բաժինը կբացատրի, թե ինչպես է ձեր հարցումը վերածվում այդ ցանկի։

Սկզբնական հարցման մեջ ցանկի յուրաքանչյուր կետ կապված է որոշակի պաշտոնի հետ։ Պաշտոն-ը ցույց է տալիս, թե որքան կշիռ պետք է ունենա համապատասխան բովանդակությունը և ունի հետևյալ արժեքներից մեկը (առաջնահերթության նվազման կարգով)՝ համակարգ, մշակող, օգտատեր, օգնական։

Պատասխանների API⁠(բացվում է նոր պատուհանում)-ն ընդունում է բազմաթիվ պարամետրերով JSON բեռնատարողություն։ Մենք կկենտրոնանանք այս երեքի վրա․

Նշված լինելու դեպքում Codex-ում հրահանգներ դաշտը կարդացվում է model_instructions_file⁠(բացվում է նոր պատուհանում)-ից ~/.codex/config.toml-ում, հակառակ դեպքում օգտագործվում են base_instructions, որոնք կապված են մոդելի հետ⁠(բացվում է նոր պատուհանում)։ Մոդելին հատուկ հրահանգները գտնվում են Codex պահոցում և ներառված են CLI-ում (օրինակ՝ gpt-5.2-codex_prompt.md⁠(բացվում է նոր պատուհանում))։

Գործիքներ դաշտը գործիքների սահմանումների ցանկ է, որը համապատասխանում է Պատասխանների API-ի սահմանած սխեմային։ Codex-ի համար սա ներառում է գործիքներ, որոնք տրամադրվում են Codex CLI-ի կողմից, Պատասխանների API-ի կողմից տրամադրվող գործիքներ, որոնք պետք է հասանելի լինեն Codex-ին, ինչպես նաև գործիքներ, որոնք տրամադրվում են օգտատիրոջ կողմից, սովորաբար MCP սերվերների միջոցով`

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
]

Վերջապես, JSON բեռնատարողության ներածման դաշտը տարրերի ցանկ է։ Codex-ը տեղադրում է հետևյալ տարրերը⁠(բացվում է նոր պատուհանում) ներածման մեջ՝ նախքան օգտատիրոջ հաղորդագրությունն ավելացնելը․

1։ Հաղորդագրություն պաշտոն=մշակող պարունակող, որը նկարագրում է սենդբոքսը, որը կիրառվում է միայն Codex-ի տրամադրած թաղանթի գործիքին և սահմանված է գործիքներ բաժնում։ Այսինքն՝ այլ գործիքները, օրինակ՝ MCP սերվերների կողմից տրամադրվողները, Codex-ի կողմից սենդբոքսավորված չեն և պատասխանատու են իրենց սեփական պաշտպանիչ սահմանափակումների կիրառման համար։

Հաղորդագրությունը ձևավորվում է ձևանմուշից, որտեղ բովանդակության հիմնական մասերը ստացվում են Codex CLI-ում Markdown-ի հատվածներից, օրինակ՝ workspace_write.md⁠(բացվում է նոր պատուհանում) և on_request.md⁠(բացվում է նոր պատուհանում):

Պարզ տեքստ

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. (Ընտրովի) պաշտոն=մշակող ունեցող հաղորդագրություն, որի բովանդակությունն օգտատիրոջ config.toml ֆայլից կարդացված մշակող_հրահանգներ արժեքն է։

3. (Ընտրովի) պաշտոն=օգտատեր պարունակող հաղորդագրություն, որի բովանդակությունը «օգտատիրոջ հրահանգներն» են, որոնք չեն վերցվում մեկ ֆայլից, այլ հավաքագրվում են տարբեր աղբյուրներից⁠(բացվում է նոր պատուհանում)։ Ընդհանուր առմամբ, ավելի կոնկրետ հրահանգները կհայտնվեն ավելի ուշ՝

4. պաշտոն=օգտատեր պարունակող հաղորդագրություն, որը նկարագրում է այն տեղական միջավայրը, որտեղ ագենտը ներկայումս գործում է։ Սա նշում է ընթացիկ աշխատանքային գրացուցակը և օգտատիրոջ թաղանթը⁠(բացվում է նոր պատուհանում)․

Պարզ տեքստ

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

Երբ Codex-ը կատարում է վերը նշված բոլոր հաշվարկները՝ ներածումը-ը սկզբնավորելու համար, այն ավելացնում է օգտատիրոջ հաղորդագրությունը՝ խոսակցությունը սկսելու նպատակով։

Նախորդ օրինակները կենտրոնացած էին յուրաքանչյուր հաղորդագրության բովանդակության վրա, սակայն նկատի ունեցեք, որ ներածման յուրաքանչյուր տարր JSON օբյեկտ է՝ տեսակ, պաշտոն⁠(բացվում է նոր պատուհանում) և բովանդակություն դաշտերով՝ հետևյալ կերպ․

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
}

Երբ Codex-ը ստեղծում է ամբողջական JSON բեռնատարողությունը՝ Պատասխանների API-ին ուղարկելու համար, այնուհետև կատարում է HTTP POST հարցումը՝ Թույլտվություն վերնագրով՝ կախված նրանից, թե ինչպես է Պատասխանների API-ի վերջնակետը կազմաձևված ~/.codex/config.toml ֆայլում (եթե նշված են, ավելացվում են լրացուցիչ HTTP վերնագրեր և հարցման պարամետրեր)։

Երբ OpenAI Պատասխանների API սերվերը ստանում է հարցումը, այն օգտագործում է JSON-ը՝ մոդելի համար հարցումը ձևավորելու նպատակով հետևյալ կերպ (համոզվելու, որ Պատասխանների API-ի հատուկ իրականացումը կարող է այլ ընտրություն կատարել)․

Դիագրամի սքրինշոթ, որը ցույց է տալիս ԱԲ ագենտի ցիկլի մեկ քայլ։ Օգտատիրոջ հարցումը մուտք է գործում մոդել, որը ստեղծում է միտք, գործողություն գործիքի անունով և գործիքի մուտք։ Դիագրամը ընդգծում է այս միջանկյալ հիմնավորման քայլը՝ նախքան գործիքը կանչելը։

Ինչպես տեսնում եք, հարցման առաջին երեք տարրերի հերթականությունը որոշվում է սերվերի, ոչ թե հաճախորդի կողմից։ Այդուհանդերձ, այդ երեք տարրերից միայն համակարգի հաղորդագրության բովանդակությունն է վերահսկվում սերվերի կողմից, քանի որ գործիքները և հրահանգները որոշվում են հաճախորդի կողմից։ Դրանց հաջորդում է JSON բեռնատարողության ներածումը՝ հարցումն ավարտելու համար։

Այժմ, երբ մենք ունենք մեր հարցումը, մենք պատրաստ ենք մոդելից նմուշ վերցնել։

Առաջին պտույտը

Պատասխանների API-ին ուղղված այս HTTP հարցումը սկսում է Codex-ում խոսակցության առաջին «շրջափուլ»-ը։ Սերվերը պատասխանում է սերվերի կողմից ուղարկվող իրադարձությունների հոսքով (SSE⁠(բացվում է նոր պատուհանում))։ Յուրաքանչյուր իրադարձության տվյալները JSON բեռնատարողություն է՝ «տեսակ»-ով, որը սկսվում է «պատասխան»-ով, և կարող է լինել, օրինակ, այսպիսի մի բան (իրադարձությունների ամբողջական ցանկը կարելի է գտնել մեր API փաստաթղթերում⁠(բացվում է նոր պատուհանում)):

Պարզ տեքստ

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-ը սպառում է իրադարձությունների հոսքը⁠(բացվում է նոր պատուհանում) և դրանք վերահրատարակում է որպես ներքին իրադարձությունների օբյեկտներ, որոնք հաճախորդը կարող է օգտագործել։ response.output_text.delta-ի նման իրադարձություններն օգտագործվում են UI-ում հոսքային հեռարձակումն ապահովելու համար, մինչդեռ response.output_item.added-ի նման այլ իրադարձությունները վերածվում են օբյեկտների, որոնք ավելացվում են ներածմանը՝ հետագա Պատասխանների API կանչերի համար։

Ենթադրենք, որ Պատասխանների API-ին ուղղված առաջին հարցումը ներառում է երկու response.output_item.done իրադարձություն՝ մեկը տեսակ=հիմնավորում, իսկ մյուսը տեսակ=գործառույթ_կանչ։ Այս իրադարձությունները պետք է ներկայացվեն JSON-ի ներածման դաշտում, երբ մենք կրկին հարցում ենք անում մոդելին գործիքի կանչի պատասխանով՝ 

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
]

Հաջորդ հարցման համար մոդելից նմուշառում կատարելու նպատակով օգտագործվող հարցումը կունենա հետևյալ տեսքը՝

«Վայրկենական լուսանկար 2» պիտակով դիագրամ, որը ցույց է տալիս ԱԲ ագենտին գործիքի կանչից հետո։ Մոդելը ստանում է գործիքի դիտարկում և արտադրում է նոր միտք և գործողություն։ Սլաքները միացնում են մուտքերը, դիտարկումները և արդյունքները ցույց տալու համար, թե ինչպես է ագենտը կրկնում իր հիմնավորման ցիկլը։

Մասնավորապես, նկատի ունեցեք, թե ինչպես հին հարցումը նոր հարցման ճշգրիտ նախածանցն է ։ Սա միտումնավոր է, քանի որ դա հետագա հարցումները դարձնում է շատ ավելի արդյունավետ՝ թույլ տալով մեզ օգտվել հարցման քեշավորումից (որի մասին կխոսենք հաջորդ բաժնում՝ կատարողականության վերաբերյալ)։

Հետ նայելով ագենտի ցիկլի մեր առաջին դիագրամին՝ տեսնում ենք, որ կարող են լինել բազմաթիվ կրկնություններ ինֆերենսի և գործիքների կանչի միջև։ Հարցումը կարող է շարունակել աճել, մինչև վերջապես ստանանք օգնականի հաղորդագրություն՝ նշելով շրջափուլի ավարտը․

Պարզ տեքստ

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

Codex CLI-ում մենք օգտատիրոջը ներկայացնում ենք օգնականի հաղորդագրությունը և կենտրոնացնում ուշադրությունը հեղինակի վրա՝ ցույց տալու օգտատիրոջը, որ իրենց «հերթն» է շարունակել զրույցը։ Եթե օգտատերը պատասխանի, ապա և՛ նախորդ պտույտի օգնականի հաղորդագրությունը, և՛ օգտատիրոջ նոր հաղորդագրությունը պետք է կցվեն ներածմանը Պատասխանների API հարցման մեջ՝ նոր պտույտը սկսելու համար․

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
]

Կրկին, քանի որ մենք շարունակում ենք զրույցը, Պատասխանների API-ին ուղարկվող ներածման երկարությունը շարունակում է աճել․

«Վայրկենական լուսանկար 3» պիտակով դիագրամ, որը ցույց է տալիս արհեստական բանականության ագենտի ցիկլի վերջնական փուլը։ Գործիքների արդյունքները ստանալուց հետո մոդելը ստեղծում է եզրափակիչ միտք և վերջնական պատասխան, որը վերադարձվում է օգտատիրոջը։ Սլաքները ցույց են տալիս գործիքի ելքից մինչև ավարտված պատասխան անցումը։

Եկեք ուսումնասիրենք, թե այս անընդհատ աճող հարցումը ինչ է նշանակում կատարողականության համար։

Կատարողականության նկատառումներ

Գուցե ինքներդ ձեզ հարցնեք՝ «Սպասեք, ագենտի ցիկլը քառակուսայի՞ն չէ՝ ըստ խոսակցության ընթացքում Պատասխանների API-ին ուղարկված JSON-ի քանակի»։ Եվ դուք ճիշտ եք։ Թեև Պատասխանների API-ն աջակցում է ընտրովի previous_response_id⁠(բացվում է նոր պատուհանում) պարամետր՝ այս խնդիրը մեղմելու համար, Codex-ն այսօր այն չի օգտագործում՝ հիմնականում հարցումները լիովին առանց որևէ վիճակի պահելու և չպահվող տվյալի (ZDR) կազմաձևումներն աջակցելու համար։

previous_response_id-ից խուսափելը պարզեցնում է Պատասխանների API-ի մատակարարի աշխատանքը, քանի որ այն ապահովում է, որ յուրաքանչյուր հարցում լինի առանց վիճակի։ Սա նաև հեշտացնում է այն հաճախորդների աջակցումը, որոնք ընտրել են չպահվող տվյալ (ZDR)⁠(բացվում է նոր պատուհանում), քանի որ previous_response_id-ին աջակցելու համար պահանջվող տվյալների պահպանումը կհակասեր ZDR-ին։ Նկատի ունեցեք, որ ZDR հաճախորդները չեն զիջում նախորդ պտույտներից սեփական հիմնավորման հաղորդագրություններից օգտվելու հնարավորությունը, քանի որ համապատասխան կոդավորված_բովանդակություն-ը կարող է գաղտնազերծվել սերվերի վրա։ (OpenAI-ը պահպանում է ZDR հաճախորդի գաղտնազերծման բանալին, բայց ոչ նրանց տվյալները։) Տեսեք PR-ները #642⁠(բացվում է նոր պատուհանում) և #1641⁠(բացվում է նոր պատուհանում)՝ Codex-ում ZDR-ին աջակցելու համար կատարված համապատասխան փոփոխությունների համար։

Ընդհանուր առմամբ, մոդելի նմուշառման ծախսը գերազանցում է ցանցային թրաֆիկի ծախսը, ինչի արդյունքում նմուշառումը դառնում է մեր արդյունավետության ջանքերի հիմնական թիրախը։ Ահա թե ինչու է հարցումների քեշավորումն այդքան կարևոր, քանի որ այն թույլ է տալիս մեզ վերօգտագործել նախորդ ինֆերենսի կանչի հաշվարկը։ Երբ մենք ստանում ենք քեշի հիթեր, մոդելի նմուշառումը լինում է գծային, այլ ոչ թե քառակուսային։ Մեր հարցման քեշավորման ⁠(բացվում է նոր պատուհանում)փաստաթուղթը սա բացատրում է ավելի մանրամասն․

Քեշի հիթերը հնարավոր են միայն այն դեպքում, երբ հարցման նախածանցը ճշգրիտ համընկնում է։ Քեշավորման առավելություններն իրացնելու համար ձեր հարցման սկզբում տեղադրեք ստատիկ բովանդակություն, ինչպես օրինակ՝ հրահանգներ և օրինակներ, իսկ փոփոխական բովանդակությունը, ինչպես օրինակ՝ օգտատիրոջը հատուկ տեղեկությունները, տեղադրեք վերջում։ Սա վերաբերում է նաև պատկերներին և գործիքներին, որոնք պետք է նույնական լինեն հարցումների միջև։

Սա հաշվի առնելով՝ դիտարկենք, թե ինչ տեսակի գործողությունները կարող են Codex-ում առաջացնել «քեշի բացթողում»։

  • Խոսակցության ընթացքում մոդելի համար հասանելի գործիքներ-ի փոփոխումը։
  • Փոխելով մոդել-ը, որը Պատասխանների API հարցման թիրախն է (գործնականում սա փոխում է սկզբնական հարցման երրորդ տարրը, քանի որ այն պարունակում է մոդելին հատուկ հրահանգներ)։
  • Սենդբոքսի կազմաձևի, հաստատման ռեժիմի կամ ընթացիկ աշխատանքային գրացուցակի փոփոխություն։

Codex թիմը պետք է զգոն լինի, երբ նոր հնարավորություններ են ներդրվում Codex CLI-ում, որոնք կարող են վտանգել հարցումների քեշավորումը։ Որպես օրինակ, մեր սկզբնական աջակցությունը MCP գործիքների համար ներկայացրեց սխալ, որի պատճառով մենք չկարողացանք գործիքները թվարկել հետևողական հերթականությամբ⁠(բացվում է նոր պատուհանում), ինչի հետևանքով առաջացան քեշի բացթողումներ։ Նկատի ունեցեք, որ MCP գործիքները կարող են հատկապես բարդ լինել, քանի որ MCP սերվերները կարող են թռուցիկ կերպով փոխել իրենց տրամադրած գործիքների ցանկը՝ notifications/tools/list_changed⁠(բացվում է նոր պատուհանում) ծանուցման միջոցով։ Երկար զրույցի ընթացքում այս ծանուցումը հաշվի առնելը կարող է հանգեցնել թանկարժեք քեշի բացթողման։

Հնարավորության դեպքում մենք զրույցի ընթացքում տեղի ունեցող կազմաձևման փոփոխությունները մշակում ենք՝ ավելացնելով նոր հաղորդագրություն ներածմանը՝ արտահայտելու փոփոխությունը, այլ ոչ թե փոփոխելով ավելի վաղ հաղորդագրությունը․

Մենք մեծ ջանքեր ենք գործադրում՝ կատարողականությունը բարձրացնելու համար քեշի հիթեր ապահովելու նպատակով։ Կա ևս մեկ կարևոր ռեսուրս, որը մենք պետք է կառավարենք՝ համատեքստի պատուհանը։

Մեր ընդհանուր ռազմավարությունը՝ համատեքստային պատուհանից դուրս չմնալու համար, այն է, որ կրճատենք զրույցը, երբ թոքենների քանակը գերազանցում է որոշակի շեմը։ Մասնավորապես, մենք փոխարինում ենք ներածում-ը նոր, ավելի փոքր տարրերի ցանկով, որը ներկայացնում է զրույցը՝ հնարավորություն տալով ագենտին շարունակել՝ հասկանալով, թե ինչ է տեղի ունեցել մինչ այդ։ Կրճատման վաղ իրականացումը⁠(բացվում է նոր պատուհանում) պահանջում էր, որ օգտատերը ձեռքով գործարկի /կրճատում հրամանը, որը կկատարեր հարցում Պատասխանների API-ին՝ օգտագործելով առկա զրույցը և ամփոփման⁠(բացվում է նոր պատուհանում) համար նախատեսված հատուկ հրահանգներ։ Codex-ն օգտագործեց ստացված օգնականի հաղորդագրությունը, որը պարունակում էր ամփոփագիրը որպես նոր ներածում⁠(բացվում է նոր պատուհանում) հետագա զրույցի փուլերի համար։

Դրանից հետո Պատասխանների API-ն զարգացել է՝ աջակցելու հատուկ /պատասխաններ/կոմպակտ վերջնակետին⁠(բացվում է նոր պատուհանում), որը կրճատումն իրականացնում է ավելի արդյունավետ կերպով։ Այն վերադարձնում է տարրերի ցանկը⁠(բացվում է նոր պատուհանում), որը կարող է օգտագործվել նախորդ ներածման փոխարեն՝ զրույցը շարունակելու համար՝ միաժամանակ ազատելով համատեքստային պատուհանը։ Այս ցանկը ներառում է հատուկ տեսակ=կրճատում տարր՝ անթափանց կոդավորված_բովանդակություն տարրով, որը պահպանում է մոդելի լատենտ ըմբռնումը սկզբնական զրույցի վերաբերյալ։ Այժմ Codex-ն ավտոմատ կերպով օգտագործում է այս վերջնակետը՝ զրույցը կրճատելու համար, երբ auto_compact_limit⁠(բացվում է նոր պատուհանում)-ը գերազանցվում է։

Հաջորդիվ

Մենք ներկայացրել ենք Codex-ի ագենտի ցիկլը և քննարկել, թե ինչպես է Codex-ը ձևավորում և կառավարում իր համատեքստը մոդելին հարցում կատարելիս։ Այս ընթացքում մենք ընդգծեցինք գործնական նկատառումները և լավագույն փորձերը, որոնք կիրառելի են բոլոր նրանց համար, ովքեր Պատասխանների API-ի վրա կառուցում են ագենտի ցիկլ։

Թեև ագենտի ցիկլը հիմք է Codex-ի համար, այն միայն սկիզբն է։ Առաջիկա գրառումներում մենք ավելի մանրամասն կճանաչենք CLI-ի ճարտարապետությունը, կուսումնասիրենք, թե ինչպես է իրականացվում գործիքների օգտագործումը, և ավելի մանրակրկիտ կդիտարկենք Codex-ի սենդբոքսի մոդելը։

Հեղինակ

Michael Bolin

Շնորհակալագրեր

Հատուկ շնորհակալություն ամբողջ թիմին, որը ստեղծեց Codex CLI-ն։

Շարունակել կարդալ

Դիտել բոլորը
Tax Agent > Art Card
Ինքնակատարելագործվող հարկային ագենտներ Codex-ով

Ճարտարագիտություն

codex windows > art card
Windows-ում Codex-ը գործարկելու համար անվտանգ, արդյունավետ sandbox-ի կառուցում

Ճարտարագիտություն

MRC 1_1
Որտեղից հայտնվեցին գոբլինները

Ճարտարագիտություն