ពិធីការ MCP និង Browser Agent៖ ពីការតភ្ជាប់ N×M មកការតភ្ជាប់តែម្តង

នៅពេល Agent ត្រូវធ្វើការងារពិតប្រាកដ វាធម្មតាចុងក្រោយត្រូវប្រើ browser៖ login, បង្ហោះមាតិកា, ប្រមូលទិន្នន័យ ឬបំពេញ form។ ចំណុចលំបាកផ្នែកបច្ចេកទេសមិនមែនថាអាច click បានឬអត់ទេ ប៉ុន្តែជាថ្លៃដើមនៃការតភ្ជាប់ browser ឲ្យ Agent ប្រើ។

អន្ទាក់នៃការសម្របសម្រួល N×M

សន្មត់ថាមានឧបករណ៍ N និងម៉ូឌែល M នៅលើទីផ្សារ។ អ្នកផ្តល់ឧបករណ៍ត្រូវសរសេរកូដតភ្ជាប់សម្រាប់ម៉ូឌែលនីមួយៗ ខណៈផ្នែកម៉ូឌែលក៏ត្រូវមានស្រទាប់សម្របសម្រួលសម្រាប់ឧបករណ៍នីមួយៗដែរ។ ភាគីទាំងពីរថែទាំការអនុវត្តរបស់ខ្លួន ដូច្នេះសរុបក្លាយជា N×M។

បញ្ហាគឺវាជាការគុណ។ បន្ថែមឧបករណ៍មួយ មិនមែនមានការងារបន្ថែមតែមួយទេ តែត្រូវភ្ជាប់ឧបករណ៍នោះជាមួយម៉ូឌែលគ្រប់មួយ។ ផ្ទុយទៅវិញ ពេលម៉ូឌែលប្តូរកំណែ ឧបករណ៍ដែលបានភ្ជាប់រួចអាចត្រូវផ្ទៀងផ្ទាត់ឡើងវិញ។ សមត្ថភាពមួយអាចល្អប៉ុណ្ណាក៏ដោយ បើគ្មាន adapter សម្រាប់ម៉ូឌែលណាមួយ វាក៏មិនអាចប្រើបាន ហើយឧបករណ៍ត្រូវជាប់នៅជំហានចែកចាយ។

នៅដំណាក់កាលដំបូង ម្នាក់ៗត្រូវសរសេររបស់ខ្លួន។ ការងារដូចគ្នា—រាយ environment, ចាប់ផ្តើម browser, អាន page—ត្រូវសរសេរឡើងវិញពេល caller ផ្លាស់ប្តូរ ហើយ logic ក៏ជាញឹកញាប់មិនដូចគ្នា៖ ខ្លះដាក់ការរង់ចាំនៅ client ខ្លះនៅ server។

ពិធីការបំបែកភាគីទាំងពីរ

MCP (Model Context Protocol) ត្រូវបានបង្ហាញជាសាធារណៈនៅចុងឆ្នាំ 2024។ វាកំណត់ការស្វែងរក និងការហៅឧបករណ៍ជាទម្រង់ស្តង់ដារ៖ តើបង្ហាញអ្វី បរិយាយ parameters ដូចម្តេច និងត្រឡប់ structure អ្វី—ទាំងអស់ត្រូវបានកំណត់ក្នុងពិធីការ។

ស្ថាបត្យកម្មក្លាយជា Agent ភ្ជាប់ទៅ MCP Client ហើយ Client ភ្ជាប់ទៅ MCP Server ច្រើនតាមពិធីការ ខណៈសមត្ថភាពពិតស្ថិតនៅពីក្រោយ Server។ បរិមាណការអនុវត្តថយពី N×M ទៅ N+M៖ ផ្នែកម៉ូឌែលអនុវត្ត client ម្តង និងផ្នែកឧបករណ៍អនុវត្ត server ម្តង។

មានតែតួនាទីបី។ Host ជា application ដែលដំណើរការម៉ូឌែល និងចាប់ផ្តើម client។ Client ជាការអនុវត្ត protocol client ដែលជាទូទៅមួយសម្រាប់ Server មួយ។ Server សរសេរដោយអ្នកផ្តល់ឧបករណ៍ ហើយបង្ហាញសមត្ថភាពជាឧបករណ៍ស្តង់ដារ។

បច្ចុប្បន្នមានរបៀបទំនាក់ទំនងពីរ។ Local mode ប្រើ standard input/output ដោយ client និង server នៅលើម៉ាស៊ីនតែមួយ; ផ្លូវខ្លី និងការកំណត់តិច ដូច្នេះប្រើច្រើនសម្រាប់ automation។ Remote mode ប្រើ HTTP ឬ WebSocket ហើយសមស្របសម្រាប់ distributed deployment ប៉ុន្តែត្រូវគិតបន្ថែមអំពី authentication និង network boundaries។

ក្នុង browser មានសមត្ថភាពបីស្រទាប់

ពេលភ្ជាប់ browser environment ចូលពិធីការ សមត្ថភាពដែលបង្ហាញចេញជាទូទៅចែកជា៣ស្រទាប់។

ស្រទាប់លើគេគឺ environment៖ រាយ environment ក្នុង account, បង្កើតថ្មីតាម configuration, ចាប់ផ្តើម environment កំណត់មួយ, ភ្ជាប់ network egress និងបិទក្រោយប្រើ។ កន្លងមកសកម្មភាពទាំងនេះបែកចែកនៅក្នុង API របស់អ្នកផ្តល់ផ្សេងៗ; ឥឡូវវាជាឧបករណ៍ដែលម៉ូឌែលអាចរកឃើញ និងហៅបាន។ ក្រោយចាប់ផ្តើម ជាធម្មតានឹងត្រឡប់ debugging endpoint ដូចជា port ឬ WebSocket address ដែលអាចផ្ញើទៅ driver ដូចជា Selenium ឬ Puppeteer។

ស្រទាប់កណ្តាលគឺ page៖ បើក address, អាន DOM ឬ accessibility tree, ប្តូរ tab និងថត screenshot។

ស្រទាប់ក្រោមគឺ action៖ click, បញ្ចូលអត្ថបទ, scroll, រង់ចាំលក្ខខណ្ឌមួយ និងដោះស្រាយ pop-up។

ការផ្លាស់ប្តូរសំខាន់មិនមែននៅចំនួន action ទេ។ Environment ផ្លាស់ពីកូដដែលត្រូវសរសេរខ្លួនឯង ទៅជាធនធានដែល Agent អាចជ្រើស និងប្រើដោយខ្លួនឯង។ អ្នកគ្រាន់តែប្រាប់គោលដៅឲ្យច្បាស់; Agent អាចសម្រេចថាត្រូវបង្កើត environment ថ្មី ឬប្រើមួយដែលមានស្រាប់ និងហៅឧបករណ៍តាមលំដាប់ណា។ នៅពេលប្រើ environment ច្រើនស្របគ្នា វាកាន់តែច្បាស់៖ scheduling ស្ថិតក្នុង prompt ជំនួសឲ្យ hard-code ក្នុង script។

អ្វីដែលនៅមិនទាន់ដោះស្រាយ

ពិធីការដោះស្រាយការតភ្ជាប់ មិនមែនភាពត្រឹមត្រូវ។ មានចំណុចមួយចំនួនដែលងាយមើលរំលង។

គុណភាពនៃការពិពណ៌នាឧបករណ៍កំណត់លទ្ធផលនៃការហៅ។ បើ parameters ខុស ឬជ្រើសឧបករណ៍ខុស ពិធីការមិនអាចជួយបាន។ ពេលឧបករណ៍កាន់តែច្រើន ការពិពណ៌នាក៏ប្រើ context ដែរ ដូច្នេះត្រូវមានតុល្យភាពរវាងចំនួន និង granularity។ បើធំពេក ម៉ូឌែលមិនដឹងថាឧបករណ៍មួយធ្វើបានប៉ុន្មានរឿង; បើលម្អិតពេក context នឹងពេញមុន។

Permissions និង auditing នៅដំណាក់កាលដំបូង។ Server ជាច្រើនជាប្រភេទ local single-machine ដែលមានសិទ្ធិខ្ពស់តាំងពីចាប់ផ្តើម ហើយខ្វះ fine-grained authorization និង call records។ Remote mode ត្រូវកំណត់សិនថានរណាអាចភ្ជាប់ និងអាចមើលអ្វីបាន។

ភាពមិនស្ថិតស្ថេររបស់ page ក៏មិនបាត់ទេ។ រក element មិនឃើញ, loading timing មិនថេរ, login session ផុតកំណត់ និង CAPTCHA នៅតែត្រូវការការរង់ចាំ, retry និង fallback។ ពិធីការគ្រាន់តែធ្វើឲ្យ entry point ដូចគ្នា។

ភាពចាស់ទុំរបស់ ecosystem ក៏មិនស្មើគ្នា។ Server ផ្សេងៗមិនដូចគ្នាទាំងស្រុងលើ resource types, return structures និង error codes។ ពេលផ្សំ Server ច្រើនសម្រាប់ task មួយ orchestration logic ជាញឹកញាប់នៅតែត្រូវសរសេរខ្លួនឯង។ ពិធីការក៏កំពុងវិវត្ត ដូច្នេះត្រូវប្រុងប្រយ័ត្នចំពោះ behavior differences រវាង versions។

មានព្រំដែនមួយទៀតត្រូវបែងចែកឲ្យច្បាស់៖ ពិធីការគ្រប់គ្រងរបៀបដែលម៉ូឌែលហៅឧបករណ៍ មិនមែនថា task ខ្លួនវាស្របច្បាប់ ឬស្របបទបញ្ជាឬអត់ទេ។ ការប្រមូលទិន្នន័យមានការអនុញ្ញាតឬអត់ គោលបំណងប្រើ account ត្រឹមត្រូវឬអត់ និងបំពាន platform rules ឬអត់ គឺជាការវាយតម្លៃដាច់ដោយឡែក និងមិនពាក់ព័ន្ធនឹងថាការតភ្ជាប់រលូនប៉ុណ្ណា។

ក្នុងសេណារីយ៉ូ multi-environment ការដាច់ពីគ្នារវាង environment និងការកំណត់ network egress, timezone និង language ជាប្រព័ន្ធតែមួយ ជាញឹកញាប់មានឥទ្ធិពលលើលទ្ធផលច្រើនជាងវិធី integration។ នៅស្រទាប់ environment isolation, PurpleMark ផ្តល់ interface សម្រាប់បង្កើត ចាប់ផ្តើម និងកំណត់ network ដែល AI tools អាចហៅ ហើយ client តែមួយអាចធ្វើ scheduling បាន។

អត្ថបទនេះគ្រាន់តែពន្យល់គោលការណ៍បច្ចេកទេសប៉ុណ្ណោះ។ សូមប្រើពិធីការ និងឧបករណ៍ដែលពាក់ព័ន្ធដោយគោរពច្បាប់ និងបទបញ្ជាដែលអនុវត្ត។