بنى الوكلاء المتعددين والتنسيق

لماذا أنظمة الوكلاء المتعددين

يمكن لوكيل واحد باستدعاء LLM واحد التعامل مع المهام المباشرة. لكن المشاكل الواقعية تتجاوز بسرعة ما يمكن لوكيل واحد التعامل معه بشكل جيد. تعالج أنظمة الوكلاء المتعددين أربعة تحديات أساسية:

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

التخصص — المهام المختلفة تتطلب تكوينات مختلفة. وكيل البرمجة يحتاج وصولاً لمفسر الكود ويجب أن يستخدم نموذجاً محسّناً لتوليد الكود. وكيل التلخيص يحتاج نافذة سياق كبيرة لكن لا يحتاج وصولاً للأدوات. بمنح كل وكيل أمر النظام الخاص به ومجموعة الأدوات واختيار النموذج، تحسّن لكل مهمة فرعية.

التنفيذ المتوازي — المهام الفرعية المستقلة يمكن تشغيلها في وقت واحد. إذا كان استفسار العميل يحتاج البحث عن الطلب ومعلومات المنتج معاً، يمكن لوكيلين جلب تلك البيانات بالتوازي بدلاً من التسلسل، مما يقلل زمن الاستجابة بشكل كبير.

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

أنماط التنسيق

نمط المشرف

وكيل مشرف مركزي يستقبل طلب المستخدم، ويقسمه إلى مهام فرعية، ويوجه كل مهمة فرعية للوكيل المتخصص المناسب، ويجمع النتائج في استجابة نهائية.

طلب المستخدم → المشرف → [وكيل أ، وكيل ب، وكيل ج] → المشرف → الاستجابة

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

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

النمط الهرمي

شجرة من المشرفين حيث يفوّض مشرف المستوى الأعلى إلى مشرفي المستوى المتوسط، الذين يفوّضون بدورهم إلى وكلاء العمل. هذا يوسع نمط المشرف للتعامل مع تفكيك المهام الأكثر تعقيداً.

المشرف الأعلى → [قائد فريق أ، قائد فريق ب]
قائد فريق أ → [عامل أ1، عامل أ2]
قائد فريق ب → [عامل ب1، عامل ب2]

نقاط القوة: يتوسع للمهام المعقدة، تقسيم طبيعي للمسؤوليات. نقاط الضعف: التسلسلات الهرمية العميقة تضيف زمن استجابة. تتبع الأعطال عبر مستويات متعددة صعب.

نمط الند للند

الوكلاء يتواصلون مباشرة مع بعضهم البعض بدون منسق مركزي. كل وكيل يقرر متى يسلّم العمل لوكيل آخر بناءً على تقييمه الخاص للمهمة.

وكيل أ ←→ وكيل ب ←→ وكيل ج

نمط OpenAI Swarm يستخدم هذا المنهج: الوكلاء لديهم دوال handoff تنقل المحادثة لوكيل آخر عندما يحددون أن المهمة خارج تخصصهم.

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

نمط خط الأنابيب

الوكلاء مرتبون في تسلسل ثابت حيث يصبح ناتج كل وكيل مدخلاً للوكيل التالي. هذا يعمل جيداً لسير العمل ذات المراحل الواضحة.

المدخل → وكيل أ → وكيل ب → وكيل ج → المخرج

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

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

النمط القائم على السوق

الوكلاء "يزايدون" على المهام بناءً على قدراتهم وحمل العمل الحالي. وسيط المهام يعيّن العمل للوكيل الأنسب. هذا أقل شيوعاً في أنظمة LLM لكنه يظهر في الحوسبة الموزعة.

نقاط القوة: موازنة حمل ديناميكية، تنظيم ذاتي. نقاط الضعف: معقد التنفيذ، مبالغ فيه لمعظم حالات استخدام وكلاء LLM.

مناهج إدارة الحالة

كيفية مشاركة الوكلاء للمعلومات هو قرار معماري حاسم:

الحالة المشتركة

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

interface SharedState {
  messages: Message[];
  currentAgent: string;
  taskResults: Record<string, any>;
  metadata: Record<string, any>;
}

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

تمرير الرسائل

الوكلاء يتواصلون بإرسال رسائل مهيكلة لبعضهم البعض. كل وكيل يحتفظ بحالته الداخلية الخاصة ولا يكشف المعلومات إلا عبر الرسائل.

interface AgentMessage {
  from: string;
  to: string;
  type: "request" | "response" | "handoff";
  payload: any;
  conversationId: string;
}

المقايضات: فصل نظيف للمسؤوليات. الوكلاء قابلون للاختبار بشكل مستقل. لكن توجيه الرسائل يضيف تعقيداً، وتحتاج وسيط رسائل أو ناقل أحداث.

بنية السبورة

مساحة عمل مشتركة ("السبورة") حيث ينشر الوكلاء نتائج جزئية. أي وكيل يمكنه قراءة السبورة والمساهمة عندما يكون لديه شيء ذو صلة ليضيفه. متحكم يراقب السبورة وينشّط الوكلاء حسب الحاجة.

المقايضات: مرن وقابل للتوسيع. جيد للمشاكل حيث الحل يظهر تدريجياً. لكن منطق التحكم يمكن أن يصبح معقداً.

بروتوكولات تسليم الوكلاء

التسليم يحدث عندما ينقل وكيل التحكم في المحادثة لوكيل آخر. تصميم بروتوكولات التسليم بشكل جيد أمر حاسم لتجربة المستخدم وموثوقية النظام.

ما يجب نقله أثناء التسليم

1. سجل المحادثة — سلسلة الرسائل الكاملة ليكون لدى الوكيل المستقبل سياق
2. حالة المهمة — ما تم إنجازه حتى الآن وما تبقى
3. نية المستخدم — لماذا يحدث التسليم (تقييم الوكيل الأول)
4. البيانات الوصفية — هوية المستخدم، معرف الجلسة، مستوى الأولوية، أي نتائج أدوات مجمّعة

محفزات التسليم

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

نمط تنفيذ التسليم

interface HandoffRequest {
  sourceAgent: string;
  targetAgent: string;
  reason: string;
  conversationHistory: Message[];
  taskState: Record<string, any>;
  priority: "low" | "medium" | "high" | "critical";
}

الوكيل المستقبل يجب أن يتحقق أنه يمكنه التعامل مع الطلب قبل قبوله. إذا لم يستطع، يجب أن يرفض التسليم مع سبب، مما يسمح للمنسق بتجربة وكيل بديل.

أنماط الفشل في أنظمة الوكلاء المتعددين

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

نمط الفشل	الوصف	التخفيف
حلقة التفويض اللانهائية	الوكيل أ يسلّم للوكيل ب، الذي يسلّم مرة أخرى للوكيل أ	تتبع سجل التسليم؛ تحديد حد أقصى للتسليمات لكل طلب
تلف الحالة	الوكلاء المتزامنون يكتبون فوق تحديثات حالة بعضهم البعض	استخدام حالة مُسَخَّرة مع حل التعارضات
استنفاد الموارد	الوكلاء يولّدون مهام فرعية كثيرة جداً، مستهلكين جميع الرموز أو استدعاءات API المتاحة	تعيين ميزانيات رموز وحدود مهام لكل طلب
الجمود	الوكيل أ ينتظر نتيجة الوكيل ب بينما ب ينتظر أ	استخدام مهلات زمنية على جميع الاتصالات بين الوكلاء
الفشل المتسلسل	فشل وكيل واحد يسبب فشل الوكلاء اللاحقين	قواطع الدائرة تعزل الوكلاء الفاشلين
تجاوز نافذة السياق	سجل المحادثة المتراكم يتجاوز حد سياق النموذج	تلخيص أو اقتطاع السجل قبل التسليم

بنى وكلاء متعددين في العالم الحقيقي

Anthropic Claude — استخدام الأدوات وMCP

منهج Anthropic يتمحور حول نموذج واحد قادر مع وصول واسع للأدوات عبر بروتوكول سياق النموذج (MCP). بدلاً من عدة وكلاء LLM، البنية تمنح وكيلاً واحداً وصولاً لأدوات كثيرة عبر خوادم MCP. النموذج يقرر أي الأدوات يستدعي، وينفذها، ويفكر في النتائج في حلقة.

هذه تقنياً بنية وكيل واحد مع تنسيق أدوات متعددة، لكن النمط يتوسع لبنية متعددة الوكلاء عندما تحتوي خوادم MCP نفسها على منطق الوكلاء.

نمط OpenAI Swarm

نمط Swarm (مفتوح المصدر من OpenAI) ينفذ تسليم وكلاء الند للند. كل وكيل يُعرَّف بأمر نظام ومجموعة دوال، بما فيها دوال handoff_to_* التي تنقل المحادثة. إطار العمل يدير حالة المحادثة ويوجه الرسائل للوكيل النشط.

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

مشرف LangGraph

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

هيكل الرسم البياني يجعل تدفق التحكم صريحاً وقابلاً للتصوير. الحالة مُنمَّطة ومُتحقق منها عند كل انتقال.

تعمق في المقابلات: نظام دعم عملاء متعدد الوكلاء

هذا أحد أكثر أسئلة تصميم الوكلاء المتعددين شيوعاً في المقابلات. إليك كيفية التعامل معه:

المتطلبات

• توجيه استفسارات العملاء للمتخصص المناسب (الفوترة، الدعم التقني، المرتجعات، عام)
• التعامل مع الاستفسارات متعددة المواضيع (مثل: "لدي سؤال عن الفاتورة وأيضاً مشكلة تقنية")
• التصعيد للبشر عندما لا يستطيع الوكلاء حل المشكلة
• الحفاظ على استمرارية المحادثة عبر التسليمات
• تتبع مقاييس الحل

البنية المقترحة

اختيار النمط: مشرف مع وكلاء متخصصين

رسالة العميل
      ↓
  وكيل التوجيه (المصنّف)
      ↓
  المشرف
      ↓ يوجّه إلى
  ┌──────────────────────────────────────┐
  │ وكيل الفوترة │ وكيل تقني │ وكيل    │
  │               │           │ المرتجعات │
  └──────────────────────────────────────┘
      ↓ إذا لم يُحل
  وكيل التصعيد → طابور البشر

وكيل التوجيه — يصنف نوع الاستفسار باستخدام نموذج سريع وغير مكلف. للاستفسارات متعددة المواضيع، يحدد جميع المواضيع وينشئ مهام فرعية.

الوكلاء المتخصصون — كل منهم لديه أمر نظام مركّز، ووصول للأدوات ذات الصلة (واجهة API لنظام الفوترة، قاعدة المعرفة، إدارة الطلبات)، وأمثلة few-shot خاصة بالمجال.

منطق التصعيد:

• ثقة الوكيل تحت العتبة بعد 3 محاولات
• العميل يطلب إنساناً صراحة
• اكتشاف مواضيع حساسة (قانونية، سلامة) بواسطة المصنّف
• تجاوز ميزانية الرموز بدون حل

إدارة الحالة: حالة مشتركة مع سجل المحادثة، وتعيين الوكيل الحالي، وحالة الحل لكل موضوع، وسجل التصعيد.

نقاط رئيسية للمقابلة يجب ذكرها:

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

نصيحة للمقابلة: عند تصميم أنظمة وكلاء متعددين، عالج دائماً ثلاثة أمور: كيف يكتشف الوكلاء قدرات بعضهم البعض، وكيف تتدفق الحالة بين الوكلاء، وماذا يحدث عندما يفشل وكيل. هذه الاهتمامات الثلاثة تفصل التصاميم المبتدئة عن المتقدمة.

في المختبر، ستنفذ إطار تنسيق وكلاء متعددين بلغة TypeScript — ببناء المشرف، وبروتوكول التسليم، والحالة المشتركة، وأنماط قاطع الدائرة من الصفر. :::