ავტონომიური კოდის განხილვა ოთხი AI-აგენტით: 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-ს კი ტესტების განახლებას და სიმბოლური ბმულების გადაწყვეტისთვის უსაფრთხოების ახალი ტესტის დამატებას. ციკლი stateful ჩატში მიმდინარეობს: ეს შეტყობინებების საერთო სიაა, რომელსაც ყველა აგენტი კითხულობს და ავსებს, ორკესტრატორი კი რიგს Planner-ის მითითებებით მართავს.

ავტორი სარგებელს ჩამოთვლის: უფრო ღრმა ანალიზი, ადამიანის ზედამხედველობის ნაკლები საჭიროება, დიზაინის გადაწყვეტილებების ავტომატური დოკუმენტაცია ჩატის ჟურნალში და სტატიკური ანალიზის ჩაშენების მარტივი გზა. მოდელი მასშტაბირდება: შეიძლება DevOps ან Doc აგენტის დამატება კონტეინერიზაციისა და დოკუმენტაციისთვის.