कोडिंग एजेंटों को समानांतर (Parallel) में चलाने के लिए, प्रत्येक एजेंट को उसका अपना Git worktree और शाखा (Branch) दें, एजेंटों को उन योजनाओं की कतार से कार्य सौंपें जिनकी किसी मानव इंजीनियर ने पहले ही समीक्षा कर ली है, किसी के भी diff पढ़ने से पहले प्रत्येक worktree के भीतर टेस्ट और लिंट चलाएं, और प्रत्येक योजना की लागत का रिकॉर्ड रखें। अधिकांश टीमें तीन शुरुआती पैटर्नों से गुजरकर इस सेटअप तक पहुंचती हैं: चैट विंडो में एक अकेला एजेंट, मैन्युअल रूप से प्रति शाखा शुरू किया गया एक एजेंट, और वर्कर एजेंटों के साथ एक टास्क कतार। प्रत्येक पैटर्न एक समस्या को हल करता है और अगली समस्या को उजागर करता है। यह गाइड इन चार पैटर्नों, प्रत्येक चरण पर आने वाली बाधाओं और उन छह आवश्यक जिम्मेदारियों को कवर करती है जिन्हें एक ऑर्केस्ट्रेटर को संभालना होता है।
चार प्रमुख पैटर्न
स्टीव येग्गे (Steve Yegge) का "8 Levels of AI-Assisted Development" (2025) एक बेहद उपयोगी वैचारिक ढांचा प्रदान करता है। इसका अंतर्निहित लूप — किसी कदम पर विचार करना (Reason), कार्य करना (Act), परिणाम देखना (Observe), दोहराना — वही है जिसे Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models में औपचारिक रूप दिया गया था। नीचे दिया गया प्रत्येक पैटर्न इस बात का अलग उत्तर है कि उस लूप की निगरानी कौन करता है। इस लेख के लिखे जाने के समय अधिकांश टीमें स्तर 2 से 3 पर हैं: एक डेवलपर एजेंट को प्रॉम्प्ट देता है, परिणाम देखता है और कमिट करता है। समानांतर एजेंटों, निरंतर मेमोरी और समीक्षा गेट्स के साथ ऑर्केस्ट्रेशन स्तर 8 का प्रतिनिधित्व करता है।
पैटर्न 1: चैट विंडो में एक अकेला एजेंट
एक डेवलपर टर्मिनल या IDE पैनल खोलता है, कार्य का वर्णन करता है, और एजेंट को वर्किंग डायरेक्टरी में फाइलों को संपादित करते हुए देखता है। थ्रूपुट प्रति डेवलपर एक समय में केवल एक कार्य तक सीमित रहता है, क्योंकि एजेंट और डेवलपर एक ही चेकआउट साझा करते हैं। पहला कार्य समाप्त होने से पहले शुरू किया गया दूसरा कार्य दोनों संपादनों को एक ही कोड ट्री में मिला देता है, और परिणामी diff का कोई अर्थ नहीं रह जाता।
पैटर्न 2: प्रति शाखा एक एजेंट, मैन्युअल रूप से शुरू किया गया
अगला कदम प्रत्येक कार्य को उसकी अपनी शाखा और अपना चेकआउट देना है। Git worktrees इसे बेहद कुशल और हल्का बनाते हैं: एक साझा ऑब्जेक्ट स्टोर और कई स्वतंत्र वर्किंग डायरेक्टरी।
# मुख्य चेकआउट से:
git worktree add ../feature-search-button -b feature/search-button
cd ../feature-search-button
claude "Add a search button to the sidebar. Run the tests when done."
एक डेवलपर अब एक साथ दो या तीन एजेंट चला सकता है, प्रत्येक अपनी अलग डायरेक्टरी में। यहां जो व्यवस्था टूटती है वह प्रबंधन और ट्रैकिंग है: कोई यह रिकॉर्ड नहीं रखता कि कौन सा worktree किस कार्य से संबंधित है, और प्रॉम्प्ट्स टर्मिनल के इतिहास में खो जाते हैं। यदि दो एजेंट एक ही फाइल पर काम करते हैं, तो मर्ज टकराव केवल कोड मिलाते समय ही सामने आते हैं।
पैटर्न 3: अलग-थलग Worktrees में वर्कर एजेंटों के साथ एक कतार
जब टीम मुट्ठी भर से अधिक एजेंटों को चलाने लगती है, तो मैन्युअल रूप से शुरू करने का कदम सबसे धीमा अवरोध बन जाता है। इसका समाधान एक कतार (Queue) है: कार्य कतार में जाते हैं, बैकग्राउंड वर्कर प्रक्रियाएं उन्हें उठाती हैं, एक worktree बनाती हैं, एजेंट को चलाती हैं, शाखा को पुश करती हैं और एक Pull Request खोलती हैं। AutoGen जैसे मल्टी-एजेंट अनुसंधान फ्रेमवर्क इसी वर्कर-और-कतार व्यवस्था को औपचारिक रूप देते हैं।
प्रत्येक कार्य की शुरुआत से मानव को पूरी तरह हटा देने से अगली विफलता सामने आती है। एजेंट के काम शुरू करने से पहले कोई भी कार्य की समीक्षा नहीं करता है, इसलिए खराब ढंग से निर्दिष्ट कार्य उन पुल रिक्वेस्ट्स पर महंगे टोकन खर्च करते हैं जिन्हें कोई नहीं चाहता। पुल रिक्वेस्ट से पहले कोई भी आउटपुट की जांच नहीं करता है, जिससे मानवीय समीक्षक सबसे धीमा रोड़ा बन जाते हैं। और चूंकि कतार बिना किसी मानवीय निगरानी के चलती है, इसलिए लागत अनियंत्रित रूप से बढ़ती जाती है।
पैटर्न 4: समीक्षा चेकपॉइंट्स के साथ योजना का जीवन चक्र
अंतिम पैटर्न दो मानवीय चेकपॉइंट्स और एक स्वचालित सत्यापन चरण जोड़ता है। कोई भी कार्य पहले एक लिखित योजना (Plan) बनता है। कोई भी कोड लिखे जाने से पहले एक मानव उस योजना को पढ़ता और अनुमोदित करता है। एजेंट पूरी तरह से अलग-थलग Git worktrees में निष्पादित होते हैं। टेस्ट, लिंट और diff सारांश worktree के अंदर ही चलते हैं — यह निरंतर एकीकरण (Continuous Integration) का वही सिद्धांत है जिसे प्रति डेवलपर के बजाय प्रति एजेंट लागू किया गया है। एक मानव diff की समीक्षा करता है। केवल तभी एक पुल रिक्वेस्ट खोली जाती है।
Ivy इस पैटर्न को एक "सॉफ्टवेयर फैक्ट्री (Software Factory)" कहता है: एक मानकीकृत और पुनरावृत्ति योग्य वर्कफ़्लो जिसमें प्रत्येक परिवर्तन समान चरणों और उन्हीं दो मानवीय हस्ताक्षरों से होकर गुजरता है। पूरी परिभाषा के लिए देखें सॉफ्टवेयर फैक्ट्री क्या है।
प्रत्येक चरण में क्या टूटता है
| पैटर्न | यह क्या हल करता है | इसके बाद क्या समस्या आती है |
|---|---|---|
| चैट में अकेला एजेंट | अभी कुछ नहीं; यह आधारभूत स्थिति है | प्रति डेवलपर केवल एक कार्य; साझा डायरेक्टरी का टकराव |
| प्रति शाखा एक एजेंट, मैन्युअल | फ़ोल्डर टकराव के बिना समवर्ती कार्य | संदर्भ का नुकसान, अलिखित प्रॉम्प्ट, मर्ज के समय अप्रत्याशित टकराव |
| वर्कर कतार | मैन्युअल शुरुआत का रोड़ा समाप्त | अनिर्दिष्ट कार्य, कचरा PRs की बाढ़, समीक्षा में देरी, अनियंत्रित लागत |
| चेकपॉइंट्स के साथ योजना चक्र | व्यर्थ निष्पादन और असत्यापित परिवर्तनों का खात्मा | कतार, आइसोलेशन, सत्यापन, लागत और मेमोरी संभालने के लिए विशेष टूलिंग की आवश्यकता |
एक ऑर्केस्ट्रेटर को किन छह जिम्मेदारियों को संभालना चाहिए
एक ऑर्केस्ट्रेटर वह सॉफ्टवेयर है जो पैटर्न 4 को सुचारू रूप से चलाता है। इसके छह प्रमुख उत्तरदायित्व हैं; इनमें से यदि कोई भी गायब है, तो उसे हाथ से करना होगा और वह प्रक्रिया फिर से सबसे धीमा अवरोध बन जाएगी:
- कतार प्रबंधन (Queue): योजनाएं एक परिभाषित क्रम में स्पष्ट स्थिति के साथ प्रतीक्षा करती हैं: ड्राफ्ट (draft), स्वीकृत (approved), निष्पादित (executing), सत्यापित (verifying), समीक्षाधीन (in review), मर्ज किया गया (merged)। टर्मिनल खोले बिना स्थिति पूरी तरह स्पष्ट होनी चाहिए।
- आइसोलेशन (Isolation): निष्पादित होने वाली प्रत्येक योजना को उसका अपना worktree और शाखा मिलती है। मुख्य (main) शाखा में कभी भी किसी एजेंट द्वारा सीधे संपादन नहीं किया जाता है। समानांतर AI एजेंटों के लिए Git Worktrees बताता है कि worktrees साझा चेकआउट और भारी कंटेनरों से बेहतर क्यों हैं।
- स्वचालित सत्यापन (Verification): निष्पादन के बाद और किसी मानव के देखने से पहले, टेस्ट, लिंट, टाइप चेक और diff सारांश worktree के अंदर चलते हैं। असफलताएं वास्तविक त्रुटि लॉग के साथ एजेंट को वापस भेज दी जाती हैं।
- मानवीय समीक्षा (Review): ठीक दो चेकपॉइंट्स — योजना और diff — प्रत्येक में स्पष्ट स्वीकृति या अस्वीकृति की कार्रवाई। योजना चरण में अस्वीकृति पर कोड जनरेशन का शून्य टोकन खर्च होता है। diff चरण में अस्वीकृति पर केवल एक निष्पादन की लागत आती है।
- लागत लेखांकन (Cost accounting): प्रति योजना और प्रति कार्य टोकन और डॉलर का सटीक रिकॉर्ड, ताकि टीम यह देख सके कि एक मर्ज किए गए परिवर्तन की क्या लागत आई और खर्च करने के बाद किन योजनाओं को छोड़ दिया गया।
- मेमोरी (Memory): एजेंट ने एक योजना में जो कुछ भी सीखा, वह अगली योजना में उपलब्ध होना चाहिए; अन्यथा प्रत्येक योजना शून्य से शुरू होती है और उन्हीं गलतियों को दोहराती है।
Ivy Tendril इसे कैसे लागू करता है
Ivy Tendril macOS, Windows और Linux के लिए एक लोकल-फर्स्ट डेस्कटॉप एप्लिकेशन है जो किसी भी CLI कोडिंग एजेंट के लिए पैटर्न 4 चलाता है। यह tendril --web के साथ हेडलेस मोड में भी चलता है।
- कतार प्रबंधन: Plans इंटरफ़ेस प्रत्येक योजना को उसकी जीवन चक्र स्थिति के साथ रखता है। Drafts, Icebox और Recommendations उन कार्यों को व्यवस्थित करते हैं जो अभी स्वीकृत नहीं हुए हैं। योजनाएं वेबहुक के माध्यम से GitHub इश्यू और jam.dev बग रिपोर्ट से, या MCP सर्वर, REST API और CLI के माध्यम से बनाई जा सकती हैं।
- आइसोलेशन: जब निष्पादन शुरू होता है, तो Tendril उस योजना के लिए एक Git worktree और शाखा बनाता है। कई योजनाएं एक साथ अपने-अपने worktree में समानांतर निष्पादित होती हैं। मर्ज के बाद, Tendril worktree को हटा देता है। देखें समानांतर AI एजेंटों के लिए Git Worktrees।
- सत्यापन: Review ऐप प्रत्येक योजना के लिए अलग टैब के रूप में टेस्ट, लिंट और diff दिखाता है। Pro योजनाएं CI से सीधे सत्यापन परिणाम आयात कर सकती हैं।
- समीक्षा: योजना चेकपॉइंट एक समीक्षक को ड्राफ्ट का विस्तार (Expand), विभाजन (Split), या अद्यतन (Update) करने देता है, या इनलाइन टिप्पणी करने की अनुमति देता है जिससे योजना फिर से लिखी जा सके। diff चेकपॉइंट सत्यापन के बाद आता है। दोनों के बिना कोई भी पुल रिक्वेस्ट नहीं खुलती है।
- लागत लेखांकन: टोकन और लागत को प्रति योजना और प्रति कार्य ट्रैक किया जाता है, और डैशबोर्ड लागत KPI और रुझान चार्ट प्रदर्शित करता है।
- मेमोरी: प्रत्येक जीवन चक्र चरण एक प्रॉम्प्टवेयर (Promptware) इकाई द्वारा संचालित होता है जिसमें विकसित होने वाले निर्देशों की Program.md, कोडबेस के बारे में स्थाई सीख की Memory/ डायरेक्टरी, सीमित Tools/, और ऑडिट Logs/ शामिल हैं। अंतर्निहित इकाइयों में CreatePlan, ExpandPlan, ExecutePlan, UpdatePlan, SplitPlan, CreatePr, और CreateIssue शामिल हैं। देखें प्रॉम्प्टवेयर।
Tendril एजेंट-अज्ञेयवादी (agent-agnostic) है। यह Claude Code, OpenAI Codex CLI, GitHub Copilot CLI, Google Gemini CLI, OpenCode, और किसी भी अन्य CLI एजेंट को चलाता है, और एजेंट या मॉडल को प्रति योजना बदला जा सकता है। कोड मशीन पर ही रहता है; एकमात्र बाहरी कॉल आपके द्वारा कॉन्फ़िगर किए गए LLM API और GitHub पर होती हैं।
Ivy रिपोर्ट करता है कि इस वर्कफ़्लो को अपनाने के बाद उसकी अपनी इंजीनियरिंग टीम प्रति दिन लगभग 10 से बढ़कर 100 से अधिक पुल रिक्वेस्ट्स तक पहुंच गई।
शुरुआत कैसे करें
- Tendril स्थापित करें: macOS या Linux पर
curl -sSf https://cdn.ivy.app/install-tendril.sh | shचलाएं, Windows परirm https://cdn.ivy.app/install-tendril.ps1 | iexचलाएं। विवरण इंस्टॉलेशन गाइड में उपलब्ध हैं। - इसमें एक रिपॉजिटरी खोलें और अपने द्वारा उपयोग किए जाने वाले मॉडल प्रदाता के लिए एक API कुंजी जोड़ें।
- किसी मौजूदा टिकट से एक योजना बनाएं, ड्राफ्ट की समीक्षा करें, इसे निष्पादित करें, और Review ऐप में diff देखें।
- पहली योजना के मर्ज हो जाने के बाद, एक साथ तीन योजनाएं बनाएं और उन्हें समानांतर में निष्पादित होते देखें।
Tendril Functional Source License के तहत निःशुल्क और स्रोत-उपलब्ध है; टीम सुविधाएं, SSO, ऑन-प्रिमाइसेस होस्टिंग, और CI सत्यापन आयात Pro ($59 प्रति उपयोगकर्ता प्रति माह) और Enterprise योजनाओं में उपलब्ध हैं।
अक्सर पूछे जाने वाले प्रश्न (FAQ)
क्या मुझे एजेंटों को समानांतर में चलाने के लिए कंटेनरों की आवश्यकता है?
नहीं। Git worktrees प्रत्येक एजेंट को एक साझा ऑब्जेक्ट स्टोर का उपयोग करते हुए अपनी स्वयं की वर्किंग डायरेक्टरी और शाखा प्रदान करते हैं। कंटेनर रनटाइम आइसोलेशन जोड़ते हैं, जो केवल तभी मायने रखता है जब एजेंट सिस्टम पैकेज स्थापित करते हैं या नेटवर्क पोर्ट बांधते हैं; अधिकांश कोडिंग कार्यों को इसकी आवश्यकता नहीं होती है।
एक साथ कितने एजेंट चल सकते हैं?
इसकी सीमा आमतौर पर मॉडल प्रदाता की दर सीमा (rate limits) और टेस्ट चलाने के लिए आपकी मशीन की प्रसंस्करण क्षमता होती है, ऑर्केस्ट्रेटर नहीं। तीन से पांच समानांतर योजनाओं से शुरुआत करें और संख्या तब तक बढ़ाएं जब तक कि सत्यापन कार्य समय पर पूरा होता रहे।
क्या होता है जब दो योजनाएं एक ही फाइल को छूती हैं?
मर्ज होने वाली दूसरी योजना अपनी शाखा पर एक कॉन्फ्लिक्ट उत्पन्न करेगी। इसका समाधान योजना के चरण में ही निहित है: निष्पादन से पहले उन योजनाओं को विभाजित या अनुक्रमित (sequence) करें जो समान मॉड्यूल को छूती हैं, जिसके लिए Tendril में Split एक्शन बनाया गया है।
Ivy Tendril के साथ शुरुआत करें
क्या आप डेवलपर-स्तरीय समानांतर एजेंट ऑर्केस्ट्रेशन के लिए तैयार हैं?
- कोड एक्सप्लोर करें: GitHub पर Ivy Tendril देखें (ओपन सोर्स)।
- दस्तावेज़ पढ़ें: tendril.ivy.app पर इंटीग्रेशन गाइड पढ़ें।
- आर्किटेक्चर सत्र शेड्यूल करें: 30 मिनट के तकनीकी परामर्श के लिए renco@ivy.app पर संपर्क करें।