पिछले अध्याय में, हमने एक एजेंट से MCP द्वारा बाहरी टूल जोड़ना देखा। यहाँ तक "दिमाग, औज़ार, याददाश्त, लूप" वाला एक स्वायत्त एजेंट चलने लगा है। पर जब काम बड़ा होता है, तो एक ही में सब कुछ ठूँस देने वाला डिज़ाइन कहीं न कहीं टूट जाता है। इस अध्याय में, भूमिकाएँ बाँटकर कई एजेंटों से हल करने वाले "मल्टी-एजेंट डिज़ाइन" और उसके तालमेल की सोच (A2A: Agent-to-Agent) को, फ़्रेमवर्क से आज़ाद अवधारणा-स्तर पर व्यवस्थित करेंगे।
लक्ष्य है "कब और कैसे बाँटने से मज़बूती बढ़ती है" यह निर्णय ले पाना
जब एक एजेंट काफ़ी न रह जाए
एक एजेंट सरल, साफ़ नज़र आने वाला, और उसकी हरकत भी पकड़ने में आसान होती है — इसीलिए पहले एक ही से बनाना सही है। समस्या तब खड़ी होती है जब उसमें एक के बाद एक भूमिकाएँ जोड़ते जाएँ। "पता लगाओ, लिखो, समीक्षा करो, अनुवाद करो, और प्रकाशित भी करो…" — एक ही प्रॉम्प्ट में ज़िम्मेदारियाँ ठूँस दें, तो एक बिंदु से अचानक सटीकता गिरने लगती है।
वजहें मुख्यतः 3 हैं। ①निर्देश लंबा और धुँधला हो जाता है (यह भी वह भी लिखते जाएँ, तो मॉडल किसे प्राथमिकता दे, यह उलझ जाता है)। ②कॉन्टेक्स्ट फूल जाता है (बेमतलब जानकारी तक समेट लेता है, और असल निर्देश पतला पड़ जाता है)। ③टूल बहुत ज़्यादा हो जाते हैं (विकल्प जितने बढ़ें, गलत टूल चुनना उतना आसान)। एक ही में ज़रूरत से ज़्यादा ठूँसी हालत, मानो "एक ही आदमी को कई भूमिकाएँ थमाकर उलझा देना वाला दफ़्तर" है।
💡 सोच का पलटाव। एक को लगातार समझदार बनाते रहने के बजाय, "एक भूमिका पर केंद्रित छोटे एजेंट, कई, तालमेल से चलाओ" वाली सोच अपनाएँ। यही मल्टी-एजेंट डिज़ाइन की शुरुआत है। इंसानी संगठन में काम बाँटने वाले तर्क की तरह ही, हर एक की ज़िम्मेदारी जितनी संकरी और साफ़, पूरा तंत्र उतना स्थिर रहता है।
पर — बाँटने से हमेशा बेहतर हो, यह ज़रूरी नहीं। बँटवारे के साथ तालमेल की लागत लगी रहती है। इसीलिए इस अध्याय का असल विषय सिर्फ़ "कैसे बाँटें" नहीं, बल्कि "बाँटना चाहिए भी या नहीं" यह परखना है। पहले 3 प्रतिनिधि रूप देखकर, फिर उस निर्णय के आधार पर बढ़ें।
3 बुनियादी पैटर्न
मल्टी-एजेंट के ढाँचे अनगिनत खींचे जा सकते हैं, पर असल काम में बार-बार सामने आने वाला कंकाल 3 में सिमट जाता है। इन तीन को जोड़-मिला लें तो ज़्यादातर ढाँचे समझाए जा सकते हैं। पहले एक-एक करके, भूमिका और कब उपयुक्त-अनुपयुक्त, यह पकड़ें।
माता-पिता (ऑर्केस्ट्रेटर) पूरी योजना बनाता है, टास्क बच्चों (वर्कर) में बाँटकर चलवाता है, और नतीजे इकट्ठे कर एकीकृत करता है। बच्चे एक-दूसरे को नहीं जानते, बस माता-पिता को देखते हैं। केंद्रीकृत और नियंत्रित करने में आसान — यही इसकी ताक़त।
कब उपयुक्त: टास्क को बाँटा जा सके और समानांतर चलाना हो।
चरणों को क़तार में रखें, और पिछले एजेंट का आउटपुट, अगले एजेंट का इनपुट बनाकर क्रम से थमाएँ। जैसे "शोध → लेखन → प्रूफ़रीडिंग"। हर चरण बस एक काम सँभालता है, इसलिए ज़िम्मेदारी साफ़ और जाँच भी आसान।
कब उपयुक्त: तरीका रैखिक हो, और चरण तय हों।
"शोध प्रभारी", "कोड प्रभारी", "समीक्षा प्रभारी" की तरह अपने-अपने क्षेत्र में माहिर विशेषज्ञ एजेंट तैयार करें, और स्थिति के मुताबिक़ चुन-चुनकर बुलाएँ। हर एक के निर्देश और टूल सीमित रख सकते हैं, इसलिए विशेषज्ञता बढ़ती है।
कब उपयुक्त: ज़रूरी क्षमताएँ क्षेत्र दर क्षेत्र बहुत अलग हों।
ये तीन परस्पर विशिष्ट नहीं हैं। असली सिस्टम अक्सर नेस्टेड (एक के भीतर एक) संरचना बन जाता है, जैसे "ऑर्केस्ट्रेटर विशेषज्ञ-प्रकार के वर्करों को बाँधे, और उनमें से एक पाइपलाइन हो"। पहले सबसे बाहरी कंकाल एक तय करें, और सिर्फ़ ज़रूरी जगह पर भीतर दूसरा पैटर्न इस्तेमाल करें — यह जमाने का तरीका सँभालने में आसान है।
📊 उलझन हो तो ① से। तीनों में सबसे बहुउपयोगी है ऑर्केस्ट्रेटर + वर्कर। माता-पिता केंद्र में योजना और एकीकरण थामे रहता है, इसलिए नियंत्रित करना आसान, और यह कई मल्टी-एजेंट ढाँचों का बुनियादी रूप बनता है। पैटर्न का पूरा ब्यौरा मल्टी-एजेंट क्या है, और सिस्टम के रूप में समझने के लिए मल्टी-एजेंट सिस्टम क्या है भी देखें।
कब बाँटें / कब न बाँटें
पैटर्न जान लेने पर, बस मन करता है सब कुछ बाँट दें। पर बँटवारे के साथ हमेशा "तालमेल की लागत" लगती है — एजेंटों के बीच जानकारी थमाना, आपस में मिलाना, इंतज़ार करना। बाँटने से मिलने वाला फ़ायदा जब इस तालमेल-लागत से ज़्यादा हो, तभी मल्टी-एजेंट सही निकलता है। पहले दोनों पहलू साथ रखकर देखें।
- समानांतर चल सकता है: स्वतंत्र सब-टास्क एक साथ चलाकर समय बचा सकते हैं
- विशेषज्ञता चाहिए: क्षेत्र दर क्षेत्र निर्देश-टूल सीमित करने से सटीकता बढ़ती है
- खोज व्यापक है: कई नज़रिए या विकल्प बाँटकर खोजना चाहते हैं
- कॉन्टेक्स्ट अलग करना है: भूमिका दर भूमिका कॉन्टेक्स्ट काटकर मिलावट रोक सकते हैं
- मूलतः सरल है: एक से बन जाने वाले काम को बेवजह जटिल बना देना
- लागत बढ़ती है: एजेंट जितने बढ़ें, LLM कॉल और टोकन उतने जमा होते हैं
- तालमेल भारी है: थमाना और इंतज़ार का बोझ, बँटवारे के फ़ायदे को खा जाता है
- मज़बूत क्रमिक निर्भरता: पिछले नतीजे पर बहुत निर्भर, समानांतरता की गुंजाइश न के बराबर
⚠️ पहले "क्या एक ही काफ़ी है" पूछें। मल्टी-एजेंट ताक़तवर है, पर पहली चाल में चुनने वाली चीज़ नहीं। एक → प्रॉम्प्ट सुधारो → टूल जोड़ो → फिर भी कमी रहे तो बाँटो — इस तरह चरण दर चरण बढ़ना नियम है। जटिलता, "क्या मौजूदा एक सचमुच सीमा पर है" यह पक्का करके ही जोड़ें। बँटवारा बाद में भी हो सकता है।
व्यावहारिक पैमाना यह है — "उस भूमिका को किसी इंसानी सहकर्मी को समझाते वक़्त, क्या वह एक व्यक्ति के जॉब-डिस्क्रिप्शन में सहज बैठ जाती है" — यह कल्पना करें। एक ही पदनाम में लिखा जा सके, तो अभी एक ही काफ़ी है। "यह शोध वाला, यह लेखन वाला" — अलग व्यक्ति बनाने का मन हो, वही पल बँटवारे पर विचार का वक़्त है। निर्णय का पूरा खाका मल्टी-एजेंट सिस्टम कैसे बनाएँ के साथ भी देखें।
एजेंटों के बीच तालमेल (A2A)
बाँटने का तय कर लें, तो अगला डिज़ाइन-सवाल है "एजेंट आपस में जानकारी कैसे लेन-देन करें"। इंसानी टीम की भाषा में यह हैंडओवर दस्तावेज़ का फ़ॉर्मैट या रिपोर्टिंग के नियम तय करने जैसा है। यहाँ धुँधलापन रहे, तो चाहे हर एक कितना भी क़ाबिल हो, पूरा तंत्र नहीं मिलेगा। तालमेल में पकड़ने योग्य बातें मोटे तौर पर 2 हैं।
क्या, किस रूप में थमाना है यह तय करें। "टास्क का निर्देश, ज़रूरी इनपुट, अपेक्षित आउटपुट रूप" को एक स्पष्ट तयशुदा नियम बनाएँ, तो लेने वाला नहीं उलझता। खुले-टेक्स्ट में सब सौंप देने से, संरचित लेन-देन ज़्यादा स्थिर रहता है।
कई आउटपुट को एक में समेटने का चरण। आख़िरी ज़िम्मेदारी लेकर कौन एकीकृत करेगा यह तय कर रखें। विरोधाभासी नतीजे आने पर प्राथमिकता, और समेटने का ढंग (सार, मिलान, बहुमत) भी डिज़ाइन में शामिल करें।
इस "एजेंट आपस में भूमिका बाँटकर तालमेल करें" वाली सोच को और मानकीकृत ढंग से सँभालने की कोशिश ही A2A (Agent-to-Agent) है। पिछले अध्याय का MCP जहाँ "एजेंट ↔ टूल/डेटा" को जोड़ने वाला तयशुदा नियम था, वहीं A2A "एजेंट ↔ एजेंट" को जोड़ने वाला तयशुदा नियम है — सामने वाले एजेंट के पास क्या क्षमता है यह जानने, टास्क सौंपने, और नतीजा लेने का साझा शिष्टाचार, ऐसा समझें।
💡 MCP और A2A को तुलना से याद रखें। मोटे तौर पर MCP = एजेंट को "हाथ" जोड़ना, A2A = एजेंटों को आपस में "जोड़ना"। पहला औज़ार-डेटा कनेक्शन, दूसरा तालमेल का शिष्टाचार। अभी अवधारणा के रूप में पकड़ लें तो काफ़ी है, और ठोस प्रोटोकॉल को अगले अध्यायों में भी छुएँगे। ज़्यादा विस्तार के लिए A2A प्रोटोकॉल क्या है देखें। पिछले अध्याय के MCP और टूल कनेक्शन से मिलाकर पढ़ें तो अंतर साफ़ हो जाता है।
अहम यह है कि प्रोटोकॉल का नाम रटना नहीं, बल्कि "तालमेल के लिए स्पष्ट तयशुदा नियम चाहिए" वाला डिज़ाइन-रवैया। कौन कौन-सा टास्क थामे, किस इनपुट से शुरू हो, क्या लौटाए, और नाकाम हो तो किसे लौटाए — यह नियम पहले तय कर लेना ही, आकार बढ़ने पर भी न टूटने वाले सिस्टम की बुनियाद है।
कॉन्टेक्स्ट और लागत का प्रबंधन
मल्टी-एजेंट का सबसे बड़ा व्यावहारिक जोखिम है कॉन्टेक्स्ट और लागत का फूलना। एजेंट जितने बढ़ें और आपस में जितनी जानकारी थमाएँ, हर एजेंट का ढोया हुआ कॉन्टेक्स्ट उतना मोटा होता है, और LLM कॉल की गिनती व टोकन दोनों जमा होते जाते हैं। छोड़ दें तो धीमा, महँगा और अस्थिर सिस्टम बन जाता है। डिज़ाइन के चरण में ही लगाम थाम लें।
बच्चे को उस टास्क के लिए ज़रूरी जितना ही दें। पूरा इतिहास ज्यों का त्यों मत बहाएँ। बेमतलब कॉन्टेक्स्ट सटीकता भी घटाता है।
लंबे नतीजे को मुख्य बिंदुओं में समेटकर आगे थमाएँ। कच्चे लॉग नहीं, "निष्कर्ष और आधार" थमाने की सोच।
एक साथ चलाए जाने वाले बच्चों की गिनती पर सीमा लगाएँ। बेतहाशा बढ़ाने पर लागत और रेट-लिमिट से टूट जाता है।
भारी तर्क वाले माता-पिता और सरल काम वाले बच्चे में मॉडल का आकार अलग-अलग इस्तेमाल करें। सब कुछ शीर्ष मॉडल पर मत डालें।
ख़ासकर "थमाई जानकारी सीमित करें" बड़े असर वाला डिज़ाइन-निर्णय है। ऑर्केस्ट्रेटर + वर्कर प्रकार में, माता-पिता पूरा खाका रखता है, पर बच्चे को काटा हुआ टास्क और न्यूनतम इनपुट ही थमाता है। बच्चे का ढोया कॉन्टेक्स्ट जितना छोटा रखा जाए, सटीकता उतनी बढ़ती है और लागत घटती है। इसे पिछले अध्यायों में छुई कॉन्टेक्स्ट इंजीनियरिंग की सोच का, कई एजेंटों तक विस्तार समझें।
⚠️ लागत "गिनती × चरण-गिनती" से असर करती है। एक एजेंट बढ़ाएँ, तो उतनी कॉल लूप की गिनती जितनी जमा होती है। गिनती जितनी बढ़े, प्रति-एजेंट फ़िज़ूलख़र्ची पूरे तंत्र में कई गुना फूल जाती है — इस पर ध्यान दें। समानांतर गिनती की सीमा, और हर एजेंट की चरण-सीमा (कब रुकना) शुरू से ही तय कर लें। यह "कितना इस्तेमाल हो रहा है" मापने वाली बात, अगले अध्याय की ऑब्ज़र्वेबिलिटी से जुड़ती है।
अड़चनें और डिज़ाइन से बचाव
मल्टी-एजेंट में कुछ ऐसी ख़ास नाकामियाँ हैं जो अकेले में नहीं होतीं। ये सब चलते वक़्त क़िस्मत के भरोसे नहीं, बल्कि डिज़ाइन से पहले ही रोकना — यही नियम है। 3 प्रतिनिधि और उनका उपाय पकड़ लें।
कई एजेंट एक ही काम दो बार करते हैं, या "किसका प्रभार है" धुँधला होने से कोई नहीं करता।
बचाव: हर एजेंट की ज़िम्मेदारी को बिना ओवरलैप और बिना चूक बाँटें, और सीमा एक वाक्य में कह सकने की हालत में रखें।
A से B, B से A… आपस में काम धकेलते रहते हैं, और कभी ख़त्म नहीं होता / वही आदान-प्रदान दोहराते रहते हैं।
बचाव: समाप्ति की शर्त, और आना-जाना व चरण-गिनती की सीमा ज़रूर रखें। केंद्र (माता-पिता) आख़िरी निर्णय थामे, तो बेकाबू होना मुश्किल।
एक की नाकामी या गलत आउटपुट, ज्यों का त्यों आगे बह जाता है, और पूरे तंत्र को रोक देता है / गलत नतीजा बना देता है।
बचाव: थमाने से पहले आउटपुट की जाँच करें, और नाकामी पर फ़ॉलबैक (दोबारा कोशिश, विकल्प, इंसान तक एस्केलेशन) तय कर रखें।
तीनों में साझा सीख है, "सीमा, समाप्ति-शर्त, जाँच" को कोड लिखने से पहले तय कर लेना। कौन क्या सँभाले (सीमा), कब रुके (समाप्ति-शर्त), और थमाने से पहले क्या पक्का करे (जाँच)। इन 3 बिंदुओं को डिज़ाइन में बुन लें, तो मल्टी-एजेंट की ख़ास मुसीबतों में से ज़्यादातर पहले ही टल जाती हैं।
📊 "दिखे बिना सुधार नहीं होता"। ये नाकामियाँ, कौन एजेंट ने क्या किया, यह बाद में पीछा किया जा सके ऐसी हालत में हो तभी पकड़ में आती हैं। कई एजेंट उलझें, तो अकेले से भी ज़्यादा "कहाँ क्या हुआ" दिखना मुश्किल हो जाता है — इसीलिए अगले अध्याय की मूल्यांकन और ऑब्ज़र्वेबिलिटी, मल्टी-एजेंट में और भी अहम बन जाती है।
- एक में ज़रूरत से ज़्यादा ठूँसें तो सटीकता गिरती है। भूमिका संकरी बाँटे छोटे एजेंटों के तालमेल से हल करें।
- बुनियादी पैटर्न 3 हैं — ऑर्केस्ट्रेटर + वर्कर, पाइपलाइन, भूमिका-बँटवारा। इन्हें नेस्ट किया जा सकता है।
- बाँटना तब जब समानांतरता, विशेषज्ञता, व्यापक खोज चाहिए। सरल हो तो एक ही रहें। पहले "क्या एक ही काफ़ी है" पूछें।
- तालमेल स्पष्ट तयशुदा नियम से करें (A2A = एजेंटों को आपस में जोड़ने का शिष्टाचार)। कॉन्टेक्स्ट और लागत सीमित रखकर सँभालें।
- ख़ास फिसलनें (दोहराव, फेंकाफेंकी, शृंखलाबद्ध नाकामी) को सीमा, समाप्ति-शर्त, जाँच डिज़ाइन में पहले तय करके रोकें।
कई एजेंट चलने लगें, तो अगली ज़रूरत है "क्या सचमुच अच्छे से चल रहा है यह मापना, और हरकत को दृश्यमान बनाना"। अगले अध्याय 5 "मूल्यांकन और ऑब्ज़र्वेबिलिटी" में, एजेंट की गुणवत्ता मापने, और भीतरी हरकत का पीछा कर पाने की हालत बनाने के तरीके की ओर बढ़ते हैं।