أنماط التنسيق متعددة الوكلاء باستخدام OpenClaw

يمكن لعامل الذكاء الاصطناعي الواحد أتمتة العملية. يمكن لنظام الوكلاء المنسق جيدًا أتمتة وظيفة العمل. ويكمن الاختلاف في كيفية قيام الوكلاء بالتنسيق والتواصل والتعامل مع الفشل عبر الحدود. التنسيق متعدد الوكلاء هو النظام الهندسي الذي يُحدث الفرق بين مجموعة من الروبوتات المستقلة ونظام مستقل موثوق به.

يوفر OpenClaw الأساسيات للتنسيق متعدد الوكلاء: ناقل الرسائل المكتوبة، وسجل الوكيل، وبروتوكولات التسليم، ومساحات أسماء الذاكرة المشتركة، والتتبع الموزع الذي يتبع الطلبات عبر حدود الوكيل. يغطي هذا الدليل أنماط التنسيق الأساسية الأربعة، ومتى يتم استخدام كل منها، وكيفية تنفيذها في OpenClaw، وأوضاع الفشل التي يجب التصميم مقابلها.

الوجبات الرئيسية

• يعد نمط المشرف والعامل هو النمط الأكثر شيوعًا: حيث يقوم وكيل تنسيق بتحليل الأهداف وتفويض العمال المتخصصين.
• يعد نمط خط الأنابيب هو الأفضل لمعالجة المستندات المتسلسلة أو تحويل البيانات متعدد الخطوات حيث تنتج كل مرحلة مدخلات للمرحلة التالية.
• يمكّن نمط الإجماع العديد من الوكلاء المستقلين من تقييم نفس السؤال، مما يقلل من مخاطر أخطاء الوكيل الفردي في القرارات عالية المخاطر.
• يقوم نمط صانع السوق بتخصيص المهام للوكيل المتوفر الأكثر قدرة بشكل ديناميكي، مما يتيح موازنة التحميل والتدهور السلس.
• يستخدم الاتصال عبر الوكلاء ناقل الرسائل المكتوب في OpenClaw - بدون تمرير سلسلة أولية، ولا توجد حالة مشتركة قابلة للتغيير بين الوكلاء.
• يعد التتبع الموزع ضروريًا لتصحيح أخطاء الوكيل المتعدد - تحمل كل رسالة معرف ارتباط يمتد عبر حدود الوكيل.
• تعمل قواطع الدائرة عند حدود الوكيل على منع حالات الفشل المتتالية عند عدم توفر وكيل واحد في النظام.
• تقوم ECOSIRE بتصميم وتنفيذ بنيات متعددة الوكلاء لسير عمل أتمتة المؤسسات المعقدة.

---

المؤسسة: نموذج تواصل الوكيل الخاص بـ OpenClaw

قبل تغطية الأنماط، من المهم فهم كيفية تواصل وكلاء OpenClaw. هناك ثلاث آليات، لكل منها مقايضات مختلفة:

ناقل الرسائل هو قناة الاتصال الأساسية بين الوكلاء في نفس النظام. يقوم الوكلاء بنشر الرسائل المكتوبة على القنوات المسماة؛ يشترك الوكلاء الآخرون في تلك القنوات. يتم الاحتفاظ بالرسائل بواسطة وسيط الناقل (Redis Streams أو Kafka، قابل للتكوين)، لذلك لا يتم فقدان الرسائل إذا كان وكيل الاستقبال غير متاح مؤقتًا.

الاستدعاء المباشر يسمح لأحد العملاء باستدعاء المهارات المكشوفة لدى وكيل آخر مباشرة وانتظار الرد. يعد هذا متزامنًا من وجهة نظر المتصل ومناسبًا لعمليات سير العمل ذات زمن الوصول المنخفض حيث لا يمكن لوكيل الاتصال المتابعة حتى يحصل على النتيجة. استخدم بشكل مقتصد - فهو يخلق اقترانًا محكمًا بين العوامل.

مساحات أسماء الذاكرة المشتركة تسمح للعملاء داخل نفس النظام بالقراءة من المنطقة المشتركة لمخزن الذاكرة والكتابة إليها. يعد هذا مناسبًا لتمرير كائنات السياق الكبيرة (مستند تتم معالجته، وملف تعريف العميل الذي يتم إثرائه عبر المراحل) دون إجراء تسلسل لها من خلال حمولات الرسائل.

// 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

متى يتم الاستخدام: عندما يتطلب هدف معقد خبرة غير متجانسة. المشرف يتعامل مع منطق التنسيق. الموظفون متخصصون في المجال ويفعلون شيئًا جيدًا.

** تنفيذ OpenClaw **:

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 **:

يدير خط أنابيب 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 حالة خط الأنابيب الجزئي حتى يتمكن من الاستئناف من آخر مرحلة ناجحة بدلاً من البدء من جديد.
• يتيح التفريع لأنواع المستندات المختلفة اتباع خطوط فرعية مختلفة بعد التصنيف.
• استخدم مساحة اسم الذاكرة المشتركة لتمرير الحمولات الكبيرة (المخازن المؤقتة للمستندات) بين المراحل بدلاً من إجراء تسلسل لها من خلال ناقل الرسائل.

معالجة الفشل: عندما تفشل المرحلة N بعد المراحل M الناجحة، يتم فحص حالة خط الأنابيب في المرحلة M. بعد حل الفشل (التصحيح اليدوي، إعادة المحاولة بعد استعادة التبعية)، يستأنف خط الأنابيب من المرحلة M+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

متى يتم الاستخدام: القرارات عالية المخاطر (الموافقات على القروض، واكتشاف الاحتيال، وتحليل السجلات الطبية، ومراجعة بنود العقد)، أو المدخلات المتعارضة حيث قد يتم التلاعب بوكيل واحد، أو المواقف التي تتمتع فيها النماذج المختلفة بنقاط قوة متكاملة.

** تنفيذ OpenClaw **:

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();
});

باستخدام التتبع الموزع، يمكنك تصور شجرة التنفيذ الكاملة لأي مهمة عبر جميع حدود الوكيل - وهو أمر لا يقدر بثمن لتصحيح مشكلات زمن الاستجابة والسلوك غير المتوقع.

---

الأنماط المضادة التي يجب تجنبها

حالة مشتركة قابلة للتغيير: يؤدي قيام العديد من الوكلاء بالكتابة إلى نفس سجل مخزن البيانات دون تنسيق إلى فقدان التحديثات وحالات السباق. استخدم ناقل الرسائل للتنسيق؛ الوكلاء يمتلكون دولتهم الخاصة.

سلاسل متزامنة أطول من ثلاثة وكلاء: إذا اتصل الوكيل A بـ B الذي يستدعي C الذي يستدعي D بشكل متزامن، فإن مركبات زمن الوصول ونصف قطر انفجار الفشل يكون كبيرًا. قم بتقسيم السلاسل المتزامنة الطويلة إلى مراحل خطوط أنابيب غير متزامنة مع نقاط التفتيش.

الوكلاء المشرفون الذين لديهم منطق المجال: يجب على المشرفين تنسيق عمل المجال، وليس تنفيذه. عندما يبدأ المشرف في احتواء منطق الاستخراج أو قواعد التحقق من الصحة، يصبح كتلة متراصة مقنعة.

العقود الضمنية بين الوكلاء: يجب إصدار مخططات الرسائل والتحقق من صحتها على مستوى الناقل. الوكلاء الذين يفترضون بنية الرسالة بدلاً من التحقق من صحتها يفشلون بصمت عندما يقوم المرسل بتغيير تنسيق الإخراج الخاص به.

---

الأسئلة المتداولة

كيف تتعامل مع حالات الفشل الجزئي في نظام المشرف-العامل حيث ينجح بعض العمال ويفشل البعض الآخر؟

يتلقى المشرف نتائج جميع مهام العامل كمزيج من النجاحات والإخفاقات. تحدد مهارة التوليف كيفية التعامل مع النتائج الجزئية بناءً على الهدف: بالنسبة لبعض الأهداف، تكون النتائج الجزئية كافية لإنتاج مخرجات مفيدة؛ وبالنسبة للآخرين، فإن جميع النتائج مطلوبة. قم بتكوين المشرف بالحد الأدنى من النجاح - إذا نجح أقل من تلك النسبة من العمال، قم بالتصعيد بدلاً من إنتاج مخرجات جزئية قد تكون مضللة.

هل يمكن لنفس الوكيل المشاركة في أنماط تنسيق متعددة في وقت واحد؟

نعم. الوكيل هو مجرد خدمة - يمكن أن يكون عاملاً في نظام مشرف-عامل بينما يكون أيضًا مرحلة في خط الأنابيب ويشارك كمقيم في فحص الإجماع. كل استدعاء مستقل. الشرط الحاسم هو أن يكون الوكلاء عديمي الحالة بين الاستدعاءات (تنتقل البيانات ذات الحالة إلى مخازن الذاكرة، وليس في متغيرات مثيل الوكيل) بحيث لا تتداخل الاستدعاءات المتزامنة المتعددة.

ما هو الحمل الزائد لناقل الرسائل للأنظمة عالية الإنتاجية؟

باستخدام Redis Streams كواجهة خلفية لحافلة الرسائل، يكون زمن استجابة نشر/اشتراك الرسائل أقل من 2 مللي ثانية للرسائل التي يقل حجمها عن 64 كيلو بايت. بالنسبة لخطوط الأنابيب عالية الإنتاجية التي تعالج آلاف المستندات في الدقيقة، فإن هذا لا يكاد يذكر مقارنة بأعمال المعالجة في كل مرحلة. بالنسبة للأنظمة ذات الإنتاجية العالية للغاية (ملايين الرسائل يوميًا)، توفر كافكا إنتاجية مستدامة أعلى على حساب التعقيد التشغيلي العالي.

كيف يمكنك إصدار أنظمة متعددة الوكلاء عندما يتطور الوكلاء الفرديون؟

يستخدم وكلاء الإصدار الإصدار الدلالي بشكل مستقل في بياناتهم. يقوم ناقل الرسائل بالتحقق من صحة الرسائل مقابل إصدار المخطط المعلن الخاص بها. عندما يقوم الوكيل بتغيير مخطط الإخراج الخاص به (تغيير فاصل)، فإنه يرفع الإصدار الرئيسي ويقوم الناقل بتوجيه رسائل المخطط القديم إلى الإصدار السابق. يعمل كلا الإصدارين في وقت واحد أثناء نافذة الترحيل. يحدد تكوين المشرف أو خط الأنابيب إصدار كل عامل يحتاجه، مما يتيح لك التحكم الكامل في توقيت بدء التشغيل.

كيف يتعامل نمط صانع السوق مع ترتيب المهام عندما يكون للمهام تبعيات؟

يُعد صانع السوق مناسبًا للمهام المستقلة، وهي المهام التي يمكن تنفيذها بأي ترتيب. بالنسبة للمهام ذات التبعيات، استخدم نمط خط الأنابيب أو المشرف بدلاً من ذلك، والذي يفرض الترتيب بشكل صريح. إذا كان لديك مزيج من المهام المستقلة والتابعة، فإن نمط المشرف يعمل بشكل جيد: يقوم المشرف بإرسال المهام المستقلة إلى مجمع صانعي السوق ويدير ترتيب التبعية للباقي.

---

الخطوات التالية

يؤدي التنسيق متعدد الوكلاء إلى فتح تعقيدات الأتمتة التي لا يستطيع الوكلاء الفرديون التعامل معها. تغطي الأنماط الواردة في هذا الدليل - العامل المشرف، وخط الأنابيب، والإجماع، وصانع السوق - الغالبية العظمى من حالات استخدام التشغيل الآلي للمؤسسة. المفتاح هو اختيار النمط الصحيح لبنية الاتصال الخاصة بالمشكلة، وليس فرض كل مشكلة في بنية واحدة.

توفر ECOSIRE [خدمة تنسيق OpenClaw متعددة الوكلاء] (/services/openclaw/multi-agent-orchestration) التصميم المعماري والتنفيذ والتحسين المستمر للأنظمة المعقدة متعددة الوكلاء. لقد صمم فريقنا بنيات متزامنة لأنظمة معالجة المستندات التي تتعامل مع ملايين المستندات شهريًا، وخطوط أنابيب التحليل المالي التي تعمل على مدار الساعة طوال أيام الأسبوع، وأنظمة أتمتة الموارد البشرية التي تنسق عبر عشرات الوكلاء المتخصصين.

اتصل بـ ECOSIRE لمناقشة متطلبات البنية متعددة الوكلاء لديك.