ब्राउज़र रैपर से सीमित कंप्यूटर उपयोग तक

• कंप्यूटर उपयोग क्या है और यह महत्वपूर्ण क्यों है? कंप्यूटर उपयोग एक सरल विचार है, जिसके प्रभाव व्यापक हैं: मॉडल से सवालों के जवाब माँगने के बजाय हम उनसे सॉफ़्टवेयर चलाने को कहते हैं—वे वेबसाइट पर नेविगेट करें, फ़ॉर्म भरें, प्रक्रियाओं में क्लिक करते हुए आगे बढ़ें और शुरू से अंत तक कार्य स्वायत्त रूप से पूरे करें.

• इससे वास्तविक दुनिया के ऐसे बहुत से कार्य संभव हो जाते हैं जो अभी अलग-अलग इंटरफ़ेस में बँटे हैं, जैसे शुरू से अंत तक बुकिंग, ई-कॉमर्स चेकआउट, कई चरणों वाली यात्रा योजना और ऐसी प्रशासनिक प्रक्रियाएँ जिनके लिए कोई स्पष्ट एपीआई विकल्प नहीं है. ये समस्याएँ नई नहीं हैं. नई बात यह है कि अब सामान्य-उद्देश्य वाले मॉडल से इन्हें हल करना संभव है.

• Anthropic और OpenAI के हालिया सिस्टम ने ऐसे एजेंट दिखाए हैं जो केवल कार्रवाई ही नहीं करते, बल्कि स्थिति पर रीज़निंग करते हैं, त्रुटियों से उबरते हैं और तुरंत कार्य-विशिष्ट समाधान तैयार करते हैं. इससे ब्राउज़र एजेंट के लिए एक सामान्य निष्पादन परिवेश बन जाता है, लेकिन डिज़ाइन से जुड़ा एक तात्कालिक सवाल भी उठता है: इस परिवेश का कितना हिस्सा मॉडल को उपलब्ध कराया जाए?

• शुरुआती सिस्टम ने ब्राउज़र को सुरक्षित और पहले से तय कार्रवाइयों के निश्चित समूह में बाँधकर इसका जवाब दिया. जैसा कि हम इस लेख में बताएँगे, यह तरीका अब अपनी सीमाओं तक पहुँच रहा है.

ब्राउज़र एजेंट बनाते समय एक परिचित धारणा होती है: मॉडल पर बहुत अधिक भरोसा न करें.

इसलिए हम ब्राउज़र पर रैपर लगाते हैं. हम क्लिक करना, टाइप करना, स्क्रॉल करना, चुनना और read_text जैसे पहले से तय टूल उपलब्ध कराते हैं. हम डॉक्यूमेंट ऑब्जेक्ट मॉडल (DOM) को सरल बनाते हैं. हम संभावित कार्रवाइयों का दायरा घटाते हैं. हम अपने बनाए अमूर्तन के जरिए व्यवहार को समझने और नियंत्रित करने योग्य बनाने की कोशिश करते हैं.

शुरुआत के लिए यह उचित तरीका है. लेकिन दीर्घकाल में यह लगातार गलत आर्किटेक्चर भी साबित हो रहा है.

अत्याधुनिक मॉडल बेहतर होने के साथ अब समस्या केवल यह नहीं रह गई है कि मॉडल के पास टूल नहीं हैं. समस्या यह है कि हम उसे ऐसे अमूर्तन के जरिए काम करने को मजबूर कर रहे हैं जो मूल सिस्टम की बहुत-सी जानकारी हटा देते हैं. हम एक अव्यवस्थित और गतिशील परिवेश को कार्रवाइयों के निश्चित इंटरफ़ेस में समेट देते हैं, फिर मॉडल से जानकारी के इस नुकसान के बीच अच्छा प्रदर्शन करने को कहते हैं.

यह समझौता अब कम आकर्षक होता जा रहा है.

जिस बदलाव पर हम काम कर रहे हैं, उसे समझाना आसान है, लेकिन उसके परिणाम महत्वपूर्ण हैं. एजेंट को पहले से तय कार्रवाइयों का चयनकर्ता मानने के बजाय, हम उसे सीमित रनटाइम में काम करने वाला प्रोग्राम निर्माता मानते हैं.

मॉडल बहुत सक्षम हो गए हैं और अब उन्हें आपके अमूर्त सुरक्षा-बाड़ों की जरूरत नहीं है—उन्हें कार्य की योजना बनाने, उसे पूरा करने और लक्ष्य मिलने तक उसमें सुधार करते रहने के लिए कार्रवाइयों का पूरा दायरा चाहिए.

यह लेख अमूर्तन पर अत्यधिक निर्भर ब्राउज़र स्वचालन से सीमित कंप्यूटर उपयोग की ओर इसी बदलाव और इस तरह सिस्टम डिज़ाइन करने पर होने वाले परिवर्तनों के बारे में है.

समस्या यह नहीं है कि कार्रवाइयों के निश्चित इंटरफ़ेस वैचारिक रूप से गलत हैं. समस्या यह है कि वेब उनके अनुरूप नहीं चलता.

आधुनिक इंटरफ़ेस React, Vue और Angular पर बने होते हैं. इनमें असिंक्रोनस स्थिति अपडेट, कृत्रिम ईवेंट सिस्टम और अपने जीवनचक्र वाले क्रॉस-ओरिजिन iframe में मौजूद बाहरी पक्ष के विजेट होते हैं. “इस इनपुट में टाइप करें” कहने वाला रैपर तभी सही है, जब पेज टाइप करने की आपकी परिभाषा से सहमत हो. कई पेज सहमत नहीं होते. किसी मान को सीधे सेट करने से अक्सर फ़्रेमवर्क की बदलाव पहचान प्रणाली पूरी तरह छूट जाती है. इनपुट भरा हुआ दिखाई देता है. सत्यापन कभी शुरू नहीं होता. फ़ॉर्म काम नहीं करता.

आप इसे सुधार सकते हैं. आप React इनपुट के लिए विशेष मामले जोड़ सकते हैं, फ़ोकस के बाद ब्लर ईवेंट भेज सकते हैं और स्थिति पढ़ने से पहले नेटवर्क निष्क्रिय होने की प्रतीक्षा कर सकते हैं. हर सुधार अपने स्तर पर सही होता है. लेकिन साथ मिलकर ये ऐसे सिस्टम में बदल जाते हैं जिसका रखरखाव लगातार कठिन होता जाता है और जो केवल पहले से देखी गई साइटों के लिए अधिक विशिष्ट बनता जाता है.

मूल समस्या यह है कि आप अमूर्तन परत में इंटरैक्शन के काम करने के तरीके से जुड़ी धारणाएँ कोड करते हैं, फिर पता चलता है कि वेब की धारणाएँ अलग हैं.

Stripe या Adyen के जरिए क्रॉस-ओरिजिन iframe में एम्बेड किए गए भुगतान फ़ॉर्म पर विचार करें. आपका रैपर उस तक सीधे नहीं पहुँच सकता, क्योंकि वह एक अलग ओरिजिन में मौजूद है. आपका read_text टूल उसकी आंतरिक स्थिति नहीं देख सकता. आपका टाइप करने वाला टूल उसके इनपुट तक नहीं पहुँच सकता. रैपर-आधारित एजेंट यहाँ आकर रुक जाता है. अमूर्तन मुख्य दस्तावेज़ के लिए बनाया गया था. वास्तविक कार्य ऐसी जगह है जिसे अमूर्तन देख ही नहीं सकता.

कम स्पष्ट प्रक्रियाओं में भी ऐसा ही बेमेल दिखाई देता है. फ़्रेमवर्क से नियंत्रित ड्रॉपडाउन सीधे क्लिक करने पर बिल्कुल प्रतिक्रिया न दे, क्योंकि दिखाई देने वाला तत्व वास्तविक नियंत्रण नहीं होता. मूल स्थिति परिवर्तन शुरू करने के लिए कीबोर्ड ईवेंट का एक क्रम जरूरी हो सकता है. बाहर से यूज़र इंटरफ़ेस क्लिक करने योग्य दिखता है. अमूर्तन कहता है, “क्लिक करें.” कुछ नहीं होता.

या कई चरणों वाली ऐसी मोडल प्रक्रिया पर विचार करें जिसमें दिखने वाले DOM के अपडेट आंतरिक स्थिति में हुए बदलावों के बाद दिखाई देते हैं. अगली सही कार्रवाई ऐसे स्थिति परिवर्तन पर निर्भर करती है जो अभी आपके रैपर को दिखाई देने वाले तत्वों में दर्ज नहीं हुआ है. रैपर-आधारित एजेंट बहुत जल्दी कार्रवाई कर देता है या पुरानी स्थिति पढ़ता है, क्योंकि वह सिस्टम के अधूरे दृश्य पर काम कर रहा होता है.

हर मामले में अमूर्तन उन संकेतों को छिपा देता है जिनकी एजेंट को वास्तव में जरूरत होती है.

निचले स्तर पर काम करने वाला मॉडल—जो सक्रिय DOM की जाँच करता है, फ़्रेम की सीमाओं पर रीज़निंग करता है और उस विशिष्ट सतह के लिए इंटरैक्शन क्रम बनाता है—इन स्थितियों को संभाल सकता है. ऐसा नहीं है कि मॉडल स्वाभाविक रूप से अधिक बुद्धिमान है. बात यह है कि अब उसके पास वह जानकारी उपलब्ध है जिसे हटा दिया गया था.

हम जिस बदलाव की दिशा में काम कर रहे हैं, उसे समझाना आसान है: मॉडल से पहले से तय कार्रवाइयाँ चुनने को कहने के बजाय, हम उसे निचले स्तर की निष्पादन सतह देते हैं और अमूर्तन डिज़ाइन के बजाय रनटाइम नीति से उस सतह को सीमित करते हैं.

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

कई डेवलपर के टूल संग्रह में प्रमुख विकल्प के रूप में Claude Code की सफलता और टर्मिनल-आधारित एजेंट की ओर उद्योग के व्यापक रुझान पर विचार करें. Claude Code का सबसे बड़ा लाभ स्वयं मॉडल नहीं, बल्कि निचले स्तर का हार्नेस है. मॉडल को कम संख्या में, अधिक मॉड्यूलर और निचले स्तर के टूल देना—यानी टर्मिनल देना—टूल कॉल करने का प्रदर्शन बेहतर करता है. इसका मुख्य कारण यह है कि एजेंट कॉन्टेक्स्ट विंडो को अनावश्यक रूप से भरने वाले सामान्यीकृत टूल इस्तेमाल करने के बजाय मौजूदा कार्य पर रीज़निंग कर सकता है और उसके लिए विशिष्ट स्क्रिप्ट बना सकता है.

ब्राउज़र स्वचालन में व्यवहारतः इसका अर्थ है कि मॉडल हर चीज़ को पहले से बनी निश्चित कार्रवाइयों से जोड़ने के बजाय सक्रिय पेज की स्थिति सीधे जाँच सकता है, फ़्रेम में जा सकता है और मौजूदा इंटरफ़ेस के लिए खास इंटरैक्शन कोड बना सकता है.

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

महत्वपूर्ण बात यह है कि अमूर्तन परत हटाने से सिस्टम का अनुशासन कम नहीं होता. अनुशासन बस दूसरी जगह चला जाता है.

जो काम पहले रैपर डिज़ाइन और असामान्य मामले संभालने में होता था, वह अब तीन जगह होता है: प्रॉम्प्ट में, जो संचालन प्रशिक्षण का रूप लेता है; रनटाइम में, जो नेविगेशन के दायरे, संवेदनशील कार्रवाइयों और दोबारा प्रयास के व्यवहार जैसी सीमाएँ लागू करता है; और मूल्यांकन परत में, जो केवल यह नहीं जाँचती कि कार्य सफल हुआ या नहीं, बल्कि यह भी देखती है कि बीच के चरण सही थे या नहीं. कम नाजुक अमूर्तन. अधिक मजबूत सहायक सिस्टम.

इस बदलाव का एक परिणाम यह है कि समग्र सिस्टम की क्षमता बढ़ने के बावजूद उत्पाद कोड अक्सर सरल हो जाता है. इंटरैक्शन पैटर्न को दोबारा इस्तेमाल किए जा सकने वाले रैपर के रूप में कोड करने के बजाय, एजेंट रनटाइम पर व्यवहार तैयार करता है. विशेष टूल और असामान्य मामलों के लिए लॉजिक का दायरा बढ़ाते रहने के बजाय, आप शक्तिशाली मूल घटकों का एक छोटा समूह और सीमित निष्पादन परिवेश बनाए रखते हैं.

इससे सिस्टम के सामान्यीकरण का तरीका भी बदल जाता है. रैपर-आधारित एजेंट उन कार्यों पर अच्छी तरह सामान्यीकरण करता है जो आपके पहले से बनाए रैपर जैसे होते हैं. सीमित रनटाइम वाला एजेंट साझा निष्पादन आधार वाले कार्यों पर सामान्यीकरण करता है, भले ही उनका दिखने वाला इंटरफ़ेस अलग हो.

उदाहरण के लिए, यूज़र इंटरफ़ेस के स्तर पर खोज फ़ॉर्म, बुकिंग प्रक्रिया या सेटिंग पेज से इंटरैक्ट करना बिल्कुल अलग दिख सकता है. लेकिन भीतर से उनमें समान पैटर्न होते हैं: स्थिति पढ़ना, ईवेंट शुरू करना, परिणामों की पुष्टि करना और असिंक्रोनस अपडेट संभालना. उस स्तर पर काम करने वाला सिस्टम विभिन्न कार्यों में अधिक सहजता से ढलता है.

दोबारा इस्तेमाल किया जा सकने वाला घटक कार्रवाइयों की सूची नहीं, बल्कि स्थिति की जाँच करने, सुरक्षित ढंग से काम करने और परिणाम सत्यापित करने की मॉडल की क्षमता है.

इस काम से मिली सबसे स्पष्ट सीख यह है कि मॉडल को अधिक सहायक फ़ंक्शन देने से विश्वसनीयता नहीं आती. यह अक्सर उसे कम लेकिन अधिक शक्तिशाली मूल घटक देने और उन पर सही सीमाएँ लगाने से आती है. जरूरत से ज्यादा सहायता में किसी कार्य को करने के तरीके से जुड़ी धारणाएँ स्थायी रूप से कोड कर दी जाती हैं. सीमाएँ सुरक्षित संचालन की हद तय करती हैं और मॉडल को बेहतर स्थानीय समाधान खोजने देती हैं.

अधिक शक्तिशाली निष्पादन सतह के लिए अधिक सुदृढ़ सुरक्षा मॉडल भी चाहिए. जब एजेंट पहले से तय कुछ कार्रवाइयों तक सीमित नहीं रहता, तो वह वास्तव में सीधे असली सॉफ़्टवेयर पर काम कर रहा होता है. इससे जोखिम का स्वरूप तुरंत बदल जाता है.

डिज़ाइन में इन चार चिंताओं का ध्यान रखना चाहिए:

डेटा का उजागर होना. अगर एजेंट असली इंटरफ़ेस के साथ इंटरैक्ट कर रहा है, तो उसे अक्सर संवेदनशील जानकारी मिलेगी. इसके लिए डेटा छिपाने और पहुँच नियंत्रित करने का अनुशासित तरीका चाहिए. डेटा केवल तभी दिखाया जाना चाहिए जब निष्पादन के लिए जरूरी हो. लॉग और ट्रेस भी सावधानी से संभालने चाहिए, ताकि निगरानी की व्यवस्था सिस्टम का सबसे संवेदनशील हिस्सा न बन जाए.

निष्पादन का दायरा. शक्तिशाली एजेंट को मनमाने ढंग से काम करने की अनुमति नहीं होनी चाहिए. व्यवहार में इसका अर्थ है कि उसके नेविगेशन, पहुँच योग्य डोमेन और इंटरैक्ट करने की अनुमति वाले सिस्टम पर सीमाएँ लगाई जाएँ. इन सीमाओं को प्रॉम्प्ट में निर्देश भर मानने के बजाय रनटाइम स्तर पर लागू किया जाना चाहिए.

परिवेश पर भरोसा. आधुनिक इंटरफ़ेस में भ्रामक या सक्रिय रूप से दुर्भावनापूर्ण निर्देश, सामग्री या प्रक्रियाएँ हो सकती हैं. पेज की सामग्री से होने वाला प्रॉम्प्ट इंजेक्शन हमले का वास्तविक माध्यम है. एजेंट को अनचाहे निर्देशों का पालन करने से रोकने के लिए सिस्टम में निर्देशों का स्पष्ट पदानुक्रम, सत्यापन जाँच और समाप्ति की शर्तें होनी चाहिए.

स्वायत्तता का दायरा. हर कार्रवाई पूरी तरह स्वायत्त नहीं होनी चाहिए. कई उत्पादन परिवेशों में स्वायत्तता को एक दायरे के रूप में देखना जरूरी है. सिस्टम खोज और निष्पादन में काफी हद तक एजेंट की तरह काम कर सकता है, फिर भी कुछ श्रेणियों की कार्रवाइयों के लिए अनुमति जरूरी रखी जा सकती है.

मूल सिद्धांत सीधा है: मॉडल को अधिक शक्ति देने के साथ उसके सहायक सिस्टम को भी अधिक मजबूत बनाना पड़ता है. नीति के बिना स्वायत्तता उत्पादन के लिए तैयार नहीं है.

हमने यह पूछना छोड़ दिया: ब्राउज़र की किन कार्रवाइयों को उपलब्ध कराना सही होगा?

हमने पूछना शुरू किया: मॉडल को कार्रवाइयों का पूरा दायरा कैसे दिया जाए—और उसके आसपास ऐसी रनटाइम नीतियाँ कैसे बनाई जाएँ जो इसे सुरक्षित भी रखें?

यह नया दृष्टिकोण आपकी प्राथमिकताएँ बदल देता है. कार्रवाइयों का वर्गीकरण और रैपर की पूर्णता कम महत्वपूर्ण हो जाते हैं. रनटाइम नीति, निगरानी और प्रत्येक चरण का मूल्यांकन अधिक महत्वपूर्ण हो जाते हैं. मॉडल की क्षमता और सिस्टम डिज़ाइन एक-दूसरे के विकल्प नहीं हैं. मॉडल बेहतर होने के साथ सिस्टम का काम कम नहीं, बल्कि अधिक महत्वपूर्ण हो जाता है.

प्रदर्शन में काम करने वाले ब्राउज़र एजेंट अक्सर इसलिए सफल होते हैं क्योंकि कार्य सीमित और परिवेश अनुकूल होता है. उत्पादन सिस्टम को कुछ अलग चाहिए: सीमित निष्पादन, मापने योग्य व्यवहार और ऐसा मूल्यांकन जो सही परिणाम तथा संयोग से मिले परिणाम में अंतर कर सके.

रैपर डिज़ाइन कम. सिस्टम इंजीनियरिंग अधिक.

हमने भले ही ब्राउज़र एजेंट पर ध्यान दिया हो, लेकिन यह कंप्यूटर उपयोग को सिस्टम से जुड़े अनुशासन के रूप में देखने के एक व्यापक तरीके की ओर संकेत करता है.