क्लाउड एजेंट इंफ्रास्ट्रक्चर का निर्माण: क्या अलग है, और हमने क्या सीखा

आज के अधिकांश एजेंट फ्रेमवर्क डेस्कटॉप को ध्यान में रखकर बनाए गए हैं। एक उपयोगकर्ता, एक मशीन, एक प्रक्रिया। एजेंट तब तक चलता है जब तक लैपटॉप खुला है, लोकल फाइलसिस्टम पर लिखता है, एनवायरनमेंट वेरिएबल्स में API कीज़ रखता है, और टर्मिनल बंद होते ही मर जाता है। जब कुछ टूटता है, तो उपयोगकर्ता पुनः प्रयास करता है। जब एजेंट को कोई पैकेज चाहिए, तो pip install उसे उपयोगकर्ता के Python में डाल देता है। स्टेट, सीक्रेट्स और लाइफसाइकिल, सब एक ही विश्वसनीय सीमा के अंदर बैठते हैं।

क्लाउड एजेंट इंफ्रास्ट्रक्चर के पास ये सारी सुविधाएँ नहीं हैं।

एजेंट एक सैंडबॉक्स पर चलता है जो हर बार ताज़ा बूट होता है, अजनबियों के साथ साझा हार्डवेयर पर, उन कॉलर्स द्वारा ट्रिगर किया जाता है जिनसे उपयोगकर्ता कभी नहीं मिलता: एक शेड्यूल, एक HTTP अनुरोध, दूसरा एजेंट। जब रन होता है तब उपयोगकर्ता आमतौर पर सो रहा होता है। सैंडबॉक्स के अंदर का कोड विरोधी हो सकता है। फाइलसिस्टम को डिप्लॉयमेंट से बचना होता है। क्रेडेंशियल्स वहाँ नहीं रह सकते जहाँ एजेंट रहता है। डेस्कटॉप आपको मुफ्त में जो गारंटी देता है — पर्सिस्टेंस, आइडेंटिटी, नेटवर्क ट्रस्ट, रिट्राई — उन सबको एक स्पष्ट सिस्टम के रूप में फिर से बनाना होता है।

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

सबक 1: धीरे बदलने वाली चीज़ों को तेज़ बदलने वाली चीज़ों से अलग करें

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

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

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

फिर कपलिंग की समस्या सामने आती है।

वही इमेज जो उपयोगकर्ता के वातावरण को फ्रीज करती है, उसमें रनर कोड भी होता है — हमारे द्वारा विकसित छोटा हार्नेस लाइब्रेरी जो हर रन पर एजेंट को मैनेज करता है। उपयोगकर्ता चाहता है कि उनका वातावरण स्थिर रहे। हम चाहते हैं कि हमारा रनर दिन में कई बार शिप हो। एक आर्टिफैक्ट, दो विपरीत आवश्यकताएँ।

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

अनअटेंडेड रनों ने उस कवर को मार डाला। सोमवार सुबह 9 बजे का एक cron job अपना वातावरण नहीं खोना चाहिए क्योंकि हमने 8:55 पर डिप्लॉय किया। वह अनुबंध जिसका हम चुपचाप उल्लंघन कर रहे थे — "आपका वातावरण तब तक फ्रोजन है जब तक आप इसे बदलते नहीं" — टूट गया।

समाधान देखने में हमें अपेक्षा से अधिक समय लगा। उपयोगकर्ता का वातावरण और रनर कोड पूरी तरह से अलग दरों पर बदलते हैं। उपयोगकर्ता अपने एजेंट को तब संपादित करता है जब वह चाहता है। हम प्लेटफॉर्म को दिन में कई बार डिप्लॉय करते हैं। उन्हें एक आर्टिफैक्ट के रूप में मानने से हर डिप्लॉयमेंट पर एक विकल्प मजबूर होता था: पुराना रनर कोड रखें, या उस फ्रोजन वातावरण को नष्ट करें जिसे उपयोगकर्ता ने स्पष्ट रूप से संरक्षित करने के लिए कहा था।

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

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

1. नए रनर को सैंडबॉक्स के अंदर एक टेम्प डायरेक्टरी में स्टेज करें।
2. node --check से इसे वैलिडेट करें ताकि किसी भी सिंटैक्स एरर को पकड़ा जा सके इससे पहले कि हम कुछ लाइव को छूएँ।
3. इसे एटॉमिक रूप से स्वैप करें: पुराने रनर पर इम्यूटेबल फ्लैग को अनलॉक करें, नए को कॉपी करें, chattr +i से फिर से लॉक करें, फिर chattr बाइनरी को स्वयं छिपा दें ताकि सैंडबॉक्स कोड लॉक को उलट न सके।
4. V8 के कम्पाइल कैश (/home/user/.cache/v8-compile-cache/*) को पर्ज करें ताकि नई फाइल वास्तव में लोड हो, पुराने बाइटकोड को चलाने के बजाय।
5. यदि कोई भी चरण विफल होता है, तो सैंडबॉक्स को मारें और ताज़ा के साथ पुनः प्रयास करें। कोई आधा-अपग्रेड किया गया स्टेट कभी एजेंट नहीं चलाता।

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

यदि आप इस सबक से एक चीज़ लेते हैं, तो वह है नैदानिक प्रश्न। किसी भी चीज़ के लिए जिसे आप क्लाउड प्लेटफॉर्म पर बनाए रखते हैं, पूछें: इस आर्टिफैक्ट पर परिवर्तन की ताल कौन नियंत्रित करता है? यदि उपयोगकर्ता और प्लेटफॉर्म दोनों इसके मालिक हैं, तो आपको अंततः कपलिंग की कीमत चुकानी होगी। आर्टिफैक्ट को स्वामित्व की सीमा के साथ विभाजित करें और प्रत्येक पक्ष को अपनी घड़ी पर अपडेट करने दें।

सबक 2: सीक्रेट्स को एग्जीक्यूशन बाउंड्री से बाहर रखें

यह वह सबक है जो क्लाउड एजेंट इंफ्रास्ट्रक्चर को बाकी सब से अलग करता है।

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

हमारा नियम सरल है। कोई भी लंबे समय तक चलने वाला क्रेडेंशियल कभी सैंडबॉक्स के अंदर नहीं रहता।

जब किसी एजेंट को किसी प्रमाणित सेवा — Slack, GitHub, उपयोगकर्ता की अपनी API — को कॉल करने की आवश्यकता होती है, तो वह टोकन अपने पास नहीं रखता। वह सैंडबॉक्स के बाहर चल रहे एक API ब्रिज को एक लोकल HTTP अनुरोध भेजता है। ब्रिज होस्ट साइड पर OAuth टोकन संलग्न करता है और कॉल को आगे बढ़ाता है। प्रतिक्रिया बिना टोकन के कभी सैंडबॉक्स की मेमोरी या एनवायरनमेंट में प्रवेश किए वापस आती है।

दिलचस्प हिस्सा यह है कि ब्रिज को कैसे पता चलता है कि सैंडबॉक्स को पूछने की अनुमति है। दो जाँचें, जानबूझकर स्तरित।

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

दूसरा, प्रति रन मिंट किया गया एक अल्पकालिक JWT। जब कोई सैंडबॉक्स बूट होता है, तो प्लेटफॉर्म एक टोकन पर हस्ताक्षर करता है जो उस विशिष्ट रन तक सीमित होता है: कौन सा उपयोगकर्ता, कौन सा ऐप, कौन सा सत्र, एक समाप्ति के साथ जो रन विंडो को कवर करता है और उससे अधिक कुछ नहीं। सैंडबॉक्स इसे हर ब्रिज कॉल पर प्रस्तुत करता है। ब्रिज हस्ताक्षर सत्यापित करता है, समाप्ति की जाँच करता है, और उसके बाद ही उपयोगकर्ता के संग्रहीत क्रेडेंशियल्स को हल करता है और उन्हें सर्वर-साइड संलग्न करता है। यदि कोई सैंडबॉक्स अपहृत हो जाता है, तो हमलावर को एक ऐसा टोकन मिलता है जो रन के साथ मर जाता है और केवल उसी सत्र तक सीमित कॉल को अधिकृत करता है। चुराने के लिए कोई मास्टर क्रेडेंशियल नहीं है।

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

यदि कोई प्रॉम्प्ट इंजेक्शन कल किसी एजेंट को process.env को एक वेबहुक पर डंप करने के लिए मनाता है, तो हमलावर को एक अल्पकालिक JWT मिलता है जो केवल हमारे नेटवर्क के अंदर से काम करता है और रन के साथ समाप्त हो जाता है। वह गुण ही हमें अविश्वसनीय उपयोगकर्ता कोड को साझा बुनियादी ढाँचे पर बिना चिंता के चलाने देता है।

अंतर्निहित पैटर्न

विश्वसनीय, सुरक्षित क्लाउड एजेंट इंफ्रास्ट्रक्चर कोई नई प्रणाली नहीं है। यह कुछ ऐसे गुण हैं जिन्हें बिना किसी अपवाद के धारण किया जाता है:

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

वह अंतिम गुण पूरे डिज़ाइन का मुख्य बिंदु है। एक executeAgent फंक्शन UI क्लिक, शेड्यूल किए गए रन और API कॉल को संभालता है। बिलिंग सिस्टम, क्रेडिट कटौती लॉग, ऑब्जर्वेबिलिटी सिग्नल — सभी समान, भले ही किसी मानव ने Run क्लिक किया हो, कोई cron फायर हुआ हो, या किसी स्क्रिप्ट ने API को कॉल किया हो। एक नया ट्रिगर सरफेस जोड़ना एक रूटिंग परिवर्तन है, आर्किटेक्चर परिवर्तन नहीं। एजेंट स्वयं नहीं जानता या परवाह नहीं करता कि ट्रिगर किसने खींचा।

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

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

यही वह चीज़ है जो अगले सरफेस को शिप करने के लिए सस्ता और सुरक्षित बनाती है।