THE Loop Engineering का उत्तराधिकारी और वह वर्कफ़्लो जो आपके एजेंटों को 10x व्यापक चलाता है...
जो लोग मल्टी-स्टेप एजेंट बनाते हैं, उनमें से अधिकतर एक सीधी रेखा बनाकर रख देते हैं
स्टेप एक, स्टेप दो, स्टेप तीन। हर एक पिछले के खत्म होने का इंतज़ार करता है
यहाँ वो चीज़ है जो लगभग कोई नहीं जाँचता:
उन आधे स्टेप्स को कभी इंतज़ार करने की ज़रूरत नहीं थी
वे बस एक बार में एक काम को कतार में लगाते हैं, जब तक कि कॉन्टेक्स्ट विंडो भर न जाए और एजेंट भूल न जाए कि वह क्या कर रहा था
- यह इसलिए धीमा नहीं था क्योंकि मॉडल कमज़ोर था
- यह इसलिए धीमा था क्योंकि आपने एक रेखा खींच दी जहाँ काम वास्तव में एक ग्राफ़ था**
यह गाइड आपको उस रेखा से एक ऐसे ग्राफ़ तक ले जाती है जो एक पूरी टीम में फैल जाता है और अपने काम की जाँच खुद करता है
पाँच स्टेप्स। स्टेप 2 तक आप एक बना चुके होंगे -
यह आपको एक काम करने वाला ग्राफ़ देता है और उन जालों के नाम बताता है जो असली ग्राफ़ को तोड़ देते हैं, और मैं बताऊँगा कि मुश्किल हिस्से कहाँ शुरू होते हैं
अल्फ़ा से पहले - अधिक ताज़ा अल्फ़ा के लिए मेरे सबस्टैक को सब्सक्राइब करें ↓
अध्याय 0 - ग्राफ़ इंजीनियरिंग वास्तव में क्या है
एक महीने पहले फ़ील्ड लूप्स के बारे में बात कर रहा था।
पीटर स्टीनबर्गर ने इसे नौ शब्दों में पकड़ लिया:
https://x.com/steipete/status/2078277297791189132
एक लूप बेहतर होने का एक चक्र है:
कुछ करने की कोशिश करो → परिणाम जाँचो → समायोजित करो → फिर से करो
यही परमाणु है: एक एकल एजेंट एक चीज़ को बार-बार बेहतर बनाता है
(अगर आपने मेरा Loop Engineering अंश पढ़ा है, तो यह वही है)
https://x.com/0xCodila/status/2072329149520232639
लेकिन सिंगल लूप की एक ज्ञात विफलता है - एक सपोर्ट टीम एक फ़ीडबैक लूप को एक मीट्रिक से बाँधती है: टिकट रिज़ॉल्यूशन दर
यह संख्या महीनों तक बढ़ती है जबकि संतुष्टि गिरती है। बॉट ने समस्याओं को हल करने के बजाय टिकट जल्दी बंद करना सीख लिया
यह गुडहार्ट का नियम है। एक लूप केवल अपना मीट्रिक देख सकता है। यह नहीं पूछ सकता कि लक्ष्य सही है या नहीं, या अपने माप को बहते हुए नोटिस नहीं कर सकता।
इसका उत्तर बेहतर लूप नहीं है। यह लूप्स का एक ग्राफ़ है - एक नेटवर्क जहाँ चक्र एक-दूसरे को देखते और सुधारते हैं
एजेंटों के लिए, इसका मतलब एक चीज़ है:
एक एजेंट लिखना बंद करें जो सब कुछ एक लाइन में करता है - काम के
आकार
को डिज़ाइन करें - क्या किससे पहले चलता है, क्या एक ही समय पर चलता है, क्या इंतज़ार करता है।
नोड सोचते हैं। एज परिणाम ले जाती हैं
और Claude Code ने इन्हें सीधे बनाने के लिए टूलिंग शिप कर दी: डायनामिक वर्कफ़्लो
स्टेप 1 - उन एजों को देखें जो वहाँ नहीं हैं
एक ग्राफ़ के दो हिस्से होते हैं:
- एक नोड काम की एक इकाई है: एक एजेंट, एक काम, एक इनपुट, एक आउटपुट
- एक एज एक निर्भरता है: इस नोड का आउटपुट उस नोड के इनपुट को फीड करता है
हर कोई जो गलती करता है वह है "और फिर" को एक एज मान लेना।
"इस फ़ाइल को सारांशित करो
और फिर
मुझे मौसम बताओ"
मौसम सारांश नहीं पढ़ता।
ये दो स्वतंत्र काम हैं जिन्हें एक रैखिक स्क्रिप्ट बिना किसी कारण के जोड़ती है। प्रत्येक बिना किसी वजह पिछले का इंतज़ार करता है
वह आदत जो सब कुछ शुरू करती है:
हर "और फिर" के लिए पूछें - क्या अगला स्टेप वास्तव में पिछले स्टेप के आउटपुट को पढ़ता है?
- अगर हाँ → असली एज। क्रम बनाए रखें।
- अगर नहीं → कोई एज नहीं। इंतज़ार बेकार है। उन्हें एक साथ चलाएँ।
अगर दो बक्सों के बीच कोई डेटा नहीं जाता, तो वे स्वतंत्र हैं।
यही स्वतंत्रता है जिसका आप इस गाइड के बाकी हिस्से में फ़ायदा उठाएँगे
आपका सादा "A करो, फिर B करो, फिर C करो" वाला एजेंट पहले से ही एक ग्राफ़ है - बस सबसे दुखद: एक एकल श्रृंखला जहाँ अगर C अटक जाए, तो D कभी नहीं होता।
स्टेप 2 - अपना पहला ग्राफ़ बनाएँ (शुरू से अंत तक)
बहुत सिद्धांत हो गया। एक बनाएँ और उसे चलते हुए देखें।
शुरू करने से पहले:
- Claude Code v2.1.154+ (
claude --versionसे चेक करें) - एक भुगतान वाली योजना। Max, Team, या Enterprise पर, वर्कफ़्लो डिफ़ॉल्ट रूप से चालू रहते हैं। Pro पर, /config में Dynamic workflows रो को चालू करें
1. एक ऐसा रेपो खोलें जिसे आप जानते हैं।
एक असली रेपो, ताकि परिणाम का कुछ मतलब हो।
2. यह प्रॉम्प्ट पेस्ट करें (Anthropic द्वारा):
1src/routes/ के तहत हर रूट फ़ाइल में मिसिंग ऑथ चेक के लिए ऑडिट करने का एक वर्कफ़्लो बनाएँ। प्रति फ़ाइल एक एजेंट खड़ा करें, फिर प्रत्येक निष्कर्ष पर रिपोर्ट करने से पहले एक स्वतंत्र वेरीफ़ायर चलाएँ। शुरू करने के लिए अधिकतम 20 फ़ाइलों का विश्लेषण करें।
src/routes/ को अपनी फ़ाइलों के स्थान से बदलें। "अधिकतम 20" लाइन आपकी पहली रन को सस्ता रखती है।
3. "वर्कफ़्लो" को चमकते देखें।
Claude Code इसे हाइलाइट करता है: "डायनामिक वर्कफ़्लो का अनुरोध किया गया।" यह संकेत है कि एक ग्राफ़ बन रहा है, सामान्य चैट नहीं
4. योजना को स्वीकृत करें।
Claude एक JavaScript ऑर्केस्ट्रेशन स्क्रिप्ट लिखता है और पहले चरण दिखाता है। उन्हें पढ़ें, "हाँ, इसे चलाएँ" चुनें।
5. टीम को चलने दें।
प्रति फ़ाइल एक एजेंट, समानांतर में, जबकि आपका सत्र मुक्त रहे।
इसे लाइव देखने के लिए /workflows टाइप करें: scope, fan-out, verify, synthesize।
6. एक उत्तर पढ़ें।
बीस अलग-अलग चैट नहीं। एक रिपोर्ट - क्योंकि मध्यवर्ती परिणाम स्क्रिप्ट के वेरिएबल्स में रहते थे, आपके कॉन्टेक्स्ट में नहीं।
यह एक ग्राफ़ है।
एक वाक्य से एक दर्जन एजेंट।
"ज़ीरो टोकन" के दावे के बारे में जो आप सुनेंगे
समन्वय स्क्रिप्ट कोड है
इसलिए एजेंटों के बीच परिणाम पास करने से कॉन्टेक्स्ट फिर से खर्च नहीं होता जैसा कि चैट हैंडऑफ़ में होता है।
लेकिन एजेंट अभी भी उपयोग की लागत लेते हैं। एक वर्कफ़्लो की लागत सामान्य सत्र से काफी अधिक होती है।
बचत समन्वय में है, काम में नहीं। स्कोप्ड शुरू करें, उपयोग देखें, फिर विस्तार करें।
- इसे अपना बनाएँ
जब कोई रन अच्छी हो, तो s दबाएँ।
यह ~/.claude/workflows में सेव हो जाती है, नाम से फिर से चलाने योग्य
अब कार्य बदलें और आकार रखें। "मिसिंग ऑथ चेक" को "अनहैंडल्ड प्रॉमिसेज़" या "100 लाइनों से अधिक फ़ंक्शन" से बदलें
यह कितना दूर तक स्केल होता है (लेख का नाम)
एक वर्कफ़्लो रन 1,000 एजेंटों तक फैल सकता है, जिसमें एक बार में अधिकतम 16 काम कर सकते हैं
यहीं से "1000+ लूप्स इन वन विंडो" आता है - कोई रूपक नहीं, फ़ीचर की वास्तविक सीमा
- और स्केल ही मुद्दा है एक हज़ार एजेंटों का मतलब है एक ऐसा काम जिसे कोई एक कॉन्टेक्स्ट कभी संभाल नहीं सकता - एक साथ पूरा कोडबेस ऑडिट किया गया, एक माइग्रेशन जो हर फ़ाइल को छूता है, एक खोज जो समानांतर में एक हज़ार कोण चलाती है
16-एक-साथ की सीमा का मतलब सिर्फ इतना है कि टीम लहरों में चलती है, बिना आपके किसी एक की देखभाल किए सभी हज़ार को खत्म करती है
एक रन कैसे व्यवहार करता है और उसकी लागत क्या है यह देखने के लिए 20 से शुरू करें - फिर इसे खोलें - क्योंकि यह वह छत है जिसके खिलाफ कोई और नहीं बना रहा है
स्टेप 3 - वह हिस्सा जो वास्तव में टूटता है
आपने एक ग्राफ़ बनाया। यहाँ वह जगह है जहाँ असली ग्राफ़ गिरते हैं।
दो विफलताएँ सबसे ज़्यादा मायने रखती हैं
- विफलता एक: ग्राफ़ खुद से सहमत होता है
जब कोई एजेंट अपने काम की जाँच करता है, तो वह खुद पर आसानी जाता है। मॉडल अपने स्वयं के आउटपुट को पसंद करते हैं
इसलिए आप एज पर एक वेरीफ़ायर लगाते हैं - एक अलग नोड जो निष्कर्ष को डाउनस्ट्रीम जाने से पहले पुष्टि करता है।
पकड़ जो कोई नहीं बताता: वेरीफ़ायर को साफ़ कॉन्टेक्स्ट चाहिए
इसे वही बातचीत दें जो एक्ज़ीक्यूटर के पास थी, और यह सत्यापित नहीं कर रहा है। यह एक अलग फ़ॉन्ट में खुद से सहमत हो रहा है
एक कॉन्टेक्स्ट साझा करने वाले एजेंटों का एक ग्राफ़ एक कॉस्ट्यूम में एक सिंगल लूप है। यह उसी तरह विफल होता है - बाद में, अधिक खर्चीले ढंग से, नीचे जाते समय अधिक हरी बत्तियों के साथ
इसलिए वेरीफ़ायर एक ताज़ा नोड है - अपना स्वयं का कॉन्टेक्स्ट - एक असली सिग्नल की जाँच कर रहा है - न कि "क्या एजेंट ने कहा कि यह हो गया," बल्कि "क्या टेस्ट वास्तव में पास होता है"
- विफलता दो: एजेंट एक-दूसरे पर पैर रख रहे हैं
यह काल्पनिक नहीं है
जब Bun की टीम ने पहली बार एक बड़े पोर्ट को कई एजेंटों में फैलाया, तो रन संचालनात्मक रूप से विफल रहा और एजेंटों ने एक वर्कस्पेस में साझा git कमांड का उपयोग किया और एक-दूसरे को ओवरराइट कर दिया
समाधान संरचनात्मक था, चतुर प्रॉम्प्टिंग नहीं। उन्होंने असुरक्षित कमांड को प्रतिबंधित किया और प्रत्येक समूह को अपना अलग-अलग आइसोलेटेड वर्कट्री दिया
यह समानांतरता का असली सबक है - एक ही फ़ाइल लिखने वाले दो एजेंट रेस करते हैं
फैलाने से पहले, तीन सवालों के जवाब दें:
- प्रत्येक एजेंट कहाँ काम करता है?
- परिणाम कैसे मर्ज होते हैं?
- जब दो असहमत हों तो क्या होता है?
उस योजना के बिना एक ग्राफ़ स्केल नहीं करता - यह तेज़ी से विफल होता है
स्टेप 4 - इस सप्ताह बनाने के लिए छह ग्राफ़
विधि: असली एजें खोजें → फैलाएँ → स्वतंत्र कॉन्टेक्स्ट पर सत्यापित करें → वर्कर्स को आइसोलेट करें
///
इनमें से प्रत्येक वही आकार है, जो एक नए काम पर लक्षित है। कार्य पंक्ति बदलें और चलाएँ:
- सुरक्षा स्वीप - लापता ऑथ की खोज करने वाला प्रति फ़ाइल एक एजेंट, प्रत्येक हिट की पुष्टि करने वाला एक वेरीफ़ायर (वह जो आपने बनाया)
- /deep-research के साथ उद्धृत रिपोर्ट - पहले से शिप हो जाता है: आपके प्रश्न को कोणों में विभाजित करता है, समानांतर में खोज करता है, लिखने से पहले एजेंट एक-दूसरे का खंडन करते हैं
- एक मॉड्यूल पोर्ट करें - फ़ाइल दर फ़ाइल, टेस्ट एक गेट के रूप में, विफलताएँ वापस लूप की गईं
- प्रतिकूल डिफ़ रिव्यू - आकार के अनुसार रूटेड: छोटा बदलाव → एक पास; बड़ा बदलाव → पूर्ण समानांतर ऑडिट
- अनुसूचित इकोसिस्टम स्कैन - एक बार सेव करें, नाम से फिर से चलाएँ
- अज्ञात आकार की खोज - फ़ाइंडर समानांतर में चलते हैं, प्रत्येक परिणाम देखी गई हर चीज़ के खिलाफ जाँचा जाता है, जब तक कि दो राउंड में कुछ नया न मिले तब तक लूप करते रहें
///
छत कैसी दिखती हैhttps://simonwillison.net/2026/Jul/8/rewriting-bun-in-rust/
Bun का Zig-to-Rust पोर्ट इसी मशीनरी पर चला।
लगभग 50 वर्कफ़्लो, एक बार में अधिकतम 64 एजेंट समानांतर में। लगभग 535,000 लाइनें Zig, 11 दिनों में दस लाख से अधिक लाइनों Rust में बदल गईं।
इसकी लागत लगभग $165,000 उपयोग में थी, इसे पूरी चीज़ को डिज़ाइन और मॉनिटर करने के लिए एक मानव की ज़रूरत थी
और इसने सार्वजनिक आलोचना खींची कि क्या इतने सारे AI-निर्मित कोड की सुरक्षित रूप से समीक्षा की जा सकती है।
स्केल असली है। कीमत और निगरानी भी उतनी ही असली है
स्टेप 5 - वे एंकर जो ग्राफ़ को ईमानदार रखते हैं
अकेला टोपोलॉजी सच नहीं खरीदता
एक-दूसरे की पुष्टि करने वाले एजेंटों का एक नेटवर्क, जिनमें से कोई भी वास्तविक चीज़ को नहीं छूता, बिल्कुल उसी तरह विफल होता है जैसे सिंगल लूप - बस अधिक चलने वाले हिस्सों के साथ
ग्राफ़ को एंकर चाहिए: ऐसे नोड जिनसे बहस नहीं की जा सकती
- टेस्ट जो वास्तव में चले - न कि "पास होने चाहिए," हुए पास
- एक वेरीफ़ायर सबूत पर, भावना पर नहीं
- जमे हुए नियम जिन्हें एजेंट कभी ट्यून नहीं कर सकते - क्योंकि वे वही हैं जिन्हें एक ऑप्टिमाइज़र कमज़ोर करेगा
ग्राफ़ उतना ही ईमानदार है जितनी उसमें वे चीज़ें हैं जो हिलने से इनकार करती हैं
जब ग्राफ़ गलत चुनाव है
अधिकांश कार्य ग्राफ़ नहीं होते। जब आपको इसकी ज़रूरत न हो तब एक के लिए पहुँचना सिर्फ पैसे जलाता है और विफल होने के तरीके जोड़ता है।
ग्राफ़ छोड़ें जब:
- कार्य छोटा या पृथक है। एक फ़ंक्शन जोड़ना, एक बग ठीक करना। यहाँ एक वर्कफ़्लो पूरी तरह से ओवरहेड है - एक एकल एजेंट तेज़ और सस्ता है।
- आपको कड़ी निगरानी चाहिए। यदि आप अगले स्टेप के चलने से पहले हर स्टेप को पढ़ना और अनुमोदित करना चाहते हैं, तो ग्राफ़ का पूरा बिंदु (आपके बिना चौड़ा चलना) आपके खिलाफ काम करता है।
- आप अभी तक नहीं जानते कि आप क्या ढूँढ रहे हैं। खोजपूर्ण काम एक ऐसा एजेंट चाहता है जिसे आप चला सकें, एक ऐसी टीम नहीं जो समस्या को समझने से पहले एक योजना के लिए प्रतिबद्ध हो।
- स्टेप वास्तव में एक-दूसरे पर निर्भर करते हैं। यदि हर स्टेप पिछले स्टेप का आउटपुट पढ़ता है, तो यह एक वास्तविक श्रृंखला है। समानांतरता के पास पकड़ने के लिए कुछ नहीं है। एक वास्तविक अनुक्रमिक कार्य पर ग्राफ़ को थोपना सिर्फ शून्य गति के लिए समन्वय लागत जोड़ता है।
बताने वाली बात स्टेप 1 है। यदि आप बीच में कोई तीर न लगे दो बक्से नहीं खोज सकते, तो बनाने के लिए कोई ग्राफ़ नहीं है। यह एक लूप है, और एक लूप ठीक है।
एक ग्राफ़ चौड़ाई के लिए एक उपकरण है - स्वतंत्र काम, एक साथ किया गया
जब काम चौड़ा नहीं है, तो रेखा कभी समस्या नहीं थी...
बदलाव
एक प्रॉम्प्टर एक सवाल पूछता है। एक आर्किटेक्ट एक ग्राफ़ खींचता है।
रैखिक एजेंट कभी छत नहीं था।
यह पहला आकार था - जिस तक हर कोई पहुँचता है क्योंकि यह हमारे टाइप करने के तरीके से मेल खाता है: एक पंक्ति, एक बार में एक चीज़।
एक बार जब आप नोड और एज देख लेते हैं, तो आप एजेंट से और अधिक करने के लिए कहना बंद कर देते हैं और ग्राफ़ से इसे और व्यापक करने के लिए कहना शुरू कर देते हैं:
- फैलाएँ जहाँ काम स्वतंत्र है
- एज पर गेट लगाएँ जहाँ विश्वास मायने रखता है
- उन नोड को फ्रीज़ करें जो सत्य रखते हैं
अधिकांश लोग कदमों को एक पंक्ति में कतारबद्ध करते रहेंगे।
कुछ लोग जो ग्राफ़ खींचना सीखते हैं, और उसे तोड़ने वाली चीज़ों का सम्मान करते हैं, एक टीम चलाएँगे।
ग्राफ़ खींचे। आर्किटेक्ट बने रहें।
शर्त के साथ शुरू करें:
- एकल लूप जिस पर यह बना है
