VPS वर स्वतःचा AI agent कसा तयार करावा

AI agent म्हणजे नेमके काय

AI agent म्हणजे language model भोवती तयार केलेला loop होय. Model परिस्थिती वाचतो, एका action चा निर्णय घेतो, तुमचा code तो action पूर्ण करतो, त्याचा परिणाम पुन्हा model कडे जातो आणि task पूर्ण होईपर्यंत loop पुन्हा चालतो. हीच संपूर्ण कल्पना आहे. साधा chatbot एकदा उत्तर देतो आणि थांबतो. Agent मात्र तुम्ही दिलेले goal साध्य होईपर्यंत पुढे काम करत राहतो आणि प्रत्येक turn दरम्यान प्रत्यक्ष actions घेतो. हा loop इतका छोटा असतो की तो तुम्ही एका दुपारमध्ये स्वतः लिहू शकता. त्यानंतर tools, memory आणि safety जोडण्यापूर्वी agents सुरुवातीपासून शिकण्यासाठीचा टप्प्याटप्प्याचा मार्ग इथून सुरू होतो.

Action हा महत्त्वाचा भाग आहे. स्वतःहून language model फक्त text तयार करतो. तो file वाचू शकत नाही, API call करू शकत नाही किंवा command run करू शकत नाही. Agent model ला वापरण्याची परवानगी असलेल्या tools चा संच आणि ते वापरण्याची विनंती करण्याची पद्धत देतो. Model ला web search करायचा असेल किंवा file लिहायची असेल, तर ते काम तो स्वतः करत नाही. तो structured request तयार करतो, तुमचा code tool run करतो आणि उत्तर model पुढे वाचणाऱ्या पुढील input म्हणून परत येते. Model judgement पुरवतो; तुमचा server प्रत्यक्ष कृती करण्याची क्षमता पुरवतो.

प्रत्येक task साठी agent आवश्यक नसतो. प्रत्येक वेळी agent वापरणे ही सामान्य चूक आहे. Steps आधीच माहीत असतील, तर साधा script अधिक सोपा, जलद आणि विश्वासार्ह असतो. "ही page दर तासाला fetch करा आणि price मला email करा" हे scheduled job आहे, agent नाही. मार्ग आधीच निश्चित नसताना, म्हणजे model ला मिळालेल्या माहितीचे परीक्षण करून पुढे काय करायचे ते ठरवावे लागते, तेव्हा agent तयार करा. Agent ची किंमत unpredictability आहे. त्यामुळे flexibility मुळे प्रत्यक्ष लाभ मिळत असेल तेव्हाच ती किंमत स्वीकारा.

साधने: एजंट कशा प्रकारे कार्य करतो

साधन म्हणजे तुम्ही मॉडेलला दिलेली कोणतीही क्षमता. तिचे पुरेसे स्पष्ट वर्णन केलेले असते, त्यामुळे ती कधी वापरायची हे मॉडेलला समजते. फाइल वाचणे, shell command चालवणे, database कडे query पाठवणे किंवा message पाठवणे—यापैकी प्रत्येक एक साधन आहे. प्रत्येक साधनाला नाव, संक्षिप्त वर्णन आणि inputs ची सूची असते. साधने तुम्ही परिभाषित करता; ती कधी call करायची हे मॉडेल ठरवते. Web search हे सहसा जोडण्यास योग्य असलेले पहिले साधन असते. तुमचे स्वतःचे SearXNG instance आधीपासून चालू असल्यास, व्यावसायिक search API साठी पैसे देण्याऐवजी तुम्ही ते एजंटचे search backend बनवू शकता.

तुम्ही कोणतेही model वापरले तरी ही यंत्रणा सर्वत्र सारखीच असते. मॉडेल structured request परत करते. त्या request मध्ये साधनाचे नाव असते आणि त्याचे inputs भरलेले असतात. तुमचा code तो request वाचतो, संबंधित function चालवतो आणि पुढील turn मध्ये त्याचा result पाठवतो. मॉडेल result वाचते आणि दुसरे साधन call करते किंवा अंतिम उत्तर लिहिते. Function calling ही प्रत्येक agent अंतर्गत असलेली plumbing आहे. ती चालवणारा loop ordinary code च्या फक्त काही lines मध्ये लिहिता येतो.

तुमचे नियंत्रणही याच ठिकाणी असते. मॉडेल command चालवण्याची विनंती करू शकते; परंतु तुमचा code ते चालवण्याचा निर्णय घेईपर्यंत काहीही चालत नाही. धोकादायक कृतींसाठी approval prompts, एखादे साधन कोणत्या resources वर कार्य करू शकते यावरील मर्यादा आणि एजंटने केलेल्या प्रत्येक कृतीचा log तुम्ही याच ठिकाणी ठेवता. तुम्ही एजंटला दिलेली साधने आणि त्यांच्यापुढे ठेवलेल्या checks यांइतकीच एजंटची सुरक्षितता असते.

MCP: साधने जोडण्याचा प्रमाणित मार्ग

प्रत्येक सेवेसाठी स्वतंत्र integration स्वतः लिहिणे लवकरच त्रासदायक ठरते. Model Context Protocol किंवा MCP हा यासाठी उपाय करणारा open standard आहे. तुमच्या files, database आणि issue tracker साठी स्वतंत्र tool code करण्याऐवजी, ही साधने आधीच उपलब्ध करून देणाऱ्या MCP server कडे agent निर्देशित करता. Agent एकाच protocol द्वारे संवाद साधतो; प्रत्यक्ष प्रणालीशी संवाद साधण्याचे काम server करतो.

यामुळे पुनर्वापर करता येतो. तुम्ही वापरत असलेल्या सेवेसाठी दुसऱ्याने लिहिलेला MCP server कोणताही नवीन integration code न लिहिता तुमच्या agent साठी उपलब्ध होतो. तसेच तुम्ही लिहिलेला server हा protocol वापरणाऱ्या कोणत्याही agent सोबत वापरता येतो. काही self-hosted apps आता स्वतःचा MCP server देतात: openGym, व्यायाम नोंदवणारे अॅप read-only MCP server उपलब्ध करून देते. त्यामुळे agent तुमच्या training history बद्दल प्रश्नांची उत्तरे देऊ शकतो, पण त्यात कोणताही बदल करू शकत नाही. VPS वर हे महत्त्वाचे आहे, कारण MCP servers ही agent च्या शेजारी स्वतंत्र लहान services म्हणून चालवता येतात आणि प्रत्येकाला आवश्यक तेवढाच access देता येतो. या servers मागील systems अशा network वर असतील जे VPS ला दिसत नाही, उदाहरणार्थ घरातील किंवा कार्यालयातील database, तर subnet router वापरून ते network तुमच्या tailnet ला उपलब्ध करून देणे यामुळे agent त्यांच्यापर्यंत private addresses द्वारे पोहोचू शकतो आणि public internet वर काहीही उघड करावे लागत नाही. याची setup प्रक्रिया मी VPS वर MCP servers चालवणे येथे स्पष्ट केली आहे.

स्मृती आणि पुनर्प्राप्ती

एका call नंतर दुसऱ्या call दरम्यान language model कडे स्वतःची स्मृती नसते. सध्याच्या task साठी आवश्यक असलेली सर्व माहिती प्रत्येक turn मध्ये model ला द्यावी लागते. छोट्या कामासाठी हे पुरेसे असते, कारण संपूर्ण conversation एका request मध्ये बसते. किती मजकूर बसतो हे context window वर अवलंबून असते. Ollama द्वारे serve केलेल्या self-hosted model ला लहान default context window मिळतो. त्यामुळे सर्वात जुने turns शांतपणे वगळले जातात. म्हणून agent वर विसरण्याचा दोष देण्यापूर्वी तुमचा loop तयार करत असलेल्या traffic शी num_ctx जुळवणे उपयुक्त ठरते. अधिक दीर्घ कामासाठी स्मृतीचे व्यवस्थापन स्वतः करावे लागते. यासाठी दोन पद्धती जाणून घेणे उपयुक्त आहे.

पहिली पद्धत म्हणजे scratchpad. Agent वाचू आणि लिहू शकेल अशी file द्या. त्याला काम करताना शिकलेली माहिती त्या file मध्ये नोंदवण्यास सांगा. पुढील turn मध्ये किंवा पुढील session मध्ये agent ती file पुन्हा वाचतो आणि जिथे काम थांबले होते तिथून पुढे सुरू करतो. ही plain document स्वरूपातील स्मृती आहे. Agent त्या file ला आणखी एका tool प्रमाणे वापरतो, म्हणून ही पद्धत कार्य करते.

दुसरी पद्धत म्हणजे retrieval. एका मोठ्या document संग्रहातून ज्ञान आवश्यक असताना ते संपूर्ण ज्ञान एका request मध्ये कधीच बसणार नाही. अशावेळी documents searchable स्वरूपात साठवले जातात. गरज पडल्यावर त्यातील फक्त संबंधित भाग model च्या context मध्ये आणले जातात. या पद्धतीला retrieval-augmented generation किंवा RAG म्हणतात. Agent प्रश्न विचारतो. तुमचा code जुळणारे काही passages शोधतो. त्यानंतर फक्त ते passages model कडे पाठवले जातात. Store तुमच्या server वर राहतो. त्यामुळे तुमचे private documents server च्या बाहेर जात नाहीत.

एक समन्वयक, अनेक agents

अनेक tasks साठी एक agent आणि अनेक tools पुरेसे असतात. एखादे काम मोठे असेल किंवा ते स्वाभाविकपणे अनेक भागांत विभागले जात असेल, तर वेगळी रचना अधिक उपयुक्त ठरते: specialised sub-agents कडे काम सोपवणारा coordinator agent. coordinator उद्दिष्टाचे भाग करतो, प्रत्येक भाग त्या प्रकारच्या कामासाठी तयार केलेल्या sub-agent कडे सोपवतो आणि मिळालेले परिणाम एकत्र करतो. या भागांमध्ये delegation साठी एक channel आवश्यक असतो. त्याची सर्वांत सोपी आवृत्ती तुमच्या server वर आधीपासून उपलब्ध आहे: एकाच VPS वरील दोन Claude Code sessions एकमेकांना messages पाठवू शकतात. स्वतःची coordination machinery तयार करण्यापूर्वी handoffs कसे कार्य करतात हे समजून घेण्याचा हा कमी खर्चाचा मार्ग आहे.

याचा मुख्य फायदा focus हा आहे. मर्यादित काम आणि कमी tool set असलेला sub-agent सर्वकाही हाताळणाऱ्या generalist पेक्षा चांगले निर्णय घेतो. स्वतंत्र भाग एकाच वेळी चालवता येतात. मात्र coordination ची किंमत प्रत्यक्ष असते. त्यामुळे एखाद्या कामाला अधिक agents ची स्पष्ट गरज भासेपर्यंत single agent वापरा. सुरुवात साधी ठेवा. एखादा agent स्पष्टपणे क्षमतेपलीकडे ताणला जात असेल तेव्हाच नवीन agents जोडा.

Self-hosted किंवा hosted: तुमचा agent कोणता model चालवतो

Agent मधील model हा असा एकमेव भाग आहे, जो तुम्हाला स्वतः चालवण्याची गरज नाही. तो कुठे चालवायचा हा तुमचा सर्वात मोठा निर्णय असेल. API द्वारे वापरला जाणारा hosted model काहीही operate न करता सर्वाधिक सक्षम reasoning देतो: तुम्ही text पाठवता आणि text परत मिळवता. Self-hosted model तुमच्या स्वतःच्या server वर चालतो. त्यामुळे प्रत्येक request private राहते, token-नुसार शुल्क देण्याऐवजी ठरावीक खर्च येतो आणि इतर कोणाची service उपलब्ध राहण्यावर अवलंबून राहावे लागत नाही. यासाठी capability आणि effort यांच्यात तडजोड करावी लागते. सर्वोत्तम hosted models हे तुम्ही स्वतः चालवू शकता त्यापेक्षा अधिक सक्षम असतात. स्वतःचा model चालवण्यासाठी तो memory मध्ये बसेल इतकी क्षमता द्यावी लागते.

हा शेवटचा मुद्दा व्यवहारातील अडचण आहे. Model तुमच्या server च्या memory मध्ये बसला पाहिजे. GPU वापरत असल्यास तो GPU च्या video memory मध्येही बसला पाहिजे. Hardware साठी model खूप मोठा असल्यास तो load होणार नाही. Self-hosted agent ची योजना करण्यापूर्वी, तुम्हाला हवा असलेला model तुमच्याकडील machine मध्ये बसेल का ते तपासा:

आकडे जुळत नसल्यास तुमच्याकडे तीन पर्याय आहेत: लहान model निवडा, अधिक आक्रमक quantization वापरून त्याचा आकार कमी करा किंवा reasoning साठी hosted API वापरा आणि फक्त तुमची tools आणि data server वर ठेवा. अनेक self-hosted agents सुरुवातीला VPS वर Ollama द्वारे local model वापरतात आणि सर्वात अवघड steps साठी hosted API कडे fallback करतात.

सर्व्हर हा धोकादायक भाग आहे

Shell commands चालवू शकणारा आणि files लिहू शकणारा agent शक्तिशाली असतो. याच कारणामुळे तो धोकादायकही असतो. Model चा निर्णय सामान्यतः चांगला असतो, पण तो निर्दोष नसतो. चुकीची सूचना, bug किंवा hostile input यांमुळे उपयुक्त agent चुकीची गोष्ट delete करू शकतो किंवा secret उघड करू शकतो. Security चे काम ऐच्छिक नाही. सर्व्हरवर तेच सर्वात महत्त्वाचे असते.

काही सवयी सुरक्षेचा बहुतांश भार सांभाळतात. Agent dedicated unprivileged user म्हणून चालवा; root म्हणून कधीही चालवू नका. त्यामुळे चुकांमुळे होणारे नुकसान मर्यादित राहते. हाच विचार unprivileged user म्हणून services चालवणे यामध्येही लागू होतो. API keys सारखे secrets code मध्ये ठेवू नका आणि ते फक्त त्या user ला वाचता येतील याची खात्री करा. तसेच system शी संपर्क करणारी tools sandbox करा, म्हणजे agent फक्त त्याला खरोखर आवश्यक असलेल्या resources पर्यंत पोहोचू शकेल. प्रत्येक check स्वतः लिहायचा नसेल, तर install करण्यासारखे DeepSeek Harness plugins तयार components म्हणून हीच कामे करतात: tool permission rules, prompt injection scanning आणि agent थांबण्यापूर्वी तो किती खर्च करू शकतो यावर मर्यादा. प्रत्यक्ष self-hosted agent harden करण्याचे उदाहरण पाहण्यासाठी VPS वर OpenClaw सुरक्षितपणे चालवणे पहा. Intelligence साठी hosted model वापरायचा असल्यास, VPS वर Claude वापरून agent तयार करणे या companion guide मध्ये हीच तत्त्वे घेऊन त्यामागे विशिष्ट model वापरला आहे.

प्रत्यक्ष उदाहरणासाठी OpenClaw-शैलीचा personal agent तयार करणे या मार्गदर्शकात हे components एकत्र लागू केले आहेत. तयार agent चालवायचा असल्यास VPS वर Hermes Agent self-host करणे किंवा तुमच्या स्वतःच्या server वर Agent Zero चालवणे यापासून सुरुवात करा. 2026 मधील सर्वोत्तम self-hosted AI agents मध्ये आम्ही समाविष्ट केलेल्या सर्व ready-made पर्यायांची side-by-side तुलना केली आहे.

FAQ

AI agent आणि chatbot यांच्यात काय फरक आहे?

Chatbot संदेशाला उत्तर देतो आणि थांबतो. Agent एक loop चालवतो: model एखादी कृती ठरवतो, तुमचा code ती कृती करतो, परिणाम पुन्हा model कडे जातो आणि task पूर्ण होईपर्यंत ही प्रक्रिया सुरू राहते. Agent आणि chatbot यांच्यातील फरक असा आहे की agent प्रत्येक turn दरम्यान प्रत्यक्ष कृती करतो. तो केवळ text तयार न करता files वाचण्यासाठी, commands चालवण्यासाठी किंवा services ला query करण्यासाठी tools call करतो.

VPS वर AI agent चालवण्यासाठी मला GPU आवश्यक आहे का?

तुम्ही model self-host करत असाल तरच. Agent loop, tools आणि memory हे सामान्य code असतात आणि GPU शिवायही सामान्य VPS वर व्यवस्थित चालतात. Language model तुमच्या स्वतःच्या hardware वर चालवायचा असल्यास GPU महत्त्वाचा ठरतो, कारण model memory मध्ये बसणे आवश्यक असते. तुम्ही API द्वारे hosted model वापरत असाल, तर जड computation दुसरीकडे होते आणि साधारण VPS पुरेसा असतो.

MCP म्हणजे काय आणि agent तयार करण्यासाठी त्याची गरज आहे का?

MCP म्हणजे Model Context Protocol. हे agent ला tools आणि data sources शी जोडण्यासाठीचे open standard आहे. त्याची सक्तीची गरज नाही, कारण प्रत्येक tool तुम्ही स्वतः लिहू शकता. सामान्य services साठी उपलब्ध servers पुन्हा वापरता येतात आणि तुमच्या systems ना एकदाच expose करून कोणत्याही agent ला वापरता येते, त्यामुळे MCP हे काम सोपे करते. Integrations ची संख्या वाढत गेल्यावर ही सुविधा उपयुक्त ठरते.

AI agent ला माझ्या server चा access देणे सुरक्षित आहे का?

त्याला मर्यादित access दिल्यास ते सुरक्षित असू शकते. Commands चालवणाऱ्या agent ची सुरक्षितता तो ज्या account अंतर्गत चालतो आणि तुम्ही त्याला परवानगी दिलेल्या tools वर अवलंबून असते. तो unprivileged user म्हणून चालवा, त्याची secrets त्याच्या access पासून दूर ठेवा, filesystem ला स्पर्श करणारे tools sandbox करा आणि पूर्ववत करणे कठीण असलेल्या कृतींसाठी approval आवश्यक ठेवा. Agent हा केवळ अधिक सक्षम असलेला untrusted code आहे असे समजा आणि task साठी आवश्यक तेवढाच access द्या.