ब्राउझर आवरणांपासून मर्यादित संगणक वापरापर्यंत

• संगणक वापर म्हणजे काय आणि तो महत्त्वाचा का आहे? संगणक वापर ही व्यापक परिणाम घडवणारी सोपी कल्पना आहे: मॉडेलना प्रश्नांची उत्तरे द्यायला सांगण्याऐवजी, आम्ही त्यांना सॉफ्टवेअर वापरायला सांगतो—संकेतस्थळांवर मार्गक्रमण करणे, फॉर्म भरणे, विविध कार्यप्रवाहांमध्ये क्लिक करणे आणि कार्ये सुरुवातीपासून शेवटपर्यंत स्वायत्तपणे पूर्ण करणे.

• यामुळे सध्या विविध इंटरफेसमध्ये विखुरलेल्या वास्तवातील अनेक प्रकारच्या कार्यांची दारे खुली होतात. उदाहरणार्थ, सुरुवातीपासून शेवटपर्यंत आरक्षण करणे, ऑनलाइन खरेदीची देयक प्रक्रिया, अनेक टप्प्यांचे प्रवास नियोजन आणि ज्यांना सुटसुटीत एपीआय पर्याय नाहीत असे प्रशासकीय कार्यप्रवाह. या समस्या नवीन नाहीत. नवीन बाब म्हणजे सर्वसाधारण वापराच्या मॉडेलच्या मदतीने त्या सोडवणे आता व्यवहार्य झाले आहे.

• Anthropic आणि OpenAI यांच्या अलीकडील प्रणालींनी असे एजंट दाखवून दिले आहेत, जे केवळ कृती करत नाहीत, तर स्थितीबाबत रीझनिंग करतात, त्रुटींमधून सावरतात आणि गरजेनुसार कार्यविशिष्ट उपाय तयार करतात. यामुळे ब्राउझर एजंटसाठी सर्वसाधारण अंमलबजावणी वातावरण बनतो. पण त्यातून रचनेशी संबंधित एक तातडीचा प्रश्न निर्माण होतो: त्या वातावरणातील किती भाग मॉडेलला उपलब्ध करून द्यावा?

• सुरुवातीच्या प्रणालींनी ब्राउझरला सुरक्षित आणि पूर्वनिर्धारित कृतींच्या निश्चित संचात गुंडाळून याचे उत्तर दिले. या लेखात आम्ही मांडणार आहोत त्याप्रमाणे, हा दृष्टिकोन आता मर्यादेपर्यंत पोहोचत आहे.

ब्राउझर एजंट तयार करताना एक परिचित सहजप्रवृत्ती दिसते: मॉडेलवर फार विश्वास ठेवू नका.

म्हणून आम्ही ब्राउझरभोवती आवरण तयार करतो. आम्ही click, type, scroll, select आणि read_text यांसारखी पूर्वनिर्धारित साधने उपलब्ध करतो. आम्ही दस्तऐवज ऑब्जेक्ट मॉडेल (DOM) सोपे करतो. आम्ही संभाव्य कृतींची व्याप्ती कमी करतो. आम्ही तयार केलेल्या अमूर्तीकरणांच्या मदतीने वर्तन समजण्याजोगे आणि नियंत्रित ठेवण्याचा प्रयत्न करतो.

हा सुरुवातीसाठी विवेकी दृष्टिकोन आहे. पण दीर्घकालीन दृष्टीने तो अधिकाधिक चुकीचा स्थापत्य आराखडाही ठरत आहे.

अत्याधुनिक मॉडेल सुधारत असताना, मॉडेलकडे साधने नसणे हीच एकमेव मर्यादा राहिलेली नाही. मूळ प्रणालीतील खूप जास्त माहिती काढून टाकणाऱ्या अमूर्तीकरणांतून आम्ही त्याला काम करायला भाग पाडतो, ही खरी मर्यादा आहे. आम्ही गोंधळाचे आणि गतिशील वातावरण निश्चित कृती इंटरफेसमध्ये संकुचित करतो आणि मग त्या माहितीच्या ऱ्हासातही मॉडेलने उत्तम काम करावे अशी अपेक्षा करतो.

ही तडजोड आता कमी आकर्षक ठरत आहे.

आम्ही तपासत असलेला बदल सांगायला सोपा असला, तरी त्याचे परिणाम महत्त्वपूर्ण आहेत. एजंटकडे पूर्वनिर्धारित कृती निवडणारी यंत्रणा म्हणून पाहण्याऐवजी, आम्ही त्याच्याकडे मर्यादित रनटाइममध्ये काम करणारी प्रोग्राम निर्माण करणारी यंत्रणा म्हणून पाहतो.

मॉडेल आता खरोखरच अत्यंत सक्षम झाली आहेत आणि त्यांना तुमच्या अमूर्त सुरक्षा मर्यादांची गरज उरलेली नाही. त्यांना कार्याची रचना करणे, ते अंमलात आणणे आणि उद्दिष्ट साध्य होईपर्यंत त्यात सुधारणा करणे यासाठी कृतींची संपूर्ण व्याप्ती हवी आहे.

हा लेख अमूर्तीकरणावर मोठ्या प्रमाणात अवलंबून असलेल्या ब्राउझर स्वयंचलनापासून मर्यादित संगणक वापराकडे होणाऱ्या या बदलाबद्दल आणि अशा प्रकारे प्रणालींची रचना केल्यावर काय बदलते याबद्दल आहे.

निश्चित कृती इंटरफेस संकल्पनेच्या पातळीवर चुकीचे आहेत, ही समस्या नाही. समस्या अशी आहे की, वेब त्यांना अपेक्षित साथ देत नाही.

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

तुम्ही यावर तात्पुरती दुरुस्ती करू शकता. तुम्ही React इनपुटसाठी विशेष परिस्थिती जोडू शकता, फोकसनंतर blur घटना पाठवू शकता आणि स्थिती वाचण्यापूर्वी नेटवर्क निष्क्रिय होण्याची वाट पाहू शकता. प्रत्येक दुरुस्ती स्थानिक पातळीवर योग्य असते. पण त्या एकत्रितपणे साठत जाऊन अशी प्रणाली तयार करतात, जी सांभाळणे अधिकाधिक कठीण होते आणि जी तुम्ही आधीच पाहिलेल्या संकेतस्थळांपुरती अधिकाधिक विशिष्ट बनते.

यातील अधिक खोल समस्या अशी की, परस्परसंवाद कसे चालले पाहिजेत याबद्दलची गृहीतके तुम्ही अमूर्तीकरणाच्या स्तरात बांधता आणि मग वेबची गृहीतके वेगळी असल्याचे लक्षात येते.

क्रॉस-ओरिजिन आयफ्रेममध्ये Stripe किंवा Adyen द्वारे जोडलेल्या देयक फॉर्मचा विचार करा. तो वेगळ्या ओरिजिनमध्ये असल्यामुळे तुमचे आवरण त्याच्यापर्यंत थेट पोहोचू शकत नाही. तुमचे read_text साधन त्याची अंतर्गत स्थिती पाहू शकत नाही. तुमचे type साधन त्याच्या इनपुटना हाताळू शकत नाही. आवरणावर आधारित एजंट येथे अडकतो. अमूर्तीकरणाची रचना मुख्य दस्तऐवजासाठी करण्यात आली होती. प्रत्यक्ष कार्य मात्र अमूर्तीकरणाला न दिसणाऱ्या ठिकाणी असते.

अशीच विसंगती कमी स्पष्ट असलेल्या प्रक्रियांमध्येही दिसते. फ्रेमवर्कद्वारे नियंत्रित अधोमुखी सूची थेट क्लिकला अजिबात प्रतिसाद देणार नाही, कारण दिसणारा घटक हा प्रत्यक्ष नियंत्रण घटक नसतो. अंतर्गत स्थितीबदल सुरू करण्यासाठी तिला कळफलकावरील घटनांचा विशिष्ट क्रम लागू शकतो. बाहेरून पाहता वापरकर्ता इंटरफेस क्लिक करता येण्यासारखा दिसतो. अमूर्तीकरण “क्लिक करा” असे सांगते. काहीच घडत नाही.

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

प्रत्येक परिस्थितीत अमूर्तीकरण एजंटला खरोखर आवश्यक असलेले संकेत लपवते.

अधिक खालच्या पातळीवर काम करणारे मॉडेल—थेट DOM तपासून, फ्रेमच्या सीमांबाबत रीझनिंग करून आणि त्या विशिष्ट पृष्ठभागासाठी परस्परसंवादाचा क्रम तयार करून—या परिस्थिती हाताळू शकते. मॉडेल मुळातच अधिक बुद्धिमान आहे असे नाही. काढून टाकलेल्या माहितीमध्ये त्याला आता प्रवेश आहे, एवढाच फरक आहे.

आम्ही साध्य करू पाहत असलेला बदल सांगायला सोपा आहे: मॉडेलला पूर्वनिर्धारित कृती निवडायला सांगण्याऐवजी, आम्ही त्याला अधिक खालच्या पातळीवरील अंमलबजावणी पृष्ठभाग देतो आणि अमूर्तीकरणाच्या रचनेऐवजी रनटाइम धोरणाद्वारे त्या पृष्ठभागावर मर्यादा घालतो.

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

अनेक विकसकांच्या साधनसंचात Claude Code हा प्रमुख पर्याय कसा ठरला आहे आणि उद्योग टर्मिनलवर आधारित एजंटकडे कसा वळत आहे, याचा विचार करा. Claude Code चा सर्वांत मोठा लाभ स्वतः मॉडेल नसून, खालच्या पातळीवरील हार्नेस आहे. मॉडेलला कमी, अधिक घटकाधारित आणि खालच्या पातळीवरील साधने देणे—म्हणजेच. टर्मिनल देणे—यामुळे साधने वापरण्याची कामगिरी सुधारते. याचे मुख्य कारण असे की, कॉन्टेक्स्ट विंडो अनावश्यकपणे भरणारी सर्वसाधारण साधने वापरण्याचा प्रयत्न करण्याऐवजी एजंट रीझनिंग करू शकतो आणि समोरील कार्यासाठी सानुकूल स्क्रिप्ट तयार करू शकतो.

ब्राउझर स्वयंचलनाच्या वापरात याचा प्रत्यक्ष अर्थ असा की, प्रत्येक गोष्ट आधी तयार केलेल्या निश्चित कृतींच्या संचाशी जुळवण्याऐवजी मॉडेल थेट पृष्ठाची वर्तमान स्थिती तपासू शकते, फ्रेममधून मार्गक्रमण करू शकते आणि सध्याच्या इंटरफेससाठी खास परस्परसंवाद कोड तयार करू शकते.

मॉडेल निवड करणाऱ्या यंत्रणेसारखे कमी आणि रनटाइम रचणाऱ्या लेखकासारखे अधिक वागते. ते सध्याची स्थिती तपासते, इंटरफेसबाबत रीझनिंग करते आणि त्या विशिष्ट परिस्थितीसाठी परस्परसंवादाचे तर्कशास्त्र तयार करते. ते अनेक टप्प्यांचे क्रम तयार करू शकते, असामान्य प्रक्रियांशी जुळवून घेऊ शकते आणि पुढे जाण्यापूर्वी परिणाम पडताळू शकते. एखादी कृती अयशस्वी झाल्यास, मॉडेलला मूळ त्रुटी दिसते आणि ते स्वतःच दुरुस्ती करते. हे अधिक शक्तिशाली आणि अधिक जोखमीचे आहे, पण समस्येच्या प्रत्यक्ष स्वरूपाशी ते बरेच अधिक जुळते.

महत्त्वाचे म्हणजे, अमूर्तीकरणाचा स्तर काढल्याने प्रणालीतील शिस्त कमी होत नाही. फक्त शिस्तीचे स्थान बदलते.

पूर्वी आवरणांच्या रचनेत आणि अपवादात्मक परिस्थिती हाताळण्यात असलेले काम आता तीन ठिकाणी जाते: प्रॉम्प्टमध्ये, जो कार्यपद्धतीच्या प्रशिक्षणाचे रूप घेतो; रनटाइममध्ये, जो मार्गक्रमणाची व्याप्ती, संवेदनशील कृती आणि पुनर्प्रयत्नाचे वर्तन यांसारख्या सीमा लागू करतो; आणि मूल्यमापन स्तरात, जो कार्य यशस्वी झाले का एवढेच नव्हे, तर मधले टप्पे योग्य होते का हेही तपासतो. ठिसूळ अमूर्तीकरणे कमी. सभोवतालच्या प्रणाली अधिक मजबूत.

या बदलाचा एक परिणाम असा की, एकूण प्रणाली अधिक सक्षम होत असतानाही उत्पादनाचा कोड अनेकदा अधिक सोपा होतो. परस्परसंवादाच्या पद्धती पुन्हा वापरता येणाऱ्या आवरणांमध्ये बांधण्याऐवजी, एजंट रनटाइममध्ये वर्तन तयार करतो. विशेषीकृत साधने आणि अपवादात्मक परिस्थितींसाठीचे तर्क सतत वाढवत नेण्याऐवजी, तुम्ही मोजक्या शक्तिशाली मूलभूत घटकांचा संच आणि मर्यादित अंमलबजावणी वातावरण सांभाळता.

यामुळे प्रणालीचे सामान्यीकरण कसे होते, हेही बदलते. आवरणांवर आधारित एजंट तुम्ही आधीच तयार केलेल्या आवरणांसारख्या कार्यांसाठी चांगले सामान्यीकरण करतो. मर्यादित रनटाइममधील एजंट दृश्यमान इंटरफेस वेगळा असला, तरी समान अंमलबजावणी पायाभूत रचना असलेल्या कार्यांसाठी सामान्यीकरण करतो.

उदाहरणार्थ, शोध फॉर्म, आरक्षण प्रक्रिया किंवा सेटिंग्ज पृष्ठाशी होणारा परस्परसंवाद वापरकर्ता इंटरफेसच्या पातळीवर पूर्णपणे वेगळा दिसू शकतो. पण अंतर्गत पातळीवर त्यांच्यात समान पद्धती असतात: स्थिती वाचणे, घटना सुरू करणे, परिणामांची पडताळणी करणे आणि असमकालिक अद्यतने हाताळणे. त्या पातळीवर काम करणारी प्रणाली विविध कार्यांमध्ये अधिक सहजपणे वापरली जाते.

पुन्हा वापरता येणारा घटक म्हणजे कृतींची यादी नव्हे. तो म्हणजे स्थिती तपासण्याची, सुरक्षितपणे कृती करण्याची आणि परिणाम पडताळण्याची मॉडेलची क्षमता.

या कामातून मिळालेला सर्वांत स्पष्ट धडा असा की, मॉडेलला अधिक साहाय्यक कार्ये दिल्याने विश्वासार्हता मिळत नाही. अनेकदा त्याला कमी, पण अधिक शक्तिशाली मूलभूत घटक देऊन आणि त्यांच्यावर योग्य मर्यादा घालून ती साध्य होते. अतिसाहाय्यामुळे एखादे कार्य कसे केले पाहिजे याबद्दलची गृहीतके कोडमध्ये कायमची बांधली जातात. मर्यादा सुरक्षित कार्यसीमा ठरवतात आणि मॉडेलला स्थानिक पातळीवर अधिक चांगले उपाय शोधू देतात.

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

रचना करताना चार बाबींचा विचार करावा लागतो:

डेटा उघड होणे. एजंट प्रत्यक्ष इंटरफेसशी संवाद साधत असल्यास, त्याला अनेकदा संवेदनशील माहिती आढळेल. त्यामुळे माहिती लपवणे आणि प्रवेश नियंत्रण यांसाठी शिस्तबद्ध दृष्टिकोन आवश्यक आहे. अंमलबजावणीसाठी गरज असेल तेव्हाच डेटा उघड केला पाहिजे. तसेच निरीक्षणक्षमता हाच प्रणालीचा सर्वाधिक संवेदनशील भाग ठरू नये, म्हणून नोंदी आणि मागोवे काळजीपूर्वक हाताळले पाहिजेत.

अंमलबजावणीची व्याप्ती. शक्तिशाली एजंटला मनमानीपणे काम करता येऊ नये. प्रत्यक्षात याचा अर्थ तो कुठे जाऊ शकतो, कोणत्या डोमेनमध्ये प्रवेश करू शकतो आणि कोणत्या प्रणालींशी संवाद साधू शकतो यावर मर्यादा घालणे. या मर्यादा प्रॉम्प्टमधील संकेत म्हणून न ठेवता रनटाइमच्या पातळीवर लागू केल्या पाहिजेत.

वातावरणावरील विश्वास. आधुनिक इंटरफेसमध्ये दिशाभूल करणाऱ्या किंवा जाणीवपूर्वक घातक सूचना, मजकूर किंवा प्रक्रिया असू शकतात. पृष्ठावरील मजकुरातून होणारे प्रॉम्प्ट इंजेक्शन हे खरेखुरे आक्रमणक्षेत्र आहे. एजंटने अनपेक्षित मार्गदर्शनाचे पालन करू नये यासाठी प्रणालीमध्ये सूचनांचा स्पष्ट प्राधान्यक्रम, पडताळणी तपासण्या आणि समाप्तीच्या अटी आवश्यक आहेत.

स्वायत्ततेची श्रेणी. सर्व कृती पूर्णपणे स्वायत्त असू नयेत. अनेक उत्पादन वातावरणांमध्ये स्वायत्ततेकडे एका श्रेणीप्रमाणे पाहणे महत्त्वाचे असते. प्रणाली शोध आणि अंमलबजावणी करताना अत्यंत स्वायत्त असू शकते, तरीही कृतींच्या काही प्रकारांसाठी मंजुरी आवश्यक ठेवता येते.

मूलभूत तत्त्व सरळ आहे: मॉडेलला अधिक सामर्थ्य देताना त्याच्या सभोवतालची प्रणालीही अधिक मजबूत करावी लागते. धोरणाविना स्वायत्तता उत्पादनासाठी सज्ज नसते.

ब्राउझरच्या कोणत्या कृती उपलब्ध करून द्याव्यात, हा प्रश्न आम्ही विचारणे थांबवले.

त्याऐवजी आम्ही विचारू लागलो: मॉडेलला कृतींची संपूर्ण व्याप्ती कशी देता येईल आणि त्याच्याभोवती सुरक्षितता कायम राखणारी रनटाइम धोरणे कशी तयार करता येतील?

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

प्रात्यक्षिकात चालणारे ब्राउझर एजंट अनेकदा यशस्वी होतात, कारण कार्य मर्यादित आणि वातावरण अनुकूल असते. उत्पादन प्रणालींसाठी वेगळ्या गोष्टी आवश्यक असतात: मर्यादित अंमलबजावणी, मोजमाप करता येईल असे वर्तन आणि योग्य परिणाम व योगायोगाने मिळालेला परिणाम यांतील फरक ओळखणारे मूल्यमापन.

आवरणांची रचना कमी. प्रणाली अभियांत्रिकी अधिक.

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