شرح أسراب وكلاء الذكاء الاصطناعي: المخطط، المنفذون، والمدققون

ملخص سريع

تعتمد أسراب وكلاء الذكاء الاصطناعي على تقسيم الهدف الواحد عبر ثلاثة أدوار: المخطِّط الذي يجزئ العمل إلى مهام، والمنفّذون الذين ينجزون هذه المهام بالتوازي داخل مساحات عمل معزولة، والمراجعون الذين يختبرون كل تعديل قبل اعتماده. يُخصَّص النموذج الأقوى لكلٍّ من المخطِّط والمراجع، بينما تتولى النماذج الأسرع والأقل تكلفة مهام التنفيذ. ويفشل هذا النمط عندما يتشارك المنفّذون الملفات نفسها، أو يوافق المراجعون دون تدقيق فعلي، أو يُترك الإنفاق بلا سقف محدد.

لماذا عادت أسراب وكلاء الذكاء الاصطناعي إلى واجهة الأخبار؟

أتاحت Google نموذج Gemini 4 Carbon للاستخدام العام وقدمت معاينة لأمر /swarm في Google Antigravity، والذي يحول توجيهاً واحداً إلى فريق متكامل ومنسق من الوكلاء. وبحسب تعبير Google، يتولى Carbon «التصميم المعماري، والتنسيق، والتدقيق»، مقترناً بـ «نماذج أخف وأسرع تعمل عبر مساحات عمل معزولة ومتوازية، ومراجعين صارمين يختبرون كل تعديل بعين ناقدة».

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

ما هو سرب وكلاء الذكاء الاصطناعي؟

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

وصفت Anthropic هذا النمط في عام 2024 باسم نمط المنسق والعمال (orchestrator-workers pattern): حيث يقوم نموذج مركزي بتفكيك المهمة وتوزيع أجزائها ثم تجميع النتائج. أما دور المراجع فهو الإضافة الأحدث، وهو الدور الذي تتجاهله معظم الفرق.

السرب ليس مجرد «وكلاء كثر يؤدون العمل نفسه»؛ فوجود خمسة وكلاء بالتوجيه نفسه على المستودع البرمجي ذاته يمثل حالة تسابق (race condition) وليس فريق عمل. توزيع الأدوار هو ما يصنع السرب بالفعل. للاطلاع على الصورة الأوسع لكيفية تنسيق الوكلاء، راجع ما هو تنسيق وكلاء الذكاء الاصطناعي.

الأدوار الثلاثة: المخطِّط، والمنفّذون، والمراجعون

يجيب كل دور عن سؤال مختلف، ويتطلب كل منها سياقاً مستقلاً.

ماذا يفعل المخطِّط؟

يحول المخطِّط الهدف العام إلى مهام محددة لا تتداخل فيما بينها. وتحدد الخطة الجيدة الملفات التي يحق لكل مهمة تعديلها، والاختبار الذي يثبت اكتمالها، وترتيب التنفيذ عند وجود تبعيات بين المهام. وإذا تطلبت مهمتان تعديل الملف ذاته، يدمجهما المخطط في مهمة واحدة أو يوجه بتنفيذهما على التوالي.

ماذا يفعل المنفّذون؟

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

ماذا يفعل المراجعون؟

يسعى المراجعون إلى إثبات وجود خلل في التعديلات. والوصف الذي استخدمته Google هنا هو «التحقق الناقد (adversarial)»، وهو وصف دقيق؛ إذ يشغّل المراجع الاختبارات، ويطابق فارق التعديلات مع متطلبات المهمة، ويبحث عن أي حلول مختصرة أو التفافية قد يكون المنفّذ لجأ إليها. فالمراجع الذي يكتفي بالسؤال «هل نجحت الاختبارات؟» سيتغافل حتماً عن منفّذ عدّل الاختبارات نفسها لتنجح زوراً.

لماذا يُسند التخطيط والتدقيق للنموذج الأعلى تكلفة؟

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

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

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

وتؤكد استراتيجية Google هذا التوزيع؛ حيث توضح أن Gemini 4 Argon «يظل الخيار المثالي لغالبية مهام هندسة البرمجيات والعمل المعرفي»، بينما يستهلك Carbon رموزاً أكثر «للاستكشاف الشامل، والاستدلال العميق، وإجراء حلقات تدقيق وتحقق مطولة». تبلغ تكلفة Carbon دولارين لكل مليون رمز مدخلات و10 دولارات لكل مليون رمز مخرجات حتى 30 نوفمبر 2026، ثم ترتفع إلى 4 دولارات و20 دولاراً. لتفاصيل أكثر حول النماذج، اقرأ Gemini 4 Carbon لوكلاء البرمجة وGemini 4 Argon لوكلاء البرمجة. وينطبق المنطق نفسه على أي نموذجين تختارهما؛ انظر فرق العمل (Crews) متعددة النماذج بمنفّذين اقتصاديين ومراجع متقدم.

مواطن الخلل في أسراب وكلاء الذكاء الاصطناعي

تنجم معظم إخفاقات الأسراب عن ثلاث ثغرات أساسية: تداخل الحالة المشتركة (shared state)، وضعف آليات التدقيق، وغياب سقف للميزانية.

لماذا يلغي الوكلاء تعديلات بعضهم البعض؟

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

لماذا يوافق المراجعون بصورة شكلية دون تدقيق؟

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

كيف تتفاقم تكاليف السرب وتخرج عن السيطرة؟

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

وثمة خلل رابع يختبئ وراء ما سبق: إذا وُضعت الخطة وسجلات التشغيل والقرارات في نافذة سياق واحدة (context window)، فلن يتمكن أحد من تدقيق النتيجة. لا بد من وجود جهة رقابية من خارج السرب لمتابعة مسار العمل.

كيف تشغّل سرب وكلاء ذكاء اصطناعي عبر لوحة مهام مشتركة

لا تحتاج إلى أداة مخصصة لإدارة السرب؛ فكل ما يلزمك هو مهام محددة، ومساحات عمل معزولة، وبوابة مراجعة (gate). توفر لك لوحة المهام المشتركة هذه العناصر الثلاثة، وتحتفظ بسجل واضح يمكن للبشر الاطلاع عليه ومتابعته.

1. أنشئ مهمة رئيسية واحدة للهدف العام. يقرأ المخطط هذه المهمة ويصيغ الخطة في صورة مهام فرعية، مع تحديد ملفات كل مهمة واختبار القبول الخاص بها.
2. أسند لكل منفّذ مهمة واحدة فقط. مهمة واحدة، لوكيل واحد، على فرع عمل واحد. وإذا اشتركت مهمتان فرعيتان في ملف واحد، فاجمعهما في مهمة واحدة قبل أن يبدأ أي طرف بالعمل.
3. شغّل كل مهمة في مجلد مستقل خاص بها. يضمن استخدام worktree مستقل لكل تشغيل الفصل التام بين التعديلات المتوازية.
4. أضف حالة «قيد المراجعة» (Review) قبل حالة «مكتمل» (Done). لا تُنقل أي مهمة إلى «مكتمل» بناءً على تأكيد المنفّذ بمفرده.
5. أسند المراجعة إلى وكيل تدقيق يعتمد على نموذج أقوى. يقرأ الوكيل فارق التعديلات ومخرجات الاختبار، ثم يعتمد المهمة أو يعيدها مع بيان سبب الرفض.
6. اجعل المراجع البشري هو الخطوة الأخيرة. يقلص وكيل المراجعة قائمة الفحص، ويتولى الإنسان الاعتماد النهائي.

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

يحصل الوكلاء الذين يعملون بنمط دليل العمل المؤقت (working-directory mode) على مجلد معزول لكل مهمة، كما يمكن لعمليات التشغيل المرتبطة بمستودعات الكود تجهيز worktree جديد ونظيف، بحيث لا يتشارك المنفّذون المتوازيون الملفات نفسها. ويعمل كل وكيل على بيئة التشغيل (Runtime) التي تحددها له، وهو ما يتيح تشغيل القائد والمراجع بنموذج أقوى من نموذج المنفذين.

تُمثَّل بوابة المراجعة بحالة معتمدة في مسار عمل المهام الخاص بك. يستطيع الوكيل وضع المهمة في انتظار المراجعة البشرية، وتظهر عملية التسليم هذه في وحدة محادثات المهام (Task Chats) في الشريط الجانبي الرئيسي، كما توضح وثائق تنفيذ مهام الوكلاء. وتصل عمليات التشغيل الفاشلة أو المتعثرة مباشرةً إلى صندوق الوارد (Inbox). يبحث الوكلاء وينفذون ويختبرون ويرفعون التقارير، في حين يتولى البشر تحديد الاتجاه، ومنح الصلاحيات، واعتماد النتائج. بدء استخدام Sharkly مجاني تماماً: اربط جهاز كمبيوتر واحداً، وأنشئ وكيلين، وأسند مهمة بسيطة لفريق عمل (Crew). للمزيد حول الدور البشري، راجع تصميم المراجعة للوكلاء المتوازيين.

متى تستغني عن سرب وكلاء الذكاء الاصطناعي؟

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

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

خاتمة

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

الأسئلة الشائعة

ما الفرق بين سرب الوكلاء وتنسيق الوكلاء المتعددين؟

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

كم عدد الوكلاء الذين ينبغي أن يضمهم سرب الذكاء الاصطناعي؟

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

هل يمكن أن يكون المخطط والمراجع هو الوكيل نفسه؟

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

هل أحتاج إلى Google Antigravity لتشغيل سرب من الوكلاء؟

كلا، يُعد أمر /swarm مجرد معاينة تجريبية داخل Antigravity، في حين لا يتطلب النمط بحد ذاته سوى تقسيم المهام، ومساحات عمل معزولة، وخطوة للمراجعة. يمكنك بناء ذلك باستخدام git worktrees ولوحة مهام عادية، مع أي وكلاء برمجة تعتمد عليهم حالياً.

ما الذي يمنع منفذي السرب من تعديل الملف ذاته؟

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