AI एजेंट ऑर्केस्ट्रेशन तब प्रोडक्शन-रेडी (Production Ready) माना जाता है जब आठ शर्तें पूरी होती हैं: एजेंट अलग-थलग वर्कस्पेस (Workspaces) में निष्पादित हों, प्रत्येक कोड परिवर्तन स्वचालित सत्यापन पास करे, परिभाषित चेकपॉइंट्स पर एक मानव इंजीनियर निर्णय ले, लागत को मर्ज किए गए कार्य की प्रत्येक इकाई के आधार पर आंका जाए, एजेंट निर्देश वर्शन-नियंत्रित फाइलों के रूप में हों, ऑर्केस्ट्रेटर किसी एक मॉडल वेंडर से बंधा न हो, डेटा रेजीडेंसी (Data Residency) स्पष्ट हो, और विफल हुए निष्पादन के लिए एक निर्धारित रिकवरी प्रक्रिया हो। एक पायलट प्रोजेक्ट को इनमें से किसी की भी आवश्यकता नहीं होती और फिर भी वह प्रभावशाली दिखता है। प्रोडक्शन को इन सभी आठों की आवश्यकता होती है, क्योंकि इनमें से प्रत्येक एक ऐसा विफलता मोड (Failure Mode) है जो केवल बड़े पैमाने पर ही सामने आता है। यह लेख वही चेकलिस्ट है, जिसमें बताया गया है कि एक असंतोषजनक उत्तर कैसा दिखता है, और आप अपने मौजूदा सिस्टम के विरुद्ध प्रत्येक बिंदु का परीक्षण कैसे कर सकते हैं।
मुख्य चेकलिस्ट
| # | आवश्यकता | पूछा जाने वाला प्रश्न | एक असंतोषजनक उत्तर |
|---|---|---|---|
| 1 | वर्कस्पेस आइसोलेशन | प्रत्येक एजेंट कहां लिखता है? | "रिपॉजिटरी चेकआउट में सीधे" |
| 2 | स्वचालित सत्यापन | किसी मानव के देखने से पहले क्या पास होना चाहिए? | "समीक्षक स्वयं टेस्ट चलाता है" |
| 3 | मानवीय चेकपॉइंट्स | कोई व्यक्ति ठीक किस जगह निर्णय लेता है? | "समीक्षक पीआर (PR) देखते हैं" |
| 4 | लागत का आवंटन | अंतिम मर्ज किए गए परिवर्तन की क्या लागत थी? | "हम मासिक API बिल देखते हैं" |
| 5 | वर्शन-नियंत्रित निर्देश | एजेंट के निर्देश कहां सुरक्षित हैं? | "चैट में पेस्ट किए गए प्रॉम्प्ट में" |
| 6 | वेंडर पोर्टेबिलिटी | यदि मॉडल बंद (deprecate) हो जाए तो क्या टूटेगा? | "हम प्रॉम्प्ट्स को दोबारा लिखेंगे" |
| 7 | डेटा रेजीडेंसी | किन पक्षों के पास कोड की प्रतिलिपि है? | "वेंडर इसे संभालता है" |
| 8 | रिकवरी | जब कोई रन बीच में ही विफल हो जाता है तो क्या होता है? | "कोई ध्यान देता है और सफाई करता है" |
इनका क्रम बहुत महत्वपूर्ण है। बिंदु 1 से 3 शुद्धता (Correctness) से जुड़े हैं: इनके बिना, उच्च वॉल्यूम दोषों (Bugs) को उस गति से उत्पन्न करता है जिसे मानवीय समीक्षा पकड़ ही नहीं पाती। बिंदु 4 से 6 स्थिरता और निरंतरता से जुड़े हैं: इनके बिना, सिस्टम चलता तो है लेकिन उसका न तो विश्लेषण किया जा सकता है और न ही उसे माइग्रेट किया जा सकता है। बिंदु 7 और 8 वे प्रश्न हैं जो सुरक्षा समीक्षा दल और ऑन-कॉल इंजीनियर आमतौर पर रोलआउट के बाद उठाते हैं।
1. वर्कस्पेस आइसोलेशन (Workspace isolation)
एक ही चेकआउट में संपादन करने वाले दो एजेंट एक-दूसरे के लिखे कोड को ओवरराइट कर देंगे, और परिणामी diff किसी भी योजना से मेल नहीं खाएगा। आइसोलेशन की प्राथमिक इकाई एक git worktree होनी चाहिए: अपनी शाखा (Branch) और इंडेक्स के साथ एक अलग वर्किंग डायरेक्टरी, जो मुख्य चेकआउट के साथ ऑब्जेक्ट स्टोर साझा करती है। इसे बनाना एक चेकआउट है, क्लोन नहीं, इसलिए इसमें पूरे इतिहास को फिर से डाउनलोड करने के बजाय सेकंड का एक छोटा हिस्सा लगता है।
# प्रति योजना एक डायरेक्टरी और एक ब्रांच।
git worktree add ../work/plan-4812 -b plan/4812
git -C ../work/plan-4812 status --short
git worktree remove ../work/plan-4812
जब एजेंट गैर-भरोसेमंद कोड चलाता है तो कंटेनर (Containers) एक मजबूत सीमा प्रदान करते हैं, और Docker का सुरक्षा मॉडल स्पष्ट करता है कि वह सीमा वास्तव में क्या गारंटी देती है। आपके अपने रिपॉजिटरी में काम करने वाले विश्वसनीय एजेंट के लिए, एक worktree आमतौर पर सबसे सही विकल्प है: क्रिटिकल पाथ पर कंटेनर शुरू किए बिना प्रति योजना पूर्ण अलगाव। समानांतर AI एजेंटों के लिए Git Worktrees विफलता मोड को कवर करता है, जिसमें साझा हुक और सबमॉड्यूल के मामले शामिल हैं जो टीमों को मुश्किल में डालते हैं।
परीक्षण करें: एक ही फाइल को छूने वाली दो योजनाएं शुरू करें और पुष्टि करें कि दोनों साफ और अलग-अलग diff उत्पन्न करती हैं।
2. मानवीय समीक्षा से पहले स्वचालित सत्यापन
एक समीक्षक जो ऐसा diff पढ़ रहा है जो संकलित (compile) भी नहीं होता, वह अपना समय बर्बाद कर रहा है। परीक्षण (Tests), लिंट, टाइप चेक, बिल्ड और योजना के विरुद्ध स्कोप चेक सभी एजेंट के worktree के भीतर चलने चाहिए और उनका आउटपुट परिवर्तन के साथ संलग्न होना चाहिए। यह निरंतर एकीकरण (Continuous Integration) है, जिसे प्रति शाखा के बजाय प्रति योजना लागू किया गया है।
दो गेट्स विशेष रूप से एजेंट आउटपुट के लिए होते हैं। एक स्कोप चेक (Scope check) योजना द्वारा नामित फाइलों के मुकाबले बदली गई फाइलों की तुलना करता है, क्योंकि एक एजेंट जिसे नल चेक (null check) ठीक करने के लिए कहा गया था, वह कभी-कभी पूरी फाइल को दोबारा फॉर्मेट कर देता है और वेरिएबल का नाम बदल देता है। एक सुरक्षा स्कैन OWASP Top 10 for LLM Applications में श्रेणियों की तलाश करता है: असुरक्षित आउटपुट प्रबंधन, आपूर्ति श्रृंखला में असुरक्षित पैकेज जोड़ना, लीक हुए क्रेडेंशियल। AI-जनित कोड के लिए सत्यापन गेट्स स्पष्ट करता है कि किन गेट्स को ब्लॉक करना चाहिए और किन्हें केवल सूचना देनी चाहिए।
परीक्षण करें: पूछें कि एजेंट परिवर्तनों का कितना प्रतिशत असफल परीक्षणों के साथ मानव तक पहुंचता है। यदि कोई नहीं जानता, तो सत्यापन गेट का कोई अस्तित्व नहीं है।
3. ठीक दो बिंदुओं पर मानवीय चेकपॉइंट्स
शून्य चेकपॉइंट का मतलब है कि एजेंट सीधे main शाखा में मर्ज करता है और त्रुटियां अन्य लोगों द्वारा खोजी जाती हैं। दस चेकपॉइंट का मतलब है प्रत्येक टूल कॉल को स्वीकृत करना, जो मनुष्य को सबसे धीमा घटक बनाता है और समीक्षकों को बिना सोचे-समझे स्वीकृति देने के लिए प्रशिक्षित करता है।
दो चेकपॉइंट मानवीय निर्णय को वहां रखते हैं जहां यह परिणाम को बदलता है। प्लान गेट वह स्थान है जहां किसी गलतफहमी को सुधारना सबसे सस्ता होता है, क्योंकि कोई कोड नहीं लिखा गया है और योजना केवल पाठ (Text) का एक पृष्ठ है। diff गेट वह स्थान है जहां सत्यापन आउटपुट के आधार पर शुद्धता की पुष्टि की जाती है। सॉफ्टवेयर फैक्ट्री क्या है पूरे क्रम का वर्णन करता है।
परीक्षण करें: उन दो पलों के नाम बताएं जब कोई व्यक्ति निर्णय लेता है। यदि उत्तर दो स्पष्ट बिंदुओं के बजाय गतिविधियों की एक विस्तृत श्रृंखला है, तो वहां कोई चेकपॉइंट नहीं है, केवल मैन्युअल निगरानी है।
4. प्रति मर्ज किए गए परिवर्तन पर लागत का आवंटन
मासिक API बिल आपको कोई कार्रवाई योग्य जानकारी नहीं देता है। ट्रैक करने योग्य संख्या प्रति मर्ज किए गए पुल रिक्वेस्ट (PR) की लागत है: उस अवधि में कुल खर्च (अस्वीकृत या छोड़ी गई योजनाओं सहित) को मर्ज किए गए पुल रिक्वेस्ट की संख्या से विभाजित किया जाना चाहिए। अस्वीकृत कार्य भी स्वीकृत कार्य की लागत का ही एक हिस्सा होता है।
इसे अस्वीकृति दर (denial rate) के साथ पढ़ें, यानी बिना मर्ज किए बंद किए गए पुल रिक्वेस्ट का अनुपात। इनमें से किसी भी संख्या को दूसरे को खराब करके अकेले सुधारा जा सकता है, यही कारण है कि DORA मेट्रिक्स को हमेशा एक जोड़ी के रूप में रिपोर्ट किया जाता है। AI कोडिंग एजेंट थ्रूपुट मापना प्रत्येक मीट्रिक को परिभाषित करता है और यह बताता है कि खराब रीडिंग का क्या अर्थ है।
परीक्षण करें: पिछले महीने के लिए प्रति मर्ज किए गए PR की लागत पूछें। यदि इसकी गणना केवल इनवॉइस से हाथ से की जा सकती है, तो इसका सक्रिय प्रबंधन नहीं किया जा रहा है।
5. वर्शन-नियंत्रित फाइलों के रूप में निर्देश
एजेंट का व्यवहार जो किसी चैट विंडो में पेस्ट किए गए प्रॉम्प्ट में रहता है, उसकी समीक्षा नहीं की जा सकती, diff नहीं देखा जा सकता, या रोलबैक नहीं किया जा सकता है। निर्देश रिपॉजिटरी में होने चाहिए, उसी कारण से जैसे The Twelve-Factor App में कॉन्फ़िगरेशन कोड के साथ रहता है: कोई भी परिवर्तन पुल रिक्वेस्ट में एक diff बन जाता है जिसे एक वरिष्ठ इंजीनियर अस्वीकार कर सकता है।
// निर्देश और मेमोरी वे फाइलें हैं जिन्हें ऑर्केस्ट्रेटर पढ़ता है,
// न कि बाइनरी में संकलित स्ट्रिंग्स। सोमवार को सीखी गई एक परंपरा
// मंगलवार को प्रत्येक एजेंट और प्रत्येक डेवलपर द्वारा लागू की जाती है।
interface Promptware {
program: string; // Program.md - इस चरण के निर्देश
memory: string[]; // Memory/ - इस कोडबेस के बारे में सीख
tools: string[]; // Tools/ - सीमित अनुमतियां
logs: string[]; // Logs/ - केवल-जोड़ने योग्य निष्पादन इतिहास
}
इसका मुख्य जोखिम ड्रिफ्ट (drift) है: एक एजेंट जो अपने स्वयं के निर्देशों को संपादित कर सकता है, वह उन्हें बदतर भी बना सकता है — उदाहरण के लिए, एक अस्थिर परीक्षण के बाद "असफल परीक्षणों को तीन बार तक पुनः प्रयास करें" नियम जोड़ना। वर्शनिंग इस पर नियंत्रण रखती है, क्योंकि संशोधन एक diff के रूप में समीक्षक को दिखता है। प्रॉम्प्टवेयर: एजेंट जो अपने स्वयं के निर्देशों में सुधार करते हैं इस जोखिम और मेमोरी के अत्यधिक विस्तार दोनों को कवर करता है।
परीक्षण करें: अपने एजेंट निर्देशों को रखने वाली डायरेक्टरी पर git log चलाएं। एक खाली परिणाम का अर्थ है कि निर्देश इंजीनियरिंग नियंत्रण के अधीन नहीं हैं।
6. मॉडल और एजेंटों के बीच पोर्टेबिलिटी
मॉडल वेंडर के शेड्यूल पर अप्रचलित (deprecate) होते हैं, आपके नहीं। एक ऑर्केस्ट्रेटर जो किसी एक प्रदाता पर निर्भर है, वह मॉडल बंद होने की सूचना को एक संकटकालीन माइग्रेशन प्रोजेक्ट में बदल देता है। जिस परत पर आपका नियंत्रण होना चाहिए वह वर्कफ़्लो है: चरण, गेट्स, चेकपॉइंट्स और मेमोरी। नीचे का निष्पादन इंजन प्रति योजना बदलने योग्य होना चाहिए, और टूल एक्सेस प्रत्येक एजेंट के लिए अलग इंटीग्रेशन के बजाय Model Context Protocol जैसे प्रकाशित इंटरफ़ेस के माध्यम से होना चाहिए।
पोर्टेबिलिटी आपको लागत के अनुसार रूट करने की अनुमति भी देती है। एक प्रारंभिक ट्राइएज कदम के लिए एक महंगे फ्रंटियर मॉडल की आवश्यकता नहीं होती है; एक आर्किटेक्चरल योजना के लिए हो सकती है। आप यह निर्णय केवल तभी ले सकते हैं जब मॉडल बदलना केवल कॉन्फ़िगरेशन का मामला हो, न कि कोड को फिर से लिखने का।
परीक्षण करें: एक योजना पर मॉडल बदलें और इसे चलाएं। यदि इसके लिए कोड परिवर्तन की आवश्यकता होती है, तो आपके पास एक हार्ड-कोडेड निर्भरता है, कॉन्फ़िगरेशन नहीं।
7. ज्ञात डेटा रेजीडेंसी (Data Residency)
आपके नियंत्रण से बाहर आपके रिपॉजिटरी की प्रत्येक प्रतिलिपि की एक सूची बनानी होगी, अनुबंध करना होगा और अंततः हटाना होगा। एक होस्टेड क्लाउड एजेंट रिपॉजिटरी को वेंडर के वातावरण में क्लोन करता है, जिससे आपके स्रोत पर कम से कम दो प्रोसेसर आ जाते हैं: एजेंट वेंडर और मॉडल प्रदाता। एक लोकल-फर्स्ट ऑर्केस्ट्रेटर में केवल एक होता है, और वह भी केवल कोड के उन हिस्सों के लिए जो प्रॉम्प्ट्स में दिखाई देते हैं।
यह केवल सुरक्षा का तर्क नहीं है बल्कि विधिक दायरे का तर्क है: यह निर्धारित करता है कि एक GDPR समीक्षा में कितने डेटा प्रोसेसिंग समझौतों को शामिल करना होगा, और क्या यूरोपीय संघ में डेटा रखना केवल एक प्रदाता सेटिंग है या एक जटिल वेंडर बातचीत। लोकल-फर्स्ट AI डेवलपमेंट उन सवालों पर चर्चा करता है जो एक सुरक्षा टीम पूछेगी।
परीक्षण करें: एक एजेंट रन के दौरान आपके कोड की प्रति रखने वाले प्रत्येक पक्ष की सूची बनाएं। यदि सूची आपकी अपेक्षा से अधिक लंबी है, तो सुरक्षा समीक्षा भी उसी निष्कर्ष पर पहुंचेगी।
8. एक निर्धारित रिकवरी पथ
बड़े पैमाने पर रन विफल होते हैं: निष्पादन के बीच में नेटवर्क टाइमआउट, एजेंट जो लूप में फंस जाता है, एक सत्यापन चरण जो कभी समाप्त नहीं होता। ऑर्केस्ट्रेटर के पास प्रत्येक के लिए एक स्वचालित उत्तर होना चाहिए, और उत्तर यह नहीं हो सकता कि "कोई ध्यान देगा और इसे ठीक करेगा।"
- विफल सत्यापन: कार्य वास्तविक विफलता आउटपुट के साथ एजेंट को वापस भेजा जाता है, सारांश के साथ नहीं, और पुनः प्रयास की सीमा तक उसी worktree में पुनः निष्पादित होता है।
- छोड़ा गया रन: Worktree और उसकी शाखा को हटा दिया जाता है, ताकि रुकी हुई योजना ऐसी कोई डायरेक्टरी न छोड़े जिससे बाद के रन बाधित हों।
- अनियंत्रित लागत या लूप: प्रति योजना टोकन और समय बजट जो निष्पादन को सक्रिय रूप से रोकता है, न कि तथ्य के बाद रिपोर्ट करता है।
- अधूरा दूषित स्टेट: चूंकि प्रत्येक योजना अपने worktree और शाखा की मालिक है, इसलिए एक विफल रन को केवल एक डायरेक्टरी हटाकर पूरी तरह से रीसेट किया जा सकता है। साझा कोडबेस में कुछ भी दूषित नहीं होता।
परीक्षण करें: किसी योजना के बीच में ही एजेंट प्रक्रिया को जबरन समाप्त (kill) करें। डिस्क पर क्या बचता है, और क्या अगली योजना पर इसका कोई प्रभाव पड़ता है?
Ivy Tendril इन आठों का उत्तर कैसे देता है
Ivy Tendril macOS, Windows और Linux के लिए एक लोकल-फर्स्ट डेस्कटॉप एप्लिकेशन है जो कोडिंग एजेंटों को योजना से लेकर समीक्षा किए गए पुल रिक्वेस्ट तक चलाता है। इसमें शामिल हैं: वर्कट्री-प्रति-योजना (1), प्रत्येक परिवर्तन के साथ टेस्ट, लिंट और diff निरीक्षण (Pro में CI आयात के साथ) (2), दो आवश्यक मानवीय चेकपॉइंट्स (3), प्रति योजना और प्रति कार्य लागत ट्रैकिंग (4), वर्शन-नियंत्रित फाइलों के रूप में प्रॉम्प्टवेयर इकाइयां (5), प्रति योजना कोई भी CLI एजेंट और मॉडल चुनने की स्वतंत्रता (6), कोड और लॉग्स जो आपकी मशीन को कभी नहीं छोड़ते (7), और पूर्ण विफलता आउटपुट और स्वचालित worktree सफाई के साथ पुनः प्रयास (8)।
curl -sSf https://cdn.ivy.app/install-tendril.sh | sh
Windows पर, irm https://cdn.ivy.app/install-tendril.ps1 | iex का उपयोग करें। Tendril Functional Source License के तहत निःशुल्क और स्रोत-उपलब्ध है; टीम सुविधाएं, ऑन-प्रिमाइसेस होस्टिंग, SSO और CI सत्यापन आयात Pro और Enterprise योजनाओं पर उपलब्ध हैं।
अक्सर पूछे जाने वाले प्रश्न (FAQ)
किसी टीम को इन आठ में से सबसे पहले किसे ठीक करना चाहिए?
पहले आइसोलेशन, फिर सत्यापन, फिर चेकपॉइंट्स। लागत और मेमोरी की समस्याएं परेशान करने वाली हैं; लेकिन एक ही चेकआउट में लिखने वाले दो एजेंट एक ऐसा दोष उत्पन्न करते हैं जिसका स्रोत कोई नहीं जान सकता, जो कहीं अधिक विनाशकारी और डीबग करने में कठिन है।
क्या यह चेकलिस्ट केवल कोडिंग एजेंटों के लिए विशिष्ट है?
विफलता मोड निश्चित रूप से कोडिंग एजेंटों के लिए विशिष्ट हैं। आइसोलेशन, स्कोप चेक और diff समीक्षा इसलिए मौजूद हैं क्योंकि आउटपुट एक साझा कोडबेस में परिवर्तन है। एक एजेंट जो केवल डेटा पढ़ता है, या जो अपने स्वयं के डेटाबेस में लिखता है, उसकी आवश्यकताएं अलग होती हैं।
इसके महत्वपूर्ण होने से पहले कितने एजेंट समानांतर में चल सकते हैं?
ठीक दो। एक चेकआउट में एक एजेंट को इनमें से किसी की भी आवश्यकता नहीं है। जिस क्षण दूसरा एजेंट समानांतर में चलता है, आइसोलेशन और लागत आवंटन अनिवार्य हो जाते हैं, और समीक्षा क्षमता निष्पादन गति के बजाय थ्रूपुट पर मुख्य बाधा बन जाती है।
क्या अधिक समानांतरता से थ्रूपुट अनिश्चित काल तक बढ़ता रहता है?
नहीं। कोड समीक्षा एक क्रमिक (serial) प्रक्रिया है, इसलिए आमडाहल के नियम (Amdahl's law) के अनुसार क्रमिक भाग अधिकतम सीमा निर्धारित करता है: उस बिंदु से आगे एजेंटों को जोड़ना जहां समीक्षक पूरी तरह संतृप्त हैं, मर्ज बढ़ाए बिना केवल लागत और अस्वीकृति दर को बढ़ाता है।
Ivy Tendril के साथ शुरुआत करें
क्या आप डेवलपर-स्तरीय समानांतर एजेंट ऑर्केस्ट्रेशन के लिए तैयार हैं?
- कोड एक्सप्लोर करें: GitHub पर Ivy Tendril देखें (ओपन सोर्स)।
- दस्तावेज़ पढ़ें: tendril.ivy.app पर इंटीग्रेशन गाइड पढ़ें।
- आर्किटेक्चर सत्र शेड्यूल करें: 30 मिनट के तकनीकी परामर्श के लिए renco@ivy.app पर संपर्क करें।