एक ही रिपॉज़िटरी पर कई AI एजेंट
कई एजेंट एक रिपॉज़िटरी साझा कर सकते हैं अगर लेखन को कोई नियंत्रित करे: एजेंट उन रास्तों की घोषणा करता है जिन्हें वह छूने वाला है, सर्वर उसे ये दे देता है, और जब तक वह इन्हें छोड़ न दे, बाकी सबको मना कर देता है। इस नियंत्रण के बिना, दूसरा एजेंट बिना किसी सूचना के पहले का काम मिटा देता है।
वह मामला जो सब बिगाड़ देता है
दो एजेंट को दो ऐसे काम मिलते हैं जो एक ही फ़ाइल को छूते हैं। पहला फ़ाइल पढ़ता है, बीस सेकंड सोचता है, लिखता है। दूसरे ने पहले के लिखने से पहले वही वर्ज़न पढ़ा था, और वह उसके ऊपर लिख देता है। कुछ भी क्रैश नहीं हुआ, किसी को कोई चेतावनी नहीं मिली, और पहले का काम गायब हो गया।
जैसे ही एक से ज़्यादा एजेंट हों, यह मामला दुर्लभ नहीं रहता, क्योंकि एजेंट व्यापक पढ़ते हैं और तेज़ी से लिखते हैं। यही वजह है कि लगभग हर टूल अलगाव अपनाता है: हर एजेंट के लिए एक मशीन, हर एजेंट के लिए एक ब्रांच।
बाकी दुनिया क्या करती है: हर एजेंट के लिए एक worktree
इस समस्या का आम जवाब बंटवारा है: हर एजेंट को अपना git worktree दिया जाता है, फ़ाइलों की पूरी कॉपी अपने इंडेक्स के साथ, और यह देखा जाता है कि दायरे एक-दूसरे से न टकराएं। यही Windsurf, Conductor और OpenHands करते हैं, और यही ज़्यादातर गाइड सुझाते हैं।
यह काम करता है, और इसमें ठीक एक कमी है: बंटवारा एक वादा है, गारंटी नहीं। कोई यह जांच नहीं करता कि दायरे टकरा नहीं रहे, और जब वे टकराते हैं तो पता मर्ज के समय चलता है, जब दोनों एजेंट काम खत्म कर चुके होते हैं और किसी को वजह याद नहीं रहती।
आरक्षण, तीन चरणों में
लिखने से पहले, एजेंट उन रास्तों की घोषणा करता है जिन्हें वह छूने वाला है। बोर्ड, अगर वे खाली हों तो उसे दे देता है, और अगर किसी के पास हों तो मना कर देता है। हर पल, एक फ़ाइल का एक ही मालिक।
काम के दौरान, एक ऑब्ज़र्वर डिस्क पर असली लेखन देखता है और हर एक को उसके लेखक से जोड़ता है। किसी और के पास मौजूद रास्ते पर आया लेखन डिस्क पर उतरने से पहले स्नैपशॉट किया जाता है: पिछला वर्ज़न सुरक्षित रहता है, इसलिए नियम टूटने पर भी कुछ नहीं खोता।
आख़िर में, एजेंट अपने रास्ते छोड़ देता है। फ़ाइल अगले के लिए फिर से उपलब्ध हो जाती है, बिना किसी मर्ज के, क्योंकि एक साथ दो ज़िंदा वर्ज़न कभी हुए ही नहीं।
स्क्रीन पर यह कैसा दिखता है
हर विंडो अपने एजेंट को काम करते दिखाती है, और बोर्ड दिखाता है कि किसके पास क्या है। दिखता है कि कोई एजेंट इंतज़ार कर रहा है, और क्यों। अटका हुआ एजेंट नुकसान करने से पहले दिख जाता है, और अदृश्य कतार से यही असली फ़र्क़ है।
लोग भी गिनती में आते हैं। एक ही कैनवस पर मौजूद कई लोग अपने-अपने एजेंट चलाते हैं और बाकी सबके नाम वाले कर्सर देखते हैं।
जब यह सही तरीका नहीं
अगर आपके काम सच में स्वतंत्र और लंबे हैं, तो मशीन के हिसाब से अलगाव अब भी ठीक-ठाक है: कुछ तय करने को नहीं, कुछ इंतज़ार करने को नहीं। साझा करना तब जीतता है जब काम एक-दूसरे को छूते हैं, जो एक ही फ़ीचर पर काम करते समय हमेशा होता है। तुलनाएं टूल के हिसाब से यह चुनाव विस्तार से बताती हैं।
सीधे जवाब
क्या कई एजेंट चलाने के लिए git worktree चाहिए?
ज़्यादातर गाइड यही जवाब देते हैं, और यह काम करता है: हर एजेंट के लिए एक worktree, हर एक अपने इंडेक्स और फ़ाइलों के साथ, यानी कोई टकराव संभव नहीं। इसकी एक कीमत है, और वह हमेशा एक जैसी है: जितने एजेंट उतनी कॉपियां, और आख़िर में हर कॉपी के लिए एक मर्ज। एक साझा फ़ोल्डर और फ़ाइल आरक्षण दोनों को हटा देता है, कीमत बस यह कि कभी-कभी एजेंट तीस सेकंड इंतज़ार करता है।
हर एजेंट को अपनी ब्रांच क्यों नहीं दी जाती?
यह आम हल है और कीमत को अंत तक टाल देता है। तीन ब्रांच तीन मर्ज बनाती हैं, और टकराव तब दिखता है जब तीनों एजेंट काम खत्म कर चुके होते हैं, यानी जब किसी को वजह याद नहीं रहती। साझा फ़ोल्डर टकराव को उसी पल सुलझा देता है जब वह होता है।
अगर कोई एजेंट आरक्षण को नज़रअंदाज़ कर दे तो क्या होता है?
उसके पास चुनने का मौका नहीं: यह नियम सर्वर लागू करता है, मॉडल को सिर्फ़ सुझाया नहीं जाता। एक ऑब्ज़र्वर लेखन पर नज़र रखता है और हर एक को उसके लेखक से जोड़ता है, और किसी और के पास मौजूद रास्ते पर आया लेखन डिस्क पर उतरने से पहले स्नैपशॉट कर लिया जाता है, इसलिए दोनों वर्ज़न अभी भी मौजूद रहते हैं।
एक साथ कितने एजेंट?
Pro योजना पर पांच एजेंट विंडो, और उससे ऊपर और भी। असली सीमा मशीन नहीं, बल्कि किसी पल प्रोजेक्ट में मौजूद स्वतंत्र काम की संख्या है।