Վերադառնալ
Բազմագործակալ համակարգ՝ կոդի ինքնավար վերանայման համար. Planner, Implementer, Tester, Critic
SiTech AI Team2 წთ. საკითხავი

Բազմագործակալ համակարգ՝ կոդի ինքնավար վերանայման համար. Planner, Implementer, Tester, Critic

Գործնական ուղեցույցը ցույց է տալիս, թե ինչպես են Planner, Implementer, Tester և Critic չորս մասնագիտացված գործակալները մեկ ընդհանուր չաթում քննարկում, թեստավորում և համաձայնեցնում կոդի ուղղումները։

Ծրագրավորողների TormentNexus բլոգը հրապարակել է բազմագործակալ համակարգի գործնական ուղեցույց, որը կոդը ինքնավար է վերանայում։ Հոդվածը սեպտեմբերի 26-ին հրապարակվել է Dev.to-ում։ Հեղինակի պնդմամբ՝ մեկ AI օգնականին պակասում են հասուն ինժեներական թիմի ստուգումներն ու հավասարակշռությունը. առաջարկները չեն ստուգվում, ուղղումները չեն թեստավորվում կողմնակի ազդեցությունների համար, իսկ դիզայնի հետևանքները հազվադեպ են քննարկվում։

Ինչու մեկ օգնականը բավարար չէ

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

Չորս դերերը համակարգում

Յուրաքանչյուր գործակալ առանձին LLM կանչ է՝ իր system prompt-ով։ Planner-ը տեխնիկական ղեկավարի դերում է. վերլուծում է կոդը և կազմում վերանայման օրակարգ՝ անվտանգության, արտադրողականության և ընթեռնելիության շուրջ։ Implementer-ը գրում է կոնկրետ ուղղումը կամ ռեֆակտորինգը։ Tester-ը ստուգում է փոփոխությունները unit և ինտեգրացիոն թեստերով ու անվտանգության սկաներով։ Critic-ը կասկածի տակ է դնում ենթադրությունները, վիճարկում ճարտարապետությունը և ստուգում պահպանելիությունը։

Օրինակ՝ կոնֆիգուրացիայի բեռնիչի ամրապնդում

Օրինակում կարճ Python ֆունկցիա է՝ YAML կոնֆիգուրացիա կարդալու և տվյալների բազայի բաժինը վերադարձնելու համար։ Planner-ը սահմանում է օրակարգը. վերլուծել անվտանգության ռիսկերը՝ path traversal-ը և տվյալների վստահությունը, բարելավել սխալների մշակումը բացակայող բանալիների և անվավեր YAML-ի համար, ապա գնահատել դիզայնը։ Implementer-ը ավելացնում է try/except բլոկներ՝ պարզ ValueError հաղորդագրություններով, իսկ Tester-ը pytest փաթեթ է գրում նոր սխալների ուղիների համար։

Critic-ը ավելի շատ է առարկում, քան ընդունում։ Միայն config['database']-ի վերադարձը նա անվանում է հակաօրինաչափություն, որը թաքցնում է կոնֆիգուրացիայի ամբողջ համատեքստը, և մատնանշում TOCTOU ռիսկը. ֆայլի ուղին կարող է փոխվել ստուգման և օգտագործման միջև։ Նրա խորհուրդն է վերադարձնել ամբողջ config-ը և բացելուց առաջ լուծել սիմվոլիկ հղումները os.path.realpath-ով։

Կոնսենսուս և նվագախմբում

Երբ Implementer-ը և Critic-ը չեն համաձայնում, վճռում է Planner-ը։ Օրինակում նա հանձնարարում է Implementer-ին վերադարձնել ամբողջ config-ը, իսկ Tester-ին՝ թարմացնել թեստերը և ավելացնել սիմվոլիկ հղումների անվտանգության թեստ։ Ցիկլը ընթանում է վիճակով չաթում. դա ընդհանուր հաղորդագրությունների ցանկ է, որը բոլոր գործակալները կարդում և լրացնում են, իսկ նվագախմբիչը հերթը կառավարում է Planner-ի հրահանգներով։

Հեղինակը թվարկում է օգուտները. ավելի խորը վերլուծություն, մարդու վերահսկողության փոքր կարիք, դիզայնի որոշումների ավտոմատ փաստաթղթավորում չաթի մատյանում և ստատիկ վերլուծությունը հոսքին միացնելու հեշտ ուղի։ Մոդելը ընդլայնելի է. կարելի է ավելացնել DevOps կամ Doc գործակալ՝ կոնտեյներացման և փաստաթղթերի համար։

SSiTech

SiTech — AI-ով հզորացված վեբ մշակում

Ստեղծում ենք արագ ու ժամանակակից կայքեր և AI-ը ներդնում իրական բիզնես գործընթացներում։ Ունե՞ք նախագիծ կամ հարց։ Ուրախ կլինենք օգնել։