Perplexity पर एजेंट कौशल डिजाइन, परिष्कृत और बनाए रखना

Perplexity के फ्रंटियर एजेंट उत्पाद मॉड्यूलर कौशल (Agent Skills) में संकुलित जानकारी और डोमेन विशेषज्ञता की नींव पर टिके हैं। हम अपने तकनीकी परिवेशों में कौशलों का सावधानीपूर्वक तैयार किया गया पुस्तकालय बनाए रखते हैं। इन कौशलों में Perplexity Computer को संचालित करने वाली कई सामान्य-उद्देश्यीय उपयोगिताएं; वित्त, कानून और स्वास्थ्य जैसे क्षेत्रों में ऊर्ध्वाधर-विशिष्ट क्षमताएं; और उपयोगकर्ता की जरूरतों को पूरा करने के लिए मॉड्यूल की एक बहुत लंबी सूची शामिल है। कुछ कौशल शायद ही कभी उपयोग किए जाते हैं, लेकिन जब उपयोग किए जाते हैं तो वे महत्वपूर्ण होते हैं। लगातार उत्कृष्ट उपयोगकर्ता अनुभव सुनिश्चित करने के लिए, Perplexity की एजेंट टीम कौशल की गुणवत्ता को कोड की गुणवत्ता के समान ही प्राथमिकता देती है।

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

उदाहरण के लिए, यदि आप PEP20 - द ज़ेन ऑफ़ पाइथन से कुछ सूक्तियों को लें, तो यह स्पष्ट हो जाता है कि अच्छा पाइथन कोड लिखना अच्छे कौशल लिखने जैसा नहीं है। 20 पंक्तियों के ज्ञान में से, कम से कम आधी पंक्तियाँ कौशल लिखते समय पूरी तरह से गलत या सक्रिय रूप से भ्रामक हैं। उनमें से पांच यहाँ दिए गए हैं:

Python के Zen और Skills लिखने के लिए लेख के मार्गदर्शन के बीच पाँच अंतर।

यह मार्गदर्शिका वह दस्तावेज है जिसका उपयोग Perplexity भर के इंजीनियर कौशल विकसित और समीक्षा करते समय करते हैं। हम इस मार्गदर्शिका को सार्वजनिक भी कर रहे हैं ताकि हमारी खोजों और सीखों से व्यापक समुदाय को लाभ मिल सके। चाहे आप अपने दैनिक कार्य में उत्पादन कौशल डिजाइन करने वाले इंजीनियर हों, Computer उपयोगकर्ता हों जो अपने स्वयं के कौशल विकसित करना चाहते हों, या दोनों, यह मार्गदर्शिका आपके लिए है।

कौशल क्या है?

जब आप कोई कौशल लिखते हैं, तो आप साधारण पुराना सॉफ्टवेयर नहीं लिख रहे होते हैं (भले ही कौशल अब एजेंट प्रणालियों के लिए मुख्य तार्किक इंजन का हिस्सा हैं)। बल्कि, आप मॉडल और उनके परिवेश के लिए संदर्भ बना रहे होते हैं। एक कौशल में अलग-अलग बाधाएं और अलग-अलग डिजाइन सिद्धांत होते हैं। यदि आप कोड की तरह कौशल लिखेंगे, तो आप असफल हो जाएंगे।

एक कौशल कम से कम चार चीजें है, विशेष रूप से Perplexity में हम उन्हें कैसे बनाते हैं, इस संदर्भ में।

एक कौशल एक निर्देशिका है

एक कौशल केवल एक SKILL.md फाइल नहीं है। कई मामलों में, एक कौशल में कई फाइलें शामिल होती हैं। आपके कौशल के नाम पर बनी निर्देशिका के अंतर्गत, आपके पास हो सकता है:

SKILL.md: फ्रंटमैटर और निर्देश

scripts/: कोड जिसे एजेंट चलाता है, फिर से आविष्कार नहीं करता

references/: भारी दस्तावेज, सशर्त रूप से लोड किए गए

assets/: टेम्प्लेट, स्कीमा और डेटा

config.json: पहली बार उपयोगकर्ता सेटअप

यह हब-एंड-स्पोक पैटर्न आपको कौशल को बहुत केंद्रित और चुस्त रखने की अनुमति देता है, और कोई भी फोल्डर संरचना का बहुत रचनात्मक तरीके से उपयोग कर सकता है। कभी-कभी, विशेष रूप से जटिल कौशल मॉडल को बेहतर तरीके से नेविगेट करने में मदद करने के लिए पदानुक्रम के कई स्तरों से लाभान्वित होते हैं। मान लीजिए कि एक कौशल को 300 विषयों में ज्ञान की आवश्यकता है, जिन्हें 20 विषय क्षेत्रों में समूहीकृत किया जा सकता है। 300 में से सही विषय को विश्वसनीय रूप से चुनना आज के सर्वश्रेष्ठ फ्रंटियर मॉडल के लिए भी एक अनसुलझी चुनौती है। मॉडल के लिए 15 विषयों के बीच की तुलना में 20 क्षेत्रों में से एक पर ध्यान केंद्रित करना एक बहुत आसान चयन समस्या है।

बहुस्तरीय पदानुक्रम कैसे मूल्य प्रदान करता है, इसका एक उदाहरण के रूप में, हमारी टीम ने पिछले कर सीजन में Computer की अमेरिकी आयकर क्षमताओं को संचालित करने वाले कौशल के भीतर सामयिक नेस्टिंग के तीन स्तरों को नियोजित किया। कर कानून की जटिलता को देखते हुए यह पदानुक्रम पूरी तरह से अपरिहार्य था: हमारे शुरुआती परीक्षणों में, मॉडल को अमेरिकी आंतरिक राजस्व कोड के सभी 1,945 अनुभागों वाली एक एकल फ़ोल्डर प्रस्तुत करने के परिणामस्वरूप कौशल को बिल्कुल भी लोड न करने की तुलना में खराब प्रदर्शन हुआ। जानकारी को तार्किक उपखंडों में व्यवस्थित करना उच्च-सटीक पठन संचालन सुनिश्चित करने के लिए अपरिहार्य था।

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

बड़ा करें

एक कौशल एक प्रारूप है

एक कौशल एक प्रारूप है। मुख्य रूट SKILL.md फाइल में नाम और विवरण दोनों होने चाहिए। इसके अलावा, कौशल को उस निर्देशिका नाम के साथ सटीक रूप से मैप करने की आवश्यकता है जिसमें कौशल स्थित है। नाम सभी छोटे अक्षरों में होना चाहिए, कोई स्पेस नहीं होना चाहिए, और हाइफन का उपयोग किया जा सकता है। विवरण रूटिंग ट्रिगर है। यह एक सामान्य विफलता बिंदु है: विवरण इस बात के लिए आंतरिक प्रलेखन नहीं है कि कौशल क्या करता है। यह मॉडल के लिए निर्देश है कि कौशल कब लोड करना है। इसलिए, आप अक्सर "Load when" देखेंगे, न कि "This Skill does"। यह महत्वपूर्ण है क्योंकि अधिकांश कार्यान्वयन विवरण को मॉडल संदर्भ में कैसे इंजेक्ट करते हैं।

फ्रंटमैटर के भीतर, “depends:” भी है, जो आपको पदानुक्रमित कौशल निर्भरताएं बनाने की अनुमति देता है, और “metadata:”, जिसका उपयोग समीक्षाओं और मूल्यांकन के लिए किया जाता है। विभिन्न एजेंट प्रणालियां अपने स्वयं के फ्रंटमैटर फ़ील्ड को भी परिभाषित कर सकती हैं, जिनका उपयोग उन प्रणालियों के लिए विशिष्ट तरीके से किया जा सकता है। एक विकल्प के रूप में, कौशल-विशिष्ट मेटाडेटा को एक सहायक JSON या YAML कॉन्फ़िगरेशन फाइल में संकुलित किया जा सकता है। यह तब वांछनीय होता है जब ऐसी एजेंट प्रणालियां बनाई जाती हैं जिन्हें मॉडल के संदर्भ को विवरणों के साथ प्रदूषित किए बिना प्रति कौशल रनटाइम व्यवहार के विभिन्न प्रकारों की सुविधा प्रदान करने की आवश्यकता होती है। अंत में, इसी तरह का व्यवहार पठन पर कौशल फ्रंटमैटर को हटाकर प्राप्त किया जा सकता है। Computer इस पद्धति को नियोजित करता है, जो कॉन्फ़िगरेशन को रूट SKILL.md फाइल में संरक्षित करने की अनुमति देता है। पार्सिंग तर्क में विस्तार पर सावधानीपूर्वक ध्यान देने की आवश्यकता है, और यदि कुछ फ़ील्ड हैं जो मॉडल संदर्भ के भीतर होना उपयोगी हैं तो आप सशर्त स्ट्रिपिंग लागू करना चाह सकते हैं।

एक कौशल आमंत्रणीय है

एक कौशल आमंत्रणीय है। एजेंट रनटाइम पर एक कौशल लोड करता है। महत्वपूर्ण बात यह है कि कौशल हमेशा संदर्भ में बंडल नहीं किए जाते हैं। डिफ़ॉल्ट रूप से, अधिकांश एजेंट प्रणालियां विशेष आवश्यकता पर कौशल को क्रमिक रूप से खोलती हैं।

Computer में हमने जिस तरह से कौशल लागू किए हैं, उसमें संदर्भ लागत के कम से कम तीन स्तर हैं। प्रक्रिया यहां दी गई है:

Computer load_skill(name="...") को कॉल करता है

Computer कौशल निर्देशिका को अलग किए गए निष्पादन सैंडबॉक्स में कॉपी करता है

Computer “depends:” टैग में निर्भरताओं को पुनरावर्ती रूप से ऑटो-लोड करता है

Computer फिर फ्रंटमैटर को हटा देता है और एजेंट इस प्रकार केवल मुख्य भाग और अतिरिक्त फ़ाइलों को देखता है

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

एक कौशल प्रगतिशील है

कौशल प्रगतिशील हैं। Computer में, संदर्भ लागत के तीन अलग-अलग स्तर हैं, और हम विभिन्न चरणों में तीनों को उठाते हैं:

Skill संदर्भ के तीन स्तर: index, full Skill load, और runtime reference files.

Computer एक कौशल इंडेक्स बनाता है जिसमें प्रत्येक उपलब्ध कौशल के लिए नाम और विवरण होता है। इसके लिए बजट प्रति कौशल लगभग 100 टोकन है (छोटा और भी बेहतर है)। यह इतना तंग है क्योंकि आप हर सत्र में, हर उपयोगकर्ता के लिए इस लागत का भुगतान कर रहे हैं। इसे बातचीत की शुरुआत में ही सिस्टम प्रॉम्प्ट में इंजेक्ट किया जाता है। मॉडल के पास कई नामित कौशल और विवरणों तक पहुंच है ताकि यह निर्णय ले सके कि “load_skill()” को कॉल करना है या नहीं। इस इंडेक्स में शामिल होने के लिए बार बहुत ऊंचा है। आपके कौशल को बहुत उपयोगी होने की आवश्यकता है, और विवरण को अत्यधिक सघन और संक्षिप्त होने की आवश्यकता है क्योंकि हर कोई हर समय लागत का भुगतान कर रहा है।

एजेंट सिस्टम द्वारा कौशल लोड करने के बाद, पूर्ण SKILL.md बॉडी होती है। आदर्श रूप से, बॉडी टेक्स्ट 5,000 टोकन से अधिक नहीं होना चाहिए। तब भी, आप चाहते हैं कि हर वाक्य मायने रखे क्योंकि एक बार जब आप एक कौशल लोड कर लेते हैं, तो बाकी बातचीत को तब तक भुगतान करना पड़ता है जब तक आप संकुचन सीमा तक नहीं पहुंच जाते। कई थ्रेड तीन और पांच अलग-अलग कौशल के बीच लोड होते हैं, जिससे यह लागत गुणा हो जाती है। बहुत अधिक अनावश्यक जानकारी वाले कौशल लगभग निश्चित रूप से अन्य कौशल के साथ-साथ समग्र एजेंटिक क्षमताओं को भी खराब कर देंगे। संक्षेप में, यदि आपका कौशल लोड होता है और वह सही काम नहीं करता है, तो यह व्यर्थ का संदर्भ है।

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

इंडेक्स में, हर टोकन महत्वपूर्ण है। लोड किया गया कौशल बॉडी अधिक शिथिल है, और रनटाइम सबसे अधिक शिथिल है। यह 20,000 टोकन या शून्य टोकन हो सकता है। यह वह स्तर है जिस पर आप प्रगतिशील फैशन में मॉडल के संदर्भ का विस्तार करने के बारे में सोच सकते हैं।

आपको कौशल की आवश्यकता कब होती है?

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

जब आपको किसी कौशल की आवश्यकता होती है

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

यह हो सकता है कि आपका ज्ञान टिकाऊ है लेकिन प्रशिक्षण डेटा में नहीं है। कटऑफ या उद्यम विशिष्ट वर्कफ़्लो हो सकते हैं, या यह स्वाद का मामला हो सकता है। उदाहरण के लिए, हमारे पास Computer में हेनरी मोडिसिट (डिजाइन के हमारे प्रमुख) द्वारा लिखित कई डिजाइन-संबंधित कौशल हैं। उन कौशलों में हर टोकन के अस्तित्व का कारण यह है कि जब वेबसाइटों और पीडीएफ को डिजाइन करने की बात आती है तो हेनरी का स्वाद बहुत अच्छा है। हेनरी निर्दिष्ट करता है कि किन फोंट का उपयोग करना है और किन फोंट का उपयोग नहीं करना है, वे फोंट कैसे महसूस होते हैं, और निर्णय के अन्य मामले जो मॉडल केवल प्रशिक्षण डेटा से नहीं सीख सकता है।

जब आपको कौशल की आवश्यकता नहीं होती है

हम कई कौशल देखते हैं जिनमें इंजीनियरों ने git कमांड की एक श्रृंखला लिखी है जिसे क्रम में निष्पादित करने की आवश्यकता है। यह अनावश्यक है क्योंकि मॉडल पहले से ही जानता है कि यह कैसे करना है, जिसका अर्थ है कि यह बेहतरीन प्रलेखन बनाता है लेकिन एक खराब कौशल।

हम ऐसे उदाहरण देखते हैं जहाँ कौशल सिस्टम प्रॉम्प्ट से निर्देशों को दोहराते हैं। आपको उसके लिए कौशल की आवश्यकता नहीं है। अधिकांश अनुरोधों के लिए प्रासंगिक ज्ञान वैश्विक संदर्भ में शामिल किया जाना चाहिए, न कि सशर्त रूप से लोड किए गए कौशल में

यदि कोई ऐसी चीज है जो आपके द्वारा बनाए रखने की तुलना में तेजी से बदल रही है, तो आपको कौशल की आवश्यकता नहीं है। उदाहरण के लिए, यदि आप किसी रिमोट MCP एंडपॉइंट को हिट कर रहे हैं और उसके उपकरण या उन उपकरणों के संस्करण अक्सर बदल रहे हैं, तो आपको उन्हें कौशल में इंजेक्ट नहीं करना चाहिए। यदि आप ऐसा करते हैं, तो आप केवल बहाव के साथ समाप्त हो जाएंगे और मॉडल गलतियां करेगा।

हर कौशल एक कर है

यहाँ एक उपयोगी परीक्षण है जिसे आप अपने कौशल के हर वाक्य पर लागू कर सकते हैं: “क्या एजेंट इस निर्देश के बिना इसे गलत समझेगा?” यदि वाक्य को वहां होने की आवश्यकता नहीं है, तो यह वहां होने का खर्च नहीं उठा सकता क्योंकि हर कोई हर बार इस लागत का भुगतान कर रहा है। जब आप यह तय कर रहे हों कि कौशल जोड़ना है या नहीं, तो इस कर को याद रखें जिसमें प्रत्येक सत्र और प्रत्येक उपयोगकर्ता टोकन की लागत लेता है।

निम्नलिखित प्रसिद्ध उद्धरण, जो फ्रेंच में बेहतर लगता है, मोटे तौर पर अनुवाद करता है कि “मैंने इस पत्र को केवल इसलिए लंबा बनाया है क्योंकि मेरे पास इसे छोटा बनाने का समय नहीं था।”

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — ब्लेज़ पास्कल, Lettres Provinciales, 1657

पास्कल की तरह, आपको हर कौशल में समय निवेश करने की आवश्यकता है। छोटा कौशल लिखना कठिन है। यदि आपका कौशल लिखना आसान है, तो यह शायद बहुत लंबा है या इसे अस्तित्व में नहीं होना चाहिए। एक अच्छा कौशल जितना संभव हो उतना छोटा होता है।

यदि आप खुद को वन-शॉट कौशल निर्माण करने और पांच मिनट में पीआर (PRs) डालने की कोशिश करते हुए पाते हैं, तो परिणाम लगभग निश्चित रूप से घटिया होंगे। वास्तव में, शुरुआती शोध ने दिखाया है कि यदि आप कौशल लिखने के लिए एलएलएम (LLMs) का उपयोग कर रहे हैं, तो एलएलएम को शायद इससे कोई लाभ नहीं होगा: “स्व-निर्मित कौशल औसतन कोई लाभ नहीं प्रदान करते हैं, यह दिखाते हुए कि मॉडल उस प्रक्रियात्मक ज्ञान को विश्वसनीय रूप से लेखक नहीं कर सकते हैं जिससे उन्हें उपभोग करने से लाभ होता है।”

कौशल कैसे बनाएं

इसे दूसरे तरीके से कहें तो, आपको अपने द्वारा लिखे गए किसी भी कौशल में अपनी राय को इंजेक्ट करने की आवश्यकता है। इन चरणों का पालन करें।

चरण 0: इवैल (Evals) लिखें

सबसे पहले कुछ इवैल लिखें। आप मूल्यांकन मामले यहां से प्राप्त कर सकते हैं:

वास्तविक उपयोगकर्ता क्वेरी: उत्पादन या अपने ब्रेन ट्रस्ट से नमूना

ज्ञात विफलताएं: एजेंट विफल हो गया क्योंकि कौशल मौजूद नहीं था

पड़ोसी भ्रम: आपके डोमेन सीमा के करीब लेकिन किसी अन्य कौशल के लिए रूट करता है

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

समान नकारात्मक और सकारात्मक उदाहरणों के साथ शुरू करें। नकारात्मक उदाहरण अत्यंत शक्तिशाली हैं और सकारात्मक उदाहरणों से अधिक मायने रख सकते हैं।

चरण 1: विवरण

यह कौशल की सबसे कठिन पंक्ति है। यह एक रूटिंग ट्रिगर है, प्रलेखन नहीं। नाम और विवरण को सही करने के लिए, आपको कौशल की सामग्री के बारे में परवाह नहीं है। आप केवल इस बारे में परवाह करते हैं कि क्या कौशल सही बिंदुओं पर लोड और इंजेक्ट किया गया है और ऑफ-टारगेट साइड इफेक्ट्स से मुक्त है, जो कि नंबर एक विफलता मोड है। हर बार जब आप एक अतिरिक्त कौशल जोड़ते हैं, तो आप हर दूसरे कौशल को थोड़ा खराब बनाने का जोखिम उठाते हैं, इसलिए आपको यह सुनिश्चित करने की आवश्यकता है कि आप प्रतिगमन (regression) को कम कर रहे हैं।

फिर से, एक बुरा विवरण बताता है कि कौशल क्या करता है या यह क्यों उपयोगी है। एक अच्छा विवरण कहता है कि एजेंट को कौशल कब लोड करना चाहिए। उदाहरण के लिए, कहें कि आपके पास पुल अनुरोधों की निगरानी के लिए कुछ है। यह न लिखें कि कौशल क्या करता है। वह लिखें जो इंजीनियर तब कहते हैं जब वे निराश होते हैं और वे चाहते हैं कि आप सुनिश्चित करें कि उनका पीआर काम करता है, जैसे “babysit” या “watch CI” या “make sure this lands.”

यहाँ एक त्वरित चेकलिस्ट है:

“Load when...” के साथ शुरू होता है

50 शब्द या उससे कम का लक्ष्य रखें

उपयोगकर्ता के इरादे का वर्णन करता है, आदर्श रूप से वास्तविक क्वेरी से

वर्कफ़्लो को संक्षेप में प्रस्तुत नहीं करता है

वास्तविक क्वेरी वे हैं जिन्हें आप 80-20 में कवर कर सकते हैं। आमतौर पर, दो या तीन उदाहरण अच्छी तरह से काम करते हैं। जितना आपको चाहिए, उतना ही सटीक रूप से जोड़ना आसान नहीं है।

चरण 2: बॉडी लिखें

इसके बाद, कौशल की सामग्री को स्वयं लिखें। ध्यान दें कि यह चरण 0 या चरण 1 नहीं है।

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

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

उदाहरण के लिए, आपको लिखने की आवश्यकता नहीं है, “git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

इसके बजाय, लिखें, “Cherry-pick the commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why.”

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

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

अंत में, यदि कोई ऐसा हिस्सा है जो सशर्त है या सामग्री में अत्यधिक भारी है, तो इसे SKILL.md से बाहर निकालें, जो हब है, और इसे स्पोक्स में से एक में डाल दें। इसे एक एक्सेसरी फाइल में डालें जिसे क्रमिक रूप से लोड किया जा सकता है, जिसे हम आगे देखेंगे।

चरण 3: पदानुक्रम का उपयोग करें

जब आपके पास स्क्रिप्ट, संदर्भ हों, या आप किसी विशिष्ट टूल का उपयोग कर रहे हों तो कौशल पदानुक्रम का उपयोग करें:

Skill के भीतर scripts, references, assets, और configuration के लिए सुझाए गए उपयोग।

मुख्य कौशल से सशर्त या शाखाबद्ध किसी भी चीज के लिए, इसे एक फोल्डर में तोड़ दें। याद रखें, यह भी कि पदानुक्रम का बहुस्तरीय उपयोग विशेष रूप से जटिल कौशल के लिए किया जा सकता है। इनके लिए, आप इस पर सावधानीपूर्वक विचार करना चाहेंगे कि क्या कार्यक्षमता को एक अखंड रूप में कार्यान्वित किया जाना चाहिए या कौशल के संग्रह के रूप में (शायद depends: आधारित लोडिंग संबंधों के साथ)।

चरण 4: इटरेट (Iterate)

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

आप संभवतः कई छोटे शब्द परिवर्तन करेंगे। विवरण में छोटे शब्द परिवर्तनों का रूटिंग पर अत्यधिक प्रभाव पड़ सकता है (अन्य कौशलों पर स्पिलओवर प्रभाव सहित), इसलिए चरण 5 से पहले वह सारा काम करें।

चरण 5: शिप (Ship)

इसे शिप करें।

कौशल को कैसे बनाए रखें

अब जब आपने एक कौशल लिख लिया है, तो आपको इसे बनाए रखना होगा।

गॉचा फ्लाईव्हील

इस बिंदु से आगे, आपके गॉचा की सूची बहुत बढ़ने या बदलने लगती है। हम अक्सर उन इंजीनियरों को देखते हैं जो पीआर (PRs) बनाते हैं जो अन-इवैल होते हैं, उदाहरण के लिए, विवरण बदलते हैं। यदि आपका कौशल मर्ज हो जाने के बाद आप विवरण बदल रहे हैं, तो आप पटरी से उतर गए हैं। यदि आप उस चीज में बदलाव कर रहे हैं जो यह तय करती है कि आपके कौशल को रूट करना है या नहीं, तो आपको कुछ इवैल लिखने की आवश्यकता है जो परिवर्तनों का समर्थन करते हैं।

कौशल परिशिष्ट-मुख्य रूप से हैं। गॉचा अनुभाग समय के साथ सबसे अधिक मूल्य अर्जित करता है:

एजेंट किसी चीज पर विफल होता है → गॉचा जोड़ें

एजेंट कौशल को ऑफ टारगेट लोड करता है → विवरण को कस लें और नकारात्मक इवैल जोड़ें

एजेंट कौशल को लोड नहीं करता है जब उसे करना चाहिए → कीवर्ड और सकारात्मक इवैल जोड़ें

सिस्टम प्रॉम्प्ट बदलता है → विवाद या दोहराव की जांच करें

आंतरिक परीक्षण में या उत्पादन में एक विफलता मामले को नोटिस करना और गॉचा जोड़ना आसान है। यह एक नकारात्मक उदाहरण है इसलिए यह वास्तव में स्पष्ट मार्गदर्शन नहीं बदल रहा है, लेकिन यह मॉडल को बताता है, “हे, यह ज्ञात विफलता है।”

जैसे-जैसे आप 80-20 से 99.9% या 99.99% सफलता दर तक पहुंचने की ओर बढ़ते हैं, इस गॉचा सूची को बढ़ाना आसान है। जैसे ही आप इन नकारात्मक उदाहरणों को देखते हैं, आपको अधिकांश गॉचा अनुभाग में जोड़ना चाहिए। आपको लंबे निर्देश नहीं जोड़ने चाहिए या विवरण नहीं बदलना चाहिए।

इवैल सुइट्स (Eval Suites)

Perplexity में, हम विभिन्न चीजों की जांच करने के लिए कई इवैल सुइट्स चलाते हैं। कौशल लोडिंग और कौशल फ़ाइल रीड्स हैं, जो कौशल लोडिंग की सटीकता, रिकॉल और निषिद्ध जांच की जांच करता है। क्या एजेंट आपके कौशल को रूट करेगा जब उसे करना चाहिए? ये सुनिश्चित करते हैं कि नए कौशल मौजूदा सीमाओं को न तोड़ें।

ऐसे इवैल भी हैं जो उचित प्रगतिशील लोडिंग की जांच कर सकते हैं। एजेंट कौशल लोड कर सकता है, लेकिन क्या यह एक्सेसरी फाइल या फाइलों को पढ़ता है? उदाहरण के लिए, यदि आपके पास वित्त क्वेरी के लिए वित्त कौशल है, तो क्या यह विशेष FORMATTING.md फाइल को पढ़ता है?

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

अंत में, इन इवैल को विभिन्न मॉडल के खिलाफ चलाना महत्वपूर्ण है। Computer कम से कम तीन अलग-अलग ऑर्केस्ट्रेशन मॉडल परिवारों का समर्थन करता है: GPT, Claude Opus, और Claude Sonnet। आप यह सुनिश्चित करने के लिए कि आपको अलग व्यवहार न मिले, इन विभिन्न एजेंट ऑर्केस्ट्रेटर के खिलाफ अपना कौशल लोडिंग और डोमेन कौशल चलाना चाहते हैं। जब कौशल की बात आती है तो Sonnet और GPT काफी अलग तरह से व्यवहार करते हैं।

अंतिम विचार और टेकअवे

आप जितने अधिक कौशल बनाएंगे, उन्हें बनाने में आप उतने ही बेहतर होंगे। यदि आप कौशल का उपयोग करके दैनिक आधार पर किए जा रहे कार्यों को स्वचालित नहीं कर रहे हैं या अधिक पुनरुत्पादक बनाने की कोशिश नहीं कर रहे हैं, तो तुरंत शुरू करें।

कौशल बनाने का कार्य आपको अधिक कौशल बनाने में बेहतर बनाता है, लेकिन साथ ही, वे व्यावसायिक प्रक्रियाओं को स्वचालित करने में बेहद अच्छे हैं। यदि आप कुछ ऐसा वर्णन कर सकते हैं जो आप हर हफ्ते अपने स्टैंडअप से पहले, हर स्प्रिंट के अंत में, या कुछ भी जो आप एक इंजीनियर के रूप में दैनिक, साप्ताहिक, या त्रैमासिक आधार पर करते हैं, तो आपको अपना समय वापस खरीदने के लिए एक कौशल लिखना चाहिए।

क्या आप पोस्टमॉर्टम को स्वचालित कर सकते हैं? क्या आप पुल अनुरोधों की समीक्षा कर सकते हैं? कोई भी कार्य जो आप कर सकते हैं, आप कम से कम पहला पास एक एजेंट कौशल रख सकते हैं। यह आपका महत्वपूर्ण समय बचाएगा।

कहा जा रहा है कि, याद रखें कि एक कौशल आसान या हमेशा आवश्यक भी नहीं है। कम ही अधिक है। कुछ अन्य टेकअवे:

कौशल से पहले इवैल लिखें। आसन्न लेकिन अलग कौशल के लिए नकारात्मक उदाहरण और निषिद्ध लोड शामिल करें।

विवरण कठिन हिस्सा है। “Load when...” (हर शब्द ध्यान आकर्षित करने की लागत लेता है)।

गॉचा अत्यधिक उच्च-मूल्य वाली सामग्री हैं। पतले से शुरू करें, जैसे एजेंट विफल होता है वैसे ही बढ़ें।

याद रखें कि नया कौशल जोड़कर अन्य पूर्व-मौजूद कौशल को तोड़ना आसान है, भले ही आपने उसे छुआ न हो (दूरी पर कार्रवाई से सावधान रहें)।

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

उद्धरण

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}