6 Multi-Agent Orchestration Patterns That Actually Work in Production

أفادت غارتنر بارتفاع هائل بلغت نسبته 1,445% في الاستفسارات المتعلقة بأنظمة الوكلاء المتعددين بين الربع الأول من عام 2024 والربع الثاني من عام 2025. وتستخدم المؤسسات بالفعل ما متوسطه 12 وكيلاً، ومن المتوقع أن يرتفع هذا العدد بنسبة 67% في غضون عامين.

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

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

1. المنسق والعامل (Orchestrator-worker)

يتلقى وكيل واحد المهمة، ويقسمها إلى مهام فرعية، ويفوض كلاً منها إلى عامل متخصص، ثم يجمع النتائج. يستخدم المنسق نموذجاً عالي القدرة بينما يستخدم العمال نماذج أرخص ومتخصصة في مهام معينة، مما يقلل التكاليف بنسبة تتراوح بين 40% و60%.

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

تستخدم شركة Wells Fargo هذا النمط لمنح 35,000 من موظفي البنك إمكانية الوصول إلى 1,700 إجراء في 30 ثانية بدلاً من 10 دقائق. كما تطبقه Salesforce في منصتها Agentforce 2.0 من خلال محرك التفكير لديهم Atlas Reasoning Engine.

كيف يفشل

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

وتعد مشكلة تجاوز سعة نافذة السياق (Context window overflow) أكثر دقة وصعوبة؛ حيث يجمع المنسق السياق من كل عامل. وعند وجود أربعة عمال أو أكثر، غالباً ما يتجاوز السياق حدود النافذة. وبالتالي، فإن تدفقات العمل التي تكلف 0.50 دولار في مرحلة الاختبار يمكن أن تصل تكلفتها إلى 50,000 دولار شهرياً عند إجراء 100 ألف عملية تشغيل، لأن المنسق يجري مكالمات متعددة للنماذج اللغوية الكبيرة (LLM) لتقسيم المهام وتجميعها بالإضافة إلى مكالمة كل عامل.

2. المسار التسلسلي (Sequential pipeline)

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

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

يوثق مركز هندسة Azure التابع لشركة Microsoft استخدام شركة محاماة لهذا النمط لإنشاء العقود: اختيار القالب، وتخصيص البنود، ومراجعة الامتثال، وتقييم المخاطر، حيث يتم التعامل مع كل مرحلة بواسطة AI agent مستقل.

كيف يفشل

انتشار الأخطاء. تؤدي المخرجات السيئة في المرحلة الأولى إلى تتابع الأخطاء عبر جميع المراحل اللاحقة دون إمكانية للرجوع والتراجع.

أما المشكلة الأقل وضوحاً فهي الأعباء الإضافية لمعالجة البيانات. فالمسار المكون من أربعة وكلاء يراكم حوالي 950 مللي ثانية من أعباء التنسيق الإضافية بينما تستغرق المعالجة الفعلية 500 مللي ثانية فقط. كما يستهلك مسار مكون من ثلاثة وكلاء 29,000 رمز (token) مقابل 10,000 رمز لنهج الوكيل الواحد المكافئ. وإذا لم يكن مسار العمل الخاص بك بحاجة لل تخصص، فأنت تدفع 3 أضعاف التكلفة للحصول على نفس النتيجة.

3. توزيع المهام وتجميعها (Fan-out / fan-in)

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

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

كيف يفشل

حدود معدل واجهة برمجة التطبيقات (API rate limits). خمسة عشر وكيلاً متزامناً يستهلكون 150 طلباً في الثانية عندما يكون حدك الأقصى هو 100 طلب. يكون كل وكيل ضمن الحدود الفردية، لكن الحمل الجماعي يتجاوز القدرة الاستيعابية.

تتوسع حالات تضارب البيانات (Race conditions) على الحالة المشتركة بشكل تربيعي. فأنظمة تحتوي على عدد N من الوكلاء لديها N(N-1)/2 من التفاعلات المتزامنة المحتملة. عند وجود خمسة وكلاء، فهذا يعني 10 نزاعات محتملة، وعند وجود عشرة وكلاء، يرتفع الرقم إلى 45 نزاعاً.

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

4. مناظرة الوكلاء المتعددين (Multi-agent debate)

يشارك وكلاء متعددون في محادثة مشتركة، ويقدمون وجهات النظر، ويتحدون بعضهم البعض، ويصقلون مواقفهم عبر جولات متعددة. يتضمن ذلك حلقات "الصانع والمدقق" حيث يقوم وكيل واحد بالإنشاء وآخر بالتحقق من الصدق حتى تتم الموافقة.

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

وهناك بديل عملي: استخدام نموذج سريع ورخيص لـ "الصانع" ونموذج قادر وذكي لـ "المدقق". وبذلك تحصل على تحسين الجودة الناتج عن المناظرة بتكلفة أقل بنسبة 40-60% من تشغيل كلا النموذجين على إصدارات عالية القدرة.

كيف يفشل

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

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

5. التسليم الديناميكي (Dynamic handoff)

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

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

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

كيف يفشل

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

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

6. التخطيط التكيفي (Adaptive planning)

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

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

توثق Microsoft مثالاً لـ SRE: يضع المدير خطة أولية، ويستشير وكلاء التشخيص والبنية التحتية، وعندما يكشف التشخيص عن مشكلة في قاعدة البيانات بدلاً من مشكلة في النشر، تتغير الخطة بأكملها في الوقت الفعلي.

كيف يفشل

البطء في الوصول إلى نقطة التقاء وتوافق؛ حيث يركز هذا النمط على دقة النتائج على حساب السرعة، وبالتالي لا يتناسب مع المهام الحساسة للوقت.

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

كيف تختار النمط المناسب

ابدأ بأبسط نمط يناسب مشكلتك، فمعظم الفرق تبالغ في تعقيد الهندسة المعمارية.

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

هل ترغب في خطوات خطية ثابتة؟ المسار التسلسلي. الترتيب لا يتغير أبداً وتعتمد كل خطوة على مخرجات الخطوة السابقة.

هل العمل متوازٍ ومستقل؟ توزيع المهام وتجميعها. أربع مهام أو أكثر دون وجود تبعيات بينها.

هل تحتاج إلى التحقق من الجودة؟ مناظرة الوكلاء المتعددين. وخاصة حلقات "الصانع والمدقق" حيث تهم الدقة أكثر من السرعة.

هل التوجيه غير متوقع؟ التسليم الديناميكي. لا يمكنك معرفة المتخصص المطلوب حتى تتكشف خيوط المحادثة.

هل تواجه مشكلة مفتوحة؟ التخطيط التكيفي. يجب اكتشاف الخطة نفسها، وليس فقط تنفيذها.

وجد مختبر Princeton NLP أن وكيلاً واحداً عادل أو تفوق في الأداء على أنظمة الوكلاء المتعددين في 64% من المهام المعيارية عند تزويده بنفس الأدوات والسياق. ويضيف نظام الوكلاء المتعددين 2.1 نقطة مئوية من الدقة بضعف التكلفة تقريباً. وتعد هذه المقايضة مجدية للعمل المعقد عابر المجالات. أما بالنسبة لأي شيء آخر، فإن بناء AI agent واحد بشكل جيد يعد أبسط، وأسرع، وأرخص.

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