VPS पर अपना खुद का AI agent कैसे बनाएं

AI agent वास्तव में क्या है

AI agent एक language model के चारों ओर बना एक loop है। Model स्थिति को पढ़ता है, एक action का निर्णय लेता है, आपका code उस action को पूरा करता है, परिणाम वापस model के पास जाता है, और यह loop तब तक चलता है जब तक कार्य पूरा न हो जाए। यही इसका मूल विचार है। एक साधारण chatbot एक बार उत्तर देता है और रुक जाता है। एक agent अपना काम जारी रखता है, अपनी बारी के बीच वास्तविक actions लेता है, जब तक कि वह आपके द्वारा दिए गए लक्ष्य तक न पहुँच जाए। यह loop इतना छोटा है कि आप इसे एक दोपहर में खुद लिख सकते हैं, जहाँ से शून्य से agents सीखने का एक चरणबद्ध मार्ग शुरू होता है, जिसके बाद इसमें tools, memory और safety जोड़ी जाती है।

Action इसका सबसे महत्वपूर्ण हिस्सा है। अपने आप में एक language model केवल text उत्पन्न करता है। यह न तो कोई file पढ़ सकता है, न API call कर सकता है, और न ही कोई command चला सकता है। एक agent model को tools का एक set देता है जिन्हें इस्तेमाल करने की उसे अनुमति होती है, और उन्हें माँगने का एक तरीका भी देता है। जब model web search करना चाहता है या कोई file लिखना चाहता है, तो वह खुद काम नहीं करता है। वह एक structured request भेजता है, आपका code tool को चलाता है, और उत्तर उस अगली चीज़ के रूप में वापस आता है जिसे model पढ़ता है। Model निर्णय लेने की क्षमता प्रदान करता है; आपका server उसे क्रियान्वित करने के लिए हाथ प्रदान करता है।

हर कार्य के लिए agent की आवश्यकता नहीं होती, और डिफ़ॉल्ट रूप से agent का उपयोग करना एक आम गलती है। यदि चरण पहले से ज्ञात हैं, तो एक साधारण script अधिक सरल, तेज़ और विश्वसनीय होती है। "हर घंटे यह page fetch करें और मुझे कीमत email करें" एक scheduled job है, न कि कोई agent। Agent तब बनाएँ जब रास्ता पहले से तय न हो, जब model को यह देखना हो कि उसे क्या मिला है और उसके आधार पर यह तय करना हो कि आगे क्या करना है। Agent की कीमत उसकी अनिश्चितता है, इसलिए इसका उपयोग केवल तभी करें जब इसकी लचीलापन (flexibility) सार्थक हो।

Tools: एक एजेंट कैसे काम करता है

Tool कोई भी ऐसी क्षमता है जिसे आप मॉडल को देते हैं, जिसे इतनी स्पष्टता से वर्णित किया जाता है कि वह जान सके कि इसका उपयोग कब करना है। किसी फाइल को पढ़ना, shell command चलाना, database query करना, या message भेजना: प्रत्येक एक tool है जिसका अपना नाम, संक्षिप्त विवरण और inputs की सूची होती है। आप tools को परिभाषित करते हैं; मॉडल यह तय करता है कि उन्हें कब कॉल करना है। Web search आमतौर पर सबसे पहला tool है जिसे जोड़ना सार्थक होता है, और यदि आप पहले से ही अपना SearXNG instance चला रहे हैं, तो आप इसे एजेंट के search backend में बदल सकते हैं बजाय इसके कि आप किसी commercial search API के लिए भुगतान करें।

यह प्रक्रिया हर जगह समान है, चाहे आप कोई भी मॉडल उपयोग करें। मॉडल एक structured request लौटाता है जो एक tool का नाम बताती है और उसके inputs को भरती है। आपका code उस request को देखता है, संबंधित function को चलाता है, और परिणाम को अगले turn में वापस भेज देता है। मॉडल परिणाम को पढ़ता है और या तो किसी अन्य tool को कॉल करता है या अपना अंतिम उत्तर लिखता है। Function calling हर एजेंट के पीछे की plumbing है, और इसे चलाने वाला loop केवल कुछ पंक्तियों का सामान्य code होता है।

यहीं पर आपका नियंत्रण भी निहित होता है। मॉडल किसी command को चलाने के लिए कह सकता है, लेकिन जब तक आपका code उसे चलाने का निर्णय नहीं लेता, तब तक कुछ भी रन नहीं होता। वह अंतराल ही वह जगह है जहाँ आप खतरनाक कार्यों के लिए approval prompts, tool किन चीजों को छू सकता है इसकी सीमाएं, और एजेंट द्वारा की गई हर गतिविधि का log रख सकते हैं। एक एजेंट उतना ही सुरक्षित होता है जितने tools आप उसे देते हैं और जो जांच आप उनके सामने रखते हैं।

MCP: टूल्स को कनेक्ट करने का एक मानक तरीका

हर सर्विस के लिए मैन्युअल रूप से नया इंटीग्रेशन लिखना जल्दी ही थकाऊ हो जाता है। Model Context Protocol, या MCP, एक ओपन स्टैंडर्ड है जो इस समस्या का समाधान करता है। अपनी फाइलों, डेटाबेस और इश्यू ट्रैकर के लिए अलग-अलग टूल कोड करने के बजाय, आप एजेंट को एक ऐसे MCP सर्वर की ओर निर्देशित करते हैं जो उन चीजों को पहले से ही टूल के रूप में एक्सपोज़ करता है। एजेंट एक ही प्रोटोकॉल का उपयोग करता है; सर्वर वास्तविक सिस्टम से बात करने का काम करता है।

इसका लाभ पुन: उपयोग (reuse) है। किसी और द्वारा आपके द्वारा उपयोग की जाने वाली सर्विस के लिए लिखा गया MCP सर्वर बिना किसी नए इंटीग्रेशन कोड के आपके एजेंट के लिए उपलब्ध हो जाता है, और आपके द्वारा लिखा गया सर्वर उस प्रोटोकॉल का समर्थन करने वाले किसी भी एजेंट द्वारा उपयोग किया जा सकता है। कुछ self-hosted ऐप्स अब अपना खुद का MCP सर्वर प्रदान करते हैं: openGym, एक वर्कआउट ट्रैकर एक read-only MCP सर्वर एक्सपोज़ करता है, ताकि एक एजेंट आपके ट्रेनिंग इतिहास के बारे में सवालों के जवाब दे सके, बिना उसमें कोई बदलाव किए। VPS पर यह महत्वपूर्ण है, क्योंकि आप MCP सर्वर्स को एजेंट के साथ-साथ उनकी अपनी छोटी सर्विस के रूप में चला सकते हैं, जिनमें से प्रत्येक के पास केवल आवश्यक एक्सेस हो। जब उन सर्वर्स के पीछे के सिस्टम ऐसे नेटवर्क पर होते हैं जिन्हें VPS नहीं देख सकता, जैसे कि घर या ऑफिस का डेटाबेस, तो उस नेटवर्क को अपने tailnet पर एक subnet router के साथ advertise करना एजेंट को उन्हें प्राइवेट एड्रेस के माध्यम से एक्सेस करने की अनुमति देता है, बिना किसी चीज़ को पब्लिक इंटरनेट पर एक्सपोज़ किए। मैंने VPS पर MCP सर्वर्स चलाने के सेटअप को कवर किया है।

मेमोरी और रिट्रीवल

एक language model की अपनी कोई मेमोरी नहीं होती जो एक कॉल से दूसरी कॉल तक बनी रहे। वर्तमान कार्य के बारे में जो कुछ भी उसे पता होता है, वह हर बार उसे देना पड़ता है। छोटे कार्यों के लिए यह ठीक है, क्योंकि पूरी बातचीत एक ही request में आ जाती है। कितना डेटा समा सकता है, यह context window पर निर्भर करता है। Ollama द्वारा serve किए जाने वाले self-hosted model में एक छोटा default context window होता है जो चुपचाप सबसे पुरानी बातों को हटा देता है। इसलिए, agent को भूलने का दोषी ठहराने से पहले num_ctx को अपने लूप द्वारा उत्पन्न traffic के अनुसार सेट करना उचित है। लंबे कार्यों के लिए आपको स्वयं मेमोरी मैनेज करनी होगी, और इसके लिए दो तरीके जानने योग्य हैं।

पहला तरीका scratchpad है। आप agent को एक ऐसी file देते हैं जिसे वह पढ़ और लिख सकता है, और उसे निर्देश देते हैं कि वह जो कुछ भी सीखे उसे उसमें दर्ज करे। अगली turn या अगले session में, वह file को वापस पढ़ता है और वहीं से शुरू करता है जहाँ उसने छोड़ा था। यह एक साधारण document के रूप में मेमोरी है, और यह इसलिए काम करता है क्योंकि agent उस file को एक अन्य tool की तरह ही इस्तेमाल करता है।

दूसरा तरीका retrieval है। जब agent को दस्तावेजों के एक बड़े संग्रह से जानकारी की आवश्यकता होती है जो कभी भी एक request में नहीं आ सकते, तो आप उन दस्तावेजों को searchable रूप में store करते हैं। जब जरूरत होती है, तो केवल प्रासंगिक हिस्सों को ही model के view में लाया जाता है। इस पैटर्न को retrieval-augmented generation या RAG कहा जाता है। agent एक सवाल पूछता है, आपका code मेल खाते हुए कुछ अंश ढूँढता है, और केवल वही model तक भेजे जाते हैं। यह store आपके server पर रहता है, इसलिए आपके निजी दस्तावेज कभी भी बाहर नहीं जाते।

कई एजेंट, एक समन्वयक

अधिकांश कार्यों के लिए कई टूल्स वाला एक एजेंट पर्याप्त होता है। जब कोई कार्य बड़ा हो या स्वाभाविक रूप से कई भागों में विभाजित हो, तो एक अलग संरचना अधिक प्रभावी होती है: एक समन्वयक एजेंट (coordinator agent) जो विशेष उप-एजेंटों (sub-agents) को कार्य सौंपता है। समन्वयक लक्ष्य को टुकड़ों में तोड़ता है, प्रत्येक टुकड़े को उस कार्य के लिए बने उप-एजेंट को सौंपता है, और परिणामों को संयोजित करता है। कार्य सौंपने (delegation) के लिए भागों के बीच एक चैनल की आवश्यकता होती है, और इसका सबसे सरल संस्करण पहले से ही आपके सर्वर पर मौजूद है: एक ही VPS पर दो Claude Code सत्र एक-दूसरे को संदेश भेज सकते हैं, जो यह समझने का एक सस्ता तरीका है कि अपना स्वयं का समन्वय तंत्र बनाने से पहले हैंडऑफ़ कैसे काम करते हैं।

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

Self-hosted या hosted: आपका agent किस मॉडल पर चलता है

मॉडल आपके agent का वह हिस्सा है जिसे आपको स्वयं चलाने की आवश्यकता नहीं है, और यह चुनना कि यह कहाँ स्थित होगा, आपका सबसे महत्वपूर्ण निर्णय होगा। एक hosted मॉडल, जिसे API के माध्यम से एक्सेस किया जाता है, आपको सबसे सटीक reasoning प्रदान करता है और आपको कुछ भी operate नहीं करना पड़ता: आप text भेजते हैं, और आपको उत्तर में text प्राप्त होता है। एक self-hosted मॉडल आपके अपने सर्वर पर चलता है, जो हर request को private रखता है, प्रति token शुल्क के बजाय एक निश्चित लागत पर चलता है, और किसी अन्य सेवा के चालू रहने पर निर्भर नहीं रहता। इसका समझौता क्षमता और प्रयास के बीच है। सबसे अच्छे hosted मॉडल आपकी स्वयं की क्षमता से आगे हैं, और अपने मॉडल को चलाने का अर्थ है उसे पर्याप्त memory प्रदान करना।

अंतिम बिंदु व्यावहारिक चुनौती है। एक मॉडल को आपके सर्वर की memory में फिट होना चाहिए, और यदि आप GPU का उपयोग करते हैं, तो उसकी video memory में। जो मॉडल hardware के लिए बहुत बड़ा है, वह load नहीं होगा। self-hosted agent की योजना बनाने से पहले, यह जाँच लें कि क्या आप जिस मॉडल का उपयोग करना चाहते हैं, वह आपकी मशीन में फिट बैठता है:

यदि आंकड़े मेल नहीं खाते हैं, तो आपके पास तीन विकल्प हैं: एक छोटा मॉडल चुनें, उसे छोटा करने के लिए अधिक aggressive quantization का उपयोग करें, या reasoning के लिए hosted API का उपयोग करें और केवल अपने tools और data को सर्वर पर रखें। कई self-hosted agents Ollama on a VPS के माध्यम से एक local मॉडल के साथ शुरू होते हैं और सबसे कठिन चरणों के लिए hosted API का सहारा लेते हैं।

सर्वर सबसे जोखिम भरा हिस्सा है

एक ऐसा एजेंट जो shell commands चला सकता है और files लिख सकता है, वह बहुत शक्तिशाली होता है, और यही कारण है कि यह खतरनाक भी है। मॉडल का निर्णय अच्छा है लेकिन पूर्ण नहीं है, और एक गलत निर्देश, एक bug, या कोई hostile input एक सहायक एजेंट को ऐसा बना सकता है जो गलत चीज़ को delete कर दे या किसी secret को leak कर दे। सुरक्षा का काम वैकल्पिक नहीं है, और सर्वर पर यही वह हिस्सा है जो सबसे अधिक मायने रखता है।

कुछ आदतें अधिकांश सुरक्षा सुनिश्चित करती हैं। एजेंट को एक समर्पित unprivileged user के रूप में चलाएं, कभी भी root के रूप में नहीं, ताकि किसी गलती का प्रभाव सीमित रहे; यही तर्क unprivileged user के रूप में services चलाने में भी दिया गया है। इसके secrets, जैसे कि API keys, को code से बाहर रखें और उन्हें केवल उस user द्वारा ही पढ़ने योग्य रखें। और उन tools को sandbox करें जो system को प्रभावित करते हैं, ताकि एजेंट केवल उन्हीं चीज़ों तक पहुँच सके जिनकी उसे वास्तव में आवश्यकता है। यदि आप हर जांच को खुद नहीं लिखना चाहते हैं, तो DeepSeek Harness plugins जिन्हें इंस्टॉल करना चाहिए तैयार-उपलब्ध समाधानों के रूप में वही काम करते हैं: tool permission rules, prompt injection scanning, और एजेंट के रुकने से पहले उसके खर्च की सीमा तय करना। एक वास्तविक self-hosted एजेंट को सुरक्षित बनाने के उदाहरण के लिए, VPS पर OpenClaw को सुरक्षित रूप से चलाना देखें। यदि आप intelligence के लिए hosted मॉडल का उपयोग करना पसंद करते हैं, तो VPS पर Claude के साथ एजेंट बनाना पर दी गई companion guide उन्हीं विचारों को अपनाती है और उनके पीछे एक विशिष्ट मॉडल का उपयोग करती है।

एक व्यावहारिक उदाहरण के लिए, OpenClaw-style व्यक्तिगत एजेंट बनाना इन हिस्सों को लागू करता है, और यदि आप एक तैयार एजेंट चलाना चाहते हैं, तो VPS पर Hermes Agent को self-host करना या अपने सर्वर पर Agent Zero चलाना से शुरुआत करें, और 2026 में सर्वश्रेष्ठ self-hosted AI एजेंट हमारे द्वारा कवर किए गए प्रत्येक तैयार-उपलब्ध विकल्प की तुलना करता है।

FAQ

AI agent और chatbot में क्या अंतर है?

Chatbot केवल एक संदेश का उत्तर देता है और रुक जाता है। एक agent एक लूप (loop) में चलता है: मॉडल एक क्रिया (action) तय करता है, आपका कोड उसे निष्पादित करता है, परिणाम वापस मॉडल के पास जाता है, और यह प्रक्रिया तब तक दोहराई जाती है जब तक कार्य पूरा न हो जाए। अंतर यह है कि एक agent अपनी बारी के बीच वास्तविक क्रियाएं करता है, जैसे फाइलें पढ़ने, कमांड चलाने या सेवाओं को क्वेरी करने के लिए टूल्स का उपयोग करना, न कि केवल टेक्स्ट उत्पन्न करना।

क्या AI agent को VPS पर चलाने के लिए GPU की आवश्यकता होती है?

केवल तभी, यदि आप मॉडल को स्वयं होस्ट (self-host) कर रहे हैं। Agent लूप, टूल्स और मेमोरी सामान्य कोड हैं जो बिना GPU वाले सामान्य VPS पर ठीक से चलते हैं। GPU तब मायने रखता है जब आप भाषा मॉडल को अपने हार्डवेयर पर चलाना चाहते हैं, क्योंकि मॉडल को मेमोरी में फिट होना पड़ता है। यदि आप API के माध्यम से होस्ट किए गए मॉडल का उपयोग करते हैं, तो भारी गणना कहीं और होती है और एक साधारण VPS पर्याप्त है।

MCP क्या है और क्या मुझे agent बनाने के लिए इसकी आवश्यकता है?

MCP (Model Context Protocol) एक ओपन स्टैंडर्ड है जो एक agent को टूल्स और डेटा स्रोतों से जोड़ता है। आपको इसकी सख्त आवश्यकता नहीं है, क्योंकि आप प्रत्येक टूल को हाथ से लिख सकते हैं। MCP आपको सामान्य सेवाओं के लिए मौजूदा सर्वर का पुन: उपयोग करने और अपने सिस्टम को एक बार एक्सपोज करने की सुविधा देकर वह मेहनत बचाता है। यह एक ऐसी सुविधा है जो तब उपयोगी हो जाती है जब इंटीग्रेशन की संख्या बढ़ जाती है।

क्या AI agent को अपने सर्वर का एक्सेस देना सुरक्षित है?

यह सुरक्षित हो सकता है, यदि आप इसे नियंत्रित रखें। कमांड चलाने वाला एक agent उतना ही सुरक्षित है जितना कि वह अकाउंट जिसके तहत वह चलता है और वे टूल्स जिनकी आप अनुमति देते हैं। इसे एक unprivileged user के रूप में चलाएं, इसके secrets को पहुंच से दूर रखें, फाइल सिस्टम को छूने वाले टूल्स को सैंडबॉक्स (sandbox) करें, और उन क्रियाओं के लिए अनुमोदन (approval) की आवश्यकता रखें जिन्हें पूर्ववत करना कठिन है। Agent को untrusted कोड के रूप में मानें जो संयोग से चतुर है, और इसे केवल वही दें जिसकी कार्य के लिए आवश्यकता है।