في المرة الأولى التي استخدمت فيها وكيلاً فرعياً، أسأت استخدامه. شغّلت واحداً لإعادة تسمية متغير. متغيّر واحد. كان الأمر أشبه بتوظيف مقاول لتغيير مصباح — أبطأ، وأكثر تكلفةً، وبدا سخيفاً نوعاً ما. لذا قبل أن أريك كيف تُعدّ وكيلاً فرعياً في Claude Code، دعني أكون صريحاً بشأن متى لا ينبغي لك فعل ذلك.
الوكيل الفرعي هو نسخة منفصلة من Claude يمكن لجلستك الرئيسية أن تُسنَد إليها مهمة. يحصل على نافذة سياق خاصة به — لوح أبيض نظيف — يُنجز المهمة، ثم يعود بملخص. الكلمة المفتاحية هي منفصل. عمل الوكيل الفرعي لا يزحم محادثتك الرئيسية. يستكشف، ويتصفح عشرة ملفات، وجلستك الرئيسية لا ترى إلا الخلاصة.
هذا هو الهدف الكامل للوكلاء الفرعيين، ولهذا السبب يسيء معظم المبتدئين استخدامهم.
متى يُفيد الوكلاء الفرعيون فعلاً
يُفيدون حين تكون المهمة ستملأ سياقك الرئيسي بأشياء لا تحتاج إلى الاحتفاظ بها.
فكّر في البحث في قاعدة كود كبيرة عن "أين نتعامل مع المصادقة؟" بدون وكيل فرعي، يقرأ Claude خمسة عشر ملفاً في محادثتك الرئيسية، وتجلس تلك الملفات في السياق لبقية الجلسة، تستهلك التوكنات في كل دور. مع وكيل فرعي، يجري ذلك الاستكشاف في نافذة مؤقتة. يعود إليك بـ"المصادقة موجودة في src/auth/، وهكذا يجري تدفقها" — ثلاث جمل بدلاً من خمسة عشر ملفاً.
إذن: يستحق الوكلاء الفرعيون مكانهم حين يكون العمل استكشافياً (قراءة كثيرة، خلاصة صغيرة) أو متوازياً (عدة أشياء مستقلة في آنٍ واحد). البحث، والتحقيق، وتشغيل جناح اختبارات كبير وتلخيص الإخفاقات، ومراجعة diff مقابل قائمة تحقق — هذه كلها حالات مثالية.
هذا هو الاختبار الذي أستخدمه الآن. اسأل نفسك: هل ستقرأ هذه المهمة كثيراً لتنتج القليل؟ إذا كانت الإجابة نعم، فاستخدم وكيلاً فرعياً. إذا كانت المهمة تعديلاً مباشراً ترى بالفعل كيف تجريه، افعله مباشرةً. إعادة تسمية متغير لا تقرأ شيئاً وتُنتج تغييراً دقيقاً. لا حاجة لوكيل فرعي.
متى لا تستخدمهم
لا تستخدم وكيلاً فرعياً لتعديل ملف واحد تفهمه. لا تستخدمه للعمل التسلسلي حيث تعتمد كل خطوة على رؤية السابقة. ولا تستخدمه فقط لأنه يبدو متطوراً. لكل وكيل فرعي عبء — يبدأ التشغيل، يبني سياقه الخاص، يعود بالتقرير. بالنسبة للأعمال الصغيرة، يكلّف هذا العبء أكثر مما يوفر.
تتسم نماذج Claude الأحدث أيضاً بتحفّظ واضح في إنشاء وكلاء فرعيين من تلقاء نفسها، وهذا عادةً صحيح. إذا كنت تريد التفويض، فغالباً ما تضطر إلى طلبه صراحةً أو إعداده. وهنا يأتي سؤال الكيفية.
إعداد وكيل فرعي مخصص
يتيح لك Claude Code تعريف وكلاء فرعيين مسمّيين كملفات. ضع ملف markdown في .claude/agents/ بمشروعك (أو في إعداداتك الرئيسية للاستخدام العام). إليك واحداً حقيقياً أستخدمه لمراجعة الكود:
---
name: reviewer
description: Reviews a diff for bugs and missing edge cases. Use after writing code, before committing.
tools: Read, Grep, Bash
---
You are a focused code reviewer. Given a diff or a set of changed files:
1. Read the changed code and the files it touches.
2. Look for actual bugs — off-by-one, null handling, wrong async behavior.
3. Check for missing edge cases and untested paths.
4. Report findings as a short list, each with a severity (high/medium/low).
Don't rewrite the code. Don't nitpick style. Report what you find and stop.
ثمة أشياء تستحق الإشارة إليها. سطر description ليس زينةً — إنه الطريقة التي يقرر بها Claude متى يُفوّض إلى هذا الوكيل. اكتبه كما تكتب وصف أداة: قل متى تلجأ إليه، لا فحسب ما يفعله. "استخدم بعد كتابة الكود، قبل الـ commit" يمنح Claude محفزاً ملموساً.
سطر tools يُحدد ما يمكن للوكيل الفرعي لمسه. مراجعي يحصل على Read وGrep وBash — يكفي للفحص وتشغيل الاختبارات، لا شيء للتعديل. هذا مقصود. لا ينبغي للمراجع أن يُغيّر كودك. تضييق قائمة الأدوات يُبقي الوكيل الفرعي في مساره، وهو أمر أقل تقلق بشأنه.
الجسم هو موجّه النظام للوكيل الفرعي — شخصيته الكاملة ومهمته. لاحظ أنه محدد ومقيّد. "أبلّغ عما تجد ثم توقف" مهم، لأن الوكيل الفرعي الحماسي خلاف ذلك يبدأ في إصلاح الأشياء، وفجأة تجد لديك تغييرات لم تطلبها.
طريقة الاستخدام
بمجرد وجود الملف، يمكنك استدعاؤه في جلسة:
استخدم الوكيل الفرعي reviewer على آخر commit لديّ.
يُطلقه Claude، يُنجز الوكيل الفرعي قراءته وتقريره في سياقه الخاص، وتحصل على قائمة نظيفة من النتائج — دون أن تهبط خمسة عشر ملفاً في محادثتك الرئيسية. للاستكشاف، لا تحتاج حتى إلى ملف مخصص؛ الوكيل الفرعي العام المدمج يُعالج مهام "اذهب واكتشف X" بشكل جيد.
التحوّل الذهني
هذا ما جعل الوكلاء الفرعيين أخيراً منطقيين بالنسبة لي. توقف عن التفكير فيهم باعتبارهم "Claude أقوى". إنهم ليسوا أذكى. إنهم طريقة للحفاظ على نظافة سياقك الرئيسي بإرسال العمل الفوضوي إلى مكان آخر.
بمجرد أن ترى الأمر بهذه الطريقة، تُجيب على سؤال متى الاستخدام من تلقاء نفسها. عمل فوضوي، كثيف القراءة، غير قابل للاحتفاظ؟ فوّضه. عمل دقيق تستطيع تصوّره بالفعل؟ افعله. مراجع يُشغّل اختباراتك ويُسلّمك قائمة نتائج — رائع. مقاول لتغيير مصباح — ليس بالقدر نفسه.
اكتب وكيلاً فرعياً واحداً هذا الأسبوع. اجعله المراجع أعلاه. شغّله على commit قادم. ستشعر حينئذٍ بالفارق، وستعرف تماماً متى تلجأ إلى التالي.