एजेंट विकास उपकरणों (Agent Development Tools) को अपने कंप्यूटर पर कितनी अनुमति दी जाए?

वह युग समाप्त हो गया है जब एडिटर आपके लिए केवल कोड लिखते थे। अब, क्लाउड कोड (Claude Code) जैसे एजेंट सीधे टर्मिनल खोलते हैं, फ़ाइल सिस्टम को स्कैन करते हैं और कोड को संशोधित करते हैं। यह सुविधाजनक है, लेकिन साथ ही थोड़ा डरावना भी है। एक सिंगल प्रॉम्प्ट इंजेक्शन आपकी .env फ़ाइल या SSH कीज़ को बाहर लीक कर सकता है। एजेंटों को स्वायत्तता देना आवश्यक है, लेकिन उन्हें अपनी सीमा पार करने से रोकने के लिए विशिष्ट नियंत्रण विधियों की आवश्यकता है।

प्रोजेक्ट रूट में एजेंटों के लिए एक संविधान (Constitution) बनाना

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

1. रूट में CLAUDE.md या .agent-rules फ़ाइल बनाएँ।
2. फ़ाइल के अंदर प्रतिबंधित पथों (paths) को स्पष्ट रूप से निर्दिष्ट करें। .env, ~/.ssh, ~/.aws/credentials जैसे पथों के लिए deny नियम जोड़ें ताकि एजेंट उन्हें देख भी न सकें।
3. एजेंट को चलाते समय केवल आवश्यक सुविधाओं को अनुमति देने के लिए --allowedTools विकल्प का उपयोग करें। यह Bash, Read, या Write जैसे न्यूनतम आवश्यक उपकरणों को ही सक्रिय करने का एक तरीका है।

क्लाउड कोड के ऑथोराइजेशन मोड के बीच, Default मोड का उपयोग करना जो सभी राइट (write) ऑपरेशन्स के लिए उपयोगकर्ता की स्वीकृति मांगता है, सोर्स कोड लीक के जोखिम को भौतिक रूप से रोक सकता है। एक साधारण कॉन्फ़िगरेशन फ़ाइल एजेंट को आपकी अनुमति के बिना पर्यावरण चर (environment variables) को बाहर भेजने से रोकने के लिए पर्याप्त है।

लूप में फंसे एजेंट को आपका बटुआ खाली करने से कैसे रोकें

एजेंट-केंद्रित उपकरण अपनी योजनाएँ खुद बनाते और निष्पादित करते हैं। समस्या तब आती है जब वे तार्किक त्रुटि में फंस जाते हैं। यदि कोई एजेंट समाधान खोजने में असमर्थ है और अंतहीन लूप में बार-बार API कॉल करता है, तो बिल तुरंत दर्जनों डॉलर तक पहुँच सकता है। एंथ्रोपिक (Anthropic) के शोध डेटा के अनुसार, प्रॉम्प्ट में स्पष्ट निकास मानदंड (Exit Criteria) सेट करने मात्र से निष्पादन समय में 62% तक की कटौती की जा सकती है।

लागत में उछाल को रोकने के लिए, आपको सीधे प्रॉम्प्ट के भीतर एक 'सर्किट ब्रेकर' डिजाइन करना होगा:

• प्रयासों की सीमा: निर्देश के नीचे एक बाधा जोड़ें: "यदि 5 प्रयासों के बाद भी समस्या हल नहीं होती है, तो तुरंत रुकें और विफलता के कारण की रिपोर्ट करें।"
• वस्तुनिष्ठ सफलता मानदंड: "कोड अच्छा दिखने पर समाप्त करें" जैसे व्यक्तिपरक निर्देश सबसे खराब होते हैं। इसके बजाय, npm test या विशिष्ट यूनिट परीक्षणों को पास करने को समाप्ति के पूर्ण मानदंड के रूप में निर्दिष्ट करें।
• संदर्भ सीमा (Context Limitation): .cursorrules फ़ाइल में ग्लोब (Glob) पैटर्न का उपयोग करके एजेंट को केवल विशिष्ट डायरेक्टरी नियमों जैसे src/api/**/* को पढ़ने के लिए सीमित करें, जो अनावश्यक टोकन बर्बादी को रोकता है।

इन एक्जिट गेट्स (exit gates) को सेट करके, आप अस्पष्ट निर्देशों के कारण होने वाले टोकन उपभोग को नियंत्रित कर सकते हैं और मासिक औसत API लागत को 40% से अधिक बचा सकते हैं।

मुख्य शाखा (Main Branch) को दूषित न करने वाला एक पृथक वर्कफ़्लो

एजेंटों द्वारा सीधे स्थानीय फ़ाइलों को संशोधित करना तेज़ है लेकिन जोखिम भरा है। ऐसा इसलिए है क्योंकि असत्यापित कोड मुख्य शाखा को खराब कर सकता है। शॉपिफाई (Shopify) इंजीनियरिंग टीम ने अपना स्वयं का एजेंट टूल 'साइडकिक' (Sidekick) संचालित करते हुए एक ऐसी पद्धति अपनाई है जहाँ आउटपुट को एक अलग मॉडल द्वारा क्रॉस-वेरिफाई किया जाता है। हमें एजेंटों के लिए एक समर्पित कार्यक्षेत्र (workspace) भी अलग करना चाहिए।

सबसे स्वच्छ तरीका git worktree का उपयोग करना है। एजेंट सत्र के लिए एक स्वतंत्र डायरेक्टरी और शाखा बनाएँ और उन्हें कार्य सौंपें। कार्य पूरा होने के बाद, उनसे git diff चलाकर परिवर्तनों की सारांश रिपोर्ट देने के लिए कहें, और Playwright या Vitest जैसे उपकरणों के साथ स्वचालित रूप से यूनिट परीक्षण चलाएँ। इस प्रक्रिया के माध्यम से, आप मैन्युअल समीक्षा समय को 70% तक कम कर सकते हैं और केवल सत्यापित कोड को ही मुख्य शाखा में मिला सकते हैं।

एजेंट की गति में बाधा डालने वाली IDE सेटिंग्स को संशोधित करना

एजेंट के कोड लिखने की गति मानव टाइपिंग की तुलना में बहुत तेज़ होती है। इस समय, यदि VS Code की editor.formatOnSave सुविधा चालू है, तो एजेंट द्वारा कोड लिखते समय फ़ाइल स्वरूप जबरन बदल जाता है, जिससे टेक्स्ट मिलान त्रुटियां (text matching errors) होती हैं। यह उपकरण का अपने ही पैरों पर गिर जाने जैसा है।

इसके अलावा, एजेंटों द्वारा चलाए जाने वाले गैर-संवादात्मक शेल (non-interactive shells) अक्सर .zshrc में सेट पर्यावरण चरों को नहीं पढ़ पाते हैं, जिससे उपकरण विफल हो जाते हैं।

1. सहयोगी प्रोजेक्ट्स की .vscode/settings.json में editor.formatOnSave को false पर सेट करके बंद करें।
2. PATH या API कीज़ की सेटिंग्स को .zshrc के बजाय .zshenv फ़ाइल में ले जाना चाहिए, जो शेल निष्पादन विधि की परवाह किए बिना लोड होती है।
3. इसके बजाय, Husky का उपयोग करके प्री-कमिट हुक कॉन्फ़िगर करें ताकि लिंटर (linter) और फॉर्मेटर केवल तभी चलें जब एजेंट अपना काम पूरा करने के बाद कमिट करे।

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

सेटिंग वर्गीकरण	फ़ाइल नाम	अनुशंसित सेटिंग सामग्री	एजेंट दृश्यता
वैश्विक पर्यावरण चर	.zshenv	PATH, API_KEY, SDK पथ	सभी सत्रों में लोड किया गया
संवादात्मक सेटिंग्स	.zshrc	alias, prompt, theme	एजेंट निष्पादन के दौरान अनदेखा किया जा सकता है
लॉगिन सेटिंग्स	.zprofile	सिस्टम-व्यापी आरंभीकरण स्क्रिप्ट	केवल लॉगिन शेल में मान्य