जब हमने एक साल पहले पहली बार क्लाउड एजेंट्स लॉन्च किए, तो वे लोकल एजेंट्स के सीधे विस्तार जैसे लगे। तब से, क्लाउड एजेंट की क्षमताएँ काफ़ी बढ़ गई हैं।

अब क्लाउड एजेंट्स अपनी समर्पित वर्चुअल मशीनों पर चलते हैं, अपने अलग परिवेश, निर्भरताओं और नेटवर्क एक्सेस के साथ। वे समानांतर में काम कर सकते हैं, बिना निगरानी के चल सकते हैं, और आपके लैपटॉप पर चल रहे किसी लोकल एजेंट की तुलना में लंबे कार्य संभाल सकते हैं।

ये क्षमताएँ परिवेश सेटअप, विश्वसनीयता और ऑर्केस्ट्रेशन से जुड़ी ऐसी चुनौतियाँ लाती हैं, जो तब कम उभरती हैं जब कोई एजेंट आपके लैपटॉप पर चल रहा हो।

इस पोस्ट में, हम क्लाउड एजेंट्स बनाते हुए सीखे गए सबसे बड़े सबक साझा करना चाहते हैं, और यह भी बताना चाहते हैं कि क्यों यह काम अब किसी लोकल एजेंट को सर्वर पर पोर्ट करने से कम, और उसके चारों ओर एक ऑपरेटिंग लेयर बनाने जैसा ज़्यादा लगता है।

#विकास परिवेश ही उत्पाद है

पिछले एक साल में हमने सीखा है कि क्लाउड एजेंट के आउटपुट की गुणवत्ता को सबसे ज़्यादा प्रभावित करने वाला कारक यह है कि उसके पास एक डेवलपर की तरह पूरा विकास परिवेश हो।

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

क्रैश या किसी त्रुटि संदेश की बजाय, अक्सर इसका एकमात्र संकेत आउटपुट की गुणवत्ता में हल्की-सी गिरावट होती है। हो सकता है कि शुरुआत में आप इसे नोटिस न करें, और अगर करें भी, तो इसे मॉडल की वजह मान लें।

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

आज, "पूर्ण परिवेश" तक पहुँचने के लिए हैरान कर देने वाली मात्रा में अवसंरचना को फिर से बनाना पड़ता है:

• एजेंट परिवेश बनाने के लिए बेहतर उपयोगकर्ता उपकरण
• संदेशों के बीच एजेंट VM को कुशलतापूर्वक हाइबरनेट करने और फिर से शुरू करने के मेथड्स
• VM इमेज को तेज़ी से और भरोसेमंद तरीके से चेकपॉइंट, रीस्टोर, और फोर्क करने के लिए पाइपलाइन
• मज़बूत उपयोग में लाने के ढांचे और क्लाइंट इंटीग्रेशन, ताकि एजेंट और इंसान दोनों परिवेश को समझ सकें और उसके साथ इंटरैक्ट कर सकें

और जैसे-जैसे क्लाउड एजेंट ज़्यादा काम अपने ऊपर लेते हैं, उन्हें PR बनाने, निर्भरताएँ पुल करने, और अनुसंधान करने के लिए नियंत्रित नेटवर्क एक्सेस की आवश्यकता होती है। समय के साथ, हमने मूल रूप से एजेंट्स के लिए enterprise IT जैसा एक सिस्टम बना लिया है, जिसमें सीक्रेट रिडैक्शन, नेटवर्क नीतियाँ, और क्रेडेंशियल प्रबंधन शामिल हैं।

#लंबे समय तक चलने वाले एजेंट्स को टिकाऊ निष्पादन की आवश्यकता होती है

क्लाउड एजेंट, लोकल एजेंट्स की तुलना में विश्वसनीयता की एक अलग तरह की चुनौती पेश करते हैं। आपके लैपटॉप पर लोकल संसाधनों के लिए प्रतिस्पर्धा करने के बजाय, क्लाउड एजेंट अपने अलग-थलग VMs में चलते हैं। इससे डेवलपर्स के लिए कई एजेंट्स को समानांतर में चलाना और लंबे समय तक चलने वाले टास्क उन्हें सौंपना आसान हो जाता है, जो अक्सर मिनटों के बजाय घंटों लेते हैं।

लेकिन VM में चलने का मतलब है कि अनुमिति प्रदाता के आउटेज, पॉड्स के बदले जाने की आवश्यकता, और EC2 नोड्स के डाउन होने जैसी रुकावटों का जोखिम भी रहता है।

हमने क्लाउड एजेंट्स का निर्माण work-stealing architecture के साथ शुरू किया था, जहाँ वर्कर नोड्स एजेंट्स को उठा सकते थे और उन्हें पूरा होने तक लूप में चला सकते थे। यह लोकल में काम करने वाले तरीके को सर्वर पर ले आया, लेकिन यह सेटअप काफ़ी नाज़ुक था—क्लाउड एजेंट्स का हमारा शुरुआती beta अक्सर विश्वसनीयता के सिर्फ़ one 9 तक ही पहुँच पाता था।

जैसे-जैसे क्लाउड एजेंट्स परिपक्व हुए, हमें महसूस हुआ कि हम टिकाऊ निष्पादन के कई आदिम घटकों को फिर से बना रहे थे, जिन्हें Temporal पहले से हल करता है (जैसे retry mechanisms, मशीनों के बीच कार्य का अनुसूचीकरण, और नोड विफलताओं के दौरान durability), इसलिए हमने इसकी बजाय वहाँ माइग्रेट किया।

Temporal पर हमारा मौजूदा एजेंट लूप अनुमिति की विश्वसनीयता में आने वाली क्षणिक रुकावटों, पॉड हाइबरनेशन और दोबारा शुरू होने, और उन runs को भी संभाल सकता है जो कई दिनों या यहाँ तक कि हफ़्तों तक चलते हैं। सिर्फ़ उसी माइग्रेशन ने हमें विश्वसनीयता के two 9s से आगे पहुँचा दिया, और आज Temporal 70 लाख से अधिक अद्वितीय वर्कफ़्लो में प्रतिदिन 5 करोड़ से अधिक कार्रवाइयाँ संभालता है। आंतरिक रूप से, हमारे 40% से अधिक PRs क्लाउड एजेंट्स से आते हैं, और यह संख्या लगातार बढ़ रही है।

समय के साथ, हमने सीखा है कि अपने Temporal वर्कफ़्लो को और बेहतर तरीके से कैसे आर्किटेक्ट किया जाए। हम "eternal" एजेंट वर्कफ़्लो से कई छोटे वर्कफ़्लो की ओर बढ़े हैं, जो एक-एक कार्य पूरा करने के बाद समाप्त हो जाते हैं, जिससे संस्करण अपग्रेड करना आसान हो जाता है। हमने activities को भी अलग किया है, ताकि टाइमआउट और retries को async टूल कॉल्स, उप-एजेंट, और अनुमिति प्रदाता के आउटेज के रूप में बेहतर ढंग से कैप्चर किया जा सके, क्योंकि इन बदलावों ने हमारी बुनियादी धारणाएँ बदल दी हैं।

#एजेंट और मशीनों को बातचीत की स्थिति से अलग करना

अब क्लाउड एजेंट सिर्फ एक मशीन पर चलने वाला एक लूप नहीं रहा। इसके बजाय, कोई एजेंट एक मशीन पर चल सकता है, कई मशीनों पर async उप-एजेंट स्पॉन कर सकता है, या लोकल तौर-तरीके से शुरू होकर काम क्लाउड को सौंप सकता है। कोई उप-एजेंट अपने मूल से भी ज़्यादा समय तक चल सकता है, या बिल्कुल अलग तरह के पॉड पर चल सकता है।

इसे संभव बनाने के लिए, हमने पाया कि एजेंट लूप, मशीन की स्थिति और बातचीत की स्थिति को अलग-अलग कंपोनेंट के रूप में रखना उपयोगी है। क्योंकि एजेंट लूप VM पर चलने के बजाय Temporal में रहता है, हम पॉड lifecycle को स्वतंत्र रूप से प्रबंधित कर सकते हैं और अलग-अलग तरह के पॉड पर एजेंट चला सकते हैं — जिसमें readonly VM या prewarmed VM जैसे optimization भी शामिल हैं।

बातचीत के पक्ष में, हमने स्टोरेज और स्ट्रीमिंग layer को मुख्य एजेंट वर्कफ़्लो से अलग कर दिया। हमने एक कुशल append-only storage mechanism बनाया, जो बातचीत के अपडेट वेब और डेस्कटॉप क्लाइंट तक स्ट्रीम करता है। यह layer retries को संभालती है, ताकि अगर एजेंट लूप का कोई चरण आंशिक आउटपुट स्ट्रीम करने के बाद विफल हो जाए और फिर दोबारा चलाया जाए, तो क्लाइंट इसका पता लगा सके, अपनी stream को rewind कर सके, और पुराने डेटा की जगह नया डेटा दिखा सके।

#यह समझना कि कब रास्ते से हट जाना चाहिए

क्लाउड एजेंट को उपयोग में लाने का ढांचा बनाना इस बात का लगातार पुनर्मूल्यांकन करना है कि कितना व्यवहार निर्धारक है और कितना एजेंट को सौंपा जाता है।

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

CI Autofix के साथ भी यही हुआ। पहले, हमारे क्लाउड एजेंट को उपयोग में लाने के ढांचे के पुराने संस्करणों में job failure logs को लाने और उन्हें VM में लिखने का लॉजिक होता था। अब, हम बस एजेंट को GitHub CLI तक पहुँच देते हैं और बड़े आउटपुट्स को स्वचालित रूप से उन फ़ाइलों में लिख देते हैं जिनमें वह खोज कर सकता है। एजेंट को भेजी जाने वाली सूचना अब काफ़ी सरल हो गई है, और हमें उम्मीद है कि यह रुझान आगे भी जारी रहेगा।

उपयोग में लाने का ढांचा खत्म नहीं हो रहा है, बल्कि उसमें क्या शामिल है, यह बदल रहा है। इसका एक अच्छा उदाहरण अभी computer use है। हमारे क्लाउड एजेंट को उपयोग में लाने के ढांचे में computer use के लिए एक समर्पित उप-एजेंट प्रकार है, जिसकी अपनी मॉडल रूटिंग, कस्टम प्रॉम्प्टिंग, और screen recording है। VNC और Chrome परिवेश का हिस्सा हैं, जिसे पैरेंट एजेंट और उप-एजेंट के बीच साझा किया जाता है। इससे पैरेंट उनका सीधे उपयोग कर सकता है, उदाहरण के लिए Playwright स्क्रिप्ट चलाकर। हम इस scaffolding का उपयोग इसलिए करते हैं क्योंकि मॉडल अभी अपने दम पर computer use संभालने के लिए पूरी तरह तैयार नहीं हैं, लेकिन इसे कब invoke करना है, इसका नियंत्रण फिर भी एजेंट के पास ही रहता है।

क्लाउड एजेंट्स को उपयोग में लाने के ढांचे में लोकल एजेंट्स की तुलना में अलग तरह के प्रॉम्प्ट्स की भी ज़रूरत होती है। हम उन्हें अधिक स्वायत्त होने के लिए प्रोत्साहित करते हैं, क्योंकि रुकने की लागत कहीं अधिक होती है। लोकल रूप से, आपको पता चल जाता है कि एजेंट कब रुक गया है और अनुमति की प्रतीक्षा कर रहा है, लेकिन क्लाउड में वह घंटों तक यूँ ही पड़ा रह सकता है, इससे पहले कि आप वापस आकर उसकी जाँच करें।

#स्व-उपचारक एजेंट परिवेश

आगे की ओर देखते हुए, हमारा ध्यान एजेंट का हाथ पकड़कर चलाने और उसे पूरी तरह अपने हाल पर छोड़ देने जैसे दो-टूक विकल्पों से आगे बढ़ने पर है। इससे बेहतर पैटर्न यह है कि एजेंट को अपने आसपास के सिस्टम को समझने के लिए उपकरण दिए जाएँ।

हम चाहते हैं कि क्लाउड एजेंट्स यह रिपोर्ट कर सकें कि कब सीक्रेट्स मौजूद नहीं हैं, नेटवर्क एक्सेस ब्लॉक है, या उनका परिवेश किसी और तरह से उन्हें आगे बढ़ने से रोक रहा है, और फिर वे स्व-उपचारक तरीके से कार्रवाई भी कर सकें। हाल के एक अनुसंधान ब्लॉग में हमने इसे प्राप्त करने के एक तरीके के बारे में बात की थी, जिसे हम “autoinstall” कहते हैं।

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