प्रॉम्प्ट से एजेंटों के बेड़े तक का 14-चरणीय रोडमैप
ज्यादातर लोग जो मल्टी-स्टेप एजेंट बनाते हैं, वे एक सीधी रेखा पर ही पहुँचते हैं।
स्टेप एक, स्टेप दो, स्टेप तीन। हर एक विनम्रता से पिछले वाले के खत्म होने का इंतजार करता है।
और लगभग कोई नहीं जानता कि उनमें से आधे स्टेप्स को कभी इंतजार करने की जरूरत नहीं थी।
वे रूट नहीं करते। वे ब्रांच नहीं करते। वे पैरेललाइज़ नहीं करते। वे बस कतार में लग जाते हैं। एक हेड, एक कॉन्टेक्स्ट, एक बार में एक चीज़, जब तक विंडो भर न जाए और एजेंट भूल न जाए कि वह क्या कर रहा था।
यह 14-चरणीय रोडमैप है जो उस सिंगल-फाइल लाइन को एक ग्राफ में बदल देता है। एक ऐसा ग्राफ जो पूरे बेड़े में फैलता है, अपने निष्कर्षों को सत्यापित करता है, और एक ऐसे परिणाम पर एकत्रित होता है जिसे एक अकेला एजेंट कभी बनाए नहीं रख सकता।
अंत तक, आप तीन चीज़ें जान जाएंगे:
→ आपका मौजूदा सिस्टम कहाँ बिना वजह इंतज़ार कर रहा है → बिना विश्वास खोए काम को कैसे वितरित करें → गुणवत्ता को छुए बिना बिल कैसे कम करें
फ्रेमवर्क शिफ्ट जो कोई नहीं समझाता
एक प्रॉम्प्ट एक वाक्य है। एक लूप एक चक्र है। एक हार्नेस वह ज़मीन है जिस पर एजेंट खड़ा होता है।
लेकिन काम का आकार—क्या पहले चलता है, क्या एक साथ चल सकता है, क्या बाकी सबका इंतज़ार करना है—वह आकार एक ग्राफ है।
नोड्स सोचते हैं। एजेज़ परिणाम ट्रांसपोर्ट करते हैं।
और Claude Code के पास पहले से ही उन्हें सीधे बनाने के लिए टूलिंग है: डायनेमिक वर्कफ़्लोज़।
Claude सादे JavaScript में एक ऑर्केस्ट्रेशन स्क्रिप्ट लिखता है और फिर उसे निष्पादित करने के लिए सब-एजेंटों का एक समन्वित बेड़ा लॉन्च करता है। समन्वय में शून्य मॉडल टोकन खर्च होते हैं क्योंकि यह कोड है, बातचीत नहीं।
रोडमैप चार ब्लॉक में बंटा है:
→ 01 से 04, आपका पहले से मौजूद ग्राफ़ देखना → 05 से 08, बेड़े को चलाना → 09 से 11, जो निकले उस पर भरोसा करना → 12 से 14, यह सुनिश्चित करना कि यह आपको बर्बाद न करे
ब्लॉक 1 · अपना पहले से मौजूद ग्राफ़ देखना
01. नोड्स कार्य हैं, एजेज़ वह है जो बहता है
एक ग्राफ़ में ठीक दो चीज़ें होती हैं, और उनके बारे में स्पष्ट होना लगभग सारा भ्रम दूर कर देता है।
→ नोड: काम की एक इकाई। एक एजेंट, एक सीमाबद्ध कार्य, एक इनपुट, एक आउटपुट। → एज: एक निर्भरता। यह बताता है कि इस नोड का आउटपुट उस नोड के इनपुट को फीड करता है। बस इतना ही।
गलती "और फिर" को एक एज समझने की है।
"इस फ़ाइल को समरीज़ करो और फिर मुझे मौसम बताओ" के दोनों भागों के बीच कोई एज नहीं है। मौसम की रिपोर्ट समरी को कंज़्यूम नहीं करती। वे दो असंबद्ध नोड हैं जिन्हें एक लीनियर स्क्रिप्ट बिना किसी आवश्यकता के एक साथ जोड़ देती है।
एज तभी मौजूद होता है जब डेटा वास्तव में क्रॉस करता है।
इसे बक्से और तीर के रूप में बनाएं। एक बक्सा agent() को कॉल है। एक तीर एक वेरिएबल है जो एक कॉल के रिटर्न से निकलता है और दूसरे के प्रॉम्प्ट में प्रवेश करता है।
अगर आप तीर नहीं खींच सकते, अगर कोई वेरिएबल क्रॉस नहीं करता, तो वे दो बक्से स्वतंत्र हैं।
और वही स्वतंत्रता है जिसका आप अगले 13 चरणों में दोहन करने वाले हैं।
→ नियम: अपने एजेंट में हर "और फिर" के लिए पूछें कि क्या अगला चरण पिछले वाले का आउटपुट पढ़ता है। अगर नहीं, तो इंतज़ार बर्बाद समय है।
02. आपकी लीनियर स्क्रिप्ट पहले से ही एक ग्राफ़ है, बस एक डीजनरेट
जब आप एक एजेंट को "A करो, फिर B, फिर C, फिर D" के रूप में लिखते हैं, तो आप पहले ही एक ग्राफ़ खींच चुके हैं। बिना शाखाओं वाली एक श्रृंखला। प्रत्येक नोड में ठीक एक इनपुट एज और एक आउटपुट एज।
यह काम करता है। यह धीमी और नाजुक तरीके से भी चलता है क्योंकि एक श्रृंखला में कोई रिडंडेंसी नहीं है: अगर C अटक जाता है, तो D कभी नहीं होता, और A का काम अपस्ट्रीम में फंस जाता है जहाँ से जाने की कोई जगह नहीं।
ग्राफ़ इंजीनियरिंग का पहला वास्तविक कौशल है श्रृंखला को फिर से खींचना।
अपने लीनियर एजेंट को लें और प्रत्येक तीर के लिए, स्टेप 01 से सवाल पूछें।
अधिकांश श्रृंखलाओं में दो या तीन तीर होते हैं जो डेटा ट्रांसपोर्ट नहीं करते। वे केवल इसलिए हैं क्योंकि आपने उन्हें उसी क्रम में टाइप किया था।
उन तीरों को काटें और श्रृंखला कुछ व्यापक में बदल जाती है: कुछ स्वतंत्र नोड जो सभी एक साथ चल सकते हैं, एक ही नोड में फीड करते हैं जिसे वास्तव में उन सभी की ज़रूरत है।
इसकी कोई कीमत नहीं है, किसी नए टूल की ज़रूरत नहीं है, और आमतौर पर यह आपके द्वारा खरीदी जा सकने वाली किसी भी चीज़ से अधिक इंतज़ार खत्म करता है।
→ नियम: कुछ भी जोड़ने से पहले, उन एजेज़ को हटाएं जो डेटा ट्रांसपोर्ट नहीं करते।
03. प्रत्येक नोड को एक कॉन्ट्रैक्ट दें
एक ऐसा नोड जिसके बारे में आप तर्क नहीं कर सकते, वह एक ऐसा नोड है जिसे आप पैरेललाइज़ नहीं कर सकते।
समाधान एक कॉन्ट्रैक्ट है: सीमाबद्ध इनपुट, सीमाबद्ध आउटपुट, एक ही काम।
→ इनपुट वह है जो नोड पढ़ता है, स्पष्ट रूप से पास किया गया, कभी भी साझा विंडो से माना नहीं गया → आउटपुट एक परिभाषित आकार है, आदर्श रूप से मान्य, ताकि अगला नोड बिना अनुमान लगाए इसका उपभोग करे
वर्कफ़्लो में, वह कॉन्ट्रैक्ट एक स्कीमा के साथ लागू किया जाता है। जब आप Claude को JSON स्कीमा के साथ agent() कॉल देते हैं, तो सब-एजेंट मान्य स्ट्रक्चर्ड डेटा लौटाने के लिए बाध्य होता है। मान्यता टूल कॉल लेयर पर होती है, इसलिए जब यह फिट नहीं होता तो रीट्राई होती है, बजाय इसके कि फ्री टेक्स्ट लौटाया जाए जिसे आपको पार्स करना हो और उम्मीद करनी हो कि यह सही निकले।
1// एक वास्तविक कॉन्ट्रैक्ट वाला नोड: सीमाबद्ध इनपुट, मान्य आउटपुट, एक ही काम2const ITEM = {3 type: 'object',4 additionalProperties: false,5 properties: {6 title: { type: 'string' },7 url: { type: 'string' },8 impact: { type: 'string', enum: ['high', 'medium', 'low'] },9 },10 required: ['title', 'url', 'impact'],11};1213const output = await agent(source.prompt, {14 label: `research:${source.key}`,15 schema: ITEM,16 agentType: 'general-purpose',17});
यही फर्क है एक ऐसे नोड के बीच जिसे Claude एक ग्राफ़ में वायर कर सकता है और एक ऐसे नोड के बीच जो केवल तब काम करता है जब कोई इंसान इसे पढ़े।
→ नियम: अगर किसी नोड के आउटपुट का कोई आकार नहीं है, तो वह नोड नहीं है। वह एक बातचीत है।
04. एज भी एक कॉन्ट्रैक्ट है, और यह मुफ़्त है
एज का मतलब "B, A के बाद आता है" नहीं है। यह एक वादा है कि क्या क्रॉस करता है: A यह आकार उत्पन्न करता है, B इस आकार का उपभोग करने के लिए बनाया गया है।
जब आप एज को उसके क्रम के बजाय उसके डेटा से नाम देते हैं, तो दो चीज़ें आसान हो जाती हैं:
→ आप तुरंत देखते हैं कि एज वास्तविक है या नहीं, क्योंकि आप पूछ सकते हैं कि क्या कुछ इसके माध्यम से चलता है → आप ग्राफ़ को तोड़े बिना किसी भी सिरे पर नोड को बदल सकते हैं, जब तक आकार बनाए रखा जाए
व्यवहार में, एज सादे JavaScript में रहता है। फैन आउट और संश्लेषण के बीच कमी का चरण—फ़्लैटन करना, डीडुप्लिकेट करना, फ़िल्टर करना—सिर्फ कोड है जो आपके नोड्स द्वारा लौटाए गए आकारों पर काम करता है।
वहाँ किसी एजेंट की ज़रूरत नहीं है।
और यह ग्राफ़ में सोचने की एक मूक जीत है: लोग टोकन के लिए जो भुगतान करते हैं उसका एक क्रूर हिस्सा वास्तव में एक एज है, और एजेज़ मुफ़्त हैं।
प्रलोभन "परिणामों को संयोजित" करने के लिए एक एजेंट लॉन्च करने का है। इसका विरोध करें।
अगर संयोजन का मतलब फ़्लैटन और डीडुप्लिकेट करना है, तो वह एक flatMap और एक Set है। नियतात्मक, तत्काल, शून्य टोकन।
→ नियम: एजेंट निर्णय के लिए हैं, प्लंबिंग के लिए नहीं। एक ग्राफ़ जहाँ हर एज एक एजेंट है, अपने ही वायरिंग का किराया चुकाता है।
ब्लॉक 2 · बेड़े को चलाना
05. parallel() के साथ फैन आउट करें
यह वह कदम है जो बाकी सबके लिए भुगतान करता है।
जब आपके पास N स्वतंत्र नोड हों, N स्रोत जिनसे परामर्श करना हो, N फ़ाइलें जिनकी समीक्षा करनी हो, N रूट जिनका ऑडिट करना हो, तो आप उन्हें श्रृंखलाबद्ध नहीं करते। आप Claude को उन्हें फैलाने और एक ही समय में चलाने के लिए कहते हैं।
वर्कफ़्लो में, यह parallel() है: यह थंक्स की एक सरणी लेता है, प्रति थंक एक सब-एजेंट लॉन्च करता है, सभी एक साथ निष्पादित होते हैं, और परिणामों की सरणी लौटाता है।
दो विवरण इसे मजबूत बनाते हैं:
→ parallel() एक बैरियर है। यह लौटने से पहले सभी थंक्स की प्रतीक्षा करता है, इसलिए अगला चरण पूरा सेट देखता है। → एक थंक जो अपवाद फेंकता है, वह पूरे बैच को नीचे लाने के बजाय null में हल हो जाता है, इसलिए एक अस्थिर एजेंट निष्पादन को डुबा नहीं सकता।
यही कारण है कि आप हमेशा आउटपुट को .filter(Boolean) करते हैं।
समवर्तीता मोटे तौर पर आपके कोर की संख्या से सीमित होती है और अतिरिक्त कतारबद्ध हो जाता है, इसलिए आप सौ थंक्स पास कर सकते हैं और वे सभी समाप्त हो जाएंगे, बस मुट्ठी भर में।
1phase('Research');23const raw = await parallel(4 SOURCES.map((f) => () =>5 agent(f.prompt, {6 label: `research:${f.key}`,7 phase: 'Research',8 schema: ITEM,9 agentType: 'general-purpose',10 }),11 ),12);1314const collected = raw.filter(Boolean); // असफल एजेंटों से null हटाएं
और यहाँ महत्वपूर्ण हिस्सा है: फैन आउट कोड में रहता है जो Claude ने लिखा है, मॉडल के साथ बातचीत में नहीं।
Claude का अपना कॉन्टेक्स्ट कभी भी एक साथ नौ स्रोत नहीं रखता। प्रत्येक सब-एजेंट अपना खुद का लोड करता है, और केवल अंतिम प्रतिक्रिया वापस आती है।
यही वह चीज़ है जो सत्र को डुबोए बिना दसियों या सैकड़ों सब-एजेंटों तक स्केलिंग की अनुमति देती है। ऑर्केस्ट्रेशन लेयर में शून्य टोकन खर्च होते हैं क्योंकि यह Claude के सोचने का एक और दौर नहीं है।
→ नियम: अगर N चीज़ें एक-दूसरे को नहीं पढ़तीं, तो उन्हें कतारबद्ध न करें। उन्हें फैला दें।
06. एक बैरियर पर फैन को बंद करें
फैन आउट तभी काम करता है जब कोई इसे इकट्ठा करे।
फैन इन वह नोड है जहाँ एजेज़ एकत्रित होती हैं। जहाँ एक एजेंट, या कोड का एक टुकड़ा, एक साथ सभी अपस्ट्रीम परिणामों को देखता है और कुछ ऐसा करता है जिसके लिए पूरे सेट की आवश्यकता होती है: स्रोतों में डीडुप्लिकेट करना, प्रभाव के अनुसार छाँटना, जल्दी बाहर निकलना अगर बिल्कुल कुछ नहीं आया।
यह एकमात्र जगह है जहाँ एक बैरियर घड़ी के समय में अपनी लागत कमाता है।
सभी स्रोतों में डीडुप्लिकेट करना? बैरियर, सही।
सिर्फ एक सूची को फ़्लैटन करना? वह एक एज है, इसे इनलाइन करें।
1// एज: सादा JS, कोई एजेंट नहीं, शून्य टोकन2const flat = collected.flatMap((c) => c.items);3log(`Collected ${flat.length} elements`);45phase('Curate');67// बैरियर नोड: डीडुप्लिकेट और सॉर्ट करने के लिए पूरे सेट की आवश्यकता है8const curated = await agent(9 `Deduplicate and sort these by impact:10${JSON.stringify(flat)}`,11 { phase: 'Curate', schema: CURATED },12);
परीक्षण सरल है: अगर आपने parallel → transform → parallel लिखा है, और उस बीच के ट्रांसफ़ॉर्मेशन में तत्वों के बीच कोई निर्भरता नहीं है, तो आपको एक पाइपलाइन का उपयोग करना चाहिए था और पूरे बैरियर को छोड़ देना चाहिए था।
→ नियम: बैरियर तभी जब किसी चरण को वास्तव में सभी पिछले परिणामों की एक साथ आवश्यकता हो।
07. डायमंड: स्प्लिट, वर्क, मर्ज
फैन आउट और फैन इन को मिलाएं और आपके पास किसी भी गंभीर एजेंट ग्राफ़ की कार्य टोपोलॉजी है: डायमंड।
एक नोड कार्य को विभाजित करता है। कई नोड समानांतर में काम करते हैं। एक नोड इसे मर्ज करता है।
विहित रूप का एक नाम है जो याद रखने लायक है: फैन आउट → रिड्यूस → सिंथेसाइज़।
→ चौड़ाई पाने के लिए फैन आउट करें → इसे संपीड़ित करने के लिए सादे कोड से रिड्यूस करें → एक अंतिम एजेंट के साथ सिंथेसाइज़ करें जो प्रतिक्रिया लिखता है
यह बाजार स्कैन, निर्भरता ऑडिट, कोड समीक्षा और शोध रिपोर्ट का कंकाल है। आप स्रोतों और प्रॉम्प्ट को बदलते हैं और वही कंकाल अनुकूल हो जाता है।
जब आप डायमंड देखते हैं, तो आप "मैं अपने एजेंट को और अधिक कदम कैसे उठाऊं" पूछना बंद कर देते हैं और "स्प्लिट कहाँ है और मर्ज कहाँ है" पूछना शुरू कर देते हैं। जो वह सवाल है जो वास्तव में स्केल करता है।
→ नियम: चरणों को डिज़ाइन न करें। डिज़ाइन करें कि यह कहाँ विभाजित होता है और कहाँ जुड़ता है।
08. रनटाइम पर एज को रूट करें
सभी ग्राफ़ निश्चित नहीं होते। कभी-कभी लिया गया एज इस बात पर निर्भर करता है कि एक नोड ने क्या पाया।
एक राउटर नोड एक परिणाम का निरीक्षण करता है और तय करता है कि कौन सा पथ ट्रिगर किया गया है। यह टिकट को वर्गीकृत करता है और सही हैंडलर पर ब्रांच करता है। यह डिफ़ के आकार को देखता है और एक त्वरित समीक्षा या पूर्ण ऑडिट लॉन्च करने के बीच चुनाव करता है।
वर्कफ़्लो में, यह एक नोड के मान्य आउटपुट पर एक सरल JavaScript if या switch है, क्योंकि फ़्लो कंट्रोल कोड में रहता है।
1// राउटर नोड: एक एजेंट वर्गीकृत करता है, कोड एज चुनता है2const { severity } = await agent(3 `Classify the risk of this diff:4${diff}`,5 { schema: {6 type: 'object',7 properties: { severity: { enum: ['low', 'high'] } },8 required: ['severity'],9 }},10);1112let review;13if (severity === 'high') {14 review = await parallel(FILES.map((a) => () => agent(`Audit ${a}`)));15} else {16 review = await agent(`Quick review of ${diff}`);17}
यहाँ, नियतात्मकता एक विशेषता है, सीमा नहीं।
राउटर का निर्णय Claude से आ सकता है, लेकिन रूटिंग कोड है। यह एक ही वर्गीकरण के लिए हर बार एक ही तरह से चलता है।
नोड में मॉडल निर्णय, एज में स्क्रिप्ट विश्वसनीयता। कोई उभरती हुई आश्चर्य नहीं जैसे "एजेंट ने ऑडिट छोड़ने का फैसला किया," क्योंकि उस छोड़ को ग्राफ़ में लिखा जाना होता। और वह नहीं है।
→ नियम: मॉडल को तय करने दें कि यह क्या है, और कोड को तय करने दें कि इसके साथ क्या किया जाता है।
काउंटर-नियम (जारी रखने से पहले पढ़ें) एक ग्राफ़ चौड़ाई खरीदता है।
यह बेहतर निर्णय नहीं खरीदता।
अगर आपके काम के हर चरण को पिछले वाले की पूरी तस्वीर चाहिए, तो इसे एजेंटों के बीच वितरित करने से आपको बेहतर जवाब नहीं मिलता। यह आपको वही जवाब देता है, अधिक महंगा और बाद में। ग्राफ़ ठीक उसी क्षण भुगतान करना शुरू करता है जब काम उन कार्यों में विभाजित हो जाता है जो कभी एक-दूसरे के परिणाम नहीं पढ़ते। एक भी एजेंट जोड़ने से पहले, एकमात्र सवाल जो आपका बिल तय करता है वह है:
मेरा काम कहाँ विभाजित होता है?
अगर यह विभाजित नहीं होता है, तो एक एजेंट के साथ रहें और बाकी 6 चरणों को अपने ऊपर बचाएं।
ब्लॉक 3 · जो निकले उस पर भरोसा करना
09. एज पर एक वेरिफ़ायर रखें
ग्राफ़ का वास्तविक लाभ अधिक एजेंट होना नहीं है। यह वह संरचना है जिसे आप उनके चारों ओर बना सकते हैं ताकि विश्वास उत्पन्न हो सके।
एक वेरिफ़ायर नोड एज पर बैठता है, इससे पहले कि किसी परिणाम को नीचे जाने दिया जाए। इसका एकमात्र काम खोज को मारने का प्रयास करना है। अगर यह बच जाता है, तो यह गुज़रता है। अगर नहीं, तो यह कभी उत्तर तक नहीं पहुँचता।
और इस सबके नीचे एक कठोर नियम है: कभी भी उसी एजेंट को अपनी ही परीक्षा ग्रेड न करने दें। एक मॉडल अपने स्वयं के आउटपुट की समीक्षा करते हुए अपनी अधिकांश त्रुटियों को याद करता है क्योंकि वह उसी स्थान से मूल्यांकन कर रहा है जहाँ से उसने गलती की थी।
हाथ में रखने लायक तीन पैटर्न:
→ प्रतिकूल सत्यापन: प्रत्येक खोज के लिए, N स्वतंत्र संदेहवादियों को इसका खंडन करने के आदेश के साथ लॉन्च करें। यह तभी रहता है जब यह बहुमत से बच जाता है।
→ विविध लेंस सत्यापन: प्रत्येक वेरिफ़ायर को एक अलग कोण दें। सही, सुरक्षित, प्रतिलिपि करने योग्य। विविधता उन विफलता मोड को पकड़ती है जो N समान जाँचें कभी नहीं पातीं।
→ न्यायाधीशों का पैनल: विभिन्न कोणों से N प्रयास उत्पन्न करें, उन्हें समानांतर न्यायाधीशों के साथ स्कोर करें, विजेता से उन लोगों में से सर्वश्रेष्ठ को ग्राफ्ट करके संश्लेषित करें जो करीब आए थे।
यह एजेंटों के साथ किए गए सबसे महत्वाकांक्षी परियोजनाओं के पीछे का पैटर्न है, जैसे अंत में नहीं बल्कि लूप के भीतर ही प्रतिकूल समीक्षा के साथ एक पूरे रनटाइम को पोर्ट करना।
→ नियम: कोई भी खोज सत्यापन के बिना यात्रा नहीं करती, और दो वेरिफ़ायर कभी एक ही सवाल नहीं पूछते।
10. नोड्स को अलग करें ताकि विफलता ग्राफ़ को जहरीला न करे
एक श्रृंखला में, एक विफलता झरने की तरह फैलती है। C मर जाता है, D कभी नहीं चलता, सब कुछ रुक जाता है।
एक ग्राफ़ में, विफलता को अपने नोड में ही सीमित रहना चाहिए।
यह पहले से ही आंशिक रूप से सच है: parallel() के अंदर एक थंक जो विस्फोट करता है, वह null में हल हो जाता है, इसलिए आठ अच्छे एजेंट लौटते हैं जबकि बुरा अकेला गिरता है। आपका .filter(Boolean) ही रोकथाम है।
हर फैन इन को पूरे सेट को मानने के बजाय लापता इनपुट को सहन करने के लिए डिज़ाइन करें।
सबसे सूक्ष्म विफलता नोड्स का एक-दूसरे पर कदम रखना है। जब कई एजेंट समानांतर में फ़ाइलें लिखते हैं, तो वे टकराते हैं।
समाधान अलगाव है: प्रत्येक एजेंट अपने स्वयं के git वर्कट्री में चलता है, सैंडबॉक्स में अपना काम करता है, और फिर साफ-साफ मर्ज करता है।
इसका सहारा तभी लें जब नोड्स वास्तव में समानांतर में लिखते हैं। यह केवल उस टोपोलॉजी के लिए सीटबेल्ट है जिसे इसकी आवश्यकता है, हर निष्पादन पर डिफ़ॉल्ट टैक्स नहीं।
→ नियम: प्रति फ़ाइल एक ही लेखक। और हर फैन इन अंतराल को सहन करता है।
11. एक चक्र जोड़ें, लेकिन इसे अभिसरण करें
कभी-कभी आपको तब तक नहीं पता होता कि काम कितना बड़ा है जब तक आप उसके अंदर न हों। अज्ञात आकार की खोज। एक बग स्वीप जहाँ एक खोजने से तीन अन्य का पता चलता है।
इसके लिए एक चक्र की आवश्यकता है: पिछले नोड पर वापस एक नियंत्रित एज।
खतरा स्पष्ट है। एक चक्र जो अभिसरण नहीं करता, वह एक अनंत लूप है जो आपके बजट को पिघलने तक एजेंट लॉन्च करता रहता है।
जो पैटर्न अभिसरण करता है वह है सूखने तक लूप: K लगातार राउंड तक सर्चर लॉन्च करते रहें जब तक कुछ नया न मिले, फिर रुक जाएं।
और वह विवरण जो इसे बनाता या तोड़ता है, वह गलती जो लगभग हर कोई पहली बार करता है, वह है आप किसके खिलाफ डीडुप्लिकेट करते हैं।
सब कुछ जो देखा गया है, उसके खिलाफ डीडुप्लिकेट करें, न कि केवल जो पुष्टि की गई थी।
अन्यथा, अस्वीकृत खोजें हर राउंड में फिर से प्रकट होती हैं, लूप कभी सूखता नहीं है, और आपने एक ऐसी मशीन बनाई है जो उन्हीं मृत सिरों को हमेशा के लिए फिर से खोजने के लिए भुगतान करती है।
1const seen = new Set();2const confirmed = [];3let dryRounds = 0;45while (dryRounds < 2) { // 2 खाली राउंड के बाद रुकें6 const found = (await parallel(7 SEARCHERS.map((b) => () => agent(b.prompt, { schema: BUGS }))8 )).filter(Boolean).flatMap((r) => r.bugs);910 const newItems = found.filter((b) => !seen.has(key(b)));11 if (!newItems.length) { dryRounds++; continue; } // कुछ नया नहीं → सूखने की ओर1213 dryRounds = 0;14 newItems.forEach((b) => seen.add(key(b))); // देखे गए के खिलाफ डीडुप, पुष्टि नहीं1516 const judged = await parallel(newItems.map((b) => () =>17 parallel(['correct', 'security', 'repro'].map((lens) => () =>18 agent(`Judge "${b.desc}" from ${lens}. Is it real?`, { schema: VERDICT })))19 .then((v) => ({ b, real: v.filter(Boolean).filter((x) => x.real).length >= 2 }))20 ));2122 confirmed.push(...judged.filter((v) => v.real).map((v) => v.b));23}
→ नियम: हर लूप की एक राउंड सीमा होती है और वह सब कुछ जो देखा गया है, उसके खिलाफ डीडुप्लिकेट करता है।
ब्लॉक 4 · यह सुनिश्चित करना कि यह आपको बर्बाद न करे
12. नोड्स में मॉडल को स्टैगर करें
हर नोड को आपके सबसे अच्छे मॉडल की ज़रूरत नहीं है।
एक ग्राफ़ इसे एक तरह से स्पष्ट करता है जैसे एक अकेला एजेंट कभी नहीं करता। सीमाबद्ध और दोहराव वाले नोड होते हैं—इस फ़ील्ड को निकालें, इस टिकट को वर्गीकृत करें—और नोड होते हैं जहाँ वास्तविक निर्णय रहता है—रिपोर्ट को संश्लेषित करें, खोज का निर्णय करें।
उबाऊ वाले को सस्ते मॉडल पर चलाएं और महंगे टोकन को वहाँ खर्च करें जहाँ निर्णय मायने रखता है।
वर्कफ़्लो में, प्रत्येक सब-एजेंट आपके सत्र से मॉडल प्राप्त करता है जब तक कि स्क्रिप्ट इसे ओवरराइड न करे। डिफ़ॉल्ट रूप से, एक बड़ा निष्पादन पूरी तरह से आपके सत्र स्तर पर बिल करता है।
एक विशिष्ट agent() कॉल में model विकल्प उस नोड को कहीं और रूट करता है।
बड़े निष्पादन से पहले /model की समीक्षा करें, और फिर दोहराव वाले फैन-आउट नोड्स को डाउनग्रेड करें जबकि फ़्यूज़न नोड को उच्च रखें।
यह वह लीवर है जो एक टोकन-भूखे ग्राफ़ को उसके आकार को छुए बिना किफायती में बदल देता है।
→ नियम: महंगा मॉडल केवल वहाँ जहाँ निर्णय दांव पर है।
13. टोपोलॉजी आपकी लागत और आपकी विलंबता है
ग्राफ़ का आकार कॉस्मेटिक नहीं है। यह घड़ी के समय पर सबसे बड़ा लीवर है जो मौजूद है।
वह निर्णय जो सभी को फँसाता है: parallel() बनाम pipeline()।
→ parallel() बैरियर अगले चरण के शुरू होने से पहले सब कुछ सबसे धीमे नोड की प्रतीक्षा करवाता है → pipeline() प्रत्येक तत्व को बिना किसी बैरियर के सभी चरणों के माध्यम से स्वतंत्र रूप से प्रवाहित करने देता है। तत्व A चरण 3 में हो सकता है जबकि B अभी भी चरण 1 में है
तेज़ तत्व जल्दी समाप्त हो जाते हैं, धीमे के पीछे फंसने के बजाय।
डिफ़ॉल्ट रूप से, pipeline। बैरियर का सहारा तभी लें जब किसी चरण को वास्तव में एक साथ सभी पिछले परिणामों की आवश्यकता हो: सेट के खिलाफ डीडुप, कुल के आधार पर जल्दी बाहर निकलना, एक प्रॉम्प्ट जो "अन्य खोजों" के खिलाफ तुलना करता है।
"यह साफ़ दिखता है" और "चरण अलग महसूस होते हैं" कारण नहीं हैं। बैरियर विलंबता वास्तविक, मापने योग्य और बर्बाद समय है।
अलग होना सिंक्रोनाइज़्ड होने के समान नहीं है।
→ नियम: डिफ़ॉल्ट रूप से pipeline, उचित अपवाद द्वारा बैरियर।
14. Claude को ग्राफ़ बनाने दें
अंतिम कदम उन कामों के लिए हाथ से ग्राफ़ बनाना बंद करना है जिन्हें आप पहले से प्लान नहीं कर सकते।
डायनेमिक वर्कफ़्लो के साथ, आप लक्ष्य का वर्णन करते हैं और Claude स्वयं ऑर्केस्ट्रेशन स्क्रिप्ट लिखता है: कार्य को विघटित करता है, फैन आउट चुनता है, सब-एजेंटों का एक समन्वित बेड़ा लॉन्च करता है, और परिणाम को संश्लेषित करता है।
आपको एक विशिष्ट निष्पादन के लिए तैयार किया गया ग्राफ़ मिलता है, न कि एक निश्चित ग्राफ़ जिसे आपने उम्मीद की थी कि फिट होगा।
तीन प्रवेश बिंदु हैं:
→ अपने प्रॉम्प्ट में "workflow" शब्द कहें और Claude कार्य के लिए एक लिखता है → एक सहेजे गए या मानक को निष्पादित करें। /deep-research एक वास्तविक ग्राफ़ है जो प्रोडक्शन में चल रहा है: बाउंड → पैरेलल सर्च → फ़ेच → एडवरसैरियल वेरिफिकेशन → सिंथेसिस। बिल्कुल इस रोडमैप का कंकाल। → उस मोड को सक्रिय करें जो सत्र में हर महत्वपूर्ण कार्य के लिए वर्कफ़्लो की योजना बनाता है
जब कोई निष्पादन अच्छा जाता है, तो उसकी स्क्रिप्ट को .claude/workflows/ में सहेजें। संस्करणित, नाम से पुनः निष्पादन योग्य, और रिपॉजिटरी को क्लोन करने वाले किसी भी व्यक्ति द्वारा लॉन्च करने योग्य।
› src/routes/ में सभी रूट्स का ऑडिट करने वाला वर्कफ़्लो लॉन्च करें जो
लापता ऑथ की तलाश में है। प्रति रूट फ़ाइल एक एजेंट, और रिपोर्ट करने से पहले प्रत्येक खोज को सत्यापित करें।
● Claude ने एक ऑर्केस्ट्रेशन स्क्रिप्ट लिखी · बैकग्राउंड में लॉन्च…
/workflows — auth-audit · चल रहा है
✓ Bound 1/1 2.1k tok · 4s
✓ Fan-out 18/18 प्रति रूट फ़ाइल एक एजेंट
◯ Verify 11/18 प्रति खोज 3 वोटों पर संदेहवादी…
○ Synthesize 0/1 सत्यापन की प्रतीक्षा कर रहा है
सत्र प्रतिक्रियाशील बना रहता है, बेड़ा चलने के दौरान आप काम करते रह सकते हैं
→ नियम: अगर काम हर निष्पादन में आकार बदलता है, तो ग्राफ़ न बनाएं। इसका वर्णन करें।
इस सप्ताह बनाने के लिए छह ग्राफ़
सभी रूट्स पर सुरक्षा स्वीप। प्रति रूट फ़ाइल एक सब-एजेंट, प्रत्येक लापता ऑथ चेक की तलाश में, उसके बाद एक सत्यापन पास जो प्रत्येक खोज की पुष्टि करता है इससे पहले कि वह रिपोर्ट तक पहुँचे। वह चौड़ाई जिसे कोई एक कॉन्टेक्स्ट बनाए नहीं रख सकता।
/deep-research के माध्यम से स्रोतों के साथ रिपोर्ट। एक ग्राफ़ जो पहले से ही Claude Code के अंदर आता है। यह आपके प्रश्न को विभिन्न कोणों में विघटित करता है, समानांतर में खोज चलाता है, स्रोतों को डीडुप्लिकेट करता है, और लिखने से पहले तीन वोटों पर संदेहवादियों के साथ हर दावे का प्रतिकूल सत्यापन करता है।
एक मॉड्यूल को पोर्ट करना, फ़ाइल दर फ़ाइल। फ़ाइलों पर अनुवाद को फैलाएं, प्रत्येक के लिए परीक्षण सूट एक गेट के रूप में, और विफलताएं वापस लूप में जाती हैं। प्रतिकूल समीक्षा वह पकड़ती है जो एक एकल पास टूटा हुआ देता।
एक डिफ़ की प्रतिकूल समीक्षा। आकार के आधार पर रूट करें: एक छोटा परिवर्तन एक त्वरित पास प्राप्त करता है, एक बड़ा एक पूर्ण समानांतर ऑडिट को ट्रिगर करता है जिसमें विभिन्न लेंस का उपयोग करने वाले समीक्षक—सही, सुरक्षित, तेज़—और फिर न्यायाधीशों का एक पैनल संश्लेषित करता है।
निर्धारित इकोसिस्टम स्कैन। एक बार सहेजा गया और हमेशा के लिए पुनः निष्पादित। कई स्रोतों से समानांतर में परामर्श करता है—रिलीज़, ब्लॉग, फ़ोरम—एक बैरियर पर प्रभाव के अनुसार सॉर्ट करता है, और सारांश लिखता है। .claude/workflows/ में संस्करणित, नाम से लॉन्च करने योग्य।
अज्ञात आकार की खोज। आप नहीं जानते कि कितने बग हैं। समानांतर सर्चर, प्रत्येक नई खोज को सब कुछ देखे गए के खिलाफ डीडुप्लिकेट करें, उत्तरजीवियों का सत्यापन, और लूप तब तक जारी रहता है जब तक दो राउंड कुछ न दें। फिर रुकें।
अपना पहला ग्राफ़ लॉन्च करने से पहले चेकलिस्ट
→ क्या मैंने उन एजेज़ को हटा दिया है जो डेटा ट्रांसपोर्ट नहीं करते? → क्या काम वास्तव में विभाजित होता है, या हर चरण को पिछले वाले की आवश्यकता है? → क्या प्रत्येक नोड में सीमाबद्ध इनपुट, आकार का आउटपुट और एक ही कार्य है? → क्या मैं कुछ ऐसा करने के लिए एजेंट को भुगतान कर रहा हूँ जो flatMap है? → क्या कोई ऐसा बैरियर है जिसे पूरे सेट की आवश्यकता नहीं है? → क्या कोई खोज बिना किसी के इसे मारने की कोशिश किए परिणाम तक पहुँचती है? → क्या दो वेरिफ़ायर एक ही सवाल पूछते हैं? → क्या सभी लूप की एक राउंड सीमा है? → क्या एक ही फ़ाइल में एक से अधिक नोड लिख रहे हैं? → क्या दोहराव वाले नोड महंगे मॉडल पर चल रहे हैं?
अगर आप तीन से अधिक में असफल होते हैं, तो आपके पास ग्राफ़ नहीं है। आपके पास अधिक चरणों वाली एक श्रृंखला है।
निष्कर्ष
जो प्रॉम्प्ट करता है, वह एक सवाल पूछता है। जो आर्किटेक्ट करता है, वह एक ग्राफ़ बनाता है।
लीनियर एजेंट कभी छत नहीं था। यह सिर्फ पहला रूप था, वह जिसे हर कोई पकड़ लेता है क्योंकि यह उस तरीके से मेल खाता है जिस तरह हम लिखते हैं। एक पंक्ति, एक हेड, एक बार में एक चीज़।
जब आप नोड्स और एजेज़ को देखना शुरू करते हैं, तो आप एजेंट से और अधिक कदम उठाने के लिए कहना बंद कर देते हैं और ग्राफ़ से इसे व्यापक बनाने के लिए कहना शुरू कर देते हैं।
जहाँ काम स्वतंत्र है, वहाँ फैन आउट करें। जहाँ विश्वास मायने रखता है, वहाँ एजेज़ पर गेट्स लगाएं। जहाँ निर्णय दांव पर नहीं है, वहाँ सस्ते मॉडल का उपयोग करें।
अधिकांश एक सिंगल-फ़ाइल लाइन में कदमों को कतारबद्ध करते रहेंगे।
जो ग्राफ़ बनाना सीखते हैं, वे एक पूरा बेड़ा चलाएंगे। और वे कभी उस नीची छत पर ध्यान नहीं देंगे जिसके नीचे बाकी फंसे हुए हैं।
आज रात अपने मौजूदा सिस्टम को बनाएं। सिर्फ कार्य और उनके बीच के तीर। नकली एजेज़ को गिनें और उन्हें हटाएं।
यह पूरी कला का पहला कदम है, यह मुफ्त है, और यह आमतौर पर किसी भी खरीदे गए उपकरण से अधिक प्रतीक्षा को कम करता है।
