NAME
agentic-infrastructure-stack — एजेंटिक बुनियादी ढांचा और नया बैकएंड
SYNOPSIS
cat agentic-infrastructure-stack.md
DESCRIPTION
हमने अक्सर एजेंटिक फ्रेमवर्क के बारे में बात की है। लैंगग्राफ, क्रूएआई, ऑटोजेन, विभिन्न एसडीके, लूप, टूल कॉलिंग, मेमोरी, प्लानर, आलोचक, पर्यवेक्षक। सभी उपयोगी शब्द, भलाई के लिए। लेकिन जितना अधिक मैं वास्तव में उपयोग किए गए एजेंटों को देखता हूं, उतना ही मुझे ऐसा लगता है कि दिलचस्प हिस्सा ढांचे के स्तर से नीचे चला गया है।
सवाल अब सिर्फ यह नहीं है: स्टेप मॉडल को सोचने के लिए मैं किस लाइब्रेरी का उपयोग करूं?
असली सवाल यह है: जब यह एजेंट डेमो बनना बंद कर देता है तो वह कहां रहता है?
क्योंकि एक गंभीर एजेंट एक ऐसा फ़ंक्शन नहीं है जो किसी मॉडल को कॉल करता है और टेक्स्ट लौटाता है। यह एक छोटी वितरित प्रणाली है. इसे संदर्भ पढ़ना चाहिए, टूल का उपयोग करना चाहिए, कोड निष्पादित करना चाहिए, फ़ाइलों को छूना चाहिए, निर्णय याद रखना चाहिए, अनुमति मांगनी चाहिए, अच्छी तरह से विफल होना चाहिए, पुनरारंभ करना चाहिए, लॉग छोड़ना चाहिए, बजट नहीं जलाना चाहिए और उत्पादन भंडार के अंदर बुलडोजर में नहीं बदलना चाहिए।
ढाँचा स्टीयरिंग व्हील है। बुनियादी ढाँचा है सड़क, ब्रेक, गैराज, बीमा और वह व्यक्ति जो जानता है कि चाबियाँ कहाँ हैं।
क्योंकि अभी इसके बारे में बहुत चर्चा हो रही है
2023 और 2024 में बातचीत बहुत मॉडल-केंद्रित थी। कौन सा एलएलएम? कितना प्रसंग? इसकी कीमत कितनी होती है? वह प्रोग्रामिंग में कितना अच्छा है?
2025 और 2026 में बातचीत बदल गई है। मॉडल वास्तविक कार्य करने के लिए काफी अच्छे हैं, लेकिन इसीलिए उबाऊ बिट्स दिखाई देने लगते हैं: रनटाइम, सुरक्षा, कनेक्टर्स, पहचान, अवलोकन, कोड निष्पादन, परिनियोजन, रोलबैक।
यह जादू से इंजीनियरिंग की ओर स्वाभाविक परिवर्तन है।
जब किसी एजेंट को केवल प्रतिक्रिया उत्पन्न करने की आवश्यकता होती है, तो एक चैट ही पर्याप्त है। जब आपको पुल अनुरोध खोलने, डेटाबेस को क्वेरी करने, सीआरएम को कॉल करने, नौकरी शुरू करने, साइट नेविगेट करने, स्लैक पढ़ने, कोड संकलित करने और दस्तावेज़ को अपडेट करने की आवश्यकता होती है, तो आपको इसके चारों ओर एक ऑपरेटिंग सिस्टम की आवश्यकता होती है।
शाब्दिक अर्थ में नहीं. संगठनात्मक अर्थ में.
पहला भाग: एक रनटाइम जहां एजेंट टिक सकता है
एक एजेंट अक्सर चरणों में काम करता है। स्थिति को देखें, एक क्रिया चुनें, एक उपकरण का उपयोग करें, परिणाम का निरीक्षण करें, योजना को अद्यतन करें, दोहराएं।
यदि यह लूप एकल HTTP अनुरोध के अंदर रहता है, तो आपको तुरंत एक समस्या होगी। कुछ क्रियाएं धीमी हैं. कुछ लोग मानवीय इनपुट की प्रतीक्षा करते हैं। कुछ विफल हो जाते हैं और उन्हें दोबारा प्रयास करना चाहिए। कुछ को तैनाती या टाइमआउट से बचना होगा।
यहीं पर टिकाऊ वर्कफ़्लो, कतारें, नौकरी की पृष्ठभूमि और राज्य मशीनें चलन में आती हैं। वे ग्लैमरस नहीं हैं, लेकिन वे एक ऐसे एजेंट के बीच अंतर हैं जो डेमो पर स्मार्ट दिखता है और एक ऐसे एजेंट के बीच जो आप कॉफी लेने जाते समय काम करना छोड़ सकते हैं।
मेरे लिए एजेंटिक रनटाइम को बहुत ठोस सवालों का जवाब देना होगा:
- मैं एक चरण से दूसरे चरण के बीच की स्थिति को कहां सहेजूं?
- यदि प्रक्रिया बीच में ही समाप्त हो जाए तो क्या होगा?
- क्या मैं रुक सकता हूँ और अनुमोदन माँग सकता हूँ?
- क्या मैं यह समझने के लिए एक दौड़ दोबारा खेल सकता हूं कि उसने यह विकल्प क्यों चुना?
- क्या मैं अवधि, मेमोरी, उपकरण और लागत को सीमित कर सकता हूँ?
वर्सेल वेब अनुप्रयोगों के भीतर एजेंटों के निर्माण के लिए एआई एसडीके, फ़ंक्शंस, वर्कफ़्लो और टूल के साथ इस मोर्चे पर कड़ी मेहनत कर रहा है। लेकिन बात सिर्फ वर्सेल की नहीं है. मुद्दा यह है कि एजेंट को एक ऑपरेशनल होम की जरूरत है, एक भी समापन बिंदु की नहीं।
दूसरा टुकड़ा: सैंडबॉक्स, क्योंकि एजेंट को बिना तोड़े गंदा करने में सक्षम होना चाहिए
जैसे ही कोई एजेंट कोड लिखता है या कमांड निष्पादित करता है, एक सैंडबॉक्स की आवश्यकता होती है।
यह एक तकनीकी शब्द लगता है, लेकिन विचार घरेलू है: आप उसे एक कार्यक्षेत्र दें। यह फ़ाइलें खोल सकता है, निर्भरताएँ स्थापित कर सकता है, परीक्षण चला सकता है, प्रयोग कर सकता है, आउटपुट उत्पन्न कर सकता है। यदि वह गलत हो जाता है, तो आपने नुकसान रोक लिया है। यदि यह काम करता है, तो परिणाम को बढ़ावा दें।
एक एजेंटिक सैंडबॉक्स में कुछ गुण होने चाहिए:
- पृथक फ़ाइल सिस्टम;
- सीपीयू, मेमोरी और समय सीमा;
- नियंत्रित नेटवर्क;
- रहस्य केवल जरूरत पड़ने पर ही सामने आते हैं;
- पूर्ण लॉग;
- कलाकृतियों को निर्यात करने की संभावना;
- जब आवश्यक हो, रनों के बीच क्लीन रीसेट करें।
वर्सेल सैंडबॉक्स बिल्कुल इसी दिशा में जाता है: मुख्य एप्लिकेशन रनटाइम में सब कुछ चलाए बिना कोड चलाने, निर्भरता स्थापित करने, फ़ाइलों के साथ काम करने और कलाकृतियों का उत्पादन करने के लिए पृथक वातावरण।
यह बात जितनी दिखती है उससे कहीं अधिक महत्वपूर्ण है. कई एजेंटिक प्रोटोटाइप सीधे मॉडल से वास्तविक सिस्टम में चले जाते हैं। मॉडल टूल को कॉल कर सकता है। उपकरण चीजें कर सकते हैं. यह सब पहले गलत कमांड, गलत जगह पर स्थापित पहली निर्भरता, लॉग में समाप्त होने वाले पहले टोकन तक सुरुचिपूर्ण लगता है।
सैंडबॉक्स यह कहने का वयस्क तरीका है: आगे बढ़ें, लेकिन यहीं।
तीसरा भाग: एमसीपी और कनेक्टर समस्या
मॉडल कॉन्टेक्स्ट प्रोटोकॉल पारिस्थितिकी तंत्र के सबसे दिलचस्प हिस्सों में से एक बन गया है क्योंकि यह किसी ऐसी चीज़ को मानकीकृत करने की कोशिश करता है जो अन्यथा जल्दी से असहनीय हो जाती है: एक मॉडल बाहरी उपकरणों की खोज और उपयोग कैसे करता है।
मानक के बिना, प्रत्येक एकीकरण एक छोटा द्वीप है। GitHub के लिए एक कनेक्टर को एक तरह से किया गया, स्लैक के लिए एक को दूसरे तरीके से किया गया, एक को विभिन्न शब्दार्थ वाले डेटाबेस के लिए, एक को ब्राउज़र स्वचालन के लिए जो कुछ भी नहीं दिखता है।
एमसीपी क्लाइंट और सर्वर के बीच एक आम भाषा का प्रस्ताव करता है: उपकरण, संसाधन, संकेत, प्राधिकरण, परिवहन, खोज। यह शासन और सुरक्षा को जादुई ढंग से हल नहीं करता है, लेकिन यह एक व्याकरण देता है।
और व्याकरण मायने रखता है. जब एक एजेंट कई उपकरणों से जुड़ सकता है, तो सवाल सिर्फ यह नहीं है कि "क्या वह ऐसा कर सकता है?" समस्या यह है कि "क्या वह समझता है कि वह क्या कर सकता है, किन सीमाओं के साथ, किसके लिए कर सकता है और क्या निशान छोड़ सकता है?"
मेरे लिए एमसीपी प्रचार नहीं है क्योंकि यह "टूल कॉलिंग करता है"। हमने पहले ही ऐसा कर लिया है. यह प्रचारित है क्योंकि यह गुरुत्वाकर्षण के केंद्र को एकल एकीकरण से उपकरणों की परिचालन सूची में स्थानांतरित करता है।
एक अच्छे एजेंटिक आर्किटेक्चर में, MCP एक प्रकार का पैच पैनल बन जाता है:
- कोड और मुद्दों के लिए GitHub;
- बातचीत के संदर्भ में सुस्ती;
- नियोजित कार्य के लिए रैखिक या जीरा;
- एनालिटिक्स के लिए केवल पढ़ने योग्य डेटाबेस;
- बाहरी साइटों के लिए नियंत्रित ब्राउज़र या स्क्रैपर;
- दस्तावेज़ भंडारण;
- पृथक निष्पादन वातावरण;
- सख्त अनुमतियों के साथ आंतरिक सिस्टम उजागर।
पेचीदा बात यह है कि नीति-मुक्त टूल कैटलॉग अराजकता पैदा करने का एक अधिक शानदार तरीका है।
चौथा भाग: पहचान और अनुमतियाँ
यह वह क्षेत्र है जहां कई डेमो आंखें मूंद लेते हैं।
एक एजेंट किसी की ओर से कार्य करता है। इसलिए यह स्पष्ट होना चाहिए कि कार्रवाई का विषय कौन है।
क्या यह उपयोगकर्ता अनुमतियों का उपयोग कर रहा है? एक सेवा खाते का? कार्यक्षेत्र का? क्या आपके पास अस्थायी या स्थायी पहुँच है? क्या आप सबकुछ पढ़ सकते हैं या सिर्फ कुछ संसाधन? क्या आप लिख सकते हैं? क्या आप रद्द कर सकते हैं? क्या वह वास्तविक लोगों को संदेश भेज सकता है?
यदि आप इन प्रश्नों का उत्तर ठीक से नहीं देते हैं, तो देर-सबेर आप एक ऐसा सहायक बना लेंगे जिसके पास घर की चाबियाँ होंगी और उसे यह याद नहीं रहेगा कि चाबियाँ उसे किसने दी थीं।
मुझे जो सामान्य नियम पसंद है वह यह है: एजेंट को इंसान से कम काम करने में सक्षम होना चाहिए, इंसान से ज्यादा नहीं। और जब उसे कुछ जोखिम भरा काम करना होता है, तो उसे रुकना पड़ता है और पूछना पड़ता है।
इसका अर्थ है OAuth, टोकन स्कोप्ड, गुप्त प्रबंधन, ऑडिट लॉग, टूल नीति, अनुमति सूची, अनुमोदन चरण। बहुत रोमांटिक चीज़ नहीं. आवश्यक सामान.
पाँचवाँ भाग: स्मृति और संदर्भ, लेकिन कचरा जमा किए बिना
एजेंटों को स्मृति की आवश्यकता होती है, लेकिन स्मृति तब खतरनाक होती है जब यह अटारी बन जाती है।
मेमोरी कम से कम तीन प्रकार की होती है:
- मेमोरी चलाएँ: इस निष्पादन में क्या हुआ;
- प्रोजेक्ट मेमोरी: परंपराएं, निर्णय, बाधाएं;
- व्यक्तिगत या टीम स्मृति: प्राथमिकताएँ, स्वर, अनुष्ठान, प्रक्रियाएँ।
Putting everything in the prompt is the shortcut. यह तब तक काम करता है जब तक यह और काम नहीं करता। उपयोगी मेमोरी का ध्यान रखा जाना चाहिए: अनुक्रमित, अद्यतन, समाप्त, सत्यापित, उपयुक्त बनाया गया।
एक एजेंट जो अच्छी तरह याद नहीं रखता, वह उस एजेंट से भी बदतर है जो याद नहीं रखता। क्योंकि वह आत्मविश्वास से बोलते हैं.
इसलिए बुनियादी ढांचे में पुनर्प्राप्ति, निर्देश फ़ाइलें, ज्ञान का आधार, आवश्यकता पड़ने पर एम्बेडिंग, लेकिन सफाई भी शामिल होनी चाहिए। हमें स्मृति की संस्कृति की आवश्यकता है: क्या प्रवेश करता है, कौन इसका अनुमोदन करता है, कब इसका क्षय होता है, मैं इसे कैसे ठीक करूं।
छठा भाग: अवलोकन, मूल्यांकन और पुनरावृत्ति
If an agent makes a mistake, the "called the model" log is not enough.
आप मार्ग देखना चाहते हैं. उसे क्या सन्दर्भ प्राप्त हुआ? कौन से उपकरण उपलब्ध थे? आपने कौन सा टूल चुना? किस तर्क से? आपको क्या प्रतिक्रिया मिली? इसका क्या खर्चा आया? कहां फंस गया? क्या इंसान को कोई चीज़ मंजूर थी? Is the error model, tool, prompt, data or permission error?
यहां एजेंट चैटबॉट्स की तुलना में वितरित सिस्टम की तरह अधिक हैं।
आपको केवल टेक्स्ट लॉग ही नहीं, बल्कि पढ़ने योग्य अंशों की भी आवश्यकता है। आपको एक रन दोबारा चलाने में सक्षम होना चाहिए। ज्ञात कार्यों पर एक ही एजेंट के दो संस्करणों की तुलना करना आवश्यक है। हमें प्रतिगमन को मापने की आवश्यकता है: यह न केवल "बेहतर उत्तर देता है", बल्कि यह "अनचाही फ़ाइलों को छुए बिना सही टिकट बंद कर देता है"।
एजेंटिक मूल्यांकन पाठ मूल्यांकन की तुलना में अधिक कठिन होते हैं क्योंकि उनमें क्रियाएं शामिल होती हैं। अपेक्षित स्ट्रिंग की तुलना करना पर्याप्त नहीं है। आपको क्रम, दुष्प्रभाव, कलाकृति की गुणवत्ता, समय, लागत, मानवीय हस्तक्षेप की संख्या को देखना होगा।
मजेदार बात यह है कि हम हमेशा वहीं वापस आते हैं: सॉफ्टवेयर इंजीनियरिंग। परीक्षण, वातावरण, निशान, रोलबैक। सिवाय इसके कि कोड अब यह भी तय करता है कि आगे क्या करना है।
सातवां भाग: मानवीय इंटरफ़ेस
एजेंट को केवल चैट में ही नहीं रहना है।
कुछ एजेंटों को एक बोर्ड की आवश्यकता होती है. अन्य स्थिति और लॉग वाला एक पृष्ठ। "अनुमोदन" बटन के अन्य। अधिक इनलाइन टिप्पणियाँ. सीएलआई के अभी भी अन्य।
यूआई व्यवहार बदलता है। यदि किसी एजेंट को नियंत्रित करने का एकमात्र तरीका एक लंबा संदेश लिखना है, तो उपयोगकर्ता एजेंट को अस्पष्ट निर्देश देगा। हालाँकि, यदि वह योजना, अंतर, स्रोत, जोखिम और अगली कार्रवाई देखता है, तो वह सटीक रूप से हस्तक्षेप कर सकता है।
एक सभ्य एजेंट बुनियादी ढांचे में नियंत्रण सतहें शामिल हैं:
- वर्तमान स्थिति;
- संपादन योग्य योजना;
- निर्मित कलाकृतियाँ;
- अंतर;
- अनुमोदन अनुरोध;
- कालक्रम;
- स्टॉप बटन;
- पुनः प्रयास करें बटन;
- दृश्यमान अनुमतियाँ।
यह मामूली लगता है, लेकिन ऐसा नहीं है। "डरावना एआई" और "विश्वसनीय सहायक" के बीच का अंतर अक्सर बस इतना होता है कि बाद वाला आपको दिखाता है कि उसके हाथ कहां हैं।
मानसिक ढेर
यदि मैं इसे आज बनाऊं, तो न्यूनतम एजेंट स्टैक यह होगा:
- मॉडल: यदि आवश्यक हो तो तर्क, पीढ़ी, टूल कॉलिंग, मल्टीमॉडल।
- ऑर्केस्ट्रेशन: लूप, स्टेप, प्लानर, पॉलिसी, ह्यूमन-इन-द-लूप।
- टिकाऊ रनटाइम: वर्कफ़्लो, कतार, पुनः प्रयास, रोकें, फिर से शुरू करें।
- सैंडबॉक्स: कोड निष्पादन, पृथक फ़ाइल सिस्टम, सीमाएँ, कलाकृतियाँ।
- टूल परत: एमसीपी, आंतरिक एपीआई, ब्राउज़र, डेटाबेस, रिपॉजिटरी।
- पहचान परत: OAuth, दायरा, रहस्य, ऑडिट, नीति।
- मेमोरी परत: परियोजना संदर्भ, पुनर्प्राप्ति, निर्देश, समाप्ति।
- अवलोकनशीलता: ट्रेस, रीप्ले, मूल्यांकन, लागत और गुणवत्ता मेट्रिक्स।
- उत्पाद की सतह: जब पर्याप्त हो तब चैट करें, जब जरूरत हो तो डैशबोर्ड, जब महत्वपूर्ण हो तो समीक्षा करें।
एजेंटिक ढांचा मुख्य रूप से बिंदु 2 और बिंदु 1 का एक टुकड़ा शामिल करता है। बाकी असली काम है।
मैं व्यवहार में क्या करूंगा
यदि कोई टीम मुझसे कहती है कि "हमें उत्पादन में एजेंट चाहिए," तो मैं दस एजेंटों से शुरुआत नहीं करूंगा।
मैं एक छोटे, दोहराव वाले और अवलोकन योग्य वर्कफ़्लो के साथ शुरुआत करूँगा। उदाहरण के लिए: रखरखाव पीआर खोलें, बंद मुद्दों से दस्तावेज़ अपडेट करें, साप्ताहिक समीक्षा तैयार करें, डुप्लिकेट बग का परीक्षण करें, प्रभावित फ़ाइलों के लिए परीक्षण तैयार करें।
तब मैं बहुत स्पष्ट सीमाएँ निर्धारित करूँगा:
- शाखाओं या सैंडबॉक्स के बिना कोई लेखन नहीं;
- संकेत में कोई रहस्य नहीं;
- अनुमति सूची में उपकरण;
- बाहरी कार्यों के लिए मानवीय अनुमोदन;
- अनिवार्य लॉग और ट्रेस;
- प्रति रन बजट;
- आउटपुट हमेशा निरीक्षण योग्य।
तभी मैं विस्तार करूंगा.
एजेंट केवल इसलिए विफल नहीं होते क्योंकि मॉडल गलत हो जाते हैं। वे विफल हो जाते हैं क्योंकि हम उन्हें भ्रमित करने वाली अनुमतियों और नाटकीय अपेक्षाओं वाले अस्पष्ट वातावरण में डाल देते हैं।
मेरा पढ़ना
एजेंटिक बुनियादी ढांचा सबसे अच्छे तरीके से उबाऊ है।
यह वह हिस्सा नहीं है जो आपको डेमो में ताली बजाने पर मजबूर करता है। यह वह हिस्सा है जो आपको वास्तविक लोगों, वास्तविक डेटा और वास्तविक परिणामों के साथ सोमवार की सुबह डेमो का उपयोग करने देता है।
एजेंटों का भविष्य केवल इस बात से तय नहीं होगा कि किसके पास सबसे अच्छा रोल मॉडल है। यह उस व्यक्ति द्वारा तय किया जाएगा जो उसे काम करने के लिए सबसे अच्छी जगह बनाता है: जब वह प्रयोग करता है तो अलग हो जाता है, जब जरूरत होती है तो जुड़ा होता है, हमेशा देखने योग्य होता है, मानदंडों के साथ अधिकृत होता है और इतना विनम्र होता है कि जब उसे पता नहीं होता है तो रुक जाता है।
यहीं पर एजेंट खिलौना बनना बंद कर देते हैं और बुनियादी ढांचा बन जाते हैं।
स्रोत
METADATA
- date: 2026-06-30
- reading: 12 min
- author: Filippo Spinella
- tags: AI, Agents, Infrastructure, Developer Tools, Vercel