आप अपने टर्मिनल, कोड या एआई एजेंट से क्विकनोड को मैनेज कर सकते हैं।अब CLI, एडमिन API, MCP और SDK के साथ।
निर्माण शुरू करेंएसओसी 2 टाइप II प्रमाणित · आईएसओ 27001
ERC-8257 क्या है? एजेंट टूल रजिस्ट्री की व्याख्या
ERC-8257 क्या है? एथेरियम एजेंट टूल रजिस्ट्री, टूल डिस्कवरी, प्रेडिकेट्स, एजेंट मार्केटप्लेस और एआई इंफ्रास्ट्रक्चर के लिए एक गाइड।

22 जून, 2026 — पढ़ने में 8 मिनट लगेंगे

एआई एजेंट कोड जनरेट कर सकते हैं, वर्कफ़्लो को निष्पादित कर सकते हैं और बाहरी सेवाओं के साथ इंटरैक्ट कर सकते हैं।
नए उपकरण खोजना अभी भी बहुत कठिन है।
अधिकांश एजेंट पहले से कॉन्फ़िगर किए गए एकीकरणों पर निर्भर करते हैं, चाहे वे प्रॉम्प्ट, फ़्रेमवर्क, एपीआई या मार्केटप्लेस के माध्यम से हों। एजेंटों के लिए सुलभ सेवाओं की संख्या बढ़ने के साथ, इस दृष्टिकोण को बड़े पैमाने पर लागू करना मुश्किल हो जाता है।
ERC-8257 एजेंटिक टूल्स और सेवाओं को खोजने और सत्यापित करने का एक अनुमति-रहित तरीका प्रदान करता है।
यह ब्लॉग बताता है कि ERC-8257 क्या है, एजेंट टूल रजिस्ट्री कैसे काम करती है, यह समग्र एजेंटिक इंफ्रा स्टैक में कैसे फिट बैठती है, और यह रजिस्ट्री कौन सी क्षमताओं को अनलॉक करती है।
ERC-8257 (एजेंट टूल रजिस्ट्री) एथेरियम का एक ड्राफ्ट मानक है जो एआई एजेंटों और टूल्स के लिए एक अनुमति-रहित ऑनचेन रजिस्ट्री को परिभाषित करता है। यह एक टूल क्या है, इसे किसने प्रकाशित किया है, और इसे कौन कॉल कर सकता है, इसका एक न्यूनतम, सत्यापन योग्य रिकॉर्ड मानकीकृत करता है।
अप्रैल 2026 में, ओपनसी में कोडी सियर्स और रयान घोड्स ने एआई एजेंटों को स्वायत्त रूप से उपकरणों की खोज करने, उन तक पहुंच खरीदने और उनका उपयोग करने की अनुमति देने के लिए इस मानक का प्रस्ताव रखा।
प्रत्येक पंजीकृत टूल या ERC-8257 संगत एजेंट के पास 3 घटकों का ऑनचेन रिकॉर्ड होगा:
निर्माता का पता: प्रकाशक, पंजीकरण पर स्थायी रूप से बाध्य
मेटाडेटा यूआरआई: टूल के ऑफचेन मैनिफेस्ट का एक पॉइंटर
मैनिफेस्ट हैश: यह सत्यापित करता है कि विवरण में कोई परिवर्तन नहीं हुआ है।
और एक्सेस प्रेडिकेट में एक वैकल्पिक चौथा घटक होता है, जो एक कॉन्ट्रैक्ट एड्रेस होता है और यह तय करता है कि कौन टूल को कॉल कर सकता है।
ये सभी मिलकर टूल मेटाडेटा के लिए सत्य का एक साझा स्रोत बनाते हैं, जिसमें एक गारंटी होती है: आपके द्वारा प्राप्त किया गया मैनिफेस्ट वही है जिसे निर्माता ने अपने नियंत्रण वाले मूल स्रोत से, अपने हस्ताक्षर वाले पते के तहत कमिट किया था।
एजेंट टूल रजिस्ट्री के उद्देश्य और उसमें मौजूद घटकों को समझने के बाद, आइए जानें कि वे सभी एक साथ कैसे काम करते हैं और उनका प्रवाह कैसा होता है।
क्या आपको पता है? ERC-8257 एथेरियम मेननेट और बेस पर लाइव है और 2026 के मध्य तक इस पर 76 टूल इंडेक्स किए जा चुके हैं।
ERC-8257 के अंतर्गत दो कार्यप्रवाह हैं, अर्थात्:
रजिस्ट्री प्रवाह: प्रकाशक और रजिस्ट्री के बीच अंतःक्रिया।
खोज एवं सत्यापन प्रवाह: एजेंटों, रजिस्ट्री और उपकरणों के बीच परस्पर क्रिया।
आइए इनमें से प्रत्येक को अलग-अलग समझते हैं।
रजिस्ट्री प्रक्रिया यह नियंत्रित करती है कि कोई टूल कैसे प्रकाशित होता है और खोजने योग्य बनता है। एक प्रकाशक टूल के निर्माता का पता, मेटाडेटा यूआरआई और मैनिफेस्ट हैश (साथ ही एक वैकल्पिक एक्सेस प्रेडिकेट) पंजीकृत करता है, जिससे ऑनचेन रिकॉर्ड बनता है जिसे एजेंट बाद में हल और सत्यापित कर सकते हैं।
जब कोई एजेंट किसी टूल या सेवा को ढूंढता है, तो यह खोज और सत्यापन प्रक्रिया एजेंट द्वारा पढ़े जा रहे मेटाडेटा में विश्वास स्थापित करती है।
रजिस्ट्री की भूमिका तब समाप्त हो जाती है जब एजेंट यह सत्यापित कर लेता है कि मैनिफेस्ट, प्रकाशक और पहुंच संबंधी आवश्यकताएं पंजीकृत रिकॉर्ड से मेल खाती हैं।
अब तक, ERC-8257 एक सामान्य रजिस्ट्री की तरह प्रतीत होता है, लेकिन वैकल्पिक प्रेडिकेट अनुभाग ही वह जगह है जहां ERC-8257 एक रजिस्ट्री से कहीं अधिक बन जाता है।
एजेंट टूल रजिस्ट्री खोज और सत्यापन की समस्या का समाधान करती है। लेकिन, यह आवश्यक नहीं है कि हर टूल हर एजेंट द्वारा उपयोग किया जा सके या पूरी तरह से सार्वजनिक हो।
कुछ सेवाओं के लिए सदस्यता की आवश्यकता हो सकती है। अन्य सेवाएं एनएफटी धारकों, उद्यम ग्राहकों या विशिष्ट प्रतिष्ठा आवश्यकताओं को पूरा करने वाले एजेंटों तक ही सीमित हो सकती हैं।
ERC-8257 एक वैकल्पिक घटक के साथ एक्सेस की समस्या का समाधान करता है जिसे एक्सेस प्रेडिकेट कहा जाता है: एक बाहरी अनुबंध जो यह तय करता है कि कोई कॉलर किसी टूल का उपयोग कर सकता है या नहीं।
एक्सेस प्रेडिकेट एक अनुबंध पता है जो टूल पंजीकरण से जुड़ा होता है।
जब कोई एजेंट किसी टूल का उपयोग करने का प्रयास करता है, तो वह प्रेडिकेट कॉन्ट्रैक्ट को कॉल कर सकता है और एक सरल प्रश्न पूछ सकता है: क्या इस कॉलर को इस टूल तक पहुंचने की अनुमति है?
अब, प्रेडिकेट कॉन्ट्रैक्ट यह जांच कर सकता है कि क्या कोई एजेंट एनएफटी का मालिक है, सदस्यता टोकन रखता है, पहुंच के लिए भुगतान किया है, अनुमति सूची से संबंधित है, या प्रतिष्ठा की आवश्यकता को पूरा करता है।
रजिस्ट्री में बदलाव किए बिना ही विभिन्न टूल अलग-अलग नीतियां लागू कर सकते हैं। यहां कुछ उदाहरण दिए गए हैं:
उपकरण प्रकार | विधेय तर्क |
|---|---|
सार्वजनिक एपीआई | हमेशा true लौटाएँ |
प्रीमियम अनुसंधान उपकरण | सक्रिय सदस्यता सत्यापित करें |
उद्यम सेवा | अनुमति सूची सदस्यता की जाँच करें |
एनएफटी-गेटेड टूल | एनएफटी के स्वामित्व का सत्यापन करें |
एजेंट बाज़ार | भुगतान या प्रतिष्ठा संबंधी आवश्यकताओं की जाँच करें |
सबसे महत्वपूर्ण बात यह है कि ERC-8257 इनमें से किसी भी नियम को हार्डकोड नहीं करता है, यह प्रेडिकेट कॉन्ट्रैक्ट को एक वैकल्पिक ऐड-ऑन होने देता है, जिससे मानक हल्का रहता है और साथ ही इसे कई उपयोग मामलों के लिए विस्तार योग्य भी रखता है।
अब हम जानते हैं कि एजेंट टूल रजिस्ट्री क्या है, यह कैसे पंजीकृत होती है, एजेंट इसे कैसे खोजते हैं और इसकी पहुँच को कैसे नियंत्रित किया जाता है। अब, आप इससे क्या बना सकते हैं?
एक रजिस्ट्री अपने आप में कोई खास दिलचस्प चीज नहीं है।
DNS का महत्व इसलिए बढ़ा क्योंकि इसके माध्यम से वेबसाइटों का पता लगाया जा सकता था। पैकेज रजिस्ट्री का महत्व इसलिए बढ़ा क्योंकि सॉफ्टवेयर उन पर निर्भर हो सकते थे। ऐप स्टोर का महत्व इसलिए बढ़ा क्योंकि वे उपयोगकर्ताओं को एप्लिकेशन से जोड़ते थे।
ERC-8257 एजेंट-पहुँच योग्य टूल के लिए एक डिस्कवरी लेयर बनाता है। आइए, इसके कारण अनलॉक हुई कई क्षमताओं का पता लगाएं:
प्रत्येक टूल की उत्पत्ति सत्यापित की जा सकती है, उस तक पहुंच को प्रोग्राम किया जा सकता है और उसमें ऑनचेन मूल्य निर्धारण संबंधी संकेत मौजूद होते हैं। यह एक ऐसा बाज़ार बनाने के लिए पर्याप्त है जहां प्लेटफॉर्म ऑपरेटर की मध्यस्थता के बिना ही टूल खोजे, उपयोग किए और बेचे जा सकें।
एक टूल प्रदाता प्रेडिकेट अनुबंध के माध्यम से मूल्य निर्धारण, सदस्यता, टोकन स्वामित्व आवश्यकताएं, प्रतिष्ठा सीमाएं या उद्यम अनुमतियां परिभाषित कर सकता है। यह लचीलापन विभिन्न एक्सेस मॉडलों को प्रतिस्पर्धा करने की अनुमति देता है, साथ ही खोज स्तर पर उनकी परस्पर संचालन क्षमता को भी बनाए रखता है।
ERC-8257 के साथ अब मल्टी-स्टेप एजेंट पाइपलाइन बनाना संभव है, जिसमें प्रत्येक टूल को स्वतंत्र रूप से सत्यापित और नियंत्रित किया जाता है।
उदाहरण के लिए, एक ट्रेडिंग एजेंट को 24/7 न्यूज़ स्क्रैपर टूल से जोड़ा जा सकता है या एक प्रेडिक्शन मार्केट एजेंट को ट्विटर (X) एजेंट से जोड़ा जा सकता है।
ERC-8257 उन निर्भरताओं को खोजने और सत्यापित करने का एक मानक तरीका प्रदान करता है, जिससे स्वतंत्र प्रदाताओं में मल्टी-एजेंट वर्कफ़्लो को संयोजित करना आसान हो जाता है।
अंततः हर प्लेटफॉर्म को एक ही चुनौती का सामना करना पड़ता है: अपनी सेवाओं की निर्देशिका को बनाए रखना।
ERC-8257 इस ज़िम्मेदारी को साझा बुनियादी ढांचे में स्थानांतरित करता है। टूल प्रदाता एक बार प्रकाशित करते हैं। एजेंट फ्रेमवर्क, वॉलेट, मार्केटप्लेस और एप्लिकेशन समान रिकॉर्ड का उपयोग करते हैं।
आज अधिकांश एजेंट वर्कफ़्लो एक ही संगठन या प्लेटफ़ॉर्म के भीतर संचालित होते हैं।
ERC-8257 विक्रेता-ग्राहक, ग्राहक-बाजार और अन्य जैसे अंतर-संगठनात्मक कार्यप्रवाहों के लिए मार्ग प्रशस्त करता है।
उदाहरण के लिए, एक शोध एजेंट पंजीकृत उपकरणों के माध्यम से उजागर किए गए मालिकाना डेटा फीड तक पहुंच खरीद सकता है।
ERC-8257 की कार्यप्रणाली और क्षमताओं को अब समझ लिया गया है। अगला चरण एजेंटों को वास्तव में काम करने में मदद करने के लिए आवश्यक व्यापक एजेंट स्टैक को समझना है।
ERC-8257 व्यापक एजेंट स्टैक के भीतर एक विशिष्ट समस्या का समाधान करता है: क्षमता की खोज और सत्यापन योग्य अंतःक्रिया।
लेकिन, एजेंटों को अभी भी आपस में बातचीत करने के लिए पहचान, निष्पादन वातावरण, भुगतान प्रणाली और समन्वय की आवश्यकता होती है।
चलिए अब स्टैक को एक साथ जोड़ते हैं।
परत | सवाल | शिष्टाचार |
|---|---|---|
एजेंट पहचान | एजेंट कौन है? | ERC-8004 पहचान या वॉलेट |
खोज | कौन-कौन सी क्षमताएं मौजूद हैं? | ईआरसी-8257 |
अभिगम नियंत्रण | इनका उपयोग कौन कर सकता है? | ईआरसी-8257 विधेय |
इस नजरिए से देखने पर, ERC-8257 एक AI मानक की बजाय एक बुनियादी ढांचे की तरह अधिक प्रतीत होता है।
एक पंजीकृत टूल एमसीपी सर्वर को उजागर कर सकता है।
किसी शर्त के तहत पहुँच प्रदान करने से पहले भुगतान की आवश्यकता हो सकती है।
अनुरोध करने वाले व्यक्ति को साबित करने के लिए एजेंट पहचान मानक का उपयोग किया जा सकता है।
इनमें से कोई भी जिम्मेदारी स्वयं ERC-8257 की नहीं है।
इस मानक का उद्देश्य एक सरल प्रश्न का उत्तर देना है: "कौन सी क्षमताएं उपलब्ध हैं और उन्हें कहां पाया जा सकता है?"
अब, संरचना सुदृढ़ है और डिजाइन का चुनाव भी सही है। सवाल सिर्फ इसे अपनाने को लेकर है।
आजकल अधिकांश सॉफ्टवेयर प्रत्यक्ष एकीकरण के आधार पर निर्मित होते हैं।
एक डेवलपर किसी सेवा का चयन करता है, उसके दस्तावेज़ पढ़ता है, उसके एपीआई के अनुसार कोड लिखता है और समय के साथ उस संबंध को बनाए रखता है।
ERC-8257 इसे आगे नहीं बढ़ाता बल्कि एजेंटिक इन्फ्रास्ट्रक्चर को एक अलग दिशा में धकेल देता है।
रनटाइम पर क्षमताओं का पता लगाया जा सकता है।
पहुँच नीतियाँ प्रोग्राम करने योग्य हो जाती हैं।
मानवीय अनुमति के बिना भी सेवाओं का उपयोग किया जा सकता है।
ERC-8257 एक सामान्य डिस्कवरी लेयर है। यह देखने में बुनियादी ढांचे का एक छोटा सा हिस्सा लग सकता है।
DNS एक छोटा सा ढांचा था। पैकेज रजिस्ट्री भी एक छोटा सा ढांचा था। ऐप स्टोर की शुरुआत डायरेक्टरी के रूप में हुई थी।
आगे और भी कठिन चुनौती है।
एजेंटों को प्रतिष्ठा का मूल्यांकन कैसे करना चाहिए? बाज़ारों को उपकरणों की रैंकिंग कैसे करनी चाहिए? स्वायत्त प्रणालियों के बीच भुगतान, सदस्यता या राजस्व साझाकरण को नियंत्रित करने वाले मानक क्या होने चाहिए? संगठनों को सुरक्षा से समझौता किए बिना आंतरिक क्षमताओं को कैसे प्रदर्शित करना चाहिए?
ERC-8257 सवालों के जवाब नहीं देता। यह संवाद और समाधान की प्रक्रिया शुरू करता है।
एक प्रदाता निर्माता का पता, मेटाडेटा यूआरआई, मैनिफेस्ट हैश और वैकल्पिक एक्सेस प्रेडिकेट प्रकाशित करके एक टूल को पंजीकृत करता है। एजेंट मैनिफेस्ट को प्राप्त करते हैं, ऑनचेन रिकॉर्ड के विरुद्ध उसकी पुष्टि करते हैं, एक्सेस संबंधी आवश्यकताओं का मूल्यांकन करते हैं और फिर टूल को सक्रिय करते हैं।
मैनिफेस्ट किसी टूल का मशीन-पठनीय विवरण होता है। इसमें क्षमताएं, एंडपॉइंट, उपयोग संबंधी आवश्यकताएं और अन्य जानकारी शामिल होती है, जिनकी आवश्यकता एजेंटों को सेवा को समझने और उसके साथ इंटरैक्ट करने के लिए होती है।
नहीं। किसी भी मशीन-पहुँच योग्य सेवा को ERC-8257 के माध्यम से पंजीकृत किया जा सकता है। हालाँकि यह मानक AI एजेंटों को ध्यान में रखकर बनाया गया था, लेकिन API, सॉफ़्टवेयर सेवाएँ, स्वचालन प्रणालियाँ और अन्य प्रोग्राम करने योग्य अनुप्रयोग भी इसी खोज मॉडल का उपयोग कर सकते हैं।
MCP टूल्स को प्रदर्शित करने और उपयोग करने के तरीके को मानकीकृत करता है। ERC-8257 टूल्स की खोज और सत्यापन के तरीके को मानकीकृत करता है। ये दोनों एक दूसरे के पूरक हैं और एक ही एजेंट आर्किटेक्चर के भीतर एक साथ उपयोग किए जा सकते हैं।
डेवलपर्स एक साझा रजिस्ट्री मानक के आधार पर एजेंट मार्केटप्लेस, प्रोग्रामेबल एक्सेस सिस्टम, क्रॉस-ऑर्गेनाइजेशनल एजेंट वर्कफ़्लो, सर्विस डिस्कवरी लेयर्स और मल्टी-एजेंट इकोसिस्टम का निर्माण कर सकते हैं।
हाँ। टूल रजिस्ट्री अनुबंध यहाँ तैनात है: 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 एथेरियम मेननेट और बेस पर। 2026 के मध्य तक, 76 टूल इंडेक्स किए जा चुके हैं। EIP अभी भी ड्राफ्ट स्थिति में है, जिसका अर्थ है कि अंतिम रूप दिए जाने से पहले इंटरफ़ेस में बदलाव हो सकते हैं।
नहीं। रजिस्ट्री में मेटाडेटा के संदर्भ संग्रहीत होते हैं, न कि स्वयं मेटाडेटा। टूल विवरण ऑफचेन रहते हैं, जबकि ऑनचेन संग्रहीत हैश एजेंटों को उनकी अखंडता सत्यापित करने की अनुमति देते हैं।
2017 में स्थापित, Quicknode डेवलपर्स और उद्यमों के लिए संस्थागत स्तर का ब्लॉकचेन इंफ्रास्ट्रक्चर उपलब्ध कराता है। 99.99% अपटाइम और 80 से अधिक चेन के समर्थन के साथ, टीमें बिना किसी समझौते के ऑनचेन एप्लिकेशन बनाती और उनका विस्तार करती हैं।
नवीनतम इंजीनियरिंग संबंधी जानकारियां, उत्पाद अपडेट और वेब3 समाचार सीधे आपके इनबॉक्स में पहुंचाए जाएंगे।
भुगतान
इस सुविधा का भुगतान कैसे किया जाता है? |
x402, स्टेबलकॉइन्स |
कार्यान्वयन | टूल्स को कैसे इस्तेमाल किया जाता है? | एमसीपी, एपीआई, एजेंट फ्रेमवर्क |
समन्वय | एजेंट आपस में मिलकर कैसे काम करते हैं? | बहु-एजेंट प्रणालियाँ |