ការបើក Browser ច្រើនសម្រាប់ AI Agent៖ តម្រូវការបំបែក ៣ ប្រភេទ និងថ្លៃធនធាន

ដើម្បីបង្ហាញថា AI Agent អាចធ្វើអ្វីបាន browser window តែមួយគឺគ្រប់គ្រាន់។ ប៉ុន្តែនៅពេលដាក់ចូលក្នុងការងារអាជីវកម្មពិត តម្រូវការនឹងកើនឡើងយ៉ាងលឿនទៅជាបង្អួចរាប់សិប ហើយវាមិនត្រូវរំខានគ្នាទេ។ មូលហេតុមិនស្ថិតនៅលើ Agent ខ្លួនវាទេ ប៉ុន្តែស្ថិតនៅលើបរិស្ថាន browser ដែលវាដំណើរការលើ។

តើមានបញ្ហាអ្វីខ្លះពេលប្រើបរិស្ថានតែមួយរួមគ្នា

បញ្ហាដែលឃើញច្បាស់បំផុតគឺ Cookie និងស្ថានភាព login ប៉ះពាល់គ្នា។ នៅក្នុង browser data directory តែមួយ ប្រសិនបើកិច្ចការពីរចូលគណនីខុសគ្នាតាមលំដាប់ ការចូលក្រោយអាចសរសេរជំនួស session របស់កិច្ចការមុន។ ប្រសិនបើកិច្ចការមួយសម្អាត cache ស្ថានភាពទំព័ររបស់កិច្ចការផ្សេងក៏អាចបាត់បង់ផងដែរ។

បន្ទាប់មកគឺការប្រជែងធនធាន។ ក្នុង browser instance តែមួយ tab, focus, download directory និង pop-up សុទ្ធតែជាធនធានរួម។ ប្រសិនបើកិច្ចការពីរបើក tab ថ្មីក្នុងពេលតែមួយ វានឹងពិបាកដឹងថាកិច្ចការណាកំពុងគ្រប់គ្រងទំព័រណា។ dialog របស់កិច្ចការមួយក៏អាចធ្វើឱ្យ script របស់កិច្ចការផ្សេងជាប់គាំងបាន។ ការប៉ះទង្គិចស្ថានភាព login ការសរសេរជំនួសទិន្នន័យ និងការរំខានគ្នារវាងប្រតិបត្តិការ គឺស្ទើរតែជាផលជៀសមិនរួចនៃការដំណើរការដំណាលគ្នា។

បញ្ហាទីបីលេចឡើងបន្ទាប់ពីការបរាជ័យ។ វាពិបាកកំណត់ថាតើ logic របស់ script ខុស ឬបរិស្ថានត្រូវបានកិច្ចការផ្សេងរំខាននៅជំហានណាមួយ។ នៅពេលកិច្ចការច្រើនប្រើ process និង log តែមួយ រោគសញ្ញានៃការបរាជ័យក៏អាចមិនដូចគ្នា ហើយធ្វើឱ្យថ្លៃ troubleshooting កើនឡើងច្រើន។

នៅមានហានិភ័យមួយទៀតដែលមិនងាយមើលឃើញ៖ នៅពេល identity ច្រើនដំណើរការយូរនៅក្នុងបរិស្ថានតែមួយ វានឹងទុកសញ្ញាដែលអាចភ្ជាប់គ្នាបាន។ device parameters, storage state និង network egress សុទ្ធតែដូចគ្នា ដូច្នេះ platform អាចមើលឃើញថាជាប្រតិបត្តិការជាក្រុមពីឧបករណ៍តែមួយបានងាយ។ ប្រសិនបើគណនីមួយត្រូវបានចាត់ទុកថាមិនប្រក្រតី គណនីផ្សេងទៀតក៏អាចរងផលប៉ះពាល់ដែរ។

បើក window ច្រើនមិនស្មើនឹងការបំបែកបរិស្ថាន

មនុស្សជាច្រើនគិតដំបូងថាគ្រាន់តែបើក window ច្រើនដោយដៃ។ មើលទៅវាដាច់ពីគ្នា ប៉ុន្តែជាក់ស្តែងវាប្រើ browser profile តែមួយ៖ Cookie ដូចគ្នា local storage ដូចគ្នា និងព័ត៌មានឧបករណ៍ដូចគ្នា។ Window អាចមើលឃើញស្ថានភាព login របស់គ្នា ហើយសកម្មភាពក្នុង window មួយអាចប៉ះពាល់ដល់ window ផ្សេង។

ការបំបែកពិតប្រាកដត្រូវធ្វើដល់កម្រិត data directory និង environment parameters។ បរិស្ថាននីមួយៗត្រូវមាន storage directory ផ្ទាល់ខ្លួន device parameters ផ្ទាល់ខ្លួន ដូចជា resolution, language, time zone, fonts, Canvas, WebGL ជាដើម និង network egress ផ្ទាល់ខ្លួន។ ប្រសិនបើខ្វះមួយក្នុងចំណោមបីនេះ ការបំបែកមិនពេញលេញទេ។ ទោះបីបរិស្ថានដាច់ពីគ្នាក៏ដោយ ការប្រើ egress រួមគ្នានៅតែអាចធ្វើឱ្យការត្រួតពិនិត្យទំនាក់ទំនងដំណើរការ។

តម្លៃនៃការបំបែក និងអ្វីដែលទទួលបានវិញ

ការបំបែកមិនមែនឥតគិតថ្លៃទេ។ នៅពីក្រោយបរិស្ថាននីមួយៗមាន browser process ឯករាជ្យ និង data directory ដាច់ដោយឡែក។ នៅពេលចំនួនបរិស្ថានកើនឡើង memory និង CPU នឹងទទួលសម្ពាធមុនគេ។ ប្រសិនបើមានបរិស្ថានរាប់សិបនៅលើម៉ាស៊ីនតែមួយ គួរគណនាទំហំធនធានដែលនៅសល់ជាមុន ជាជាងរង់ចាំឱ្យប្រព័ន្ធគាំងហើយទើបដោះស្រាយ។

មានចំណុចជាច្រើនអាចសម្របសម្រួលបាន៖ ដកបរិស្ថានដែលមិនសូវប្រើចេញ ហើយបើកឡើងវិញពេលត្រូវការ; ចែកកិច្ចការតាមទម្ងន់ទៅម៉ាស៊ីនច្រើន ជំនួសឱ្យដាក់អ្វីៗទាំងអស់លើម៉ាស៊ីនតែមួយ; និងកំណត់ lifecycle ច្បាស់សម្រាប់បរិស្ថាន ដើម្បីកុំឱ្យបរិស្ថានរាប់រយដំណើរការជាប់ជានិច្ច។ រចនាសម្ព័ន្ធកិច្ចការក៏សំខាន់ដែរ។ កិច្ចការដែលដំណើរការតាមលំដាប់ក្រោមគណនីតែមួយមិនចាំបាច់បំបែកទៅបរិស្ថានច្រើនទេ ព្រោះវាគ្រាន់តែខ្ជះខ្ជាយធនធាន។

ម្យ៉ាងវិញទៀតមានអត្ថប្រយោជន៍។ នៅពេលការបំបែកត្រូវបានធ្វើត្រឹមត្រូវ អាការៈបរាជ័យនឹងមានស្ថិរភាព៖ បញ្ហាគឺជារបស់បរិស្ថានជាក់លាក់មួយ មិនមែនជាបាតុភូតដែលពិបាកពន្យល់ទេ។ នៅពេលពង្រីកទំហំ តម្លៃនៃភាពអាចទស្សន៍ទាយបាននេះធំជាងធនធានតិចតួចដែលសន្សំបានពីការប្រើរួមគ្នាច្រើន។

រឿង ៣ ដែលត្រូវស្ថិតនៅកម្រិតបរិស្ថានពេលពង្រីកទំហំ

ទីមួយគឺ batch scheduling។ បរិស្ថានគួរអាចស្នើប្រើ និងដោះលែងដូចជា compute resources ហើយគាំទ្រ on-demand creation, batch startup, concurrency control, retry បន្ទាប់ពីបរាជ័យ និង automatic recycling ជំនួសឱ្យបង្កើត និងបិទម្តងមួយៗនៅក្នុង script។

ទីពីរគឺ network egress ឯករាជ្យ។ បរិស្ថាននីមួយៗគួរភ្ជាប់ទៅ egress ផ្ទាល់ខ្លួន ហើយតំបន់របស់ egress ត្រូវស្របនឹង geographic parameters របស់បរិស្ថាន។ ចំណុចនេះងាយមើលរំលង ប៉ុន្តែវាជាលក្ខខណ្ឌមូលដ្ឋានសម្រាប់ការបំបែកទាំងមូល។

ទីបីគឺស្ថានភាពដែលអាចសួរបាន។ ត្រូវអាចដឹងគ្រប់ពេលថាបរិស្ថានណាកំពុងដំណើរការ បរិស្ថានណាទំនេរ និងបរិស្ថានណាមិនប្រក្រតី។ Agent ដំណើរការដោយគ្មានមនុស្សមើលថែ; ប្រសិនបើមិនអាចសួរស្ថានភាពបាន ការដោះស្រាយបញ្ហានឹងក្លាយជាការទាយ។

សមត្ថភាពទាំងបីនេះមិនស្រួលដាក់នៅក្នុង script ទេ។ វាត្រូវការ storage, configuration និង scheduling នៅកម្រិតបរិស្ថាន។ ឧបករណ៍គ្រប់គ្រង multi-environment មួយចំនួនធ្វើការនៅកម្រិតនេះតែម្ដង។ PurpleMark គឺមួយក្នុងចំណោមវា ដោយបម្លែង browser environment ទៅជាធនធានដែលអាចបំបែក អាច schedule ជាក្រុម និងអាចហៅតាម interface។

ពេលណាមិនចាំបាច់មានបរិស្ថានច្រើន

ប្រសិនបើ Agent ប្រើតែគណនីមួយ និងដំណើរការមិនញឹកញាប់ browser ធម្មតាគឺគ្រប់គ្រាន់ ហើយការបំបែកបន្ថែមគ្រាន់តែបង្កើនបន្ទុកថែទាំ។ ប៉ុន្តែបើមានលក្ខខណ្ឌណាមួយខាងក្រោម កម្រិតបរិស្ថានគួរត្រូវបានបំបែកចេញ៖ កិច្ចការត្រូវដំណើរការស្របគ្នា, identity ច្រើនត្រូវចូល platform តែមួយ, ត្រូវរក្សាស្ថានភាព login រយៈពេលវែង ឬទំហំ concurrency នឹងបន្តកើនឡើង។

ចំណុចរួមនៃករណីទាំងនេះគឺដូចគ្នា៖ បញ្ហាមិនមែនថា Agent ឆ្លាតគ្រប់គ្រាន់ឬអត់ទេ ប៉ុន្តែថាបរិស្ថានដែលវាឈរលើស្អាត និងដាច់ដោយឡែកគ្រប់គ្រាន់ឬអត់។

ដែនកំណត់

មិនថាជ្រើសរើសរចនាសម្ព័ន្ធណាទេ ដែនកំណត់នៃច្បាប់មិនផ្លាស់ប្តូរ៖ គោរព terms of service និង robots rules របស់ platform នីមួយៗ មិនប្រើព័ត៌មាន identity ក្លែងក្លាយ មិនគេចវេសវិធានការការពារបច្ចេកទេស គ្រប់គ្រងប្រេកង់នៃ request និងមិនរំខានដល់ការដំណើរការធម្មតារបស់សេវារបស់ភាគីផ្សេង។