რა არის კომპიუტერის გამოყენება და რატომ არის ის მნიშვნელოვანი? კომპიუტერის გამოყენება მარტივი იდეაა, რომელსაც ფართო გავლენა აქვს: იმის ნაცვლად, რომ მოდელებს კითხვებზე პასუხი მოვთხოვოთ, მათ პროგრამული უზრუნველყოფის მართვას ვავალებთ — ვებსაიტებზე გადაადგილებას, ფორმების შევსებას, პროცესების ეტაპობრივ გავლასა და ამოცანების თავიდან ბოლომდე ავტონომიურად შესრულებას.
ეს შესაძლებელს ხდის რეალური სამყაროს ამოცანათა ფართო კლასის შესრულებას, რომლებიც დღეს სხვადასხვა ინტერფეისშია დანაწევრებული: სრულ დაჯავშნას, ონლაინშესყიდვის დასრულებას, მოგზაურობის მრავალეტაპიან დაგეგმვასა და შიდა საოპერაციო პროცესებს, რომლებსაც API-ის სრულფასოვანი ანალოგი არ აქვს. ეს პრობლემები ახალი არ არის. ახალი ისაა, რომ მათი გადაჭრა ზოგადი დანიშნულების მოდელებით უკვე რეალურად შესაძლებელია.
Anthropic-ისა და OpenAI-ის უახლესმა სისტემებმა წარმოაჩინა აგენტები, რომლებიც არა მხოლოდ მოქმედებენ, არამედ მდგომარეობაზე მსჯელობენ, შეცდომების შემდეგ მუშაობას აღადგენენ და კონკრეტული ამოცანისთვის გადაწყვეტებს უშუალოდ პროცესში ქმნიან. ეს ბრაუზერს აგენტებისთვის ზოგად საშემსრულებლო გარემოდ აქცევს, თუმცა დაუყოვნებლივ აჩენს საპროექტო კითხვას: ამ გარემოს რა ნაწილი უნდა გავუხსნათ მოდელს?
ადრეულ სისტემებში ბრაუზერს უსაფრთხო, წინასწარ განსაზღვრული მოქმედებების ფიქსირებულ ნაკრებში აქცევდნენ. როგორც ამ სტატიაში დავასაბუთებთ, ეს მიდგომა საკუთარ ზღვარს უახლოვდება.
ბრაუზერის აგენტების შექმნისას ჩვეული ინსტინქტი იჩენს თავს: მოდელს ზედმეტად არ ენდოთ.
ამიტომ ბრაუზერს გარსში ვაქცევთ. ვთავაზობთ წინასწარ განსაზღვრულ ხელსაწყოებს, როგორიცაა click, type, scroll, select და read_text. ვამარტივებთ დოკუმენტის ობიექტურ მოდელს (DOM). ვამცირებთ შესაძლო მოქმედებების სივრცეს. ჩვენს მიერ შექმნილი აბსტრაქციებით ვცდილობთ, ქცევა გასაგები და მართვადი გავხადოთ.
ეს გონივრული საწყისი მიდგომაა. ამავე დროს, ის სულ უფრო მეტად იქცევა არასწორ გრძელვადიან არქიტექტურად.
მოწინავე მოდელების გაუმჯობესებასთან ერთად პრობლემა მხოლოდ ხელსაწყოების ნაკლებობა აღარ არის. პრობლემა ისაა, რომ მოდელს ვაიძულებთ იმუშაოს აბსტრაქციებით, რომლებიც საფუძვლად არსებული სისტემის ზედმეტად დიდ ნაწილს მალავს. რთულ, დინამიკურ გარემოს მოქმედებების ფიქსირებულ ინტერფეისამდე ვკუმშავთ და შემდეგ მოდელს ვთხოვთ, ინფორმაციის ასეთი დანაკარგის პირობებში კარგად იმუშაოს.
ეს კომპრომისი სულ უფრო ნაკლებად მიმზიდველი ხდება.
ცვლილება, რომელსაც ვიკვლევთ, მარტივად აღსაწერია, თუმცა მნიშვნელოვანი შედეგები აქვს. იმის ნაცვლად, რომ აგენტი წინასწარ განსაზღვრული მოქმედებების ამრჩევად მივიჩნიოთ, მას განვიხილავთ პროგრამის შემქმნელად, რომელიც შეზღუდულ საშემსრულებლო გარემოში მოქმედებს.
მოდელები ძალიან დაიხვეწა და თქვენი აბსტრაქტული დამცავი საზღვრები აღარ სჭირდება — მათ მოქმედებების სრული სივრცე სჭირდებათ, რათა ამოცანის გადაწყვეტა დაგეგმონ, შეასრულონ და დახვეწონ, სანამ მიზანს არ მიაღწევენ.
ეს სტატია სწორედ ამ ცვლილებას ეხება — აბსტრაქციებით დატვირთული ბრაუზერის ავტომატიზაციიდან კომპიუტერის შეზღუდულ გამოყენებაზე გადასვლას და იმას, თუ რა იცვლება სისტემების ამგვარად დაპროექტებისას.
პრობლემა ის არ არის, რომ მოქმედებების ფიქსირებული ინტერფეისები კონცეპტუალურად მცდარია. პრობლემა ისაა, რომ ვები მათ წესებს არ ემორჩილება.
თანამედროვე ინტერფეისები აგებულია React-ზე, Vue-სა და Angular-ზე; მათ ახასიათებს მდგომარეობის ასინქრონული განახლებები, სინთეზური მოვლენების სისტემები და მესამე მხარის ჩაშენებული ვიჯეტები, რომლებიც სხვადასხვა წყაროს iframe-ებში საკუთარი სასიცოცხლო ციკლით მუშაობს. გარსი, რომელიც ამბობს „ამ ველში აკრიფე“, მხოლოდ მაშინ მუშაობს სწორად, თუ გვერდი აკრეფის თქვენეულ განმარტებას ეთანხმება. ბევრი გვერდი არ ეთანხმება. მნიშვნელობის პირდაპირ მინიჭება ხშირად სრულად უვლის გვერდს ფრეიმვორკის ცვლილებათა აღმოჩენის მექანიზმს. ველი შევსებული ჩანს. შემოწმება საერთოდ არ იწყება. ფორმა კვლავ გაუმართავია.
ამის გამოსწორება დროებითი პატჩით შეგიძლიათ. შეგიძლიათ დაამატოთ განსაკუთრებული შემთხვევები React-ის ველებისთვის, ფოკუსირების შემდეგ blur მოვლენები გაგზავნოთ და მდგომარეობის წაკითხვამდე ქსელის უმოქმედობას დაელოდოთ. თითოეული პატჩი ცალკე აღებული სწორია. ერთად კი ისინი ქმნის სისტემას, რომლის მოვლაც სულ უფრო რთულდება და რომელიც სულ უფრო მეტადაა მორგებული უკვე ნანახ საიტებზე.
უფრო ღრმა პრობლემა ისაა, რომ ურთიერთქმედების წესების შესახებ ვარაუდებს აბსტრაქციის შრეში ამაგრებთ, შემდეგ კი აღმოაჩენთ, რომ ვებს სხვა წესები აქვს.
განვიხილოთ Stripe-ის ან Adyen-ის მეშვეობით სხვადასხვა წყაროს iframe-ში ჩაშენებული გადახდის ფორმა. თქვენი გარსი მას პირდაპირ ვერ წვდება, რადგან ის ცალკე წყაროში მდებარეობს. თქვენი read_text ხელსაწყო მის შიდა მდგომარეობას ვერ ხედავს. თქვენი type ხელსაწყო მის ველებს ვერ მიმართავს. გარსზე დაფუძნებული აგენტი აქ ჩიხში ექცევა. აბსტრაქცია მთავარი დოკუმენტისთვის იყო შექმნილი. რეალური ამოცანა კი იქაა, სადაც აბსტრაქცია ვერ ხედავს.
მსგავსი შეუსაბამობა ნაკლებად თვალსაჩინო პროცესებშიც გვხვდება. ფრეიმვორკის მიერ მართული ჩამოსაშლელი სია შეიძლება პირდაპირ დაწკაპუნებაზე საერთოდ არ რეაგირებდეს, რადგან ხილული ელემენტი რეალური საკონტროლო ელემენტი არ არის. საფუძვლად არსებული მდგომარეობის გადასვლის გასააქტიურებლად მას შეიძლება კლავიატურის მოვლენების თანმიმდევრობა დასჭირდეს. გარედან მომხმარებლის ინტერფეისი დაწკაპუნებადი ჩანს. აბსტრაქცია ამბობს: „დააწკაპუნე“. არაფერი ხდება.
ან განვიხილოთ მრავალეტაპიანი მოდალური პროცესი, რომელშიც ხილული DOM-ის განახლებები შიდა მდგომარეობის ცვლილებებს ჩამორჩება. შემდეგი სწორი მოქმედება დამოკიდებულია მდგომარეობის გადასვლაზე, რომელიც თქვენი გარსისთვის ხილულ ელემენტებში ჯერ არ ასახულა. გარსზე დაფუძნებული აგენტი საბოლოოდ ნაადრევად მოქმედებს ან მოძველებულ მდგომარეობას კითხულობს, რადგან სისტემას არასრული ხედით აკვირდება.
ყოველ ასეთ შემთხვევაში აბსტრაქცია მალავს სიგნალებს, რომლებიც აგენტს სინამდვილეში სჭირდება.
უფრო დაბალ დონეზე მოქმედ მოდელს — რომელიც მიმდინარე DOM-ს ამოწმებს, ფრეიმების საზღვრებზე მსჯელობს და კონკრეტული ზედაპირისთვის ურთიერთქმედების თანმიმდევრობას ქმნის — ამ სიტუაციებთან გამკლავება შეუძლია. საქმე ის არ არის, რომ მოდელი თავისთავად უფრო ჭკვიანია. საქმე ისაა, რომ მას წვდომა აქვს ადრე ჩამოშორებულ ინფორმაციაზე.
ცვლილება, რომლისკენაც მივისწრაფვით, მარტივად აღსაწერია: მოდელს წინასწარ განსაზღვრული მოქმედებების არჩევის ნაცვლად დაბალი დონის საშემსრულებლო ზედაპირს ვაძლევთ და მას აბსტრაქციის დიზაინის ნაცვლად საშემსრულებლო პოლიტიკით ვზღუდავთ.
ეს საპროექტო არჩევანი ინდუსტრიის უფრო ფართო ცვლილებიდან მომდინარეობს, რომელიც უპირატესობას დაბალი დონის პრიმიტიულ ხელსაწყოებს ანიჭებს. ისინი ეყრდნობა აგენტის ბუნებრივ უნარს, შესრულებისას შეიტანოს შესწორებები და მაღალი ხარისხის კოდი შექმნას, ნაცვლად მყარად ჩაშენებული სპეციალიზებული ხელსაწყოებისა, რომლებიც საიმედოა, მაგრამ მოდელს სხვადასხვა გარემოსთან ადაპტაციის უნარს ართმევს.
გაიხსენეთ Claude Code-ის წარმატება, რომელმაც მრავალი დეველოპერის ხელსაწყოთა ნაკრებში ძირითადი ადგილი დაიკავა, და ინდუსტრიის უფრო ფართო გადასვლა ტერმინალზე დაფუძნებულ აგენტებზე. Claude Code-ის უდიდესი უპირატესობა თავად მოდელი კი არა, დაბალი დონის სარტყელია. მოდელისთვის ნაკლები, უფრო მოდულური და დაბალი დონის ხელსაწყოების მიცემა — ანუ ტერმინალის მიცემა — ხელსაწყოების გამოძახებისას უკეთეს შედეგს იძლევა, ძირითადად იმიტომ, რომ აგენტს შეუძლია იმსჯელოს და მიმდინარე ამოცანისთვის სპეციალური სკრიპტები შექმნას, ნაცვლად ზოგადი ხელსაწყოების გამოყენებისა, რომლებიც კონტექსტურ ფანჯარას ზედმეტად ავსებს.
ბრაუზერის ავტომატიზაციის შემთხვევაში ეს პრაქტიკულად ნიშნავს, რომ მოდელს შეუძლია პირდაპირ შეამოწმოს გვერდის მიმდინარე მდგომარეობა, გადაადგილდეს ფრეიმებს შორის და არსებული ინტერფეისისთვის სპეციალური ურთიერთქმედების კოდი შექმნას, ნაცვლად იმისა, რომ ყველაფერი წინასწარ აგებულ მოქმედებათა ფიქსირებულ ნაკრებს მოარგოს.
მოდელი ნაკლებად ჰგავს ამრჩევს და უფრო მეტად — შესრულებისას კოდის ავტორს. ის ამოწმებს მიმდინარე მდგომარეობას, მსჯელობს ინტერფეისზე და კონკრეტული სიტუაციისთვის ურთიერთქმედების ლოგიკას ქმნის. მას შეუძლია ააწყოს მრავალეტაპიანი თანმიმდევრობები, მოერგოს უჩვეულო პროცესებს და გაგრძელებამდე შედეგები შეამოწმოს. მოქმედების წარუმატებლობისას მოდელი საფუძვლად არსებულ შეცდომას ხედავს და თავად ასწორებს ქცევას. ეს მიდგომა უფრო მძლავრი და უფრო სარისკოა, თუმცა პრობლემის რეალურ ბუნებას ბევრად უკეთ შეესაბამება.
მნიშვნელოვანია, რომ აბსტრაქციის შრის მოცილება სისტემას ნაკლებად დისციპლინირებულს არ ხდის. ის მხოლოდ დისციპლინის ადგილს ცვლის.
სამუშაო, რომელიც ადრე გარსის დიზაინსა და გამონაკლისების დამუშავებაში სრულდებოდა, სამ ადგილას გადადის: მოთხოვნაში, რომელიც საოპერაციო სწავლების ფორმად იქცევა; საშემსრულებლო გარემოში, რომელიც აღასრულებს ისეთ საზღვრებს, როგორიცაა ნავიგაციის ფარგლები, მგრძნობიარე მოქმედებები და ხელახალი ცდების წესები; და შეფასების შრეში, რომელიც ადგენს არა მხოლოდ იმას, შესრულდა თუ არა ამოცანა, არამედ იმასაც, სწორი იყო თუ არა შუალედური ნაბიჯები. ნაკლები მყიფე აბსტრაქცია. უფრო ძლიერი გარშემომყოფი სისტემები.
ამ ცვლილების ერთ-ერთი შედეგი ისაა, რომ პროდუქტის კოდი ხშირად მარტივდება, მთლიანად სისტემა კი მეტ შესაძლებლობას იძენს. ურთიერთქმედების შაბლონების მრავალჯერად გარსებში ჩაშენების ნაცვლად, აგენტი ქცევას შესრულების დროს ქმნის. სპეციალიზებული ხელსაწყოებისა და გამონაკლისების ლოგიკის მზარდი ნაკრების ნაცვლად, თქვენ ინარჩუნებთ მძლავრი პრიმიტივების მცირე ნაკრებსა და შეზღუდულ საშემსრულებლო გარემოს.
ეს სისტემის განზოგადების უნარსაც ცვლის. გარსებზე დაფუძნებული აგენტი კარგად უმკლავდება იმ ამოცანების განზოგადებას, რომლებიც უკვე შექმნილ გარსებს ჰგავს. შეზღუდულ საშემსრულებლო გარემოში მოქმედი აგენტი განზოგადებას ახერხებს საერთო აღსრულების საფუძვლის მქონე ამოცანებზე, მაშინაც კი, როცა ხილული ინტერფეისი განსხვავებულია.
მაგალითად, საძიებო ფორმასთან, დაჯავშნის პროცესთან ან პარამეტრების გვერდთან ურთიერთქმედება მომხმარებლის ინტერფეისის დონეზე შეიძლება სრულიად განსხვავებულად გამოიყურებოდეს. თუმცა საფუძვლად მათ საერთო შაბლონები აქვთ: მდგომარეობის წაკითხვა, მოვლენების გააქტიურება, შედეგების შემოწმება და ასინქრონული განახლებების დამუშავება. ამ დონეზე მოქმედი სისტემა ერთი ამოცანიდან მეორეზე უფრო ბუნებრივად გადადის.
მრავალჯერადი გამოყენების კომპონენტი მოქმედებათა სია კი არა, მოდელის უნარია, შეამოწმოს მდგომარეობა, უსაფრთხოდ იმოქმედოს და შედეგები გადაამოწმოს.
ამ სამუშაოდან მიღებული უმთავრესი გაკვეთილია, რომ საიმედოობას მოდელისთვის მეტი დამხმარე ფუნქციის მიცემა არ უზრუნველყოფს. ხშირად საიმედოობა მიიღწევა ნაკლები, მაგრამ უფრო მძლავრი პრიმიტივების მიცემითა და მათი სათანადოდ შეზღუდვით. ზედმეტი დახმარება კოდში მყარად ამაგრებს ვარაუდებს იმის შესახებ, თუ როგორ უნდა შესრულდეს ამოცანა. შეზღუდვები უსაფრთხო მუშაობის საზღვრებს ადგენს და მოდელს უკეთესი ლოკალური გადაწყვეტების პოვნის საშუალებას აძლევს.
უფრო მძლავრ საშემსრულებლო ზედაპირს უსაფრთხოების უფრო მკაფიო მოდელიც სჭირდება. როგორც კი აგენტი წინასწარ განსაზღვრული მოქმედებების მცირე ნაკრებით აღარ შემოიფარგლება, ის ფაქტობრივად პირდაპირ რეალურ პროგრამულ უზრუნველყოფაში მოქმედებს. ეს რისკების პროფილს მყისიერად ცვლის.
დაპროექტებისას ოთხი საკითხია გასათვალისწინებელი:
მონაცემების გამჟღავნება. რეალურ ინტერფეისებთან ურთიერთქმედებისას აგენტი ხშირად ხვდება კონფიდენციალურ ინფორმაციას. ამიტომ საჭიროა მონაცემთა შენიღბვისა და წვდომის კონტროლის დისციპლინირებული მიდგომა. მონაცემები მხოლოდ აღსრულებისთვის საჭირო დროს უნდა გამჟღავნდეს, ჟურნალები და კვალიც ფრთხილად უნდა დამუშავდეს, რათა დაკვირვებადობა სისტემის ყველაზე მგრძნობიარე ნაწილად არ იქცეს.
აღსრულების ფარგლები. მძლავრ აგენტს თვითნებურად მოქმედება არ უნდა შეეძლოს. პრაქტიკაში ეს ნიშნავს შეზღუდვას, თუ სად შეუძლია გადაადგილება, რომელ დომენებზე აქვს წვდომა და რომელ სისტემებთან შეუძლია ურთიერთქმედება. ეს შეზღუდვები საშემსრულებლო გარემოს დონეზე უნდა აღსრულდეს და არა მოთხოვნებში დაუწერელ წესებად დარჩეს.
გარემოს სანდოობა. თანამედროვე ინტერფეისები შეიძლება შეიცავდეს შეცდომაში შემყვან ან აქტიურად მტრულ ინსტრუქციებს, შიგთავსსა თუ პროცესებს. გვერდის შიგთავსის მეშვეობით პრომპტ ინიექცია რეალური თავდასხმის ზედაპირია. სისტემას სჭირდება ინსტრუქციების მკაფიო იერარქია, შემოწმების მექანიზმები და შეწყვეტის პირობები, რათა აგენტმა გაუთვალისწინებელ მითითებებს არ მისდიოს.
ავტონომიურობის სპექტრი. ყველა მოქმედება სრულად ავტონომიური არ უნდა იყოს. ბევრ საწარმოო გარემოში მნიშვნელოვანია, ავტონომიურობა სპექტრად განვიხილოთ. სისტემას შეუძლია ძიებისა და აღსრულებისას მაღალი აგენტურობა გამოავლინოს, თუმცა მოქმედებათა გარკვეული კატეგორიებისთვის კვლავ მოითხოვოს დამტკიცება.
ძირითადი პრინციპი მარტივია: მოდელისთვის მეტი ძალის მინიჭება მის გარშემო არსებული სისტემის გაძლიერებას მოითხოვს. პოლიტიკის გარეშე ავტონომიურობა საწარმოო გამოყენებისთვის მზად არ არის.
აღარ ვსვამდით კითხვას: ბრაუზერის რომელი მოქმედებები უნდა გავხადოთ ხელმისაწვდომი?
დავიწყეთ კითხვა: როგორ მივცეთ მოდელს მოქმედებების სრული სივრცე და მის გარშემო ისეთი საშემსრულებლო პოლიტიკები შევქმნათ, რომლებიც უსაფრთხოებას შეინარჩუნებს?
ასეთი ახალი ხედვა პრიორიტეტებს ცვლის. მოქმედებათა კლასიფიკაციასა და გარსების სისრულეს ნაკლები მნიშვნელობა ენიჭება. საშემსრულებლო პოლიტიკა, დაკვირვებადობა და თითოეული ნაბიჯის შეფასება უფრო მნიშვნელოვანი ხდება. მოდელის შესაძლებლობები და სისტემის დიზაინი ერთმანეთს ვერ ჩაანაცვლებს. მოდელების გაუმჯობესებასთან ერთად სისტემის სამუშაო უფრო მნიშვნელოვანი ხდება და არა ნაკლებად.
დემონსტრაციებში წარმატებული ბრაუზერის აგენტები ხშირად იმიტომ მუშაობს, რომ ამოცანა ვიწროა, გარემო კი ხელსაყრელი. საწარმოო სისტემებს სხვა რამ სჭირდება: შეზღუდული აღსრულება, ინსტრუმენტებით აღრიცხული ქცევა და შეფასება, რომელიც სწორ შედეგს შემთხვევით მიღებული წარმატებისგან განასხვავებს.
ნაკლები გარსის დიზაინი. მეტი სისტემური ინჟინერია.
მართალია, ყურადღება ბრაუზერის აგენტებზე გავამახვილეთ, მაგრამ ეს კომპიუტერის გამოყენების, როგორც სისტემური დისციპლინის, უფრო ფართო ხედვაზე მიგვითითებს.