२,४६५ सार्वजनिकरित्या सूचीबद्ध केलेल्या AI-agent "skills" च्या ताज्या ऑडिटमध्ये असे दिसून आले आहे की, अर्ध्याहून अधिक स्किल्स प्रकाशित नियमांचे (specification) उल्लंघन करतात, आणि ७.८ टक्के स्किल्समध्ये आवश्यक मेटाडेटा नसल्यामुळे एजंट त्यांना निवडू देखील शकत नाहीत. हे दोष अशा कोणत्याही प्रणालीची विश्वासार्हता धोक्यात आणतात जी या स्किल्सना आपोआप शोधते आणि लोड करते.
या ऑडिटचे महत्त्व काय आहे
एजंट-स्किल रजिस्ट्री डेव्हलपर्सना पुन्हा वापरण्यायोग्य क्षमता (reusable capabilities) प्रकाशित करण्याची परवानगी देतात—हे असे कोड पॅकेजेस आहेत ज्यांना एखादा स्वायत्त (autonomous) एजंट गरजेनुसार वापरू शकतो. एजंट रजिस्ट्री स्कॅन करतो, प्रत्येक स्किलचा YAML frontmatter वाचतो (एक लहान स्ट्रक्चर्ड टेक्स्ट ब्लॉक ज्यामध्ये किमान नाव आणि वर्णन असणे आवश्यक आहे) आणि ते स्किल त्याच्या उद्दिष्टांशी जुळते की नाही याचा निर्णय घेतो. जर frontmatter गहाळ असेल किंवा चुकीच्या स्वरूपात असेल, तर ते स्किल एजंटच्या मेनूमधून गायब होते. ज्या जगात स्वायत्त एजंट मीटिंग्स शेड्यूल करतात, सर्व्हरमधील समस्या सोडवतात आणि बरेच काही करतात, तिथे एखादे खराब झालेले स्किल संपूर्ण वर्कफ्लोमध्ये अडथळा आणू शकते.
आकडेवारी काय दर्शवते
- ५७.८% स्किल्समध्ये किमान एक spec violation आहे.
- २९.२% स्किल्समध्ये असे नाव आहे जे रजिस्ट्री slug (URL identifier) शी जुळत नाही.
- १८.१% मध्ये तुटलेले package paths किंवा मृत लिंक्स आहेत.
- ७.८% (१९२ स्किल्स) मध्ये अजिबात YAML frontmatter नाही, ज्यामुळे त्यांना नाव किंवा वर्णन मिळत नाही.
- ३.८% मध्ये असे absolute file paths आहेत जे फक्त लेखकाच्या मशीनवर अस्तित्वात आहेत.
- २.४% मध्ये
allowed-toolsफील्डचा चुकीचा वापर केला आहे, ज्यामुळे एजंटला ते वाचता येत नाही. - २.१% मध्ये environment variables द्वारे API keys उघड होतात, जे सुरक्षेच्या दृष्टीने धोक्याची घंटा आहे.
- १.३% मध्ये बाह्य command-line टूल्स घोषित न करता वापरले जातात, जे portability नियमांचे उल्लंघन करते.
Portability चा प्रश्न सर्वात जास्त समोर येतो. /home/USER/.local/bin/tool सारखा absolute path त्या डेव्हलपरसाठी काम करतो ज्याने स्किल लिहिले आहे, परंतु इतर कोणत्याही वापरकर्त्यासाठी तो अपयशी ठरतो, ज्यामुळे runtime errors येतात ज्या स्टॅटिक चेकमध्ये कधीही पकडल्या जात नाहीत.
सखोल विश्लेषण: openclaw केस
या ऑडिटमध्ये openclaw रिपॉझिटरीमध्ये असलेल्या ४६ स्किल्सची देखील तपासणी करण्यात आली. चुकीचे अलार्म (false alarms) टाळण्यासाठी टेस्टिंग स्क्रिप्टमध्ये सुधारणा केल्यानंतर, रिव्ह्यूअरला ५९ वास्तविक दोष आढळले—हे एक स्मरणपत्र आहे की अतिशय आक्रमक linters उलट परिणाम करू शकतात. जेव्हा एखादे टूल खूप जास्त निरुपद्रवी समस्या दर्शवते, तेव्हा डेव्हलपर्स त्याचा वापर करणे थांबवतात आणि खऱ्या समस्या सुटून जातात.
openclaw मधील दोन दोष अशा फाईल्सकडे निर्देश करत होते ज्या आता रिपॉझिटरीमध्ये अस्तित्वात नाहीत. मेंटेनकरने एक फिक्स मर्ज केला ज्यामुळे गहाळ संदर्भ (references) पुन्हा प्राप्त झाले, हे दर्शवते की एक सिंगल pull request कशी तुटलेली dependency chain दुरुस्त करू शकते.
डेव्हलपर्सच्या प्रतिक्रिया
ऑडिटकरने मूळ स्किल रिपॉझिटरीजवर issues उघडले. एक रिपोर्ट फेटाळण्यात आला; मेंटेनकरने असा युक्तिवाद केला की "broken" हे प्रत्यक्ष runtime behavior नुसार ठरवले पाहिजे, केवळ स्टॅटिक फाईल इन्स्पेक्शनद्वारे नाही. ऑडिटकरने मान्य केले की 'brokenness' ची कडक व्याख्या ही स्किल प्रत्यक्षात कसे कार्यान्वित होते याशी सुसंगत असावी. दुसरा issue स्वीकारला गेला आणि त्यावरील फिक्स आता लाईव्ह आहे.
कोणाला फायदा—किंवा तोटा होऊ शकतो
- एजंट्स आणि एंड-युजर्सना जेव्हा रजिस्ट्रीमध्ये केवळ नियमांचे पालन करणारी आणि portable स्किल्स असतात, तेव्हा अधिक सुलभ आणि अधिक अंदाजित (predictable) वर्तन मिळते.
- स्किल ऑथर्सना अधिक स्पष्ट व्हॅलिडेशन नियम मिळतात जे प्रकाशनापूर्वी चुका पकडतात, ज्यामुळे issue triage मधील येण्या-जाण्याचा त्रास कमी होतो.
- रजिस्ट्री ऑपरेटर्सना अधिक कडक व्हॅलिडेशन पाइपलाइन्स तयार कराव्या लागतील किंवा इंटिग्रेट कराव्या लागतील; त्यांच्याशिवाय, संपूर्ण इकोसिस्टमचा विश्वास कमी होण्याचा धोका आहे.
शिथिल व्हॅलिडेशनमुळे "quick-and-dirty" सबमिशनला प्रोत्साहन मिळते, ज्यामुळे प्रोडक्शनमध्ये एजंट्समध्ये बिघाड होऊ शकतो आणि संभाव्यतः खर्चिक डाउनटाइम किंवा सुरक्षा धोके निर्माण होऊ शकतात.
प्रतिवाद: सर्व उल्लंघन घातक आहेत का?
काही लोकांचा असा युक्तिवाद आहे की काही "त्रुटी" निरुपद्रवी आहेत. जर एखादा एजंट प्रदर्शित नावाऐवजी slug द्वारे स्किल्स निवडत असेल, तर नावातील विसंगतीचा त्यावर परिणाम होणार नाही. लोकल डेव्हलपमेंटसाठी environment मधून API keys वाचणे हा एक हेतुपुरस्सर डिझाइन निर्णय असू शकतो. तथापि, ऑडिटमधील टक्केवारी कोणत्याही विचलनाला (deviation) उल्लंघन मानते, ज्यामुळे काही समस्यांचा व्यावहारिक प्रभाव अतिरंजित वाटू शकतो.
पुढे काय पाहावे
- प्रगत linters जे खऱ्या portability bugs आणि निरुपद्रवी गोष्टींमधील फरक ओळखतील.
- रजिस्ट्री-साइड व्हॅलिडेशन हुक्स जे आवश्यक frontmatter नसलेल्या किंवा absolute paths असलेल्या सबमिशनना नाकारतील.
- कम्युनिटी-चालित ऑडिट्स जे उत्पादन (production) एजंट्सपर्यंत पोहोचण्यापूर्वी लपलेले दोष समोर आणतील.
- संभाव्य spec रिव्हिजनज जे
allowed-toolsसारख्या संदिग्ध फील्ड्स स्पष्ट करतील आणि environment variables च्या स्वीकार्य वापराची व्याख्या करतील.
टूल्सची पुढची लाट बहुधा या तपासण्या continuous-integration पाइपलाइन्समध्ये समाविष्ट करेल, ज्यामुळे अनुपालन (compliance) ही मॅन्युअल विचार करण्याऐवजी एक ऑटोमॅटिक गेट बनली जाईल.
निष्कर्ष
सार्वजनिकरित्या सूचीबद्ध केलेल्या बहुतांश AI-agent कौशल्यांमध्ये मूलभूत अनुपालन (compliance) तपासणीत अपयश येते आणि एक मोठा हिस्सा तर अजिबात निवडता येत नाही. हे निष्कर्ष अधिक कडक प्रमाणीकरण (validation), उत्तम लिंटिंग टूल्स (linting tools) आणि एक अशी सामुदायिक संस्कृती यांची स्पष्ट गरज अधोरेखित करतात, जी स्पेसिफिकेशनचे (spec) पालन करणे ही प्रकाशनासाठी एक पूर्वअट मानते. जोपर्यंत ही सुरक्षा यंत्रणा (safeguards) कार्यान्वित होत नाही, तोपर्यंत एजंट्सना ठिसूळ आणि नॉन-पोर्टेबल (non-portable) कौशल्यांमुळे अडचणी येत राहतील.