🔧 स्किल क्या है?
AI एजेंट्स के संदर्भ में, एक skill (जिसे यह भी कहा जाता है tool or function) एक पैकेज्ड, पुन: प्रयोज्य क्षमता है जिसे एक LLM संदर्भ विंडो के बाहर दुनिया के साथ इंटरैक्ट करने के लिए इनवोक कर सकता है। स्किल्स भाषा समझ और वास्तविक दुनिया की क्रिया के बीच की खाई को पाटते हैं।
प्रत्येक स्किल के चार घटक होते हैं:
- Name — एक अनोखा पहचानकर्ता जिसे मॉडल स्किल का संदर्भ देने के लिए उपयोग करता है (उदा.,
web_search) - Description — यह क्या करता है और कब उपयोग करें इसका प्राकृतिक भाषा में वर्णन; LLM इसे पढ़ता है यह तय करने के लिए कि कब स्किल को कॉल करना है
- इनपुट स्कीमा — आर्गुमेंट्स की संरचित परिभाषा (JSON Schema); मॉडल कार्य के आधार पर इन्हें भरता है
- Implementation — वास्तविक कोड जो चलता है: एक API कॉल, डेटाबेस क्वेरी, शेल कमांड, या कोई अन्य ऑपरेशन
उदाहरण: A get_weather स्किल का विवरण "किसी शहर के लिए वर्तमान मौसम लाता है", स्वीकार करता है { "city": "string" } को इनपुट के रूप में, और एक मौसम API को कॉल करता है। LLM कभी भी API कुंजी या HTTP कॉल नहीं देखता — इसे सिर्फ परिणाम टेक्स्ट के रूप में वापस मिलता है।
⚙️ कैसे टूल कॉलिंग काम करती है
जब एक एजेंट के पास स्किल्स की पहुंच होती है, तो LLM उन्हें सीधे कॉल नहीं करता — यह requests एक कॉल उत्पन्न करके एक संरचित आउटपुट भेजता है। रनटाइम (आपका एप्लिकेशन कोड) वास्तविक कॉल को निष्पादित करता है और परिणाम लौटाता है। यहाँ पूरा चक्र है:
- टूल पंजीकरण — आपका कोड मॉडल को उपलब्ध स्किल्स की एक सूची उनके विवरण और स्कीमाओं के साथ भेजता है
- मॉडल तर्क — LLM कार्य और उपलब्ध टूल्स पढ़ता है, तय करता है कौन सा टूल कॉल करना है और किन आर्गुमेंट्स के साथ
- टूल कॉल अनुरोध — मॉडल एक संरचित "tool call" संदेश आउटपुट करता है (उदा.,
{ "tool": "web_search", "args": { "query": "current Gemini models" } }) - Execution — आपका रनटाइम कोड वास्तविक फ़ंक्शन, API, या सेवा को कॉल करता है
- रिज़ल्ट इंजेक्शन — परिणाम वार्तालाप संदर्भ में वापस जोड़ दिया जाता है
- लगातार तर्क — मॉडल परिणाम पढ़ता है और या तो कोई और टूल कॉल करता है, फॉलो-अप पूछता है, या अंतिम उत्तर उत्पन्न करता है
यह लूप एक ही टर्न में कई बार दोहरा सकता है। एक जटिल एजेन्टिक कार्य अंतिम उत्तर देने से पहले अनुक्रम में 10–20 टूल्स को कॉल कर सकता है।
📊 Skills बनाम Plugins बनाम MCP Servers
टर्मिनोलॉजी तेजी से विकसित हुई है। ऐतिहासिक रूप से ये अवधारणाएँ कैसे संबंधित हैं:
| Era | Name | यह कैसे काम करता था | Status |
|---|---|---|---|
| 2023 | ChatGPT Plugins | OpenAPI स्पेक के साथ उपयोगकर्ता-स्थाप्य एक्सटेंशन्स; ChatGPT ने इन्हें HTTP के माध्यम से कॉल किया | डिप्रिकेटेड (GPTs + tools द्वारा प्रतिस्थापित) |
| 2023 | OpenAI Function Calling | API-स्तर JSON Schema परिभाषाएँ; मॉडल संरचित फ़ंक्शन कॉल आउटपुट करता है, आपका कोड इसे निष्पादित करता है | सक्रिय — पुनः नामित "tool use" |
| 2023– | Tool Use / Skills | फ़ंक्शन कॉलिंग जैसा ही; Anthropic ने "tool use" शब्द बनाया, अन्य इसे "skills" या "functions" कहते हैं | सक्रिय — वर्तमान मानक |
| 2024– | MCP Servers | मानकीकृत प्रोटोकॉल (Anthropic, Dec 2024) टूल सर्वरों को पैकेज और वितरित करने के लिए; कोई भी MCP क्लाइंट किसी भी MCP सर्वर से कनेक्ट कर सकता है | सक्रिय — बढ़ता हुआ इकोसिस्टम |
मुख्य अंतर: परंपरागत टूल उपयोग आपके एप्लिकेशन कोड में इनलाइन परिभाषित होता है। MCP सर्वर स्टैंडअलोन प्रोसेस होते हैं जो एक मानकीकृत प्रोटोकॉल पर टूल्स एक्सपोज़ करते हैं — जिससे उन्हें अलग-अलग AI क्लाइंट्स (Claude Desktop, Cursor, VS Code, कस्टम एजेंट्स) के बीच पुन: उपयोग योग्य बनाया जा सके। और पढ़ें: MCP क्या है.
🗂️ टूल श्रेणियाँ और जोखिम स्तर
सभी टूल्स एक जैसा जोखिम नहीं रखते। जोखिम स्तर के अनुसार समूहित करना आपके एजेंट के लिए परिभाषित करने में मदद करता हैएक्शन स्पेसऔर मानव-इन-द-लूप चेकपॉइंट्स कहाँ जोड़ने हैं:
| Category | Examples | Risk | Recommendation |
|---|---|---|---|
| Read-only | web_search, read_file, get_weather, list_dir | Low | स्वायत्त रूप से अनुमति दें; सभी कॉल्स का लॉग रखें |
| लेख (लोकल) | write_file, create_dir, edit_code | Medium | एक सैंडबॉक्सड वर्कस्पेस डायरेक्टरी तक सीमा निर्धारित करें |
| नेटवर्क / बाहरी | send_email, post_to_slack, call_api | मध्यम–उच्च | अपरिवर्तनीय भेजने के लिए HITL अनुमोदन |
| OS / Shell | run_command, execute_script, install_package | High | कंटेनरीकृत वातावरण तक सीमित करें; HITL आवश्यक |
| Destructive | delete_file, drop_table, revoke_access | Critical | हमेशा स्पष्ट मानव पुष्टि आवश्यक करें |
🏗️ एक अच्छे स्किल की संरचना
एक स्किल के लिए सबसे महत्वपूर्ण डिज़ाइन निर्णय इसका description. LLM निर्णय लेने के लिए विवरण पढ़ता है — खराब लिखी गई विवरण गलत टूल चयन, मिस कॉल या अस्पष्ट आर्गुमेंट्स का कारण बन सकती है।
एक विवरण प्रभावी क्या बनाता है
- जब उपयोग करना है इसके बारे में स्पष्ट रहें — "जब उपयोगकर्ता वास्तविक समय के डेटा या वर्तमान घटनाओं के बारे में पूछता है तो इस टूल का उपयोग करें" "वेब खोज करता है" की तुलना में बेहतर है
- कहें कि यह क्या नहीं करता — "30 दिनों से पुराने ऐतिहासिक डेटा लौटाता नहीं है"
- आउटपुट फ़ॉर्मेट का वर्णन करें — "शीर्षक, url, और स्निपेट फ़ील्ड्स के साथ खोज परिणामों की JSON ऐरे लौटाता है"
- इसे 200 शब्दों से कम रखें — ~200 टोकन से लंबी विवरण बहुत से टूल्स पंजीकृत होने पर मॉडल के ध्यान को ओवरवेल्म कर सकती है
स्कीमा डिज़ाइन सिद्धांत
- अनिवार्य बनाम वैकल्पिक — केवल तब फ़ील्ड्स को आवश्यक के रूप में चिह्नित करें जब वास्तव में आवश्यक हों; डिफ़ॉल्ट्स के साथ वैकल्पिक फ़ील्ड्स मॉडल त्रुटियों को कम करते हैं
- सीमित मानों के लिए enums का उपयोग करें —
"format": {"enum": ["json", "markdown", "text"]}हैलुसिनेटेड मानों को रोकता है - आइडम्पोटेंट टूल्स को प्राथमिकता दें — जो टूल्स सुरक्षित रूप से पुन: प्रयास किए जा सकते हैं (रीड, लुकअप) वे वन-शॉट कार्रवाईयों (सेंड, डिलीट) से अधिक सुरक्षित होते हैं
- संरचित डेटा लौटाएँ — JSON रिस्पॉन्सेस मॉडल के लिए अनस्ट्रक्चर्ड टेक्स्ट ब्लॉब्स की तुलना में तर्क करने में आसान होते हैं
💡 वास्तविक दुनिया के उदाहरण
| स्किल नाम | यह क्या करता है | मुख्य आर्गुमेंट्स | Risk |
|---|---|---|---|
web_search | एक सर्च इंजन से क्वेरी करें और शीर्ष परिणाम लौटाएं | query: string, num_results?: number | Low |
read_file | वर्कस्पेस डायरेक्टरी से फ़ाइल पढ़ें | path: string, offset?: number, limit?: number | Low |
write_file | एक फ़ाइल बनाएं या ओवरराइट करें | path: string, content: string | Medium |
run_tests | प्रोजेक्ट टेस्ट सूट को निष्पादित करें और परिणाम लौटाएं | filter?: string | Medium |
browser_screenshot | एक URL पर नेविगेट करें और स्क्रीनशॉट लौटाएं | url: string | Medium |
send_email | एक या अधिक प्राप्तकर्ताओं को ईमेल भेजें | to: string[], subject: string, body: string | उच्च — हमेशा HITL |
run_shell | किसी भी शेल कमांड को निष्पादित करें | command: string, cwd?: string | उच्च — सैंडबॉक्स आवश्यक |
✅ सर्वोत्तम प्रथाएँ
न्यूनतम अनुमतियाँ
प्रत्येक एजेंट को केवल वे टूल्स दें जिनकी उसे उसके विशिष्ट कार्य के लिए आवश्यकता है। एक एजेंट जो FAQ प्रश्नों का उत्तर देता है उसे की ज़रूरत नहीं है write_file or send_email. जितना छोटा एक्शन स्पेस होगा, यदि एजेंट को गलत दिशा में मोड़ा जाता है तो विस्फोट क्षेत्र उतना ही छोटा होगा। देखें:अति-अधिकारिता.
सभी टूल कॉल का ऑडिट करें
हर टूल कॉल को उसके आर्गुमेंट्स और परिणाम के साथ लॉग करें। यह डिबगिंग, लागत विभाजन, और असामान्य व्यवहार का पता लगाने में सक्षम बनाता है (उदा., एक एजेंट पढ़ रहा है ~/.ssh/ जबकि उसे केवल प्रोजेक्ट डायरेक्टरी तक पहुंचनी चाहिए)। AgentOps प्लेटफ़ॉर्म जैसे LangSmith इसे आसान बनाते हैं।
अपरिवर्तनीय क्रियाओं के लिए मानव-इन-द-लूप
कोई भी कार्रवाई जो उलटा करना कठिन या असंभव हो — संदेश भेजना, डेटा हटाना, खरीदारी करना — को निष्पादन से पहले स्पष्ट मानव पुष्टि की आवश्यकता होनी चाहिए। अपने एजेंट रनटाइम में HITL चेकपॉइंट्स बनाएं, सिर्फ प्रॉम्प्ट में नहीं। प्रॉम्प्ट ओवरराइड हो सकते हैं; कोड नहीं।
टूल पॉइज़निंग से सावधान रहें
यदि आप एजेंट्स को गतिशील रूप से MCP सर्वरों की स्थापना या खोज की अनुमति देते हैं, तो एक दुर्भावनापूर्ण सर्वर एक विवरण के साथ छिपे निर्देशों वाले टूल को पंजीकृत कर सकता है। किसी भी टूल को एजेंट के रजिस्ट्री में जोड़ने से पहले हमेशा टूल विवरणों की समीक्षा करें। देखें:टूल पॉइज़निंग.
स्पष्ट त्रुटि वापसी लिखें
जब एक टूल विफल होता है, तो मॉडल को पुनर्प्रयास करने, फॉलबैक टूल उपयोग करने, या उपयोगकर्ता को गरिमापूर्वक सूचित करने के लिए पर्याप्त संदर्भ के साथ एक संरचित त्रुटि लौटाएँ — न कि एक कच्चा अपवाद स्टैक ट्रेस। उदाहरण: { "error": "rate_limited", "retry_after": 5 }. एक अच्छी तरह से वर्णित त्रुटि एजेंट को पुन: प्रयास करने, एक फॉलबैक टूल का उपयोग करने, या उपयोगकर्ता को विनम्रता से सूचित करने देती है।