डेमो के लिए एक Agent और एक ब्राउज़र विंडो पर्याप्त है। प्रोडक्शन में दर्जनों समानांतर कार्यों को अलग वातावरण चाहिए; वरना लॉगिन सेशन आपस में मिलते हैं, टैब नियंत्रण के लिए टकराते हैं और विफलता का कारण ढूँढना कठिन हो जाता है।
AI Agent क्या कर सकता है, यह दिखाने के लिए एक ब्राउज़र विंडो पर्याप्त है। लेकिन वास्तविक व्यावसायिक उपयोग में जरूरत जल्दी ही दर्जनों विंडो तक पहुँच जाती है, और उन्हें एक-दूसरे में हस्तक्षेप नहीं करना चाहिए। कारण Agent स्वयं नहीं, बल्कि उसके नीचे चलने वाला ब्राउज़र वातावरण है।
एक ही वातावरण साझा करने पर क्या समस्याएँ आती हैं
सबसे स्पष्ट समस्या Cookie और लॉगिन स्थिति का एक-दूसरे को प्रभावित करना है। एक ही ब्राउज़र डेटा डायरेक्टरी में यदि दो कार्य बारी-बारी से अलग खातों में लॉगिन करते हैं, तो बाद वाला लॉगिन पहले वाले की सेशन स्थिति को ओवरराइट कर सकता है। यदि एक कार्य कैश साफ करता है, तो दूसरे कार्य की पेज स्थिति भी खो सकती है।
इसके बाद साझा संसाधनों के लिए टकराव आता है। एक ब्राउज़र इंस्टेंस में टैब, फोकस, डाउनलोड डायरेक्टरी और पॉप-अप साझा संसाधन होते हैं। यदि दो कार्य एक ही समय में नए टैब खोलें, तो यह स्पष्ट नहीं रहता कि कौन-सा कार्य किस पेज को नियंत्रित कर रहा है। एक कार्य का डायलॉग बॉक्स दूसरे कार्य की स्क्रिप्ट को रोक सकता है। लॉगिन स्थिति के टकराव, डेटा के ओवरराइट होने और कार्यों के एक-दूसरे में हस्तक्षेप जैसी समस्याएँ समानांतर निष्पादन में लगभग अनिवार्य हैं।
तीसरी समस्या विफलता के बाद सामने आती है। यह तय करना कठिन हो जाता है कि गलती स्क्रिप्ट लॉजिक में थी या किसी चरण पर दूसरे कार्य ने वातावरण को प्रभावित किया। जब कई कार्य एक ही प्रोसेस और एक ही लॉग साझा करते हैं, तो विफलता के लक्षण भी अलग-अलग हो सकते हैं, जिससे समस्या खोजने की लागत कई गुना बढ़ जाती है।
एक कम स्पष्ट जोखिम भी है: कई पहचान लंबे समय तक एक ही वातावरण में चलें तो वे आपसी संबंध के संकेत छोड़ती हैं। डिवाइस पैरामीटर, स्टोरेज स्थिति और नेटवर्क एग्रेस एक जैसे होते हैं, इसलिए प्लेटफ़ॉर्म उन्हें आसानी से एक ही डिवाइस से होने वाली बैच गतिविधि मान सकता है। यदि एक खाता असामान्य माना जाए, तो दूसरे खातों पर भी असर पड़ सकता है।
कई विंडो खोलना आइसोलेशन नहीं है
पहली प्रतिक्रिया अक्सर कई विंडो मैन्युअली खोलने की होती है। वे अलग दिखती हैं, लेकिन वास्तव में एक ही ब्राउज़र प्रोफ़ाइल साझा करती हैं: वही Cookie, वही लोकल स्टोरेज और वही डिवाइस जानकारी। विंडो एक-दूसरे की लॉगिन स्थिति देख सकती हैं, और एक विंडो की गतिविधि दूसरी को प्रभावित कर सकती है।
वास्तविक आइसोलेशन डेटा डायरेक्टरी और वातावरण के पैरामीटर तक होना चाहिए। हर वातावरण के लिए अलग स्टोरेज डायरेक्टरी, अलग डिवाइस पैरामीटर—रेज़ोल्यूशन, भाषा, टाइम ज़ोन, फ़ॉन्ट, Canvas, WebGL आदि—और अलग नेटवर्क एग्रेस चाहिए। इन तीन में से कोई एक भी न हो तो आइसोलेशन अधूरा है। वातावरण अलग होने पर भी यदि नेटवर्क एग्रेस साझा है, तो संबंध पहचानने वाली जाँच फिर भी काम कर सकती है।
आइसोलेशन की लागत और उससे मिलने वाला लाभ
आइसोलेशन मुफ्त नहीं है। हर वातावरण के पीछे एक स्वतंत्र ब्राउज़र प्रोसेस और अलग डेटा डायरेक्टरी होती है। वातावरणों की संख्या बढ़ने पर सबसे पहले मेमोरी और CPU पर दबाव आता है। यदि एक मशीन पर दर्जनों वातावरण चलाने हों, तो क्रैश के बाद प्रतिक्रिया देने के बजाय पहले से उपलब्ध क्षमता का हिसाब लगाना बेहतर है।
कुछ जगह संतुलन बनाया जा सकता है: कम उपयोग वाले वातावरण को बंद करके जरूरत पर फिर शुरू करना; कार्यों को उनकी भार-स्तर के अनुसार कई मशीनों में बाँटना, बजाय सब कुछ एक मशीन पर रखने के; और वातावरणों के लिए स्पष्ट जीवनचक्र तय करना ताकि सैकड़ों वातावरण लगातार सक्रिय न रहें। कार्य की संरचना भी मायने रखती है। एक ही खाते के क्रमिक कार्यों को अलग-अलग वातावरण में बाँटने की जरूरत नहीं; इससे केवल संसाधन बर्बाद होंगे।
दूसरी ओर लाभ है। सही आइसोलेशन के बाद विफलताओं का व्यवहार स्थिर हो जाता है: समस्या किसी खास वातावरण से जुड़ी होती है, न कि किसी रहस्यमय घटना से। बड़े पैमाने पर यह पूर्वानुमेयता साझा वातावरण से बचाए गए थोड़े से संसाधनों से कहीं अधिक मूल्यवान होती है।
बड़े पैमाने पर वातावरण स्तर पर जरूरी तीन चीजें
पहली है बैच शेड्यूलिंग। वातावरणों को कंप्यूट संसाधनों की तरह आवंटित और मुक्त किया जा सके, और ऑन-डिमांड निर्माण, बैच स्टार्ट, समानांतरता नियंत्रण, विफलता के बाद दोबारा प्रयास और स्वचालित पुनर्चक्रण का समर्थन हो। इन्हें स्क्रिप्ट के भीतर एक-एक करके बनाना और बंद करना उचित नहीं है।
दूसरी है स्वतंत्र नेटवर्क एग्रेस। हर वातावरण का अपना एग्रेस होना चाहिए, और उसकी लोकेशन वातावरण के भौगोलिक पैरामीटर से मेल खानी चाहिए। यह बिंदु आसानी से छूट जाता है, लेकिन पूरी आइसोलेशन व्यवस्था की बुनियादी शर्त है।
तीसरी है क्वेरी की जा सकने वाली स्थिति। किसी भी समय यह पता होना चाहिए कि कौन-से वातावरण चल रहे हैं, कौन-से खाली हैं और किनमें असामान्यता है। Agent बिना निगरानी के चलते हैं; यदि स्थिति देखी न जा सके तो समस्या आने पर केवल अनुमान लगाना पड़ता है।
इन तीन क्षमताओं को स्क्रिप्ट के अंदर संभालना असुविधाजनक है। इनके लिए वातावरण स्तर पर स्टोरेज, कॉन्फ़िगरेशन और शेड्यूलिंग चाहिए। कुछ मल्टी-एनवायरनमेंट प्रबंधन टूल इसी स्तर पर काम करते हैं। PurpleMark उनमें से एक है, जो ब्राउज़र वातावरण को ऐसे संसाधन में बदलता है जिसे अलग रखा जा सके, बैच में शेड्यूल किया जा सके और इंटरफ़ेस के माध्यम से बुलाया जा सके।
कई वातावरण कब जरूरी नहीं होते
यदि Agent केवल एक खाते पर कम आवृत्ति से चलता है, तो सामान्य ब्राउज़र सचमुच पर्याप्त है और अतिरिक्त आइसोलेशन केवल रखरखाव का बोझ बढ़ाता है। लेकिन इनमें से कोई भी स्थिति आते ही वातावरण स्तर को अलग करना उचित है: कार्यों को समानांतर चलाना हो, कई पहचान से एक ही प्लेटफ़ॉर्म तक पहुँचना हो, लॉगिन स्थिति लंबे समय तक बनाए रखनी हो, या समानांतर कार्यों का पैमाना आगे भी बढ़ना हो।
इन सभी स्थितियों में एक बात समान है: सवाल यह नहीं कि Agent पर्याप्त बुद्धिमान है या नहीं, बल्कि यह कि उसके नीचे का वातावरण पर्याप्त साफ और अलग है या नहीं।
सीमाएँ
समाधान चाहे जो हो, नियमों की सीमाएँ नहीं बदलतीं: हर प्लेटफ़ॉर्म की सेवा शर्तों और robots नियमों का पालन करें, झूठी पहचान संबंधी जानकारी का उपयोग न करें, तकनीकी सुरक्षा उपायों को दरकिनार न करें, अनुरोधों की आवृत्ति नियंत्रित रखें और दूसरे पक्ष की सेवाओं के सामान्य संचालन में बाधा न डालें।
