Phase 16: Multi-Agent & Swarms

उत्पादन स्केलिंग कतारें, चेकपोइंट, स्थायित्व

कई एजेंटों के सिस्टम को हजारों समवर्ती रन के लिए स्केलिंग की आवश्यकता होती है durable execution काम की कतारें और चेकपॉइंट्स, ताकि कोई भी कार्यकर्ता किसी भी दुर्घटना के बाद किसी भी रन को फिर से शुरू कर सके, बशर्ते कि लीज हैंडलिंग, अक्षम दुष्प्रभाव और निर्धारात्मक रीप्ले की स्थिति में हों। लैंगग्राफ का रनटाइम संदर्भ उदाहरण हैः यह प्रत्येक सुपर-स्टेप के बाद एक चेकपॉइंट लिखता है जो किthread_id(डिफ़ॉल्ट रूप से पोस्टग्रेड); श्रमिक दुर्घटनाओं के बाद एक पट्टे का अनुबंध जारी किया जाता है और एक अन्य श्रमिक फिर से शुरू होता है। एजेंट मानव input के लिए अनिश्चित काल तक सो सकते हैं। MegaAgent(arXiv:2408.09955) ने प्रति एजेंट तीन राज्यों (Idle / Processing / Response) और दो-स्तरीय समन्वय (ग्रुप के भीतर चैट + समूह के बीच व्यवस्थापक चैट) के साथ उत्पादक-उपभोक्ता कतार चलाया। Fiber/asyncLLM स्ट्रीमिंग के लिए धागे प्रति काम से पीटा जाता हैः धागे टोकन के लिए 99% समय इंतजार करते हुए निष्क्रिय रहते हैं, फाइबर सहकारी रूप से I/O पर उत्पन्न होते हैं। काउंटरपॉइंटः Ashpreet Bedi का "स्केलिंग एजेंटिक सॉफ्टवेयर" तर्क देता हैFastAPI + Postgres + nothing elseजब तक लोड अन्यथा साबित नहीं होता है सरल वास्तुकला उम्मीद से आगे जाती है। यह सबक एक टिकाऊ चेकपॉइंट लॉग बनाता है, राज्य संक्रमणों के साथ प्रति एजेंट कार्य कतार, एक असिनक बनाम थ्रेड डेमो, और व्यावहारिक "सुरुवात सरल" नियम को लैंड करता है।

Type: Learn + Build

Languages: Python (stdlib, asyncio, sqlite3), TypeScript

Prerequisites: Phase 16 · 09 (Parallel Swarm Networks), Phase 16 · 13 (Shared Memory)

Time: ~75 minutes

समस्या

एक प्रोटोटाइप मल्टी-एजेंट सिस्टम एक लैपटॉप पर काम करता है जिसमें तीन एजेंट एक इन-मेमोरी इवेंट लूप में होते हैं। आप उत्पादन में जाते हैंः

  • एजेंट कभी-कभी घंटों तक दौड़ते हैं (लंबे शोध, मानव-इन-द-लुप प्रतीक्षाएं) ।
  • कामगार प्रक्रियाओं दुर्घटनाग्रस्त. पुनरारंभ राज्य खो देता है.
  • पीक लोड 10x औसत है; आप क्षैतिज स्केलिंग की जरूरत है।
  • उपयोगकर्ता प्रति एजेंट रन भुगतान करते हैं; आप चार्ज करने के लिए एक बार के लिए एक ही अर्थशास्त्र की जरूरत है।

इन-मेमोरी इवेंट लूप इन सभी का कोई काम नहीं करता है। आपको नीचे एक टिकाऊ निष्पादन परत की आवश्यकता है। 2026 के लिए वैकल्पिक विकल्प हैंः

  1. चेक-पॉइंट (टाइमरल, लैंगग्राफ रनटाइम) के साथ एक वर्कफ़्लो इंजन।
  2. एक राज्य स्टोर के साथ एक संदेश कतार (Postgres + SQS/RabbitMQ) ।
  3. अभिनेता-मॉडल फ्रेमवर्क (मेगाएजेंट का उत्पादक-उपभोक्ता प्रति एजेंट)
  4. हाथ से रोल किया गया FastAPI + Postgres (बेदी का तर्क)

यह सबक प्रत्येक का एक लघु चित्र बनाता है।

अवधारणा

टिकाऊ निष्पादन, पैटर्न

एक टिकाऊ-कार्यकारी इंजन प्रत्येक "चरण" (लंगग्राफ की भाषा में सुपर-चरण) के बाद पूर्ण कार्यक्रम स्थिति बनाए रखता है। दुर्घटना परः

code
worker crashes mid-step
  -> lease timeout
  -> another worker picks up the thread_id
  -> resumes from last checkpoint
  -> no duplicate side effects

इसके काम करने के लिए आवश्यकताएंः

  • Serializable state.सभी एजेंट राज्य बनाए रखा जाना चाहिए. लाइव डेटाबेस कनेक्शन के साथ समारोह बंद नहीं रहते हैं.
  • Deterministic resume.एक ही स्थिति और एक ही इनपुट को देखते हुए, एजेंट एक ही क्रियाओं का उत्पादन करता है (या एलएलएम कॉल के लिए बाहरी निर्धारक ओरेकल को स्थगित करता है) ।
  • Idempotent side effects.बाहरी कॉल (आजार कॉल, भुगतान) निष्क्रिय होना चाहिए या एक डिडप्लिकेशन कुंजी का उपयोग करना चाहिए।

लैंगग्राफ प्रत्येक सुपर-चरण के बाद एक चेकपॉइंट लिखता है; समयबद्ध प्रत्येक गतिविधि के बाद लिखता है; रीसेट घटना-स्रोत पत्रिकाओं का उपयोग करता है। तीनों एक ही पैटर्न लागू करते हैं।

एक चेक-पॉइंट-प्रति-चरण रनटाइम

LangGraph का रनटाइम कामकाजी उदाहरण हैः प्रत्येक एजेंट के पास एक thread_id; राज्य एक टाइप किया गया डिक्ट है; प्रत्येक सुपर-चरण चेकपोइंट तालिका में एक पंक्ति लिखता है। रिज्यूमे में, रनटाइम को अंतिम चेकपोइंट से फिर से खेला जाता है, खरोंच से नहीं। एजेंट कर सकते हैं interrupt()मानव प्रविष्टि का इंतजार करते हुए; रनटाइम बरकरार रहता है और श्रमिक को मुक्त करता है। जब प्रविष्टि आती है, तो कोई भी श्रमिक फिर से शुरू कर सकता है।

यह अप्रैल 2026 में उत्पादन का संदर्भ डिजाइन है।

मेगाएजेंट की प्रति एजेंट कतार

arXiv:2408.09955 एक पैमाने प्रयोग का वर्णन करता हैः एक क्लस्टर में हजारों समवर्ती एजेंट। वास्तुकलाः

code
agent i:
  state ∈ {Idle, Processing, Response}
  in_queue   <- messages addressed to agent i
  out_queue  -> replies + side effects

coordinators:
  intra-group chat  (agents in the same group)
  inter-group admin chat  (high-level routing)

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

कार्य के प्रति धागा बनाम समक्रमण

LLM कॉल I / O-bound हैं। अगले टोकन की प्रतीक्षा करने वाला एक थ्रेड 99% समय में निष्क्रिय होता है। थ्रेड की लागत ~ 1MB रैम प्रति है; 10,000 समवर्ती कॉल पर, जो केवल स्टैक के लिए 10GB है।

फाइबर (पाइटन asyncio, जाओ गोरूटीन, रुस्ट tokio) सहकारी रूप से I/O पर परिणाम देता है। वही 10,000 कॉल प्रक्रिया में आराम से फिट बैठते हैं। LLM-एजेंट पैमाने पर, async एक अनुकूलन नहीं है यह वास्तुकला है।

अपवादः सीपीयू-बाउंड पोस्ट प्रोसेसिंग (इम्बेडिंग, टोकनराइज़र ट्रिक्स) अभी भी धागे या प्रक्रियाओं की आवश्यकता है। अपने आई / ओ परत को अपने सीपीयू परत से अलग करें।

बेदी का प्रतिबिंब

"स्केलिंग एजेंटिक सॉफ्टवेयर" (अशप्रीत बेदी, 2026) का तर्क है कि अधिकांश टीमों ने लोड को मापने से पहले ओवर-इंजीनियर किया है। व्यावहारिक डिफ़ॉल्टः

  • फास्टएपीआई + पोस्टग्रेस।
  • प्रत्येक एजेंट रन एक पंक्ति है; स्थिति अनुकूल समवर्तीता के साथ अद्यतन किया गया है।
  • के माध्यम से पृष्ठभूमि नौकरियांpg_notifyया एक साधारण सेलेरी कार्यकर्ता.
  • आवेदन कोड में नीति पुनः प्रयास करें।

प्रबंधनीय कार्यों पर ~ 100 समवर्ती एजेंट-रन से कम लोड के लिए, यह अक्सर आपको बस इतना ही चाहिए। जब आप इसे मापने में विफल होते हैं तो अपग्रेड करें।

नियमः जब आप एक ठोस समस्या को देखते हैं तो स्थायी निष्पादन ढांचे को अपनाएं जिसे सरल वास्तुकला हल नहीं कर सकती है। समय से पहले अपनाएं वे समारोहों पर समय बर्बाद करते हैं जो फल नहीं देते हैं।

एक बार के लिए सही अर्थशास्त्र

भुगतान एजेंट रन के लिए, आपको "एक बार प्रभावी" (कम से कम एक बार डिलीवरी + अक्षम उपभोक्ता) की आवश्यकता होती है। इंजीनियरिंग चालः

  • Dedup key per run.इसे हर साइड इफेक्ट कॉल में शामिल करें।
  • Outbox pattern.साइड इफेक्ट्स पहले एक तालिका में लिखें, फिर एक अलग प्रक्रिया उन्हें निष्पादित करती है. दोनों चरणों idempotent.
  • Compensating transactions.जब कोई दुष्प्रभाव सफल हो लेकिन उसका ट्रैकिंग लेखन विफल हो जाए, तो एक क्षतिपूर्ति की योजना बनाएं।

ये डेटाबेस इंजीनियरिंग पैटर्न हैं, एलएलएम-विशिष्ट नहीं। एलएलएम कर केवल यह है कि एलएलएम कॉल धीमी होती हैं; बाकी सब मानक वितरित प्रणाली हैं।

रेनबॉक्स तैनाती

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

यह लंबे समय तक चलने वाली राज्य प्रणाली के लिए मानक है; 2026 अनुकूलन यह है कि एजेंट घंटों तक रह सकते हैं, इसलिए तैनाती चक्रों को समायोजित करना चाहिए।

कैनोनिक उत्पादन चेकलिस्ट

  • टिकाऊ स्थिति (चेकपॉइंट, स्नैपशॉट, या आउटबॉक्स + प्लेएबल लॉग) ।
  • अशक्त दुष्प्रभाव।
  • LLM कॉल के लिए असिनक्रोनस I/O परत।
  • कम से कम एक बार डिडप के साथ डिलीवरी।
  • राज्य भर में कार्यभार के लिए रेनबॉक्स/कैनरी तैनाती।
  • अवलोकनशीलताः प्रति एजेंट निशान, सुपर-चरण लेखा परीक्षा, पुनः परीक्षण काउंटर।

इसे बनाओ

code/main.pyकार्य करता हैः

  • CheckpointStore थ्रेड-आईडी कुंजी के साथ SQLite समर्थित चेकपॉइंट लॉग। प्रत्येक सुपर-चरण एक पंक्ति जोड़ता है।
  • run_with_checkpoint(agent, thread_id) मध्य-चलन में दुर्घटना का अनुकरण करता है; दूसरा कार्यकर्ता अंतिम चेकपोस्ट से फिर से काम करता है।
  • AgentQueue प्रति एजेंट एक छोटी कार्य कतार के साथ निष्क्रिय / प्रसंस्करण / प्रतिक्रिया राज्य मशीन।
  • demo_async_vs_threads() असिनसियो और थ्रेड के माध्यम से 500 समवर्ती सिमुलेटेड "एलएलएम कॉल" चलाता है; दीवार घड़ी और पीक मेमोरी (अंदाजे) रिपोर्ट करता है।

दौड़ें:

code
python3 code/main.py
npx tsx code/main.ts

अपेक्षित आउटपुटः चेकपॉइंट रिज़्यूमे सिमुलेटेड क्रैश के बाद सफल होता है; असिनक्रॉनिक संस्करण < 1s में 500 समवर्ती कॉल को संभालता है; थ्रेड संस्करण में कई सेकंड लगते हैं और प्रति समवर्ती इकाई में परिमाण के अधिक आदेशों का उपयोग करता है।

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

outputs/skill-scaling-advisor.mdटिकाऊ निष्पादन विकल्प पर सलाह देता हैः फास्टएपीआई + पोस्टग्रेस, लैंगग्राफ रनटाइम, टेम्पोरल, या कस्टम। भार, राज्य-रक्षण आवश्यकताओं और तैनाती आवृत्ति द्वारा मापा जाता है।

इसे भेजें

कैनोनिक उत्पादन कठोरताः

  • Start simple (Bedi's rule).फास्टएपीआई + पोस्टग्रेस जब तक आप इसे नापने में विफल नहीं होते।
  • Instrument everything before optimizing.प्रति रन विलंबता हिस्टोग्राम, प्रति चरण समय, पुनः प्रयास गिनती, विफलता वर्गीकरण।
  • Outbox pattern for side effects.विशेष रूप से भुगतान और बाहरी एपीआई कॉल।
  • Rainbow deploys.तैनाती के दौरान उड़ान एजेंटों को कभी नहीं मारना।
  • Adopt durable-execution engines (Temporal / LangGraph / Restate) whenआप विशिष्ट समस्याओं से गुजरते हैंः घंटों का मानव-इन-द-लुप प्रतीक्षा, अंतर-क्षेत्र समन्वय, जटिल पुनः प्रयास/वक्षय नीति।
  • Async for the I/O layer.केवल सीपीयू-बाउंड पोस्ट प्रोसेसिंग के लिए थ्रेड।

व्यायाम

  1. दौड़ेंcode/main.py. चेकपॉइंट रिज्यूमे काम करता है की पुष्टि; async बनाम धागे समवर्ती अंतर मापें.
  2. एक outboxतालिकाः प्रत्येक उपकरण कॉल पहले आउटबॉक्स में लिखता है, फिर एक अलग goroutine / कार्य निष्पादित करता है। उपकरण कॉल को दो बार चलाकर निष्पादित करें।
  3. एक का अनुकरण करेंrainbow deploy: दो समवर्ती रनटाइम संस्करण; प्रत्येक में नए थ्रेड_आईडी का आधा मार्ग; पुष्टि करें कि पुराने संस्करण पर उड़ान में थ्रेड नहीं बाधित हैं।
  4. LangGraph के रनटाइम डॉक्यूमेंट (नीचे लिंक किया गया) को पढ़ें। पहचानें कि रनटाइम की कौन सी सुविधाओं को हाथ से रोल्ड किए गए FastAPI + Postgres संस्करण में दोहराया जाने में सबसे अधिक समय लगेगा। क्या यह अपनाए जाने का एक कारण है, या आप इसे स्थगित कर सकते हैं?
  5. मेगाएजेंट (arXiv:2408.09955) पढ़ें धारा 3. दो-स्तरीय समन्वय (ग्रुप के भीतर + समूह के बीच व्यवस्थापक चैट) स्पष्ट है। स्केच करें कि आप इसे दो कतार परिवारों के साथ संदेश कतार में कैसे मानचित्रित करेंगे।

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

TermWhat people sayWhat it actually means
Durable execution"Persist the program state"Engine writes state after each super-step; crash recovery is deterministic.
Super-step"Transactional boundary"Unit of work between checkpoints. LangGraph term.
thread_id"Agent run identifier"Key that binds checkpoints and resume logic.
Idempotency"Safe to retry"Repeating a side effect produces the same result as one attempt.
Outbox pattern"Decouple side effects"Write intent to a table; a separate executor performs and marks done.
At-least-once delivery"Possible duplicates"Message queue semantics; dedup key makes consumer effective-once.
Rainbow deploy"Overlapping versions"Multiple runtime versions concurrent during long-running workloads.
Async fiber"Cooperative yielding"User-mode concurrency; cheap compared to threads for I/O-bound loads.
Checkpoint"State snapshot"Serialized state at a super-step boundary; key for resume.

आगे पढ़ना

  • LangChain — The runtime behind production deep agents लैंगग्राफ रनटाइम डिज़ाइन
  • MegaAgent प्रति एजेंट उत्पादक-उपभोक्ता कतार; दो-परत समन्वय हजारों समवर्ती एजेंटों पर
  • Matrix समन्वय सब्सट्रेट के रूप में संदेश कतारों के साथ विकेंद्रीकृत ढांचा
  • Temporal docs टिकाऊ निष्पादन के लिए संदर्भ कार्यप्रवाह इंजन
  • Anthropic — Multi-agent research system उत्पादन पाठों सहित इंद्रधनुष तैनाती

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.