AI एजेंट्स बनानामध्यमपाठ 2026 मिनट का पाठ

कई एजेंट्स को एक साथ चलाना (Orchestration)

एक एजेंट काम के कुछ हिस्से दूसरे एजेंट्स को सौंप सकता है। orchestrator-worker पैटर्न और हैंडऑफ़ के बारे में जानें, और यह भी कि कब ज़्यादा एजेंट्स मदद करते हैं और कब वे सिर्फ़ ख़र्च और उलझन बढ़ाते हैं।

पाठ वीडियो में

60 सेकंड में

कई एजेंट्स को एक साथ चलाना (Orchestration)

एक एजेंट काम के कुछ हिस्से दूसरे एजेंट्स को सौंप सकता है। orchestrator-worker पैटर्न और हैंडऑफ़ के बारे में जानें, और यह भी कि कब ज़्यादा एजेंट्स मदद करते हैं और कब वे सिर्फ़…

1/4
आसान शब्दों में
क्रिकेट की टीम में, कप्तान हर ओवर खुद नहीं फेंकता। वह तय करता है कि कौन गेंदबाज़ी करेगा, कौन कहाँ फ़ील्डिंग करेगा, और मैच के हिसाब से योजनाएँ बदलता है। लेकिन कैरम के खेल के लिए ग्यारह लोगों की टीम होना बेवकूफ़ी होगी। ज़्यादा खिलाड़ी तभी काम आते हैं जब काम काफ़ी बड़ा हो।
जब एजेंट्स टीमों में काम करते हैं में बताया गया था कि लोग एजेंट्स के बीच काम का बँटवारा क्यों करते हैं। यहाँ हम देखेंगे कि इसे बनाते कैसे हैं। एक "मल्टी-एजेंट सिस्टम" आमतौर पर सिर्फ़ कई मॉडल कॉल्स होते हैं, जिनमें से हर एक के पास अपने निर्देश, टूल्स और context होता है, जो आपके कोड से आपस में जुड़े होते हैं।

दो आम पैटर्न

पैटर्नयह कैसे काम करता हैकिसके लिए अच्छा है
Orchestrator-workerएक मुख्य (lead) एजेंट काम को बाँटता है, उसके हिस्सों को वर्कर एजेंट्स के पास भेजता है (अक्सर एक साथ / पैरेलल में), और फिर उनके नतीजों को जोड़ता है।कई स्रोतों से रिसर्च करना, कई फ़ाइलों की समीक्षा करना, ऐसा काम जो स्वतंत्र हिस्सों में बँट सकता हो।
Handoff (रूटिंग)एक एजेंट पूरी बातचीत किसी ज़्यादा उपयुक्त एजेंट को सौंप देता है, जैसे कोई फ़ोन कॉल सही विभाग को ट्रांसफ़र कर दिया जाए।कस्टमर सपोर्ट जहाँ बिलिंग, डिलीवरी और टेक्निकल समस्याओं के लिए अलग-अलग एजेंट्स हों।

कोड में Orchestrator-worker

वर्कर्स को एक छोटा, केंद्रित context मिलता है: सिर्फ़ उनका छोटा काम (सब-टास्क), न कि पूरी पुरानी बातचीत। वे छोटे नतीजे वापस भेजते हैं। ऑर्केस्ट्रेटर सिर्फ़ उन सारांशों को देखता है, जिससे उसका अपना context साफ़-सुथरा रहता है।
orchestrator.py: split, run workers in parallel, combinepython
from concurrent.futures import ThreadPoolExecutor

def call_model(prompt: str) -> str:
    # Placeholder. Plug in your provider here.
    return "[model answer to: " + prompt[:50] + "...]"

def worker(sub_task: str) -> str:
    # Each worker could run its own agent loop with its own narrow tools.
    return call_model("You are a research worker. Do only this, and reply "
                      "in at most 5 bullet points with sources: " + sub_task)

def orchestrate(goal: str) -> str:
    sub_tasks = [   # in real code, ask the model for this list as JSON
        "Price and validity of plan A",
        "Price and validity of plan B",
        "Price and validity of plan C",
    ]
    with ThreadPoolExecutor(max_workers=3) as pool:
        results = list(pool.map(worker, sub_tasks))
    notes = "\n".join(t + ": " + r for t, r in zip(sub_tasks, results))
    return call_model("Goal: " + goal + "\nWorker notes:\n" + notes +
                      "\nCombine into one short comparison. Say if anything is missing.")

print(orchestrate("Compare three mobile plans for a student"))

Handoffs

हैंडऑफ़ को अक्सर एक टूल के रूप में बनाया जाता है: transfer_to_billing(reason)। जब मॉडल इसे कॉल करता है, तो आपका कोड बिलिंग एजेंट के निर्देशों और टूल्स पर स्विच कर जाता है, और मामले का एक छोटा सारांश भेज देता है। ध्यान से तय करें कि हैंडऑफ़ के साथ क्या भेजा जाए: पूरी बातचीत, एक सारांश, या सिर्फ़ वे तथ्य जिनकी अगले एजेंट को ज़रूरत है।

कब ज़्यादा एजेंट्स मदद करते हैं, और कब नुकसान पहुँचाते हैं

ज़्यादा एजेंट्स आमतौर पर तब नुकसान पहुँचाते हैं जब
  • काम छोटा हो या पूरी तरह से एक-के-बाद-एक (step-by-step) होने वाला हो
  • हर कदम अपने पिछले कदम पर निर्भर करता हो
  • एजेंट्स को आपस में बहुत सारी बारीक जानकारियाँ शेयर करनी पड़ती हों
  • आप अभी तक एक अकेले एजेंट से भी भरोसेमंद तरीके से काम नहीं करवा पा रहे हों
ज़्यादा एजेंट्स आमतौर पर तब मदद करते हैं जब
  • काम अलग-अलग स्वतंत्र हिस्सों में बँट सकता हो
  • समय बचाने के लिए कई हिस्से एक साथ (पैरेलल में) चलाए जा सकते हों
  • अलग-अलग हिस्सों के लिए अलग-अलग टूल्स या अनुमतियों (permissions) की ज़रूरत हो
  • एक अकेले एजेंट के लिए सारा context बहुत ज़्यादा भर जाएगा
मल्टी-एजेंट सिस्टम्स में आमतौर पर कुल मिलाकर ज़्यादा tokens ख़र्च होते हैं, क्योंकि हर एजेंट को अपने निर्देश और context चाहिए होते हैं, और नतीजों का फिर से सारांश बनाया जाता है। उनमें गलतियाँ ढूँढना (debug करना) भी मुश्किल होता है: एक गलती किसी एक वर्कर से शुरू हो सकती है और अंतिम जवाब में दिख सकती है। हमेशा एक एजेंट से शुरुआत करें, और काम को तभी बाँटें जब आप साफ़ बता सकें कि बाँटने से कौन-सी समस्या हल हो रही है।

डिज़ाइन के नियम

  • हर वर्कर को एक साफ़ सब-टास्क, काम पूरा हुआ या नहीं जाँचने का तरीका (done-test), और आउटपुट का एक फ़ॉर्मैट दें।
  • हर वर्कर को सिर्फ़ वही टूल्स दें जिनकी उसके सब-टास्क को ज़रूरत है। रिसर्च करने वाले वर्कर को ईमेल टूल की ज़रूरत नहीं होती।
  • वर्कर्स की संख्या और उनकी गहराई (depth) सीमित रखें: वर्कर्स को बिना किसी सीमा के आगे नए वर्कर्स नहीं बनाने चाहिए।
  • हर एजेंट की कॉल्स को एक ही रन आईडी (run id) के तहत ट्रैक (trace) करें, ताकि आप एजेंट्स के बीच किसी समस्या की जड़ तक पहुँच सकें।
  • नतीजों को जोड़ने से पहले ऑर्केस्ट्रेटर से उनकी जाँच करवाएं, उदाहरण के लिए छूटी हुई बातों या विरोधाभासों के लिए।
सावधान रहें
वर्कर का आउटपुट ऑर्केस्ट्रेटर के लिए एक ऐसा इनपुट है जिस पर आँख मूँदकर भरोसा नहीं किया जा सकता। अगर किसी वर्कर ने कोई दूषित (poisoned) वेब पेज पढ़ा है, तो उसका सारांश हमले को आगे बढ़ा सकता है। चीज़ों में बदलाव करने वाले (write) टूल्स उसी एजेंट के पास रखें जो यूज़र की मंज़ूरी के सबसे करीब हो, उन वर्कर्स के पास नहीं जो बाहर का कंटेंट पढ़ते हैं। देखें एजेंट्स के बीच फैलने वाले हमले।
इसे आज़माएँ। किसी ऐसे काम के बारे में सोचें जो आप किसी एजेंट को दे सकते हैं। क्या इसे 3 स्वतंत्र हिस्सों में बाँटा जा सकता है? अगर हर हिस्से को पिछले हिस्से के नतीजे की ज़रूरत है, तो शायद एक अकेला एजेंट ही बेहतर रहेगा।

और देखें और पढ़ें

लैब

दो स्तरों वाले एजेंट सिस्टम का एक लिखित डिज़ाइन, साथ में यह साफ़ तर्क कि इसे एक से ज़्यादा एजेंट्स की ज़रूरत क्यों है।

~30 min

समस्या

एक अख़बार एक ऐसा सिस्टम चाहता है जो हर सुबह 10 क्षेत्रीय समाचार वेबसाइटों को पढ़े और आसान भाषा में खेती से जुड़ी ख़बरों का एक पन्ने का सारांश तैयार करे।

  1. तय करें: एक अकेला एजेंट, या ऑर्केस्ट्रेटर के साथ वर्कर्स? तीन वाक्यों में समझाएं कि क्यों।
  2. अगर आप वर्कर्स चुनते हैं: तो हर वर्कर का सब-टास्क, टूल्स और आउटपुट फ़ॉर्मैट लिखें। अगर नहीं चुनते, तो अकेले एजेंट के कदम लिखें।
  3. यह नियम लिखें कि जब कोई वर्कर फ़ेल हो जाए या कुछ भी न भेजे, तब ऑर्केस्ट्रेटर क्या करेगा।
  4. यह तय करें कि कौन-सा एजेंट पब्लिश कर सकता है (यदि कोई हो), और उसे किस मंज़ूरी की ज़रूरत होगी।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1दो वर्कर्स ऐसे तथ्य वापस भेजते हैं जो एक-दूसरे से उलट हैं। ऑर्केस्ट्रेटर को क्या करना चाहिए?दिखाएं

उसे चुपचाप किसी एक को नहीं चुन लेना चाहिए। वह हर वर्कर द्वारा दिए गए स्रोतों की जाँच कर सकता है, किसी वर्कर से दोबारा जाँच करने को कह सकता है, या दोनों पक्षों को उनके स्रोतों के साथ पेश कर सकता है और किसी मानव संपादक के देखने के लिए इस टकराव को मार्क कर सकता है। टकरावों को छिपाने से सारांश सही न होते हुए भी आत्मविश्वास से भरा दिखता है।

Q2किसी दूसरे एजेंट के काम की जाँच करने वाला "रिव्यूअर" एजेंट जोड़ने के बाद भी गलतियाँ क्यों छूट सकती हैं?दिखाएं

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

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

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

अपने आप नहीं। यह एक साथ ज़्यादा दायरा कवर कर सकता है और हर context को केंद्रित रख सकता है, जिससे बड़े कामों के नतीजे बेहतर हो सकते हैं। लेकिन यह ख़र्च भी बढ़ाता है, नतीजों को जोड़ने में समय लेता है, और गलतियों की संभावना भी बढ़ा देता है। इसे अपने कामों पर परख कर देखें।

क्या सभी एजेंट्स को एक ही मॉडल का इस्तेमाल करना चाहिए?

ऐसा ज़रूरी नहीं है। कुछ टीमें ऑर्केस्ट्रेटर के लिए ज़्यादा शक्तिशाली मॉडल और सीधे-सादे वर्कर्स के लिए सस्ते मॉडल्स का इस्तेमाल करती हैं। टेस्ट करके देखें कि क्या सस्ते वर्कर्स भी काम के लिए काफ़ी अच्छे हैं।

एजेंट्स आपस में जानकारी कैसे शेयर करते हैं?

आपके कोड के ज़रिए: किसी वर्कर को दिए गए arguments, वापस मिले नतीजे, या कोई साझा जगह जैसे कि कोई नोट्स फ़ाइल। शेयर किए गए डेटा को व्यवस्थित और छोटा रखें, और यह रिकॉर्ड रखें कि कौन-सी बात किस एजेंट ने लिखी है।

एजेंट-टू-एजेंट प्रोटोकॉल के बारे में क्या?

अलग-अलग सिस्टम के एजेंट्स के आपस में बात करने के लिए प्रोटोकॉल मौजूद हैं। वे अपने साथ भरोसे से जुड़े सवाल लाते हैं: दूसरा एजेंट कौन है, और वह क्या मांग सकता है? देखें एजेंट-टू-एजेंट प्रोटोकॉल और भरोसा।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें