تصف جوجل الآن نمط "السرب" (Swarm) للوكلاء المتعددين بأنه التصميم الأكثر قوة — والأكثر تكلفة — للأنظمة المدفوعة بالذكاء الاصطناعي. يجب على المطورين الذين يبنون مساعدين لتصميم المنتجات أو مساعدين للبحث موازنة التكلفة الباهظة وزيادة زمن الاستجابة مقابل الوعد بنقاش أغنى وذاتي التنظيم بين الوكلاء المستقلين.
ماذا يفعل نمط السرب فعلياً
في السرب، يتحدث كل وكيل متخصص مباشرة مع كل وكيل آخر. يستبدل هذا النمط المنسق المشرف الواحد بشبكة مسطحة من الأقران الذين ينقدون المهام ويصقلونها ويسلمونها لبعضهم البعض. يقوم موزع مهام (dispatcher) خفيف الوزن ببدء العملية ولكنه لا يملي المحادثة؛ حيث يقرر كل وكيل ما إذا كان سيستمر في العمل على مقترح ما أو يمرره إلى قرين موثوق. والنتيجة هي حوار شامل (all-to-all) يبرز وجهات نظر قد يغفل عنها مدير واحد.
كيف يختلف عن المنسق التقليدي
يجلس المنسق في قمة الهرم، حيث يقوم بتعيين المهام وجمع النتائج. أما السرب فلا يوجد فيه رئيس. يتفاوض الوكلاء على الخطوة التالية، ويمكن لأي منهم تولي مهمة فرعية دون انتظار أمر مركزي. تطلق جوجل على هذا الجانب وصف "الأكثر قوة" لأن النظام يستكشف مساحة المشكلة بالتوازي، ويبني باستمرار على رؤى بعضهم البعض.
متى يكون السرب منطقياً
يتألق هذا النمط في المشكلات الغامضة ومتعددة التخصصات حيث يصعب قياس المقايضات. تخيل سير عمل لتصميم منتج يجب أن يوازن بين تجربة المستخدم، والجدوى الهندسية، والقيود المالية. يمكن لباحث ومهندس ومحلل مالي — كل منهم متمثل في وكيل — أن يتجادلوا حول مزايا ميزة ما، ويقترحوا بدائل، ويتوصلوا إلى مواصفات موحدة، وهو أمر قد يجد المنسق الواحد صعوبة في تنظيمه.
متى يجب تجنبه
النقاش بأسلوب السرب يعد مبالغاً فيه للمهام جيدة الهيكلة التي تتبع مساراً واضحاً. إذا كان المشروع يتطلب تكلفة تشغيلية منخفضة، أو سرعة في الإنجاز، أو نقطة توقف محددة، فإن الأعباء الإضافية لهذا النمط ستفوق فوائده بسرعة. فكثرة المحادثات بين الجميع تضاعف استدعاءات النماذج (model calls)، مما يحول أعباء العمل المتواضعة إلى عمليات مكلفة وثقيلة من حيث زمن الاستجابة. وبدون قاعدة خروج واضحة — مثل حد زمني، أو حد أقصى لعدد الأدوار، أو عتبة إجماع — يمكن للحوار أن يستمر إلى ما لا نهاية.
التكاليف الخفية والمخاطر
- التكلفة وزمن الاستجابة – كل تبادل بين الوكلاء يؤدي إلى استدعاء منفصل للنموذج.
- عدم ضمان التقارب – قد يدور الوكلاء في حلقات مفرغة حول نفس الحجج، دون الوصول إلى قرار. يفتقر النظام إلى حكم مدمج لكسر الجمود.
- تعقيد التنفيذ – بناء المنطق الذي يحكم الثقة، وتسليم المهام، وشروط الإنهاء ليس بالأمر الهين. يجب على المطورين صياغة كود تنسيق (orchestration code) متطور فوق نماذج الذكاء الاصطناعي الأساسية.
ثلاث قواعد عملية للمطورين
- حدد شرط الخروج مسبقاً. سواء كان ذلك حداً زمنياً صارماً، أو حداً أقصى لعدد جولات الحوار، أو مستوى إجماع مطلوب، يحتاج النظام إلى إشارة توقف واضحة.
- ضع ميزانية لاستخدام موارد أعلى. توقع أن يستهلك السرب قدرة حوسبة أكبر من أي تصميم يعتمد على المنسق استخدمته من قبل.
- ابدأ بمنسق. إذا كان بإمكان وكيل واحد مبرمج جيداً إنجاز المهمة، فلا يوجد سبب يذكر لإضافة التعقيد الإضافي للسرب.
المقايضة من حيث المنظور
يقول المؤيدون إن قدرة السرب على إبراز الرؤى الخفية والتصحيح الذاتي من خلال نقد الأقران يمكن أن تنتج حلولاً قد يغفل عنها المنسق الواحد. ويشير النقاد إلى التكلفة الباهظة وخطر حلقات الجدال اللامتناهية. هذا النمط ليس ترقية شاملة؛ بل هو أداة متخصصة لمجموعة ضيقة من المشكلات حيث تفوق عمق الاستدلال السرعة والتكلفة.
ما يجب مراقبته لاحقاً
توصي وثائق جوجل الآن بالتعامل مع السرب كخيار ملاذ أخير بعد تقييم الأنماط الأبسط. وحتى ذلك الحين، يجب على المطورين بناء نماذج أولية باستخدام منسق، وقياس الأداء، والانتقال إلى السرب فقط عندما تتطلب تعقيدات المشكلة حقاً جوقة من الوكلاء المتناظرين.
للحصول على الوصف التقني الكامل، راجع دليل جوجل الرسمي لتصميم أنظمة الذكاء الاصطناعي الوكيل (agentic AI system design).