ओपनक्लॉ के साथ मल्टी-एजेंट ऑर्केस्ट्रेशन पैटर्न

एक एकल AI एजेंट एक प्रक्रिया को स्वचालित कर सकता है। एजेंटों की एक सुव्यवस्थित प्रणाली किसी व्यावसायिक कार्य को स्वचालित कर सकती है। अंतर इस बात में निहित है कि एजेंट किस प्रकार सीमाओं के पार समन्वय, संचार और विफलता को संभालते हैं। मल्टी-एजेंट ऑर्केस्ट्रेशन इंजीनियरिंग अनुशासन है जो स्वतंत्र बॉट्स के संग्रह और एक सुसंगत, विश्वसनीय स्वायत्त प्रणाली के बीच अंतर करता है।

OpenClaw मल्टी-एजेंट ऑर्केस्ट्रेशन के लिए प्राइमेटिव्स प्रदान करता है: एक टाइप किया गया संदेश बस, एक एजेंट रजिस्ट्री, हैंडऑफ़ प्रोटोकॉल, साझा मेमोरी नेमस्पेस, और वितरित ट्रेसिंग जो एजेंट सीमाओं के पार अनुरोधों का पालन करता है। यह मार्गदर्शिका चार मूलभूत ऑर्केस्ट्रेशन पैटर्न को कवर करती है, प्रत्येक का उपयोग कब करना है, उन्हें ओपनक्लाव में कैसे कार्यान्वित करना है, और विफलता मोड के विरुद्ध डिज़ाइन करना है।

मुख्य बातें

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

---

फाउंडेशन: ओपनक्लॉ का एजेंट संचार मॉडल

पैटर्न को कवर करने से पहले, यह समझना महत्वपूर्ण है कि ओपनक्लॉ एजेंट कैसे संवाद करते हैं। तीन तंत्र हैं, प्रत्येक अलग-अलग व्यापार-बंद के साथ:

संदेश बस एक ही सिस्टम में एजेंटों के बीच प्राथमिक संचार चैनल है। एजेंट नामित चैनलों पर टाइप किए गए संदेश प्रकाशित करते हैं; अन्य एजेंट उन चैनलों की सदस्यता लेते हैं। संदेशों को बस ब्रोकर (रेडिस स्ट्रीम या काफ्का, कॉन्फ़िगर करने योग्य) द्वारा जारी रखा जाता है, इसलिए यदि प्राप्तकर्ता एजेंट अस्थायी रूप से अनुपलब्ध है तो संदेश खो नहीं जाते हैं।

प्रत्यक्ष आह्वान एक एजेंट को दूसरे एजेंट के उजागर कौशल को सीधे कॉल करने और प्रतिक्रिया की प्रतीक्षा करने की अनुमति देता है। यह कॉलर के दृष्टिकोण से समकालिक है और कम-विलंबता वाले वर्कफ़्लो के लिए उपयुक्त है जहां कॉलिंग एजेंट परिणाम मिलने तक आगे नहीं बढ़ सकता है। संयम से प्रयोग करें—यह एजेंटों के बीच मजबूत संबंध बनाता है।

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

// Publishing a message
await messageBus.publish("document.classified", {
  documentId: "DOC-4521",
  type: "vendor-invoice",
  confidence: 0.94,
  storageKey: "incoming/doc-4521.pdf",
});

// Subscribing to messages
messageBus.subscribe("document.classified", async (message) => {
  await extractionAgent.handle(message);
});

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

---

पैटर्न 1: पर्यवेक्षक-कार्यकर्ता

पर्यवेक्षक-कार्यकर्ता पैटर्न सबसे व्यापक रूप से लागू मल्टी-एजेंट आर्किटेक्चर है। एक पर्यवेक्षक एजेंट शीर्ष-स्तरीय लक्ष्य प्राप्त करता है, इसे उप-कार्यों में विघटित करता है, प्रत्येक उप-कार्य को एक विशेष कार्यकर्ता एजेंट को सौंपता है, प्रगति की निगरानी करता है, और परिणामों को संश्लेषित करता है।

User/System Goal
      ↓
[ Supervisor Agent ]
  ├─ task 1 → [ Worker Agent A ]
  ├─ task 2 → [ Worker Agent B ]
  └─ task 3 → [ Worker Agent C ]
      ↓
[ Supervisor Agent ] ← results from all workers
      ↓
Synthesized Response

कब उपयोग करें: जब किसी जटिल लक्ष्य के लिए विविध विशेषज्ञता की आवश्यकता होती है। पर्यवेक्षक समन्वय तर्क को संभालता है; कर्मचारी डोमेन विशेषज्ञ हैं जो एक काम अच्छा करते हैं।

ओपनक्ला कार्यान्वयन:

export const SupervisorAgent = defineAgent({
  name: "due-diligence-supervisor",
  skills: ["decompose-goal", "assign-workers", "synthesize-results"],
  async run({ goal, workerRegistry, messageBus }) {
    // Decompose goal into tasks
    const tasks = await decomposeGoal(goal);

    // Assign to appropriate workers
    const assignments = tasks.map((task) => ({
      task,
      worker: workerRegistry.findBestMatch(task.type),
    }));

    // Publish tasks and wait for results
    const results = await Promise.allSettled(
      assignments.map(({ task, worker }) =>
        messageBus.requestReply(`worker.${worker.id}.tasks`, task, { timeoutMs: 60_000 })
      )
    );

    // Synthesize
    const successfulResults = results
      .filter((r) => r.status === "fulfilled")
      .map((r) => r.value);

    return synthesize(goal, successfulResults);
  },
});

मुख्य डिज़ाइन निर्णय:

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

वास्तविक दुनिया का उदाहरण: एक उचित परिश्रम स्वचालन प्रणाली जहां पर्यवेक्षक एक वित्तीय विश्लेषण कार्यकर्ता, कानूनी दस्तावेज़ समीक्षा कार्यकर्ता, बाजार अनुसंधान कार्यकर्ता और संदर्भ जांच कार्यकर्ता को सौंपे गए समानांतर कार्यों में कंपनी की समीक्षा को विघटित करता है। पर्यवेक्षक सभी निष्कर्षों को एक एकीकृत उचित परिश्रम रिपोर्ट में जोड़ता है।

---

पैटर्न 2: पाइपलाइन

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

Input Document
    ↓
[ Stage 1: Ingestion Agent ]
    ↓
[ Stage 2: Classification Agent ]
    ↓
[ Stage 3: Extraction Agent ]
    ↓
[ Stage 4: Validation Agent ]
    ↓
[ Stage 5: Integration Agent ]
    ↓
Output: ERP Record

कब उपयोग करें: प्रत्येक चरण पर स्पष्ट चरण सीमाओं और परिवर्तन के साथ अनुक्रमिक वर्कफ़्लो। उच्च-थ्रूपुट दस्तावेज़ प्रसंस्करण के लिए उत्कृष्ट।

ओपनक्ला कार्यान्वयन:

OpenClaw की पाइपलाइन प्रिमिटिव स्टेज श्रृंखला का प्रबंधन करती है, विफलताओं को संभालती है, और पेलोड सामग्री के आधार पर किसी भी चरण में ब्रांचिंग का समर्थन करती है।

import { definePipeline } from "@openclaw/orchestration";

export const InvoicePipeline = definePipeline({
  name: "invoice-processing",
  stages: [
    { agent: "document-ingester", timeout: 30_000 },
    {
      agent: "document-classifier",
      timeout: 15_000,
      branch: {
        "vendor-invoice": "invoice-extractor",
        "credit-memo": "credit-memo-extractor",
        "unknown": "human-review-queue", // Branch to exception handling
      },
    },
    { agent: "invoice-validator", timeout: 20_000 },
    { agent: "invoice-enricher", timeout: 10_000 },
    { agent: "erp-integrator", timeout: 30_000, retries: 3 },
  ],
  onFailure: {
    agent: "exception-handler",
    preservePartialState: true,
  },
});

मुख्य डिज़ाइन निर्णय:

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

विफलता प्रबंधन: जब सफल चरण एम के बाद चरण एन विफल हो जाता है, तो पाइपलाइन स्थिति को चरण एम पर चेकपॉइंट किया जाता है। विफलता का समाधान होने के बाद (मैन्युअल सुधार, निर्भरता ठीक होने के बाद पुनः प्रयास करें), पाइपलाइन उसी पेलोड के साथ चरण एम+1 से फिर से शुरू होती है।

---

पैटर्न 3: आम सहमति

सर्वसम्मति पैटर्न एक ही इनपुट के विरुद्ध कई स्वतंत्र एजेंटों को चलाता है और सिस्टम के कार्य करने से पहले उन्हें (एक सीमा के भीतर) सहमत होने की आवश्यकता होती है। यह दूसरी राय के समान बहु-एजेंट है और उच्च जोखिम वाले निर्णयों में सबसे मूल्यवान है जहां एकल-एजेंट की त्रुटि महंगी होगी।

Input
  ├─ → [ Evaluator Agent A ] → assessment A
  ├─ → [ Evaluator Agent B ] → assessment B
  └─ → [ Evaluator Agent C ] → assessment C
          ↓
  [ Consensus Resolver ]
    ├── unanimous or majority? → act
    └── no consensus? → escalate to human

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

ओपनक्ला कार्यान्वयन:

export const FraudConsensusCheck = defineAgent({
  name: "fraud-consensus",
  async run({ transaction, evaluators }) {
    // Run all evaluators in parallel
    const assessments = await Promise.all(
      evaluators.map((evaluator) =>
        evaluator.assess(transaction)
      )
    );

    const fraudVotes = assessments.filter((a) => a.isFraud).length;
    const totalVotes = assessments.length;
    const agreementRatio = fraudVotes / totalVotes;

    if (agreementRatio >= 0.67) { // Supermajority fraud detection
      return { decision: "block", confidence: agreementRatio, assessments };
    } else if (agreementRatio === 0) { // Unanimous clear
      return { decision: "allow", confidence: 1 - agreementRatio, assessments };
    } else {
      // Disagreement — escalate with all assessments for human review
      return { decision: "escalate", confidence: null, assessments };
    }
  },
});

मुख्य डिज़ाइन निर्णय:

• मूल्यांकनकर्ता एजेंटों को सहसंबद्ध विफलताओं को कम करने के लिए विभिन्न मॉडलों या विभिन्न प्रोत्साहन रणनीतियों का उपयोग करना चाहिए। दो एजेंट जो एक ही संकेत के साथ एक ही मॉडल का उपयोग करते हैं वे आम तौर पर सहमत होंगे - जो उद्देश्य को विफल करता है।
• सर्वसम्मति सीमा विन्यास योग्य है। अपरिवर्तनीय कार्यों के लिए सर्वसम्मत समझौता उपयुक्त है; साधारण बहुमत प्रतिवर्ती निर्णयों के लिए पर्याप्त है।
• वृद्धि पथों को क्षमता नियोजन की आवश्यकता है - यदि आपकी वृद्धि दर अधिक है, तो मूल्यांकनकर्ता मानदंड को ट्यूनिंग की आवश्यकता है।

---

पैटर्न 4: बाज़ार-निर्माता

मार्केट-मेकर पैटर्न वर्कर एजेंटों का एक पूल बनाए रखता है और कार्य आने के समय सबसे उपयुक्त उपलब्ध वर्कर को गतिशील रूप से कार्य आवंटित करता है। श्रमिक अपनी क्षमताओं और वर्तमान भार को पंजीकृत करते हैं; मार्केट-निर्माता प्रत्येक कार्य को सर्वोत्तम मिलान पर ले जाता है।

Task Queue
    ↓
[ Market-Maker Agent ]
    ├── Worker A: [language-translation] load: 30%
    ├── Worker B: [language-translation] load: 80%
    └── Worker C: [language-translation] load: 10%  ← assigned

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

export const TranslationMarketMaker = defineAgent({
  name: "translation-market-maker",
  tools: ["worker-registry", "task-queue"],
  async run({ tools }) {
    while (true) {
      const task = await tools.taskQueue.dequeue("translation.pending");
      if (!task) { await sleep(100); continue; }

      const workers = await tools.workerRegistry.getAvailable({
        capability: "language-translation",
        targetLanguage: task.targetLanguage,
      });

      if (workers.length === 0) {
        // No specialist available — try generalist
        const generalists = await tools.workerRegistry.getAvailable({ capability: "general-translation" });
        if (generalists.length === 0) {
          await tools.taskQueue.requeueWithDelay(task, { delayMs: 5000 });
          continue;
        }
        workers.push(...generalists);
      }

      // Select worker with lowest load
      const selected = workers.sort((a, b) => a.currentLoad - b.currentLoad)[0];
      await selected.dispatch(task);
    }
  },
});

मुख्य डिज़ाइन निर्णय:

• वर्कर लोड रिपोर्टिंग सटीक और कम विलंबता वाली होनी चाहिए। पुराना लोड डेटा असमान वितरण की ओर ले जाता है।
• फ़ॉलबैक श्रृंखला (विशेषज्ञ → सामान्यवादी → विलंब के साथ कतार) क्षमता की कमी के दौरान कार्य हानि को रोकती है।
• कर्मचारी स्टार्टअप पर स्व-पंजीकरण करते हैं और ग्रेसफुल शटडाउन पर पंजीकरण रद्द करते हैं। स्वास्थ्य जांच मतदान दुर्घटनाग्रस्त श्रमिकों को स्वचालित रूप से हटा देता है।

---

क्रॉस-पैटर्न: वितरित ट्रेसिंग

चाहे आप किसी भी ऑर्केस्ट्रेशन पैटर्न का उपयोग करें, उत्पादन मल्टी-एजेंट सिस्टम के लिए वितरित ट्रेसिंग गैर-परक्राम्य है। प्रत्येक संदेश में एक correlationId और एक spanId होता है। जब कोई एजेंट एक चाइल्ड टास्क बनाता है (पर्यवेक्षक पैटर्न में) या काम को अगले चरण (पाइपलाइन पैटर्न में) में भेजता है, तो यह वर्तमान स्पैन के चाइल्ड के रूप में एक नया स्पैन बनाता है।

// Middleware that injects tracing into all agent message handlers
agent.useHook("preRun", (ctx) => {
  ctx.span = tracer.startSpan(ctx.skill, { childOf: ctx.message.parentSpan });
  ctx.span.setTag("agent.id", ctx.agentId);
  ctx.span.setTag("correlation.id", ctx.message.correlationId);
});

agent.useHook("postRun", (ctx) => {
  ctx.span.finish();
});

वितरित ट्रेसिंग के साथ, आप सभी एजेंट सीमाओं के पार किसी भी कार्य के लिए पूर्ण निष्पादन ट्री की कल्पना कर सकते हैं - विलंबता समस्याओं और अप्रत्याशित व्यवहार को डीबग करने के लिए अमूल्य।

---

विरोधी पैटर्न से बचना चाहिए

साझा परिवर्तनशील स्थिति: समन्वय के बिना एक ही डेटा स्टोर रिकॉर्ड पर एकाधिक एजेंट लिखने से अपडेट खो जाते हैं और दौड़ की स्थिति पैदा होती है। समन्वय के लिए संदेश बस का उपयोग करें; एजेंट अपने राज्य के मालिक होते हैं।

तीन एजेंटों से अधिक लंबी सिंक्रोनस चेन: यदि एजेंट ए बी को कॉल करता है जो सी को कॉल करता है जो डी को सिंक्रोनस रूप से कॉल करता है, तो विलंबता यौगिक और विफलता ब्लास्ट त्रिज्या बड़ी होती है। चेकपॉइंटिंग के साथ लंबी सिंक्रोनस श्रृंखलाओं को एसिंक्रोनस पाइपलाइन चरणों में तोड़ें।

डोमेन तर्क के साथ पर्यवेक्षक एजेंट: पर्यवेक्षकों को डोमेन कार्य निष्पादित नहीं करना चाहिए, बल्कि व्यवस्थित करना चाहिए। जब एक पर्यवेक्षक निष्कर्षण तर्क या सत्यापन नियमों को समाहित करना शुरू कर देता है, तो यह भेष में एक अखंड पत्थर बन जाता है।

एजेंटों के बीच अंतर्निहित अनुबंध: संदेश स्कीमा को बस स्तर पर संस्करणित और मान्य किया जाना चाहिए। वे एजेंट जो संदेश संरचना को मान्य करने के बजाय मान लेते हैं, जब प्रेषक अपना आउटपुट स्वरूप बदलता है तो चुपचाप विफल हो जाता है।

---

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

आप पर्यवेक्षक-कार्यकर्ता प्रणाली में आंशिक विफलताओं को कैसे संभालते हैं जहां कुछ कार्यकर्ता सफल होते हैं और कुछ विफल होते हैं?

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

क्या एक ही एजेंट एक साथ कई ऑर्केस्ट्रेशन पैटर्न में भाग ले सकता है?

हाँ। एक एजेंट सिर्फ एक सेवा है - यह एक पर्यवेक्षक-कार्यकर्ता प्रणाली में एक कार्यकर्ता हो सकता है, साथ ही एक पाइपलाइन में एक चरण भी हो सकता है और एक आम सहमति जांच में एक मूल्यांकनकर्ता के रूप में भाग ले सकता है। प्रत्येक आह्वान स्वतंत्र है. महत्वपूर्ण आवश्यकता यह है कि एजेंट इनवोकेशन के बीच स्टेटलेस हों (स्टेटफुल डेटा मेमोरी स्टोर्स में जाता है, एजेंट इंस्टेंस वेरिएबल्स में नहीं) इसलिए एकाधिक समवर्ती इनवोकेशन हस्तक्षेप नहीं करते हैं।

उच्च-थ्रूपुट सिस्टम के लिए संदेश बस का ओवरहेड क्या है?

संदेश बस बैकएंड के रूप में रेडिस स्ट्रीम के साथ, संदेश प्रकाशन/सदस्यता विलंबता आमतौर पर 64KB से कम के संदेशों के लिए 2ms से कम है। प्रति मिनट हजारों दस्तावेजों को संसाधित करने वाली उच्च-थ्रूपुट पाइपलाइनों के लिए, यह प्रत्येक चरण में प्रसंस्करण कार्य की तुलना में नगण्य है। अत्यधिक उच्च-थ्रूपुट सिस्टम (प्रति दिन लाखों संदेश) के लिए, काफ्का उच्च परिचालन जटिलता की कीमत पर उच्च निरंतर थ्रूपुट प्रदान करता है।

जब व्यक्तिगत एजेंट विकसित होते हैं तो आप मल्टी-एजेंट सिस्टम का संस्करण कैसे बनाते हैं?

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

जब कार्यों पर निर्भरता होती है तो मार्केट-मेकर पैटर्न कार्य क्रम को कैसे संभालता है?

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

---

अगले चरण

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

ECOSIRE की ओपनक्लाव मल्टी-एजेंट ऑर्केस्ट्रेशन सेवा जटिल मल्टी-एजेंट सिस्टम के लिए आर्किटेक्चर डिजाइन, कार्यान्वयन और चल रहे अनुकूलन प्रदान करती है। हमारी टीम ने दस्तावेज़ प्रसंस्करण प्रणालियों के लिए ऑर्केस्ट्रेशन आर्किटेक्चर डिज़ाइन किया है जो मासिक रूप से लाखों दस्तावेज़ों को संभालती है, 24/7 चलने वाली वित्तीय विश्लेषण पाइपलाइनें, और एक दर्जन विशेष एजेंटों के साथ समन्वय करने वाली एचआर स्वचालन प्रणाली।

अपनी मल्टी-एजेंट आर्किटेक्चर आवश्यकताओं पर चर्चा करने के लिए ECOSIRE से संपर्क करें।