DeepSeek ने कोडिंग के काम समानांतर करने के लिए Super-agent प्रोटोटाइप जारी किया

एक साथ कई काम संभालने के लिए बना कोडिंग एजेंट

DeepSeek की Harness टीम ने 31 अक्टूबर, 2026 को अपना Super-agent डिज़ाइन प्रकाशित किया। इसके साथ MIT लाइसेंस वाला एक शोध प्रोटोटाइप भी जारी किया गया, जो GitHub रिपॉज़िटरी के लिए मिले अनुरोधों को अलग-अलग कोडिंग सत्रों में बदलता है। इसका उद्देश्य कई काम एक साथ आगे बढ़ाना है, ताकि डेवलपर्स को बातचीतों के बीच आने-जाने और प्रगति की जांच में कम समय देना पड़े।

टीम के शुरुआती प्रयोग में करीब 300 सिम्युलेटेड संदेशों का इस्तेमाल हुआ, जिनमें लगभग 20 काम के अनुरोध थे। Super-agent ने 12.4 मिनट के भीतर आधे और 15.7 मिनट के भीतर 95% काम पूरे किए। तटस्थ निर्देशों के तहत, एक मुख्य सत्र और सहायक एजेंट की सुविधा वाले तुलना सिस्टम को 95% का आंकड़ा हासिल करने में 29.5 मिनट लगे।

DeepSeek की सार्वजनिक प्रोटोटाइप रिपॉज़िटरी, जिसका नाम dsh-superagent-prototype है, अधिक सीमित और व्यावहारिक रिलीज़ पेश करती है: एक GitHub रिपॉज़िटरी के लिए सक्रिय कोडिंग एजेंट, जिसे DeepSeek Harness के बंडल के रूप में पैक किया गया है। यह GitHub और वैकल्पिक रूप से Feishu पर नजर रखता है, किसी अधिकृत व्यक्ति के काम का अनुरोध करने पर कार्य शुरू करता है और उसी मूल बातचीत में जवाब देता है। जवाब में कोड बदलावों का प्रस्ताव देने वाला पुल रिक्वेस्ट भी हो सकता है।

README में स्पष्ट चेतावनी भी दी गई है। प्रकाशित कोड आंतरिक सिस्टम और डिज़ाइन निबंध के कुछ हिस्सों से अलग है। प्रस्तावित कुछ सुविधाएं अभी भविष्य के काम का हिस्सा हैं, और DeepSeek इस रिलीज़ को तैयार उत्पाद के बजाय शोध कोड बताता है।

प्रोटोटाइप का रखरखाव करने वाली DeepSeek Harness टीम README में इसकी स्थिति बताती है:

केवल संदर्भ के लिए शोध प्रोटोटाइप, DeepSeek का आधिकारिक उत्पाद नहीं।

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

DeepSeek सत्र प्रबंधन को पर्दे के पीछे क्यों रखना चाहता है

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

हार्नेस वह सॉफ्टवेयर है जो AI मॉडल के आसपास रहकर टूल, फाइलें, बातचीत और काम के निष्पादन को संभालता है। मॉडल किसी काम पर तर्क करता है; हार्नेस तय करता है कि वह काम मॉडल तक कैसे पहुंचेगा और उसकी कार्रवाइयां कैसे चलेंगी। Super-agent कई कामों के बीच तालमेल की अधिक जिम्मेदारी इसी आसपास के सॉफ्टवेयर को देता है।

टीम ने चार लक्ष्य बताए हैं: बातचीतों के बीच निरंतरता, समानांतर काम का कुशल निष्पादन, घटनाओं पर सक्रिय प्रतिक्रिया और खराबी के बाद संभलते हुए लगातार संचालन। एक उदाहरण में डेवलपर चैट में कोई योजना चुनते हैं और बाद में GitHub टिप्पणी में उसे बदल देते हैं। सिस्टम को इन बातचीतों को जोड़कर उसी काम में बदलाव करना चाहिए।

यह रिलीज़ Harness v0.2.1-alpha.1 में DeepSeek के 3 अक्टूबर के Claude Code एक्सटेंशन अनुकूलता प्रयोग के बाद आई है। उस अपडेट में एक्सटेंशन के लिए एक ब्रिज की जांच की गई थी; Super-agent इस बात का पता लगाता है कि हार्नेस खुद जारी काम का समन्वय कैसे कर सकता है। सिस्टम को लागू करने और डिज़ाइन निबंध लिखने का श्रेय Yujia Qiao को दिया गया है। समीक्षा और चर्चा में शामिल 15 अन्य लोगों के नाम भी सूचीबद्ध हैं।

एक Router समन्वय करता है, कई Workers काम करते हैं

Super-agent जिम्मेदारियों को लगातार सक्रिय रहने वाले Router और अलग-अलग Workers के बीच बांटता है। Router लोगों से मिलने वाले संदेश लेता है, सभी कामों में साझा जानकारी संभालता है और काम सौंपता है। वह खुद कोडिंग नहीं करता, ताकि दूसरे सत्र व्यस्त हों तब भी समन्वय की भूमिका निभा सके।

अलग-अलग काम Workers संभालते हैं। हर Worker का अपना बातचीत संदर्भ और निष्पादन टूल होता है, जिससे बग की जांच, कोड समीक्षा के जवाब और फीचर में बदलाव एक साथ आगे बढ़ सकते हैं। Workers नतीजे Router को बताते हैं। Router लोगों से संवाद करता है, ताकि कई सत्र स्वतंत्र रूप से जवाब न दें।

DeepSeek का सुझाव है कि रूटिंग के लिए अक्सर हल्का मॉडल पर्याप्त हो सकता है, जबकि कोड की गुणवत्ता तय करने वाले काम अधिक सक्षम मॉडल करें। जटिल काम के लिए Worker सहायक एजेंट भी बना सकता है। Router हर काम के भीतर के कदमों की योजना बनाने के बजाय कामों के बीच के संबंध संभालता है।

प्रोटोटाइप में हर काम के लिए अलग सत्र और डायरेक्टरी होती है। उन्हें एक साथ शुरू किया जा सकता है, लेकिन एक तय सीमा तक ही। इसलिए ऑपरेटर नियंत्रित कर सकते हैं कि एक समय में कितने काम शुरू हों। बातचीत के अलग-अलग इतिहास से एक काम की जानकारी के दूसरे काम पर हावी होने की आशंका घटती है, जबकि Router साझा नजरिया बनाए रखता है।

लगातार बाधा डाले बिना संदेशों को काम में बदलना

चैट संदेश, कोड समीक्षा की टिप्पणियां और स्वचालित टेस्ट के नतीजे ऐसी घटनाएं बन जाते हैं जिन पर कार्रवाई शुरू हो सकती है। व्यापक डिज़ाइन में ईमेल और कैलेंडर रिमाइंडर पर भी विचार किया गया है। Continuous integration, या CI, ऐसे स्वचालित जांचों को कहते हैं जो बदलाव के बाद कोड को बिल्ड या टेस्ट करती हैं और ऐसे नतीजे देती हैं जिन पर एजेंट प्रतिक्रिया कर सकता है।

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

आपस में संबंधित घटनाएं एक Thread में रखी जाती हैं, जैसे किसी एक पुल रिक्वेस्ट के नीचे की टिप्पणियां या चैट का एक विषय। काम मिलने के बाद Worker उस Thread को सब्सक्राइब करता है। बाद की टिप्पणियां और टेस्ट नतीजे सीधे उसी तक पहुंच सकते हैं, बिना Router से दोबारा काम सौंपने को कहे।

एक से अधिक Workers एक ही Thread को सब्सक्राइब कर सकते हैं। एक पुल रिक्वेस्ट पर काम कर रहे कई Workers को एक जैसे अपडेट मिल सकते हैं, जिससे वे अपने काम को प्रभावित करने वाले बदलाव देख सकें। कोई Worker कई संबंधित Threads को भी फॉलो कर सकता है या अपने काम के दायरे से बाहर की घटना Router को लौटा सकता है।

जल्दी कार्रवाई, लेकिन जवाब तभी जब उपयोगी हो

DeepSeek का कहना है कि उसका एक आंतरिक Super-agent लगातार चलता है। वह समस्याओं को दोहराकर देखता और ठीक करता है, कोड समीक्षाओं का जवाब देता है और Harness को विकसित करने में मदद करता है। लिखित नियम के तहत, समूह चैट में बताए गए बग की जांच वह तब भी कर सकता है जब कोई सीधे एजेंट को टैग न करे।

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

Harness टीम अपने README में काम करने का सिद्धांत बताती है:

लोगों का ध्यान जितना कम हो सके उतना लें और जितना संभव हो उतना मूल्य दें।

प्रोटोटाइप तब कार्रवाई करता है जब कोई अधिकृत व्यक्ति अनुरोध करे या टीम का लिखा नियम इसकी अनुमति दे। इसका वेब पैनल उन कामों की सूची दिखाता है जिन पर इंसान का ध्यान जरूरी है। इस तरह इंटरफेस हर टूल कॉल या बीच के विचारों के बजाय फैसलों और इस्तेमाल लायक नतीजों पर केंद्रित रहता है।

पुराना संदर्भ और नए निर्देश उपलब्ध रखना

DeepSeek का डिज़ाइन मॉडल की कॉन्टेक्स्ट विंडो, यानी एक बार में विचार के लिए उपलब्ध जानकारी की सीमित मात्रा, को कैश की तरह देखता है। बार-बार जरूरी पड़ने वाली सामग्री पास रहती है; लंबा या कम प्रासंगिक इतिहास विंडो के बाहर रहता है, जब तक कि उसकी मांग न की जाए।

निबंध इन कार्रवाइयों को Inline और Spill कहता है। Inline के जरिए उपयोगी विवरण सीधे मौजूदा संदर्भ में रखे जाते हैं, जैसे पास के चैट संदेश, पहचानकर्ता या छोटा पूर्वावलोकन। Spill में लंबी सामग्री कहीं और रखी जाती है, साथ में ऐसा संदर्भ दिया जाता है जिसे मॉडल आगे पढ़ने के लिए इस्तेमाल कर सके।

Chain of Recall इन संदर्भों को जोड़ता है। घटनाओं, Threads और Worker सत्रों को विशिष्ट पहचानकर्ता दिए जाते हैं। इससे एजेंट किसी मौजूदा संदेश से उसकी चर्चा, फिर उससे जुड़े Worker और किसी अन्य कोड समीक्षा तक पहुंच सकता है। मकसद यह है कि हर बार पूरा इतिहास लोड किए बिना अलग-अलग चैनलों में पुराने काम को फिर से ढूंढा जा सके।

DeepSeek रुकावट की एक और तात्कालिक समस्या का भी समाधान करता है: कोई लंबा कमांड पारंपरिक एजेंट को जवाब देने से रोक सकता है। इसका एसिंक्रोनस तरीका काम को बैकग्राउंड में शुरू करता है और नतीजे को नई घटना के रूप में भेजता है। उपयोगकर्ता इस दौरान निर्देश देना जारी रख सकते हैं, जैसे एजेंट से दिशा बदलने या रुकने को कहना।

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

क्लाउड में समन्वय, स्थानीय कंप्यूटर पर काम

DeepSeek एजेंट चलाने वाली कंप्यूटिंग, सहेजे गए सत्र इतिहास और कमांड चलाने वाली मशीन को अलग-अलग रखता है। प्रस्तावित एजेंट लूप क्लाउड कंटेनरों में चलता है, सत्र की स्थिति डेटाबेस में रहती है और एक हल्की स्थानीय सेवा कमांड चलाकर नतीजे लौटाती है।

यह व्यवस्था Bring Your Own Machine, या BYOM, को समर्थन देती है। डेवलपर किसी नए रिमोट माहौल में सब कुछ ले जाने के बजाय अपनी मौजूदा मशीन जोड़ सकता है, जिसमें रिपॉज़िटरी, टूल और अधूरे बदलाव मौजूद हों। मशीन डिस्कनेक्ट होने पर भी क्लाउड में समन्वय जारी रह सकता है; जिस काम को उस मशीन की जरूरत हो, वह उसके वापस जुड़ने तक इंतजार करेगा।

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

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

प्रयोग में क्या मापा गया

DeepSeek ने प्रयोग की हर व्यवस्था को पांच बार दोहराया। तुलना Super-agent की ऐसे संस्करण से की गई जिसमें सीधे घटना भेजने की सुविधा नहीं थी, और एक सहायक एजेंट वाले एकल सत्र की दो व्यवस्थाओं से भी। काम में कृत्रिम संदेश और लंबे कोडिंग कार्य का अनुकरण करने वाला टूल इस्तेमाल हुआ। संदेशों के बीच का अंतराल और काम की अवधि एक चौथाई कर दी गई थी।

12.4 मिनट का माध्यिका समय बताता है कि आधे काम इस समय तक पूरे हो गए। 15.7 मिनट का 95वां पर्सेंटाइल बताता है कि इस समय के भीतर 95% काम पूरे हुए। तटस्थ निर्देशों वाले एकल सत्र के 29.5 मिनट के 95वें पर्सेंटाइल की तुलना में Super-agent ने यह समय 13.8 मिनट, यानी करीब 47%, घटाया।

काम सौंपने का तरीका इस नतीजे को समझने में मदद करता है। तटस्थ निर्देशों के तहत एकल सत्र ने पांच में से किसी भी प्रयोग में अपने सहायक एजेंट को नहीं बुलाया। काम सौंपने को प्राथमिकता देने का निर्देश मिलने पर उसने चार प्रयोगों में काम सौंपा और पांचवें में काम खुद किया। Super-agent में समन्वय और निष्पादन को अलग रखना सिस्टम की संरचना का हिस्सा है।

इन परीक्षणों में सिम्युलेटेड निष्पादन के साथ शेड्यूलिंग और समन्वय का मूल्यांकन किया गया। असली कोडिंग की गुणवत्ता, स्वतंत्र प्रदर्शन माप और सक्रिय उपयोगकर्ताओं की संख्या के आंकड़े प्रकाशित नहीं किए गए हैं। टीम ने अपने मापों को शुरुआती बताया है। DeepSeek ने उत्पादन संस्करण जारी करने की कोई तारीख नहीं दी है।

तेज समन्वय के लिए अधिक कैश्ड टोकन खर्च होते हैं

Super-agent की समानांतर क्षमता के साथ कैश्ड इनपुट का इस्तेमाल भी बढ़ा। इसने 23.23 मिलियन कैश्ड टोकन पढ़े, जबकि एकल सत्र की दो व्यवस्थाओं ने 6.05 मिलियन और 10.82 मिलियन टोकन पढ़े। टोकन टेक्स्ट की छोटी इकाइयां हैं जिन्हें मॉडल प्रोसेस करता है; कैश्ड रीड में पहले के अनुरोधों से सहेजे गए इनपुट का दोबारा इस्तेमाल होता है।

सीधे घटना भेजने की सुविधा हटाने से कैश्ड रीड 23.23 मिलियन से बढ़कर 31.77 मिलियन हो गए, यानी करीब 37% की वृद्धि हुई। Router के फैसलों की संख्या भी लगभग 30% बढ़ी। इसलिए आगे के संदेश सीधे काम संभाल रहे Worker को भेजने से समानांतर व्यवस्था में समन्वय का काम बचा।

अधिक ट्रैफिक संभालने में बैचिंग ने Router की मदद की। घटनाओं की दर करीब एक से बढ़कर 40 ट्रिगर प्रति मिनट होने पर औसत बैच आकार 1.0 से बढ़कर 2.8 हो गया और अनुरोध की अवधि 2.5 से बढ़कर 3.9 सेकंड हो गई। हर Router निर्णय के लिए आवंटित अनुमान समय 6.4 से घटकर 1.6 सेकंड बताया गया।

व्यावहारिक समझौता यह है कि लोगों को कम इंतजार करना पड़ता है, लेकिन अलग-अलग सत्रों में मॉडल प्रोसेसिंग बढ़ती है। टोकन के ये आंकड़े मौद्रिक खर्च नहीं बताते। इसे लागू करने की सोच रही टीमों को मॉडल की कीमतों, समवर्ती काम की सेटिंग और अपने वास्तविक वर्कलोड को ध्यान में रखना होगा।

स्थानीय अनुमतियों के कारण सुरक्षा अहम चिंता

प्रोटोटाइप के निष्पादन संबंधी दस्तावेज़ों के मुताबिक, Worker के कमांड ऑपरेटर के ऑपरेटिंग सिस्टम खाते के तहत बिना अनुमति मांगे चलते हैं। पांच सेकंड के बाद अग्रभूमि में चल रहे शेल कमांड बैकग्राउंड में चले जाते हैं और बैकग्राउंड के काम को हर चरण में 30 मिनट तक मिलते हैं। इन सेटिंग्स के कारण ऑपरेटर के खाते की अनुमतियां तैनाती से जुड़ी अहम चिंता बन जाती हैं।

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

DeepSeek सुरक्षा और गोपनीयता, Router का विस्तार, लंबे समय तक मेमोरी बनाए रखना और एजेंट इंस्टेंसों के बीच संवाद को ऐसे क्षेत्र बताता है जिन पर काम बाकी है। README उपयोगकर्ताओं से कोड की समीक्षा और उसे अपने हिसाब से ढालने को कहता है। इसमें चेतावनी है कि बग और असंगत इंजीनियरिंग तरीके मौजूद हो सकते हैं। इंजीनियरिंग का काफी हिस्सा खुद कोडिंग एजेंटों ने किया है।

लॉन्च पर तेजी से ध्यान गया, जिसमें Hugging Face के शोध प्रमुख Leandro von Werra की पोस्ट भी शामिल थी। घटनाक्रम दिखाता है कि प्रोटोटाइप कितनी तेजी से फैला:

• 31 अक्टूबर, 2026, 09:32 UTC: GitHub रिपॉज़िटरी बनाई गई।
• 31 अक्टूबर: Harness टीम ने अपना डिज़ाइन निबंध प्रकाशित किया; 22:10 UTC तक रिपॉज़िटरी को 2,046 स्टार और 172 फोर्क मिल चुके थे।
• 1 नवंबर, 04:20 UTC: रिपॉज़िटरी के स्टार बढ़कर 3,433 हो गए।

इंजीनियरिंग टीमों के सामने तत्काल फैसला यह है कि वे प्रयोगात्मक समन्वय सिस्टम की जांच करके उसे अपने हिसाब से ढालें या नहीं। इसकी खासियत कम रुकावटों के साथ अधिक काम संभालने की संभावना है; लेकिन इसके संचालन में कोड की समीक्षा, अनुमतियां तय करना और यह फैसला करना शामिल है कि किन कार्रवाइयों के लिए किसी व्यक्ति की जरूरत है।

मुख्य बिंदु

• DeepSeek ने एक GitHub रिपॉज़िटरी में कोडिंग के काम के लिए MIT लाइसेंस वाला शोध प्रोटोटाइप जारी किया है, जिसमें Feishu का वैकल्पिक एकीकरण भी है।
• Router समन्वय संभालता है, जबकि अलग-अलग Workers एक साथ काम करते हैं।
• लिखित नियमों के तहत आंतरिक सिस्टम सीधे टैग किए बिना बताए गए बग की जांच कर सकता है।
• कृत्रिम परीक्षणों में काम पूरा होने का माध्यिका समय 12.4 मिनट और 95वां पर्सेंटाइल 15.7 मिनट दर्ज हुआ। इसमें एकल सत्र के विकल्पों की तुलना में कैश्ड टोकन का इस्तेमाल अधिक था।
• Workers ऑपरेटर के खाते के तहत बिना अनुमति लिए कमांड चलाते हैं, इसलिए अनुमतियां और क्रेडेंशियल अहम चिंता हैं।
• सार्वजनिक कोड आंतरिक सिस्टम से अलग है और DeepSeek का आधिकारिक उत्पाद होने के बजाय शोध प्रोटोटाइप है।