कई एजेंट चलाना

एक योजना पर एक एजेंट डिफ़ॉल्ट है, और यह अधिकांश काम को कवर करता है। कुछ काम एक सत्र से अधिक चौड़ा होता है: एक बदलाव जो कई रिपॉज़िटरीज़ को पार करता है, एक रिलीज़ जिसे क्रम में उतरना है, या एक बैकलॉग जिसमें एक एजेंट को कई दिन लगेंगे। DWP अपना अनुबंध बदले बिना उस काम तक विस्तार करती है। योजना सत्य का स्रोत बनी रहती है, हर कार्य अब भी अपने गेट पर बंद होता है, और अतिरिक्त एजेंट लेन होते हैं जिनका समन्वय एक लीड करता है।

यह अध्याय मॉडल का वर्णन करता है। यह तीन वैकल्पिक ऐडऑन का उपयोग करता है — पेन और पीयर्स के लिए Herdr, खातों के लिए agentkit, और कंटेनरों के लिए devcontainer — और एकल-एजेंट योजना के लिए इनमें से कोई भी आवश्यक नहीं है।

एक लीड और उसकी लेन

लीड पैरेंट योजना का स्वामी है। वह लेन तय करता है, हर लेन को उसका दायरा सौंपता है, माइलस्टोन एकत्र करता है, और वह अनुमति देता है जिससे कोई लेन मर्ज या रिलीज़ कर सके। वह किसी दूसरी लेन का कोड नहीं लिखता।

एक लेन एक दायरे वाला एक एजेंट है — आमतौर पर एक रिपॉज़िटरी। वह उस रिपॉज़िटरी का AGENTS.md पढ़ती है, उस रिपॉज़िटरी का गेट चलाती है, और अपनी योजना रिपॉज़िटरी के भीतर रखती है। एक ऑर्केस्ट्रेटर हब में, पैरेंट योजना हब की .dwp/plans/ में एक चाइल्ड ट्रैकिंग तालिका के साथ रहती है, और हर लेन की योजना अपनी रिपॉज़िटरी में रहती है, उस रिपॉज़िटरी के योजना ID और गेट का उपयोग करते हुए।

लेन कहाँ चलती हैं

एक लेन टर्मिनल पेन में एक एजेंट है, और पेन कई जगहों पर रह सकता है। Herdr हर एजेंट को एक पेन में रखता है और SSH के माध्यम से दूसरी मशीनों तक पहुँचता है, इसलिए लीड हर लेन को एक ही साइडबार में देखता है।

• होस्ट पर। हर लेन के लिए एक पेन, लीड के साथ-साथ। सबसे तेज़ सेटअप, उन रिपॉज़िटरीज़ के लिए जिनमें डेवलपर पहले से काम करता है।
• एक कंटेनर में। एक devcontainer-kit कंटेनर dck up पर Herdr मेश से जुड़ता है: उसके एजेंट होस्ट और दूसरे कंटेनरों तक पहुँचते हैं, और होस्ट उन तक पहुँचता है। कंटेनर ही sandbox है, इसलिए उसके एजेंट स्वायत्तता में चल सकते हैं।
• दूसरी मशीन पर। कोई भी मशीन जिस तक Herdr SSH से पहुँचता है, उसी तरह लेन होस्ट करती है, वहाँ भी herdr-peers इंस्टॉल होने के साथ।

स्थान अलगाव को बदलता है, प्रोटोकॉल को नहीं: कंटेनर में एक लेन और होस्ट पर एक लेन लीड के साथ एक ही तरह समन्वय करती हैं।

हेडरूम के आधार पर खाते और विक्रेता

कई एजेंट कोटा जल्दी खर्च करते हैं। हर लेन अपने खाते पर चलती है — coding-agents-kit में एक CLI और एक प्रोफ़ाइल — ताकि लेन एक ही विंडो को खाली न करें और किसी एक खाते के सीमा पर पहुँचने से एक लेन रुके, सभी नहीं।

• ak usage हर खाते और प्रोफ़ाइल पर बचा कोटा दिखाता है, हर बैच में एक बार।
• ak pick <kind> --count N सबसे अधिक गुंजाइश वाले N खाते लौटाता है, सबसे अच्छा पहले; --exclude किसी व्यस्त खाते को बाहर रखता है, --model एक मॉडल की विंडो गिनता है और --need पर्याप्त गुंजाइश के बिना शुरू करने से इनकार करता है।
• ak <kind> @<profile> लेन के एजेंट को उस खाते पर, उसके पेन में शुरू करता है।

विक्रेता भी इसी तरह मिलते हैं। एक Claude लेन लिख सकती है जबकि एक Codex लेन समीक्षा करती है, हर एक उस खाते पर जिसे ak pick ने उसके प्रकार के लिए चुना। एक कंटेनर लेन होस्ट के खातों का उपयोग कर सकती है: डेवलपर की devcontainer-kit होस्ट प्रोफ़ाइल में host_profiles चालू होने पर, कंटेनर को उन CLI की होस्ट प्रोफ़ाइलें मिलती हैं जिन्हें रिपॉज़िटरी इंस्टॉल करती है — Claude हर प्रोफ़ाइल के लिए एक दीर्घकालिक टोकन से, Codex अपनी auth फ़ाइल से — और उसे अपने लॉगिन की आवश्यकता नहीं होती। केवल अपने खातों का उपयोग करें और हर विक्रेता की शर्तों के भीतर रहें: काम को उनमें बाँटें, किसी सीमा से बचने के लिए खाते कभी न घुमाएँ।

बिना मनुष्य के लेन शुरू करना और उन्हें अनब्लॉक करना

एक लीड कीबोर्ड पर किसी के बिना लेन शुरू कर सकता है और उन्हें चलता रख सकता है। जब डेवलपर बिना निगरानी के संचालन की अनुमति दे चुका हो — एक स्थायी निर्देश या योजना की पूर्व-अनुमति — तो हर लॉन्च के लिए किसी और स्वीकृति की आवश्यकता नहीं होती। लीड Herdr के अपने कमांड्स का उपयोग करता है; kit का कोई कोड कीस्ट्रोक नहीं भेजता। प्रक्रिया का एक निश्चित क्रम है: एक बार तैयारी करें, प्रॉम्प्ट से बचें, रुकावट पहचानें, केवल एक ही मामले में कीज़ भेजें, बाकी को आगे बढ़ाएँ।

1. एक बार तैयारी करें, डेवलपर के रूप में। Claude Code हर प्रोफ़ाइल के लिए एक बार अपने bypass-permissions मोड की स्वीकृति माँगता है। वह bypass-permissions स्वीकृति डेवलपर का अपना कदम है, जो प्रोफ़ाइल बनाते समय लिया जाता है; devcontainer-kit कंटेनर में, kit उसे केवल कंटेनर की अपनी home डायरेक्टरीज़ में लिखता है। कोई भी एजेंट इसके लिए कभी कीज़ नहीं भेजता।
2. बचें। ak pick <kind> सबसे अधिक गुंजाइश वाले खाते का नाम बताता है, और herdr pane run <pane> 'ak <kind> @<profile> --trust-cwd' लेन को उसके अपने फ़ोल्डर में लॉन्च करता है। --trust-cwd (या AGENTKIT_TRUST_CWD=1) उस फ़ोल्डर को पहले से trusted कर देता है, इसलिए Claude और Codex बिना किसी कीस्ट्रोक के अपनी फ़ोल्डर-trust स्क्रीन छोड़ देते हैं।
3. पहचानें। herdr-peers lanes (या herdr agent list) हर लेन को working, idle, blocked या done के रूप में दिखाता है। जो लेन blocked है, या बिना आउटपुट के idle है, उसके लिए herdr-peers status <pane> उस स्क्रीन का वर्गीकरण करता है जिस पर वह है — फ़ोल्डर trust, bypass स्वीकृति, लॉगिन, अनुमति या अज्ञात — दस्तावेज़ित अगले कदम के साथ, और herdr pane read <pane> उसे दिखाता है।
4. एक कीस्ट्रोक, एक मामला। लीड केवल वही कीज़ भेज सकता है जो फ़ोल्डर-trust स्क्रीन का उत्तर हों, ऐसे पेन पर जिसे उसने स्वयं लॉन्च किया हो, जब --trust-cwd उपलब्ध न रहा हो। वह कीज़ भेजने से पहले स्क्रीन पढ़ता है, उत्तर देने के लिए न्यूनतम कीज़ भेजता है, और फिर से पढ़ता है।
5. बाकी सब पढ़ें, दर्ज करें और आगे बढ़ाएँ। Claude की bypass-permissions स्वीकृति, लॉगिन और क्रेडेंशियल प्रॉम्प्ट, प्रति-क्रिया अनुमति अनुरोध, विनाशकारी पुष्टिकरण, भुगतान या प्लान प्रॉम्प्ट, अज्ञात स्क्रीन और वे पेन जिन्हें लीड ने नहीं बनाया, डेवलपर के पास एक blocked माइलस्टोन के रूप में जाते हैं, कभी कीस्ट्रोक के रूप में नहीं।
6. opt-out हमेशा प्रभावी रहता है। AGENTKIT_PERMISSIONS=ask के साथ, लेन कार्य करने से पहले पूछती हैं, और लीड opt-out से आने वाले किसी प्रॉम्प्ट को कभी दरकिनार नहीं करता।
7. फिर से लॉन्च करें। यदि कोई एजेंट बंद हो जाता है, तो लीड उसे उसी खाते पर फिर से शुरू करता है, या दूसरा चुनता है। खोया हुआ लॉगिन एक क्रेडेंशियल प्रॉम्प्ट है: वह आगे बढ़ाया जाता है।

हर हस्तक्षेप — स्क्रीन ने क्या दिखाया, कौन-सी कीज़ भेजी गईं, उसके बाद क्या हुआ — पैरेंट योजना में दर्ज किया जाता है।

herdr-peers के माध्यम से समन्वय

लेन और लीड herdr-peers के माध्यम से बात करते हैं: एक ask एक स्टैम्प रखता है जो ठीक एक reply को अधिकृत करता है, और हर आदान-प्रदान दर्ज किया जाता है। लीड प्रोटोकॉल को छोटा रखता है:

• माइलस्टोन ऊपर। हर लेन निश्चित बिंदुओं पर रिपोर्ट करती है — योजना तैयार, pull request खुला, blocked, done — और उनके बीच उत्तर की प्रतीक्षा किए बिना काम करती रहती है।
• प्रश्न ask के रूप में। जिस लेन को किसी निर्णय की आवश्यकता होती है वह लीड से पूछती है; लीड एक reply से उत्तर देता है।
• गहराई एक। किसी reply का कभी उत्तर नहीं दिया जाता, और कोई लेन आगे प्रत्यायोजन नहीं करती। प्रति कॉलर fan-out सीमित है, डिफ़ॉल्ट रूप से चार पीयर।
• डेटा, निर्देश नहीं। एक reply प्राप्तकर्ता को ऐसा कुछ नहीं देता जो उसके पास पहले से न हो। किसी लेन का यह दावा कि उसका गेट पास हुआ, गेट चलाकर जाँचा जाता है।
• किसने क्या किया, इसका रिकॉर्ड। हर प्रत्यायोजन रिकॉर्ड लेन के खाते और विक्रेता का नाम दर्ज करता है, ताकि पैरेंट योजना दिखाए कि किस खाते ने कौन-सा काम किया।
• Codex लेन अपना पेन बताते हैं। Codex किसी लेन के कमांड उस खाते के सभी सत्रों द्वारा साझा किए गए एक बैकग्राउंड सर्वर से चलाता है, इसलिए उसे विरासत में मिला पेन id किसी दूसरे लेन का हो सकता है। Codex लेन लीड के ब्रीफ़ में दिया अपना पेन हर herdr-peers कमांड पर --pane <pane> के साथ देता है (ask, reply, notify, check, wait, lanes, cancel)।

लीड पूरे ऑर्केस्ट्रा को एक साथ देख सकता है: herdr-peers lanes हर लेन को उसकी स्थिति के साथ सूचीबद्ध करता है, और DeepWorkPlan Vim किसी ऑर्केस्ट्रेटर योजना की लेन को योजना के ठीक बगल में दिखाता है (:DwpLanes)।

हर रिपॉज़िटरी के लिए एक ब्रांच, एक रिलीज़

कई लेन को समीक्षा योग्य रखने वाला नियम सरल है: हर रिपॉज़िटरी के लिए एक लेन, उसके बेस चेकआउट पर, पूरे बदलाव के लिए एक ब्रांच, एक pull request और एक रिलीज़ के साथ। लेन अपने काम को कई ब्रांचों या worktrees में नहीं बाँटती। Worktrees केवल उस स्थिति के लिए हैं जहाँ दो लेखकों को एक रिपॉज़िटरी साझा करनी हो: हर एक को अपना मिलता है, ताकि हर पथ का एक ही लेखक हो।

pull request लीड के GO तक खुला, हरा और समीक्षा के लिए लेबल किया हुआ रहता है। फिर लेन मर्ज और टैग करती है, और टैग वापस रिपोर्ट करती है।

रिलीज़ क्रम

रिपॉज़िटरीज़ एक-दूसरे पर निर्भर होती हैं, इसलिए वे निर्भरता के क्रम में रिलीज़ होती हैं: पहले टूल, फिर वे जो उन्हें पिन करते हैं, फिर वह प्रलेखन जो परिणाम का वर्णन करता है, फिर वे उपभोक्ता जो उसे अपनाते हैं। लीड क्रम रखता है और एक-एक रिपॉज़िटरी को GO भेजता है। जो लेन किसी दूसरी रिपॉज़िटरी की रिलीज़ पिन करती है, वह पिन लिखने से पहले उस टैग की प्रतीक्षा करती है, ताकि कोई पिन कभी ऐसी रिलीज़ की ओर इशारा न करे जो मौजूद नहीं है।

चेकपॉइंट

पैरेंट योजना रिपोर्टों पर नहीं, साक्ष्य पर बंद होती है:

1. प्रति लेन। हर लेन का गेट उसकी अपनी ब्रांच पर पास होता है, और उसके pull request की समीक्षा साफ़ होती है। समीक्षा अपनी एक अलग लेन हो सकती है: AI Diff Reviewer हर लेन के pull request की समीक्षा करता है, और Dailybot ऐडऑन के साथ हर लेन अपनी प्रगति की रिपोर्ट स्वयं टीम को देती है।
2. प्रति रिलीज़। हर टैग मौजूद है और वह पिन करता है जिसकी अगली रिपॉज़िटरी को आवश्यकता है।
3. एकीकरण। अंतिम रिलीज़ के बाद, एक चेकपॉइंट उपभोक्ताओं को रिलीज़ किए गए संस्करणों पर चलाता है और निर्णय को पैरेंट योजना की analysis_results/ में दर्ज करता है।
4. अंतिम समीक्षा। पैरेंट योजना पूरी होने से पहले, एक सुरक्षा जाँच हर उस चीज़ को कवर करती है जिसने कोई सीमा पार की — सबसे बढ़कर कंटेनरों में साझा किए गए खाते, टोकन और फ़ाइलें।

सुरक्षा

• किसी ask, प्रॉम्प्ट या लॉग में कभी कोई कुंजी, टोकन या secret न रखें; वेरिएबल्स का उल्लेख नाम से करें।
• साझा संसाधनों को एक लॉक मिलता है: कोई लेन कंटेनर बिल्ड जैसे भारी चरण से पहले उसे लेती है और बाद में छोड़ देती है।
• अनुमति opt-out, जब सेट हो, हर लेन और हर उस एजेंट के लिए प्रभावी रहता है जिसे कोई लेन शुरू करती है।
• जो लेन आगे नहीं बढ़ सकती वह इसे blocked माइलस्टोन के रूप में बताती है और रुक जाती है; निर्णय लीड करता है।

जब कोई खाता या लीड ख़त्म हो जाए

एक लंबा रन किसी भी एक खाते से अधिक चलता है। coding-agents-kit (v0.7.1) और herdr-peers (v0.3.2) से, एक लेन हर कार्य-सीमा पर अपनी क्षमता जाँचती है और अपना खाता ख़त्म होने से पहले एक पैकेट के माध्यम से अपना काम आगे सौंप देती है, एक लीड नेतृत्व आगे सौंपता है या उसका डिप्टी उसकी जगह लेता है, और केवल critical मामले ही डेवलपर तक पहुँचते हैं। स्वार्म स्वायत्तता लूप, पैकेट, उत्तराधिकार और एस्कलेशन वर्गों का वर्णन करता है।