असली सॉफ़्टवेयर बनाने और शिप करने वाले AI एजेंट: Jobbit की इंजीनियरिंग
असली सॉफ़्टवेयर शिप करने वाले AI एजेंट कैसे बनाएं — मल्टी-एजेंट ऑर्केस्ट्रेशन, टूल यूज़, सैंडबॉक्स्ड कोड एक्ज़ीक्यूशन, RAG, evals और एज डिप्लॉयमेंट पर Jobbit Labs की गहराई से जानकारी।

ज़्यादातर "AI एजेंट" बातचीत तक ही सीमित रह जाते हैं। वे जवाब देते हैं, और फिर असली काम कोई इंसान करता है। दिलचस्प — और सचमुच कठिन — इंजीनियरिंग समस्या ऐसे एजेंट बनाने की है जो खुद काम करें: एक पूरी फुल-स्टैक एप्लिकेशन लिखें, उसे चलाएं, अपनी ही गलतियाँ सुधारें, और उसे प्रोडक्शन में डिप्लॉय करें। यही वह समस्या है जिस पर Jobbit की इंजीनियरिंग टीम और इसका R&D डिवीज़न, Jobbit Labs (jobbitlabs.com), हर दिन काम करते हैं।
यह पोस्ट सॉफ़्टवेयर बनाने और शिप करने वाले AI एजेंट के पीछे के पैटर्न में गहराई से उतरती है — आर्किटेक्चर, फेलियर मोड, और सबक। यह जानबूझकर व्यावहारिक और किसी एक प्रोवाइडर तक सीमित नहीं है: चाहे आप LLMs, मल्टी-एजेंट ऑर्केस्ट्रेशन, टूल कॉलिंग, या RAG पर काम कर रहे हों, ये सिद्धांत हर जगह काम आते हैं।
चैटबॉट जवाब देते हैं; एजेंट काम करते हैं
चैटबॉट से एजेंट तक की छलांग टेक्स्ट जनरेट करने से लेकर दुनिया में कार्रवाई करने तक की छलांग है। एक एजेंट को कई चरणों वाले काम की योजना बनानी होती है, टूल कॉल करने होते हैं, नतीजे पढ़ने होते हैं, और तय करना होता है कि आगे क्या करना है — फिर लक्ष्य पूरा होने तक यही दोहराना होता है। यह लूप, जिसे अक्सर एजेंटिक लूप (या reason–act लूप) कहा जाता है, पूरे सिस्टम का दिल है।
इंजीनियरिंग चुनौती यह है कि हर चरण विफल हो सकता है। मॉडल कोई ऐसा फ़ंक्शन गढ़ सकता है जो मौजूद ही नहीं है, ऐसा कोड लिख सकता है जो कंपाइल न हो, किसी टूल के आउटपुट को गलत पढ़ सकता है, या चुपचाप अपने काम से भटक सकता है। गलत चैटबॉट एक खराब वाक्य बनाता है; गलत एजेंट एक टूटा हुआ डिप्लॉय बनाता है। असली इंजीनियरिंग काम विश्वसनीयता (reliability) है, सिर्फ़ कच्ची क्षमता नहीं।
आर्किटेक्चर: प्लानर, एक्ज़ीक्यूटर, टूल्स
एक मज़बूत एजेंट प्लेटफ़ॉर्म प्लानिंग को एक्ज़ीक्यूशन से अलग रखता है। एक प्लानिंग लेयर किसी लक्ष्य ("पेमेंट के साथ एक बुकिंग ऐप बनाओ") को ठोस चरणों में तोड़ती है; एक एक्ज़ीक्यूशन लेयर हर चरण को टूल्स का इस्तेमाल करके पूरा करती है। इन दोनों को अलग रखने से सिस्टम डिबग करने लायक बनता है: आप यह जाँच सकते हैं कि योजना क्या थी, इससे अलग कि हर चरण कैसे चला।
टूल यूज़ वह जगह है जहाँ एजेंट को अपने हाथ मिलते हैं। टूल्स अच्छी तरह परिभाषित फ़ंक्शन होते हैं जिन्हें मॉडल कॉल कर सकता है — फ़ाइल पढ़ना, कोड लिखना, बिल्ड चलाना, डेटाबेस क्वेरी करना, डिप्लॉय करना। यहाँ इंजीनियरिंग अनुशासन इंटरफ़ेस डिज़ाइन का है: हर टूल को एक कसा हुआ, स्पष्ट स्कीमा, सत्यापित इनपुट, और ऐसे स्ट्रक्चर्ड आउटपुट चाहिए जिन्हें मॉडल भरोसे से पार्स कर सके। ढीले टूल इंटरफ़ेस एजेंट फेलियर का सबसे बड़ा कारण हैं; कसे हुए इंटरफ़ेस विश्वसनीयता का सबसे सस्ता तरीका हैं।
जटिल कामों के लिए, एक अकेला एजेंट अक्सर मल्टी-एजेंट ऑर्केस्ट्रेशन को रास्ता देता है — विशेषज्ञ एजेंट जो योजना बनाते हैं, कोड लिखते हैं, समीक्षा करते हैं, और सत्यापित करते हैं, एक ऑर्केस्ट्रेटर के समन्वय में। काम को बाँटने से आपको फ़ोकस मिलता है (हर एजेंट का काम संकीर्ण और संदर्भ संकीर्ण) और समानांतरता (स्वतंत्र उप-कार्य एक साथ चलते हैं)। इसकी कीमत है समन्वय का अतिरिक्त बोझ, इसलिए ऑर्केस्ट्रेशन लेयर को जहाँ संभव हो वहाँ निर्धारक (deterministic) और जहाँ न हो वहाँ लचीला होना चाहिए।
असली कोड को सुरक्षित ढंग से चलाना और डिप्लॉय करना
जो एजेंट सॉफ़्टवेयर लिखता है उसे उस सॉफ़्टवेयर को चलाना भी होता है — और मॉडल से बने कोड को चलाना किसी भी और चीज़ से पहले एक सुरक्षा समस्या है। इसका जवाब है सैंडबॉक्स्ड कोड एक्ज़ीक्यूशन: अविश्वसनीय कोड एक अलग-थलग वातावरण में, सीमित संसाधनों के साथ, बिना किसी सीक्रेट तक पहुँच और कसी हुई नेटवर्क सीमाओं के साथ चलता है। यही सैंडबॉक्स एजेंट को बार-बार दोहराने देता है — कंपाइल करना, टेस्ट करना, एरर पढ़ना, ठीक करना — बिना प्लेटफ़ॉर्म या दूसरे यूज़र्स को जोखिम में डाले।
डिप्लॉयमेंट वह चरण है जो एक बने हुए ऐप को एक प्रोडक्ट में बदल देता है। एक असली AI ऐप बिल्डर कोड से लेकर एक लाइव URL तक का पूरा रास्ता संभालता है: बिल्ड करना, होस्टिंग का इंतज़ाम करना, डोमेन जोड़ना, TLS संभालना। इसे अच्छी तरह इंजीनियर करने का मतलब है डिप्लॉय को दोहराने योग्य और वापस लौटाने योग्य बनाना — वही इनपुट वही नतीजा देते हैं, और एक खराब डिप्लॉय को रोलबैक किया जा सकता है। आइडेमपोटेंसी और साफ़ रोलबैक चमकदार नहीं हैं, पर यही चीज़ें स्वायत्त डिप्लॉयमेंट को भरोसेमंद बनाती हैं।
संदर्भ, मेमोरी, और रिट्रीवल
LLMs का संदर्भ (context) सीमित होता है, और असली प्रोजेक्ट उसमें समाते नहीं। इसलिए एक गंभीर एजेंट सिस्टम कॉन्टेक्स्ट इंजीनियरिंग में भारी निवेश करता है: यह तय करना कि मॉडल हर चरण पर क्या देखता है। सब कुछ प्रॉम्प्ट में ठूँस देना महंगा भी है और उल्टा भी — बहुत सारा अप्रासंगिक संदर्भ तर्क-क्षमता को कमज़ोर कर देता है।
यहीं RAG (retrieval-augmented generation) और वेक्टर डेटाबेस अपनी जगह बनाते हैं। पूरे कोडबेस को संदर्भ में डालने के बजाय, सिस्टम सिर्फ़ उन कुछ फ़ाइलों, सिंबल्स, या डॉक्स को निकालता है जो मौजूदा चरण के लिए ज़रूरी हैं। स्ट्रक्चर्ड मेमोरी के साथ मिलकर — लिए गए फ़ैसलों का रिकॉर्ड, विकसित होता स्पेक, और अब तक क्या-क्या आज़माया जा चुका है — रिट्रीवल एजेंट को एक लंबे काम के दौरान कॉन्टेक्स्ट विंडो भरे बिना ज़मीन से जुड़ा रखता है। अच्छा रिट्रीवल अक्सर एक बड़े मॉडल से भी बड़ा क्वालिटी लीवर होता है।
विश्वसनीयता: evals, सत्यापन, और गार्डरेल
अगर एक विचार प्रोडक्शन एजेंट इंजीनियरिंग को डेमो से अलग करता है, तो वह यह है: जो आप माप नहीं सकते, उसे आप शिप नहीं कर सकते। एजेंटिक सिस्टम स्टोकेस्टिक होते हैं, इसलिए विश्वसनीयता evals के ज़रिए इंजीनियर की जाती है — स्वचालित टेस्ट सूट जो एजेंट को प्रतिनिधि कार्यों पर स्कोर करते हैं और यूज़र्स से पहले ही रिग्रेशन पकड़ लेते हैं। ऐसा बदलाव जो "बेहतर लगता है" पर आपके eval स्कोर गिरा देता है, वह ऐसा बदलाव है जिसे आप शिप नहीं करते।
evals के ऊपर रनटाइम गार्डरेल और सत्यापन बैठते हैं। सबसे कारगर पैटर्न है एडवर्सेरियल सेल्फ-चेकिंग: जब एजेंट कोई नतीजा बना ले — कोड का एक टुकड़ा, एक योजना, एक फ़िक्स — तो एक अलग सत्यापन पास उसे खारिज करने की कोशिश करता है। क्या कोड कंपाइल होता है? क्या टेस्ट पास होते हैं? क्या आउटपुट स्कीमा से मेल खाता है? सत्यापन को एक अलग, शक्की चरण मानना उन बहुत सी विफलताओं को पकड़ लेता है जिन्हें एक अकेला आत्मविश्वासी पास चूक जाता। बैकऑफ़ के साथ रीट्राई, सर्किट ब्रेकर, और मानवीय एस्केलेशन बाकी संभाल लेते हैं।
ऐसी ऑब्ज़र्वेबिलिटी जिसे आप डिबग कर सकें
जब एक स्वायत्त सिस्टम हर काम में दर्जनों फ़ैसले लेता है, तो आपको उन्हें देखना ज़रूरी है। ऑब्ज़र्वेबिलिटी — हर प्रॉम्प्ट, टूल कॉल, और नतीजे की स्ट्रक्चर्ड ट्रेसिंग — गैर-समझौतापूर्ण है। जब कोई एजेंट गलत होता है, तो ट्रेस ही वह ज़रिया है जिससे आप ठीक वह चरण ढूँढते हैं जहाँ वह भटका, उसे दोहराते हैं, और मूल कारण ठीक करते हैं। जो इंजीनियरिंग टीमें एजेंट ट्रेस को पहले दर्जे की टेलीमेट्री मानती हैं वे मिनटों में डिबग करती हैं; जो नहीं मानतीं वे दिनों में।
एज और इलास्टिक स्केल
एजेंट वर्कलोड झटकेदार और लेटेंसी के प्रति संवेदनशील होते हैं, जो एज कंप्यूटिंग को इसके लिए स्वाभाविक रूप से उपयुक्त बनाता है। यूज़र्स के पास चलना — Cloudflare Workers और एज डेटा स्टोर जैसे प्लेटफ़ॉर्म पर — राउंड-ट्रिप लेटेंसी घटाता है और माँग के साथ इलास्टिक तरीके से स्केल करता है। Jobbit Labs अपने डेटा और प्रोडक्ट इन्फ़्रास्ट्रक्चर के कुछ हिस्सों के लिए इस एज-फ़र्स्ट तरीके पर भरोसा करता है: वैश्विक रूप से वितरित, ऑटोस्केलिंग, और जितना इस्तेमाल उतना भुगतान, ताकि क्षमता बेकार पड़ी रहने के बजाय लोड के पीछे चले।
ह्यूमन-इन-द-लूप लेयर
आर्किटेक्चर का आख़िरी टुकड़ा वही है जिसकी ज़्यादातर एजेंट प्लेटफ़ॉर्म में कमी होती है: एक ह्यूमन-इन-द-लूप रास्ता। AI मात्रा और गति संभालता है, पर कुछ फ़ैसले — सुरक्षा-संवेदनशील लॉजिक, कानूनी शब्दावली, डिज़ाइन की समझ — एक इंसान के हाथ में होने चाहिए। इसे इंजीनियर करने का मतलब है साफ़ हैंडऑफ़ बिंदु बनाना जहाँ एक जाँचा-परखा मानव विशेषज्ञ कदम रख सके, और एस्क्रो लेनदेन की रक्षा करे। एजेंट और मानव नेटवर्क प्रतिस्पर्धी लेयर नहीं हैं; वे एक सोच-समझकर रखा गया बैकअप हैं जो पूरे सिस्टम पर भरोसा करना सुरक्षित बनाता है।
एजेंट बनाने वाले इंजीनियरों के लिए सबक
अगर आप एजेंटिक सिस्टम बना रहे हैं, तो कुछ सिद्धांत आपके निवेश को कई गुना लौटा देते हैं।
कसे हुए टूल इंटरफ़ेस डिज़ाइन करें। ज़्यादातर एजेंट फेलियर अस्पष्ट टूल्स तक पहुँचते हैं। सख़्त स्कीमा और सत्यापित I/O सबसे सस्ती विश्वसनीयता हैं जो आप कभी खरीदेंगे।
एडवर्सेरियल तरीके से सत्यापित करें। आत्मविश्वासी पहले पास पर भरोसा न करें। एक अलग चरण जोड़ें जिसका काम नतीजे को खारिज करना हो।
evals से मापें। एजेंट को स्केल करने से पहले eval हार्नेस बनाएं। जो आप स्कोर नहीं कर सकते, उसे आप बेहतर नहीं बना सकते।
संदर्भ को इंजीनियर करें, ठूँसें नहीं। जो प्रासंगिक है उसे निकालें; जो मायने रखता है उसे याद रखें। बड़े प्रॉम्प्ट बेहतर प्रॉम्प्ट नहीं होते।
हर अविश्वसनीय चीज़ को सैंडबॉक्स करें। अगर कोई एजेंट कोड चलाता है, तो अलगाव एक पूर्वशर्त है, कोई फ़ीचर नहीं।
एक मानवीय रास्ता बनाए रखें। सबसे सुरक्षित स्वायत्त सिस्टम वह है जो जानता है कि कब किसी इंसान से पूछना है।
अक्सर पूछे जाने वाले सवाल
एक AI एजेंट चैटबॉट से किस तरह अलग है?
एक चैटबॉट टेक्स्ट जनरेट करता है; एक AI एजेंट योजना बनाता है और कार्रवाई करता है — टूल कॉल करना, कोड चलाना, और लक्ष्य की ओर बार-बार बढ़ना। इंजीनियरिंग की कठिनाई कई चरणों में विश्वसनीयता है, जहाँ कोई एक भी गलती नतीजा बिगाड़ सकती है।
AI से बने कोड को सुरक्षित ढंग से कैसे चलाते हैं?
सैंडबॉक्स्ड कोड एक्ज़ीक्यूशन के साथ: अविश्वसनीय कोड सीमित संसाधनों, बिना सीक्रेट तक पहुँच, और कसी हुई नेटवर्किंग वाले एक अलग-थलग वातावरण में चलता है, ताकि एजेंट प्लेटफ़ॉर्म को जोखिम में डाले बिना कंपाइल, टेस्ट, और फ़िक्स कर सके।
एजेंट सिस्टम के लिए evals इतने ज़रूरी क्यों हैं?
क्योंकि एजेंट स्टोकेस्टिक होते हैं, आपको प्रतिनिधि कार्यों पर क्वालिटी मापने और शिप करने से पहले रिग्रेशन पकड़ने के लिए स्वचालित evals चाहिए। उनके बिना, "सुधार" सिर्फ़ अनुमान होते हैं।
Jobbit Labs क्या करता है?
Jobbit Labs (jobbitlabs.com) Jobbit के पीछे का R&D और डेटा डिवीज़न है, जो भारी, डेटा-गहन, और एंटरप्राइज़ इंजीनियरिंग पर केंद्रित है — रिसर्च, डेटा प्लेटफ़ॉर्म, और वे एजेंट नींव जिन पर प्रोडक्ट बना है।
सॉफ़्टवेयर शिप करने वाले एजेंट के पीछे की इंजीनियरिंग के बारे में जिज्ञासु हैं? jobbit.uk और jobbitlabs.com पर देखें।