هندسة الوكلاء المتعددين: التقسيم الأعمى سيأتي بنتائج عكسية

“هل تقسيم وكيلي إلى عدة وكلاء سيجعله أذكى؟”

الإجابة: “الأمر يعتمد على السياق.” أبحاث Anthropic تُظهر أن الأنظمة متعددة الوكلاء تتفوق على الوكيل الواحد بنسبة 90% - لكن فقط عند اختيار البنية المناسبة. في الواقع العملي، تتفاوت الفجوات في الأداء بشكل كبير بحسب طبيعة المهمة التي تحاول حلها.

إليكم ثلاثة سيناريوهات واقعية تكشف متى يُحقق كل نمط قيمة فعلية.

الأنماط الأربعة باختصار

قبل الخوض في التفاصيل، ملخص سريع للبنى المتاحة:

• Subagents (الوكلاء الفرعيون): وكيل رئيسي يستدعي وكلاء متخصصين كأدوات. قوي في التنفيذ المتوازي، لكن كل نتيجة يجب أن تعود عبر الوكيل الرئيسي
• Skills (المهارات): وكيل واحد يُحمّل تعليمات متخصصة حسب الطلب. خفيف الوزن، لكن السياق يتراكم مع مرور الوقت
• Handoffs (التسليم): يُستبدل الوكيل النشط عند كل مرحلة. مصمّم لسير العمل التسلسلي، لكنه لا يدعم التنفيذ المتوازي
• Router (الموجّه): يُصنّف الاستعلامات، يوزّعها بالتوازي، ويجمع النتائج. عديم الحالة - لا يحتفظ بأي سياق محادثة

لنرَ الآن كيف يتصرف كل نمط في سيناريوهات حقيقية.

السيناريو الأول: الطلبات المنفردة

تخيّل أن المستخدم يقول “اشترِ لي قهوة” - طلب واحد يستطيع وكيل متخصص تنفيذه عبر أداة buy_coffee.

مقارنة الأداء:

• Subagents: 4 استدعاءات (رئيسي ← فرعي ← تنفيذ الأداة ← العودة للرئيسي ← الاستجابة)
• Skills / Handoffs / Router: 3 استدعاءات (تنفيذ مباشر)

الخلاصة الجوهرية: الطلبات المنفردة لا تحتاج إدارة حالة، لذا فإن Skills وHandoffs وRouter هي الأكثر كفاءة. Subagents تُضيف رحلة ذهاب وعودة إضافية عبر الوكيل الرئيسي، وهذا يتحوّل مباشرة إلى تأخير في الاستجابة. بالنسبة للمهام البسيطة، لا داعي لاستخدام بنية متعددة الوكلاء أصلاً.

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

السيناريو الثاني: الطلبات المتكررة

الآن يقول المستخدم “اشترِ لي قهوة أخرى” - نفس الطلب يتكرر. السياق التحادثي يُنقل من الجولة السابقة.

مقارنة الأداء (الجولة الثانية):

• Subagents: 4 استدعاءات ← 8 إجمالاً (عديم الحالة، دورة كاملة في كل مرة)
• Skills / Handoffs: استدعاءان ← 5 إجمالاً (تخفيض 40%)
• Router: 3 استدعاءات ← 6 إجمالاً (تخفيض 25%)

الخلاصة الجوهرية: الأنماط التي تحتفظ بالحالة مثل Skills وHandoffs تتفوق بوضوح هنا. تُعيد استخدام السياق المُحمّل سابقاً وتتخطى خطوات التوجيه والتهيئة بالكامل. Subagents، المصمّمة لتكون عديمة الحالة، تُكرر الدورة الكاملة في كل مرة. المقابل هو أن Subagents توفر عزلاً أفضل للسياق - وهذا يستحق التكلفة الإضافية إذا كانت الأولوية للأمان أو العزل.

في الممارسة العملية: روبوتات المحادثة، والمساعدات التفاعلية، والخدمات القائمة على الجلسات تحتاج أنماطاً تحتفظ بالحالة. إذا كان المستخدمون يقولون أشياء مثل “افعل نفس الشيء كالمرة السابقة”، فالأولوية لـ Skills أو Handoffs. يمكن تغليف Router داخل وكيل يحتفظ بالحالة كأداة عند الحاجة.

السيناريو الثالث: الاستعلامات متعددة المجالات

يسأل المستخدم “قارن Python مع JavaScript مع Rust” - استعلام يمتد عبر مجالات متخصصة متعددة. لنفترض حوالي 2,000 رمز من الوثائق المرجعية لكل لغة.

مقارنة الأداء:

• Subagents: 5 استدعاءات، حوالي 9 آلاف رمز (كل فرعي يعمل في سياق معزول)
• Skills: 3 استدعاءات، حوالي 15 ألف رمز (سياقات المهارات الثلاث تتراكم في الوكيل الرئيسي)
• Handoffs: أكثر من 7 استدعاءات، أكثر من 14 ألف رمز (تنفيذ تسلسلي فقط)
• Router: 5 استدعاءات، حوالي 9 آلاف رمز (تنفيذ متوازٍ)

الخلاصة الجوهرية: الأنماط التي تدعم التنفيذ المتوازي - Subagents وRouter - تتفوق بشكل حاسم. Subagents تعالج وثائق كل لغة في سياقات معزولة، مستخدمةً 67% رموزاً أقل مقارنة بـ Skills (9 آلاف مقابل 15 ألف). Skills تُجري استدعاءات أقل لكنها تُكدّس معرفة المجالات الثلاثة في السياق الرئيسي، مما يرفع تكلفة الرموز بشكل كبير. Handoffs، المقيّدة بالتنفيذ التسلسلي، هي الخيار الأسوأ لهذا النوع من العمل.

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

دليل اختيار النمط المناسب

السيناريو	النمط الموصى به
مهام منفردة	وكيل واحد يكفي
طلبات متكررة	Skills أو Handoffs
مجالات متعددة تُستعلَم في وقت واحد	Subagents أو Router
سير عمل تسلسلي	Handoffs

نصيحة عملية أخيرة

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

الدرس المستفاد من أبحاث Anthropic ليس “وكلاء أكثر = أداء أفضل.” بل إن البنية الصحيحة للمهمة الصحيحة هي ما يُحقق تحسناً بنسبة 90%.