متى تستخدم sub agents ومتى تتجنبها
في Claude Code توجد أداة Agent تتيح لك تشغيل وكيل فرعي مستقل أثناء المحادثة لتنفيذ مهمة معينة. يعمل الوكيل الفرعي في سياق خاص به، وعند الانتهاء يعيد النتائج إلى الوكيل الرئيسي.
يبدو هذا قوياً، لكن من واقع الاستخدام، لن تحتاجه في أغلب الحالات. هذه المقالة توضح: متى يكون فصل المهام إلى وكلاء فرعيين مفيداً فعلاً، ومتى يكون مجرد تعقيد بلا فائدة.
لا يمكنك استدعاء أداة Agent مباشرة من CLAUDE.md أو من أوامر slash — بل يقرر Claude Code بنفسه متى يستخدمها. لكن يمكنك التأثير على قراره من خلال التوجيهات (prompts).
طريقة العمل:
الخصائص الأساسية:
- سياق مستقل: لا يرى الوكيل الفرعي تاريخ المحادثة الرئيسية — فقط الـ prompt الذي أُطلق به
- ضغط النتائج: مهما كان عدد الملفات التي قرأها أو الأوامر التي نفذها، ما يعود للوكيل الرئيسي هو ملخص فقط
- التنفيذ المتوازي: يمكن تشغيل عدة وكلاء فرعيين في آنٍ واحد
هذا هو السيناريو الأكثر شيوعاً. تطلب من Claude Code التحقيق في مشكلة تتطلب البحث في عدة اتجاهات في الوقت نفسه.
مثلاً تسأل: "كيف يعمل نظام المصادقة في هذا المشروع؟"
بدون وكلاء فرعيين، سينفذ Claude Code بالتتابع: يقرأ auth controller ← يقرأ middleware ← يقرأ routes ← يقرأ model ← يقرأ config… خطوة بخطوة، ببطء.
بالتقسيم إلى وكلاء فرعيين:
تشغيل 3 وكلاء فرعيين بالتوازي:
- الوكيل 1: فحص منطق المصادقة في طبقة controller و middleware
- الوكيل 2: فحص تصميم المستخدمين والجلسات في طبقة model
- الوكيل 3: فحص إعدادات المصادقة في ملفات التكوين ومتغيرات البيئة
ثلاثة اتجاهات تعمل بالتوازي، ثم تُجمع النتائج. يمكنك توجيه ذلك في CLAUDE.md:
## مهام الاستقصاء
عند التحقيق في مسألة تمتد عبر عدة وحدات، أطلق وكلاء فرعيين بالتوازي
لتقصّي كل جزء، ثم اجمع الاستنتاجات.
نافذة السياق في Claude Code محدودة. إذا كانت مهمة فرعية تتطلب قراءة كمية كبيرة من الملفات لكن الناتج النهائي مجرد استنتاج واحد، فإن الوكيل الفرعي يحجب "نفايات المعالجة" خارج السياق الرئيسي.
أمثلة نموذجية:
ما يميز هذه المهام: المدخلات كبيرة والمخرجات صغيرة. يهضم الوكيل الفرعي الكم الهائل من المعلومات ويعيد الخلاصة فقط.
بعض المهام لا تكون متأكداً من نتائجها. باستخدام وكيل فرعي مع معامل isolation: "worktree"، يعمل في git worktree مستقل. حتى لو أفسد شيئاً، لن يؤثر على مجلد عملك الحالي.
## إعادة الهيكلة عالية المخاطر
للمهام التي تتضمن إعادة هيكلة واسعة النطاق، استخدم وكيلاً فرعياً
مع عزل worktree. تحقق من صحة النتائج قبل الدمج.
حالات مناسبة:
- إعادة هيكلة استكشافية: لست متأكداً من نجاح نهج معين، دع الوكيل الفرعي يجرّب أولاً
- مقارنة حلول متوازية: تنفيذ طريقتين في الوقت نفسه ومقارنة النتائج
- توليد الشيفرة: إنشاء كميات كبيرة من الشيفرة النمطية، ومراجعتها قبل الدمج
"غيّر اسم هذه الدالة من camelCase إلى snake_case" — هذا النوع يُنفَّذ مباشرة. تكلفة تشغيل وكيل فرعي (بناء السياق، انتظار العودة، تحليل النتائج) أبطأ من التنفيذ المباشر.
معيار الحكم: إذا كان Grep واحد + Edit واحد كافيين، لا تُقسّم إلى وكلاء.
"اقرأ التكوين ← عدّل الشيفرة بناءً عليه ← حدّث الاختبارات بناءً على التعديلات"
هذا النوع من المهام المتسلسلة حيث كل خطوة تعتمد على سابقتها. لو قسّمتها إلى وكلاء فرعيين، ستحتاج لتمرير النتائج الوسيطة عبر prompts، وهذا معقد وعرضة لفقدان المعلومات. التنفيذ التسلسلي هو الأنسب.
ما يعيده الوكيل الفرعي هو نص ملخص، وليس بيانات منظمة. إذا كنت تحتاج تعديلاً دقيقاً (مثل إدراج شيفرة محددة في السطر 47)، فالوكيل الرئيسي أكثر موثوقية.
الوكلاء الفرعيون مناسبون لـ"البحث ثم تقديم الاستنتاج"، وليسوا مناسبين لـ"تنفيذ تعديلات دقيقة".
إذا كانت المحادثة في بدايتها ونافذة السياق لا تزال فارغة، لا داعي لتقسيم المهام بحجة "حماية السياق". انتظر حتى تطول المحادثة ويبدأ الوكيل الرئيسي بضغط الرسائل السابقة، عندها فكّر في استخدام وكيل فرعي للمهام الثقيلة.
لنأخذ سيناريو حقيقياً: التحقيق في جميع الـ controllers التي تستخدم before_action في مشروع Rails، وتحليل أنماط المصادقة والتفويض.
بدون وكيل فرعي:
يقرأ Claude Code ملفات الـ controller واحداً تلو الآخر، وكل ملف يستهلك من السياق الرئيسي. إذا كان هناك 20 controller، فمحتوى الملفات وحده قد يلتهم كمية كبيرة من الـ tokens. وعند تقديم التحليل النهائي، قد تكون التفاصيل السابقة قد ضاعت بسبب الضغط.
مع وكيل فرعي:
تشغيل وكيل فرعي: "اقرأ جميع الـ controllers في app/controllers/،
ابحث عن جميع callbacks من نوع before_action،
حلل أنماط المصادقة والتفويض، وقدم ملخصاً مصنفاً."
يقرأ الوكيل الفرعي جميع الملفات في سياقه الخاص ويعيد ملخصاً نظيفاً. السياق الرئيسي بالكاد يُستهلك، ويمكن للوكيل الرئيسي المتابعة فور حصوله على الاستنتاجات.
لا يمكنك إجبار Claude Code على استخدام أو عدم استخدام الوكلاء الفرعيين، لكن يمكنك التعبير عن تفضيلاتك في CLAUDE.md:
## تفضيلات استخدام الوكلاء
### مهام مناسبة للتقسيم إلى وكلاء فرعيين
- الاستقصاء عبر وحدات متعددة (البحث في أكثر من 3 مجلدات)
- البحث والإحصاء في نطاق واسع من الشيفرة
- إعادة الهيكلة الاستكشافية (مع عزل worktree)
### مهام لا تُقسَّم إلى وكلاء فرعيين
- تعديل ملف واحد
- عمليات متعددة الخطوات بتبعيات تسلسلية
- إصلاح خلل معروف الموقع بالضبط
هل "العملية" في هذه المهمة أكبر بكثير من "النتيجة"؟
إذا نعم — استخدم وكيلاً فرعياً ليهضم العملية ويعيد النتيجة فقط.
إذا لا — نفّذ مباشرة، بلا طبقات وسيطة.
الوكلاء الفرعيون ليسوا أفضل بالكثرة. إنهم أداة لإدارة السياق، وليسوا إطار عمل للبرمجة المتوازية. استخدمهم بشكل صحيح وسيبقى Claude Code متيقظاً في المشاريع الكبيرة، واستخدمهم بشكل خاطئ ولن تكسب سوى هدر وقت التشغيل.