Phase 16: Multi-Agent & Swarms

समानांतर / झुंड / नेटवर्क आर्किटेक्चर

पर्यवेक्षक के विपरीतः कोई केंद्रीय निर्णयकर्ता नहीं। एजेंट एक साझा घटना बस पढ़ते हैं, काम को असिनक्रोनस ढंग से लेते हैं, परिणाम वापस लिखते हैं। लैंगग्राफ स्पष्ट रूप से विकेन्द्रीकृत, गतिशील वातावरण के लिए "स्वारम आर्किटेक्चर" का समर्थन करता है। मैट्रिक्स (arXiv:2511.21686) ऑर्केस्ट्रेटर की बोतल की खाई को खत्म करने के लिए वितरित कतारों के माध्यम से पारित क्रमबद्ध संदेशों के रूप में नियंत्रण और डेटा प्रवाह दोनों का प्रतिनिधित्व करता है। समझौता स्पष्ट हैः स्केलेबिलिटी के लिए निर्धारकता और पता लगाने योग्यता। Swarm कई स्वतंत्र उप-समस्याओं के साथ कार्यों को फिट करता है; यह उन कार्यों को फिट नहीं करता है जिन्हें एक ही सुसंगत योजना की आवश्यकता होती है।

Type: Learn + Build

Languages: Python (stdlib, threading, queue)

Prerequisites: Phase 16 · 05 (Supervisor Pattern), Phase 16 · 04 (Primitive Model)

Time: ~75 minutes

समस्या

एक प्रबंधक कुछ कर्मचारियों तक ही चलता है. सैकड़ों के बारे में क्या? स्वयं प्रबंधक बोतल की गर्दन बन जाता हैः एक एजेंट के माध्यम से कौन क्या करता है, इस बारे में हर निर्णय। एक धीमी योजना चरण पूरे सिस्टम को अवरुद्ध करता है।

एक समूह वास्तुकला डिजाइन को उलट देती है। एक केंद्रीय योजनाकार के बजाय काम को भेजने वाले काम करने वाले श्रमिक साझा कतार से काम चुनते हैं। "संयोजन" घटना बस अर्थशास्त्र में बेक किया जाता है। कोई ऑर्केस्ट्रेटर नहीं; सिस्टम तब तक स्केल करता है जब तक कतार नहीं करता है।

अवधारणा

आकार

                ┌──── shared queue ────┐
                │                      │
       ┌────────┼────────┐  ◄──────┬───┘
       ▼        ▼        ▼         │
     Worker  Worker  Worker   Worker
      A       B       C        D
       │        │        │         │
       └────────┴────────┴─────────┘
                 │
                 ▼
            results pool

कोई ऑर्केस्ट्रेटर नहीं। प्रत्येक कार्यकर्ता दोहराता हैः एक कार्य खींचें, प्रक्रिया करें, परिणाम लिखें (और वैकल्पिक रूप से अनुवर्ती अनुवर्ती) ।

जब झुंड मिल जाता है

  • Many independent tasks.स्क्रैपिंग, ट्रांसफॉर्मिंग, वर्गीकरण। कार्य एक दूसरे पर निर्भर नहीं करते।
  • Variable-duration work.यदि कुछ कार्यों में 100ms और अन्य में 10ms लगते हैं, तो एक झुंड स्वचालित रूप से लोड संतुलन करता है तेजी से श्रमिक अगले कार्यों को खींचते हैं। एक पर्यवेक्षक को अवधि की भविष्यवाणी करनी होगी।
  • Throughput over determinism.आप पूर्ण पूर्णता समय की परवाह करते हैं, सख्त आदेश नहीं।

जब झुंड विफल हो जाता है

  • Ordered workflows.यदि चरण 3 को चरण 2 के आउटपुट की आवश्यकता होती है, तो चरण 2 पूरा होने से पहले एक झुंड चरण 3 में फायरिंग का जोखिम उठाते हैं।
  • Global-plan tasks.जटिल शोध प्रश्नों को एक योजनाकार से लाभ मिलता है। शोधकर्ताओं का एक झुंड स्वतंत्र तथ्यों का उत्पादन करता है, एक सुसंगत रिपोर्ट नहीं।
  • Debugging.कोई केंद्रीय लॉग और असिनक्रोनस काम के बिना, बग को पुनः उत्पन्न करना महंगा है।

मैट्रिक्स (arXiv:2511.21686)

मैट्रिक्स 2025 पेपर है जो स्वैम को अपने प्राकृतिक निष्कर्ष तक ले जाता हैः नियंत्रण प्रवाह और डेटा प्रवाह दोनों वितरित कतारों पर क्रमबद्ध संदेश हैं। कोई केंद्रीय समन्वयक नहीं है। त्रुटि सहिष्णुता संदेश की स्थायित्व से आती है। स्केलेबिलिटी संदेश ब्रोकर की समस्या है, सिस्टम की नहीं।

योगदानः एक प्रोग्रामिंग मॉडल जहां मल्टी-एजेंट समन्वय "इस एजेंट को किस संदेश विषय पर सदस्यता मिलती है? " बजाय "किसी एजेंट को पर्यवेक्षक अगला चुनता है? " यह प्रणाली को एक पब / उप घटना जाल की तरह दिखता है।

ग्राफ फ्रेमवर्क में झुंड

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

विफलता मोडः भूख और हॉटस्पॉटिंग

यदि सभी श्रमिक सबसे तेज़ उपलब्ध कार्य को करते हैं, तो लंबे समय तक चलने वाले कार्य तब तक कभी नहीं चुने जाते जब तक कि वे एकमात्र नहीं रह जाते। क्लासिक कतार में भूख लगना।

कम करनाः

  • स्पष्ट उम्र बढ़ने के साथ प्राथमिकता कतारें (प्रतीक्षा समय के साथ प्राथमिकता बढ़ाएं)
  • श्रमिक विशेषज्ञताः कुछ श्रमिक केवल "लंबे" कार्य करते हैं।
  • बैक-प्रेशरः कतार में कितने तेज़ कार्य प्रवेश करते हैं, उसे सीमित करें।

सामग्री आधारित रूटिंग लिंक

सामग्री आधारित रूटिंग के साथ स्वाभाविक रूप से झुंड जोड़ें (पाठ 22) सामान्य कतार के बजाय, संदेश प्रकार के लिए एक कतार है। विशेषज्ञ कर्मचारी केवल उनके प्रकार को सदस्यता लेते हैं। यह संदेश-बस वास्तुकला का आधार है जो हजारों एजेंटों तक स्केल करता है।

इसे बनाओ

code/main.pyएक साझा से खींचने 4 श्रमिक धागे का एक झुंड लागू करता है queue.Queue. कार्यों की अवधि भिन्न होती है (कुछ तेज, कुछ धीमी) । डेमो विपरीतः

  • Sequential baseline:एक कार्यकर्ता सभी कार्यों को क्रमशः संसाधित करता है।
  • Fixed assignment:प्रत्येक कार्य को एक विशिष्ट कर्मचारी को पूर्व-निर्धारित किया गया है (पर्यवेक्षक शैली) ।
  • Swarm:श्रमिकों को साझा कतार से खींचना।

भारी वजन स्वचालित रूप से लोड होता है; जब उन्हें सौंपा गया कार्य धीमा होता है तो निश्चित कार्य करने वाले तेज मजदूर निष्क्रिय रहते हैं।

दौड़ें:

python3 code/main.py

आउटपुट प्रति कार्यकर्ता कार्य गणना (समुदाय असमान रूप से लेकिन इष्टतम रूप से वितरित) और दीवार घड़ी समय दिखाता है।

इसका प्रयोग करें

outputs/skill-swarm-fit.mdयह मूल्यांकन करता है कि क्या किसी कार्य में swarm बनाम supervisor का उपयोग करना चाहिए। इनपुटः कार्य की स्वतंत्रता, अवधि भिन्नता, आदेश आवश्यकताएं, डिबग करने की आवश्यकताएं।

इसे भेजें

चेकलिस्टः

  • Priority queue with aging.लंबी-कार्य की भूख को रोकें।
  • Worker idempotency.यदि एक कर्मचारी दौड़ के बीच दुर्घटनाग्रस्त हो जाता है तो एक कार्य को एक से अधिक बार किया जा सकता है। श्रमिकों को असमर्थ होना चाहिए।
  • Durable queue.उत्पादन के लिए काफका, रेडिस धाराओं, या डेटाबेस द्वारा समर्थित कतार का उपयोग करें। queue.Queueकेवल स्मृति में है।
  • Observability per task.प्रत्येक कार्य में एक पहचान पत्र होता है; प्रत्येक कार्यकर्ता इसके साथ शुरू/अंत करता है।
  • Back-pressure.यदि श्रमिकों की कतार से अधिक तेजी से बढ़ता है, तो उत्पादक को धीमा कर दें।

व्यायाम

  1. दौड़ेंcode/main.py. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
  2. प्राथमिकता कतार संस्करण जोड़ें (उपयोग queue.PriorityQueue) कार्य "महत्व" फ़ील्ड के अनुसार प्राथमिकताएँ असाइन करें। यह अवलोकन करें कि क्या कम प्राथमिकता वाले कार्य लगातार लोड होने पर कभी भी भूखे रहते हैं।
  3. एक हॉटस्पॉट डिटेक्टर को लागू करेंः जब कोई भी कार्यकर्ता सबसे धीमी श्रमिक की तुलना में 3 गुना अधिक कार्य करता है तो लॉग करें। यह कार्य-समय वितरण के बारे में क्या बताता है?
  4. मैट्रिक्स पेपर (arXiv:2511.21686) सार और धारा 3 पढ़ें। मैट्रिक्स स्वीकार करता है (स्केलेबिलिटी लाभ) और एक को छोड़ देता है (ट्रेसबिलिटी, निर्धारवाद) एक विशिष्ट व्यापारिक अंतर की पहचान करें।
  5. एक queue.Queueकार्य प्रकार, उपयोगिता भार) के ट्यूपल के साथ, श्रमिक केवल विशिष्ट प्रकारों को सदस्यता देते हैं। कार्य विषम होने पर कौन से रूटिंग नियम समझ में आते हैं?

प्रमुख शर्तें

TermWhat people sayWhat it actually means
Swarm architecture"Decentralized agents"Workers pull from shared queue; no central orchestrator.
Event bus"Agents subscribe to topics"Message broker that routes tasks to workers by type or content.
Starvation"Task never runs"Low-priority task never gets picked because higher-priority work arrives continuously.
Hot-spotting"One worker drowns"Load imbalance where one worker gets most tasks.
Back-pressure"Slow down the producer"Mechanism that signals upstream to stop producing when the queue fills up.
Idempotent worker"Safe to re-run"A task processed twice produces the same result. Required because workers may crash mid-run.
Durable queue"Survives crashes"Queue backed by disk or replicated storage; tasks are not lost when a worker crashes.
Matrix framework"Full message-passing swarm"Both data and control flow are serialized messages on distributed queues.

आगे पढ़ना

This free lesson is part of the AI Engineering from Scratch curriculum. Read the full explanation, run the lesson code, and verify the result in the interactive reader or from the repository source.

Browse the complete course catalog or open this lesson on GitHub.