WebMCP मूल परीक्षण में शामिल हों

Chrome 149 द्वारा WebMCP मूल परीक्षण प्रदान करना शुरू करने के बाद, वेब पेज और प्रॉक्सी के बीच संबंध अधिक प्रत्यक्ष हो जाएगा: पेज अब मशीन के अनुमान लगाने के लिए केवल DOM और दृश्यमान प्रतिलिपि नहीं देता है, नियंत्रण स्वयं उद्देश्य, स्थिति और निष्पादन योग्य सीमाओं की भी घोषणा कर सकता है। यह परिवर्तन एक एपीआई परीक्षण की तरह दिखता है, लेकिन वास्तव में यह “इंटरफ़ेस इरादे” को अंतर्निहित जानकारी से स्पष्ट प्रोटोकॉल तक उठाने जैसा है।

WebMCP जैसी किसी चीज़ का मूल्य वेब पेज पर शब्दावली की एक परत जोड़ना नहीं है, बल्कि उस अनिश्चितता को मजबूत करना है जिससे एजेंट सबसे अधिक डरते हैं। चाहे कोई बटन सबमिट करना हो, स्विच करना हो, पुष्टि करना हो या बस एक पॉप-अप परत खोलना हो; क्या कोई इनपुट बॉक्स कोई दिनांक, कोई खोज शब्द, या कोई अपॉइंटमेंट समय है जिसके लिए एक विशेष प्रारूप की आवश्यकता होती है। अतीत में, यह जानकारी मुख्य रूप से पाठ, संरचना और संदर्भ से अनुमानित की जाती थी। अनुमान काम करता है, लेकिन एक बार जब पृष्ठ जटिल हो जाता है, तो एजेंट “है” के लिए “जैसा दिखता है” की गलती करना शुरू कर देता है।

मनुष्यों के लिए, यह गलत पढ़ना आमतौर पर केवल एक गलत क्लिक है। एजेंटों के लिए, गलत रीडिंग त्रुटियों के एक स्थिर मार्ग में बदल जाती है। यह गलत समझ के साथ तब तक क्रियान्वित होता रहेगा जब तक कि इसे सत्यापन, रोलबैक या साइड इफेक्ट का सामना नहीं करना पड़ता है, जिससे पता चलता है कि पिछला चरण भटक गया है। WebMCP शब्दार्थ की इस परत को स्पष्ट करने के बाद, एजेंट को पृष्ठ को विशुद्ध रूप से दृश्य मानचित्र के रूप में अनुमान लगाने की आवश्यकता नहीं होती है, और वेब पेज मुख्य इंटरैक्शन सतहों की जिम्मेदारियों को भी स्पष्ट रूप से समझा सकता है।

यह मामला उन इंटरफेस के लिए सबसे उपयुक्त है जिन्हें शुद्ध HTML कॉपी राइटिंग के साथ समझाना मुश्किल है, जैसे कि कैलेंडर, आरक्षण, अनुमति एप्लिकेशन, सेटिंग्स पैनल, या पृष्ठों का एक समूह जो सामान्य इनपुट बॉक्स की तरह दिखते हैं लेकिन वास्तव में अलग-अलग व्यावसायिक अर्थ होते हैं। केवल लेबल और प्लेसहोल्डर पर निर्भर रहने पर, एजेंट को अक्सर पृष्ठ के चारों ओर घूमना पड़ता है और बार-बार प्रयास करना पड़ता है; एक बार जब पृष्ठ “यहां दिनांक चयन है” “यहां पुष्टिकरण कार्रवाई है” और “यहां स्थिति केवल इस दिशा में बदल सकती है” घोषित कर सकता है, तो एकीकरण लागत सीधे कम हो जाएगी।

लेकिन मूल परीक्षण एक और मुद्दा भी उठाता है: शब्दार्थ की इस परत को बनाए रखने की आवश्यकता है। पृष्ठ संरचना बदल जाएगी, बटन कॉपी बदल जाएगी, और व्यवसाय की स्थिति बदल जाएगी। यदि इरादे की वह परत जिस पर एजेंट वास्तव में भरोसा करता है, घटकों के साथ अद्यतन नहीं की जाती है, तो यह जल्द ही बह जाएगी। उस समय, सबसे खतरनाक राज्य “पूरी तरह से अनुपयोगी” नहीं है, लेकिन “अभी भी चल सकता है, लेकिन कभी-कभी गलतियाँ करता है, और गलतियाँ स्वाभाविक हैं।”

इसलिए, वेबएमसीपी एजेंट को पोस्ट किए गए अनुस्मारक कार्ड के बजाय वेब पेज के लिए एक अनुबंध की तरह है। कार्यान्वयन में, परीक्षणों में और प्रतिगमन जांचों में इंटरैक्शन सीमाओं को लिखने के लिए फ्रंट एंड की आवश्यकता होती है। जब तक अनुबंध की यह परत अभी भी प्रदर्शन चरण में है, एजेंट समझ सकता है कि सफलता का मामला है; जब यह वास्तविक पृष्ठ में प्रवेश करता है, तो वास्तव में संस्करण संगतता, डाउनग्रेड पथ और घोषणा के अमान्य होने के बाद समाधान से निपटने की आवश्यकता होती है।

मैं इस मूल परीक्षण को एक दिशात्मक संकेत मानना ​​पसंद करता हूँ। ब्राउज़रों ने गंभीरता से इस बात पर विचार करना शुरू कर दिया कि एजेंट वेब पेज कैसे पढ़ते हैं, जिसका अर्थ है कि फ्रंट एंड न केवल लोगों के लिए प्रारूपण कर रहा है, बल्कि मशीनों के लिए कार्यों को भी परिभाषित कर रहा है। पृष्ठ जितना अधिक जटिल होगा, परिभाषा की यह परत उतनी ही अधिक मूल्यवान होगी; जितनी अधिक बार पृष्ठ बदला जाता है, परिभाषा की इस परत की रखरखाव लागत उतनी ही अधिक महत्वपूर्ण होती है। WebMCP जैसी क्षमताओं की अंतिम विरासत कोई नया शब्द नहीं होगा, बल्कि फ्रंट एंड और एजेंट के बीच निरंतर संरेखण के लिए एक शब्द होगा।