AI एजेंट को भरोसेमंद कैसे बनाएँ: मापने से लेकर स्वायत्त काम तक का चरण-दर-चरण मार्ग

सशक्त मॉडल होने पर भी एजेंट भरोसेमंद क्यों नहीं होता

भरोसेमंदी पूरे सिस्टम का गुण है, केवल मॉडल का नहीं। लंबा काम दर्जनों कदमों से बनता है, और गलतियाँ जमा होती हैं: अगर हर कदम 95% सही है, तो दस कदमों की शृंखला बिना एक भी गलती के लगभग 60% रनों में पूरी होती है (0.95^10 ≈ 0.60), और पचास कदमों की शृंखला में दस प्रतिशत से भी कम। मॉडल की सटीकता आप नहीं बढ़ा सकते, लेकिन गलती को उसी कदम पर पकड़ना और उसे सस्ता बनाना आपके हाथ में है। यही हार्नेस का काम है: निर्देश, उपकरण, वातावरण, स्थिति और फ़ीडबैक मॉडल के चारों ओर।

नीचे की योजना "अनुमान" से मापी जा सकने वाली भरोसेमंदी और फिर स्वायत्त काम तक ले जाती है। कदम प्रभाव के क्रम में हैं: हर अगला कदम पिछले पर टिका है।

चरण 1. अनुमान से मूल्यांकन बंद करें

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

| तारीख | काम              | क्या हुआ                       | हिस्सा         |
|-------|------------------|--------------------------------|----------------|
| 10.10 | कार्ट में छूट    | "तैयार", e2e नहीं चलाया       | फ़ीडबैक        |
| 10.10 | payment webhook  | database नहीं उठा सका          | वातावरण        |
| 11.10 | API refactoring  | ख़ारिज किया हुआ समाधान दोहराया | स्थिति         |

"हिस्सा" वाला कॉलम सबसे अहम है। एक हफ़्ते में दिखेगा कि अड़चन कहाँ है, और तब आप केवल उसी पर काम करेंगे, हर चीज़ पर नहीं। भरोसेमंदी को केवल सफल रनों से मापना गलती है: असफलताओं का लॉग ही बताता है कि एजेंट कहाँ गिरता है।

चरण 2. दो मेट्रिक्स लाएँ: MTBF और MTTR

भरोसेमंदी दो संख्याओं में मापी जाती है। MTBF (विफलताओं के बीच का औसत समय) एजेंट के लिए यह है कि वह कितने कदम बिना अटके चलता है। MTTR (मरम्मत का औसत समय) यह है कि विफलता के बाद वापस काम करने की स्थिति तक पहुँचने में कितना समय लगता है। उपलब्धता दोनों से बढ़ती है: पहली संख्या बढ़े या दूसरी घटे।

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

चरण 3. गलती को सस्ता बनाएँ

एजेंट को स्वायत्त काम तब दिया जाए जब उसकी गलती बिना बदलाव के लिए लगभग मुफ़्त हो, न कि तब जब वह गलती करना बंद कर दे। इसके लिए तीन चीज़ें चाहिए:

• छोटे, साफ़ commits — किसी भी बदलाव को एक कमांड से वापस लिया जा सके।
• अलगाव — एजेंट अलग branch या कार्यकारी प्रति में काम करे, जैसे git worktree से, और production तक पहुँच के बिना sandbox में।
• वातावरण रीसेट की स्क्रिप्ट — database, dependencies और services एक कमांड से शुरुआती स्थिति में लौटें।

git worktree add ../shop-agent -b agent/discount
cd ../shop-agent
make reset   # database दोबारा बनाएँ, migrations लागू करें, fixtures लोड करें

घड़ी से मापें कि पूरी वापसी में कितना समय लगता है। यही आपका MTTR है। साथ ही नुक़सान का दायरा सीमित करें: एक काम में बदलावों के आकार की सीमा और उसके क्षेत्र के बाहर की फ़ाइलें बदलने पर रोक।

चरण 4. फ़ीडबैक लूप बंद करें

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

• Fail-fast: जाँच पहली गलती पर साफ़ संदेश के साथ रुके, सौ पंक्तियों का शोर न दे।
• हर बदलाव के बाद तेज़ जाँचें: linter और type checking एजेंट के hook से।
• अतिरिक्त सुरक्षा: उसी गुण की दूसरी स्वतंत्र जाँच, जैसे unit tests के ऊपर E2E परिदृश्य। हरे unit tests यह साबित नहीं करते कि उपयोगकर्ता के लिए फ़ीचर काम करता है।

"तैयार" की शर्त को जाँचे जा सकने वाली शर्त के रूप में लिखें: "promo code वाला order flow का E2E परिदृश्य पास होता है", न कि "छूट लागू की गई"।

चरण 5. याददाश्त को फ़ाइलों में रखें

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

लंबी संक्षिप्त बातचीत निरंतरता का भ्रम देती है, पर सबसे क़ीमती चीज़ खो देती है: ख़ारिज किए गए फ़ैसलों के कारण। सोच-समझकर सत्र रीसेट करना, पूरी लिखित स्थिति के साथ, आम तौर पर सस्ता पड़ता है।

चरण 6. एक समय में एक काम

लिटिल का नियम: एक साथ चलते कामों की संख्या बराबर होती है आने की दर गुणा काम का प्रणाली में समय। निश्चित क्षमता पर समानांतर काम गति नहीं बढ़ाते, बल्कि हर काम को लंबा खींच देते हैं। एजेंट के लिए यह और भी सख़्त है: तीन फ़ीचर का मतलब है एक ही context window में तीन डोमेन-मॉडल।

• WIP=1 रखें: एक फ़ीचर तब तक, जब तक वह जाँचे हुए परिणाम तक न पहुँचे।
• काम छोटे टुकड़ों में बाँटें: एक जाँचने योग्य उपयोगकर्ता-क्षमता, 1 से 3 फ़ाइलें, जाँच एक मिनट से कम।
• BACKLOG.md रखें — "साथ में" वाली बातों के लिए वाल्व। कोई पड़ोसी कमी दिखे तो बैकलॉग में एक पंक्ति, अपने-आप बदलाव नहीं।

चरण 7. काम करने वाले और जाँचने वाले को अलग करें

एजेंट का ख़ुद का मूल्यांकन कमज़ोर ब्रेक है: जो सत्र कोड लिख रहा था, वही उसे सही मानने को झुकता है। परिणाम का मूल्यांकन एक अलग subagent या अलग सत्र करे, जो केवल आवश्यकता, diff और जाँच के परिणाम देखे, काम करने वाले का तर्क नहीं। जज का फ़ैसला मशीन की जाँचों पर टिका हो, न कि "ठीक लगता है" पर।

चरण 8. एजेंट को स्वायत्त चक्र में छोड़ें

हार्नेस एक रन को भरोसेमंद बनाता है, चक्र रनों की श्रृंखला को स्वायत्त बनाता है। ख़राब हार्नेस पर चक्र केवल गलतियों को तेज़ी से बढ़ाता है, इसलिए यह कदम आख़िरी है। सबसे सरल चक्र तीन पंक्तियों में लिखा जाता है:

लक्ष्य:      promo code वाला e2e भुगतान परिदृश्य पास होता है
जाँच:       make lint && make test && make e2e
रुकना:      लक्ष्य पूरा हुआ या 15 प्रयास या 2 घंटे → इंसान को बुलाएँ

काम के हिसाब से चक्र चुनें। अगर काम का अंत है, तो लक्ष्य वाला चक्र चाहिए: प्रगति की याददाश्त, स्वतंत्र जज और कदमों का बजट। अगर अंत नहीं है (सुबह की CI जाँच, नई त्रुटियों का विश्लेषण), तो शेड्यूल वाला चक्र। आम गलती है ऐसा काम शेड्यूल पर चलाना जिसका अंत है: हर रन उसे शून्य से शुरू करता है।

सुरक्षित स्वायत्तता के नियम

• रुकने की शर्त केवल मशीन से जाँची जा सकने वाली हो, साथ में प्रयासों और बजट की सीमा।
• एस्केलेशन: पहले से लिखें कि चक्र पर क्या भरोसा नहीं किया जाता (production migrations, पैसा, डेटा मिटाना)।
• अगर काम अटका है और प्रगति असल में नहीं बढ़ रही, तो यह संकेत है कि इसे इंसान को सौंपें, चक्र को और न घुमाएँ।
• Diff पढ़ें। चक्र की गति आपके पढ़ने की गति से तेज़ न हो, वरना आप अपने ही कोडबेस को समझना बंद कर देंगे।

इस रास्ते की आम गलतियाँ

निर्देश दोबारा लिखने से शुरुआत

एजेंट की गलती पर सबसे लोकप्रिय प्रतिक्रिया है AGENTS.md में एक और नियम जोड़ देना। कुछ महीनों में फ़ाइल सैकड़ों पंक्तियों की हो जाती है और ज़रूरी नियम उसमें खो जाते हैं। अगर असफलताओं का लॉग बताता है कि एजेंट ने जाँचें नहीं चलाईं, तो फ़ीडबैक ठीक करें: जाँच की कमांड और hook, टेक्स्ट का एक और पैराग्राफ़ नहीं।

सब कुछ एक साथ ठीक करना

हार्नेस के पाँचों हिस्से एक साथ सुधारने का मन करता है। पर तब पता नहीं चलता कि असल में क्या मदद कर रहा है। हर हिस्से को 1 से 5 के पैमाने पर आँकें, सबसे कमज़ोर पर आधा घंटा लगाएँ, और वही पाँच काम पहले और बाद में चलाएँ। असफलताओं के लॉग में अंतर बताएगा कि असर हुआ या नहीं।

"टेस्ट हरे" और "फ़ीचर काम करता है" को एक मानना

एजेंट ऐसा टेस्ट लिख सकता है जो उसके ख़ुद के implementation की जाँच करे, आवश्यकता की नहीं। ऐसा टेस्ट हमेशा हरा रहता है। बचाव है उपयोगकर्ता-स्तर की जाँच (E2E परिदृश्य), जो implementation से पहले या स्वतंत्र जाँचकर्ता द्वारा लिखी गई हो, और यह नियम कि एजेंट टेस्ट को पास करवाने के लिए उसे नहीं बदलता।

रफ़्तार के लिए जाँच बंद करना

धीमी जाँचें लुभाती हैं कि "इस बार छोड़ दो"। बेहतर है उन्हें बाँटें: तेज़ linter और type checking हर बदलाव के बाद, पूरा टेस्ट सेट और E2E "तैयार" कहने से पहले। इससे फ़ीडबैक लूप छोटा रहता है और काम में बाधा नहीं बनता।

ablation को पहला कदम समझना

एक-एक करके हार्नेस के हिस्से बंद करके देखा जा सकता है कि गुणवत्ता कितनी गिरती है। यह उपयोगी जाँच है, पर महँगी है और पहली नहीं: पहले असफलताओं का लॉग अड़चन दिखाता है, और ablation केवल उस अनुमान की पुष्टि करता है। किसी घटक को बंद करने पर गिरावट शून्य हो, तो इसका मतलब यह नहीं कि वह बेकार है। हो सकता है चुने हुए कामों ने उसे इस्तेमाल ही न किया हो।

परिपक्वता की सीढ़ी

निष्कर्ष

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