Sysls चेतावनी देता है: संदर्भ के साथ Claude और Codex को अतिभारित करने से प्रदर्शन कम हो सकता है

लेखक: sysls

स्टीम टेकफ्लो

शेनचाओ का परिचय: 26 लाख फॉलोअर्स वाले डेवलपर ब्लॉगर sysls ने एक व्यावहारिक लंबा लेख लिखा है, जिसे 827 लोगों ने शेयर किया और 7000 लोगों ने पसंद किया। इसका मुख्य संदेश केवल एक वाक्य है: आपके प्लगइन, मेमोरी सिस्टम और विभिन्न हैरन्स अधिकांशतः आपकी मदद की बजाय बाधा बन रहे हैं। यह लेख कोई सिद्धांत नहीं सिखाता, बल्कि वास्तविक उत्पादन प्रोजेक्ट्स से प्राप्त सभी क्रियाशील सिद्धांतों पर केंद्रित है—चाहे वह संदर्भ को कैसे नियंत्रित करें, AI की प्रशंसा की प्रवृत्ति को कैसे संभालें, या कार्य की समाप्ति की शर्तों को कैसे परिभाषित करें, यह अब तक का सबसे स्पष्ट लेख है जिसने Claude/Codex के इंजीनियरिंग प्रैक्टिस को समझाया है।

पूर्ण पाठ निम्नलिखित है:

आप एक डेवलपर हैं, जो रोजाना Claude और Codex CLI का उपयोग करते हैं और हर दिन सोचते हैं कि क्या आपने उनकी क्षमताओं को पूरी तरह से निकाल लिया है। कभी-कभी आप देखते हैं कि यह बेहद मूर्खतापूर्ण काम करता है, और आप समझ नहीं पाते कि कुछ लोग AI का उपयोग करके रॉकेट कैसे बना रहे हैं, जबकि आप दो पत्थरों को भी स्थिर रखने में असमर्थ हैं।

आपको लगता है कि यह आपके हैरनेस की समस्या है, या प्लगइन की, या टर्मिनल की, कुछ भी। आपने beads, opencode, zep का उपयोग किया है, और आपके CLAUDE.md में 26000 पंक्तियाँ लिखी गई हैं। लेकिन जितना भी आप प्रयास करते हैं, आप समझ नहीं पाते कि आप आसमान से क्यों दूर होते जा रहे हैं, जबकि दूसरे देवदूतों के साथ खेल रहे हैं।

यही वह लेख है जिसकी आप इंतजार कर रहे थे।

इसके अलावा, मेरा कोई हित संबंध नहीं है। मैं CLAUDE.md के साथ-साथ AGENT.md का उल्लेख करता हूँ, और मैं Claude के साथ-साथ Codex का उल्लेख करता हूँ, और मैं दोनों का भारी रूप से उपयोग करता हूँ।

पिछले कुछ महीनों में, मैंने एक दिलचस्प बात देखी: लगभग कोई भी अपने एजेंट की क्षमताओं को अधिकतम तरीके से नहीं जानता।

ऐसा लगता है जैसे कुछ लोग ही प्रॉक्सी को संपूर्ण दुनिया बनाने की अनुमति दे सकते हैं, जबकि बाकी लोग उपकरणों के विशाल समुद्र में घूम रहे हैं और चयन परेशानी में पड़ गए हैं—मान लेते हैं कि सही पैकेज, कौशल या हार्नेस संयोजन ढूंढ लेने से AGI प्राप्त हो जाएगी।

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

मैं यहाँ टूरिस्ट के तौर पर नहीं हूँ—जब से एजेंट बस कोड लिखना सीख रहे थे, मैंने उनका इस्तेमाल करना शुरू कर दिया था। मैंने सभी पैकेज, सभी हारनेस, सभी पैटर्न आजमाए हैं। मैंने एजेंट फैक्ट्री का उपयोग करके सिग्नल, इंफ्रास्ट्रक्चर और डेटा पाइपलाइन लिखे हैं, ये 'टॉय प्रोजेक्ट' नहीं, बल्कि वास्तविक उत्पादन परिवेश में चलने वाले उपयोग के मामले हैं। इतना सब करने के बाद...

आज, मैंने एक ऐसी कॉन्फ़िगरेशन का उपयोग किया जो लगभग इतनी सरल है कि और सरल नहीं हो सकती — केवल बेसिक CLI (Claude Code और Codex) के साथ, और प्रॉक्सी इंजीनियरिंग के कुछ मूल सिद्धांतों की समझ के साथ, मैंने अपना सबसे बड़ा क्रांतिकारी काम किया।

सबसे पहले, मैं कहना चाहूंगा कि बेस मॉडल कंपनियाँ एक ऐतिहासिक दौड़ में हैं, और यह जल्द ही धीमी नहीं होगी। प्रत्येक 'एजेंट इंटेलिजेंस' में सुधार, आपके और उनके सहयोग के तरीके को बदल देगा, क्योंकि एजेंट्स को निर्देशों का पालन करने के लिए और अधिक तैयार बनाया जा रहा है।

कुछ ही पीढ़ियों पहले, अगर आपने CLAUDE.md में लिखा होता कि "किसी भी काम से पहले READTHISBEFOREDOINGANYTHING.md पढ़ें", तो इसके 50% संभावना थी कि यह आपको "जा रे" कहकर अपना मनमाना करता। आज, यह अधिकांश निर्देशों का पालन करता है, यहां तक कि जटिल नेस्टेड निर्देशों का भी—जैसे आप कह सकते हैं "पहले A पढ़ें, फिर B पढ़ें, अगर C है तो D पढ़ें", और अधिकांश मामलों में यह खुशी से आपके साथ चलता है।

यह क्या दर्शाता है? सबसे महत्वपूर्ण सिद्धांत यह समझना है कि प्रत्येक नई पीढ़ी के एजेंट आपको यह पुनः विचार करने के लिए मजबूर कर देते हैं कि सबसे अच्छा समाधान क्या है, जिसी कारण से कम ही अधिक होता है।

जब आप कई अलग-अलग लाइब्रेरी और हारनेस का उपयोग करते हैं, तो आप खुद को एक "समाधान" में बंद कर देते हैं, लेकिन यह समस्या अगली पीढ़ी के एजेंट के सामने संभवतः मौजूद ही नहीं होगी। क्या आप जानते हैं कि एजेंट के सबसे उत्साही और सबसे अधिक उपयोग करने वाले उपयोगकर्ता कौन हैं? हाँ—वे अग्रणी कंपनियों के कर्मचारी हैं, जिनके पास असीमित टोकन बजट होता है और वे सचमुच सबसे नवीनतम मॉडल का उपयोग करते हैं। क्या आप समझते हैं कि इसका क्या मतलब है?

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

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

मैं अनुमान लगाता हूँ कि कमेंट सेक्शन में जल्द ही 「SysLS, मैंने कुछ harness का उपयोग किया, बहुत बढ़िया! मैंने एक दिन में Google को फिर से बना दिया!」 जैसे कमेंट्स दिखाई देंगे—इसके लिए मैं कहता हूँ: बधाई हो! लेकिन आप लक्षित दर्शक नहीं हैं; आप समुदाय के एक अत्यंत अल्पसंख्यक, वास्तव में एजेंट इंजीनियरिंग को समझने वाले समूह का प्रतिनिधित्व करते हैं।

सच बताऊं तो, संदर्भ ही सब कुछ है। एक हजार प्लगइन और बाहरी निर्भरताओं का उपयोग करने की समस्या यह है कि आपको 'संदर्भ विस्तार' का शिकार बन जाता है—यानी आपका प्रॉक्सी अत्यधिक सूचना से भर जाता है।

मैं Python से एक अनुमान शब्द खेल बनाऊं? आसान है। इंतजार करें, 26 सत्र पहले का यह "मेमोरी प्रबंधित करें" नोट क्या है? अहा, उपयोगकर्ता के पास 71 सत्र पहले एक स्क्रीन थी क्योंकि हमने बहुत सारे उपप्रक्रियाएँ बना दीं। हमेशा नोट लिखें? ठीक है, कोई समस्या नहीं... यह अनुमान शब्द खेल से कैसे संबंधित है?

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

तो, मैं फिर से प्रचार करता हूँ—सभी निर्भरताओं को हटा दें, और फिर...

विस्तार से विकास विवरण दें

Remember that context is everything?

Do you remember that you wanted to inject exactly the right amount of information into the agent to complete the task—no more, no less?

इसे करने का पहला तरीका है अनुसंधान और कार्यान्वयन को अलग करना। आपको अपने एजेंट से क्या मांग रहे हैं, इस बात पर अत्यधिक सटीक होना चाहिए।

अनुमानित परिणाम क्या हैं? "एक प्रमाणीकरण प्रणाली बनाएं।" एजेंट को अध्ययन करना होगा: प्रमाणीकरण प्रणाली क्या है? कौन-से विकल्प उपलब्ध हैं? उनके क्या लाभ और नुकसान हैं? अब इसे ऑनलाइन पर ऐसी बहुत सारी जानकारी ढूंढनी होगी जो इसे वास्तव में उपयोगी नहीं है, और संदर्भ में विभिन्न संभावित कार्यान्वयन विवरणों से भर जाता है। जब वास्तविक कार्यान्वयन का समय आता है, तो यह भ्रमित होने की संभावना अधिक होती है, या चुने गए कार्यान्वयन पर अनावश्यक या संबंधहीन कल्पनाएँ पैदा करता है।

विपरीत रूप से, यदि आप कहते हैं कि "JWT प्रमाणीकरण के लिए bcrypt-12 पासवर्ड हैशिंग, रिफ्रेश टोकन रोटेशन, 7 दिन का समाप्ति समय...," तो इसकी किसी अन्य विकल्प की शोध की आवश्यकता नहीं होती, क्योंकि आपको क्या चाहिए, यह स्पष्ट हो जाता है, और इस प्रकार संदर्भ को विस्तार से विवरणों से भरा जा सकता है।

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

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

Appeasement tendency design limitations

कोई भी ऐसा उत्पाद उपयोग करना नहीं चाहता जो आपकी आलोचना करता रहे, आपको बताता रहे कि आप गलत हैं, या आपके निर्देशों को पूरी तरह नज़रअंदाज़ करे। इसलिए, ये एजेंट आपके साथ सहमति बनाने की कोशिश करेंगे और आप जो करना चाहते हैं, उसे करेंगे।

अगर आप इसे हर 3 शब्दों के बाद "खुशी" जोड़ने के लिए कहें, तो यह पूरी कोशिश करेगा — अधिकांश लोग इसे समझते हैं। इसकी अनुशासनशीलता ही इसे इतना उपयोगी बनाती है। लेकिन इसकी एक बहुत दिलचस्प विशेषता है: इसका मतलब है कि अगर आप कहें "मुझे कोडबेस में एक बग ढूंढ़ने में मदद करें", तो यह एक बग ढूंढ़ लेगा — भले ही उसे "बनाना" पड़े। क्यों? क्योंकि यह आपके निर्देशों का पालन करने के लिए बहुत बहुत चाहता है!

अधिकांश लोग जल्दी ही LLM के बारे में शिकायत करते हैं कि यह भ्रम और अस्तित्वहीन चीजों को गढ़ता है, लेकिन वे अपने आप में समस्या की पहचान नहीं करते। आप इससे क्या ढूंढने को कहते हैं, वही यह प्रदान करता है—भले ही तथ्यों को थोड़ा बढ़ाना पड़े!

तो क्या करें? मुझे पता चला कि 'न्यूट्रल प्रॉम्प्ट' बहुत प्रभावी है, जिसमें एजेंट को किसी विशिष्ट परिणाम की ओर झुकाया नहीं जाता। उदाहरण के लिए, मैं कहता हूँ 'मुझे डेटाबेस में एक बग ढूंढ़ने में मदद करें', बल्कि मैं कहता हूँ 'पूरे डेटाबेस को स्कैन करें, प्रत्येक कंपोनेंट के लॉजिक का अनुसरण करने की कोशिश करें, और सभी खोजों की रिपोर्ट करें।'

ऐसे उदासीन संकेत कभी-कभी बग पाते हैं, कभी केवल कोड के कैसे काम करने का वर्णन करते हैं। लेकिन यह प्रॉक्सी को 'बग वाला' पूर्वाग्रह नहीं देता।

सम्मान करने की प्रवृत्ति को एक अन्य तरीके से सुदृढ़ करना है। मुझे पता है कि एजेंट मुझे प्रसन्न करने और मेरे निर्देशों का पालन करने की कोशिश कर रहा है, मैं इसे इस ओर या उस ओर झुका सकता हूँ।

इसलिए मैंने एक बग खोजने वाले एजेंट को डेटाबेस में सभी बग्स पहचानने के लिए कहा, और उसे बताया कि कम प्रभाव वाले बग्स को +1 अंक, कुछ प्रभाव वाले बग्स को +5 अंक, और गंभीर प्रभाव वाले बग्स को +10 अंक मिलेंगे। मुझे पता है कि यह एजेंट सभी प्रकार के बग्स (जिनमें बग नहीं होने वाले भी शामिल हैं) को पहचानने में बहुत उत्साही होगा और मुझे 104 अंक जैसा परिणाम देगा। मैं इसे सभी संभावित बग्स के सुपरसेट के रूप में देखता हूँ।

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

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

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

यह सवाल जटिल लगता है, ऐसा लगता है कि आपको AI की अग्रणी विकासों को समझने और लगातार ट्रैक करने की आवश्यकता है, लेकिन वास्तव में यह बहुत सरल है... अगर OpenAI और Claude दोनों ने इसे लागू किया है या इसे लागू करने वाली कंपनी को अधिग्रहित किया है... तो यह संभावना है कि यह कारगर है।

क्या आपने ध्यान दिया कि "कौशल (skills)" अब सर्वव्यापी हो चुके हैं और Claude और Codex के आधिकारिक दस्तावेज़ का हिस्सा हैं? क्या आपने ध्यान दिया कि OpenAI ने OpenClaw का अधिग्रहण किया है? क्या आपने ध्यान दिया कि Claude ने तुरंत स्मृति, ध्वनि और दूरस्थ कार्य की सुविधाएँ जोड़ दीं?

प्लानिंग कैसा है? क्या आप याद करते हैं कि कई लोगों ने पाया कि पहले प्लानिंग करना और फिर इम्प्लीमेंट करना वास्तव में बहुत उपयोगी है, और यह मुख्य सुविधा बन गया?

हाँ, वे उपयोगी हैं!

क्या आपको याद है कि अनंत stop-hooks बहुत उपयोगी थे, क्योंकि एजेंट लंबे समय तक चलने वाले कार्य करने से बहुत अनिच्छुक थे... फिर Codex 5.2 आने के बाद, वह आवश्यकता एक रात में समाप्त हो गई?

यही आपको जानने की आवश्यकता है... अगर कोई चीज वास्तव में महत्वपूर्ण और उपयोगी है, तो Claude और Codex इसे खुद ही लागू कर देंगे! इसलिए आपको इस बात की चिंता करने की आवश्यकता नहीं है कि क्या आपको "नया चीज" इस्तेमाल करनी चाहिए या "नया चीज" को समझना चाहिए, आपको "अपडेट बनाए रखने" की भी आवश्यकता नहीं है।

मुझे एक दया करें। अपने चुने गए CLI टूल को अनियमित रूप से अपडेट करें और नए फीचर्स को पढ़ें। यही काफी है।

कुछ लोग प्रॉक्सी का उपयोग करते समय एक बड़ा जाल पाते हैं: कभी-कभी वे ऐसे लगते हैं जैसे वे पृथ्वी पर सबसे बुद्धिमान हों, और कभी आपको यकीन नहीं होता कि आपको इसने धोखा दिया है।

क्या यह चतुर है? यह तो एक बेवकूफ है!

सबसे बड़ा अंतर यह है कि एजेंट को क्या मानने या 'खाली स्थान भरने' के लिए मजबूर किया गया है। आज, वे 'बिंदुओं को जोड़ने', 'खाली स्थान भरने' या मान लेने में अभी भी बहुत खराब हैं। जब तक वे ऐसा करते हैं, यह तुरंत स्पष्ट हो जाता है कि स्थिति स्पष्ट रूप से खराब हो गई है।

CLAUDE.md में सबसे महत्वपूर्ण नियमों में से एक यह है कि संदर्भ कैसे प्राप्त किया जाए, और इसमें निर्देश दिया गया है कि प्रत्येक बार CLAUDE.md (यानी प्रत्येक संपीड़न के बाद) को पढ़ते समय एजेंट को पहले उस नियम को पढ़ना चाहिए। संदर्भ प्राप्त करने के नियम के हिस्से के रूप में, कुछ सरल निर्देश बहुत बड़ी भूमिका निभा सकते हैं: कार्य योजना को पुनः पढ़ना, और आगे बढ़ने से पहले (कार्य) से संबंधित फ़ाइलों को पुनः पढ़ना।

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

यह अक्सर बहुत निराशाजनक परिणामों का कारण बनता है: एजेंट अंततः कुछ स्टंट्स को लागू करके काम खत्म कर देता है।

परीक्षण एजेंट के लिए एक बहुत अच्छा मील का पत्थर है, क्योंकि परीक्षण निर्धारणात्मक होते हैं, और आप बहुत स्पष्ट अपेक्षाएँ निर्धारित कर सकते हैं। जब तक ये X परीक्षण सफल न हो जाएँ, आपका कार्य पूरा नहीं होगा; और आप परीक्षण में परिवर्तन नहीं कर सकते।

फिर आपको केवल परीक्षण की समीक्षा करनी है, और जब सभी परीक्षण सफल हो जाएँ, तो आप आराम से महसूस कर सकते हैं। आप इसे स्वचालित भी कर सकते हैं, लेकिन मुख्य बात यह है—याद रखें कि 'कार्य का समापन' मनुष्यों के लिए प्राकृतिक है, लेकिन एजेंट के लिए नहीं।

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

यह आपको अपने इच्छित डिज़ाइन की ओर एजेंट को दोहराने की अनुमति देता है, बिना चिंता किए कि यह पहले प्रयास के बाद रुक जाएगा!

इसका प्राकृतिक विस्तार एजेंट के साथ एक 'करार' बनाना और इसे नियमों में एम्बेड करना है। उदाहरण के लिए, यह `{TASK}CONTRACT.md` यह निर्दिष्ट करता है कि आपको सत्र समाप्त करने से पहले क्या करना होगा। `{TASK}CONTRACT.md` में, आप परीक्षण, स्क्रीनशॉट और अन्य प्रमाणीकरण निर्दिष्ट करेंगे जो आपको अपना कार्य समाप्त करने की अनुमति देने से पहले पूरा करना होगा!

एक अक्सर पूछा जाने वाला प्रश्न यह है कि लोग अपने एजेंट को 24 घंटे चलाएं और इसकी सुनिश्चित करें कि यह विचलित न हो?

यहाँ एक बहुत सरल तरीका है। एक stop-hook बनाएँ, जो `{TASK}_CONTRACT.md` के सभी भाग पूरे न होने तक एजेंट की सत्र समाप्ति को रोके।

अगर आपके पास 100 ऐसे स्पष्ट रूप से परिभाषित कॉन्ट्रैक्ट हैं जिनमें आप जो सामग्री बनाना चाहते हैं वह शामिल है, तो stop-hook एजेंट को बंद होने से रोक देगा, जब तक कि सभी 100 कॉन्ट्रैक्ट पूरे न हो जाएं, जिसमें सभी चलाए जाने वाले परीक्षण और पुष्टिकरण शामिल हैं!

पेशेवर सुझाव: मुझे पता चला है कि लंबे समय तक चलने वाली 24 घंटे की सत्रें «कार्य करने» के लिए अधिकतम रूप से कुशल नहीं होती हैं। इसका एक कारण यह है कि इस तरह की प्रक्रिया संरचनात्मक रूप से संदर्भ विस्तार को अनिवार्य बना देती है, क्योंकि असंबंधित कॉन्ट्रैक्ट्स का संदर्भ एक ही सत्र में आ जाता है!

इसलिए, मैं इसे करने की सलाह नहीं देता।

यहाँ एक बेहतर एजेंट स्वचालन तरीका है—प्रत्येक कॉन्ट्रैक्ट के लिए एक नया सत्र खोलें। जब भी आप कुछ करने की आवश्यकता हो, तो कॉन्ट्रैक्ट बनाएं।

एक ऑर्केस्ट्रेशन लेयर बनाएं जो जब "कुछ करने की आवश्यकता हो" तो नया कॉन्ट्रैक्ट बनाए और उस कॉन्ट्रैक्ट को संभालने के लिए नया सत्र बनाए।

यह आपके एजेंट अनुभव को पूरी तरह से बदल देगा।

क्या आप अपने एक अडमिनिस्ट्रेटिव असिस्टेंट को भर्ती करते हैं और उम्मीद करते हैं कि वह पहले दिन से ही आपकी शेड्यूल जानता होगा? या आप कैफे कैसे पीते हैं? क्या आप रात 6 बजे डिनर करते हैं, 8 बजे नहीं? स्पष्ट रूप से नहीं। आप समय के साथ अपनी पसंदें धीरे-धीरे बनाते हैं।

एजेंट के लिए भी ऐसा ही है। सबसे सरल कॉन्फ़िगरेशन से शुरू करें, जटिल संरचनाओं या हार्नेस को भूल जाएं, और बेसिक CLI को एक मौका दें।

फिर, अपनी पसंद को कदम दर कदम जोड़ें। कैसे?

नियम

अगर आप चाहते हैं कि एजेंट कुछ न करे, तो इसे नियम के रूप में लिखें। फिर CLAUDE.md में एजेंट को इस नियम के बारे में बताएं। उदाहरण के लिए: 'कोड लिखने से पहले, `coding-rules.md` पढ़ें।' नियम एक-दूसरे में निहित हो सकते हैं, और नियम शर्तात्मक हो सकते हैं! अगर आप कोड लिख रहे हैं, तो `coding-rules.md` पढ़ें; अगर आप परीक्षण लिख रहे हैं, तो `coding-test-rules.md` पढ़ें। अगर आपका परीक्षण विफल हो रहा है, तो `coding-test-failing-rules.md` पढ़ें। आप एजेंट के लिए कोई भी तर्कसंगत शाखा वाले नियम बना सकते हैं, और Claude (और Codex) CLAUDE.md में स्पष्ट निर्देश होने पर उनका पालन करने के लिए संतुष्ट होंगे।

वास्तव में, यह मैंने दी गई पहली व्यावहारिक सलाह है: अपनी CLAUDE.md को एक तार्किक, नेस्टेड डायरेक्टरी के रूप में मानें, जो विशिष्ट परिदृश्यों और परिणामों के अनुसार संदर्भ कहाँ ढूंढना है, इसकी जानकारी देती है। इसे इतना संक्षिप्त रखें कि केवल 'किस स्थिति में कहाँ संदर्भ ढूंढें' का IF-ELSE तर्क ही शामिल हो।

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

कौशल

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

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

आप एजेंट को इस कौशल के अस्तित्व के बारे में कैसे बताते हैं? हाँ! आप CLAUDE.md में लिखते हैं कि जब आपको इस स्थिति का सामना करना पड़े और आपको इस बात को संभालना हो, तो इस `SKILL.md` को पढ़ें।

प्रोसेसिंग नियम और कौशल

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

जब आप ऐसा करना शुरू कर देंगे, तो आपका एजेंट जादू की तरह महसूस होगा। यह आपके चाहने के अनुसार काम करेगा। और फिर आप अंततः एजेंट इंजीनियरिंग को समझने का अहसास करेंगे।

फिर...

आप देखेंगे कि प्रदर्शन फिर से गिरना शुरू हो गया है।

क्या हो रहा है?!

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

क्या करें?

क्लीनअप। अपने एजेंट को 「एक स्पा करवाएँ」, नियमों और कौशल को एकीकृत करें, और अपडेटेड प्राथमिकताओं को बताकर विरोधाभासों को दूर करें।

फिर यह फिर से जादू की तरह लगेगा।

यही सब है। यही वास्तविक रहस्य है। सरल रहें, नियमों और कौशल का उपयोग करें, CLAUDE.md को सूची के रूप में मानें, और उनके संदर्भ और डिजाइन सीमाओं का ध्यानपूर्वक ध्यान रखें।

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

इसलिए सावधान रहें... और अच्छा मज़ा लें!

वास्तव में मज़ा आता है कि भविष्य के खिलौने का उपयोग करते हुए (जबकि स्पष्ट रूप से इसका उपयोग गंभीर कार्यों के लिए किया जा रहा है)!