នៅពេលស្វ័យប្រវត្តិកម្មដោយ Agent ចាប់ផ្តើមឈប់ ឬបរាជ័យពេលពង្រីកទំហំការងារ បញ្ហាជាញឹកញាប់មិនស្ថិតនៅម៉ូឌែល ឬស្គ្រីបទេ ប៉ុន្តែនៅស្រទាប់បរិស្ថានកម្មវិធីរុករក។ អត្ថបទនេះពន្យល់លំនាំបរាជ័យទូទៅ 4 ប្រភេទ សញ្ញាដែលអាចសង្កេតឃើញ និងវិធីដោះស្រាយផ្នែកវិស្វកម្ម។
ការបង្កើត Agent ដោយប្រើ LangChain, AutoGen ឬ CrewAI ហើយឱ្យវាបញ្ជាគេហទំព័រតាម Playwright ឬ Puppeteer មិនមែនជារឿងពិបាកខ្លាំងទេ។ អ្វីដែលពិបាកគឺធ្វើឱ្យវាដំណើរការបន្តបានយូរ និងមានស្ថិរភាព។
នៅដំណាក់កាលដំបូង បញ្ហាមានទំនោរមិនសូវបង្ហាញច្បាស់។ ពេលចំនួន task កើនឡើង ភាពមិនប្រក្រតីចាប់ផ្តើមកើតញឹកញាប់៖ គេហទំព័ររារាំង task, session ចូលគណនីផុតសុពលភាពភ្លាមៗ ឬ Agents ច្រើនដែលរត់ពេលតែមួយរំខានគ្នា។ ជំហានដំបូងរបស់មនុស្សជាច្រើនគឺត្រឡប់ទៅពិនិត្យ code ប៉ុន្តែចុងក្រោយរកឃើញថា code មិនមានបញ្ហា។
បញ្ហាជាញឹកញាប់ស្ថិតនៅស្រទាប់បរិស្ថានកម្មវិធីរុករក។ ក្នុងគម្រោងដែលដំណើរការក្នុងបរិមាណច្រើន ទម្រង់បរាជ័យភាគច្រើនត្រូវបានកាត់ចូលជាលំនាំដដែលៗមួយចំនួន។ ពេលស្គាល់លំនាំទាំងនេះហើយ ការដោះស្រាយមិនស្មុគស្មាញខ្លាំងទេ។
ចាប់ផ្តើមមុនពេលបរិស្ថានរួចរាល់
បើបរិស្ថានកម្មវិធីរុករកដែលទើបបង្កើតត្រូវបានប្រើសម្រាប់ task ភ្លាមៗ លទ្ធផលដែលជួបញឹកញាប់គឺចូលគណនីមិនបាន ធាតុលើទំព័រផ្ទុកមិនពេញ ឬត្រូវធ្វើការផ្ទៀងផ្ទាត់តាំងពីជំហានដំបូង។ មូលហេតុសាមញ្ញណាស់៖ បរិស្ថាននេះមិនមានប្រវត្តិចូលមើល មិនមាន Cookie ហើយក៏មិនមានប្រវត្តិការរុករក។ សម្រាប់ platform វាមើលទៅដូចជាឧបករណ៍ថ្មីទាំងស្រុង ដូច្នេះកម្រិតទុកចិត្តដំបូងទាប។
សញ្ញាដែលអាចសង្កេតឃើញគឺបរាជ័យភាគច្រើនកើតនៅ task ដំបូងៗបន្ទាប់ពីបង្កើតបរិស្ថាន។ បើផ្លាស់ task ដូចគ្នាទៅបរិស្ថានដែលបានប្រើមួយរយៈ វាជាញឹកញាប់អាចបញ្ចប់បានធម្មតា។
វិធីសមស្របគឺកំណត់ភាពរួចរាល់របស់បរិស្ថានជាស្ថានភាពច្បាស់លាស់ មិនមែនសន្មតថាអាចប្រើបានភ្លាមៗទេ។ ក្រោយបង្កើតបរិស្ថាន គួរឱ្យវាធ្វើ browsing កម្រិតទាបមួយរយៈសិន ហើយទើបផ្តល់ task ពិតប្រាកដនៅពេលស្ថានភាពមានស្ថិរភាព។ Scheduler គួរតែពិនិត្យភាពរួចរាល់នេះមុនពេលបញ្ជូន task មិនមែនយកបរិស្ថានថ្មីទៅប្រើភ្លាមៗទេ។
task ច្រើនប្រកួតប្រជែងយកបរិស្ថានតែមួយ
ពេល concurrency កើនឡើង អាការៈដែលឃើញច្បាស់ជាងគេគឺ process កើនច្រើន memory ត្រូវបានប្រើអស់ ហើយ system យឺត។ បញ្ហាដែលលាក់ខ្លួនពិបាកជាងនេះគឺ task ពីរប្រើ Cookie និង local storage ដូចគ្នាជាបន្តបន្ទាប់ ស្ថានភាព login របស់ A ទៅជំនួសរបស់ B ហើយក្នុង log មើលទៅដូចជាមាន task មួយចៃដន្យបរាជ័យម្តងម្កាល។ វាពិបាករកមូលហេតុ។
នៅទីនេះគួរចាត់ទុកបរិស្ថានកម្មវិធីរុករកជាធនធានដែលអាចស្នើសុំ និងប្រគល់ត្រឡប់បាន។ នៅពេល task ចាប់ផ្តើម វាទទួលបានបរិស្ថានមួយ ហើយពេលបញ្ចប់វាប្រគល់ត្រឡប់ ដោយរក្សាទំនាក់ទំនងមួយទល់មួយរវាង task និងបរិស្ថាន។ Storage របស់បរិស្ថានផ្សេងៗមិនមើលឃើញគ្នា ដូច្នេះស្ថានភាព login របស់ task មួយមិនហូរចូលទៅ task ផ្សេង។ ពេលពង្រីកទៅ Agents រាប់សិបដែលរត់ស្របគ្នា ភាពខុសគ្នានឹងឃើញច្បាស់បើប្រៀបនឹង “បើក browser process ច្រើននៅក្នុង script”។
បើករណីប្រើប្រាស់មានគណនីច្រើន ការញែកត្រូវតែតឹងរឹងជាងមុន៖ គណនីមួយភ្ជាប់ជាមួយបរិស្ថានថេរមួយ ហើយ fingerprint parameters និង storage មិនត្រូវស្ទួនជាមួយគណនីផ្សេង។ PurpleMark ផ្តល់ស្រទាប់សម្រាប់ញែកបរិស្ថាន និង scheduling កណ្ដាល ដើម្បីរក្សាការផ្គូផ្គងមួយទល់មួយរវាងគណនី និងបរិស្ថានឱ្យមានស្ថិរភាព។
session ផុតសុពលភាព ប៉ុន្តែមិនមានអ្នកណាសង្កេតឃើញ
បរាជ័យប្រភេទនេះងាយត្រូវមើលរំលង ព្រោះវាមិនចាំបាច់បង្ហាញ error ទេ។ Task នៅតែរត់ ហើយ log នៅតែចេញ ប៉ុន្តែអ្វីដែលត្រឡប់មកពិតប្រាកដគឺទំព័រ login ឬទិន្នន័យទទេ។ បញ្ហាត្រូវបានរកឃើញតែបន្ទាប់ពីលទ្ធផលចូល data pipeline ហើយការស្រាវជ្រាវត្រូវធ្វើថយក្រោយពី downstream ដែលចំណាយខ្ពស់។
ដំណោះស្រាយគឺចាត់ទុកស្ថានភាព login ជាលក្ខខណ្ឌមុនដែលត្រូវពិនិត្យច្បាស់លាស់។ មុនចាប់ផ្តើម task ត្រូវបញ្ជាក់ថា session បច្ចុប្បន្ននៅមានសុពលភាព។ បើផុតសុពលភាព ត្រូវដំណើរការ login flow ពេញលេញ ជំនួសឱ្យបន្ត task ជាមួយស្ថានភាពមិនត្រឹមត្រូវ។ ស្ថានភាពគួររក្សាទុកនៅស្រទាប់បរិស្ថាន៖ Cookie, local storage និងប្រវត្តិ browsing ត្រូវបានរក្សាទុកក្នុងបរិស្ថាន ហើយអាចស្ដារឡើងវិញពេញលេញនៅពេលបើកម្តងទៀត ដូច្នេះ task របស់គណនីមិនចាំបាច់ initialize ឡើងវិញរាល់ពេល។
បទពិសោធន៍មួយគឺ សម្រាប់គណនីដែលដំណើរការរយៈពេលយូរ ការផ្លាស់ប្តូរស្ថានភាព login ញឹកញាប់អាចត្រូវ platform មើលថាជាសញ្ញាមិនប្រក្រតី និងបង្កឱ្យមាន verification បន្ថែម។ ដូច្នេះគួរជៀសវាងការចូលគណនីឡើងវិញដែលមិនចាំបាច់។
ត្រូវបានរារាំងហើយ task ទាំងមូលក្នុង batch ឈប់
បរាជ័យមួយទៀតកើតឡើងជាក្រុមភ្លាមៗ ដោយ task ច្រើនមិនអាចផ្តល់លទ្ធផលក្នុងពេលតែមួយ។ គេហទំព័រមិនចាំបាច់បង្ហាញការបដិសេធច្បាស់លាស់ទេ; ជាញឹកញាប់វាត្រឡប់ content ដែលបានកាត់បន្ថយ ឬទំព័រទទេ ហើយ Agent បន្តដំណើរការជាមួយទិន្នន័យគ្មានន័យរហូតដល់បញ្ហាលេចឡើងនៅដំណាក់កាលទិន្នន័យ។
ក្នុងស្ថានភាពនេះ ជំហានដំបូងគឺបំបែកការរារាំងចេញពី failure ទូទៅ។ បើបរិស្ថានក្រុមដូចគ្នាក្លាយជាមិនប្រក្រតីនៅពេលប្រហាក់ប្រហែលគ្នា មានលទ្ធភាពខ្ពស់ថាបញ្ហាស្ថិតនៅស្រទាប់បរិស្ថាន។ បន្ត retry នឹងធ្វើឱ្យផលប៉ះពាល់ធំឡើង ដូច្នេះគួរឈប់ និងញែកបរិស្ថានក្រុមនោះសិន ហើយទើបស្វែងរក trigger។
Trigger ដែលជួបញឹកញាប់មានបីទិសដៅ៖ បរិស្ថានច្រើនប្រើ fingerprint configuration ដែលស្រដៀងគ្នាខ្លាំង ដូចជា WebGL, Canvas, បញ្ជី font ឬ engine version ស្ទើរតែដូចគ្នា; exit IP, time zone និង language មិនស្របគ្នា ឧទាហរណ៍ IP អាមេរិកតែប្រើ time zone អាស៊ី; ឬចន្លោះពេលនៃសកម្មភាពទៀងទាត់ពេក រហូត rhythm ខ្លួនវាក្លាយជាលក្ខណៈសម្គាល់។ ត្រូវធ្វើឱ្យ configuration ស្របគ្នា គ្រប់គ្រងចង្វាក់ និងរក្សា log ទាំងស្ថានភាពបរិស្ថាន និងលទ្ធផល task ដើម្បីឃើញសញ្ញាមុនពេល failure រាលដាលទាំង batch។
ញែកស្រទាប់នេះចេញដោយឡែក
គម្រោងដែលមានភាពចាស់ទុំ ជាទូទៅញែកបរិស្ថានកម្មវិធីរុករកចេញពី Agent ហើយគ្រប់គ្រងវាជាស្រទាប់ដាច់ដោយឡែក៖ Agent ទទួលខុសត្រូវលើការធ្វើផែនការ និងការសម្រេចចិត្ត ស្រទាប់បរិស្ថានគ្រប់គ្រង identity និង state ហើយស្រទាប់ execution នៅតែប្រើ Playwright ឬ Puppeteer។ បន្ទាប់ពីញែកចេញ នឹងមានកន្លែងច្បាស់សម្រាប់គ្រប់គ្រងថា identity មានភាពសមហេតុផលឬអត់ state អាចស្ដារឡើងវិញបានឬអត់ និង task ត្រូវបានញែកពីគ្នាឬអត់។
បើមើលត្រឡប់ក្រោយ បរាជ័យទាំង 4 ប្រភេទមានចំណុចរួមមួយ៖ វាមិនស្ថិតនៅក្នុង model ហើយក៏មិនស្ថិតនៅក្នុង script logic ដែរ។ Model និង code ត្រូវបន្តកែលម្អជានិច្ច ប៉ុន្តែថាស្វ័យប្រវត្តិកម្មអាចរត់បានយូរ និងមានស្ថិរភាពឬអត់ ជាញឹកញាប់ត្រូវបានកំណត់ដោយស្រទាប់ខាងក្រោមនេះ។
មាតិកានេះត្រូវបានចែករំលែកសម្រាប់ការស្រាវជ្រាវបច្ចេកទេស និងការអនុវត្តអភិវឌ្ឍន៍។ ស្វ័យប្រវត្តិកម្មគួរត្រូវបានប្រើដោយស្របច្បាប់ និងអនុលោមតាមបទប្បញ្ញត្តិ ដោយគោរពលក្ខខណ្ឌសេវាកម្មរបស់ platform គោលដៅ និងច្បាប់ ឬបទប្បញ្ញត្តិមូលដ្ឋានដែលពាក់ព័ន្ធ។
