4 փետրվարի, 2026 թ.

Codex-ի կապի բացում. ինչպես կառուցեցինք հավելվածների սերվերը

Սելիա Չեն, տեխնիկական անձնակազմի անդամ

Բեռնվում է…

OpenAI-ի կոդավորման ագենտ Codex-ը հասանելի է բազմաթիվ հարթակներում՝ վեբ հավելվածում⁠(բացվում է նոր պատուհանում), CLI-ում⁠(բացվում է նոր պատուհանում), IDE ընդլայնման մեջ⁠(բացվում է նոր պատուհանում) և Codex-ի նոր macOS հավելվածում։ Ներքին կառուցվածքում, դրանք բոլորը աշխատում են նույն Codex համակարգի միջոցով՝ ագենտ ցիկլը և տրամաբանությունը, որը հիմք է հանդիսանում Codex-ի բոլոր փորձառությունների համար։ Նրանց միջև եղած կարևոր կապը՞։ Codex App Server⁠(բացվում է նոր պատուհանում)-ը՝ հաճախորդի համար հարմար, երկկողմանի JSON-RPC API։

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

Հավելվածի սերվերի սկզբնաղբյուրը

Մինչ ճարտարապետության մեջ խորանալը, օգտակար է իմանալ App Server-ի նախապատմությունը։ Սկզբում App Server-ը գործնական միջոց էր՝ Codex harness-ը տարբեր արտադրանքների միջև վերօգտագործելու համար, որը աստիճանաբար զարգացավ և դարձավ մեր ստանդարտ արձանագրությունը։

Codex CLI-ն սկսվեց որպես TUI (տերմինալի օգտատիրոջ ինտերֆեյս), ինչը նշանակում է, որ Codex-ը հասանելի է տերմինալի միջոցով։ Երբ մենք ստեղծեցինք VS Code-ի ընդլայնումը (Codex ագենտների հետ փոխգործակցելու ավելի IDE-ին հարմար եղանակ), մեզ անհրաժեշտ էր նույն գործիքը օգտագործելու միջոց, որպեսզի IDE UI-ից կարողանանք վարել նույն ագենտի ցիկլը՝ առանց այն վերաիրականացնելու։ Դա նշանակում էր աջակցել հարցման/պատասխանի սահմաններից դուրս հարուստ փոխազդեցության օրինաչափությունների, ինչպիսիք են աշխատանքային տարածքի ուսումնասիրությունը, ագենտի կողմից պատճառաբանված առաջընթացի հոսքային հեռարձակումը և տարբերությունների արտահայումը։ Մենք սկզբում փորձարկեցինք Codex-ը որպես MCP սերվեր⁠(բացվում է նոր պատուհանում) ներկայացնելը, բայց VS Code-ի համար իմաստալից կերպով MCP-ի սեմանտիկան պահպանելը դժվար էր։ Փոխարենը, մենք ներդրեցինք JSON-RPC արձանագրություն, որը արտացոլում էր TUI ցիկլը և դարձավ App Server-ի ոչ պաշտոնական առաջին տարբերակը⁠(բացվում է նոր պատուհանում) ։ Այդ ժամանակ մենք չէինք ակնկալում, որ այլ հաճախորդներ կախված կլինեն App Server-ից, ուստի այն նախագծված չէր որպես կայուն API։

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

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

Codex հարթակի ներսում

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

1. Շարքի կյանքի ցիկլը և կայունությունը։ Շարքը Codex-ի զրույց է օգտատիրոջ և ագենտի միջև։ Codex-ը ստեղծում, վերսկսում, ստեղծում է կոդային բազայի պատճենը և արխիվացնում է շարքերը, ինչպես նաև պահպանում է իրադարձությունների պատմությունը, որպեսզի հաճախորդները կարողանան կրկին միանալ և ցուցադրել հետևողական ժամանակագիծ։

2. Կոնֆիգուրացիա և վավերացում։ Codex-ը բեռնում է կարգավորումը, կառավարում է լռելյայն կարգավորումները և գործարկում նույնականացման հոսքեր, ինչպիսիք են՝ «Մուտք գործել ChatGPT‑ով», ներառյալ հավատարմագրերի վիճակը։

3. Գործիքի գործարկում և ընդլայնումներ։ Codex-ը սենդբոքսում կատարում է shell/file գործիքները և միացնում է ինտեգրացիաներ, ինչպիսիք են MCP սերվերները և հմտությունները, որպեսզի դրանք կարողանան մասնակցել ագենտի ցիկլին՝ միասնական քաղաքականության մոդելի ներքո։

Այստեղ նշված ամբողջ ագենտի տրամաբանությունը, ներառյալ հիմնական ագենտի ցիկլը, գտնվում է Codex CLI կոդային բազայի մի հատվածում, որը կոչվում է «Codex core⁠(բացվում է նոր պատուհանում)» (Codex-ի միջուկ)։ Codex միջուկը և՛ գրադարան է, որտեղ գտնվում է ագենտի ամբողջ կոդը, և՛ գործարկման միջավայր, որը կարելի է գործարկել՝ ագենտի ցիկլը աշխատեցնելու և մեկ Codex շարք (զրույց) պահպանման կառավարումը իրականացնելու համար։

Օգտակար լինելու համար Codex-ի հարթակը պետք է հասանելի լինի հաճախորդներին։ Հենց այստեղ է գործի գալիս App Server-ը։

«Հավելվածի սերվերի գործընթացի հոսք» վերնագրով դիագրամ։ Հաճախորդը JSON-RPC հաղորդագրություններ է ուղարկում stdio reader-ին, որը հարցումները փոխանցում է Codex հաղորդագրությունների մշակիչին։ Պրոցեսորը փոխազդում է թեմաների կառավարչի և հիմնական թեմայի հետ որոնման թեմաների, թեմաների բռնակների, ներկայացված հարցումների և իրադարձությունների/թարմացումների միջոցով, այնուհետև պատասխանները վերադարձնում է հաճախորդին։

App Server-ը և՛ հաճախորդի և սերվերի միջև JSON-RPC արձանագրությունն է, և՛ երկարատև գործընթաց, որը հյուրընկալում է Codex-ի հիմնական շարքերը։ Ինչպես տեսնում ենք վերևի գծապատկերից, App Server գործընթացն ունի չորս հիմնական բաղադրիչ՝ stdio ընթերցիչը, Codex հաղորդագրությունների մշակիչը, շարքերի կառավարիչը և հիմնական շարքերը։ Շարքերի կառավարիչը յուրաքանչյուր շարի համար գործարկում է մեկ հիմնական աշխատաշրջան, իսկ Codex հաղորդագրությունների մշակիչը անմիջապես կապվում է յուրաքանչյուր հիմնական աշխատաշրջանի հետ՝ հաճախորդի հարցումները ներկայացնելու և թարմացումներ ստանալու համար։

Մեկ հաճախորդի հարցումը կարող է հանգեցնել բազմաթիվ իրադարձությունների թարմացումների, և հենց այս մանրամասն իրադարձություններն են, որոնք մեզ թույլ են տալիս կառուցել հարուստ UI App Server-ի վրա։ Բացի այդ, stdio ընթերցոիչը և Codex հաղորդագրությունների մշակիչը գործում են որպես թարգմանության շերտ հաճախորդի և Codex-ի հիմնական շաչքերի միջև։ Նրանք հաճախորդի JSON-RPC հարցումները վերածում են Codex միջուկի հիմնական գործողությունների, լսում են Codex միջուկի ներքին իրադարձությունների հոսքը, ապա այդ ցածր մակարդակի իրադարձությունները վերափոխում են կայուն, UI-ի համար պատրաստ JSON-RPC ծանուցումների փոքր հավաքածուի։

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

Զրույցի տարրերը

Հաջորդիվ, մենք կմանրամասնենք զրույցի տարրերը՝ App Server պրոտոկոլի կառուցվածքային բլոկները։ Ագենտի ցիկլի համար API նախագծելը դժվար է, քանի որ օգտատիրոջ/ագենտի փոխազդեցությունը պարզ հարցում/պատասխան չէ։ Մեկ օգտատիրոջ հարցումը կարող է վերածվել գործողությունների կառուցվածքային հաջորդականության, որը հաճախորդը պետք է հավատարիմ ներկայացնի՝ օգտատիրոջ մուտքագրումը, ագենտի աստիճանական առաջընթացը և ճանապարհին ստեղծված արտեֆակտները (օրինակ՝ տարբերություններ)։ Այդ փոխազդեցությունների հոսքը UI-ների միջև հեշտ ինտեգրվող և դիմացկուն դարձնելու համար մենք ընտրեցինք երեք հիմնական սկզբունքներ՝ հստակ սահմաններով և կյանքի ցիկլերով:

1. Տարր։ Տարրը Codex-ում մուտքագրման/ելքի հիմնական միավորն է։ Տարրերը տիպավորված են (օրինակ՝ օգտատիրոջ հաղորդագրություն, ագենտի հաղորդագրություն, գործիքի կատարում, հաստատման հարցում, տարբերություն) և յուրաքանչյուրն ունի հստակ կյանքի ցիկլ։

item/started երբ տարրը սկսվում է։
ըստ ցանկության item/*/delta իրադարձություններ՝ որպես բովանդակության հոսքեր (հոսքային տարրերի տեսակների համար)
item/completed երբ տարրը ավարտվում է իր վերջնական բեռնվածքով

Այս lifecycle-ը թույլ է տալիս հաճախորդներին անմիջապես սկսել ռենդեր անել started-ի ժամանակ, հոսքագրել ինկրեմենտալ թարմացումներ delta-ի ժամանակ և ավարտել completed-ի ժամանակ։

2. Պտույտ․ Պտույտը ագենտի աշխատանքի միավոր է, որը սկսվում է օգտատիրոջ մուտքագրմամբ։ Այն սկսվում է, երբ հաճախորդը ներկայացնում է մուտքագրում (օրինակ՝ «թեստեր կատարել և ձախողումները ամփոփել») և ավարտվում է, երբ ագենտը ավարտում է այդ մուտքագրման համար արդյունքներ արտադրելը։ Պտույտը պարունակում է տարրերի հաջորդականություն, որոնք ներկայացնում են միջանկյալ քայլերը և ճանապարհին ստացված արդյունքները։

3. Շարոց․ Շարոցը կայուն կոնտեյներ է օգտատիրոջ և ագենտի միջև ընթացիկ Codex աշխատաշրջանի համար։ Այն պարունակում է մի քանի պտույտներ։ Թեմաները կարող են ստեղծվել, վերսկսվել, ճյուղավորվել և արխիվացվել։ Թեմայի պատմությունը պահպանվում է, որպեսզի հաճախորդները կարողանան կրկին միանալ և ցուցադրել համահունչ ժամանակացույց։

Հիմա մենք կդիտարկենք հաճախորդի և ագենտի միջև պարզեցված զրույց, որտեղ զրույցը ներկայացված է պարզ տարրերով:

«Հաճախորդ-սերվեր արձանագրության հաղորդագրությունների հոսք. նախնականացման ձեռքսեղմում» անվանումով դիագրամ։« Հաճախորդը սերվերին ուղարկում է clientInfo-ով նախնականացման հարցում։ Սերվերը պատասխանում է արդյունքի իրադարձությամբ, որը պարունակում է userAgent տողը՝ «my_client/1.0»:

Զրույցի սկզբում հաճախորդը և սերվերը պետք է հաստատեն initialize ձեռքսեղմումը։ Հաճախորդը պետք է ուղարկի մեկ initialize հարցում՝ նախքան որևէ այլ մեթոդ, և սերվերը հաստատում է դա պատասխանով։ Սա սերվերին հնարավորություն է տալիս ներկայացնել իր հնարավորությունները և թույլ է տալիս երկու կողմերին համաձայնության գալ պրոտոկոլի տարբերակավորման, ֆունկցիոնալ դրոշակների և լռելյայն կարգավորումների շուրջ՝ նախքան իրական աշխատանքը սկսելը։ Ահա OpenAI-ի VS Code ընդլայնման օգտակար բեռնվածքի օրինակ.

JSON

1{
2  "method": "initialize",
3  "id": 0,
4  "params": {
5    "clientInfo": {
6      "name": "codex_vscode",
7      "title": "Codex VS Code Extension",
8      "version": "0.1.0"
9    }
10  }
11}

Սա է այն, ինչ վերադարձնում է սերվերը։

JSON

1{
2  "id": 0,
3  "result": {
4    "userAgent": "codex_vscode/0.94.0-alpha.7 (Mac OS 26.2.0; arm64) vscode/2.4.22 (codex_vscode; 0.1.0)"
5  }
6}

«Հաճախորդ-սերվեր արձանագրության հաղորդագրությունների հոսք. թեմայի և շրջադարձի կյանքի ցիկլ» վերնագրով դիագրամ։ Հաճախորդը սերվերին ուղարկում է thread/start և turn/start հարցումներ։ Սերվերը արձակում է իրադարձություններ՝ thread/started (մեկնարկեց թեման), turn/started (սկսվեց), item/started (մեկնարկեց տարրը) և item/complete (ավարտվեց տարրը)՝ ցույց տալով կատարման առաջընթացը, որի ընթացքում օգտատերը ստանում է հաղորդագրություն՝ «փորձարկումներ իրականացնելու և սխալները ամփոփելու» համար։

Երբ հաճախորդը նոր հարցում է կատարում, այն նախ կստեղծի շարք, ապա՝ հերթ։ Սերվերը հետ կուղարկի առաջընթացի ծանուցումներ (thread/started և turn/started): Այն նաև հետ կուղարկի այն մուտքագրումները, որոնք գրանցում է որպես տարրեր, ինչպես օգտատիրոջ հաղորդագրությունը այստեղ։

«Հաճախորդ-սերվեր արձանագրության հաղորդագրությունների հոսք՝ գործիքի կատարում՝ կամընտիր հաստատմամբ» վերնագրով դիագրամ։ Գործիքի կանչի ընթացքում սերվերը արձակում է item/started, ապա item/commandExecution/requestApproval՝ պատճառաբանությամբ («թեստեր անցկացնել»): Հաճախորդը վերադարձնում է հաստատման իրադարձություն (allow/deny)։ Այնուհետև սերվերը արտածում է item/completed՝ ցուցադրելով հրամանի կատարումը («pnpm test»):

Գործիքների կանչերը նույնպես վերադարձվում են հաճախորդին որպես տարրեր։ Բացի այդ, սերվերը կարող է հաճախորդից հաստատում խնդրել՝ նախքան սերվերի հարցում ուղարկելով գործողություն կատարելը։ Հաստատումը կդադարեցնի պտույտը, մինչև հաճախորդը պատասխանի կամ «թույլատրել», կամ «մերժել» տարբերակները։ Ահա թե ինչ տեսք ունի հաստատման հոսքը VS Code-ի ընդլայնման մեջ՝

Մուգ թեմատիկ ինտերֆեյսում թույլտվության հարցում՝ «Ցանկանո՞ւմ եք թույլ տալ ինձ գործարկել pnpm թեստը այս աշխատանքային տարածքի համար»։ Այն թվարկում է տարբերակներ՝ 1) Այո, 2) Այո և չհարցնել կրկին pnpm test-ով սկսվող հրամանների համար, և 3) Ոչ, ներքևում «Ուղարկել» կոճակով։

«Հաճախորդ-սերվերային պրոտոկոլի հաղորդագրությունների հոսք՝ հոսքային ագենտի հաղորդագրությունների հոսք» վերնագրով դիագրամ։ Սերվերը հոսքով ուղարկում է օգնականի հաղորդագրությունը մասերով՝ item/started, երկու agentMessage/delta իրադարձություն («ran 3 tests», «all passed»), ապա item/completed։ Հերթը ավարտվում է turn/completed հրահանգով։

Վերջում սերվերը ուղարկում է ագենտի հաղորդագրություն, ապա ավարտում է հերթը՝ turn/completed։ Ագենտի հաղորդագրության դելտա իրադարձությունների հոսքը հաղորդագրության մասերը հետ է ուղարկում, մինչև հաղորդագրությունը վերջնականացվի item/completed նշումով։

Դիագրամում հաղորդագրությունները պարզեցված են՝ ընթեռնելիության բարելավման համար։ Եթե ցանկանում եք տեսնել ամբողջական պտույտի JSON-ը, կարող եք գործարկել թեստային հաճախորդը Codex CLI-ի պահոցից՝

Bash

1codex debug app-server send-message-v2 "run tests and summarize failures"

Հաճախորդների հետ ինտեգրումը

Հիմա դիտարկենք, թե ինչպես են տարբեր հաճախորդային մակերեսներ Codex-ը ներդնում App Server-ի միջոցով։ Մենք կանդրադառնանք երեք օրինաչափության՝ տեղական հավելվածներ և IDE-ներ, Codex համացանցային runtime-ը և TUI-ն։

«Codex հաճախորդներ, որոնք ինտեգրված են Codex harness-ի հետ հավելվածի սերվերի միջոցով» վերնագրով դիագրամ։ Առաջին կողմի հաճախորդները (Codex Desktop App, TUI/CLI, Web Runtime) և երրորդ կողմի ինտեգրացիաները (JetBrains IDEs, VS Code, Xcode) հաղորդակցվում են Codex harness-ի հետ JSON-RPC կանչերի միջոցով։

Բոլոր երեքի դեպքում փոխադրումը կատարվում է JSON-RPC-ով stdio-ի միջոցով (JSONL): JSON-RPC-ը հեշտացնում է հաճախորդի կապակցումների ստեղծումը ձեր ընտրած լեզվով։ Codex մակերեսները և գործընկերային ինտեգրումները իրականացրել են App Server հաճախորդներ՝ Go, Python, TypeScript, Swift և Kotlin լեզուներով։ TypeScript-ի համար դուք կարող եք սահմանումները ստեղծել անմիջապես Rust պրոտոկոլից՝ գործարկելով՝

Bash

1codex app-server generate-ts

Այլ լեզուների համար կարող եք գեներացնել JSON սխեմա փաթեթ և այն փոխանցել ձեր նախընտրած կոդի գեներատորին՝ գործարկելով:

Bash

1codex app-server generate-json-schema

Տեղական հավելվածներ և IDE-ներ

VS Code-ի էկրանի նկար՝ գործարկված Codex ընդլայնմամբ։ Բաց է Rust թեստի ֆայլը, և դրա տակ Codex վահանակը նկարագրում է fmt և cargo test -p codex-app-server հրամանների կատարումը՝ հաղորդելով, որ ձևաչափումը և թեստերը ընթացքի մեջ են՝ վերջնական հաջողության/ձախողման արդյունքի սպասման ընթացքում։

Տեղական հաճախորդները սովորաբար փաթեթավորում կամ ներբեռնում են հարթակին հատուկ App Server-ի բինարը, այն գործարկում են որպես երկարատև ենթական գործընթաց և JSON-RPC-ի համար բաց են պահում երկկողմանի stdio ալիքը։ Օրինակ, մեր VS Code-ի ընդլայնման և աշխատասեղանի հավելվածում առաքվող արտեֆակտը ներառում է հարթակին հատուկ Codex բինարը և ամրագրված է փորձարկված տարբերակին, որպեսզի հաճախորդը միշտ գործարկի հենց այն նույն բիթերը, որոնք մենք հաստատել ենք։

Ոչ բոլոր ինտեգրումները կարող են հաճախակի հաճախորդի թարմացումներ թողարկել։ Որոշ գործընկերներ, ինչպես Xcode-ը, տարանջատում են թողարկման ցիկլերը՝ հաճախորդին կայուն պահելով և անհրաժեշտության դեպքում թույլ տալով, որ այն մատնանշի ավելի նոր App Server-ի բինարը։ Այդ կերպ նրանք կարող են ընդունել սերվերային բարելավումները (օրինակ՝ Codex core-ում ավելի լավ ավտոմատ կոմպակտացում կամ նոր աջակցվող կոնֆիգուրացիոն բանալիներ) և տարածել սխալների շտկումները՝ առանց հաճախորդի թողարկմանը սպասելու։ App Server-ի JSON-RPC մակերեսը նախագծված է հետադարձ համատեղելի լինելու համար, որպեսզի հին հաճախորդները կարողանան անվտանգ հաղորդակցվել նոր սերվերների հետ։

Codex Web

Codex վեբ ինտերֆեյսի սքրինշոթ, որը ցույց է տալիս «Մուտքի հաջողության հաղորդագրության թարմացում» վերնագրով թարմացում։ Ձախ վահանակը ամփոփում է փոփոխությունները, թեստերը և փոփոխված ֆայլերը, իսկ աջ վահանակը ցուցադրում է login.rs ֆայլի կոդի տարբերությունը՝ մուտքի հաջողության հաղորդագրության ձևակերպման թարմացմամբ։

Codex Web-ը օգտագործում է Codex harness-ը, բայց այն գործարկում է կոնտեյներային միջավայրում։ Աշխատողը նախապատրաստում է կոնտեյները ստուգված աշխատատարածքով, գործարկում է App Server-ի բինարը դրա ներսում և պահպանում է երկարատև JSON-RPC կապը stdio² ալիքով։ Վեբ հավելվածը (աշխատում է օգտատիրոջ բրաուզերի ներդիրում) HTTP և SSE-ի միջոցով կապ է հաստատում Codex-ի բեքենդի հետ, որը հոսքով փոխանցում է աշխատողի կողմից ստեղծված առաջադրանքի իրադարձությունները։ Սա պահպանում է դիտարկչի կողմի UI-ը թեթև՝ միաժամանակ ապահովելով մեզ համար հետևողական գործարկման միջավայր՝ աշխատասեղանի և համացանցի համար։

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

TUI/Codex CLI

Տերմինալի սքրինշոթ, որտեղ աշխատում է Codex CLI-ն. Այն ցույց է տալիս OpenAI Codex-ի պաստառը՝ gpt-5.2-codex մոդել։ մեջտեղում, օգտատիրոջ «explain app server to me» հրամանը և «Working» կարգավիճակը։ Ստորև առաջարկ է հայտնվում՝ «գրել թեստեր @filename-ի համար», դյուրանցումների տարբերակներով։

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

Այժմ, երբ App Server-ը գոյություն ունի, մենք նախատեսում ենք վերակազմակերպել TUI-ն⁠(բացվում է նոր պատուհանում) ՝ այն օգտագործելու համար, որպեսզի այն գործի ինչպես ցանկացած այլ հաճախորդ՝ գործարկելով App Server-ի դուստր գործընթացը, stdio-ի միջոցով խոսելով JSON-RPC և արտապատկերելով նույն հոսքային իրադարձություններն ու հաստատումները։ Սա բացում է աշխատանքային հոսքեր, որտեղ TUI-ն կարող է միանալ հեռավոր մեքենայի վրա աշխատող Codex սերվերին՝ պահելով ագենտը հաշվարկային ռեսուրսներին մոտ և շարունակելով աշխատանքը նույնիսկ եթե նոութբուքը քնի կամ անջատվի, միաժամանակ տեղում ապահովելով կենդանի թարմացումներ և վերահսկման գործիքներ։

Ճիշտ պրոտոկոլի ընտրություն

Codex App Server-ը կլինի առաջին կարգի ինտեգրման մեթոդը, որը մենք կպահպանենք ապագայում, բայց կան նաև այլ մեթոդներ՝ ավելի սահմանափակ գործառույթներով։ Լռելյայն, մենք խորհուրդ ենք տալիս հաճախորդներին օգտագործել Codex App Server-ը Codex-ի հետ ինտեգրվելու համար, սակայն արժե ուսումնասիրել ինտեգրման տարբեր մեթոդները և հասկանալ դրանց առավելություններն ու թերությունները։ Ստորև ներկայացված են Codex-ը գործարկելու ամենատարածված եղանակները և թե երբ դրանք կարող են հարմար լինել։

JSON-RPC արձանագրություններ

Codex-ը որպես MCP սերվեր

Գործարկեք codex mcp-server⁠(բացվում է նոր պատուհանում) և կապ հաստատեք ցանկացած MCP հաճախորդից, որը աջակցում է stdio սերվերներին (օրինակ՝ OpenAI Agents SDK⁠(բացվում է նոր պատուհանում)): Սա հարմար տարբերակ է, եթե դուք արդեն ունեք MCP-ի վրա հիմնված աշխատանքային հոսք և ցանկանում եք Codex-ը օգտագործել որպես կանչելի գործիք։ Թերությունն այն է, որ դուք ստանում եք միայն այն, ինչ MCP-ն է բացահայտում, ուստի Codex-ին հատուկ փոխազդեցությունները, որոնք հիմնվում են ավելի հարուստ սեսիայի սեմանտիկայի վրա (օրինակ՝ diff թարմացումներ), կարող են MCP վերջնակետերի միջոցով հստակ չհամապատասխանել։

Մատակարարների միջև ագենտի կապի պրոտոկոլներ

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

Codex հավելվածի սերվեր

Ընտրեք App Server-ը, երբ ցանկանում եք, որ Codex-ի ամբողջական հարթակը բացահայտվի որպես կայուն, UI-ին հարմար իրադարձությունների հոսք։ Դուք ստանում եք թե՛ ագենտի ցիկլի ամբողջական գործառույթները, թե՛ այլ աջակցող հնարավորություններ, ինչպիսիք են «Մուտք գործել ChatGPT‑ով», մոդելի հայտնաբերումը և կազմաձևման կառավարումը։ Հիմնական ծախսը ինտեգրման աշխատանքն է, քանի որ դուք պետք է ձեր լեզվով կառուցեք հաճախորդի կողմի JSON-RPC կապակցումը։ Գործնականում, սակայն, Codex-ը կարող է կատարել ծանր աշխատանքի մեծ մասը, եթե նրան տրամադրեք JSON սխեման և փաստաթղթավորումը։ Շատ թիմեր, որոնց հետ մենք աշխատել ենք, կարողացան Codex-ի միջոցով արագ իրականացնել աշխատող ինտեգրում։

Codex-ը ներդնելու այլ միջոցներ

Codex Exec⁠(բացվում է նոր պատուհանում)

Թեթև, սկրիպտավորվող CLI ռեժիմ՝ մեկանգամյա առաջադրանքների և CI գործարկումների համար։ Այն հարմար է ավտոմատացման և խողովակաշարերի համար, երբ անհրաժեշտ է, որ մեկ հրաման գործարկվի մինչև ավարտ՝ առանց միջամտության, տրամադրի կառուցվածքային արդյունքներ լոգերի համար և ավարտվի հստակ հաջողության կամ ձախողման ազդանշանով։

Codex SDK⁠(բացվում է նոր պատուհանում)

TypeScript գրադարան՝ ձեր սեփական հավելվածի ներսից ծրագրային եղանակով տեղական Codex ագենտներին կառավարելու համար։ Ամենալավն է, երբ ցանկանում եք սերվերային գործիքների և աշխատանքային հոսքերի համար բնիկ գրադարանի ինտերֆեյս՝ առանց առանձին JSON-RPC հաճախորդ կառուցելու։ Քանի որ այն թողարկվել է ավելի վաղ, քան App Server-ը, ներկայումս այն աջակցում է ավելի քիչ լեզուների և ունի ավելի փոքր ֆունկցիոնալ ծավալ։ Եթե ծրագրավորողների հետաքրքրություն լինի, մենք կարող ենք ավելացնել լրացուցիչ SDK-ներ, որոնք փաթեթավորում են App Server-ի պրոտոկոլը, որպեսզի թիմերը կարողանան ծածկել harness-ի մակերեսի ավելի մեծ մասը՝ առանց JSON-RPC կապերի գրելու։

Շարունակելով սա

Այս գրառման մեջ մենք ներկայացրեցինք, թե ինչպես ենք մոտենում գործակալների հետ փոխազդելու նոր ստանդարտի նախագծմանը և ինչպես Codex-ի հառնեսը դարձնել կայուն, հաճախորդամետ պրոտոկոլ։ Մենք քննարկեցինք, թե ինչպես է App Server-ը բացահայտում Codex-ի միջուկը, թույլ տալիս հաճախորդներին վարել ագենտի ամբողջական ցիկլը և ապահովում է մակերեսների լայն շրջանակ, ներառյալ TUI-ը, տեղական IDE ինտեգրացիաները և վեբ runtime-ը։

Եթե սա գաղափարներ առաջացրեց Codex-ը ձեր սեփական աշխատանքային հոսքերում ինտեգրելու համար, արժե փորձել App Server-ը։ Ամբողջ սկզբնաղբյուրի կոդը գտնվում է Codex CLI-ի բաց կոդով պահոցում⁠(բացվում է նոր պատուհանում)։ Ազատորեն կիսվեք ձեր կարծիքով և գործառույթների հարցումներով։ Մենք ոգևորված ենք լսել ձեզանից և շարունակել ապահովել, որ ագենտները ավելի հասանելի լինեն բոլորի համար։

Հեղինակ

Celia Chen

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

Հատուկ շնորհակալություն Մայքլ Բոլինին, Օուեն Լինին, Էրիկ Տրաուտին և Ռասմուս Ռյուգարդին, ովքեր նպաստել են այս գրառմանը, ինչպես նաև ամբողջ Codex թիմին, որը աշխատել է App Server-ի վրա։

Ծանոթագրություններ

1
Մենք օգտագործում ենք «JSON‑RPC lite» տարբերակը՝ այն պահպանում է հարցման/պատասխանի/ծանուցման կառուցվածքը, բայց բաց է թողնում "jsonrpc": "2.0" ": վերնագիրն ու ձևակերպված է որպես JSONL՝ stdio-ի միջոցով, այլ ոչ թե խիստ JSON‑RPC 2.0։
2
«stdio»-ն վերաբերում է հավելվածի սերվերի stdin/stdout-ին կոնտեյների ներսում։ Հոսթինգի կարգավորումներում, այդ հոսքերը հաճախ թունելավորվում են կայուն ցանցային կապի միջոցով (օրինակ՝ WebSocket-ի նման) դեպի կոնտեյների runtime, այնպես որ այն գործում է ինչպես stdio, նույնիսկ եթե դա բառացիորեն տեղական խողովակ չէ։

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

Դիտել բոլորը

Ինքնակատարելագործվող հարկային ագենտներ Codex-ով

Ճարտարագիտություն27 մյս, 2026 թ.

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

Ճարտարագիտություն13 մյս, 2026 թ.

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

Ճարտարագիտություն5 մյս, 2026 թ.