Plugin maintainer reference

Plugin की आंतरिक संरचना

यह OpenClaw Plugin सिस्टम का गहन आर्किटेक्चर संदर्भ है। व्यावहारिक मार्गदर्शिकाओं के लिए, नीचे दिए गए केंद्रित पृष्ठों में से किसी एक से शुरुआत करें।

Plugin इंस्टॉल करें और उपयोग करें

Plugin जोड़ने, सक्षम करने और उनकी समस्याओं का निवारण करने के लिए अंतिम-उपयोगकर्ता मार्गदर्शिका।

Plugin बनाना

सबसे छोटे कार्यशील मैनिफ़ेस्ट के साथ पहला Plugin बनाने का ट्यूटोरियल।

चैनल Plugin

मैसेजिंग चैनल Plugin बनाएँ।

प्रोवाइडर Plugin

मॉडल प्रोवाइडर Plugin बनाएँ।

SDK अवलोकन

इम्पोर्ट मैप और पंजीकरण API संदर्भ।

सार्वजनिक क्षमता मॉडल

क्षमताएँ OpenClaw के भीतर सार्वजनिक नेटिव Plugin मॉडल हैं। प्रत्येक नेटिव OpenClaw Plugin एक या अधिक क्षमता प्रकारों के लिए पंजीकरण करता है:

क्षमता	पंजीकरण विधि	उदाहरण Plugin
टेक्स्ट अनुमान	`api.registerProvider(...)`	`anthropic`, `openai`
CLI अनुमान बैकएंड	`api.registerCliBackend(...)`	`anthropic`, `openai`
एम्बेडिंग	`api.registerEmbeddingProvider(...)`	प्रोवाइडर-स्वामित्व वाले वेक्टर Plugin
वाक्	`api.registerSpeechProvider(...)`	`elevenlabs`, `microsoft`
रीयलटाइम ट्रांसक्रिप्शन	`api.registerRealtimeTranscriptionProvider(...)`	`openai`
रीयलटाइम वॉइस	`api.registerRealtimeVoiceProvider(...)`	`google`, `openai`
मीडिया समझ	`api.registerMediaUnderstandingProvider(...)`	`google`, `openai`
ट्रांसक्रिप्ट स्रोत	`api.registerTranscriptSourceProvider(...)`	`discord`, `google-meet`, `teams-meetings`, `zoom-meetings`
इमेज जनरेशन	`api.registerImageGenerationProvider(...)`	`fal`, `google`, `openai`
संगीत जनरेशन	`api.registerMusicGenerationProvider(...)`	`fal`, `google`, `minimax`
वीडियो जनरेशन	`api.registerVideoGenerationProvider(...)`	`fal`, `google`, `qwen`
वेब फ़ेच	`api.registerWebFetchProvider(...)`	`firecrawl`
वेब खोज	`api.registerWebSearchProvider(...)`	`brave`, `firecrawl`, `google`
चैनल / मैसेजिंग	`api.registerChannel(...)`	`matrix`, `msteams`
Gateway खोज	`api.registerGatewayDiscoveryService(...)`	`bonjour`

बाहरी संगतता रुख

क्षमता मॉडल कोर में उपलब्ध है और आज बंडल किए गए/नेटिव Plugin इसका उपयोग करते हैं, लेकिन बाहरी Plugin की संगतता के लिए अब भी "यह एक्सपोर्ट किया गया है, इसलिए स्थिर है" से अधिक कठोर मानदंड आवश्यक है।

Plugin की स्थिति	मार्गदर्शन
मौजूदा बाहरी Plugin	हुक-आधारित इंटीग्रेशन को कार्यशील रखें; यही संगतता की आधाररेखा है।
नए बंडल किए गए/नेटिव Plugin	वेंडर-विशिष्ट आंतरिक पहुँच या नए केवल-हुक डिज़ाइन के बजाय स्पष्ट क्षमता पंजीकरण को प्राथमिकता दें।
क्षमता पंजीकरण अपनाने वाले बाहरी Plugin	इसकी अनुमति है, लेकिन जब तक दस्तावेज़ उन्हें स्थिर न बताएँ, क्षमता-विशिष्ट सहायक सतहों को विकसित होती हुई मानें।

क्षमता पंजीकरण अभिप्रेत दिशा है। संक्रमण के दौरान बाहरी Plugin के लिए लेगेसी हुक बिना टूट-फूट वाला सबसे सुरक्षित मार्ग बने हुए हैं। सभी एक्सपोर्ट किए गए सहायक सबपाथ समान नहीं हैं — आकस्मिक सहायक एक्सपोर्ट के बजाय सीमित, दस्तावेज़ीकृत अनुबंधों को प्राथमिकता दें।

Plugin के स्वरूप

OpenClaw प्रत्येक लोड किए गए Plugin को उसके वास्तविक पंजीकरण व्यवहार के आधार पर एक स्वरूप में वर्गीकृत करता है (केवल स्थिर मेटाडेटा के आधार पर नहीं):

plain-capability

ठीक एक क्षमता प्रकार पंजीकृत करता है (उदाहरण के लिए केवल-प्रोवाइडर Plugin, जैसे arcee या chutes)।

hybrid-capability

कई क्षमता प्रकार पंजीकृत करता है (उदाहरण के लिए openai टेक्स्ट अनुमान, वाक्, मीडिया समझ और इमेज जनरेशन का स्वामी है)।

hook-only

केवल हुक (टाइप किए गए या कस्टम) पंजीकृत करता है; कोई क्षमता, टूल, कमांड या सेवा नहीं।

non-capability

टूल, कमांड, सेवाएँ या रूट पंजीकृत करता है, लेकिन कोई क्षमता नहीं।

किसी Plugin का स्वरूप और क्षमता विवरण देखने के लिए openclaw plugins inspect <id> का उपयोग करें। विवरण के लिए CLI संदर्भ देखें।

संगतता संकेत

openclaw doctor, openclaw plugins inspect <id>, openclaw status --all, और openclaw plugins doctor ये संगतता सूचनाएँ दिखाते हैं:

संकेत	अर्थ
कॉन्फ़िग मान्य	कॉन्फ़िग सही ढंग से पार्स होता है और Plugin रिज़ॉल्व हो जाते हैं
केवल-हुक (जानकारी)	Plugin केवल हुक पंजीकृत करता है; यह समर्थित मार्ग है, लेकिन इसे अभी क्षमता पंजीकरण पर माइग्रेट नहीं किया गया है
बहिष्कृत मेमोरी-एम्बेडिंग API (चेतावनी)	गैर-बंडल Plugin `registerEmbeddingProvider` के बजाय पुराने मेमोरी-विशिष्ट एम्बेडिंग प्रोवाइडर API का उपयोग करता है
गंभीर त्रुटि	कॉन्फ़िग अमान्य है या Plugin लोड नहीं हो सका

परामर्श/चेतावनी के इनमें से कोई भी संकेत आज आपके Plugin को नहीं तोड़ता। ये संकेत openclaw status --all और openclaw plugins doctor में भी दिखाई देते हैं।

आर्किटेक्चर अवलोकन

OpenClaw के Plugin सिस्टम में चार परतें हैं:

मैनिफ़ेस्ट + खोज

OpenClaw कॉन्फ़िगर किए गए पाथ, वर्कस्पेस रूट, ग्लोबल Plugin रूट और बंडल किए गए Plugin में संभावित Plugin खोजता है। खोज पहले नेटिव openclaw.plugin.json मैनिफ़ेस्ट और समर्थित बंडल मैनिफ़ेस्ट पढ़ती है।

सक्षमता + सत्यापन

कोर तय करता है कि खोजा गया Plugin सक्षम, अक्षम, अवरुद्ध है या मेमोरी जैसे किसी विशिष्ट स्लॉट के लिए चुना गया है।

रनटाइम लोडिंग

नेटिव OpenClaw Plugin प्रोसेस के भीतर लोड होते हैं और क्षमताओं को एक केंद्रीय रजिस्ट्री में पंजीकृत करते हैं। पैकेज किया गया JavaScript नेटिव require के माध्यम से लोड होता है; तृतीय-पक्ष स्थानीय स्रोत TypeScript के लिए आपातकालीन फ़ॉलबैक Jiti है। संगत बंडलों को रनटाइम कोड इम्पोर्ट किए बिना रजिस्ट्री रिकॉर्ड में सामान्यीकृत किया जाता है।

सतह का उपयोग

OpenClaw के शेष भाग टूल, चैनल, प्रोवाइडर सेटअप, हुक, HTTP रूट, CLI कमांड और सेवाएँ उपलब्ध कराने के लिए रजिस्ट्री पढ़ते हैं।

विशेष रूप से Plugin CLI के लिए, रूट कमांड खोज दो चरणों में विभाजित है:

पार्स-समय मेटाडेटा registerCli(..., { descriptors: [...] }) से आता है
वास्तविक Plugin CLI मॉड्यूल लेज़ी रह सकता है और पहली बार आह्वान किए जाने पर पंजीकृत हो सकता है

इससे Plugin-स्वामित्व वाला CLI कोड Plugin के भीतर रहता है, जबकि OpenClaw पार्सिंग से पहले भी रूट कमांड नाम आरक्षित कर सकता है।

महत्वपूर्ण डिज़ाइन सीमा:

मैनिफ़ेस्ट/कॉन्फ़िग सत्यापन को Plugin कोड निष्पादित किए बिना मैनिफ़ेस्ट/स्कीमा मेटाडेटा से काम करना चाहिए
नेटिव क्षमता खोज एक गैर-सक्रिय रजिस्ट्री स्नैपशॉट बनाने के लिए विश्वसनीय Plugin एंट्री कोड लोड कर सकती है
नेटिव रनटाइम व्यवहार Plugin मॉड्यूल के register(api) पाथ से api.registrationMode === "full" के साथ आता है

यह विभाजन पूर्ण रनटाइम सक्रिय होने से पहले OpenClaw को कॉन्फ़िग सत्यापित करने, अनुपलब्ध/अक्षम Plugin की व्याख्या करने और UI/स्कीमा संकेत बनाने देता है।

Plugin मेटाडेटा स्नैपशॉट और लुकअप तालिका

Gateway स्टार्टअप वर्तमान कॉन्फ़िग स्नैपशॉट के लिए एक PluginMetadataSnapshot बनाता है। स्नैपशॉट केवल मेटाडेटा है: यह इंस्टॉल किए गए Plugin इंडेक्स, मैनिफ़ेस्ट रजिस्ट्री, मैनिफ़ेस्ट डायग्नोस्टिक्स, स्वामी मैप, Plugin ID नॉर्मलाइज़र और मैनिफ़ेस्ट रिकॉर्ड संग्रहीत करता है। इसमें लोड किए गए Plugin मॉड्यूल, प्रोवाइडर SDK, पैकेज सामग्री या रनटाइम एक्सपोर्ट नहीं होते।

Plugin-सजग कॉन्फ़िग सत्यापन, स्टार्टअप ऑटो-सक्षमता और Gateway Plugin बूटस्ट्रैप मैनिफ़ेस्ट/इंडेक्स मेटाडेटा को स्वतंत्र रूप से दोबारा बनाने के बजाय उस स्नैपशॉट का उपयोग करते हैं। PluginLookUpTable उसी स्नैपशॉट से व्युत्पन्न होता है और वर्तमान रनटाइम कॉन्फ़िग के लिए स्टार्टअप Plugin योजना जोड़ता है।

स्टार्टअप के बाद, Gateway वर्तमान मेटाडेटा स्नैपशॉट को बदले जा सकने वाले रनटाइम उत्पाद के रूप में रखता है। बार-बार होने वाली रनटाइम प्रोवाइडर खोज प्रत्येक प्रोवाइडर-कैटलॉग पास के लिए इंस्टॉल किया गया इंडेक्स और मैनिफ़ेस्ट रजिस्ट्री फिर से बनाने के बजाय उस स्नैपशॉट का उपयोग कर सकती है। Gateway शटडाउन, कॉन्फ़िग/Plugin इन्वेंटरी में बदलाव और इंस्टॉल किए गए इंडेक्स में लेखन होने पर स्नैपशॉट साफ़ या प्रतिस्थापित किया जाता है; जब कोई संगत वर्तमान स्नैपशॉट मौजूद नहीं होता, तो कॉलर कोल्ड मैनिफ़ेस्ट/इंडेक्स पाथ का उपयोग करते हैं। संगतता जाँच में plugins.load.paths और डिफ़ॉल्ट एजेंट वर्कस्पेस जैसे Plugin खोज रूट शामिल होने चाहिए, क्योंकि वर्कस्पेस Plugin मेटाडेटा के दायरे का हिस्सा हैं।

स्नैपशॉट और लुकअप तालिका बार-बार होने वाले स्टार्टअप निर्णयों को तेज़ पाथ पर रखते हैं:

चैनल स्वामित्व
स्थगित चैनल स्टार्टअप
स्टार्टअप Plugin ID
प्रोवाइडर और CLI बैकएंड स्वामित्व
सेटअप प्रोवाइडर, कमांड उपनाम, मॉडल कैटलॉग प्रोवाइडर और मैनिफ़ेस्ट अनुबंध स्वामित्व
Plugin कॉन्फ़िग स्कीमा और चैनल कॉन्फ़िग स्कीमा सत्यापन
स्टार्टअप ऑटो-सक्षमता निर्णय

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

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

कुछ कोल्ड-पाथ कॉलर अभी भी Gateway PluginLookUpTable प्राप्त करने के बजाय स्थायी रूप से सहेजे गए इंस्टॉल किए गए Plugin इंडेक्स से सीधे मैनिफ़ेस्ट रजिस्ट्री का पुनर्निर्माण करते हैं। वह पाथ अब माँग पर रजिस्ट्री का पुनर्निर्माण करता है; जब किसी कॉलर के पास वर्तमान लुकअप तालिका या स्पष्ट मैनिफ़ेस्ट रजिस्ट्री पहले से हो, तो रनटाइम प्रवाहों के माध्यम से उसे पास करना बेहतर है।

सक्रियण योजना

सक्रियण योजना नियंत्रण तल का हिस्सा है। व्यापक रनटाइम रजिस्ट्री लोड करने से पहले कॉलर पूछ सकते हैं कि किसी ठोस कमांड, प्रोवाइडर, चैनल, रूट, एजेंट हार्नेस या क्षमता के लिए कौन-से Plugin प्रासंगिक हैं।

प्लानर वर्तमान मैनिफ़ेस्ट व्यवहार को संगत रखता है:

activation.* फ़ील्ड स्पष्ट प्लानर संकेत हैं
providers, channels, commandAliases, setup.providers, contracts.tools, और हुक मैनिफ़ेस्ट स्वामित्व फ़ॉलबैक बने रहते हैं
केवल आईडी वाली प्लानर API मौजूदा कॉलर के लिए उपलब्ध रहती है
प्लान API कारण लेबल रिपोर्ट करती है, ताकि निदान स्पष्ट संकेतों को स्वामित्व फ़ॉलबैक से अलग कर सके

चैनल Plugin और साझा संदेश टूल

सामान्य चैट कार्रवाइयों के लिए चैनल Plugin को अलग भेजने/संपादित करने/प्रतिक्रिया देने वाला टूल पंजीकृत करने की आवश्यकता नहीं है। OpenClaw कोर में एक साझा message टूल रखता है, और चैनल Plugin उसके पीछे चैनल-विशिष्ट खोज और निष्पादन के स्वामी होते हैं।

वर्तमान सीमा यह है:

कोर साझा message टूल होस्ट, प्रॉम्प्ट वायरिंग, सत्र/थ्रेड लेखांकन और निष्पादन डिस्पैच का स्वामी है
चैनल Plugin सीमित कार्रवाई खोज, क्षमता खोज और किसी भी चैनल-विशिष्ट स्कीमा खंड के स्वामी हैं
चैनल Plugin प्रोवाइडर-विशिष्ट सत्र वार्तालाप व्याकरण के स्वामी हैं, जैसे वार्तालाप आईडी किस प्रकार थ्रेड आईडी को एन्कोड करती हैं या मूल वार्तालापों से विरासत में लेती हैं
चैनल Plugin अपने कार्रवाई अडैप्टर के माध्यम से अंतिम कार्रवाई निष्पादित करते हैं

चैनल Plugin के लिए SDK सतह ChannelMessageActionAdapter.describeMessageTool(...) है। यह एकीकृत खोज कॉल किसी Plugin को उसकी दृश्यमान कार्रवाइयाँ, क्षमताएँ और स्कीमा योगदान एक साथ लौटाने देती है, ताकि ये हिस्से एक-दूसरे से अलग न हों।

संदेश कार्रवाई नाम जानबूझकर बंद, कोर-स्वामित्व वाली शब्दावली का उपयोग करते हैं, ताकि प्रत्येक ट्रांसपोर्ट हर कार्रवाई को रेंडर कर सके। Plugin कोर PR के माध्यम से कार्रवाई नाम जोड़ते हैं; रनटाइम पंजीकरण जानबूझकर समर्थित नहीं है।

जब कोई चैनल-विशिष्ट संदेश-टूल पैरामीटर स्थानीय पाथ या रिमोट मीडिया URL जैसे मीडिया स्रोत को वहन करता है, तो Plugin को describeMessageTool(...) से mediaSourceParams भी लौटाना चाहिए। कोर इस स्पष्ट सूची का उपयोग सैंडबॉक्स पाथ सामान्यीकरण और आउटबाउंड मीडिया-पहुँच संकेत लागू करने के लिए करता है, बिना Plugin-स्वामित्व वाले पैरामीटर नामों को हार्डकोड किए। वहाँ एक चैनल-व्यापी सपाट सूची के बजाय कार्रवाई-सीमित मैप को प्राथमिकता दें, ताकि केवल प्रोफ़ाइल वाला मीडिया पैरामीटर send जैसी असंबंधित कार्रवाइयों पर सामान्यीकृत न हो।

कोर उस खोज चरण में रनटाइम स्कोप पास करता है। महत्वपूर्ण फ़ील्ड में शामिल हैं:

accountId
currentChannelId
currentThreadTs
currentMessageId
sessionKey
sessionId
agentId
विश्वसनीय इनबाउंड requesterSenderId

यह संदर्भ-संवेदी Plugin के लिए महत्वपूर्ण है। कोई चैनल सक्रिय अकाउंट, वर्तमान रूम/थ्रेड/संदेश या विश्वसनीय अनुरोधकर्ता की पहचान के आधार पर संदेश कार्रवाइयों को छिपा या दिखा सकता है, बिना कोर message टूल में चैनल-विशिष्ट शाखाएँ हार्डकोड किए।

इसी कारण एम्बेडेड-रनर रूटिंग परिवर्तन अभी भी Plugin का कार्य हैं: रनर वर्तमान चैट/सत्र पहचान को Plugin खोज सीमा में अग्रेषित करने के लिए उत्तरदायी है, ताकि साझा message टूल वर्तमान टर्न के लिए सही चैनल-स्वामित्व वाली सतह दिखाए।

चैनल-स्वामित्व वाले निष्पादन हेल्पर के लिए, चैनल Plugin को निष्पादन रनटाइम अपने Plugin मॉड्यूल के भीतर रखना चाहिए। कोर अब src/agents/tools के अंतर्गत Discord, Slack, Telegram या WhatsApp संदेश-कार्रवाई रनटाइम का स्वामी नहीं है। हम अलग plugin-sdk/*-action-runtime सबपाथ प्रकाशित नहीं करते, और इन Plugin को अपने स्थानीय रनटाइम कोड को सीधे अपने Plugin-स्वामित्व वाले मॉड्यूल से इम्पोर्ट करना चाहिए।

यही सीमा सामान्य रूप से प्रोवाइडर-नामित SDK सीमों पर लागू होती है: कोर को Discord, Signal, Slack, WhatsApp या समान Plugin के चैनल-विशिष्ट सुविधा बैरल इम्पोर्ट नहीं करने चाहिए। यदि कोर को किसी व्यवहार की आवश्यकता है, तो या तो बंडल किए गए Plugin के अपने api.ts / runtime-api.ts बैरल का उपयोग करें या उस आवश्यकता को साझा SDK में एक सीमित सामान्य क्षमता के रूप में उन्नत करें।

बंडल किए गए Plugin भी इसी नियम का पालन करते हैं। किसी बंडल किए गए Plugin के runtime-api.ts को अपने ब्रांडेड openclaw/plugin-sdk/<plugin-id> फ़साड को पुनः एक्सपोर्ट नहीं करना चाहिए। वे ब्रांडेड फ़साड बाहरी Plugin और पुराने उपभोक्ताओं के लिए संगतता शिम बने रहते हैं, लेकिन बंडल किए गए Plugin को स्थानीय एक्सपोर्ट के साथ openclaw/plugin-sdk/channel-policy, openclaw/plugin-sdk/runtime-store, या openclaw/plugin-sdk/webhook-ingress जैसे सीमित सामान्य SDK सबपाथ का उपयोग करना चाहिए। नए कोड को Plugin-आईडी-विशिष्ट SDK फ़साड तब तक नहीं जोड़ने चाहिए, जब तक किसी मौजूदा बाहरी पारिस्थितिकी तंत्र की संगतता सीमा के लिए इसकी आवश्यकता न हो।

विशेष रूप से पोल के लिए, दो निष्पादन पाथ हैं:

outbound.sendPoll उन चैनलों के लिए साझा आधाररेखा है जो सामान्य पोल मॉडल में उपयुक्त बैठते हैं
actions.handleAction("poll") चैनल-विशिष्ट पोल अर्थ-विज्ञान या अतिरिक्त पोल पैरामीटर के लिए पसंदीदा पाथ है

कोर अब साझा पोल पार्सिंग को तब तक स्थगित करता है जब तक Plugin पोल डिस्पैच कार्रवाई को अस्वीकार न कर दे, ताकि Plugin-स्वामित्व वाले पोल हैंडलर पहले सामान्य पोल पार्सर द्वारा अवरुद्ध हुए बिना चैनल-विशिष्ट पोल फ़ील्ड स्वीकार कर सकें।

पूर्ण स्टार्टअप क्रम के लिए Plugin आर्किटेक्चर के आंतरिक भाग देखें।

क्षमता स्वामित्व मॉडल

OpenClaw किसी नेटिव Plugin को किसी कंपनी या फ़ीचर की स्वामित्व सीमा मानता है, न कि असंबंधित इंटीग्रेशन का बेतरतीब संग्रह।

इसका अर्थ है:

किसी कंपनी के Plugin को सामान्यतः उस कंपनी की सभी OpenClaw-संबंधित सतहों का स्वामी होना चाहिए
किसी फ़ीचर Plugin को सामान्यतः अपने द्वारा प्रस्तुत पूर्ण फ़ीचर सतह का स्वामी होना चाहिए
चैनलों को प्रोवाइडर व्यवहार को तदर्थ रूप से पुनः लागू करने के बजाय साझा कोर क्षमताओं का उपयोग करना चाहिए

विक्रेता की बहु-क्षमता

google टेक्स्ट इन्फ़रेंस, CLI बैकएंड, एम्बेडिंग, स्पीच, रियलटाइम वॉइस, मीडिया बोध, इमेज/संगीत/वीडियो जनरेशन और वेब खोज का स्वामी है। openai टेक्स्ट इन्फ़रेंस, एम्बेडिंग, स्पीच, रियलटाइम ट्रांसक्रिप्शन, रियलटाइम वॉइस, मीडिया बोध और इमेज/वीडियो जनरेशन का स्वामी है। minimax टेक्स्ट इन्फ़रेंस के साथ मीडिया बोध, स्पीच, इमेज/संगीत/वीडियो जनरेशन और वेब खोज का स्वामी है।

विक्रेता की एकल क्षमता

arcee और chutes केवल टेक्स्ट इन्फ़रेंस के स्वामी हैं; microsoft केवल स्पीच का स्वामी है। किसी विक्रेता का Plugin तब तक इतना सीमित रह सकता है, जब तक उसे उस विक्रेता की अधिक सतह को कवर करने की आवश्यकता न हो।

फ़ीचर Plugin

voice-call कॉल ट्रांसपोर्ट, टूल, CLI, रूट और Twilio मीडिया-स्ट्रीम ब्रिजिंग का स्वामी है, लेकिन विक्रेता Plugin को सीधे इम्पोर्ट करने के बजाय साझा स्पीच, रियलटाइम ट्रांसक्रिप्शन और रियलटाइम वॉइस क्षमताओं का उपयोग करता है।

अभिप्रेत अंतिम स्थिति यह है:

किसी विक्रेता की OpenClaw-संबंधित सतह एक Plugin में रहती है, भले ही वह टेक्स्ट मॉडल, स्पीच, इमेज और वीडियो तक फैली हो
अन्य विक्रेता अपने सतह क्षेत्र के लिए भी ऐसा कर सकते हैं
चैनलों को इससे कोई सरोकार नहीं होता कि प्रोवाइडर का स्वामी कौन-सा विक्रेता Plugin है; वे कोर द्वारा उजागर साझा क्षमता अनुबंध का उपयोग करते हैं

यह मुख्य अंतर है:

Plugin = स्वामित्व सीमा
क्षमता = कोर अनुबंध जिसे अनेक Plugin लागू या उपयोग कर सकते हैं

इसलिए यदि OpenClaw वीडियो जैसा नया डोमेन जोड़ता है, तो पहला प्रश्न यह नहीं है, "किस प्रोवाइडर को वीडियो प्रबंधन हार्डकोड करना चाहिए?" पहला प्रश्न है, "कोर वीडियो क्षमता अनुबंध क्या है?" वह अनुबंध मौजूद होने के बाद, विक्रेता Plugin उसके विरुद्ध पंजीकरण कर सकते हैं और चैनल/फ़ीचर Plugin उसका उपयोग कर सकते हैं।

यदि क्षमता अभी मौजूद नहीं है, तो सामान्यतः सही कदम यह है:

क्षमता परिभाषित करें

कोर में अनुपलब्ध क्षमता परिभाषित करें।

SDK के माध्यम से उजागर करें

इसे Plugin API/रनटाइम के माध्यम से टाइप-सुरक्षित तरीके से उजागर करें।

उपभोक्ताओं को वायर करें

चैनलों/फ़ीचर को उस क्षमता से वायर करें।

विक्रेता कार्यान्वयन

विक्रेता Plugin को कार्यान्वयन पंजीकृत करने दें।

इससे स्वामित्व स्पष्ट रहता है और ऐसे कोर व्यवहार से बचाव होता है जो किसी एक विक्रेता या एकबारगी Plugin-विशिष्ट कोड पाथ पर निर्भर हो।

क्षमता स्तरीकरण

कोड कहाँ होना चाहिए, इसका निर्णय लेते समय इस मानसिक मॉडल का उपयोग करें:

कोर क्षमता स्तर

साझा ऑर्केस्ट्रेशन, नीति, फ़ॉलबैक, कॉन्फ़िग मर्ज नियम, डिलीवरी अर्थ-विज्ञान और टाइप किए गए अनुबंध।

विक्रेता Plugin स्तर

विक्रेता-विशिष्ट API, प्रमाणीकरण, मॉडल कैटलॉग, स्पीच सिंथेसिस, इमेज जनरेशन, वीडियो बैकएंड और उपयोग एंडपॉइंट।

चैनल/फ़ीचर Plugin स्तर

Discord/Slack/वॉइस-कॉल/आदि इंटीग्रेशन, जो कोर क्षमताओं का उपयोग करता है और उन्हें किसी सतह पर प्रस्तुत करता है।

उदाहरण के लिए, TTS इस संरचना का अनुसरण करता है:

कोर उत्तर-समय TTS नीति, फ़ॉलबैक क्रम, प्राथमिकताओं और चैनल डिलीवरी का स्वामी है
elevenlabs, google, microsoft, और openai सिंथेसिस कार्यान्वयन के स्वामी हैं
voice-call टेलीफ़ोनी TTS रनटाइम हेल्पर का उपयोग करता है

भविष्य की क्षमताओं के लिए भी इसी पैटर्न को प्राथमिकता दी जानी चाहिए।

बहु-क्षमता कंपनी Plugin का उदाहरण

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

  export default definePluginEntry({  id: "exampleai",  name: "ExampleAI",  description: "ExampleAI मॉडल और मीडिया क्षमताएँ।",  register(api) {    api.registerProvider({      id: "exampleai",      // प्रमाणीकरण/मॉडल कैटलॉग/रनटाइम हुक    });     api.registerSpeechProvider({      id: "exampleai",      // विक्रेता स्पीच कॉन्फ़िग — SpeechProviderPlugin इंटरफ़ेस को सीधे लागू करें    });     api.registerMediaUnderstandingProvider({      id: "exampleai",      capabilities: ["image", "audio", "video"],      describeImage: (req) => exampleAiMedia.describeImage(req),      transcribeAudio: (req) => exampleAiMedia.transcribeAudio(req),      describeVideo: (req) => exampleAiMedia.describeVideo(req),    });     api.registerWebSearchProvider({      id: "exampleai-search",      createTool() {        // विक्रेता-स्वामित्व वाला वेब खोज टूल लौटाएँ।      },    });  },});

सटीक हेल्पर नाम महत्वपूर्ण नहीं हैं। संरचना महत्वपूर्ण है:

एक Plugin विक्रेता सतह का स्वामी होता है
कोर अब भी क्षमता अनुबंधों का स्वामी होता है
प्रोवाइडर अनुरोध रूपांतरण और HTTP हेल्पर विक्रेता Plugin में रहते हैं
चैनल और फ़ीचर Plugin विक्रेता कोड का नहीं, api.runtime.* हेल्पर का उपयोग करते हैं
अनुबंध परीक्षण यह अभिकथित कर सकते हैं कि Plugin ने उन क्षमताओं को पंजीकृत किया है जिनके स्वामित्व का वह दावा करता है

क्षमता उदाहरण: वीडियो बोध

OpenClaw पहले से इमेज/ऑडियो/वीडियो बोध को एक साझा क्षमता मानता है। वही स्वामित्व मॉडल यहाँ भी लागू होता है:

कोर अनुबंध परिभाषित करता है

कोर मीडिया-समझ अनुबंध परिभाषित करता है।

वेंडर Plugin पंजीकृत होते हैं

वेंडर Plugin उपयुक्ततानुसार describeImage, transcribeAudio, और describeVideo पंजीकृत करते हैं।

उपभोक्ता साझा व्यवहार का उपयोग करते हैं

चैनल और फ़ीचर Plugin सीधे वेंडर कोड से जुड़ने के बजाय साझा कोर व्यवहार का उपयोग करते हैं।

इससे किसी एक प्रदाता की वीडियो संबंधी धारणाएँ कोर में अंतर्निहित होने से बचती हैं। वेंडर सतह का स्वामित्व Plugin के पास होता है; क्षमता अनुबंध और फ़ॉलबैक व्यवहार का स्वामित्व कोर के पास होता है।

वीडियो जनरेशन पहले से इसी क्रम का उपयोग करता है: टाइप किए गए क्षमता अनुबंध और रनटाइम सहायक का स्वामित्व कोर के पास होता है, और वेंडर Plugin इसके लिए api.registerVideoGenerationProvider(...) कार्यान्वयन पंजीकृत करते हैं।

एक ठोस रोलआउट चेकलिस्ट चाहिए? क्षमता कुकबुक देखें।

अनुबंध और प्रवर्तन

Plugin API सतह को जानबूझकर OpenClawPluginApi में टाइप और केंद्रीकृत किया गया है। यह अनुबंध समर्थित पंजीकरण बिंदुओं और उन रनटाइम सहायकों को परिभाषित करता है जिन पर कोई Plugin निर्भर हो सकता है।

यह क्यों महत्वपूर्ण है:

Plugin लेखकों को एक स्थिर आंतरिक मानक मिलता है
कोर दो Plugin द्वारा समान प्रदाता आईडी पंजीकृत करने जैसे दोहरे स्वामित्व को अस्वीकार कर सकता है
स्टार्टअप विकृत पंजीकरण के लिए कार्रवाई योग्य निदान दिखा सकता है
अनुबंध परीक्षण बंडल किए गए Plugin के स्वामित्व को लागू कर सकते हैं और अनदेखे विचलन को रोक सकते हैं

प्रवर्तन की दो परतें हैं:

रनटाइम पंजीकरण प्रवर्तन

Plugin लोड होते समय Plugin रजिस्ट्री पंजीकरणों को सत्यापित करती है। उदाहरण: डुप्लिकेट प्रदाता आईडी, डुप्लिकेट स्पीच प्रदाता आईडी और विकृत पंजीकरण अपरिभाषित व्यवहार के बजाय Plugin निदान उत्पन्न करते हैं।

अनुबंध परीक्षण

परीक्षण चलने के दौरान बंडल किए गए Plugin को अनुबंध रजिस्ट्रियों में दर्ज किया जाता है, ताकि OpenClaw स्पष्ट रूप से स्वामित्व का सत्यापन कर सके। वर्तमान में इसका उपयोग मॉडल प्रदाताओं, स्पीच प्रदाताओं, वेब खोज प्रदाताओं और बंडल किए गए पंजीकरण के स्वामित्व के लिए किया जाता है।

व्यावहारिक प्रभाव यह है कि OpenClaw को पहले से पता होता है कि किस सतह का स्वामित्व किस Plugin के पास है। इससे कोर और चैनल सहजता से संयोजित हो सकते हैं, क्योंकि स्वामित्व अंतर्निहित होने के बजाय घोषित, टाइप किया हुआ और परीक्षण योग्य होता है।

अनुबंध में क्या होना चाहिए

अच्छे अनुबंध

टाइप किए हुए
छोटे
क्षमता-विशिष्ट
कोर के स्वामित्व वाले
कई Plugin द्वारा पुनः उपयोग योग्य
वेंडर की जानकारी के बिना चैनलों/फ़ीचर द्वारा उपयोग योग्य

खराब अनुबंध

कोर में छिपी वेंडर-विशिष्ट नीति
रजिस्ट्री को बायपास करने वाले एकबारगी Plugin निकास मार्ग
सीधे वेंडर कार्यान्वयन तक पहुँचने वाला चैनल कोड
ऐसे तदर्थ रनटाइम ऑब्जेक्ट जो OpenClawPluginApi या api.runtime का हिस्सा नहीं हैं

संदेह होने पर अमूर्तन का स्तर बढ़ाएँ: पहले क्षमता परिभाषित करें, फिर Plugin को उससे जुड़ने दें।

निष्पादन मॉडल

मूल OpenClaw Plugin, Gateway के साथ उसी प्रक्रिया में चलते हैं। वे सैंडबॉक्स में नहीं होते। लोड किए गए मूल Plugin की प्रक्रिया-स्तरीय विश्वास सीमा कोर कोड के समान होती है।

संगत बंडल डिफ़ॉल्ट रूप से अधिक सुरक्षित होते हैं, क्योंकि OpenClaw वर्तमान में उन्हें मेटाडेटा/कंटेंट पैक मानता है। वर्तमान रिलीज़ में इसका अर्थ मुख्यतः बंडल किए गए Skills हैं।

बंडल न किए गए Plugin के लिए अनुमति-सूचियों और स्पष्ट इंस्टॉल/लोड पथों का उपयोग करें। वर्कस्पेस Plugin को डेवलपमेंट-समय का कोड मानें, प्रोडक्शन डिफ़ॉल्ट नहीं।

बंडल किए गए वर्कस्पेस पैकेज नामों के लिए Plugin आईडी को npm नाम से संबद्ध रखें: डिफ़ॉल्ट रूप से @openclaw/<id>, या जब पैकेज जानबूझकर अधिक सीमित Plugin भूमिका प्रदान करता हो, तब -provider, -plugin, -speech, -sandbox, या -media-understanding जैसा स्वीकृत टाइप किया हुआ प्रत्यय।

Note

विश्वास संबंधी टिप्पणी: plugins.allow Plugin आईडी पर विश्वास करता है, स्रोत की उत्पत्ति पर नहीं। जब समान आईडी वाले किसी वर्कस्पेस Plugin को सक्षम/अनुमति-सूचीबद्ध किया जाता है, तो वह जानबूझकर बंडल की गई प्रति को ओवरराइड करता है। स्थानीय डेवलपमेंट, पैच परीक्षण और हॉटफ़िक्स के लिए यह सामान्य और उपयोगी है। बंडल किए गए Plugin का विश्वास इंस्टॉल मेटाडेटा के बजाय स्रोत स्नैपशॉट—लोड के समय डिस्क पर उपस्थित मैनिफ़ेस्ट और कोड—से निर्धारित होता है। कोई दूषित या प्रतिस्थापित इंस्टॉल रिकॉर्ड, वास्तविक स्रोत के दावों से आगे किसी बंडल किए गए Plugin की विश्वास सतह को चुपचाप विस्तृत नहीं कर सकता।

निर्यात सीमा

OpenClaw क्षमताएँ निर्यात करता है, कार्यान्वयन की सुविधाएँ नहीं।

क्षमता पंजीकरण को सार्वजनिक रखें। गैर-अनुबंध सहायक निर्यात हटाएँ:

बंडल किए गए Plugin-विशिष्ट सहायक उपपथ
सार्वजनिक API के रूप में अभिप्रेत न किए गए रनटाइम प्लंबिंग उपपथ
वेंडर-विशिष्ट सुविधा सहायक
कार्यान्वयन विवरण वाले सेटअप/ऑनबोर्डिंग सहायक

आरक्षित बंडल किए गए Plugin सहायक उपपथों को जनरेट किए गए SDK निर्यात मैप से हटा दिया गया है। स्वामी-विशिष्ट सहायकों को स्वामी Plugin पैकेज के अंदर रखें; केवल पुनः उपयोग योग्य होस्ट व्यवहार को plugin-sdk/gateway-runtime, plugin-sdk/security-runtime, और इंजेक्ट की गई Plugin API क्षमताओं जैसे सामान्य SDK अनुबंधों में उन्नत करें।

आंतरिक संरचना और संदर्भ

लोड पाइपलाइन, रजिस्ट्री मॉडल, प्रदाता रनटाइम हुक, Gateway HTTP रूट, संदेश टूल स्कीमा, चैनल लक्ष्य समाधान, प्रदाता कैटलॉग, संदर्भ इंजन Plugin और नई क्षमता जोड़ने की मार्गदर्शिका के लिए Plugin आर्किटेक्चर की आंतरिक संरचना देखें।