ऑटोनॉमस AI एजेंट: उसे घंटों तक अकेले काम कैसे करने दें और कचरा न मिले

ऑटोनॉमस AI एजेंट क्या है और सामान्य अनुरोध से कैसे अलग है

सामान्य रूप से एजेंट के साथ काम चरण-दर-चरण होता है: आप प्रॉम्प्ट लिखते हैं, एजेंट एक कदम उठाता है, आप परिणाम देखते हैं और तय करते हैं कि आगे क्या करना है। ऑटोनॉमस AI एजेंट एक चक्र में चलता है। आप एक बार बताते हैं कि अंतिम अवस्था कैसी दिखनी चाहिए, और उसके बाद एजेंट खुद दोहराता है: «करो — जाँचो — सुधारो», जब तक लक्ष्य पूरा न हो या बजट खत्म न हो जाए। शुरू करने के बाद आप वहाँ से हट सकते हैं।

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

एक ज़रूरी बात: चक्र हार्नेस की जगह नहीं लेता। हार्नेस एक रन को भरोसेमंद बनाता है, चक्र रनों को लगातार चलाता है। खराब हार्नेस पर चक्र बस तेज़ी से कचरा बनाता है।

क्या कार्य ऑटोनॉमस एजेंट के लिए उपयुक्त है

पहला सवाल यह है कि क्या काम की कोई अंतिम रेखा है जिसे मशीन जाँच सके। «tests/payments में सारे टेस्ट पास होते हैं», «सूची की सारी फ़ीचर passing स्थिति में हैं», «मेट्रिक बेसलाइन से बढ़ी है» — ये उपयुक्त हैं। «कोड को बेहतर बनाओ» या «भुगतान में सुधार करते रहो» उपयुक्त नहीं हैं: ऐसे लक्ष्य का कोई अंत नहीं होता, और चक्र बजट खत्म होने तक घूमता रहेगा।

चार तरह के चक्र अलग समझना उपयोगी है:

• चरण-दर-चरण — हर प्रॉम्प्ट आप देते हैं; यह सामान्य इंटरैक्टिव काम है।
• लक्ष्य-आधारित — आप लक्ष्य देते हैं, रुकने का फ़ैसला स्वतंत्र जाँच या बजट करता है। घंटों चलने वाला ऑटोनॉमस एजेंट यही है।
• समय-आधारित — शेड्यूल पर चलता है (जैसे सुबह CI में गिरी बिल्ड्स का विश्लेषण), रोकना आप हाथ से करते हैं।
• घटना-आधारित — बाहरी ट्रिगर (नया issue, गिरा हुआ deploy) से चलता है, घटना का निपटारा या दोहराव की सीमा उसे रोकती है।

आम गलती है समय-आधारित चक्र को लक्ष्य-आधारित समझ लेना: «हर 10 मिनट में भुगतान का काम जारी रखो»। शेड्यूल पर चलने वाला चक्र हर बार निर्देश को शून्य से शुरू करता है और उसे नहीं पता होता कि पहले क्या हो चुका है। जिस कार्य का अंत है, उसे प्रगति की स्मृति वाले लक्ष्य-आधारित चक्र की ज़रूरत है।

चरण 1. सैंडबॉक्स: एजेंट कहाँ गलती कर सकता है

बिना निगरानी के चलने वाला एजेंट देर-सबेर कुछ गलत करेगा: फ़ाइल हटाएगा, माइग्रेशन दोबारा लिखेगा, कोई भारी कमांड चलाएगा। इसलिए सवाल यह नहीं है कि «उसे गलती न करने कैसे दें», बल्कि यह है कि «गलती की कीमत शून्य कैसे रहे»।

• अलग कार्य-प्रति। git worktree एजेंट को उसी रिपॉज़िटरी के ऊपर अपनी डायरेक्टरी और अपनी ब्रांच देता है। मुख्य ब्रांच अछूती रहती है, कई एजेंट एक-दूसरे में दखल नहीं देते, और असफल रन एक कमांड से हट जाता है।
• कंटेनर या वर्चुअल मशीन। अगर एजेंट को कमांड पर पूरी पहुँच चाहिए, तो उसे ऐसे कंटेनर में चलाएँ जहाँ होम डायरेक्टरी, कुंजियाँ और प्रोडक्शन डेटाबेस तक पहुँच न हो।
• परीक्षण डेटा। स्थानीय डेटाबेस, भुगतान प्रणालियों के सैंडबॉक्स, नकली कुंजियाँ। एजेंट के वातावरण में एक भी प्रोडक्शन सीक्रेट नहीं होना चाहिए।

# ऑटोनॉमस रन के लिए अपनी ब्रांच और डायरेक्टरी
git worktree add ../shop-agent -b agent/f03-refunds

# रन के बाद: परिणाम देखें या हटा दें
git -C ../shop-agent log --oneline main..
git worktree remove ../shop-agent

चरण 2. अनुमतियाँ: कार्य के लिए ज़रूरी न्यूनतम

जितनी देर एजेंट अकेले चलेगा, उसकी अनुमतियाँ उतनी ही संकरी होनी चाहिए। Claude Code में अनुमतियाँ settings.json में सेट होती हैं (टूल्स और कमांड के लिए allow और deny सूचियाँ): कार्य के लिए जो ज़रूरी है उसे साफ़ अनुमति दें — टेस्ट चलाना, linter, वर्किंग कॉपी में फ़ाइल संपादन — और खतरनाक चीज़ों पर रोक लगाएँ: मुख्य ब्रांच में push, सीक्रेट्स के साथ काम, और नेटवर्क कमांड, अगर वे ज़रूरी न हों।

ऐसा मोड, जिसमें एजेंट बिना पुष्टि के सब कुछ करता है, केवल अलग सैंडबॉक्स के भीतर ठीक है, जहाँ सबसे बुरा परिणाम फेंके गए कंटेनर के रूप में आता है। ऐसे मोड को उस कंप्यूटर पर न चलाएँ जहाँ आपकी कुंजियाँ और रिपॉज़िटरी हैं।

जो रोक किसी भी हालत में टूटनी नहीं चाहिए, उसे टेक्स्ट से नहीं, तंत्र से लागू करें। निर्देश में लिखा «migrations/ को मत छुओ» सिर्फ़ इच्छा है; उस डायरेक्टरी में संपादन रोकने वाला hook, या फ़ाइल सिस्टम की अनुमतियाँ, गारंटी हैं।

चरण 3. लक्ष्य, जाँच, रुकना — शुरू करने से पहले तीन पंक्तियाँ

सबसे सरल काम करने वाला चक्र तीन चीज़ों पर टिका है, और उन्हें शुरू करने से पहले लिख लेना चाहिए, बीच में नहीं:

1. लक्ष्य — अंतिम अवस्था कैसी दिखती है।
2. सत्यापन — यह जानने का मशीन से जाँच योग्य तरीका कि लक्ष्य मिल गया: कोई कमांड जो सफलता या त्रुटि लौटाती है।
3. रुकने की शर्त — प्रयासों, समय या पैसे की सीमा, जिसके बाद चक्र रुक जाता है, भले ही लक्ष्य न मिला हो।

यह एक अलग methodology फ़ाइल में रखना सुविधाजनक है, जिसे केवल इंसान बदलता है। भुगतान बैकएंड का उदाहरण:

# program.md — ऑटोनॉमस रन की methodology

## लक्ष्य
.agent/feature_list.json की सारी फ़ीचर passing स्थिति में हों।

## मेट्रिक
passing फ़ीचर की संख्या। यह केवल बढ़ती है। रिग्रेशन = तुरंत रोलबैक।

## सीमाएँ
- एक समय में एक फ़ीचर पर काम।
- migrations/ और infra/ न बदलें।
- लॉग में दर्ज किए बिना dependencies न बदलें।

## कार्य का क्रम
1. पहली फ़ीचर लें जो passing नहीं है।
2. लागू करें, pytest और linter चलाएँ।
3. हरा हो तो commit और .agent/progress.md में दर्ज करें। लाल हो तो ठीक करें।

## रुकना और आगे भेजना
- एक फ़ीचर पर 3 असफल प्रयास — उसे blocked चिह्नित करें और अगली पर जाएँ।
- सारी बची फ़ीचर blocked हों — रुकें और रिपोर्ट लिखें।
- ग्राहकों के पैसे, एक्सेस अधिकार या डेटा हटाने से जुड़ा कोई भी काम — न करें, इंसान को सौंपें।

चरण 4. जाँच-सुधार चक्र और डिस्क पर स्मृति

context window लंबे काम के दौरान नहीं टिकती: वह भर जाती है, सिकुड़ती है, सत्र फिर से शुरू होता है। इसलिए प्रगति एजेंट के «दिमाग» में नहीं, फ़ाइलों में रहनी चाहिए: स्थिति के साथ कार्यों की सूची, यह दर्ज करने वाला लॉग कि क्या हुआ और क्या काम नहीं आया, और git इतिहास।

एक अच्छा मॉडल है «ratchet, जो केवल आगे बढ़ता है»। Andrej Karpathy की परियोजना autoresearch में एजेंट रात भर सैकड़ों ML प्रयोग करता है। हर दौर में: methodology पढ़ो, एक परिकल्पना बनाओ, बदलाव करो, तय समय-बजट के साथ प्रयोग चलाओ, बेसलाइन से तुलना करो। सुधार हुआ तो commit, नहीं हुआ तो rollback। नतीजा लॉग में लिखा जाता है, फिर अगली परिकल्पना।

इस योजना से दो फ़ैसले लेने लायक हैं:

• हर प्रयास के लिए तय बजट। प्रयास आपस में तुलनीय बनते हैं, और एक असफल परिकल्पना पूरी रात नहीं खाती।
• मुख्य ब्रांच में केवल सुधार। जो काम नहीं आया, वह वापस लिया जाता है, बगल में ढेर नहीं लगता। git log सुबह आसानी से पढ़े जा सकने वाला सत्यापित लॉग बन जाता है।

इसी योजना में फ़ाइलों के हिसाब से भूमिकाएँ भी बँटी हैं: इन्फ्रास्ट्रक्चर और मूल्यांकन को कोई नहीं बदलता, प्रयोग का कोड केवल एजेंट बदलता है, methodology केवल इंसान। एजेंट माप का तरीका बदलकर नतीजा «सुधार» नहीं सकता।

चरण 5. कौन तय करे कि काम तैयार है: अलग मूल्यांकक

जब बीच में इंसान नहीं है, तो एजेंट का खुद का मूल्यांकन ही एकमात्र ब्रेक बन जाता है, और यह ब्रेक काम नहीं करता। जिस एजेंट ने अभी कोड लिखा है, वह उसे सही मानने को तैयार रहता है: उसके तर्क उसके सामने हैं, और वह «जानता» है कि उसका इरादा क्या था।

जनरेटर और मूल्यांकक को अलग रखने के नियम:

• काम करने वाला सत्र खुद मूल्यांकन न करे। Claude Code में इसके लिए subagents सुविधाजनक हैं: हर एक का अपना context होता है।
• मूल्यांकक को साफ़ context मिले: आवश्यकता, diff और जाँच के परिणाम — और निष्पादक के तर्कों में से कुछ नहीं।
• संभव हो तो मूल्यांकक दूसरा model हो, या कम से कम दूसरी भूमिका वाला अलग प्रॉम्प्ट।
• फ़ैसला rubric के आधार पर हो, और हर बिंदु अपने सबूत की ओर इशारा करे: टेस्ट की पंक्ति, कमांड का आउटपुट, diff में जगह।

मशीनी जाँच फिर भी प्राथमिक है। मूल्यांकक उस चीज़ के लिए है जिसे टेस्ट नहीं पकड़ते: आवश्यकता गलत समझी गई, टेस्ट को कोड के हिसाब से ढाला गया, या बदलाव कार्य की सीमा से बाहर गया।

रुकने के मानदंड: कब एजेंट को हार माननी चाहिए

रुकने की शर्त के बिना चक्र एक ही जगह घूमता रहेगा — यह बस समय की बात है। न्यूनतम सेट यह है:

प्रगति को प्रयासों की संख्या से नहीं, सार से जाँचें: «40 दौर हो गए» कुछ नहीं बताता, «पास होने वाली फ़ीचर 5 से बढ़कर 9 हुईं» बताता है। अगर कार्य अटका है, तो उसे फिर से चक्र में डालने के बजाय इंसान को सौंपना सही है।

ऑटोनॉमस एजेंट के जोखिम जो तुरंत नहीं दिखते

स्पष्ट जोखिम — हटाई गई फ़ाइलें और टूटी बिल्ड — सैंडबॉक्स और अनुमतियों से बंद हो जाते हैं। ज़्यादा खतरनाक वे चुपचाप जमा होने वाली लागतें हैं, जो हफ़्तों में इकट्ठा होती हैं:

• सत्यापन का कर्ज़। «ठीक लग रहा है» की जगह «मशीन ने पुष्टि की»। इसका इलाज केवल मशीन से जाँच योग्य रुकने की शर्तें हैं, बिना अपवाद के।
• समझ का क्षरण। आप अपने ही कोड को कम समझने लगते हैं। इलाज: diff पढ़ना अनिवार्य करें — चक्र की गति आपकी पढ़ने की गति से तेज़ न हो।
• संज्ञानात्मक समर्पण। नतीजे पर आपकी अपनी राय नहीं रहती और सब कुछ जैसे-का-तैसे स्वीकार होने लगता है। ईमानदारी से गिनें कि कितनी बार «बाद में देख लूँगा» कहा और नहीं देखा।
• context का फूलना। लंबा रन इतिहास जमा करता है, और हर अगला कदम महँगा और कमज़ोर होता जाता है। context का संक्षेपण और बाहरी स्मृति पहले चक्र से चाहिए, तब नहीं जब सब बिगड़ने लगे।

पहला ऑटोनॉमस चक्र एक शाम में कैसे चलाएँ

«एजेंट खुद काम ढूँढे और करे» से शुरू न करें। ऑटोनॉमी सीढ़ी-दर-सीढ़ी बढ़ती है: पहले एक कार्य, जिसका लक्ष्य और रुकने की शर्त हो; फिर शेड्यूल पर एक स्वचालन; फिर अलग-अलग सैंडबॉक्स कॉपी में निष्पादक और जाँचने वाला; और उसके बाद ही ऐसे चक्र जो खुद काम ढूँढते हैं और समानांतर चलते हैं।

1. ऐसा काम चुनें जो आप हफ़्ते में कम से कम दो बार हाथ से करते हैं और जिसका जाँच योग्य अंत है।
2. लक्ष्य, सत्यापन और रुकने की शर्त लिखें — तीन पंक्तियाँ।
3. अलग worktree बनाएँ और अनुमतियाँ सेट करें: टेस्ट और फ़ाइल संपादन की अनुमति है, push और सीक्रेट्स की नहीं।
4. प्रगति की फ़ाइल बनाएँ और एजेंट से कहें कि हर दौर के बाद उसे अपडेट करे।
5. भूमिकाएँ अलग करें: निष्पादक लिखता है, जाँचने वाला अलग context में diff का मूल्यांकन करता है।
6. कुल सीमा तय करें और पहली बार नतीजा एक घंटे बाद जाँचें, सुबह नहीं।

निष्कर्ष

ऑटोनॉमस AI एजेंट उतना ही भरोसेमंद है जितनी उसकी सीमाएँ: ऐसा सैंडबॉक्स जहाँ गलती की कीमत न हो, न्यूनतम अनुमतियाँ, मशीन से जाँच योग्य लक्ष्य, डिस्क पर स्मृति, अलग मूल्यांकक और सख्त रुकने की शर्तें, जिनमें इंसान तक एस्केलेशन हो। इसके बिना लंबा रन समय की बचत नहीं, बल्कि बाद में होने वाली सफ़ाई का स्थगित काम है। ऐसा चक्र एक असली प्रोजेक्ट पर, program.md से लेकर स्वतंत्र मूल्यांकक तक, harness engineering के कोर्स में व्यावहारिक रूप से बनाया जाता है।