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

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

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

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

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

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

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

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

نمط المشرف

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

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

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

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

النمط الهرمي

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

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

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

نمط الند للند

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

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

OpenAI Agents SDK هو التنفيذ السائد لهذا الشكل: الوكلاء يعرضون دوال تسليم تنقل المحادثة لوكيل آخر عندما تقع المهمة خارج تخصصهم.¹

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

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

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

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

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

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

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

الوكلاء "يزايدون" على المهام بناءً على قدراتهم وحمل العمل الحالي. وسيط المهام يعيّن العمل للوكيل الأنسب. هذا أقل شيوعاً في أنظمة 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";
}

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

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

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

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

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

نظام البحث لدى Anthropic — منسّق وعمّال

نشرت Anthropic البنية وراء ميزة Research في Claude، وهي نظام متعدد الوكلاء بنمط المنسّق والعمّال، لا وكيل واحد بأدوات كثيرة. يحلّل وكيل قائد الاستعلام، ويحدد استراتيجية، ثم يولّد وكلاء فرعيين متخصصين يبحثون بالتوازي؛ تعود نتائجهم إلى الوكيل القائد الذي يركّب الإجابة، بينما يُعالَج الإسناد في تمريرة منفصلة. الاستعلامات المعتادة تستخدم 3-5 وكلاء فرعيين بالتوازي، والبحوث المعقدة تولّد أكثر من عشرة.²

ما يجعل هذا جديراً بالدراسة أن Anthropic نشرت التكاليف إلى جانب المكاسب:

• أظهر تقييمها البحثي الداخلي أن التكوين متعدد الوكلاء (وكيل قائد أقوى مع وكلاء فرعيين أخف) تفوّق على الوكيل الواحد المرجعي بنسبة 90.2%.²
• النظام نفسه يستهلك تقريباً 15 ضعف رموز تفاعل المحادثة العادي.²
• وهي صريحة بشأن مواضع فشله: تعدد الوكلاء خيار رديء في "المجالات التي تتطلب أن يتشارك جميع الوكلاء السياق نفسه أو تنطوي على اعتماديات كثيرة"، وتسمّي معظم مهام البرمجة بوصفها هذه الحالة تحديداً.²

وبشكل منفصل، يعالج بروتوكول سياق النموذج (MCP) محوراً مختلفاً: فهو بروتوكول مفتوح لتوريد الأدوات والسياق للنموذج، بحيث تعيش الأدوات خلف حدّ بروتوكولي بدل أن تكون داخل كود وكيل بعينه. التنسيق وتوريد الأدوات خياران مستقلان — يمكنك تشغيل وكيل واحد فوق أدوات MCP، أو نظام منسّق وعمّال يعتمد عمّاله جميعاً على خوادم MCP نفسها.

OpenAI Agents SDK — التسليمات كعنصر أساسي

لشكل الند للند تنفيذ مصان في OpenAI Agents SDK، حيث يُعرَّف كل وكيل بتعليمات ومجموعة أدوات، وتكون التسليمات عنصراً أساسياً إلى جانب الحواجز والجلسات والتتبّع.¹

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

ولهذا الأمر درس تاريخي يستحق أن تحمله معك إلى المقابلة. فتحت OpenAI مصدر هذا النمط أول مرة عام 2024 باسم Swarm، بوصفه إطاراً تجريبياً تعليمياً صراحةً؛ ثم أُحيل للتقاعد، وينص ملف README الخاص به الآن بوضوح على أنه "استُبدل بـ OpenAI Agents SDK"، ويوصي بالانتقال "لجميع حالات الاستخدام الإنتاجية".³ النمط بقي؛ والمكتبة لم تبقَ. وهذه هي الحالة الطبيعية في هذا المجال، ولهذا تحديداً يسأل المحاورون عن الأنماط لا عن واجهات API.

مشرف LangGraph

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

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

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

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

المتطلبات

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

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

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

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

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

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

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

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

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

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

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

وهناك أمر رابع يفصل المتقدم عن الكبير: قل متى لن تستخدم تعدد الوكلاء. توجيه Anthropic نفسه أن النمط رديء الملاءمة حين يحتاج الوكلاء لتشارك السياق أو حين تتعلق المهام الفرعية ببعضها — وكلفته نحو 15 ضعف الرموز.² والمرشح الذي يلجأ لعدة وكلاء في مهمة كثيفة الاعتماديات يكون قد صمّم وكيلاً واحداً أبطأ وأغلى.

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

Footnotes

1. OpenAI، openai/openai-agents-python — حزمة Agents SDK التي تقدّم التسليمات والحواجز والجلسات والتتبّع كعناصر أساسية. ↩ ↩²

2. Anthropic، How we built our multi-agent research system — مدونة الهندسة لدى Anthropic. ↩ ↩² ↩³ ↩⁴ ↩⁵

3. OpenAI، openai/swarm — ملف README للمستودع، وينص على أن Swarm "استُبدل بـ OpenAI Agents SDK" ويوصي بالانتقال "لجميع حالات الاستخدام الإنتاجية". ::: ↩