Agent Teams और Swarms

एक ही काम पर कई AI एजेंट लगाएं — या तो एक टीम जो वर्कस्पेस शेयर करती है, या हेडलेस वर्कर्स का एक Swarm।

कुछ काम एक एजेंट के लिए बहुत बड़े होते हैं। 1DevTool आपको स्केल अप करने के दो तरीके देता है, और ये सच में अलग-अलग टूल हैं।

Teams: वे एजेंट जिन्हें आप देख सकते हैं

एक Team एजेंटों का एक नामित समूह होता है जो एक वर्कस्पेस और एक लक्ष्य साझा करता है। हर सदस्य एक असली टर्मिनल में चलता है जिसे आप खोल सकते हैं, पढ़ सकते हैं और उसमें टाइप कर सकते हैं। इसे Orchestration Dashboard के Teams टैब से शुरू करें।

एक टीम आपको देती है:

हर सदस्य की लाइव स्थिति एक नज़र में
एक शेयर्ड वर्कस्पेस जिसे खोलकर आप सीधे एजेंटों के टर्मिनल में जा सकते हैं
एक लाइव मैसेज रेल जो दिखाती है कि एजेंट कैसे काम आगे बढ़ा रहे हैं और आपस में बात कर रहे हैं
टीम के लिए एक इकाई के रूप में टोकन और लागत का हिसाब

Swarms: हेडलेस वर्कर्स

एक Swarm किसी एजेंट की N कॉपियां होती हैं जो बिना किसी टर्मिनल या विंडो के एक ब्रीफ पर काम करती हैं — बस सैंडबॉक्स में वर्कर्स होते हैं जो नतीजे वापस भेजते हैं। Swarm का इस्तेमाल तब करें जब काम व्यापक और दोहराव वाला हो (हर रूट का सर्वे करना, हर माइग्रेशन जांचना, N तरीके आज़माना) और आपको इसे होते हुए देखने की ज़रूरत न हो।

आप किसी भी समय worker pool को pause या resume कर सकते हैं ताकि चीज़ों की रफ़्तार धीमी की जा सके या आपकी मशीन खाली की जा सके, और पहले से चल रहे वर्कर्स को पूरा होने देते हुए कतार में लगे वर्कर्स को cancel कर सकते हैं।

कौन से एजेंट Swarm चला सकते हैं

Swarm वर्कर्स को एक लॉक्ड-डाउन सैंडबॉक्स के अंदर चलना ज़रूरी है, और हर एजेंट के पास यह नहीं होता। फ़िलहाल समर्थित Swarm टारगेट Codex, Claude, और Cursor हैं।

किसी और एजेंट पर Swarm माँगने पर तुरंत, कारण सहित मना कर दिया जाता है — यह उन एजेंटों के नाम बताता है जो सैंडबॉक्स्ड वर्कर्स चला सकते हैं और इसके बजाय आपको टर्मिनल Swarm, डायरेक्ट डेलिगेशन, या एक Agent Team की ओर इशारा करता है। यह जानबूझकर किया गया है: पहले ऐसे अनुरोध स्वीकार कर लिए जाते थे और फिर हर वर्कर एक सेकंड के भीतर बिना किसी आउटपुट या स्पष्टीकरण के मर जाता था। सैंडबॉक्सिंग टारगेट एजेंट की क्षमताओं पर निर्भर करती है, आपके ऑपरेटिंग सिस्टम पर नहीं।

डेलिगेट करने वाले एजेंटों को भी उनके अपने ऑर्केस्ट्रेशन निर्देशों में समर्थित टारगेट बता दिए जाते हैं, ताकि वे ऐसे Swarm बनाना बंद कर दें जो शुरू ही नहीं हो सकते। ये निर्देश अगली बार ऐप शुरू होने पर रिफ्रेश होते हैं।

जब कोई रन विफल हो जाए

जो रन अपने एजेंट के शुरू होने से पहले ही खत्म हो जाता है — एजेंट इंस्टॉल नहीं है, सैंडबॉक्स समर्थित नहीं है, लॉन्च मना कर दिया गया — वह कारण अपने रन रिकॉर्ड में दर्ज करता है। आप इसे Orchestration dashboard में देख सकते हैं, और यह उन रन फ़ाइलों के साथ जाता है जिन्हें आप बग रिपोर्ट में अटैच करते। पहले ऐसे रन सिर्फ़ एक खाली "error" के रूप में एक्सपोर्ट होते थे, जिसकी वजह से उनकी रिपोर्ट करना मुश्किल हो जाता था।

जहां देशी प्रोटोकॉल मौजूद हैं

Codex और OpenCode किसी स्क्रैप किए गए टर्मिनल की बजाय अपने खुद के प्रोटोकॉल पर सहयोग करते हैं: इन दोनों के साथ ऑर्केस्ट्रेटेड रन अपने नेटिव इंटरफ़ेस के ज़रिए अपना आउटपुट स्ट्रीम करते हैं, टूल अप्रूवल माँगते हैं, इंटरप्ट करते हैं, और रिज्यूम करते हैं। बाकी हर एजेंट पहले जैसा ही टर्मिनल पाथ इस्तेमाल करता है, और इस्तेमाल से पहले हर एक को इंस्टॉल किए गए वर्शन के आधार पर वेरिफ़ाई किया जाता है।

जब किसी टर्मिनल प्रॉम्प्ट की तैयारी की पुष्टि नहीं की जा सकती, तो Runs एक headless fallback दे सकते हैं जबकि आप फिर भी कतार में लगे टर्मिनल प्रॉम्प्ट को फिर से आज़मा सकते हैं। हेडलेस वर्कर्स आपके सामान्य कमांड-लाइन टूल्स इनहेरिट करते हैं, और रुके हुए रन अपने वर्कर्स और क्षमता को साफ़-सुथरे तरीके से रिलीज़ कर देते हैं।

एक टीम को resume करना

जो सेशन एक जुड़ी हुई टीम के रूप में चले थे, उन्हें Resume AI Sessions में चिह्नित किया जाता है, और एक बैनर एक ही कन्फ़र्मेशन में हर सदस्य को वापस लाने का विकल्प देता है। सदस्य एक टीम चिप दिखाते हैं ताकि आप सामूहिक सेशनों को अकेले सेशनों से अलग पहचान सकें। टर्मिनल चलने लगने के बाद, Mission Control का Resume team उन्हें फिर से कनेक्ट कर देता है।

टीमों को कहीं से भी देखना

Dashboard, All Terminals लिस्ट, और Terminal Canvas पर मौजूद एक लाइव टीम रेल हर चल रही टीम का नाम बताती है, यह बताती है कि वह किस प्रोजेक्ट में है और क्या कर रही है, और एक क्लिक में आपको उसमें ले जाती है।