أنظمة الوكلاء المتعددين (Multi-Agent): متى تحتاج فريق وكلاء بدل وكيل واحد؟

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

وش يعني Multi-Agent ببساطة؟

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

مثال واقعي: تحليل المنافسين

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

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

متى يستحق التعقيد؟

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

ومتى يكون مبالغة؟

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

مشاكل لازم تحسب حسابها

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

نصيحة التصميم

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

خطوات البدء عملياً

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

وخلّ وكيل الكتابة أو النشر آخر حلقة، ومعه موافقة بشرية في البداية. الوكلاء اللي يجمعون ويحللون أخطاؤهم تبقى داخلية، أما اللي ينشر أو يرسل للعملاء فغلطته تطلع للعلن. ومع الوقت، لما تثبت الجودة، تقدر تخفف المراجعة على المراحل الموثوقة.

في منصة أزهل الرقمية بنينا وكلاء على n8n منها بوت لتحليل المنافسين ووكيل لإدارة حساب X. لو عندك مسار عمل تحس إنه أكبر من وكيل واحد، تواصل معنا على واتساب ونساعدك تحدد: هل تحتاج فريق وكلاء فعلاً، أو وكيل واحد بتعليمات أنظف.