3 लेयरों के लिए एक व्यावहारिक गाइड जिन्हें लोग लगातार मिला रहे हैं
ज़्यादातर लोग AI एजेंट्स के बारे में ऐसे बात करते हैं जैसे यह एक ही चीज़ हो।
ऐसा नहीं है।
जब कोई एजेंट एक टॉय डेमो से आगे बढ़कर फ़ाइलों, APIs, डॉक्यूमेंट्स, कस्टमर्स या प्रोडक्शन कोड को छूने लगता है, तो आप सिर्फ़ "मॉडल को प्रॉम्प्ट" नहीं कर रहे होते।
आप एक सिस्टम डिज़ाइन कर रहे होते हैं।
और उस सिस्टम में, तीन आइडियाज़ लगातार आपस में मिल जाते हैं:
- एजेंट हार्नेस इंजीनियरिंग
- लूप इंजीनियरिंग
- ग्राफ़ इंजीनियरिंग
ये सभी एक ही मॉडल के आसपास बैठे होते हैं।
ये सभी रिलायबिलिटी को प्रभावित करते हैं।
और हाँ, इन सभी में लूप हो सकते हैं।
लेकिन ये अलग-अलग समस्याओं को हल करते हैं।
अगर आप इन्हें मिला देंगे, तो आप गलत लेयर को डीबग करने लगेंगे।
30 सेकंड का जवाब
यह रहा साफ़ वर्ज़न:
- हार्नेस इंजीनियरिंग मॉडल के चारों ओर का वातावरण बनाती है
- लूप इंजीनियरिंग दोहराए जाने वाले काम और फीडबैक चक्र को डिज़ाइन करती है
- ग्राफ़ इंजीनियरिंग वर्कफ़्लो टोपोलॉजी को स्पष्ट बनाती है
एक अच्छा मेंटल मॉडल है:
वातावरण → फीडबैक → प्रवाह
- हार्नेस मॉडल को टूल, मेमोरी, कंट्रोल और एक वर्कस्पेस देता है
- लूप तय करता है कि काम को कैसे दोबारा प्रयास किया जाए, जाँचा जाए और बेहतर बनाया जाए
- ग्राफ़ परिभाषित करता है कि आगे कौन सा कदम उठाने की अनुमति है
यही अंतर है।
ये शर्तें अब क्यों मायने रखती हैं
एक कच्चा मॉडल अपने आप असली काम नहीं कर सकता।
वह नहीं कर सकता:
- सत्रों के बीच प्रोजेक्ट स्टेट बनाए रखना
- सुरक्षित रूप से टूल को कॉल करना
- ब्राउज़र का निरीक्षण करना
- अनुमतियाँ लागू करना
- असफल काम को दोबारा प्रयास करना
- आउटपुट गुणवत्ता को मान्य करना
- विशेषज्ञों के बीच कार्यों को रूट करना
- सही समय पर रुकना
यह सब उसके आस-पास के सिस्टम से आता है।
जैसे-जैसे एजेंटिक सॉफ़्टवेयर परिपक्व होता है, एक व्यावहारिक स्टैक उभर रहा है:
- हार्नेस मॉडल को संचालन की स्थितियाँ देता है
- लूप काम को दोहराने योग्य और सत्यापन योग्य बनाते हैं
- ग्राफ़ जटिल वर्कफ़्लो को स्पष्ट और नियंत्रणीय बनाता है
एक बार जब आप इन्हें अलग-अलग लेयर के रूप में देख लेते हैं, तो AI आर्किटेक्चर का बहुत सारा भ्रम गायब हो जाता है।
एक गंभीर हार्नेस में आमतौर पर क्या शामिल होता है
- कॉन्टेक्स्ट इंजेक्शन
मॉडल कार्य करने से पहले क्या देखता है:
- निर्देश
- पुनर्प्राप्त ज्ञान
- बातचीत की स्थिति
- मेमोरी
- नीतियाँ
- कार्य-विशिष्ट नियम
- एक्शन सरफेस
मॉडल क्या कर सकता है:
- API कॉल
- ब्राउज़र एक्शन
- शेल कमांड
- कोड निष्पादन
- MCP टूल
- डेटाबेस
- कस्टम फ़ंक्शन
- पर्सिस्टेंस
समय के साथ क्या बचता है:
- फ़ाइलें
- चेकपॉइंट
- सत्र स्थिति
- प्रगति लॉग
- git इतिहास
- दीर्घकालिक मेमोरी
- निष्पादन नियंत्रण
रन कैसे प्रबंधित किया जाता है:
- पुनः प्रयास
- टाइमआउट
- बजट
- मॉडल चयन
- सबएजेंट स्पॉनिंग
- अनुमोदन गेट
- सुरक्षा और शासन
क्या सिस्टम को सुरक्षित रखता है:
- न्यूनतम-विशेषाधिकार अनुमतियाँ
- अलगाव
- अनुमति सूची
- गुप्त जानकारी संभालना
- मानव अनुमोदन
- अवलोकन क्षमता
क्या आपको इसे डीबग करने देता है:
- ट्रेस
- टूल इनपुट और आउटपुट
- स्टेट ट्रांज़िशन
- विलंबता
- लागत
- eval परिणाम
हार्नेस इंजीनियरिंग क्यों मायने रखती है
दो टीमें एक ही मॉडल का उपयोग कर सकती हैं और पूरी तरह से अलग परिणाम प्राप्त कर सकती हैं।
क्यों?
क्योंकि एक टीम मॉडल को देती है:
- साफ़ टूल
- स्थिर स्थिति
- संरचित मेमोरी
- स्पष्ट अनुमतियाँ
- देखने योग्य निष्पादन
और दूसरी उसे देती है:
- एक अस्पष्ट प्रॉम्प्ट
- गंदे टूल
- शोरगुल वाला संदर्भ
- कोई मेमोरी नहीं
- कोई सत्यापन नहीं
मॉडल एक जैसा हो सकता है।
काम करने की स्थितियाँ नहीं हैं।
हार्नेस इंजीनियरिंग तब मायने रखती है जब एजेंट:
- सही क्षमता तक नहीं पहुँच सकता
- सत्रों के बीच संदर्भ खो देता है
- वातावरण में असंगत रूप से कार्य करता है
- ऑडिट नहीं किया जा सकता
- बहुत अधिक अनुमति है
- रुकावट के बाद साफ़ रूप से ठीक नहीं हो सकता
अगर मॉडल विश्वसनीय रूप से काम नहीं कर सकता, तो पहले हार्नेस को देखना चाहिए।
2. लूप इंजीनियरिंग
यह क्या है
प्रत्येक टूल-उपयोग करने वाले एजेंट में पहले से ही एक छोटा अंतर्निहित लूप होता है:
- मॉडल को कॉल करें
- परिणाम देखें
- टूल चलाएँ
- अवलोकनों को वापस फीड करें
- तब तक दोहराएँ जब तक काम पूरा न हो जाए
लूप इंजीनियरिंग तब शुरू होती है जब आप जानबूझकर उस व्यवहार के आसपास अतिरिक्त चक्र डिज़ाइन करते हैं।
सिर्फ़ "फिर से पूछो" नहीं।
सिर्फ़ "पुनः प्रयास करो" नहीं।
बल्कि एक वास्तविक काम-और-फीडबैक सिस्टम।
एक अच्छे लूप की शारीरिक रचना
ट्रिगर
एक नया चक्र क्या शुरू करता है?
- उपयोगकर्ता अनुरोध
- विफल परीक्षण
- नया दस्तावेज़
- निर्धारित रन
- वेबहुक
- मूल्यांकक फीडबैक
लक्ष्य
हम किस विशिष्ट स्थिति तक पहुँचने की कोशिश कर रहे हैं?
"सुधारते रहो" नहीं।
एक वास्तविक लक्ष्य।
अवस्था
अगले चक्र को क्या जानने की आवश्यकता है?
- वर्तमान ड्राफ़्ट
- पिछला प्रयास
- टूल परिणाम
- त्रुटियाँ
- प्रगति स्थिति
कार्रवाई नीति
एजेंट को क्या करने की अनुमति है?
- संपादित करें
- प्रतिनिधि बनाएँ
- टूल कॉल करें
- टोकन खर्च करें
- फ़ाइलें लिखें
- PR खोलें
साक्ष्य
हमें कैसे पता चलेगा कि यह काम कर गया?
- परीक्षण
- स्कीमा सत्यापन
- उद्धरण
- अंतर
- मेट्रिक्स
- समीक्षक अनुमोदन
फीडबैक
वास्तव में क्या विफल रहा?
फीडबैक संक्षिप्त और कार्रवाई योग्य होना चाहिए।
रुकने का नियम
यह कब समाप्त होता है?
- सफलता
- टाइमआउट
- बजट समाप्त
- अधिकतम पुनः प्रयास हिट
- अपूरणीय विफलता
- मानव को एस्केलेशन
लूप इंजीनियरिंग में सबसे महत्वपूर्ण सिद्धांत
**आत्मविश्वास पर लूप न करें।
साक्ष्य पर लूप करें।**
"एजेंट कहता है कि यह हो गया" एक रुकने की शर्त नहीं है।
एक वास्तविक रुकने की शर्त कुछ इस तरह दिखती है:
- परीक्षण पास हो जाते हैं
- स्कीमा मान्य हो जाती है
- उद्धरण हल हो जाते हैं
- समीक्षक अनुमोदन करता है
- नीति जाँच साफ़ है
यही लूप इंजीनियरिंग है।
लूप इंजीनियरिंग सिर्फ़ प्रॉम्प्ट इंजीनियरिंग क्यों नहीं है
एक प्रॉम्प्ट मॉडल को बताता है कि कॉल के दौरान क्या करना है।
एक लूप परिभाषित करता है कि सिस्टम कॉल के बाद क्या करता है।
इसमें शामिल है:
- यह परिणामों की जाँच कैसे करता है
- यह विफलता पर कैसे प्रतिक्रिया करता है
- यह प्रगति को कैसे बनाए रखता है
- यह जारी रखने का निर्णय कैसे लेता है
- यह कैसे समाप्त होता है
प्रॉम्प्टिंग एक प्रतिक्रिया में सुधार करती है।
एक लूप एक प्रक्रिया में सुधार करता है।
यह एक बहुत अलग इंजीनियरिंग समस्या है।
3. ग्राफ़ इंजीनियरिंग
यह क्या है
ग्राफ़ इंजीनियरिंग वर्कफ़्लो संरचना को स्पष्ट बनाती है।
यह एक अलग प्रश्न का उत्तर देती है:
सिर्फ़ यह नहीं कि "एजेंट को क्या करना चाहिए?" बल्कि यह कि "आगे क्या होने की अनुमति है?"
ग्राफ़ इंजीनियरिंग में:
- चरण नोड हैं
- संक्रमण किनारे हैं
- शाखाएँ स्पष्ट हैं
- समानांतर कार्य स्पष्ट है
- जोड़ स्पष्ट हैं
- पुनः प्रयास स्पष्ट हैं
- मानवीय रुकावटें स्पष्ट हैं
ग्राफ़ सिस्टम के लिए नियंत्रण मानचित्र बन जाता है।
ग्राफ़ इंजीनियर वास्तव में क्या डिज़ाइन करते हैं
नोड सीमाएँ
क्या शामिल है:
- एक नियतात्मक फ़ंक्शन
- एक LLM कॉल
- एक विशेषज्ञ एजेंट
- एक मानव समीक्षा चरण
अवस्था स्कीमा
प्रत्येक नोड क्या पढ़ या लिख सकता है।
रूटिंग शर्तें
कौन सा साक्ष्य कार्य को आगे बढ़ाता है:
- आगे
- पीछे
- बगल में
- एस्केलेशन की ओर
समवर्तीता
क्या समानांतर में चल सकता है, और किसे इंतज़ार करना चाहिए।
चक्र और निकास
जहाँ पुनः प्रयास की अनुमति है, कितने की अनुमति है, और वे कैसे रुकते हैं।
स्थायित्व
जहाँ चेकपॉइंट होते हैं और रुकावट के बाद वर्कफ़्लो कैसे फिर से शुरू होता है।
ग्राफ़ कब उपयोगी होते हैं
ग्राफ़ मूल्यवान होते हैं जब प्रक्रिया में शामिल हो:
- सार्थक शाखाएँ
- अनुमोदन
- विशेषज्ञ हैंडऑफ़
- समानांतर कार्य
- रिकवरी पथ
- स्पष्ट नियंत्रण बिंदुओं वाले बहु-चरणीय वर्कफ़्लो
वे कम उपयोगी होते हैं जब काम बस इतना हो:
"एक एजेंट को कुछ टूल दें और उसे काम करने दें।"
उस स्थिति में, एक ठोस हार्नेस और कुछ लूप पर्याप्त हो सकते हैं।
ग्राफ़ स्पष्टता जोड़ता है, लेकिन यह संरचना भी जोड़ता है।
बहुत जल्दी बहुत अधिक संरचना सिस्टम को भंगुर बना सकती है।
3 लेयरें एक साथ कैसे काम करती हैं
मान लीजिए आप एक रिसर्च-एंड-पब्लिशिंग एजेंट बना रहे हैं।
उसे यह करना है:
- एक विषय का दायरा तय करना
- स्रोत इकट्ठा करना
- उद्धरणों की जाँच करना
- एक रिपोर्ट का मसौदा तैयार करना
- कानूनी समीक्षा पास करना
- अनुमोदन के बाद ही प्रकाशित करना
यहाँ बताया गया है कि लेयरें कैसे मैप होती हैं:
हार्नेस
प्रदान करता है:
- ब्राउज़र एक्सेस
- खोज टूल
- फ़ाइल वर्कस्पेस
- मेमोरी
- उद्धरण
- अनुमोदन
- ट्रेस
- मॉडल रूटिंग
लूप
संभालता है:
- जब साक्ष्य कमज़ोर हो तो स्रोत पुनर्प्राप्ति का पुनः प्रयास
- उद्धरण विफलताओं को ठीक करना
- ग्रेडर जाँच चलाना
- जब बाज़ार बदलता है तो काम को ताज़ा करना
ग्राफ़
पथ को नियंत्रित करता है:
- दायरा निर्धारण
- अनुसंधान
- जाँच
- संश्लेषण
- मसौदा तैयार करना
- समीक्षा
- प्रकाशन
रिलीज़ से पहले एक मानवीय गेट के साथ।
यही कारण है कि 3 लेयरें विनिमेय नहीं हैं।
वे एक साथ काम करती हैं, लेकिन वे एक ही चीज़ नहीं हैं।
समाधान चुनने से पहले विफलता का निदान करें
यहाँ व्यावहारिक नियम है:
अगर एजेंट काम नहीं कर सकता, तो हार्नेस ठीक करें
उदाहरण:
- लापता टूल एक्सेस
- पुरानी स्थिति
- कमज़ोर मेमोरी
- खराब अनुमतियाँ
- कोई अवलोकन क्षमता नहीं
अगर एजेंट लगभग काम करता है लेकिन अविश्वसनीय है, तो लूप ठीक करें
उदाहरण:
- पहला ड्राफ़्ट करीब है लेकिन कमज़ोर है
- सफलता असंगत है
- पुनः प्रयास अनियंत्रित हैं
- पूर्णता का कोई प्रमाण नहीं है
अगर प्रक्रिया स्वयं जटिल है, तो ग्राफ़ ठीक करें
उदाहरण:
- कई विशेषज्ञ
- अनुमोदन
- शाखाकरण तर्क
- समानांतर पथ
- संरचित हैंडऑफ़
सामान्य गलतियाँ
1. बहुत जल्दी ग्राफ़ बनाना
टीमें अक्सर यह देखने से पहले एक बड़े वर्कफ़्लो का आरेख बनाती हैं कि काम वास्तव में कैसे व्यवहार करता है।
बेहतर तरीका:
- एक सरल हार्नेस से शुरू करें
- ट्रेस इकट्ठा करें
- स्थिर पैटर्न खोजें
- केवल वही औपचारिक बनाएँ जो नियंत्रण के लायक हो
2. एक ही मॉडल को बिना सुरक्षा उपायों के लिखने और ग्रेड करने देना
स्व-समीक्षा मदद कर सकती है, लेकिन यह समान अंध स्थानों को साझा करती है।
प्राथमिकता दें:
- जहाँ संभव हो नियतात्मक जाँच
- अलग समीक्षक संदर्भ
- बाहरी मूल्यांकक
- उच्च-प्रभाव वाली कार्रवाइयों के लिए मानव अनुमोदन
3. "कोशिश करते रहो" को लूप के रूप में उपयोग करना
यह एक लूप डिज़ाइन नहीं है।
यह एक अनियंत्रित लागत रिसाव है।
प्रत्येक लूप की आवश्यकता है:
- एक मापने योग्य लक्ष्य
- वास्तविक साक्ष्य
- पुनः प्रयास सीमाएँ
- एस्केलेशन नियम
4. हार्नेस को एक जंक ड्रॉअर की तरह मानना
अधिक टूल का मतलब स्वचालित रूप से बेहतर एजेंट नहीं है।
बहुत अधिक टूल बनाते हैं:
- चयन संबंधी गलतियाँ
- शोरगुल वाला संदर्भ
- कमज़ोर विश्वसनीयता
- व्यापक जोखिम सतह
एक अच्छा हार्नेस भीड़भाड़ वाला नहीं होता।
यह सटीक होता है।
5. ऑर्केस्ट्रेशन विफलताओं के लिए मॉडल को दोष देना
एक मॉडल इसकी भरपाई नहीं कर सकता:
- टूटे हुए API
- पुरानी स्थिति
- लापता निकास शर्तें
- अस्पष्ट टूल स्कीमा
- अदृश्य विफलता मोड
उस लेयर को ठीक करें जो विफलता की मालिक है।
एक सरल प्रोडक्शन चेकलिस्ट
हार्नेस
- क्या टूल संकीर्ण और दस्तावेजित हैं?
- क्या स्थिति टिकाऊ है?
- क्या अनुमतियाँ न्यूनतम-विशेषाधिकार हैं?
- क्या ऑपरेटर रोक, निरीक्षण और फिर से शुरू कर सकते हैं?
- क्या ट्रेस दिखाई दे रहे हैं?
लूप
- कौन सा साक्ष्य सफलता साबित करता है?
- विफलता पर क्या फीडबैक लौटाया जाता है?
- कितने पुनः प्रयास की अनुमति है?
- रुकने का नियम क्या है?
- जब बजट खत्म हो जाता है तो क्या होता है?
ग्राफ़
- कौन से पथ नियतात्मक होने चाहिए?
- क्या समानांतर में चल सकता है?
- मानवीय गेट कहाँ हैं?
- कौन सी स्थिति साझा की जाती है?
- रिकवरी पथ कहाँ से शुरू होते हैं?
मूल्यांकन
- क्या आप वास्तविक ट्रेस को फिर से चला सकते हैं?
- क्या आप संस्करणों की तुलना कर सकते हैं?
- क्या आप सुधार को एक वास्तविक बदलाव के लिए जिम्मेदार ठहरा सकते हैं?
संचालन
- क्या आप लागत ट्रैक कर रहे हैं?
- विलंबता?
- विफलता दर?
- हस्तक्षेप दर?
- प्रोडक्शन में कार्य सफलता?
अंतर याद रखने का सबसे सरल तरीका
अगर आपको केवल एक बात याद रखनी है, तो यह याद रखें:
- हार्नेस इंजीनियरिंग मॉडल को संचालन योग्य बनाती है
- लूप इंजीनियरिंग काम को पुनरावृत्त और सत्यापन योग्य बनाती है
- ग्राफ़ इंजीनियरिंग निष्पादन पथ को स्पष्ट और नियंत्रणीय बनाती है
कोई भी दूसरे की जगह नहीं लेता।
एक आदर्श ग्राफ़ एक कमज़ोर हार्नेस को नहीं बचाएगा।
एक मज़बूत हार्नेस अच्छे लूप के बिना पैसा बर्बाद करेगा।
और साफ़ लूप तब प्रबंधित करना मुश्किल हो जाता है जब शाखाएँ और अनुमोदन तदर्थ कोड में छिपे रहते हैं।
विश्वसनीय एजेंट सिस्टम तब दिखाई देते हैं जब सभी 3 लेयरों को जानबूझकर डिज़ाइन किया जाता है।
यही वास्तविक आर्किटेक्चर स्टैक है।
अंतिम निष्कर्ष
लोग AI एजेंट्स के बारे में ऐसे बात करते रहते हैं जैसे सफलता का राज़ मॉडल है।
प्रोडक्शन में, यह शायद ही कभी वास्तविक अंतर होता है।
अंतर मॉडल के आस-पास का सिस्टम है:
- हार्नेस जो इसे काम करने देता है
- लूप जो इसे सुधारने देते हैं
- ग्राफ़ जो इसे नियंत्रण में संचालित करने देता है
इसी तरह टॉय एजेंट वास्तविक सिस्टम बन जाते हैं।
अगर आपने इतना दूर तक पढ़ा है:
- इसे बुकमार्क करें।
- [@LunarResearcher](https://x.com/@LunarResearcher) को फ़ॉलो करें
- मेरे Substack को फ़ॉलो करें**
- मेरे प्राइवेट टेलीग्राम चैनल को फ़ॉलो करें**
