VPS पर AI agent कैसे बनाएँ

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

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

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

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

Tools: एक agent कैसे कार्य करता है

Tool वह कोई भी capability है जो आप model को सौंपते हैं, जिसे इतनी अच्छी तरह वर्णित किया गया हो कि उसे पता हो कि इसका उपयोग कब करना है। File पढ़ना, shell command चलाना, database query करना, message भेजना: प्रत्येक एक tool है जिसमें एक name, एक संक्षिप्त description, और inputs की एक list होती है। आप tools को define करते हैं; model तय करता है कि उन्हें कब call करना है।

आप चाहे कोई भी model उपयोग करें, mechanism हर जगह समान है। model एक structured request return करता है जो एक tool का नाम लेता है और उसके inputs भरता है। आपका code उस request को देखता है, matching function चलाता है, और परिणाम अगले turn में वापस भेज देता है। model परिणाम पढ़ता है और या तो दूसरे tool को call करता है या अपना अंतिम उत्तर लिखता है। Function calling हर agent के नीचे का plumbing है, और इसे चलाने वाला loop साधारण code की कुछ lines मात्र है।

यही वह स्थान भी है जहाँ आपका control होता है। model command चलाने के लिए कह सकता है, लेकिन कुछ भी तब तक नहीं चलता जब तक आपका code उसे चलाने का निर्णय न ले ले। वह gap वह जगह है जहाँ आप खतरनाक actions के लिए approval prompts, tools की पहुँच पर सीमाएँ (limits), और agent द्वारा किए गए सभी कार्यों का log रखते हैं। एक agent उतना ही सुरक्षित होता है जितने tools आप उसे देते हैं और जितने checks आप उनके सामने लगाते हैं।

MCP: tools को जोड़ने का एक standard तरीका

हर service के लिए हाथ से नया integration लिखना जल्दी थकाऊ हो जाता है। Model Context Protocol, या MCP, एक open standard है जो इस समस्या का समाधान करता है। अपनी files, अपने database, और अपने issue tracker के लिए एक नया tool code करने के बजाय, आप agent को एक MCP server की ओर point करते हैं जो पहले से ही उन चीजों को tools के रूप में expose करता है। agent एक protocol बोलता है; server वास्तविक system से बात करने का काम करता है।

इसका लाभ reuse है। किसी अन्य व्यक्ति द्वारा आपके द्वारा उपयोग की जाने वाली service के लिए लिखा गया MCP server बिना किसी नए integration code के आपके agent के लिए उपलब्ध हो जाता है, और आपके द्वारा लिखा गया server किसी भी agent द्वारा उपयोग किया जा सकता है जो उस protocol को बोलता है। एक VPS पर यह महत्वपूर्ण है, क्योंकि आप MCP servers को agent के बगल में अपनी स्वयं की छोटी services के रूप में चला सकते हैं, जिनमें से प्रत्येक के पास केवल आवश्यक access होता है। मैं running MCP servers on a VPS में setup का विवरण देता हूँ।

Memory और retrieval

एक language model के पास calls के बीच अपनी कोई memory नहीं होती है। वर्तमान कार्य के बारे में उसे जो कुछ भी पता होता है, वह हर turn में उसे दिया जाना चाहिए। एक छोटे कार्य के लिए यह ठीक है, क्योंकि पूरी conversation एक request में आ जाती है। किसी भी लंबे कार्य के लिए आपको memory स्वयं manage करनी होगी, और दो patterns हैं जिन्हें जानना महत्वपूर्ण है।

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

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

Many agents, one coordinator

अधिकांश कार्यों के लिए कई tools वाला एक agent पर्याप्त है। जब कोई कार्य बड़ा होता है या स्वाभाविक रूप से भागों में विभाजित होता है, तो एक अलग संरचना सहायक होती है: एक coordinator agent जो specialised sub-agents को delegate करता है। coordinator लक्ष्य को टुकड़ों में तोड़ता है, प्रत्येक टुकड़े को उस प्रकार के कार्य के लिए बने sub-agent को सौंपता है, और परिणामों को जोड़ता है।

इसका लाभ focus है। एक narrow job और छोटे tool set वाला sub-agent, सब कुछ संभालने वाले generalist की तुलना में बेहतर निर्णय लेता है, और स्वतंत्र हिस्से एक साथ चल सकते हैं। इसकी लागत coordination है, जो वास्तविक है, इसलिए जब तक कार्य स्पष्ट रूप से अधिक की मांग न करे, तब तक एक ही agent तक सीमित रहें। सरल शुरुआत करें, और agents तभी जोड़ें जब एक agent स्पष्ट रूप से संघर्ष (straining) कर रहा हो।

Self-hosted या hosted: आपका agent कौन सा model चलाता है

model एक agent का वह एकमात्र हिस्सा है जिसे आपको स्वयं चलाने की आवश्यकता नहीं है, और यह तय करना कि यह कहाँ रहता है, आपका सबसे बड़ा निर्णय होगा। API के माध्यम से पहुँचाया जाने वाला एक hosted model, बिना किसी operation के आपको सबसे मजबूत reasoning देता है: आप text भेजते हैं, आपको text वापस मिलता है। एक self-hosted model आपके अपने server पर चलता है, जो हर request को private रखता है, प्रति token शुल्क के बजाय एक flat price लेता है, और कभी भी किसी अन्य के online रहने पर निर्भर नहीं करता है। इसका trade-off capability और effort है। सबसे अच्छे hosted models उस क्षमता से आगे हैं जो आप स्वयं चला सकते हैं, और अपना खुद का चलाने का अर्थ है इसे फिट होने के लिए पर्याप्त memory देना।

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

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

Server सबसे खतरनाक हिस्सा है

एक agent जो shell commands चला सकता है और files लिख सकता है, वह शक्तिशाली है, और यही कारण है कि वह खतरनाक है। model का judgement अच्छा है लेकिन perfect नहीं है, और एक गलत instruction, एक bug, या एक hostile input एक मददगार agent को ऐसी चीज़ में बदल सकता है जो गलत चीज़ डिलीट कर दे या कोई secret लीक कर दे। security work वैकल्पिक नहीं है, और server पर यह वह हिस्सा है जो सबसे अधिक मायने रखता है।

कुछ आदतें अधिकांश भार संभाल लेती हैं। agent को एक dedicated unprivileged user के रूप में चलाएं, कभी भी root के रूप में नहीं, ताकि गलती की एक सीमा (ceiling) हो; यही reasoning running services as an unprivileged user में दी गई है। इसकी secrets, जैसे API keys, को code से बाहर रखें और केवल उसी user द्वारा readable रखें। और उन tools को sandbox करें जो system को touch करते हैं, ताकि agent केवल उसी तक पहुँच सके जिसकी उसे वास्तव में आवश्यकता है। एक वास्तविक self-hosted agent को harden करने के उदाहरण के लिए, running OpenClaw safely on a VPS देखें। यदि आप intelligence के लिए hosted model का उपयोग करना चाहते हैं, तो building an agent with Claude on a VPS पर companion guide उन्हीं विचारों को लेती है और उनके पीछे एक विशिष्ट model रखती है।

एक उदाहरण के लिए, building an OpenClaw-style personal agent इन हिस्सों को लागू करता है, और यदि आप एक तैयार agent चलाना चाहते हैं, तो self-hosting Hermes Agent on a VPS या running Agent Zero on your own server से शुरुआत करें, और the best self-hosted AI agents in 2026 हमारे द्वारा कवर किए गए प्रत्येक ready-made option की तुलना side by side करता है।

FAQ

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

एक chatbot एक message का उत्तर देता है और रुक जाता है। एक agent एक loop चलाता है: model एक action का निर्णय लेता है, आपका code उसे पूरा करता है, परिणाम वापस model के पास जाता है, और यह तब तक दोहराया जाता है जब तक कार्य पूरा न हो जाए। अंतर यह है कि एक agent केवल text produce करने के बजाय अपने turns के बीच वास्तविक actions लेता है, जैसे files पढ़ने, commands चलाने, या services query करने के लिए tools को call करना।

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

केवल तभी यदि आप model को self-host करते हैं। Agent loop, tools, और memory साधारण code है जो बिना GPU वाले सामान्य VPS पर ठीक से चलता है। GPU तब महत्वपूर्ण होता है जब आप language model को अपने स्वयं के hardware पर चलाना चाहते हैं, क्योंकि model को memory में फिट होना होता है। यदि आप API के माध्यम से hosted model का उपयोग करते हैं, तो भारी computation कहीं और होता है और एक साधारण VPS पर्याप्त है।

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

MCP, Model Context Protocol, एक agent को tools और data sources से जोड़ने के लिए एक open standard है। आपको इसकी सख्त आवश्यकता नहीं है, क्योंकि आप प्रत्येक tool को हाथ से लिख सकते हैं। MCP आपको सामान्य services के लिए मौजूदा servers का reuse करने और अपने स्वयं के systems को किसी भी agent के उपयोग के लिए एक बार में expose करने की अनुमति देकर आपका काम आसान बनाता है। यह एक convenience है जो integrations की संख्या बढ़ने पर सार्थक हो जाता है।

क्या AI agent को मेरे server तक पहुँच देना सुरक्षित है?

यह हो सकता है, यदि आप इसे नियंत्रित (contain) करते हैं। एक agent जो commands चलाता है, वह केवल उतना ही सुरक्षित है जितना कि वह account जिसके तहत वह चलता है और वे tools जिनकी आप अनुमति देते हैं। इसे unprivileged user के रूप में चलाएं, इसकी secrets को पहुँच से बाहर रखें, filesystem को touch करने वाले tools को sandbox करें, और उन actions के लिए approval की आवश्यकता रखें जिन्हें undo करना कठिन हो। agent को एक untrusted code की तरह मानें जो बहुत चतुर है, और इसे केवल वही दें जिसकी कार्य को आवश्यकता है।