मल्टी-एजेंट सिस्टम (Multi-Agent System, MAS) ऐसी व्यवस्था है जिसमें कई AI एजेंट भूमिकाएँ बाँटकर समानांतर काम करते हैं और मिलकर एक काम पूरा करते हैं। एक समन्वयक एजेंट काम बाँटता है, काम करने वाले एजेंट (सब-एजेंट) अपने-अपने अलग संदर्भ (कॉन्टेक्स्ट) में खोज या लेखन करते हैं, और समन्वयक नतीजों को जोड़ता है।

लेकिन एजेंट बढ़ा देने से सिस्टम अपने-आप ज़्यादा समझदार नहीं हो जाता। Google Research और अन्य शोधकर्ताओं के छह तरह के कामों पर किए गए प्रयोग में, अकेले एजेंट की तुलना में मल्टी-एजेंट सेटअप बाँटे जा सकने वाले काम में अधिकतम लगभग 81% बेहतर रहे, जबकि क्रम से आगे बढ़ने वाले काम में अधिकतम 70% तक खराब। यह लेख परिभाषा और पाँच पैटर्न समझाने के बाद, उसी प्रयोग और Anthropic, Cognition आदि की सार्वजनिक सामग्री के आधार पर यह तय करने में मदद करता है कि किस काम में यह फ़ायदा देता है और किस काम में उल्टा नुकसान करता है।

ORCHESTRATOR · WORKER PATTERN

मल्टी-एजेंट = भूमिकाएँ बाँटकर समानांतर चलने वाली टीम

— एक ही AI से सब कुछ करवाने के बजाय, विशेषज्ञों की एक छोटी टीम काम बाँट लेती है

★
ORCHESTRATOR — समन्वयक
काम बाँटता है और तय करता है कि कौन क्या करेगा। काम करने वालों के नतीजे जाँचता है, विरोधाभास दूर करता है और जवाब तैयार करता है।
SUBAGENT A
रिसर्च और खोज
SUBAGENT B
कोड लिखना
SUBAGENT C
समीक्षा और जाँच
SUBAGENT D
डॉक्यूमेंटेशन

हर एक के पास अपनी अलग कॉन्टेक्स्ट विंडो होती है और सब समानांतर चलते हैं।
समन्वयक नतीजों को जोड़ने से पहले जाँचता है — प्रयोगों में ऐसे जाँचने वाले समन्वयक के होने या न होने से गलतियों के फैलाव में बड़ा फ़र्क़ पड़ा।

विषय-सूची

1. मल्टी-एजेंट सिस्टम क्या है

मल्टी-एजेंट सिस्टम (Multi-Agent System, MAS) ऐसी व्यवस्था है जिसमें कई AI एजेंट मिलकर एक काम हल करते हैं। हर एजेंट के अपने निर्देश (प्रॉम्प्ट), अपने टूल और अपना कॉन्टेक्स्ट होता है, और नतीजों के आदान-प्रदान से वे पूरा लक्ष्य हासिल करते हैं।

इसकी बुनियादी इकाई एक अकेला एजेंट है, जो AI एजेंट क्या है में बताए अनुसार "सोचो → टूल चलाओ → नतीजा देखो" का चक्र अकेले चलाता है। मल्टी-एजेंट सिस्टम को सबसे सही ढंग से ऐसे समझें: वही चक्र, साथ में भूमिकाओं का बँटवारा और समानांतरता।

अकेले एजेंट से यह कैसे अलग है

पहलूअकेला एजेंटमल्टी-एजेंट
ढाँचाएक AI चक्र चलाता हैकई AI साथ मिलकर काम करते हैं
कॉन्टेक्स्टसब कुछ एक ही विंडो मेंभूमिका के हिसाब से अलग (असंबंधित जानकारी नहीं मिलती)
समानांतरताज़्यादातर एक के बाद एककाम करने वाले एक साथ आगे बढ़ सकते हैं
गलतियों का फैलावअपनी गलतियाँ जमा होती जाती हैंजाँचने वाला न हो तो एक एजेंट की गलती सीधे अंतिम नतीजे में पहुँचती है
लागतकम (चैट का लगभग 4 गुना)ज़्यादा (चैट का लगभग 15 गुना)
किसमें अच्छाक्रमवार काम जिसमें हर कदम पिछले पर निर्भर होस्वतंत्र हिस्सों में बँट सकने वाली रिसर्च, तुलना और जाँच

टोकन के ये गुणक Anthropic ने अपने रिसर्च फ़ीचर के बारे में प्रकाशित किए थे (How we built our multi-agent research system, 13 जून 2025)। विस्तार खंड 6 में।

2. कई AI को साथ क्यों चलाएँ

शुरुआती सिद्धांत यह है: "अगर एक एजेंट सब संभाल ले, तो एक ही रखें।" मल्टी-एजेंट सिस्टम की ज़रूरत तब पड़ती है जब आप ऐसी तीन दीवारों से टकराते हैं जिन्हें अकेला एजेंट अपनी बनावट के कारण मुश्किल से पार कर पाता है।

3 WALLS OF SINGLE AGENT

तीन दीवारें जिन्हें अकेला एजेंट मुश्किल से पार करता है

दीवार 1: कॉन्टेक्स्ट भर जाता है
खोज के नतीजे, कोड, एरर लॉग और बीच की सोच सब एक ही विंडो में डालने पर कॉन्टेक्स्ट की सीमा करीब आ जाती है और शुरुआत के ज़रूरी निर्देश दब जाते हैं।
दीवार 2: कुछ भी एक साथ नहीं चलता
"10 कंपनियों पर रिसर्च करो" या "3 तरीकों से लागू करके देखो" अकेले एजेंट के साथ क्रमवार हो जाता है, और इंतज़ार उसी अनुपात में बढ़ता है।
दीवार 3: बनाने वाला और जाँचने वाला एक ही
उसी कॉन्टेक्स्ट में अपना काम दोबारा देखने का मतलब है वही मान्यताएँ, इसलिए चीज़ें छूट जाती हैं। अलग कॉन्टेक्स्ट वाला एजेंट उसे दूसरे कोण से देखता है।

असर के उदाहरण के तौर पर, Anthropic ने बताया कि Claude के रिसर्च (Research) फ़ीचर में Claude Opus 4 को समन्वयक और Claude Sonnet 4 को काम करने वाले एजेंट बनाने वाला सेटअप उसके आंतरिक रिसर्च मूल्यांकन में अकेले Opus 4 से 90.2% बेहतर रहा (वही स्रोत)। उसी लेख में लिखा है कि इस्तेमाल हुए टोकन की मात्रा अकेले ही प्रदर्शन के उतार-चढ़ाव का 80% समझा देती थी (BrowseComp नाम के रिसर्च मूल्यांकन में)। यानी मल्टी-एजेंट सिस्टम की ताक़त का बड़ा हिस्सा इस बात से आता है कि अलग-अलग कॉन्टेक्स्ट साथ-साथ चलकर उतना पढ़ लेते हैं जितना एक एजेंट में समा नहीं सकता।

3. पाँच पैटर्न

मल्टी-एजेंट सिस्टम के कुछ गिने-चुने ढाँचे हैं। हर प्रोडक्ट इन्हें अलग नाम देता है, लेकिन ज़्यादातर ये नीचे के पाँच में आ जाते हैं। जहाँ लागू हो, वहाँ खंड 4 के प्रयोग की संबंधित श्रेणी (स्वतंत्र, केंद्रीकृत, विकेंद्रीकृत, हाइब्रिड) भी दी गई है।

3-1. ऑर्केस्ट्रेटर–वर्कर (सबसे ज़्यादा इस्तेमाल होने वाला)

एक समन्वयक (ऑर्केस्ट्रेटर) काम बाँटकर कई वर्कर (सब-एजेंट) को देता है। हर वर्कर अलग कॉन्टेक्स्ट में चलता है और अपना नतीजा समन्वयक को लौटाता है। प्रयोग की भाषा में यह केंद्रीकृत (Centralized) सेटअप है। Anthropic का रिसर्च फ़ीचर, Claude Code के सब-एजेंट और OpenAI Agents SDK में "एजेंट को टूल की तरह बुलाने" का तरीका (Agent.as_tool()) इसी पैटर्न पर चलते हैं।

3-2. हैंडऑफ़ (ज़िम्मेदारी की रिले)

एजेंट बातचीत की कमान एक-दूसरे को सौंपते हैं, मानो कह रहे हों "अब से तुम संभालो"। OpenAI Agents SDK के दस्तावेज़ के अनुसार, हैंडऑफ़ पाने वाला विशेषज्ञ उस टर्न के बाकी हिस्से के लिए सक्रिय एजेंट बन जाता है। यह फ़्रंट-डेस्क जैसे काम के लिए ठीक है, जैसे किसी पूछताछ को रिसेप्शन से बिलिंग या तकनीकी सहायता तक भेजना। इस SDK का प्रायोगिक पूर्ववर्ती Swarm अब अपनी रिपॉज़िटरी में बताता है कि उसकी जगह Agents SDK ने ले ली है, इसलिए नए प्रोजेक्ट Agents SDK पर बनाएँ।

3-3. पदानुक्रम (टीमों की टीम)

एक पेड़ जैसा ढाँचा, जिसमें मुख्य समन्वयक के नीचे बीच के समन्वयक और उनके नीचे वर्कर होते हैं। Claude Code में सब-एजेंट अपने सब-एजेंट डिफ़ॉल्ट रूप से तीन स्तर तक चला सकते हैं (आधिकारिक दस्तावेज़), और Cursor ने भी फ़रवरी 2026 के 2.5 संस्करण में वर्कर को वर्कर चलाने की सुविधा दी। हर अतिरिक्त स्तर टोकन और इंतज़ार बढ़ाता है, इसलिए गहराई की सीमा तय करें।

3-4. पीयर-टू-पीयर (बहस और सहमति)

कोई समन्वयक नहीं: कई एजेंट बराबरी से अपनी राय रखते हैं और सहमति बनने तक दोहराते हैं। प्रयोग की भाषा में यह विकेंद्रीकृत (Decentralized) सेटअप है। Multi-Agent Debate पर हुए शोध में तथ्यात्मकता और तर्क में सुधार बताया गया है। यह उन कामों में अच्छा करता है जिनमें कई नज़रियों को आमने-सामने रखना हो, जैसे वेब पर रिसर्च (खंड 4)।

3-5. पाइपलाइन (तय क्रम)

हर एजेंट एक तय क्रम में चलता है, जैसे "रिसर्च → ढाँचा बनाना → जाँच → आउटपुट"। अगला एजेंट कौन चलेगा, यह AI नहीं बल्कि प्रोग्राम तय करता है, इसलिए नतीजे स्थिर रहते हैं और यह पता लगाना आसान होता है कि गड़बड़ कहाँ हुई। OpenAI Agents SDK "चेनिंग" (एक का आउटपुट अगले का इनपुट) और "मूल्यांकन लूप" (बनाने वाले और परखने वाले एजेंट को बारी-बारी चलाना) को कोड में बनाए जाने वाले पैटर्न के रूप में बताता है।

PATTERN AT A GLANCE

पाँचों पैटर्न एक नज़र में

① ORCHESTRATOR/WORKER
समन्वयक और समानांतर वर्कर। बाँटी जा सकने वाली रिसर्च और तुलना के लिए।
② HANDOFF
ज़िम्मेदारी की रिले। फ़्रंट-डेस्क और रूटिंग के लिए।
③ HIERARCHY
टीमों की टीम। बड़े कामों के लिए, गहराई की सीमा के साथ।
④ PEER-TO-PEER
बराबरी की बहस और सहमति। नज़रियों को परखने के लिए।
⑤ PIPELINE
तय क्रम। उन व्यावसायिक प्रक्रियाओं के लिए जिन्हें दोहराया जा सके।

4. प्रयोगों से क्या पता चला: कहाँ फ़ायदा, कहाँ नुकसान

कौन-सा पैटर्न जीतेगा, यह काम की प्रकृति के हिसाब से उलट जाता है। इसे आँकड़ों में दिखाने वाला पेपर है Google Research, Google DeepMind और अन्य संस्थानों के शोधकर्ताओं का Towards a Science of Scaling Agent Systems (नवीनतम संस्करण अप्रैल 2026)। इसमें GPT, Gemini और Claude — तीन मॉडल परिवारों — के साथ पाँच सेटअप (एक अकेला एजेंट और चार मल्टी-एजेंट) की छह तरह के कामों और 260 संयोजनों पर तुलना की गई है (Google Research ब्लॉग पर जनवरी 2026 में परिचय; ब्लॉग में बताए 180 संयोजन पहले संस्करण के हैं)।

हर काम में सबसे अच्छा मल्टी-एजेंट सेटअप और अकेले एजेंट से उसका अंतर

वित्तीय विश्लेषणFinance-Agent · केंद्रीकृत
+80.8%
वेब रिसर्चBrowseComp-Plus · विकेंद्रीकृत
+9.2%
दफ़्तरी कामWorkBench · विकेंद्रीकृत
+5.6%
टर्मिनल का कामTerminal-Bench · स्वतंत्र
+1.7%
कोड सुधारनाSWE-bench Verified · हाइब्रिड
−2.1%
चरणबद्ध योजनाPlanCraft · हाइब्रिड
−39.1%

स्रोत: पेपर का खंड 4.2। कोड सुधारने और योजना बनाने में परखे गए सभी मल्टी-एजेंट सेटअप अकेले एजेंट से पीछे रहे; यहाँ सबसे कम पिछड़ने वाला दिखाया गया है (कोड सुधारना −2.1% से −14.9%, योजना −39.1% से −70.0%)।

तीन बातें साफ़ दिखती हैं।

  • बड़ा फ़ायदा सिर्फ़ बाँटे जा सकने वाले काम में: वित्तीय विश्लेषण में आय, लागत और बाज़ार अलग-अलग खोजकर आख़िर में जोड़े जा सकते हैं, इसलिए केंद्रीकृत सेटअप अकेले एजेंट से लगभग 81% आगे रहा।
  • क्रम पर टिके काम में उल्टा असर: योजना वाले काम में, जहाँ हर कदम अगला कदम तय करता है, हर सेटअप अकेले एजेंट से खराब रहा। काम बाँटने से वर्करों की मान्यताएँ अलग-अलग दिशा में चली जाती हैं और तालमेल में मेहनत लगती है।
  • कोड सुधारने में भी सुधार नहीं: Anthropic भी लिखती है कि ज़्यादातर कोडिंग कामों में रिसर्च की तुलना में सचमुच समानांतर हो सकने वाले हिस्से कम होते हैं (उसका लेख), जो इस नतीजे से मेल खाता है।

जाँचने वाला समन्वयक गलतियों का फैलाव रोकता है

उसी पेपर ने हर सेटअप में मापा कि वर्करों की गलतियाँ अंतिम नतीजे तक कितनी फैलती हैं (गुणक के रूप में, अकेला एजेंट = 1)।

स्वतंत्र (न चर्चा, न जाँच)

17.2×

नतीजे बस साथ रख दिए जाते हैं, इसलिए गलतियाँ बनी रहती हैं

विकेंद्रीकृत (बराबरी की बहस)

7.8×

बहस से कुछ गलतियाँ सुधरती हैं, पर जाँच की ज़िम्मेदारी किसी की नहीं

हाइब्रिड

5.1×

समन्वयक के साथ वर्करों के बीच कुछ चर्चा

केंद्रीकृत (समन्वयक जाँचता है)

4.4×

समन्वयक वर्करों के नतीजे जोड़ने से पहले जाँचता है

स्रोत: पेपर की तालिका 5 (Error Amp)। उसी तालिका में प्रति काम टर्न की औसत संख्या अकेले एजेंट के लिए 7.2 थी, जबकि केंद्रीकृत के लिए 27.7 और हाइब्रिड के लिए 44.3।

"अगर अकेला एजेंट पहले से 45% या ज़्यादा हल कर लेता है, तो एजेंट जोड़ना अक्सर उल्टा पड़ता है।" पेपर बताता है कि जिन कामों में अकेले एजेंट की सटीकता पहले से लगभग 45% से ऊपर है, वहाँ एजेंट जोड़ने से अंक घटने की प्रवृत्ति रहती है। प्रयोग इस क्रम का समर्थन करता है: पहले एक एजेंट से मापें, और वह आँकड़ा देखकर ही तय करें कि और जोड़ना है या नहीं।

5. असली प्रोडक्ट इसे कैसे इस्तेमाल करते हैं

Anthropic का रिसर्च फ़ीचर: सवाल की कठिनाई के हिसाब से वर्करों की संख्या

Claude का Research ऑर्केस्ट्रेटर–वर्कर पैटर्न का क्लासिक उदाहरण है: समन्वयक सवाल बाँटता है, वर्कर समानांतर खोज करते हैं और समन्वयक नतीजे जोड़ता है। प्रकाशित डिज़ाइन की सबसे काम की बात यह है कि प्रॉम्प्ट में लिखा है कि सवाल की कठिनाई के हिसाब से कितने वर्कर लगाने हैं (उसका लेख)।

सवाल का प्रकारवर्करों की संख्याटूल कॉल
सीधा तथ्य जाँचना1 (सिर्फ़ समन्वयक)3–10
सीधी तुलना2–4हर एक के 10–15
जटिल रिसर्चकभी-कभी 10 से ज़्यादाहर वर्कर की ज़िम्मेदारी साफ़ अलग

Anthropic बताती है कि इन नियमों से पहले शुरुआती संस्करण एक आसान सवाल के लिए 50 वर्कर चला देने जैसी गलतियाँ करते थे। अपना सिस्टम बनाते समय सबसे तेज़ तरीका है इस तालिका को सीधे प्रॉम्प्ट में "काम का आकार तय करने के नियम" के रूप में डाल देना। इसके अलावा, खोज और दूसरे टूल को समानांतर बुलाने से जटिल सवालों का रिसर्च समय 90% तक कम हुआ।

Claude Code और Codex के सब-एजेंट

Claude Code में आप रिसर्च, समीक्षा और ऐसे काम सब-एजेंट को सौंप सकते हैं। हर सब-एजेंट अपने कॉन्टेक्स्ट में चलता है और मुख्य एजेंट को सिर्फ़ सारांश लौटाता है, इसलिए मुख्य कॉन्टेक्स्ट नहीं भरता। डिफ़ॉल्ट रूप से एक साथ 20 तक चल सकते हैं, और नेस्टिंग तीन स्तर तक। "एजेंट टीम", जिसमें वर्कर काम के दौरान आपस में बात करते हैं, उससे यह कैसे अलग है, यह Claude Code में सब-एजेंट बनाम एजेंट टीम में है, और Codex के साथ तुलना करते हुए समानांतर काम कैसे माँगें, यह Codex और Claude Code के समानांतर सब-एजेंट में।

Devin (Cognition): "मत बनाओ" से "समन्वय करो" तक

जून 2025 में Cognition ने "Don't Build Multi-Agents" प्रकाशित किया, जिसमें तर्क था कि एक-दूसरे के फ़ैसले न जानने वाले समानांतर वर्कर आपस में टकराने वाले नतीजे देते हैं। इसके दो सिद्धांत हैं: "कॉन्टेक्स्ट साझा करो, और अलग-अलग संदेश नहीं बल्कि एजेंट का पूरा काम-क्रम साझा करो" और "कामों में छिपे फ़ैसले होते हैं, और टकराते फ़ैसले खराब नतीजे लाते हैं"।

मार्च 2026 में उसी कंपनी ने एक फ़ीचर जारी किया जिसमें Devin बड़े काम को बाँटकर कई Devin को सौंपता है, जो अपनी-अपनी वर्चुअल मशीन में समानांतर काम करते हैं। मुख्य Devin प्रगति पर नज़र रखता है, टकराव सुलझाता है और नतीजे इकट्ठा करता है। यानी समानांतरता छोड़ी नहीं गई, बल्कि ऐसा ढाँचा अपनाया गया जिसमें वर्करों के बीच के टकराव की ज़िम्मेदारी मुख्य एजेंट लेता है — जो खंड 4 के जाँचने वाले समन्वयक वाले निष्कर्ष से मेल खाता है।

Cursor: वर्करों का इंतज़ार किए बिना आगे बढ़ना

संस्करण 2.5 (17 फ़रवरी 2026) में Cursor ने सब-एजेंट को एसिंक्रोनस चलाना शुरू किया, ताकि मुख्य एजेंट इंतज़ार किए बिना काम जारी रखे। वर्कर अपने वर्कर भी चला सकते हैं। Anthropic भी लिखती है कि सिंक्रोनस तरीका, जिसमें समन्वयक वर्करों के ख़त्म होने का इंतज़ार करता है, अड़चन पैदा करता है; इसलिए मुख्य एजेंट को इंतज़ार न कराना सभी कंपनियों की साझा चुनौती बन गया है।

6. लागत: चैट से लगभग 15 गुना टोकन

Anthropic लिखती है कि एजेंट चैट से लगभग 4 गुना और मल्टी-एजेंट सिस्टम लगभग 15 गुना टोकन इस्तेमाल करते हैं (उसका लेख)। अपने इस्तेमाल पर लागू करें तो अनुमान कुछ ऐसा बनता है।

अनुमान का उदाहरण (गुणक Anthropic के रिसर्च फ़ीचर के; काम के हिसाब से बदलते हैं)

चैट में 10,000 टोकन लेने वाला सवाल → एक एजेंट से लगभग 40,000, और मल्टी-एजेंट सिस्टम से लगभग 1,50,000 टोकन।

रोज़ 100 अनुरोध हों तो: चैट 10 लाख, एक एजेंट 40 लाख, मल्टी-एजेंट 1.5 करोड़ टोकन। फिर अपने मॉडल की आधिकारिक मूल्य-सूची से प्रति टोकन कीमत से गुणा करें।

REAL COST GAP

बढ़ते सिर्फ़ टोकन ही नहीं

टोकन (चैट की तुलना में)
एक एजेंट में लगभग 4 गुना और मल्टी-एजेंट में लगभग 15 गुना (Anthropic)। वर्करों और स्तरों की संख्या इसे और बदलती है।
टर्न की संख्या (अकेले एजेंट की तुलना में)
खंड 4 के पेपर में अकेले एजेंट का औसत 7.2 टर्न था, जबकि केंद्रीकृत का 27.7 (लगभग 3.8 गुना)। तालमेल की अतिरिक्त बातचीत से हर अनुरोध का समय भी बढ़ने लगता है।
इंतज़ार का समय
समानांतर रिसर्च से कुल समय घट सकता है (Anthropic के अनुसार 90% तक)। लेकिन अगर मुख्य एजेंट सभी वर्करों का इंतज़ार करे, तो सबसे धीमा वर्कर रफ़्तार तय करता है।

रोकने वाली सीमाएँ और दिशा देने वाले लक्ष्य अलग रखें

जब वर्कर वर्कर चलाने लगें और कुछ लूप में फँस जाए, तो खर्च तेज़ी से बढ़ता है। Claude के साथ बनाते समय दो तरह की सीमाएँ होती हैं जो अलग तरह काम करती हैं।

सीमाकहाँ सेट करेंक्या रन रुकता है
खर्च की सीमाClaude Agent SDK में max_budget_usd (TypeScript में maxBudgetUsd)हाँ (नए वर्कर नहीं चलते और क्वेरी ख़त्म होती है)
नेस्टिंग की गहराईएनवायरनमेंट वेरिएबल CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (डिफ़ॉल्ट 3, 1 रखने पर नेस्टिंग बंद)हाँ (सबसे निचले स्तर के वर्कर काम ख़ुद करते हैं)
एक साथ चलने वाले वर्करएनवायरनमेंट वेरिएबल CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS (डिफ़ॉल्ट 20)हाँ (सीमा से ऊपर वर्कर नहीं चलते)
टास्क बजटClaude API में task_budget (बीटा, न्यूनतम 20,000 टोकन)नहीं (एक लक्ष्य, जिसके हिसाब से मॉडल अपनी रफ़्तार बाँटता है)

स्रोत: Subagents in the Agent SDK और Task budgets (12 नवंबर 2026 को जाँचा गया)। ऊपर की तीन रोकने वाली सीमाएँ TypeScript SDK v0.3.219 और Python SDK v0.2.127 या उसके बाद के संस्करणों पर लागू हैं; पुराने संस्करणों में इनमें से कुछ नहीं हैं या उनके डिफ़ॉल्ट अलग हैं। दस्तावेज़ टास्क बजट को अनिवार्य नहीं बल्कि सलाह के तौर पर बताता है, इसलिए जब रन को पक्के तौर पर रोकना हो, तो इसे खर्च की सीमा या max_tokens के साथ मिलाकर इस्तेमाल करें।

7. निर्णय तालिका: इस्तेमाल करें या नहीं

ऊपर की सारी सामग्री को जोड़ें तो ज़्यादातर फ़ैसले पाँच सवालों से तय हो जाते हैं। ऊपर से नीचे जवाब दें; अगर कोई भी जवाब "अकेला एजेंट" वाले खाने में जाए, तो पहले एक एजेंट से शुरुआत करें।

सवालमल्टी-एजेंट के पक्ष मेंअकेले एजेंट के पक्ष मेंआधार
क्या काम को स्वतंत्र हिस्सों में बाँटा जा सकता है?हाँ (कंपनी, दस्तावेज़ या पहलू के हिसाब से)हर कदम पिछले नतीजे पर टिका हैवित्तीय विश्लेषण +80.8%, योजना −39.1% से −70.0%
अकेला एजेंट अभी कितना अच्छा करता है?अकेले एजेंट की सटीकता कमअकेला एजेंट पहले से लगभग 45% या ज़्यादा हल करता हैGoogle Research और अन्य का पेपर
क्या वर्करों को एक ही कॉन्टेक्स्ट साझा करना ज़रूरी है?हर वर्कर की अपनी जानकारी काफ़ी हैसब एक ही कॉन्टेक्स्ट न देखें तो नतीजे टकराते हैं (ज़्यादातर कोडिंग)Anthropic, Cognition
क्या यह एक कॉन्टेक्स्ट में समा जाता है?सामग्री बहुत ज़्यादा, एक एजेंट का कॉन्टेक्स्ट भर जाता हैएक एजेंट के कॉन्टेक्स्ट में समा जाता हैटोकन की मात्रा ने प्रदर्शन के उतार-चढ़ाव का 80% समझाया
क्या नतीजा 15 गुना टोकन के लायक है?हर अनुरोध का ऊँचा मूल्य (रिसर्च, ऑडिट और तुलना की रिपोर्ट)भारी मात्रा का रोज़मर्रा काम, तुरंत जवाब चाहने वाला फ़्रंट-डेस्कAnthropic का ~15 गुना

Anthropic भी अपनी एजेंट बनाने की गाइड में सलाह देती है कि जितना हो सके सरल हल से शुरू करें और ज़रूरत पड़ने पर ही जटिलता जोड़ें। शुरुआत के कदम और छोटे कोड उदाहरण मल्टी-एजेंट सिस्टम कैसे बनाएँ में हैं, और अपना पहला अकेला एजेंट बनाने का तरीका AI एजेंट कैसे बनाएँ में।

8. डिज़ाइन की मुख्य बातें और आम विफलताओं के प्रकार

① हर वर्कर को लक्ष्य, आउटपुट का रूप, टूल और सीमाएँ दें

Anthropic लिखती है कि धुँधले निर्देशों पर वर्कर काम गलत समझते हैं, दूसरे वर्करों जैसी ही खोज दोहराते हैं या ज़रूरी जानकारी चूक जाते हैं। हर वर्कर को साफ़ बताएँ: (1) लक्ष्य, (2) किस रूप में लौटाना है, (3) कौन-से टूल और स्रोत इस्तेमाल कर सकता है, और (4) काम की सीमा। Claude Agent SDK के सब-एजेंट को मुख्य एजेंट की बातचीत नहीं मिलती; उसे सिर्फ़ वही प्रॉम्प्ट मिलता है जिससे आप उसे बुलाते हैं (आधिकारिक दस्तावेज़), इसलिए फ़ाइल पाथ और पहले लिए गए फ़ैसले उसी प्रॉम्प्ट में लिखें।

② बताएँ कि कितनी गहराई तक जाना है

वर्कर ख़ुद यह तय करने में कमज़ोर होते हैं कि कितनी गहराई तक खोजें। खंड 5 की तालिका जैसे आकार के नियम लिखें और साथ में तर्क की गहराई भी तय करें। Claude का effort हर वर्कर के लिए अलग सेट किया जा सकता है, और Agent SDK की एजेंट परिभाषा में low से max तक के मान चुने जा सकते हैं। आसान वर्करों को हल्का और जाँच वाले वर्करों को गहरा रखने से खर्च काबू में रहता है।

③ जाँच को समन्वयक के काम का हिस्सा बनाएँ

जैसा खंड 4 में दिखा, केंद्रीकृत सेटअप — जिसमें समन्वयक नतीजे जोड़ने से पहले जाँचता है — ने बिना जाँच वाले स्वतंत्र सेटअप से कहीं कम गलतियाँ फैलाईं (4.4× बनाम 17.2×)। समन्वयक के निर्देशों में यह कदम जोड़ें: वर्करों के नतीजों के बीच विरोधाभास ढूँढो और स्वीकार करने से पहले सबूत जाँचो।

④ विफलताओं के प्रकार जानें

UC Berkeley और अन्य संस्थानों के शोधकर्ताओं ने सात मल्टी-एजेंट सिस्टम के 1,600 से ज़्यादा रन रिकॉर्ड के आधार पर विफलताओं को 3 श्रेणियों और 14 प्रकारों में बाँटा (Why Do Multi-Agent LLM Systems Fail?)। डिज़ाइन की समीक्षा करते समय इसे जाँच-सूची की तरह इस्तेमाल किया जा सकता है।

श्रेणीक्या होता हैउपाय
डिज़ाइन की समस्याएँएजेंट भूमिका या काम के निर्देश नहीं मानते, वही कदम दोहराते हैं, या नहीं जानते कि कब रुकना हैप्रॉम्प्ट में भूमिका, दायरा और रुकने की शर्त लिखें
एजेंटों के बीच तालमेल की कमीमान्यताएँ टकराती हैं, ज़रूरी जानकारी आगे नहीं जाती, दूसरे एजेंटों की बात अनसुनी होती हैपूरा काम-क्रम साझा करें; टकराव समन्वयक सुलझाए
जाँच की कमीसमय से पहले रुक जाना, जाँच न करना या ऊपरी जाँच करनाजाँचने वाला तय करें (समन्वयक या जाँच वाला वर्कर)

⑤ लॉगिंग शुरू से बनाएँ

अगर दिखे ही नहीं कि मल्टी-एजेंट सिस्टम क्या कर रहा है, तो उसे ठीक नहीं किया जा सकता। पहले दिन से हर वर्कर का इनपुट-आउटपुट, लगा समय, टोकन और बुलाए गए टूल दर्ज करें। मूल्यांकन के बारे में Anthropic लिखती है कि उसने असली इस्तेमाल जैसे लगभग 20 सवालों से शुरुआत की और एक तय पैमाने के साथ AI से अंक दिलवाए। बड़े मूल्यांकन तंत्र का इंतज़ार करने के बजाय कुछ सवालों पर बदलाव देखते रहना ही व्यावहारिक रास्ता है।

9. मुख्य SDK में हर पैटर्न कैसे लिखा जाता है

एक ही पैटर्न का नाम हर SDK में अलग होता है। इनमें से किसे चुनें (प्रोटोटाइप की रफ़्तार, प्रोडक्शन की परिपक्वता, टोकन खर्च), इसके लिए AI एजेंट फ़्रेमवर्क की तुलना देखें; यहाँ सिर्फ़ यह दिखाया गया है कि खंड 3 के हर पैटर्न से कौन-सा हिस्सा मेल खाता है।

SDKऑर्केस्ट्रेटर–वर्करहैंडऑफ़ / पाइपलाइन
Claude Agent SDKवर्कर agents में परिभाषित होते हैं और Agent टूल से बुलाए जाते हैं (पुराना नाम Task)कोई अलग हिस्सा नहीं; पाइपलाइन अपने कोड से एजेंटों को क्रम से बुलाकर बनती है
OpenAI Agents SDKवर्कर Agent.as_tool() से टूल की तरह बुलाए जाते हैंकमान handoffs से सौंपी जाती है; चेनिंग और समानांतर रन कोड में बनते हैं
LangGraphसमन्वयक नोड से वर्कर नोड की ओर शाखाक्रम, शाखाएँ और लूप नोड और किनारों के ग्राफ़ के रूप में लिखे जाते हैं
Strands Agents (AWS)वर्कर Agents as Tools से टूल की तरह बुलाए जाते हैंSwarm में वर्कर आपस में काम सौंपते हैं; Graph या Workflow से क्रम तय होता है
Microsoft Agent Frameworkमल्टी-एजेंट समन्वय के पैटर्न तैयार हिस्सों के रूप में देता हैक्रम वर्कफ़्लो के रूप में तय होता है

Microsoft ने AutoGen की रिपॉज़िटरी आर्काइव कर दी है और अब उसके लिए बग या सुरक्षा सुधार नहीं देती (12 नवंबर 2026 को जाँचा गया)। नए प्रोजेक्ट के लिए उसके उत्तराधिकारी Microsoft Agent Framework की सलाह दी गई है। हर SDK के छोटे कोड उदाहरण मल्टी-एजेंट सिस्टम कैसे बनाएँ में हैं।

सारांश

  • मल्टी-एजेंट सिस्टम कई AI में भूमिकाएँ बाँटता है, जो समानांतर काम करके एक काम पूरा करते हैं। यह अकेले एजेंट की दीवारें पार करता है: भरता कॉन्टेक्स्ट, समानांतरता की कमी, और बनाने वाले का ही जाँचने वाला होना।
  • पाँच पैटर्न हैं: ऑर्केस्ट्रेटर–वर्कर, हैंडऑफ़, पदानुक्रम, पीयर-टू-पीयर और पाइपलाइन। सबसे ज़्यादा इस्तेमाल ऑर्केस्ट्रेटर–वर्कर का होता है।
  • फ़ायदा काम पर निर्भर है। बाँटे जा सकने वाले वित्तीय विश्लेषण में यह अकेले एजेंट से +80.8% आगे रहा, क्रम पर टिकी योजना में 39.1% से 70.0% तक पीछे, और कोड सुधारने में भी सुधार नहीं हुआ।
  • जाँचने वाले समन्वयक के साथ गलतियों का फैलाव 17.2× (स्वतंत्र) से घटकर 4.4× रह गया।
  • टोकन चैट के लगभग 15 गुना लगते हैं (एक एजेंट में लगभग 4 गुना)। खर्च, गहराई और एक साथ चलने वाले वर्करों को ऐसी सीमाओं से सेट करें जो सचमुच रन रोकें।
  • फ़ैसले का क्रम: पहले एक एजेंट से बनाएँ और मापें। सिर्फ़ उन्हीं बाँटे जा सकने वाले हिस्सों को वर्करों में अलग करें जहाँ एक एजेंट कम साबित हुआ हो।

FAQ

Q1. क्या मल्टी-एजेंट सिस्टम हमेशा एक समझदार अकेले एजेंट से बेहतर होता है?

नहीं। Anthropic का रिसर्च फ़ीचर अकेले एजेंट से 90.2% बेहतर रहा, लेकिन वह स्वतंत्र हिस्सों में बँट सकने वाली रिसर्च पर था। Google Research और अन्य के प्रयोग में क्रम पर टिके योजना वाले काम में हर मल्टी-एजेंट सेटअप अकेले एजेंट से खराब रहा। सब कुछ इस पर टिका है कि काम बाँटा जा सकता है या नहीं।

Q2. क्या कोडिंग में मल्टी-एजेंट मदद करता है?

एक ही सुधार के अलग-अलग हिस्से कई वर्करों से लिखवाना आमतौर पर मदद नहीं करता। प्रयोग में कोड सुधारने (SWE-bench Verified) में हर मल्टी-एजेंट सेटअप अकेले एजेंट से नीचे रहा, −2.1% से −14.9% तक। दूसरी ओर, रिसर्च, समीक्षा और टेस्ट चलाने जैसे स्वतंत्र काम वर्करों को देकर मुख्य कॉन्टेक्स्ट खाली रखना Claude Code के सब-एजेंट का आम इस्तेमाल है।

Q3. क्या अकेले एजेंट से मल्टी-एजेंट तक धीरे-धीरे जा सकते हैं?

हाँ। पहले एक एजेंट से बनाएँ और सटीकता, टोकन और समय मापें; जब दिखने लगे कि कॉन्टेक्स्ट कहाँ भरता है या क्या समानांतर चल सकता है, तो सिर्फ़ वही हिस्से वर्करों में अलग करें। अगर शुरू से ही सब कुछ मल्टी-एजेंट डिज़ाइन करेंगे, तो माप ही नहीं पाएँगे कि असल में क्या मदद कर रहा है।

Q4. क्या एजेंटों के बीच कोई मानक संचार प्रोटोकॉल है?

एजेंटों को टूल्स और डेटा से जोड़ने में MCP (Model Context Protocol) डी-फ़ैक्टो मानक बन चुका है। यह Anthropic में उत्पन्न हुआ, दिसंबर 2025 में Linux Foundation के Agentic AI Foundation को दान किया गया, और OpenAI, Microsoft, AWS आदि ने इसे अपनाया है। एजेंटों के आपसी संचार के लिए Google से शुरू हुआ A2A (Agent2Agent) है, जो भी Linux Foundation में चला गया है। IBM का ACP (Agent Communication Protocol) अगस्त 2025 में A2A में मिल गया।

Q5. क्या टास्क बजट रखने से खर्च बेकाबू होने से बच जाता है?

अकेले उससे नहीं। Claude API का टास्क बजट एक लक्ष्य है जिसके हिसाब से मॉडल अपनी रफ़्तार बाँटता है, और दस्तावेज़ साफ़ कहता है कि यह अनिवार्य नहीं है। रन को पक्के तौर पर रोकने के लिए Agent SDK की खर्च सीमा (max_budget_usd) और नेस्टिंग की गहराई व एक साथ चलने वाले वर्करों की सीमाएँ सेट करें (खंड 6 की तालिका)।

Q6. क्या "सब-एजेंट" और "मल्टी-एजेंट" अलग चीज़ें हैं?

सब-एजेंट मल्टी-एजेंट सिस्टम के ऑर्केस्ट्रेटर–वर्कर पैटर्न में इस्तेमाल होने वाले वर्कर हैं। Claude Agent SDK में मुख्य एजेंट एक ही रहता है और ज़रूरत पड़ने पर ही Agent टूल से वर्करों को बुलाता है। जिन सेटअप में वर्कर काम के दौरान सीधे आपस में बात करते हैं (जैसे Claude Code की एजेंट टीम), वे पीयर-टू-पीयर या हाइब्रिड पैटर्न के ज़्यादा करीब हैं।