𝗔𝗖𝗖𝗢𝗨𝗡𝗧 𝗟𝗜𝗙𝗘𝗖𝗬𝗖𝗟𝗘 𝗩𝗦 𝗟𝗢𝗚𝗜𝗡 𝗦𝗧𝗔𝗧𝗘

आप एक स्क्रिप्ट लिखते हैं। यह लॉगिन करती है। आप स्टेट को सेव करते हैं। आपको लगता है कि काम पूरा हो गया है।

फिर आप एक रियल एनवायरनमेंट (real environment) में जाते हैं। आप एक प्रॉक्सी जोड़ते हैं। आप कई अकाउंट्स का उपयोग करते हैं। आप AI एजेंट्स जोड़ते हैं। लॉगिन स्टेट अब पर्याप्त नहीं है।

लॉगिन स्टेट ब्राउज़र को बताती है कि कौन साइन इन है। एक अकाउंट लाइफसाइकिल सिस्टम को बताती है कि क्या सेशन वैध (valid) है। यह आपको बताती है कि क्या सेशन सुरक्षित है।

कुकीज़ टेस्ट के लिए एक शॉर्टकट हैं। वे लॉन्ग रन (long runs) के लिए एक पूर्ण मॉडल नहीं हैं। आपकी प्रॉक्सी बदलती है। आपका रीजन (region) बदलता है। सेशन ठीक दिखता है। अकाउंट संदिग्ध (suspicious) दिखता है।

यह अंतर आपके ट्रस्ट मॉडल को तोड़ देता है। आपको अपने अकाउंट्स के लिए एक सिस्टम की आवश्यकता है।

एक अच्छी लाइफसाइकिल में शामिल हैं:

  • स्थिर अकाउंट आईडी (Stable account IDs)।
  • सेव किए गए ब्राउज़र प्रोफाइल।
  • निश्चित इंटरनेट पाथ।
  • स्पष्ट टास्क नियम।
  • प्रूफ लॉग्स।
  • सुरक्षित रीस्टार्ट पॉइंट्स।

AI एजेंट्स नए तरीकों से विफल होते हैं। वे नियमों को जाने बिना बटन क्लिक करते हैं। उन्हें सीमाओं (boundaries) की आवश्यकता होती है। एक लाइफसाइकिल तय करती है कि एजेंट को क्या करने की अनुमति है।

प्रत्येक रन से पहले ये प्रश्न पूछें:

  • क्या इस अकाउंट के लिए प्रॉक्सी सही है?
  • क्या टाइमज़ोन मेल खाता है?
  • क्या सेशन वैध है?
  • क्या टास्क को चलाने की अनुमति है?
  • क्या परिणाम के लिए पर्याप्त प्रमाण (proof) है?

लॉगिन स्टेट को पूरा अकाउंट न समझें। एक सेशन ब्राउज़र को यूजर को याद रखने में मदद करता है। एक लाइफसाइकिल आपकी टीम को कॉन्टेक्स्ट (context) याद रखने में मदद करती है।

स्रोत: https://dev.to/web4browser/why-your-browser-automation-needs-an-account-lifecycle-not-just-a-login-state-2mpl