ត្រឡប់ទៅប្លុក

លំហូរការងារ 2 ប្រភេទសម្រាប់រកចំណូលដោយប្រើ AI Agents

ស្វែងយល់ថាការងាររកចំណូលណាខ្លះដែល AI Agents អាចដំណើរការបានជឿជាក់នៅពេលនេះ ការងារណាខ្លះមិនទាន់សមស្របសម្រាប់ស្វ័យប្រវត្តិកម្ម និងចំណុចណាខ្លះត្រូវទុកឱ្យមនុស្សពិនិត្យ។

ចំណុចបែងចែកសំខាន់រវាង AI Agent និង AI សម្រាប់សន្ទនា គឺ AI Agent អាចអនុវត្តសកម្មភាពបាន៖ បើក browser បំពេញ form អាន និងសរសេរ spreadsheet ហើយបន្តតាម workflow ដោយមិនចាំបាច់ឱ្យអ្នក copy និង paste រាល់ជំហាន។

ភាពខុសគ្នានេះពិតជាបង្កើនសមត្ថភាព ប៉ុន្តែព្រំដែនរវាងអ្វីដែលអាចធ្វើបាន និងអ្វីដែលមិនអាចធ្វើបានក៏បង្ហាញច្បាស់យ៉ាងឆាប់រហ័សដែរ។ បន្ទាប់ពីដំណើរការប៉ុន្មានជុំ អ្នកនឹងឃើញថាចំណុចរាំងស្ទះភាគច្រើនមិនមែនជាបញ្ហាបច្ចេកទេសទេ ប៉ុន្តែជាកម្រិតកំណត់នៅផ្នែកផ្សេង។

ការងារដែលអាចដំណើរការបានពិតប្រាកដនៅពេលនេះ

សេណារីយ៉ូដែលមានស្ថិរភាពនៅពេលនេះមានលក្ខណៈរួមមួយ៖ មនុស្សអាចពិនិត្យលទ្ធផលបានលឿន ហើយកំហុសមិនបង្កផលវិបាកដែលមិនអាចត្រឡប់វិញបាន។

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

ការបង្កើតសេចក្តីព្រាងមាតិកាជាច្រើន និងការសរសេរឡើងវិញក៏អាចប្រើបានហើយ។ នៅពេលមានប្រធានបទ Agent អាចប្រមូលព័ត៌មានសាធារណៈ រៀបចំជាកំណត់ត្រាមានរចនាសម្ព័ន្ធ និងបង្កើតគ្រោងសេចក្តីព្រាងដំបូង ដែលសន្សំពេលវេលាស្រាវជ្រាវបានច្រើន។ ការសរសេរឡើងវិញក៏ដូចគ្នា៖ មាតិកាវែងអាចបែងចែក និងកែតម្រូវតាមប្រវែង និងសម្លេងរបស់ channel ផ្សេងៗ ដោយមានកម្រិតបញ្ចប់ខ្ពស់។ ទោះយ៉ាងណា លទ្ធផលនៅតែជាសេចក្តីព្រាង។ ផ្នែកដែលត្រូវការបទពិសោធន៍ ការវិនិច្ឆ័យ ឬទស្សនៈ ត្រូវការមនុស្សបន្ថែម បើមិនដូច្នោះទេមាតិកានឹងខ្វះខ្លឹមសារ។

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

ការប្រៀបធៀបតម្លៃ និងការប្រមូលព័ត៌មានក៏មានស្ថិរភាពដូចគ្នា។ ការប្រមូលតម្លៃផលិតផលដូចគ្នាពី channel ផ្សេងៗ ភាពខុសគ្នានៃលក្ខណៈបច្ចេកទេស និងបណ្តឹងដែលកើតឡើងញឹកញាប់ក្នុង review ទៅក្នុងតារាងតែមួយ ជាញឹកញាប់មានភាពជឿជាក់ជាងការរុករកដោយដៃ។ ប្រសិនបើកំណត់វិមាត្រប្រៀបធៀបច្បាស់ លទ្ធផលភាគច្រើនអាចយកទៅប្រើបានភ្លាម។

សេណារីយ៉ូទាំងបួននេះក៏មានលក្ខខណ្ឌលាក់មួយទៀត៖ ព្រំដែនការងារត្រូវច្បាស់។ អ្នកកំណត់បានច្បាស់ប៉ុនណាថា “អ្វីជាទិន្នន័យចូល អ្វីជាលទ្ធផលចេញ ហើយពេលណាត្រូវឈប់” workflow ក៏ដំណើរការមានស្ថិរភាពប៉ុណ្ណោះ។

ការងារដែលមិនទាន់អាចដំណើរការបានល្អ

ផ្នែកម្ខាងទៀតក៏ច្បាស់ដែរ។ វាមិនមែនតែងតែជាបញ្ហាសមត្ថភាពរបស់ model ទេ ប៉ុន្តែជាកម្រិតកំណត់នៅក្នុងពិភពពិត។

ប្រតិបត្តិការដែលត្រូវការអត្តសញ្ញាណ account គឺជាឧទាហរណ៍ច្បាស់បំផុត។ ស្ថានភាព login ព័ត៌មានអត្តសញ្ញាណដែលបានផ្ទៀងផ្ទាត់ និងកេរ្តិ៍ឈ្មោះប្រវត្តិសាស្ត្រ សុទ្ធតែជាការអនុញ្ញាតដែល platform ផ្តល់ឱ្យអង្គភាពជាក់លាក់មួយ។ Agent មិនអាចទទួលបានសិទ្ធិនេះតាមវិធីបច្ចេកទេសតែប៉ុណ្ណោះទេ។ ការឱ្យ Agent “ដំណើរការ account” ខុសពីការឱ្យវា “ដំណើរការ dataset” ដោយមូលដ្ឋាន។

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

មានសកម្មភាពមួយចំនួនទៀតដែលត្រូវការការទទួលស្គាល់ ឬអនុម័តពី platform។ ការឆ្លងកាត់ការវាយតម្លៃ ការអនុម័តគុណវុឌ្ឍិ ការចុះឈ្មោះព្រឹត្តិការណ៍ ឬការអនុម័តមាតិកា សុទ្ធតែអាស្រ័យលើការសម្រេចរបស់ platform។ គ្មានផ្លូវកាត់បច្ចេកទេសដើម្បីរំលងការសម្រេចនោះទេ។ ការអះអាងថា tool អាចធានាលទ្ធផលបែបនេះជំនួសអ្នក ជាទូទៅមិនឈរលើការពិតទេ។

ការចុះឈ្មោះ account ជាច្រើន និងការធ្វើ task ដោយស្វ័យប្រវត្តិដើម្បីប្រមូលរង្វាន់ក៏មិនគួរជាផ្នែកនៃ workflow សមរម្យដែរ។ វាប៉ះទង្គិចនឹងច្បាប់ platform ដែលសរសេរច្បាស់បំផុតមួយចំនួន ហើយការរកឃើញមិនពិនិត្យតែសកម្មភាពមួយដងទេ។ ចង្វាក់ប្រតិបត្តិការ ផ្លូវឥរិយាបថ និងភាពស្របគ្នានៃ environment សុទ្ធតែអាចត្រូវបានពិចារណា។ ទោះបីដំណើរការបានតាមបច្ចេកទេស ក៏អាយុកាល account នៅតែអាស្រ័យលើអ្វីដែល platform ព្រមទទួល ហើយលក្ខខណ្ឌនេះអាចផ្លាស់ប្តូរបានគ្រប់ពេល។

ចំណុចត្រួតពិនិត្យដែលគួរទុកឱ្យមនុស្ស

Agent សមស្របបំផុតនៅពេលប្រើជាស្រទាប់អនុវត្ត។ ជំហានខាងក្រោមគួរទុកក្រោមការគ្រប់គ្រងរបស់មនុស្សជាប្រចាំ។

កំណត់គោលដៅ និងអាទិភាព។ ការសម្រេចថាត្រូវធ្វើអ្វី ប្រើស្តង់ដារអ្វី និងពេលណាត្រូវឈប់ មានទម្ងន់សំខាន់ជាងល្បឿនអនុវត្ត។ Agent មិនទទួលផលវិបាកជំនួសអ្នក ប្រសិនបើជ្រើសទិសដៅខុសទេ។

ពិនិត្យមាតិកាដែលផ្ញើចេញក្រៅ។ អ្វីក៏ដោយដែលនឹងត្រូវអានក្នុងនាមអ្នក—អ៊ីមែល ចម្លើយ post ឬរបាយការណ៍—គួរពិនិត្យម្តងមុនផ្ញើ។ មូលហេតុសាមញ្ញណាស់៖ បើខុស អ្នកជាអ្នកទទួលខុសត្រូវ។

បញ្ជាក់សកម្មភាពពាក់ព័ន្ធនឹងប្រាក់ និងសិទ្ធិ។ សិទ្ធិអានអាចបើកទូលំទូលាយ ដើម្បីឱ្យ Agent មើលទិន្នន័យ និងបង្កើតរបាយការណ៍បានគ្រប់ពេល។ ការកែសម្រួលធម្មតា ដូចជាប្តូរ parameter ឬផ្អាក task ដែលមានប្រសិទ្ធភាពទាប ក៏អាចប្រគល់ឱ្យវា។ ប៉ុន្តែការផ្លាស់ប្តូរធំ និងប្រតិបត្តិការជាច្រើនគួរឆ្លងកាត់ការបញ្ជាក់លើកទីពីរពីមនុស្ស។ វាជួយរក្សាទាំងប្រសិទ្ធភាព និងការគ្រប់គ្រង។

រក្សាទុកប្រវត្តិអនុវត្ត។ គួរកត់ត្រាថា Agent បានធ្វើអ្វី និងធ្វើតាមច្បាប់ណា។ ពេលមានបញ្ហា វាជាមូលដ្ឋានសម្រាប់ស្វែងរកមូលហេតុ ហើយក្នុងការងារធម្មតា វាក៏ជាទិន្នន័យសម្រាប់កែលម្អ workflow ផងដែរ។

នៅពេលចង់ដំណើរការ account ច្រើនជាងមុនព្រមគ្នា

បន្ទាប់ពី workflow មួយដំណើរការរលូន វាជារឿងធម្មតាដែលអ្នកនឹងសួរថា តើអាចយករបៀបនេះទៅប្រើលើ account ច្រើនទៀតបានឬទេ។

នៅដំណាក់កាលនេះ bottleneck ភាគច្រើនមិនមែន Agent ទេ ប៉ុន្តែជាបរិស្ថាន account។ ប្រសិនបើ account ច្រើនដំណើរការនៅក្នុង browser environment ដូចគ្នា និងតាម network egress ដូចគ្នា platform អាចចងវាជាក្រុមបានងាយ ហើយដោះស្រាយជាក្រុមតែមួយ។ វិធីអនុវត្តបានគឺផ្គូផ្គង account និង environment មួយទល់មួយ៖ account នីមួយៗមាន browser environment ឯករាជ្យ និង network egress ថេរ ហើយពេលដំណើរការ task ត្រូវផ្ទុក environment ដែលសមស្របនឹង account នោះ។ Tool ដូចជា PurpleMark ផ្តល់សមត្ថភាពគ្រប់គ្រង environment ច្រើនបែបនេះ និងអាចធ្វើការជាមួយ script ដែលប្តូរ environment តាម account។

ប៉ុន្តែកុំបញ្ច្រាសលំដាប់។ ការបំបែក environment ដោះស្រាយតែសំណួរថា account “មើលទៅដូចជាអ្នកប្រើឯករាជ្យឬទេ” ប៉ុណ្ណោះ។ វាមិនអាចឆ្លើយថា “សកម្មភាពនេះគួរធ្វើឬទេ”។ សកម្មភាពរបស់ account ត្រូវគោរពច្បាប់ជាមុនសិន ទើបការបំបែក environment មានន័យ។

លំដាប់ដាក់ឱ្យដំណើរការដែលមានហានិភ័យទាប

ចាប់ផ្តើមពីសេណារីយ៉ូតូច និងច្បាស់មួយ មិនមែនស្វ័យប្រវត្តិកម្មដំណើរការទាំងមូលភ្លាមៗទេ។ ពិនិត្យថាលទ្ធផលអាចប្រើបានផ្ទាល់ឬអត់; ប្រសិនបើអាច ប្រើជំហានបន្ទាប់។ កំណត់ព្រំដែនសិទ្ធិតាំងពីដំណាក់កាលនេះ ជាពិសេស write permission និងសកម្មភាពពាក់ព័ន្ធនឹងប្រាក់។ ឱ្យ workflow មួយដំណើរការមានស្ថិរភាពមួយរយៈ មុនពង្រីកទៅ account ច្រើន ហើយរៀបចំ environment isolation មុន scale។

លំដាប់នេះយឺតបន្តិច ប៉ុន្តែតម្លៃនៃការបរាជ័យនៅរាល់ជំហានទាប ហើយចំណេះដឹងដែលទទួលបាននៅរាល់ដំណាក់កាលអាចយកទៅប្រើឡើងវិញបាន។