ការប្រមូលទិន្នន័យដោយ Agent Framework៖ បញ្ហាបរិស្ថាន 3 ប្រភេទ និងវិធីដោះស្រាយ

នៅពេលប្រើ Agent framework ដើម្បីបញ្ជា browser សម្រាប់ប្រមូលទិន្នន័យ ស្ថាបត្យកម្មជាទូទៅមាន 3 ស្រទាប់៖ Agent រៀបចំផែនការ និងសម្រេចចិត្ត, Playwright ទទួលបន្ទុកចុច បញ្ចូល និងយកទិន្នន័យ ហើយចុងក្រោយ workflow ទាក់ទងទៅ target site។ Task ខ្លីៗភាគច្រើនដំណើរការល្អ និងឆ្លង local test។ ប៉ុន្តែពេល runtime វែងឡើង និង task កើនឡើង បញ្ហាចាប់ផ្តើមប្រមូលផ្តុំនៅកន្លែងមួយដែលជាញឹកញាប់មិនទទួលការយកចិត្តទុកដាក់គ្រប់គ្រាន់ នោះគឺ browser environment។

តាមបទពិសោធន៍ជាក់ស្តែង បញ្ហានៅ environment layer អាចបែងចែកជាបីទម្រង់សំខាន់ៗ។

Environment ត្រូវបានចាត់ទុកថាមិនប្រក្រតី ហើយ pipeline ទាំងមូលឈប់

ករណីមួយគឺ platform ចាត់វិធានការលើ environment ផ្ទាល់។ ជាញឹកញាប់វាមិនមែនជា block ដោយផ្ទាល់ទេ ប៉ុន្តែជាការបន្ថយសមត្ថភាព៖ បង្ហាញ page សាមញ្ញ, ទទួល result ទទេ ឬត្រូវធ្វើ verification។ Script មិនបង្ហាញ error ប៉ុន្តែទិន្នន័យដែលបានយកមកមិនមានប្រយោជន៍ទៀត។ ជំហានបន្ទាប់នៅតែរត់ធម្មតា ហើយទិន្នន័យខុសត្រូវបានបញ្ជូនរហូតដល់តារាងចុងក្រោយ។

បញ្ហាគឺ environment បែបនេះជាញឹកញាប់ត្រូវបានចែករំលែកដោយ task ច្រើន។ បើ environment មួយមានបញ្ហា task ទាំងអស់ដែលភ្ជាប់នឹងវាអាចឈប់។ Retry ក៏មិនជួយទេ ព្រោះមូលហេតុមិនស្ថិតនៅក្នុង script។

Task ច្រើនប្រើ environment តែមួយ ហើយ session state លាយគ្នា

នៅពេល task ច្រើនដំណើរការស្របគ្នាក្នុង browser instance តែមួយ Cookie, localStorage និង IndexedDB អាច overwrite គ្នា ហើយធ្វើឱ្យ login state របស់គ្នាផ្លាស់ប្តូរ។ ក្នុងរយៈពេលខ្លីវាមិនសូវឃើញទេ ប៉ុន្តែបន្ទាប់ពីដំណើរការប៉ុន្មានថ្ងៃ អាចមានការស្នើឱ្យ login ឡើងវិញដោយគ្មានមូលហេតុច្បាស់លាស់។

មាន drift មួយទៀតដែលលាក់ខ្លួនជាងនេះ។ Browser ដែលដំណើរការយូរ នឹងមានការប្រែប្រួលបន្តិចម្តងៗក្នុង cache, storage និងសូម្បីតែ WebGL rendering state។ Environment ដដែលអាចមានលក្ខណៈខុសគ្នារវាងថ្ងៃនេះ និងបីថ្ងៃក្រោយ។ មនុស្សជាច្រើនគិតថា Cookie ផុតកំណត់ ប៉ុន្តែការពិត environment ខ្លួនវាប្រែទៅហើយ។ ដូច្នេះ ការធ្វើឱ្យ environment ជា object ដែល persistent និងអាច reuse បាន មានប្រសិទ្ធភាពជាងបង្កើត browser ថ្មីរាល់លើក។

ពេលបន្តពី checkpoint Environment ចាស់អាចមិនអាចប្រើបានទៀត

Task ប្រមូលទិន្នន័យកម្របញ្ចប់ក្នុង run តែមួយ។ ការបន្តពី checkpoint បន្ទាប់ពី interruption គឺជារឿងធម្មតា ប៉ុន្តែក៏ងាយបាត់បង់ការងារ៖ ពេល restart script អាចបង្កើត browser instance ថ្មី ហើយបាត់ login state; ឬបន្តប្រើ environment ចាស់ ទោះ platform បាន flag វារួចហើយ ដូច្នេះការបន្តរត់គ្រាន់តែចំណាយ resource បន្ថែម។

ចំណុចសំខាន់មិនមែនជាចំនួន retry ទេ ប៉ុន្តែជា granularity នៃ recovery។ បើមិនរក្សាទុកក្រៅ script ថា task ដល់ជំហានណា, ទិន្នន័យណាបានយករួច និង environment ណាត្រូវបានប្រើ ពេល restart នឹងត្រូវចាប់ផ្តើមពីដើមវិញ។

អ្វីដែលអាចធ្វើបាននៅ environment layer

បើដាក់បញ្ហាទាំងបីជាមួយគ្នា វិធីគិតសំខាន់មានបីចំណុច។

Group environment តាម task។ Task មួយគួរមានក្រុម environment ផ្ទាល់ខ្លួន ហើយកុំដាក់ task ច្រើនក្នុង instance តែមួយ។ បន្ទាប់ពី grouping អាចកំណត់ network egress, time zone និង language ដោយឡែកសម្រាប់ task នីមួយៗ។ ការរក្សា parameter ទាំងនេះឱ្យស៊ីគ្នាជាកញ្ចប់ មានភាពទុកចិត្តបានជាងកំណត់ដោយដៃដាច់ៗ។ នៅក្នុងស្ថាបត្យកម្មនេះ PurpleMark ស្ថិតនៅ environment layer៖ វាបង្កើត browser environment ជាច្រើនជាក្រុម, ភ្ជាប់ network egress ដាច់ដោយឡែកទៅ environment នីមួយៗ ហើយប្រគល់តាម API ទៅ task-orchestration layer សម្រាប់ scheduling។

Isolate failure។ បើ environment មួយត្រូវបានចាត់ទុកថាមិនប្រក្រតី គួរប៉ះពាល់តែ task ដែលភ្ជាប់នឹងវាប៉ុណ្ណោះ។ ជាធម្មតា environment នីមួយៗមាន health status សម្រាប់ពិនិត្យជាប្រចាំ ហើយពេលរកឃើញបញ្ហា គេដកវាចេញ និងប្តូរទៅ standby environment ជំនួសឱ្យឱ្យ script ខាងលើ retry environment ខូចដដែលៗ។ វាក៏ជួយឱ្យសម្គាល់បានថា បញ្ហាមកពី environment ឬ page structure បានផ្លាស់ប្តូរ។

ធ្វើឱ្យ state អាច recover បាន។ រក្សាទុក progress, deduplication fingerprints និង environment identifiers ជាប្រចាំនៅក្រៅ script។ ពេល restart អាន record ទាំងនេះជាមុន សិនហើយសម្រេចថាត្រូវបន្តពីណា និងប្រើ environment ណា។ បែងចែក task ជាដំណាក់កាលដូចជា discovery, loading និង extraction ហើយដោះស្រាយ failure ដាច់ដោយឡែក ដើម្បីកុំឱ្យ failure មួយធ្វើឱ្យ run ទាំងមូលបាត់បង់។ ក៏ត្រូវយកចិត្តទុកដាក់លើ resource ផងដែរ៖ instance ដែលដំណើរការយូរអាចមាន memory leak, page freeze និង connection timeout ដូច្នេះ session ដែលមិនមានសុពលភាពគួរត្រូវ recycle ជាប្រចាំ។

ព្រំដែនដែលត្រូវបែងចែកឱ្យច្បាស់

Environment មានស្ថេរភាព និងការអនុញ្ញាតឱ្យប្រមូលទិន្នន័យ គឺជារឿងពីរផ្សេងគ្នា។ ត្រូវពិនិត្យ robots rules និង terms of service របស់ target site ជាមុន ព្រោះ site ជាច្រើនកំណត់ច្បាស់លាស់លើ automated access; ត្រូវគ្រប់គ្រង request rate ដើម្បីកុំប៉ះពាល់សេវារបស់ភាគីម្ខាងទៀត; មិនប្រមូល personal information; ហើយពេលជួប technical protection measures គួរផ្លាស់ប្តូរ strategy ឬស្នើ authorization ជំនួសឱ្យការព្យាយាម bypass។ Technical stability មិនអាចជំនួស compliance judgment បានទេ។

មាតិកានេះមានគោលបំណងសម្រាប់ការស្រាវជ្រាវបច្ចេកទេស និងការចែករំលែកបទពិសោធន៍អភិវឌ្ឍន៍ប៉ុណ្ណោះ។ សូមអនុវត្តតាមលក្ខខណ្ឌរបស់ target site និងច្បាប់ដែលអនុវត្តនៅទីតាំងរបស់អ្នក។