الوحدة 4 — العملية التتابعية والعملية الهرمية

عرّفنا الوكلاء والمهامّ. تبقى قطعة واحدة: كيف يُقرَّر أيّ وكيل يُنفّذ أيّ مهمّة ومتى؟ CrewAI يعرض جوابين رئيسيَّين، Process.sequential وProcess.hierarchical، ولكلّ منهما ثمن وفائدة. الخيار الخاطئ يجعل الفريق مضاعف الكلفة بلا فائدة، أو محدود المرونة بلا سبب.

العملية التتابعيّة: البساطة أوّلًا

Process.sequential تُنفّذ المهامّ بالترتيب الذي كُتبت به في tasks=[...]. كلّ مهمّة تنتظر انتهاء ما قبلها، ويُنقَل مخرَجها إلى ما بعدها إن كانت مدرَجة في context. هذا كلّ شيء.

equipe = Crew(
    agents=[analyste, redacteur, relecteur, responsable],
    tasks=[tache_analyse, tache_redaction, tache_relecture, tache_finale],
    process=Process.sequential,
)

متى نختارها؟

• حين يكون تسلسل العمل معروفًا مسبقًا وثابتًا. تحليل ← كتابة ← مراجعة ← تحكيم مثال مثاليّ.
• حين نُريد تكلفة قابلة للتنبّؤ: عدد النداءات = عدد المهامّ (+ نداءات الأدوات إن وُجدت).
• حين تكون قابليّة إعادة الإنتاج مهمّة: نفس المدخلات تُنتج تقريبًا نفس المسار.

متى نتجنّبها؟

• حين لا نعرف مسبقًا كم مرّة سيحتاج المراجِع إلى إعادة إرسال النصّ للمحرِّر.
• حين تختلف المسارات بحسب المحتوى (وثيقة تقنيّة بحتة ↔ وثيقة تسويقيّة).

العملية الهرميّة: مدير يُوزّع

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

equipe = Crew(
    agents=[analyste, redacteur, relecteur, responsable],
    tasks=[tache_globale],
    process=Process.hierarchical,
    manager_llm=llm_lourd,
)

لاحظ الاختلاف الجوهريّ: مهمّة واحدة عامّة (مثلًا: «أنتج وثيقة عشر صفحات عن هذا المنتَج») بدل قائمة من أربع مهامّ. المدير هو من يُنشئ مهامّ فرعيّة داخليًّا ويُسندها.

متى نختارها؟

• حين يعتمد المسار على المحتوى: مواصفات ناقصة ← جولات تحليل إضافيّة، مواصفات ممتازة ← كتابة مباشرة.
• حين نريد الحكم في الحلقة: المدير يقرأ اقتراح المراجِع ويقرّر إن كانت التصحيحات جوهريّة أو تجميليّة.
• حين يكون فريق الوكلاء واسعًا (سبعة أو أكثر) بحيث يصعب على المطوّر أن يُصمّم المسار يدويًّا.

متى نتجنّبها؟

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

الفرق في الأرقام

قياس داخليّ على وثيقتنا (10 صفحات، 4 وكلاء) أعطى:

المقياس	تتابعيّة	هرميّة
عدد نداءات النموذج	6	14
مجموع الرموز	12 ألفًا	34 ألفًا
الزمن (بالثواني)	45	118
الكلفة على gpt-4o	0.42 د.أ	1.15 د.أ

الفارق ثلاثة أضعاف. الهرميّة تُبرَّر فقط إن كانت الجودة الإضافيّة أو قابلية التكيّف تستحقّ هذا الفارق. على وثيقة تُنتَج مرّة واحدة، ربّما. على وثائق تُنتَج مئة مرّة يوميًّا، لا.

اختيار العملية للخيط الأحمر

الوحدات 5 و6 و7 تستعمل العملية التتابعيّة، لأنّ مسارها ثابت وقابل للتنبّؤ. الوحدة 9 (تصحيح فريق لا يصل) تحوّل نفس الفريق إلى عملية هرميّة لتُظهر الفرق العمليّ: نُشغّل الحالتَين على نفس المدخلات، ونقارن الآثار.

في المشروع النهائيّ (الوحدة 10) نختار التتابعيّة لأنّ العميل يُريد وثيقة كلّ أسبوع بميزانيّة ثابتة، لا عمليّة إبداعيّة تُدير نفسها.

الفخّ الأشهر: هرميّة على مهمّة بسيطة

مطوّر يبدأ بـProcess.hierarchical لأنّه «يبدو أذكى»، على مسار من ثلاث خطوات معروفة. النتيجة: المدير يُنشئ مهمّة، يستدعي وكيلًا، يقرأ النتيجة، يشكّ فيها، يُعيد الطلب، يُوزّع مرّة أخرى… سبعة نداءات نموذج لعمل كان يحتاج ثلاثة. المسار لا يتحسّن، الكلفة تُضرَب في ضعفين.

قاعدة: ابدأ دومًا بالتتابعيّة. لا تلجأ للهرميّة إلاّ بعد أن تُثبت الحاجة إليها بمقياس ملموس (مسار متغيّر، جودة أعلى قابلة للقياس).

manager_llm والتحكّم في المدير

في العملية الهرميّة، manager_llm يحدّد نموذج المدير. نموذج ضعيف يُوزّع سيّئًا؛ نموذج قويّ جدًّا يُبالغ في المراجعة. توصية: gpt-4o-mini أو claude-3.5-haiku كنقطة انطلاق، ورقّ لاحقًا إن رأيت المدير يُخطئ.

يمكن أيضًا تخصيص تعليمة المدير عبر manager_agent (وكيل كامل بحقول role/goal/backstory) بدل المدير الخفيّ الافتراضيّ. يفيد حين نريد لكل الفريق «مسؤولًا موثّقًا» يظهر في الآثار.

قاعدة قرار

اسأل: «هل أعرف قبل التشغيل أيّ وكيل سيُنفّذ أيّ مهمّة؟» إن كانت الإجابة «نعم» ← تتابعيّة. إن كانت «يعتمد على المحتوى» ← هرميّة، وبميزانيّة زمنيّة ونقديّة إضافيّة.

الخلاصة

• Process.sequential يُنفّذ المهامّ بترتيب صريح؛ بسيط، قابل للتنبّؤ، رخيص.
• Process.hierarchical يضيف مديرًا يُوزّع ديناميكيًّا؛ مرن، لكن أغلى ثلاث مرّات في المتوسّط.
• ابدأ دومًا بالتتابعيّة، ولا تنتقل إلى الهرميّة إلاّ بمقياس يُبرّرها.
• manager_llm يُختار خفيفًا افتراضيًّا، ويُرفَّع فقط إذا رأينا المدير يفشل في التوزيع.