OpenClaw जैसा AI agent कैसे बनाएं

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

OpenClaw एक self-hosted personal AI agent है। आप इसे अपने सर्वर पर चलाते हैं, इसे उन chat apps से जोड़ते हैं जिनका आप पहले से उपयोग कर रहे हैं, और यह shell commands चला सकता है, browser को नियंत्रित कर सकता है, आपकी files को पढ़ और लिख सकता है, और आपके द्वारा भेजे गए संदेशों पर कार्रवाई कर सकता है। यह MIT-licensed है, local-first है, और 2026 के मध्य तक इसके GitHub पर 380,000 से अधिक stars हैं, जो इसे platform पर सबसे अधिक stars वाले projects में से एक बनाता है। शोर के नीचे यह समझदारी से आपस में जुड़े हुए कुछ छोटे हिस्सों का एक समूह है। यह पोस्ट उन हिस्सों के बारे में बताती है ताकि आप समझ सकें कि इस तरह का tool कैसे बनाया जाता है, और इसमें जोखिम कहाँ हैं।

शुरुआत में ही एक चेतावनी, क्योंकि यह नीचे दिए गए हर design विकल्प को प्रभावित करती है। मार्च 2026 में OpenClaw में चार दिनों के भीतर नौ security issues का खुलासा हुआ था, जिसमें 9.9 में से 9.9 की rating वाली एक critical privilege-escalation खामी (CVE-2026-32922) भी शामिल थी। यह project आपके, यानी operator के द्वारा hardened किए जाने के लिए डिज़ाइन किया गया है। कोई भी command चलाने में सक्षम agent उतना ही सुरक्षित है जितना कि वह box जिस पर वह चलता है और वे सीमाएँ जो आप उस पर लगाते हैं। इसे पढ़ते समय इस बात का ध्यान रखें।

गेटवे डेमन: एक प्रोसेस, जिसे निजी रखा जाता है

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

गेटवे के बारे में सबसे महत्वपूर्ण तथ्य यह है कि यह कहाँ listen करता है। डिफ़ॉल्ट रूप से OpenClaw इसे लूपबैक एड्रेस, 127.0.0.1, पर bind करता है, इसलिए यह इंटरनेट से तब तक पहुँच योग्य नहीं होता जब तक कि आप इसे expose करने के लिए विशेष प्रयास न करें। इसे वहीं रहने दें। यह वह एकमात्र प्रोसेस है जो कमांड्स चलाती है, इसलिए एक exposed गेटवे इसे खोजने वाले किसी भी व्यक्ति को आपके सर्वर में रिमोट एक्सेस प्रदान कर देता है। जब आपको अपने लैपटॉप से इस तक पहुँचने की आवश्यकता हो, तो पोर्ट खोलने के बजाय इसे VPN या SSH टनल के माध्यम से करें। कोई भी ऐसे पोर्ट पर हमला नहीं कर सकता जिस तक वह पहुँच ही न सके।

चैनल कनेक्टर्स: संदेश प्राप्त करना और उत्तर भेजना

एक पर्सनल एजेंट तभी उपयोगी होता है जब आप अपने द्वारा पहले से उपयोग किए जा रहे ऐप्स से उससे बात कर सकें। चैनल कनेक्टर्स यही काम करते हैं। प्रत्येक कनेक्टर एक विशिष्ट प्लेटफॉर्म, जैसे Telegram, WhatsApp, Slack, या Discord से, उस प्लेटफॉर्म के bot API या webhooks का उपयोग करके बात करता है।

सभी कनेक्टर्स का स्वरूप एक जैसा होता है। कनेक्टर प्लेटफॉर्म के साथ एक bot रजिस्टर करता है, आपका आने वाला संदेश प्राप्त करता है (प्लेटफॉर्म को पोल करके या प्लेटफॉर्म द्वारा भेजे गए webhook को प्राप्त करके), उस संदेश को gateway को सौंपता है, और gateway के उत्तर को उसी API के माध्यम से वापस पोस्ट करता है। कनेक्टर एक पतली अनुवाद परत (thin translation layer) है। यह "एक Telegram संदेश आया" को "एजेंट के लिए यहाँ टेक्स्ट है" में बदलता है और वापस भी ऐसा ही करता है। अपना स्वयं का कनेक्टर बनाना मुख्य रूप से किसी एक प्लेटफॉर्म के bot documentation को पढ़ने और उसके संदेश प्रारूप को gateway के प्रारूप के साथ मैप करने का विषय है।

ब्रेन और टूल लूप

गेटवे के अंदर वह हिस्सा होता है जो इसे चैटबॉट के बजाय एक एजेंट बनाता है। यह एक लूप है।

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

वह लूप ही एक एजेंट का पूरा विचार है, और यह वही लूप है चाहे एजेंट किसी चैट ऐप में रहता हो या टर्मिनल में। टूल्स को मानक तरीके से उस लूप से कैसे जोड़ा जाता है, इसके लिए Model Context Protocol के माध्यम से टूल्स को कनेक्ट करना अगला अच्छा लेख है, और मॉडल पक्ष के लिए, अपने स्वयं के हार्डवेयर पर मॉडल को चलाना दूसरा आधा हिस्सा पूरा करता है।

टूल सेट ही मुख्य उद्देश्य है, और यही खतरा भी

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

एक एजेंट जो किसी भी command को चला सकता है और chat app से प्राप्त निर्देशों पर काम करता है, वह एक बड़ा attack surface बनाता है। एक गलत निर्देश, browser टूल द्वारा विजिट किए गए वेब पेज में छिपा prompt-injection हमला, या March 2026 की खामियों जैसा कोई bug, "मेरा कैलेंडर पढ़ो" को "मेरी फाइलें डिलीट करो" में बदल सकता है। इसलिए, सीमाएं (limits) वैकल्पिक नहीं हैं। एजेंट को एक समर्पित, unprivileged user के रूप में चलाएं जिसके पास sudo न हो, ताकि compromise होने पर अधिकार न बढ़ सकें। खतरनाक टूल्स को एक approval step के पीछे रखें ताकि कुछ भी विनाशकारी करने से पहले एजेंट आपसे अनुमति मांगे। टूल execution को sandbox में रखें ताकि कोई भी अनियंत्रित command सीमित रहे। मॉडल की API key को अलग रखें ताकि leak होने पर हमलावर के हाथ आपका अकाउंट न लगे। उसी बॉक्स पर मौजूद अन्य secrets के बारे में भी सोचें, क्योंकि Vaultwarden के वास्तविक कमजोर बिंदु उसका admin token और backup फाइल है, न कि उसकी encryption, और shell access वाला एजेंट इन दोनों तक पहुंच सकता है।

इससे पहले कि आप ऐसी किसी चीज को expose करें जो shell commands चलाती है, बुनियादी बातों को सावधानीपूर्वक पूरा करें। अपने बॉक्स के लिए यहां एक चेकलिस्ट तैयार करें, और फिर उसका ऊपर से नीचे तक पालन करें:

Unprivileged-user वाला हिस्सा unprivileged user के रूप में services चलाना में विस्तार से बताया गया है, और वास्तविक प्रोजेक्ट के लिए सुरक्षित सेटअप का पूरा विवरण VPS पर OpenClaw को सुरक्षित रूप से चलाना में उपलब्ध है।

Memory को plain files के रूप में रखना

ज्यादातर लोग उम्मीद करते हैं कि किसी agent की memory database में रहती है। OpenClaw की memory ऐसी नहीं है। यह memory को disk पर plain Markdown files के रूप में store करती है, और यह विकल्प अपनाने योग्य है।

Files सरल होती हैं। इसमें migrate करने के लिए कोई schema नहीं है, चलाने के लिए कोई service नहीं है, और सीखने के लिए कोई query language नहीं है। ये inspectable हैं: आप folder खोलकर ठीक-ठीक पढ़ सकते हैं कि agent आपके बारे में क्या मानता है, किसी file को edit करके गलत note को सुधार सकते हैं, या किसी file को हटाकर memory delete कर सकते हैं। और ये portable भी हैं, क्योंकि agent को किसी नए server पर ले जाना केवल एक directory को copy करने जैसा है। एक single-user personal agent के लिए, text files का एक folder पर्याप्त है, और यह पूरे system को समझने में आसान बनाए रखता है।

Skills: क्षमताएं जोड़ने का एक पोर्टेबल तरीका

इन-बिल्ट टूल्स के अलावा, OpenClaw एक पोर्टेबल skill फॉर्मेट का उपयोग करता है ताकि कम्युनिटी इसके कोर में बदलाव किए बिना इसकी क्षमताओं का विस्तार कर सके। एक skill निर्देशों और कभी-कभी कोड का एक आत्मनिर्भर बंडल होता है, जो एजेंट को एक नया कार्य करना सिखाता है। जब कार्य की आवश्यकता होती है, तो एजेंट उस skill को लोड कर लेता है। वेब सर्च आमतौर पर पहली skill है जिसे लोग जोड़ते हैं, और उस skill को अपने स्वयं के SearXNG instance की ओर निर्देशित करना आपकी क्वेरीज़ को कमर्शियल सर्च API से दूर रखता है। साथ ही, यह स्पष्ट करता है कि skill की ट्रस्ट बाउंड्री कहाँ है, क्योंकि इसके द्वारा लौटाया गया सारा डेटा किसी अनजान व्यक्ति द्वारा लिखा गया टेक्स्ट होता है।

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

अपना मॉडल स्वयं लाएं

OpenClaw मॉडल-अज्ञेयवादी (model-agnostic) है। यह अपना स्वयं का भाषा मॉडल साथ नहीं लाता है। इसके बजाय, यह आपके द्वारा चुने गए मॉडल से जुड़ता है, जो एक होस्टेड API हो सकता है या ऐसा मॉडल जिसे आप स्वयं चलाते हैं।

यह विभाजन लागत, गोपनीयता और नियंत्रण के लिए महत्वपूर्ण है। एक होस्टेड API आपको बिना किसी हार्डवेयर प्रबंधन के सबसे शक्तिशाली मॉडल देता है, जिसका भुगतान प्रति-टोकन (per-token) आधार पर होता है और इसमें आपके प्रॉम्प्ट्स आपके सर्वर से बाहर जाते हैं। एक सेल्फ-होस्टेड मॉडल, जिसे Ollama जैसे किसी टूल के साथ सर्व किया जाता है, हर संदेश को आपके अपने बॉक्स पर रखता है और इसकी लागत केवल हार्डवेयर और बिजली तक सीमित रहती है, जिसकी कीमत एक छोटे या धीमे मॉडल को चलाने के रूप में चुकानी पड़ती है। कई लोग इन दोनों का मिश्रण उपयोग करते हैं। यदि आप किसी एजेंट को पूरी तरह से निजी रखना चाहते हैं, तो अपने VPS पर मॉडल को सेल्फ-होस्ट करना वह कदम है जो उस अंतिम अंतर को समाप्त करता है, और Hermes Agent एक अन्य सेल्फ-होस्टेड एजेंट है जिसकी तुलना करना सार्थक है।

क्या आपको इसे बनाना चाहिए?

आप यह सब बना सकते हैं। इसके घटक असाधारण नहीं हैं: एक daemon, कुछ chat connectors, एक model-and-tools loop, Markdown का एक फोल्डर, और एक plugin format। इन्हें समझना वास्तव में उपयोगी है, क्योंकि यह आपके द्वारा उपयोग किए जाने वाले हर agent के रहस्य को खोल देता है और आपको ठीक-ठीक बताता है कि खतरा कहाँ छिपा है।

लेकिन अधिकांश लोगों के लिए ईमानदार उत्तर यही है कि इसे फिर से बनाने के बजाय वास्तविक चीज़ चलाएँ और उसे harden करें। OpenClaw ने connectors, loop और skill format की समस्याएँ पहले ही हल कर दी हैं, और इसकी वास्तविक security scrutiny भी हो चुकी है। अपना प्रयास उस हिस्से पर लगाना अधिक उपयोगी है जिसे सही तरीके से configure करना आपके जिम्मे है: अपने server पर setup और hardening। यदि आप पहले सीखने का मार्ग अपनाना चाहते हैं, तो concepts को चरणबद्ध तरीके से समझना agent source code को बिना संदर्भ सीधे पढ़ने से बेहतर है, क्योंकि हर चरण के अंत में आपके पास वास्तव में बनाया हुआ एक component होता है। सीखने के लिए एक छोटा agent बनाएँ। उपयोग के लिए वास्तविक agent चलाएँ और उसे lock down करें।

सामान्य आधार VPS पर अपना AI agent बनाना में दिए गए हैं, और Claude के साथ एक agent बनाना उसी विचार को एक विशिष्ट model को मस्तिष्क के रूप में उपयोग करके दिखाता है।

FAQ

क्या OpenClaw जैसा agent बनाना कठिन है?

इसके व्यक्तिगत हिस्से कठिन नहीं हैं। एक gateway process, एक chat connector, एक model-and-tools loop, और फाइलों का एक फोल्डर, ये सभी अपने आप में सरल हैं। कठिन हिस्सा इसे सुरक्षित रूप से बनाना है। जो agent chat messages से shell commands चलाता है, वह सुरक्षा के लिए एक गंभीर खतरा है। sandboxing, permissions और unprivileged-user setup को सही ढंग से व्यवस्थित करना, फीचर्स को आपस में जोड़ने से कहीं अधिक मेहनत का काम है।

OpenClaw memory को database के बजाय Markdown फाइलों के रूप में क्यों स्टोर करता है?

क्योंकि एक single-user personal agent के लिए फाइलें पर्याप्त और बहुत सरल हैं। इसमें चलाने के लिए कोई database service नहीं होती, memory को पढ़ना और हाथ से ठीक करना आसान है, और agent को किसी दूसरे सर्वर पर ले जाने का मतलब केवल एक directory को copy करना है। database बड़े पैमाने पर उपयोगी होता है, यहाँ नहीं।

personal AI agent का सबसे खतरनाक हिस्सा क्या है?

वे tools जो इसे कार्य करने की अनुमति देते हैं: shell commands चलाना, browser को नियंत्रित करना और फाइलें लिखना। यही वे कारण हैं जिनके लिए इसे बनाया जाता है और यही वे कारण हैं जिनसे यह आपको नुकसान पहुँचा सकता है। OpenClaw की March 2026 की सुरक्षा घटना, जिसमें चार दिनों में नौ समस्याएं सामने आईं, जिनमें एक 9.9-rated critical समस्या भी शामिल थी, इस बात का सबसे स्पष्ट प्रमाण है कि tool layer को सावधानी से संभालना चाहिए: इसे unprivileged user के रूप में चलाएं, विनाशकारी कार्यों को नियंत्रित करें और execution को sandbox करें।

क्या इसे बनाने के लिए मुझे अपने स्वयं के language model की आवश्यकता है?

नहीं। OpenClaw जैसे agents model-agnostic होते हैं, इसलिए आप अपनी पसंद का model जोड़ सकते हैं। यह सबसे शक्तिशाली models के लिए एक hosted API हो सकता है, या पूर्ण गोपनीयता के लिए आपके द्वारा स्वयं चलाया जाने वाला model हो सकता है। Ollama के साथ self-hosting करने से हर message आपके अपने सर्वर पर रहता है, लेकिन इसके लिए आपको एक छोटा model चलाना पड़ता है।