मैंने 6 स्टेप्स, 5 प्रॉम्पट्स और 1 फाइल का उपयोग करके 1,000 AI एजेंट्स चलाए (बिल्डर्स गाइड)

प्रॉम्प्टिंग 2024 में खत्म हो गई। नई कुशलता है ऑर्केस्ट्रेशन

मैंने 30 दिनों तक 1,000 AI एजेंट चलाए और यहाँ मुझे जो मिला

वह कुशलता जिसने प्रॉम्प्टिंग की जगह ले ली, और वे सिस्टम जो आप आज चला सकते हैं।

अपने प्रॉम्प्ट को ऑप्टिमाइज़ करना बंद करें। यह अब बाधा नहीं है।

एक चैट विंडो में एक एजेंट के साथ, प्रॉम्प्ट ही पूरा खेल होता है।

दस एजेंट घंटों तक चलने के साथ, प्रॉम्प्ट एक मामूली बात भर रह जाता है।

काम की गुणवत्ता तय करती है वह प्रणाली जो एजेंटों के आसपास बनी होती है:

• प्रत्येक कार्य किस मोड में चलता है
• कौन सा मॉडल कौन सा कदम उठाता है
• एजेंट कैसे समन्वित रहते हैं
• जब आप सो रहे हों तो "हो गया" कैसे सत्यापित होता है

एक प्रॉम्प्ट आपको एक आउटपुट देता है। एक लूप आपको एक संयोजन संक्रिया (compounding operation) देता है।

बदलाव सरल है। आप वह व्यक्ति नहीं रह जाते जो हर परिणाम पढ़ता है और अगला निर्देश टाइप करता है। आप वह व्यक्ति बन जाते हैं जो एक बार सिस्टम डिज़ाइन करता है और उसे चलने देता है।

वह डिज़ाइन लेयर अब काम है। यहाँ बताया गया है कि इसे कैसे बनाया जाए।

आप ऑर्केस्ट्रेटर बनाते हैं, कोड नहीं

आप तीस एजेंटों को उनसे बात करके मैनेज नहीं करते। आप एक से बात करते हैं। वह एक ऑर्केस्ट्रेटर है, और वह बाकी सबको मैनेज करता है।

एक अच्छा ऑर्केस्ट्रेटर ठीक तीन काम करता है:

1. एक लक्ष्य को सीमित, स्वतंत्र रूप से जाँचने योग्य उप-कार्यों में विभाजित करता है।
2. प्रत्येक उप-कार्य को एक वर्कर को सौंपता है, एक संक्षिप्त ब्रीफ और स्पष्ट फ़ाइल स्वामित्व के साथ।
3. परिणामों को इकट्ठा करता है और तय करता है कि आगे क्या होगा।

एक नियम सबसे ऊपर है: ऑर्केस्ट्रेटर स्वयं काम कभी नहीं करता।

जिस क्षण आपका लीड एजेंट इम्प्लीमेंटेशन कोड लिखना शुरू करता है, उसका कॉन्टेक्स्ट विवरण से भर जाता है और वह पूरे काम का सूत्र खो देता है।

इसका कॉन्टेक्स्ट साफ रखें। यह सोचता है, विभाजित करता है, असाइन करता है, और जाँचता है। और कुछ नहीं।

फिर गहराई में जाएँ, चौड़ाई में नहीं:

• ऑर्केस्ट्रेटर को सीधे आठ वर्कर न बनाने दें। इससे उसका कॉन्टेक्स्ट बिखर जाता है।
• इसके बजाय, इसे दो या तीन लीड बनाने दें।
• प्रत्येक लीड को अपने दो या तीन विशेषज्ञ बनाने दें।

इसका लाभ है समान कॉन्टेक्स्ट लागत पर तीन गुना अधिक डीकम्पोज़ीशन गहराई। एक वास्तविक संगठन इसी तरह स्केल करता है, लेयरों के माध्यम से, न कि एक व्यक्ति द्वारा हर कार्य असाइन करने से।

सत्यापन योग्य या नहीं: वह विभाजन जो सब कुछ तय करता है

कुछ भी बनाने से पहले, कार्य के बारे में एक प्रश्न पूछें। क्या कोई मशीन जाँच सकती है कि यह हो गया है?

यह उत्तर आपका पूरा दृष्टिकोण तय करता है।

यदि कार्य सत्यापन योग्य है, तो आप इसे लूप कर सकते हैं:

• टेस्ट पास होते हैं या नहीं होते।
• टाइप चेकर हरा है या नहीं है।
• बेंचमार्क सीमा को पार करता है या नहीं करता।

एक एजेंट को सत्यापन योग्य कार्य पर लगाएँ और वह रात भर उस पर चढ़ाई करता रहेगा। आप एक हल समस्या के साथ जागते हैं।

यदि कार्य सत्यापन योग्य नहीं है, तो अकेला लूप आपको नहीं बचाएगा। उदाहरण:

• एक अच्छा इवल डिज़ाइन करना।
• यह तय करना कि क्या कोई API सही लगता है।
• यह निर्णय करना कि क्या कोई शोध दिशा आगे बढ़ाने लायक है।

इनके लिए, आप स्वाद (taste) डालते हैं। आप लक्ष्य सौंपकर चल नहीं सकते, क्योंकि रुकने के लिए कोई द्वार नहीं है।

इसलिए कदम यह है कि जितना संभव हो उतना काम सत्यापन योग्य बनाएँ:

• "इसे अच्छा बनाओ" को "इन विशिष्ट जाँचों को पास करो" में बदलें।
• अस्पष्ट लक्ष्यों को ठोस, मापने योग्य लक्ष्यों से बदलें।
• जहाँ आप नहीं कर सकते, वहाँ एक इंसान को लूप में रखें और मार्गदर्शन करें।

अधिकांश ऑर्केस्ट्रेशन इंजीनियरिंग अस्पष्ट लक्ष्यों को जाँचने योग्य लक्ष्यों में बदलना है, ताकि लूप अपने आप चल सके।

सबसे छोटे वास्तविक सिस्टम से शुरू करें: एक गोल लूप

गोल लूप एक स्थायी उद्देश्य और एक नियतात्मक जाँच है। एजेंट एक बार रुकने के बजाय एक लक्ष्य की ओर कदम दर कदम काम करता है।

पूरा सिस्टम आपके एजेंट और एक वैलिडेटर के चारों ओर एक लूप है:

1i=0
2until npm test -s; do
3  agent -p "लक्ष्य: टेस्ट सूट को हरा (green) बनाना।
4            कोड पढ़ें और कुछ भी बदलने से पहले पूरी तस्वीर बनाएँ।
5            'npm test' फेल हो रहा है। पास होने की ओर सबसे छोटा बदलाव करें।"
6  (( ++i > 20 )) && { echo "रुकें: 20 पुनरावृत्तियाँ"; exit 1; }
7done

वैलिडेटर कोई भी कमांड है जिसका एग्जिट कोड द्वार है। टेस्ट, टाइपचेक, लिंट, या एक कस्टम स्क्रिप्ट।

दो चीज़ें अनिवार्य हैं:

1. एक सीमा (cap)। बिना रुकने की शर्त वाला लूप वह है जिससे आप पाँच अंकों के टोकन बिल के साथ जागते हैं।
2. एक पहले-पढ़ने का निर्देश। हर एजेंट की डिफ़ॉल्ट विफलता मोड कोड को पढ़ने के बजाय पहले संभावित फिक्स पर एक यादृच्छिक प्रहार करना है।

पढ़ने को मजबूर करें। यह प्रति कदम धीमा है, लेकिन समग्र रूप से कहीं अधिक तेज़ है।

"हो गया" को अनिवार्य बनाएँ: जज

एजेंट जल्दी छोड़ देते हैं। उन्हें प्रशिक्षित किया जाता है कि जैसे ही वे इसे सही ठहरा सकें, रुक जाएँ।

"मैंने अपनी पूरी कोशिश की, यहीं रुक रहा हूँ" और "हो गया" एक बात नहीं है।

अगर कोई एजेंट अपने होमवर्क को खुद ग्रेड करता है, तो वह धोखा देता है। दुर्भावना से नहीं। वह बस खुद को समझा लेता है कि काम खत्म हो गया है।

इसका समाधान एक अलग जज है:

• एक दूसरा एजेंट जिसका एकमात्र काम एक ठोस रूब्रिक के आधार पर काम को स्कोर करना है।
• यह एक प्रश्न का उत्तर देता है: हो गया या नहीं हुआ, और क्या कमी है।
• इसका रुकने में कोई हित नहीं है, इसलिए यह पीछे नहीं हटता।

बिल्डर और जज को अलग-अलग मॉडल परिवारों पर चलाएँ। अलग-अलग परिवार असंबद्ध गलतियाँ करते हैं, इसलिए जज वह देखता है जो बिल्डर को नहीं दिखता।

1while :; do
2  agent --model "$BUILD" -p "कार्य: $TASK। पहले पढ़ें, इम्प्लीमेंट करें, टेस्ट चलाएँ।"
3  verdict=$(agent --model "$JUDGE" -p "सख्त समीक्षक। rubric.md में हर आइटम के विरुद्ध स्कोर करें।
4            ठीक या तो 'PASS' या 'FAIL: <जो कमी है>' उत्तर दें।")
5  [[ $verdict == PASS* ]] && break
6done

रूब्रिक को ठोस और द्विआधारी (binary) बनाएँ:

• अच्छा रूब्रिक: "सभी टेस्ट हरे, माइग्रेशन शामिल, कोई डीबग लॉगिंग नहीं।"
• खराब रूब्रिक: "इसे अच्छा बनाओ।"

एक अल्पसंख्यक जाँचकर्ता जिसके पास वीटो है, वह एक चीज़ है जो रन को घंटों तक जारी रखने देती है, बजाय इसके कि जैसे ही वर्कर थक जाए, वह ढह जाए।

हर कार्य पूरा होने पर इसे चलाएँ। फिर आप कभी केवल हरे-समीक्षित काम ही देखेंगे।

और अधिक लूप जो आप वास्तव में उपयोग करेंगे

गोल लूप मूल पैटर्न है। कुछ विविधताएँ अधिकांश चीजों को कवर करती हैं जिन्हें आप चलाएँगे।

1. वैलिडेशन लूप।

करो, वैलिडेटर चलाओ, विफलता वापस खिलाओ, तब तक दोहराओ जब तक द्वार हरा न हो जाए।

इसे रिग्रेशन स्वीप, टाइप चेक, और किसी भी नियतात्मक पास या फेल के लिए उपयोग करें।

2. क्यू और रीसेट लूप।

काम को छोटे, परमाणु कार्यों की एक सूची में तोड़ें। एक बार में एक को संसाधित करें।

प्रत्येक कार्य के बाद, एजेंट को एक साफ कॉन्टेक्स्ट में रीसेट करें और अगला उठाएँ।

एक कॉन्टेक्स्ट जो घंटों चलता है, भ्रम से भर जाता है। रीसेट करने से प्रत्येक कार्य साफ रहता है।

मेमोरी एजेंट के बाहर रहती है, टास्क फ़ाइल और कमिट इतिहास में।

1while read -r task; do
2  agent -p "कार्य: $task। पहले पढ़ें। इम्प्लीमेंट करें, फिर टेस्ट चलाएँ।"
3  npm test -s && git commit -aqm "auto: $task"   # केवल हरे होने पर कमिट करें
4done < tasks.txt

3. मॉनिटर लूप।

एक एजेंट को सिग्नल्स की एक धारा पर लगाएँ और इसे वह सतह पर लाने दें जो मायने रखता है। खुले मुद्दे, असफल बिल्ड, त्रुटि लॉग, नई प्रतिक्रिया।

यह आपके पूछने की प्रतीक्षा नहीं करता। यह पढ़ता है, ट्राइएज करता है, और ऊपर रिपोर्ट करता है, या एक ड्राफ्ट फिक्स खोलता है।

1while sleep 300; do
2  agent -p "पिछले 5 मिनट के त्रुटि लॉग पढ़ें। यदि कोई नया पैटर्न दिखाई देता है,
3            तो न्यूनतम प्रतिलिपि (minimal repro) के साथ एक मुद्दा खोलें। अन्यथा 'कुछ नया नहीं' कहें।"
4done

4. प्लान-फिर-बिल्ड लूप।

लूप को दो चरणों में चलाएँ। पहले एक प्लानिंग पास जो एक लिखित योजना तैयार करता है और रुक जाता है।

आप योजना की समीक्षा करते हैं। फिर एक निष्पादन पास अनुमोदित योजना का पालन करता है।

योजना को ठीक करना सस्ता है। कोड को ठीक करना महँगा है। योजना में ही खराब दिशा को पकड़ें।

प्रॉम्प्ट जो काम करते हैं

प्रॉम्प्ट कोई इच्छा नहीं है। एक एजेंट के लिए, यह एक स्पेसिफिकेशन है।

औसत आउटपुट और उत्कृष्ट आउटपुट के बीच का अंतर लगभग पूरी तरह से इनकी गुणवत्ता पर निर्भर करता है।

पुन: प्रयोज्य प्रॉम्प्ट का एक छोटा सेट रखें। पाँच अधिकांश भार वहन करते हैं।

1. डीकम्पोज़ीशन प्रॉम्प्ट, ऑर्केस्ट्रेटर के लिए:

1आप ऑर्केस्ट्रेटर हैं। कोड न लिखें।
2इस लक्ष्य को 3 से 6 सीमित उप-कार्यों में तोड़ें।
3प्रत्येक के लिए: एक-पंक्ति ब्रीफ, इसके स्वामित्व वाली सटीक फ़ाइलें, और इसकी हो गया जाँच।
4किसी भी ऐसे कार्य को चिह्नित करें जो दूसरे पर निर्भर करता हो। सूची आउटपुट करें, फिर रुकें।
5लक्ष्य: <goal>

2. वर्कर ब्रीफ, एक विशेषज्ञ के लिए:

1आप केवल इन फ़ाइलों के मालिक हैं: <files>।
2कार्य: <one line>। तब हो गया जब: <verifiable check>।
3संपादन से पहले उन फ़ाइलों और उनके कॉलर को पढ़ें। अपनी फ़ाइलों के बाहर कुछ भी न बदलें।
4जब हो जाए, तो <name>.md में 5-पंक्ति की रिपोर्ट लिखें, फिर टेस्ट चलाएँ।

3. जज प्रॉम्प्ट, एक अलग मॉडल परिवार के लिए:

1आप एक सख्त, निर्दयी समीक्षक हैं। आपने यह कोड नहीं लिखा।
2नीचे दिए गए प्रत्येक आइटम के विरुद्ध रेपो को स्कोर करें। कोई चूक FAIL है।
3<rubric>
4ठीक एक पंक्ति में उत्तर दें: 'PASS' या 'FAIL: <जो कमी है>'।

4. प्लान-फर्स्ट प्रॉम्प्ट, प्लान मोड के लिए:

1<goal> के लिए एक लिखित योजना तैयार करें। इसमें शामिल करें: दृष्टिकोण, छूने वाली फ़ाइलें,
2किनारे के मामले, परीक्षण रणनीति, और आप क्या नहीं करेंगे।
3अभी तक कोई कोड न लिखें। योजना के बाद रुकें ताकि मैं इसकी समीक्षा कर सकूँ।

5. रिफ्लेक्ट-या-किल प्रॉम्प्ट, जब कोई एजेंट फँस जाए:

1आप एक ही जाँच में 3 बार असफल हुए हैं। दृष्टिकोण को दोहराना बंद करें।
23 पंक्तियों में उत्तर दें: वास्तव में क्या विफल हुआ, कौन सी धारणा गलत थी,
3और प्रयास करने के लिए सबसे छोटी अलग चीज़। फिर केवल वही प्रयास करें।

एक पैटर्न सभी पाँचों में चलता है। भूमिका, सीमाएँ, हो गया जाँच, और क्या नहीं करना है, बताएँ।

मॉडल रूटिंग: वह प्रश्न जो हर कोई पूछता है

प्रश्न आमतौर पर एक विकल्प के रूप में तैयार किया जाता है। क्या मैं महँगे मॉडल को प्लानिंग पर लगाऊँ या इम्प्लीमेंटेशन पर?

यह गलत ढाँचा है। इसके बजाय ब्लास्ट रेडियस (प्रभाव क्षेत्र) के आधार पर रूट करें। पूछें कि किसी गलती की कीमत आपको सबसे अधिक कहाँ चुकानी पड़ती है।

तर्क सरल है:

• प्लानिंग में एक बुरा निर्णय आपके पूरे बेड़े में फैल जाता है।
• एक सीमित, परीक्षित फ़ंक्शन में एक बुरी लाइन मिनटों में पकड़ी जाती है।
• इसलिए आप वहाँ खर्च करते हैं जहाँ त्रुटियाँ महँगी और अपरिवर्तनीय हैं, और वहाँ बचत करते हैं जहाँ वे सस्ती और नियंत्रित हैं।

यहाँ रूटिंग है, स्तर दर स्तर:

1. योजना, वास्तुकला, और अपघटन: शीर्ष स्तर, हमेशा। उच्चतम लाभ उठाने वाला, बहुत कम टोकन वॉल्यूम। यहाँ सस्ता होना सबसे महँगी गलती है जो आप कर सकते हैं।
2. एक तंग स्पेक के साथ कार्यान्वयन: मध्य स्तर, समानांतर में चलाएँ। स्पेक ने सोच-विचार कर लिया। परीक्षणों से सत्यापित करें।
3. एक ढीले स्पेक के साथ कार्यान्वयन: शीर्ष स्तर। अंतराल भरना तर्क है, और एक सस्ता मॉडल दर्जनों दिशाओं में गलत अनुमान लगाता है।
4. समीक्षा और निर्णय: एक अलग परिवार, और कोई सस्ता नहीं। यह वह जगह है जहाँ आप महँगी चूक को पकड़ते हैं।
5. नेविगेशन, खोज, सारांशीकरण, और वर्गीकरण: सबसे सस्ता, सबसे तेज़ मॉडल। शून्य तर्क, उच्च मात्रा। कभी भी grep के लिए प्रीमियम दरों का भुगतान न करें।

तो "सस्ती योजना या सस्ता कार्यान्वयन" का वास्तविक उत्तर न तो अंधाधुंध दोनों है।

योजना और समीक्षा पर हमेशा शीर्ष मॉडल। कार्यान्वयन वह चर है।

विभिन्न मॉडल परिवारों के भी अलग-अलग व्यक्तित्व होते हैं, और रूटिंग के लिए यह मायने रखता है:

• एक परिवार अंतराल भरता है। जब स्पेक ढीला होता है, तो यह उचित धारणाएँ बनाता है और चलता रहता है। यह तब मदद करता है जब धारणाएँ अच्छी हों, और तब नुकसान पहुँचाता है जब वे न हों।
• दूसरा परिवार शाब्दिक होता है। यह वही करता है जो आपने कहा और उससे थोड़ा अधिक, एक सटीक उपयोगिता चाकू की तरह।

गैप-फिलर का उपयोग वहाँ करें जहाँ काम खुला है और स्पेक ढीला है। शाब्दिक का उपयोग समीक्षा और सटीक, अच्छी तरह से निर्दिष्ट परिवर्तनों के लिए करें।

वह लीवर जो कार्यान्वयन को नियंत्रित करता है, आपका स्पेक है

• एक तंग स्पेक आपको सस्ते, समानांतर वर्कर चलाने का अधिकार देता है।
• एक ढीला स्पेक आपको अंतराल भरने के लिए एक महँगे मॉडल पर वापस जाने के लिए मजबूर करता है।

योजना में ठीक से निवेश करें ताकि आप निर्माण को सस्ता कर सकें।

एक जाल को उजागर करना उचित है। सस्ती रूटिंग प्रत्येक कॉल की कीमत को अनुकूलित करती है, लेकिन यह चुपचाप टोकन के उस हिस्से को नष्ट कर सकती है जो शिप किए गए, विलय योग्य आउटपुट का उत्पादन करता है।

एक सस्ता मॉडल जो पाँच बार पुन: प्रयास करता है और ऐसा कोड तैयार करता है जिसे आप मर्ज नहीं कर सकते, वह एक प्रीमियम मॉडल से एक साफ पास से अधिक महँगा है।

उपयोगी आउटपुट की लागत को मापें, प्रति कॉल लागत को नहीं।

पैमाने के लिए, दो संख्याएँ मदद करती हैं:

• आपका शीर्ष स्तर प्रति-टोकन आउटपुट मूल्य में एक सस्ते स्तर से लगभग पाँच गुना अधिक खर्च करता है।
• स्तरीय रूटिंग आमतौर पर अपने सबसे अच्छे मॉडल को हर जगह चलाने की तुलना में 40% से 60% तक खर्च कम करती है।

कौशल: एक वर्कफ़्लो को एक बार पैकेज करें, इसे हमेशा के लिए पुन: उपयोग करें

जब आप एक ही प्रॉम्प्ट को चिपकाते रहते हैं या एक ही वर्कफ़्लो चलाते रहते हैं, तो इसे एक कौशल में बदल दें।

एक कौशल एक छोटी निर्देश फ़ाइल है जिसे एजेंट केवल तभी लोड करता है जब वह प्रासंगिक हो।

आप वर्कफ़्लो को एक बार लिखते हैं, और हर एजेंट उस तक पहुँच सकता है।

एक कौशल फ़ाइल के दो भाग होते हैं:

• एक नाम और विवरण के साथ YAML फ्रंटमैटर।
• वास्तविक निर्देशों के साथ एक मार्कडाउन बॉडी।

विवरण सबसे महत्वपूर्ण पंक्ति है। यह एजेंट को बताता है कि कौशल क्या करता है और इसका उपयोग कब करना है, ताकि एजेंट इसे आपके नाम दिए बिना अपने आप उठा ले।

एक न्यूनतम कौशल फ़ाइल:

1---
2name: थर्मोन्यूक्लियर-रिव्यू
3description: गहरी, विरोधात्मक कोड समीक्षा। किसी भी गैर-तुच्छ परिवर्तन के बाद,
4  या मर्ज से पहले किसी डिफ की समीक्षा, ऑडिट, या सख्त करने के लिए कहने पर उपयोग करें।
5---
6
7# थर्मोन्यूक्लियर समीक्षा
8
9पूरा डिफ और वह फ़ाइलें पढ़ें जिन्हें वह छूता है। स्किम न करें।
10
11तीन पासों में समीक्षा करें:
121. शुद्धता: तर्क त्रुटियाँ, किनारे के मामले, रेस की स्थितियाँ, ऑफ-बाय-वन।
132. सुरक्षा: इंजेक्शन, प्रमाणीकरण, रहस्य, असुरक्षित इनपुट, विनाशकारी संचालन।
143. फिट: क्या यह मौजूदा वास्तुकला से मेल खाता है, या एक नया पैटर्न जोड़ता है?
15
16प्रत्येक निष्कर्ष के लिए: फ़ाइल, पंक्ति, गंभीरता, और एक-पंक्ति फिक्स।
17एक निर्णय के साथ समाप्त करें: SHIP या BLOCK, साथ ही पहले ठीक करने के लिए शीर्ष 3 चीज़ें।

अच्छे कौशल के नियम:

1. फ़ाइल को छोटा रखें। कुछ सौ पंक्तियों से नीचे। लंबी संदर्भ सामग्री को अलग फ़ाइलों में ले जाएँ जिन्हें कौशल इंगित करता है।
2. नाम को उसके फ़ोल्डर से मिलाएँ, अन्यथा यह लोड नहीं होगा।
3. ट्रिगर करने के लिए विवरण लिखें। "उपयोग करें जब" मामलों को स्पष्ट करें।
4. किसी एजेंट को कभी भी कौशल को फिर से लिखने न दें। एक मानव प्रत्येक पंक्ति को क्यूरेट करता है।

कौशल वह तरीका है जिससे एक वर्कफ़्लो संयोजित होता है। पहली बार जब आप किसी चीज़ को अच्छी तरह से हल करते हैं, तो आप उसे सहेजते हैं और खोजने योग्य बनाते हैं। उसके बाद का हर सत्र, यह मुफ़्त है।

अनेक चलाना: बेड़ा

एक बार एक लूप काम कर जाए, तो आप पैमाना बढ़ाते हैं।

प्रत्येक वर्कर को दो चीज़ें दें:

• अपना स्वयं का git वर्कट्री, ताकि कोई भी दो एजेंट कभी एक ही फ़ाइल को स्पर्श न करें।
• अपनी स्वयं की टर्मिनल विंडो, ताकि आप इसे देख सकें और इसे संदेश भेज सकें।

1tmux new-session -d -s fleet
2for name in hilbert gauss poincare; do
3  git worktree add -B "agent/$name" "../wt-$name" main
4  tmux new-window -t fleet -n "$name" -c "../wt-$name" "$AGENT"
5done

• अपने एजेंटों को नाम दें। पंद्रह चलाने पर, "agent_7" बेकार है।
• नाम आपको पूरे बेड़े को अपने दिमाग में रखने देते हैं। यह डेटा लेयर का मालिक है, वह इवल लिखता है, वह समीक्षा करता है।
• पठनीयता ही मुद्दा है। एक बेड़ा जिसे आप ट्रैक नहीं कर सकते, वह बेड़ा है जिसे आप चला नहीं सकते।
• फिर उन्हें सहयोग करने दें। डिफ़ॉल्ट रूप से, एजेंट एक-दूसरे को अनदेखा करते हैं और किसी सहोदर से किसी भी चीज़ को पृष्ठभूमि शोर मानते हैं।

ट्रिक एजेंटों के बीच संदेशों को उपयोगकर्ता मोड़ (user turns) के रूप में देना है। मॉडल उपयोगकर्ता को उत्तर देने और आसपास के संकेतों को अधिकांशतः अनदेखा करने के लिए प्रशिक्षित होते हैं।

1send() { tmux send-keys -t "fleet:$1" "$2" Enter; }
2send hilbert "GET /search?q= returns [{id,title,url}]। इसमें UI को वायर करें।"

वह एक कदम पृथक प्रक्रियाओं के ढेर को एक टीम में बदल देता है जो अनुबंध सौंपती है और एक-दूसरे को अनब्लॉक करती है।

आप शीर्ष पर रहते हैं। आप लीड को संदेश भेजते हैं, और लीड वर्कर्स को रिले करता है।

गतिशील वर्कफ़्लो: कोड के लिए समन्वय को संकलित करें

एक लूप समन्वय को मॉडल के अंदर रखता है। मॉडल प्रत्येक कदम तय करता है, जो टोकन जलाता है और उसके कॉन्टेक्स्ट को भरता है।

एक गतिशील वर्कफ़्लो इसे उलट देता है। ऑर्केस्ट्रेटर एक स्क्रिप्ट लिखता है जो वर्कर्स का समन्वय करती है, और एक अलग रनटाइम स्क्रिप्ट को पृष्ठभूमि में चलाता है।

मुख्य विचार यह है कि स्थिति (state) कहाँ रहती है। लूप, शाखाकरण, और मध्यवर्ती परिणाम स्क्रिप्ट के चरों में बैठते हैं, मॉडल की मेमोरी में नहीं।

यह आपको क्या खरीदता है:

• समन्वय की लागत शून्य मॉडल टोकन है, क्योंकि सादा कोड यह कर रहा है।
• आपका मुख्य कॉन्टेक्स्ट साफ रहता है। केवल अंतिम परिणाम वापस आता है।
• यह व्यापक रूप से फैलता है। एक बार में दसियों वर्कर, एक रन में एक हजार तक।

इसके लिए कब पहुँचें:

• पैटर्न ज्ञात है और सत्यापन उद्देश्यपूर्ण है।
• काम व्यापक और दोहराव वाला है। कई फ़ाइलें, कई मामले, कई एंडपॉइंट।
• यह बिना निगरानी के चल सकता है।

इसके लिए कब नहीं पहुँचें:

• आप अभी भी पता लगा रहे हैं कि क्या करना है। वह एक गोल लूप है, वर्कफ़्लो नहीं।
• कार्य को तर्क की एक सुसंगत श्रृंखला की आवश्यकता है। उसे एक मजबूत एजेंट चाहिए, एक हजार नहीं।

एक ठोस आकार। मान लीजिए कि आपको 200 फ़ाइलों को एक नए API में माइग्रेट करने की आवश्यकता है:

1// ऑर्केस्ट्रेटर इसे एक बार लिखता है; एक रनटाइम इसे चलाता है, मॉडल नहीं
2const files = await glob("src/**/*.ts");
3
4const results = await mapLimit(files, 16, async (file) => {
5  const r = await subagent(`${file} को नए API में माइग्रेट करें। इसके टेस्ट चलाएँ।`);
6  return { file, ok: r.testsPassed };
7});
8
9const failed = results.filter(r => !r.ok);
10return `माइग्रेट ${results.length} में से ${results.length - failed.length}। ` +
11       `पुन: प्रयास: ${failed.map(f => f.file).join(", ")}`;

पढ़ें कि यह क्या करता है:

1. यह 200 फ़ाइलों को मॉडल के दिमाग में नहीं, बल्कि कोड में सूचीबद्ध करता है।
2. यह एक बार में 16 सबएजेंट चलाता है, प्रत्येक एक फ़ाइल को माइग्रेट करता है और उसके टेस्ट चलाता है।
3. यह प्रति फ़ाइल पास या फेल को एक सादे सरणी में रिकॉर्ड करता है।
4. यह एक छोटा सारांश लौटाता है। 200 मध्यवर्ती प्रतिलेख कभी भी आपके कॉन्टेक्स्ट को स्पर्श नहीं करते।

यह पूरी बात है। मॉडल ने एक बार सोचा, स्क्रिप्ट लिखने के लिए। स्क्रिप्ट ने मुफ्त में समन्वय किया।

गार्डरेल: बेड़े को खुद को खाने से क्या रोकता है

मानव बाधा (bottleneck) वास्तविक काम करता था। मानव गति पर, गलतियाँ जल्दी चोट पहुँचाती हैं और आप चलते-चलते उन्हें ठीक करते हैं।

खुद को पूरी तरह से हटा दें और छोटी त्रुटियाँ आपके महसूस करने से तेज़ी से बढ़ती हैं। यहाँ एक दोहराव, वहाँ एक अनावश्यक अमूर्तता।

एक दिन वास्तुकला झुकेगी नहीं, और आपके परीक्षण अविश्वसनीय होंगे क्योंकि एजेंटों ने उन्हें भी लिखा था।

नीचे दिया गया प्रत्येक गार्डरेल उस सुधार को बदल देता है जो बाधा प्रदान करती थी:

1. अनुमान लगाने से पहले पढ़ें। इसे हर बिल्ड प्रॉम्प्ट में एक स्थायी नियम बनाएँ, न कि प्रति-कार्य अनुरोध।
2. सीमा और मार डालो। हर लूप को एक पुनरावृत्ति सीमा मिलती है। हर एजेंट को एक टोकन बजट मिलता है जो लगभग 85% पर ऑटो-पॉज़ करता है। एक ही त्रुटि पर तीन फँसी हुई पुनरावृत्तियों के बाद, एजेंट को मारें और कार्य एक नए को सौंपें।
3. एक फ़ाइल, एक मालिक। वर्कट्री के साथ अलग करें। कभी भी दो एजेंटों को एक ही फ़ाइल संपादित न करने दें।
4. मिशन को फिर से इंजेक्ट करें। लंबे रन पर, हर कुछ मिनटों में एक उपयोगकर्ता संदेश के रूप में चेकलिस्ट पोस्ट करें ताकि एजेंट अपने कॉन्टेक्स्ट भरने पर बहाव न करे।

1while sleep 900; do
2  send gauss "याद दिलाना: अभी भी कार्य पर? पहले पढ़ें। प्रत्येक परिवर्तन के बाद टेस्ट चलाएँ। अपनी फ़ाइलों में रहें।"
3done &

सबसे गहरा बिंदु इस सब के नीचे बैठता है:

• सत्यापन अब बाधा है, उत्पादन नहीं।
• एजेंट आपके जाँचने की तुलना में तेज़ी से प्रशंसनीय आउटपुट तैयार करते हैं।
• प्रशंसनीय सही नहीं है।

जब तक आपका सत्यापन आपकी पीढ़ी जितना तेज़ नहीं है, मानव समीक्षा ओवरहेड नहीं है। यह सुरक्षा प्रणाली है।

मेमोरी: आप दीर्घकालिक भंडारण हैं

एक मॉडल के पास अल्पकालिक स्मृति है, संदर्भ विंडो, और कुछ नहीं। उस विंडो के पीछे की हर चीज़ चली जाती है जब तक कि आप इसे अपने साथ नहीं ले जाते।

इसलिए अपने आप को, और जिन फ़ाइलों को आप रखते हैं, उन एजेंटों के लिए दीर्घकालिक स्मृति के रूप में मानें जिनके पास केवल अल्पकालिक स्मृति है।

दो आदतें मायने रखती हैं।

पहला, संदर्भ द्वारा राज्य पास करें, सारांश द्वारा नहीं:

• जब कोई कॉन्टेक्स्ट भर जाता है, तो आलसी फिक्स इसे संक्षेप में प्रस्तुत करना है। सारांश हानिपूर्ण होते हैं और उस विवरण को छोड़ देते हैं जिसकी आपको बाद में आवश्यकता होगी।
• इसके बजाय, एजेंटों को फ़ाइलों, कार्य रिकॉर्ड और पिछले आउटपुट की ओर इंगित करें जिन्हें वे फिर से पढ़ सकते हैं। कुछ भी महत्वपूर्ण चुपचाप फेंका नहीं जाता है।

दूसरा, स्थायी मेमोरी को एजेंट के बाहर रखें:

• स्थितियों के साथ एक कार्य फ़ाइल।
• एक चल रहा प्रगति लॉग।
• कमिट इतिहास।
• एक दीर्घकालिक नोट्स फ़ाइल जो पैटर्न और समस्याओं को एकत्र करती है।

डिज़ाइन करें जैसे कि आपके एजेंट दिनों तक चलेंगे, क्योंकि अच्छे संघनन (compaction) के साथ वे चलेंगे।

मॉडल अभी तक अपने बारे में यह नहीं जानते हैं। वे एक छोटे बजट के अंदर सब कुछ हल करने की ओर एक पूर्वाग्रह रखते हैं, जैसे कि टोकन खर्च करना घातक हो। आपका मचान (scaffolding) ही उन्हें सूत्र खोए बिना लंबे समय तक चलने देता है।

टोपोलॉजी: कितने एजेंट, और किस आकार में

अधिक एजेंटों का मतलब अधिक आउटपुट नहीं है। एक बिंदु के बाद यह कम है, क्योंकि समन्वय मुफ्त नहीं है और यह हर एजेंट को जोड़ने के साथ बढ़ता है।

जो नियम मायने रखता है वह है काम के आकार को काम से मिलाना:

• अनुक्रमिक, आश्रित तर्क कम एजेंट चाहता है, कभी-कभी एक। तर्क की एक एकल श्रृंखला को विभाजित करने से तर्क खंडित होता है और परिणाम खराब होता है।
• स्वतंत्र, समानांतर काम चाहता है कि आप फैलें। सपाट टोपोलॉजी, साफ फ़ाइल स्वामित्व। यह वह जगह है जहाँ समानांतरता भुगतान करती है।
• एक समन्वित टीम तीन से पांच वर्कर चाहती है। टोकन लागत मोटे तौर पर आकार के साथ रैखिक रूप से बढ़ती है। समन्वय लागत बदतर बढ़ती है। तीन केंद्रित वर्कर पाँच बिखरे हुए वर्कर को हराते हैं।

तो कोई सैकड़ों कैसे चलाता है? एक विशाल बातचीत के रूप में नहीं जो खुद से बहस करती है।

वे उन्हें गहराई और स्वतंत्रता के रूप में चलाते हैं:

• कुछ एजेंट जिनसे आप वास्तव में बात करते हैं, प्रत्येक सीमित उप-कार्यों को सौंपता है जिन्हें समन्वय करने की आवश्यकता नहीं है।
• स्वतंत्र लूप के झुंड अपना काम कर रहे हैं और ऊपर रिपोर्ट कर रहे हैं।

पैमाना प्रतिनिधिमंडल गहराई और स्वतंत्रता से आता है। एक एकल सूत्र को चौड़ा करने से कभी नहीं।

नियंत्रण फ़ाइल: orchestration.md

आप शायद एक फ़ाइल रखते हैं जो एजेंटों को बताती है कि आपके रेपो में कोड कैसे लिखना है। शैली, समस्याएँ, वास्तुकला। इसे रखें।

हालाँकि, यह ऑर्केस्ट्रेशन के लिए गलत प्रश्न का उत्तर देती है।

फ़ाइल orchestration.md एक अलग प्रश्न का उत्तर देती है। यहाँ काम कैसे चलाया जाना चाहिए?

यह एक मानव-लिखित अनुबंध है जो कवर करता है:

• किस कार्य के लिए किस मोड का उपयोग करना है
• कौन सा मॉडल स्तर कहाँ जाता है
• गार्डरेल क्या हैं
• मानव को कब बढ़ाना है

हर एजेंट इसे हर सत्र की शुरुआत में पढ़ता है और अपने दृष्टिकोण का चयन करने के लिए इसका उपयोग करता है।

यह रेपो में सबसे अधिक लाभ उठाने वाली फ़ाइल है। यह मोड-चयन निर्णय को आपके दिमाग से बाहर ले जाती है, जहाँ आप इसे हर सत्र में असंगत रूप से फिर से बनाते हैं, और एक स्पेक में डालती है जिसका बेड़ा पालन करता है।

एक छोटा संस्करण इस तरह दिखता है:

1# orchestration.md। यहाँ काम कैसे चलाया जाता है। मानव-क्यूरेटेड। एजेंटों को संपादित नहीं करना चाहिए।
2
3मोड चुनें:
4- गोल लूप (पर्यवेक्षित): अस्पष्ट या डिज़ाइन कार्य। पूर्णता जाँच को परिभाषित करें।
5- वैलिडेशन लूप: नियतात्मक द्वार। हमेशा पुनरावृत्तियों और लागत को सीमित करें।
6- बिल्ड प्लस जज: वर्कर बनाता है, एक अलग-परिवार का जज अनुमोदित करता है।
7- फ्लीट (तीन से पांच): अन्योन्याश्रित उप-कार्य, पृथक वर्कट्री, सहकर्मी संदेश।
8- क्यू और रीसेट: कई छोटे परमाणु कार्य, प्रत्येक ताजा कॉन्टेक्स्ट।
9- गतिशील वर्कफ़्लो: ज्ञात पैटर्न, उद्देश्यपूर्ण द्वार, व्यापक और दोहराव वाला। कोड में समन्वय, बिना निगरानी के।
10
11मॉडल को ब्लास्ट रेडियस द्वारा रूट करें:
12- योजना और वास्तुकला: शीर्ष स्तर, हमेशा।
13- बिल्ड, तंग स्पेक: मध्य स्तर, समानांतर, परीक्षणों से सत्यापित करें।
14- बिल्ड, ढीला स्पेक: शीर्ष स्तर, क्योंकि अंतराल भरना तर्क है।
15- समीक्षा और निर्णय: एक अलग परिवार। कभी भी कार्यान्वयनकर्ता का मॉडल नहीं।
16- नेविगेशन, खोज, सारांश: सबसे सस्ता। विलय योग्य आउटपुट को अनुकूलित करें, कॉल मूल्य को नहीं।
17
18गार्डरेल:
19- प्रति-एजेंट टोकन बजट। लगभग 85% पर ऑटो-पॉज़। 3 फँसे हुए प्रयासों के बाद मारें और पुन: असाइन करें।
20- एक घंटे से अधिक के किसी भी रन को एक अलग जज की आवश्यकता होती है। वर्कर कभी भी स्वयं-रिपोर्ट नहीं करते कि काम हो गया।
21- परिकल्पना करने से पहले कोड पढ़ें। पहले संपादन से पहले लिखित रूप में योजना बनाएँ।

दो नियम फ़ाइल को नियंत्रित करते हैं:

1. इसे छोटा रखें।
2. किसी एजेंट को कभी भी इसे फिर से लिखने न दें।

मूल्य यह है कि एक मानव ने प्रत्येक पंक्ति को क्यूरेट किया।

जो आपका रहता है

ऑर्केस्ट्रेशन एजेंटों को निष्पादित करने में विश्वसनीय बनाता है। यह समस्या नहीं चुनता, और यह नहीं जानता कि अच्छा कैसा दिखता है।

तीन चीज़ें स्थायी रूप से आपकी तरफ रहती हैं।

पहला, कार्यों को सौंपें, निर्णय को नहीं:

• एजेंटों को स्पष्ट पास या फेल मानदंड के साथ स्कोप किया गया काम सौंपें। बॉयलरप्लेट, माइग्रेशन, टेस्ट स्कैफोल्डिंग, और ऐसे दृष्टिकोण जिन्हें आप कभी हाथ से आजमाने का समय नहीं देंगे।
• वास्तुकला, क्या नहीं बनाना है का निर्णय, और पूर्ण-संदर्भ समीक्षा अपने पास रखें।
• एजेंटों ने औसत दर्जे की वास्तुकला का एक महासागर आत्मसात कर लिया है, और वे खुशी-खुशी भारी-भरकम पैटर्न को एक ऐसी परियोजना में कार्गो-कल्ट करेंगे जिसमें उन्हें नहीं होना चाहिए। ना कहना एक ऐसी सुविधा है जो उनके पास नहीं है।

दूसरा, आपका स्पेक ही लाभ है:

जब आप एक बेड़े में फैलते हैं, तो अस्पष्ट सोच आपको केवल धीमा नहीं करती—यह कई गुना बढ़ जाती है।

एक अस्पष्ट आवश्यकता दर्जनों समानांतर रनों में फैल जाती है, प्रत्येक अपनी दिशा में गलत होता है।

एक सटीक विनिर्देश हर जगह सटीक कार्यान्वयन में गुणा हो जाता है।

यही कारण है कि एक मजबूत इंजीनियर इन उपकरणों से अधिक लाभ उठाता है, कम नहीं। टाइपिंग स्वचालित हो गई। समझ को बढ़ाया गया।

अपना अधिकांश समय प्लान मोड में बिताएं—एक लिखित योजना पर जिस पर सभी सहमत हों, पहले संपादन से पहले।

तीसरा, जानबूझकर कम फंड करें:

• चार-एजेंट वाली नौकरी को दो एजेंटों से भरें। बाधा वांछित व्यवहार को मजबूर करती है।
• आप हाथ से काम करने के बजाय लूप बनाते हैं, और अगली बार वह काम पहले से स्वचालित होता है।
• अपना बजट मैनुअल प्रयास से टोकन पर स्थानांतरित करें। शुरुआत में उच्च निवेश, उसके बाद लगभग शून्य सीमांत लागत।

जो टीमें ऐसा करती हैं, वे संयोजित होती हैं। जो नहीं करतीं, वे हर बार पूरी कीमत चुकाती हैं।

आप अब सॉफ्टवेयर नहीं लिख रहे हैं। आप वह फैक्ट्री बना रहे हैं जो इसे लिखती है।

एक फैक्ट्री को सटीक इनपुट, हर स्टेशन पर गुणवत्ता नियंत्रण, और एक मालिक की आवश्यकता होती है जो जानता हो कि उत्पाद क्या होना चाहिए।

यहां से शुरू करें

सोमवार को सौ एजेंट चलाने की कोशिश न करें। सीढ़ी चढ़ें:

1. एक सत्यापन योग्य फिनिश लाइन वाले कार्य पर एक गोल लूप चलाएं। सीखें कि एक अच्छी पूर्णता जांच कैसी लगती है।
2. एक घंटे से अधिक की किसी भी चीज़ के लिए एक अलग मॉडल परिवार से एक जज जोड़ें। स्व-रिपोर्टेड पूर्णता पर प्रतिबंध लगाएं।
3. अपना orchestration.md लिखें। अपने एजेंटों को बताएं कि वे इसे पहले पढ़ें। उन्हें आपके लिए मोड चुनते हुए देखें।
4. सावधानी से फैलें। एक समानांतर कार्य, तीन से पांच कार्यकर्ता, पृथक वर्कट्री, टोकन बजट।
5. अपने मॉडलों को रूट करें। योजना और समीक्षा पर शीर्ष स्तर, सीमित बिल्ड और ग्राइंड पर सस्ता। मर्ज करने योग्य आउटपुट मापें।
6. एक बार पैटर्न मान्य और वस्तुनिष्ठ रूप से जांचने योग्य हो जाने पर इसे बिना निगरानी के चलने दें। रात भर बैकलॉग खाली करें।

सिस्टम को केवल दिशात्मक रूप से सही होना चाहिए, पूर्ण नहीं:

• नियंत्रण फ़ाइल बेड़े को स्व-निर्देशन के लिए पर्याप्त संरचना देती है।
• जज एज केस को पकड़ता है।
• रिमाइंडर लूप मेमोरी को संभालता है।
• आपकी स्वाद उन निर्णयों को संभालता है जो सौंपे नहीं जाते।

प्रॉम्प्टिंग पिछले साल का कौशल था। यह अब का कौशल है।

यहां के हर सिस्टम के चलने योग्य संस्करण—गोल लूप, जज लूप, फ्लीट लॉन्चर, मैसेज बस, रिमाइंडर वॉचडॉग और मॉडल राउटर—साथी किट में रहते हैं। एक वेरिएबल अपने एजेंट CLI पर सेट करें और चलें।

अस्वीकरण

यह लेख लेखक के Claude Code सत्रों और codex सत्रों का उपयोग करके लिखा गया था।

लेखक और Kimi K2.6 मॉडल द्वारा व्याकरणिक और स्वरूपण संबंधी मुद्दों के लिए संपादित।