Ծրագրային ապահովման մշակման ոլորտում Բազմագործակալային համակարգերի (Multi-Agent Systems - MAS) շուրջ ներկայիս ոգևորությունը տեսանելի է։ Մենք արագորեն անցում ենք կատարել LLM-ների հետ պարզ, մեկ հարցման վրա հիմնված փոխգործակցությունից դեպի բարդ էկոհամակարգեր, որտեղ մասնագիտացված գործակալներ՝ ճարտարապետներ, ծրագրավորողներ, թեստավորողներ և անվտանգության փորձագետներ, համագործակցում են ինժեներական խճճված խնդիրներ լուծելու համար։ Այնուամենայնիվ, քանի որ այս համակարգերը մասշտաբավորվում են, ավագ ինժեներական ղեկավարները նկատում են կրկնվող մի օրինաչափություն. նախագծերը կանգ են առնում, գործառույթները շեղվում են, և կուտակվում է տեխնիկական պարտք, նույնիսկ երբ հիմքում ընկած մոդելները բարձր մակարդակով են աշխատում։

Խնդիրը գործակալների միջև լեզվի կամ հաղորդակցության ձախողումը չէ։ Ավելի շուտ, դա վիճակի կառավարման (state management) ձախողումն է։ Մենք ինքնավար գործակալներին վերաբերվում ենք որպես խորհրդակցությունների սենյակում զրուցող մարդ-խորհրդատուների, սակայն անտեսում ենք այն «կորպորատիվ գրառումները», որոնք անհրաժեշտ են այդ քննարկումները հուսալի, երկարաժամկետ տեխնիկական ենթակառուցվածքի վերածելու համար։ Փորձարարական փուլից դուրս գալու համար ձեռնարկությունները պետք է իրենց ուշադրությունը զուտ խոսակցական արդյունքներից տեղափոխեն դեպի պաշտոնական Պարտավորությունների շերտի (Commitment Layer) ներդրում։

Հեղուկ համագործակցության պատրանքը

Ներկայիս բազմագործակալային ճարտարապետությունների մեծ մասում գործակալները գործում են առանց վիճակի (stateless), կարճատև ցիկլերով։ «Ճարտարապետ գործակալը» առաջարկում է տվյալների բազայի սխեմա, «Ծրագրավորող գործակալը» գրում է իրականացումը, իսկ «Գրախոս գործակալը» հաստատում է այն։ Եթե վերանայման գործընթացը ներառում է բարդ փոխզիջում՝ օրինակ՝ բաշխված համակարգում հետևողականության և հասանելիության միջև ընտրություն կատարելը, գործակալները զրույցի ընթացքում կարող են հանգել խելամիտ որոշման։ Սակայն, հենց զրույցն ավարտվում է, այդ երկխոսության ընթացքում ձեռք բերված կոնկրետ սահմանափակումները, ճարտարապետական հրամայականները և «ջենտլմենական համաձայնությունները» անհետանում են հաջորդ հարցման նշանների (token) պատուհանում։

Բիզնեսի համար սա վտանգավոր նեղուց է։ Եթե գործակալը պարտավորվում է կատարել կոնկրետ API պայմանագիր կամ անվտանգության արձանագրություն, այդ պարտավորությունը պետք է դրոշմված լինի համակարգի «ճշմարտության աղբյուրում» (source of truth), այլ ոչ թե թաքնված լինի զրույցի պատմության մեջ։ Առանց այս պարտավորությունները գրանցելու, հետևելու և պարտադրելու կառուցվածքային եղանակի՝ ծրագրային ապահովման մշակման կենսացիկլը (SDLC) հակված է «շեղումների», երբ հավելվածի տարբեր մասերը լուռ և աննկատ հեռանում են նախնական նախագծային մտահղացումից։

Հենց այստեղ է բիզնեսի վրա ազդեցությունը դառնում չափելի։ Ավտոմատացված աշխատանքային հոսքերում մեծ ներդրումներ կատարող ընկերությունները հաճախ սկզբնական փուլում տեսնում են բարձր արագություն, որը նվազում է, երբ ծրագրային կոդը դառնում է անկառավարելի։ Երբ գործակալները չունեն հիշողության մեխանիզմ, որը պարտադրում է մոդուլների միջև համապատասխանություն, ավտոմատացման ներդրումների եկամտաբերությունը (ROI) նվազում է, քանի որ մարդ-ծրագրավորողները ստիպված են լինում միջամտել և կատարել «դատաբժշկական վրիպազերծում» (forensic debugging)՝ պարզելու համար, թե ինչու է գործակալի կողմից գրված մոդուլը հակասում երեք սպրինտ առաջ ընդունված նախագծային որոշմանը։

«Պարտավորությունն առաջին հերթին» աշխատանքային հոսքի նախագծում

Սա լուծելու համար մենք պետք է խոսակցական կազմակերպումից անցում կատարենք Դեկլարատիվ վիճակի պահպանման (Declarative State Persistence)։ Պարտավորությունների շերտն ըստ էության կամուրջ է LLM-ների հեղուկ, հավանականային աշխարհի և ծրագրային ինժեներական գործիքների դետերմինիստական, կոշտ աշխարհի միջև։ Այն գործում է որպես միջնորդ ծրագիր (middleware), որը ստիպում է գործակալներին «ստորագրել» իրենց արդյունքները կառուցվածքային տվյալների բազայում կամ տարբերակներով կառավարվող ռեեստրում։

Պարտավորությունների հուսալի շերտը պետք է ունենա հետևյալ բնութագրերը՝ ձեռնարկատիրական մակարդակի կայունություն ապահովելու համար.

  • Իմաստային պայմանագրերի ռեեստր (Semantic Contract Registry). Բնական լեզվով հրահանգներին ապավինելու փոխարեն՝ գործակալները պետք է թարմացնեն մեքենայաընթեռնելի սխեման (օրինակ՝ JSON Schema կամ Protobuf), որը ծառայում է որպես պարտադիր պայմանագիր հետագա բոլոր մոդուլների համար։
  • Որոշումների տարբերակված մատյաններ (Versioned Decision Logs). Գործակալի կողմից կատարված յուրաքանչյուր փոխզիջում պետք է գրանցվի որպես անփոփոխելի մատյանի գրառում։ Սա թույլ է տալիս իրականացնել աուդիտ և ապագա գործակալներին տալիս է «համատեքստային պատուհան»՝ հասկանալու, թե ինչու է կայացվել կոնկրետ որոշումը, այլ ոչ թե պարզապես ինչ է որոշվել։
  • Սահմանափակումների կիրառման մեխանիզմներ (Constraint Enforcement Hooks). Պարտավորությունների շերտը պետք է գործի որպես դարպասապահ։ Եթե գործակալը փորձում է գրել կոդ, որը խախտում է նախկինում ստանձնած սահմանափակումը՝ օրինակ՝ անվտանգության հրամայականը կամ տվյալների տեղակայման պահանջը, համակարգը պետք է գործարկի մերժում կամ պարտադիր մարդկային միջամտություն։
  • Երկկողմանի համաժամացում CRM-ի և նախագծերի կառավարման գործիքների հետ. Թվային փոխակերպման ավելի լայն ջանքերի համար այս պարտավորությունները չպետք է գոյություն ունենան մեկուսացված։ Դրանք պետք է կապված լինեն բիզնես տրամաբանության հետ, ինչպիսիք են CRM պահանջների կամ նախագծերի ճանապարհային քարտեզների իրական ժամանակում թարմացումը՝ ապահովելով, որ տեխնիկական իրագործումը