−25%

Windows के सालाना भुगतान पर, 31 अक्टूबर तक। प्लान देखें

EQVPS
शुरू करें

AI एजेंटों को इन्फ्रास्ट्रक्चर से असल में क्या चाहिए: 7 ज़रूरतें, और इंसानों के लिए बनी होस्टिंग कहाँ आड़े आती है

10 अक्टू॰ 2026 · 6 मिनट पढ़ने में · EQVPS Team

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

“बस उसे एक API दे दो” कहना लुभावना है। यह पहली ज़रूरत है, आख़िरी नहीं। नीचे सात ज़रूरतें हैं जो हमें अहम लगती हैं, एजेंटों के लिए अपना MCP सर्वर और REST API बनाने के अनुभव से। हर एक के लिए: उसके बिना क्या ग़लत होता है।

1. एजेंट को जो कुछ चाहिए, वह सब प्रोग्राम से हो सके

संसाधन बनाना, देखना, उनका आकार बदलना और हटाना, सब बिना ब्राउज़र के होना चाहिए। इसमें उबाऊ हिस्से भी शामिल हैं: ख़रीदने से पहले कीमत जानना, यह जाँचना कि किसी लोकेशन में क्षमता है या नहीं, नई मशीन का पासवर्ड पढ़ना, रद्द करना।

इसके बिना: एजेंट 80% रास्ता तय करता है और उस एक क़दम पर रुक जाता है जिसके लिए क्लिक चाहिए, और आख़िरकार किसी इंसान को काम पूरा करना पड़ता है। अधूरा API अक्सर न होने से भी बुरा होता है, क्योंकि वह ऐसे ऑटोमेशन को न्योता देता है जो पूरा हो ही नहीं सकता।

2. ऐसी errors जिन पर प्रोग्राम कार्रवाई कर सके

एजेंट जवाब पढ़ता है और तय करता है कि आगे क्या करना है। स्थिर कोड वाली JSON बॉडी (402 insufficient_balance, 409 sandbox_paused, रीसेट के समय के साथ 429 budget_exceeded) ऐसी चीज़ है जिसके आधार पर वह फ़ैसला बदल सकता है। HTML error पेज, या अस्पष्ट संदेश वाला 500, उसे अंदाज़ा लगाने पर छोड़ देता है: अक्सर वह ऐसी चीज़ दोहराता रहता है जो कभी सफल नहीं होगी।

इसके बिना: retry लूप। एजेंटों की सबसे महँगी विफलताएँ आम तौर पर ग़लत फ़ैसले नहीं होतीं; वे एक ही विफल कॉल होती हैं जो हज़ारों बार दोहराई जाती है।

3. बीच में इंसान के बिना भुगतान

कार्ड भुगतान ऐसे क़दमों से भरे हैं जो यह पक्का करने के लिए बने हैं कि कोई इंसान मौजूद है: 3-D Secure कोड, बैंक ऐप में पुष्टि, पहचान की जाँच। ये धोखाधड़ी रोकने के लिए अच्छे हैं और सॉफ़्टवेयर के लिए नामुमकिन। पहले से टॉप-अप किया गया प्रीपेड बैलेंस (हमारे मामले में अक्सर stablecoins से) एजेंट को अपने इस्तेमाल का भुगतान करने देता है, बिना इसके कि हर शुल्क को कोई इंसान मंज़ूरी दे।

इसके बिना: या तो हर ख़रीद को इंसान मंज़ूरी देता है, जिससे पूरा मक़सद ही ख़त्म हो जाता है, या कोई एजेंट को कार्ड दे देता है, जो ऐसा जोखिम है जो किसी को नहीं लेना चाहिए।

4. खर्च पर सख़्त सीमाएँ

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

इसके बिना: लूप का पता आपको बैलेंस देखकर चलता है। हमारी सैंडबॉक्स बिलिंग में इसी वजह से सीमाएँ हैं, और MCP सुरक्षा उपाय पेज सुझाता है कि किन कार्रवाइयों के लिए इंसान की मंज़ूरी ज़रूरी होनी ही चाहिए।

5. सही पैमाने पर कंप्यूट

एजेंट तीन बहुत अलग तरह के काम पैदा करते हैं:

  • सेकंड: बना हुआ कोड का टुकड़ा चलाना, किसी जवाब की जाँच, किसी सुधार को आज़माना।
  • घंटे: एक evaluation, एक scrape, एक लंबा build।
  • हमेशा चालू: एक बॉट, एक API, एक शेड्यूल पर चलने वाला worker।

जो प्लेटफ़ॉर्म सिर्फ़ मासिक सर्वर देता है, वह पहले तरह के काम को बेतुका महँगा बना देता है; जो सिर्फ़ कम उम्र वाले सैंडबॉक्स देता है, वह तीसरे तरह के काम को नाज़ुक बना देता है। घंटे के हिसाब से बिल होने वाली मशीन पर 20 सेकंड का काम 59 मिनट के ख़ालीपन का भुगतान करता है। प्रति-सेकंड बिलिंग कैसे काम करती है दिखाता है कि हर मॉडल कहाँ बेमानी हो जाता है।

इसके बिना: एजेंट या तो छोटे काम के लिए ज़्यादा भुगतान करते हैं, या लंबी चलने वाली सेवाएँ ऐसे इन्फ्रास्ट्रक्चर पर चलाते हैं जो चालू रहने के लिए बना ही नहीं था।

6. डिफ़ॉल्ट रूप से आइसोलेशन

एजेंट जो कोड लिखता है, वह ऐसा कोड है जिसे किसी ने रिव्यू नहीं किया। उसे ऐसी जगह चलना चाहिए जहाँ कुछ भी क़ीमती न हो: न एजेंट का अपना होस्ट, न आपकी keys वाला सर्वर, न वह मशीन जो आपका ईमेल भेजती है। व्यवहार में इसका मतलब है हर काम के लिए अलग VM या microVM, जो बाद में हटा दी जाए। अविश्वसनीय कोड के लिए आइसोलेशन के स्तर विकल्पों की तुलना करता है; Firecracker microVM आसान भाषा में बताता है कि अपना कर्नेल क्यों मायने रखता है।

इसके बिना: बने हुए कोड में पहुँचने वाला पहला prompt injection उस हर चीज़ तक पहुँच पाता है जहाँ तक एजेंट का होस्ट पहुँच सकता है।

7. दृश्यता और बंद करने का स्विच

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

इसके बिना: सफ़ाई पुरातत्व बन जाती है। भूले हुए संसाधनों का बिल बनता रहता है; लीक हुआ टोकन काम करता रहता है।

एजेंटों को क्या नहीं चाहिए

उतना ही बताने वाला यह है कि क्या मदद नहीं करता: upsell के लिए बने डैशबोर्ड, onboarding ईमेल, ऐसे प्लान जिनकी असली सीमाएँ फ़ुटनोट में हों, साइन-अप के बाद ही दिखने वाली कीमतें। इनमें से कुछ भी सॉफ़्टवेयर नहीं पढ़ सकता, और कुछ तो टेक्स्ट को शब्दशः लेने वाले मॉडल को सक्रिय रूप से गुमराह करते हैं।

क्या अब भी अनसुलझा है

यहाँ की हर चीज़ इंजीनियरिंग की हल हो चुकी समस्या नहीं है।

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

हम कहाँ पहुँचे हैं

हमने इन ज़रूरतों से बचकर नहीं, बल्कि इन्हीं के लिए बनाने की कोशिश की है: पूरे जीवनचक्र को कवर करने वाला MCP सर्वर और REST API, मशीन से पढ़ी जा सकने वाली errors, प्रीपेड बैलेंस, खर्च सीमाएँ, छोटे काम के लिए प्रति-सेकंड कोड सैंडबॉक्स और लंबे काम के लिए AI agent प्लान जैसे मासिक सर्वर। सैंडबॉक्स वाले हिस्से की पूरी झलक AI एजेंटों के लिए सैंडबॉक्स में है। हम चाहेंगे कि आप इस सूची को उसकी अपनी ख़ूबियों पर परखें; यह किसी भी ऐसे प्लेटफ़ॉर्म के लिए उपयोगी चेकलिस्ट है जिस पर आप किसी एजेंट को खुला छोड़ते हैं।

FAQ

क्या किसी एजेंट के होस्टिंग सेवा इस्तेमाल करने के लिए API काफ़ी नहीं है?

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

अगर एजेंट प्रीपेड बैलेंस से भुगतान करते हैं, तो उन्हें खर्च की सीमा क्यों चाहिए?

प्रीपेड बैलेंस सबसे बुरे हालात को उसमें मौजूद रक़म तक सीमित करता है, जो फिर भी काफ़ी हो सकती है। दैनिक या मासिक सीमा लूप में फँसे एजेंट को ख़ाली बैलेंस के बजाय एक ख़राब दोपहर तक सीमित कर देती है, और ऐसी error लौटाती है जिसे एजेंट पहचान सके।

एजेंट के लिए कंप्यूट की सही इकाई क्या है?

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

क्या अब भी अनसुलझा है?

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

टिप्पणियाँ

अभी तक कोई टिप्पणी नहीं। पहले बनें।

एक टिप्पणी छोड़ें

टिप्पणियाँ दिखने से पहले मॉडरेट की जाती हैं।