अपने द्वारा प्रबंधित मशीनों पर क्लाउड एजेंट चलाएँ
Cursor क्लाउड एजेंट अब आपके नेटवर्क के भीतर डायनेमिक रूप से शेड्यूल किए गए मशीन पूल पर निष्पादित हो सकते हैं। अंतर्निहित अवसंरचना आपके प्रबंधन में रहती है, जबकि एजेंट पहले की तरह Cursor से ही शुरू और प्रबंधित किए जाते हैं।
इससे टीमों को इस बात पर अधिक नियंत्रण मिलता है कि एजेंट कहाँ निष्पादित हों और किस अवसंरचना का उपयोग करें। एजेंट आंतरिक सेवाओं और सोर्स कंट्रोल के साथ-साथ काम कर सकते हैं, कस्टम हार्डवेयर पर चल सकते हैं, या ऐसे ऑपरेटिंग सिस्टम और बिल्ड पाइपलाइन का उपयोग कर सकते हैं जिन्हें क्लाउड एजेंट बिल्ड के रूप में पैकेज करना कठिन होता है।
आंतरिक रूप से हम जितने पुल रिक्वेस्ट्स मर्ज करते हैं, उनमें से 60% से अधिक अब क्लाउड एजेंट ही बनाते हैं, और जिन सबसे बड़े उद्यमों के साथ हम काम करते हैं, उनमें से कई में वे सॉफ़्टवेयर कार्य का लगातार बढ़ता हिस्सा संभाल रहे हैं। जैसे-जैसे उनकी भूमिका बढ़ रही है, वे जिन मशीनों पर चलते हैं उनका महत्व भी उतना ही बढ़ रहा है। ये नई क्षमताएँ टीमों के लिए उस अवसंरचना को बड़े पैमाने पर उपलब्ध कराना और प्रबंधित करना व्यावहारिक बनाती हैं।
Cursor क्लाउड एजेंट्स के लिए compute लेयर के रूप में Lambda MicroVMs के साथ, डेवलपर्स अपने ही AWS खाते में AI-संचालित कोडिंग एजेंट चला सकते हैं। हर मशीन स्नैपशॉट से लगभग तुरंत शुरू होती है, निष्क्रिय होने पर सस्पेंड हो जाती है, और पूरी स्थिति के साथ फिर से चालू हो जाती है। आपके कोडिंग एजेंट्स को Lambda की तेज़ शुरुआत, मज़बूत पृथक्करण और शून्य फ्लीट प्रबंधन का लाभ मिलता है, जबकि काम का ऑर्केस्ट्रेशन Cursor करता है।
नियंत्रित करें कि एजेंट कहाँ चलें
क्लाउड एजेंट के लिए Cursor-होस्टेड परिवेश ही डिफ़ॉल्ट बने रहते हैं। हर सत्र Cursor क्लाउड के भीतर एक समर्पित VM पर चलता है, जिसमें उसकी निर्भरताएँ इंस्टॉल रहती हैं और नेटवर्क नियंत्रण भी अलग होते हैं। प्रति-एजेंट पृथक्करण, सीक्रेट रिडैक्शन, निकासी नियंत्रण और हस्ताक्षरित कमिट्स अधिकांश टीमों की सुरक्षा आवश्यकताएँ पूरी करते हैं।
टीमें आम तौर पर स्व-होस्टेड मशीनों का उपयोग तब करती हैं जब:
- एजेंट का टूल निष्पादन उनके नेटवर्क के भीतर ही होना चाहिए, ताकि सोर्स कंट्रोल, आंतरिक सेवाओं और कोड रिपॉज़िटरी तक सीधी पहुँच रहे।
- एजेंट्स को कस्टम हार्डवेयर चाहिए, जैसे iOS विकास के लिए GPU या Mac, या Kubernetes, सैंडबॉक्स या प्रबंधित VM जैसी अवसंरचना।
- उनके ऑपरेटिंग सिस्टम या बिल्ड पाइपलाइन को क्लाउड एजेंट बिल्ड के रूप में पैकेज करना कठिन हो।
स्व-होस्टेड मशीनों के साथ केवल परिवेश बदलता है, जबकि एजेंट लूप, अनुमिति और योजना बनाना Cursor क्लाउड में ही रहते हैं। टूल आउटपुट अनुमिति के लिए Cursor को वापस भेजे जाते हैं और उनमें कोड हो सकता है, तथा agent transcripts को Cursor प्रोसेस और संग्रहीत कर सकता है। टीमें डेस्कटॉप ऐप, cursor.com, मोबाइल, Slack, GitHub और Linear से क्लाउड एजेंट तक पहले की तरह पहुँच सकती हैं।
वर्कर आपके अवसंरचना को Cursor के एजेंट लूप से जोड़ते हैं
स्व-होस्टेड मशीनों के साथ, टूल निष्पादन Cursor-होस्टेड VM से हटकर आपके परिवेश की किसी मशीन पर चला जाता है। वही मशीन रिपॉज़िटरी की कार्यशील प्रति रखती है, फ़ाइलें संपादित करती है और कमांड चलाती है। एक वर्कर इसे बाकी एजेंट सिस्टम से जोड़ता है।
किसी मशीन को पंजीकृत करने के लिए, Cursor CLI इंस्टॉल करें और agent worker start चलाकर एक वर्कर शुरू करें। इससे Cursor क्लाउड की ओर एक दीर्घकालिक आउटबाउंड HTTPS कनेक्शन खुलता है। जब कोई सत्र शुरू होता है, तो Cursor का एजेंट हार्नेस अनुमिति और योजना बनाने का काम संभालता है, और फिर निष्पादन के लिए टूल कॉल्स किसी समर्पित वर्कर को भेजता है। वर्कर अनुमिति के अगले दौर के लिए परिणाम लौटा देता है। Cursor कभी भी आपके नेटवर्क में कनेक्शन आरंभ नहीं करता।
वर्कर को दो तरीकों से कॉन्फ़िगर किया जा सकता है।
- My Machines. यह कॉन्फ़िगरेशन किसी एक लैपटॉप या VM को आपके खाते से जोड़ता है और व्यक्तिगत वर्कफ़्लो के लिए सबसे उपयुक्त है।
- Pools. पूल वर्कर की एक नामित कतार होती है, जो किसी टीम या Enterprise की ज़रूरतें पूरी कर सकती है। अनुरोध आने पर क्षमता बढ़ती है और वर्कर के डिस्कनेक्ट होने पर घट जाती है, जिससे आपका मौजूदा क्लाउड अवसंरचना डेवलपर की माँग के अनुसार स्केल कर पाता है।
डेवलपर्स के पास यह लचीलापन होना चाहिए कि वे कोडिंग एजेंट्स को उस प्लेटफ़ॉर्म पर चला सकें जो उनके वर्कफ़्लो के लिए सबसे उपयुक्त हो, और कंपनियों को इस बात पर नियंत्रण से समझौता नहीं करना चाहिए कि एजेंट कहाँ चलते हैं और वे किन चीज़ों तक पहुँच सकते हैं। विकास का भविष्य सशक्त एजेंट्स पर टिका होगा, जो सुरक्षित और पृथक परिवेशों में चलेंगे।
क्लाउड एजेंट आपकी अवसंरचना के अनुरूप ढल जाते हैं
वर्कर पूल अब कतार में लगे अनुरोधों के अनुसार स्केल कर सकते हैं और किसी भी रिपॉज़िटरी से कृति संभाल सकते हैं। हमने कई सैंडबॉक्स प्रदाताओं के लिए, तथा Mac के साथ-साथ Linux पर computer use के लिए भी समर्थन जोड़ा है।
पूल माँग के अनुसार स्केल होते हैं और किसी भी रिपॉज़िटरी के लिए काम करते हैं
क्लाउड एजेंट की माँग अक्सर उछाल के रूप में आती है, और स्व-होस्टेड मशीन पूल इन उछालों के अनुसार स्वचालित रूप से समायोजित हो जाते हैं। यह एक नियंत्रक के ज़रिए होता है, जो अनुरोध कतार पर नज़र रखता है और टीम द्वारा दी गई स्पॉन स्क्रिप्ट से आवश्यकतानुसार मशीनें शुरू करता है।
यदि पूल में कोई वर्कर उपलब्ध है, तो वही वर्कर उस अनुरोध को ले लेता है। अन्यथा अनुरोध तब तक प्रतीक्षा करता है जब तक और क्षमता उपलब्ध न हो जाए — इससे टीमों को यह तय नहीं करना पड़ता कि कितनी मशीनें चालू रखनी हैं।
टीमें हर वर्कर कनेक्शन के लिए निष्क्रियता टाइमआउट सेट कर सकती हैं। टाइमआउट समाप्त होने पर मशीन रीसेट होकर फिर से पूल में शामिल हो सकती है। एजेंट को कोई अनुवर्ती अनुरोध मिलने की स्थिति के लिए टीमें उसका कार्यस्थान सुरक्षित भी रख सकती हैं।
स्व-होस्टेड मशीन टीमों को यह नियंत्रण देती हैं कि Cursor एजेंट कहाँ चलें, और Vercel Sandbox इसे बेहद आसान बना देता है। हर कार्य को मांग पर एक पृथक सैंडबॉक्स मिलता है, कोई फ्लीट प्रबंधित करने की ज़रूरत नहीं, और कुछ भी निष्क्रिय पड़ा नहीं रहता।
एजेंट के निष्क्रिय रहते हुए मशीन को चालू रखना महँगा पड़ सकता है। लेकिन यदि मशीन छोड़ दी जाए, तो अनुवर्ती अनुरोध आने पर एजेंट को अपना कार्यस्थान दोबारा तैयार करने में कई मिनट लग सकते हैं। हाइबरनेशन के साथ टीमें इसके बजाय निष्क्रिय मशीन का स्नैपशॉट लेकर उसे बंद कर सकती हैं। यदि पुनः कनेक्ट विंडो के भीतर कोई अनुवर्ती अनुरोध आता है, तो स्नैपशॉट पुनर्स्थापित हो जाता है और उसी ID के साथ वर्कर शुरू हो जाता है। अन्यथा अनुरोध किसी नई मशीन पर चला जाता है।
पूल किसी एक रिपॉज़िटरी से बँधे नहीं होते। अनुरोध में केवल पूल की पहचान होनी चाहिए, और कोई भी उपलब्ध वर्कर उसे ले सकता है। इस तरह एक ही पूल कई रिपॉज़िटरी के लिए काम कर सकता है।
वर्कर समर्थित सैंडबॉक्स प्रदाताओं पर चलते हैं
स्व-होस्टेड मशीनों के लिए शून्य से कस्टम सैंडबॉक्स लेयर बनाने की आवश्यकता नहीं है। हमारी साझेदारी AWS Lambda, Cloudflare, Coder, Daytona, E2B, Modal, Namespace और Vercel के साथ है, जिससे वर्कर वहीं शुरू और ऑर्केस्ट्रेट किए जा सकते हैं जहाँ टीम के सैंडबॉक्स पहले से चल रहे हैं।
Modal पर Cursor स्व-होस्टेड मशीनें हर क्लाउड एजेंट सत्र को एक Modal Sandbox देती हैं, जिससे आप उसे उसके काम के हिसाब से खास तौर पर बनी मशीन सौंप सकते हैं।
एजेंट Linux और Mac पर ब्राउज़र नियंत्रित करते हैं
Linux वर्कर अब Mac के साथ-साथ computer use का समर्थन करते हैं। Chrome या Chromium सहित आवश्यक computer use निर्भरताएँ इंस्टॉल होने पर एजेंट क्लिक कर सकता है, स्क्रीनशॉट ले सकता है और ब्राउज़र को नियंत्रित कर सकता है। आप उसका डेस्कटॉप देख सकते हैं या सीधे Cursor से नियंत्रण अपने हाथ में ले सकते हैं।
Mac के बिना आप iOS या macOS ऐप नहीं बना सकते। Namespace Devboxes हर Cursor क्लाउड एजेंट के लिए एक असली Mac तैयार करता है, जो अब यह काम Apple silicon पर कर सकता है।
क्लाउड एजेंट को अपने परिवेश में लाएँ
टीमों ने वर्षों की मेहनत से अपनी अवसंरचना को अपने सॉफ़्टवेयर बनाने के तरीके के अनुरूप ढाला है। स्व-होस्टेड मशीनें क्लाउड एजेंट को उसमें कहीं अधिक स्वाभाविक रूप से समाहित होने देती हैं, और हम यह देखने के लिए उत्साहित हैं कि टीमें इन्हें कहाँ तक ले जाती हैं।
किसी मशीन को कनेक्ट करने या पूल कॉन्फ़िगर करने के लिए, दस्तावेज़ में शुरू करें।
