الوكلاء الفرعيون (Subagents) في Claude Code: فريق متخصص داخل جلسة واحدة

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

وش هو الوكيل الفرعي؟

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

ليش هذا مهم؟

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

كيف تعرّف وكيلاً فرعياً؟

الوكيل الفرعي ملف Markdown في مجلد الوكلاء — على مستوى المشروع داخل .claude/agents أو على مستوى المستخدم. في أعلاه ترويسة فيها الاسم، ووصف يحدد متى يُستدعى، واختيارياً قائمة الأدوات المسموحة والنموذج المستخدم. وتحت الترويسة تكتب تعليماته: دوره، طريقة شغله، وشكل النتيجة اللي يرجعها. وتقدر تنشئه بمساعدة الأمر /agents داخل Claude Code.

أمثلة وكلاء يستحقون الإنشاء

• مستكشف الكود: يقرأ فقط، يجاوب على «وين يصير كذا؟» ويرجع مسارات الملفات وسطوراً مختصرة.
• مراجع الكود: يراجع التغييرات الأخيرة ويرجع قائمة مشاكل مرتبة حسب الخطورة.
• مشغّل الاختبارات: يشغّل الاختبارات، يحلل الفشل، ويرجع السبب المرجح بدل آلاف أسطر المخرجات.
• مدقق الواجهة العربية: يفحص اتجاه RTL والنصوص والخطوط في المكونات المعدلة.

وتذكّر إن اختيار الوكيل المناسب يعتمد على وصفه، مثل السكِلات تماماً:

مثل السكِلات، الوكيل الرئيسي يقرر استدعاء الوكيل الفرعي بناءً على وصفه. اكتب الوصف بحيث يوضح نوع المهام بدقة، ولو تبي يُستدعى بشكل استباقي اذكر ذلك صراحةً. وتقدر دائماً تطلبه بالاسم: «استخدم وكيل المراجعة على هالتغييرات».

أخطاء شائعة

• وكيل فرعي لمهمة تحتاج سياق المحادثة كامل — هو ما يشوف محادثتك إلا اللي ينمرر له.
• عدم تحديد شكل النتيجة، فيرجع تقريراً طويلاً يلغي فائدة حماية السياق.
• إعطاء وكيل المراجعة صلاحيات تعديل «احتياطاً».
• إنشاء عشرين وكيلاً بأوصاف متداخلة فيحتار الوكيل الرئيسي بينهم.

وكيل فرعي أو سكِل؟

السكِل يضيف معرفة وطريقة شغل للوكيل نفسه داخل سياقه. الوكيل الفرعي ينقل المهمة كلها لسياق مستقل. لو تبي Claude «يعرف كيف» يسوي شيئاً، سكِل. لو تبي «أحد ثاني» يسويه ويرجع الخلاصة، وكيل فرعي. وممكن تجمعهما: وكيل فرعي يستخدم سكِلاً.

مثال: تعليمات وكيل مراجعة جيد

ترويسة الوكيل تحدد اسمه مثلاً code-reviewer، ووصفه «يراجع التغييرات غير المحفوظة في git بعد إكمال أي ميزة أو إصلاح، ويرجع مشاكل مرتبة حسب الخطورة»، وأدواته للقراءة والبحث وتشغيل git diff فقط. أما جسم التعليمات فيحدد:

• ابدأ بقراءة الـ diff، ثم افتح الملفات المرتبطة لفهم السياق.
• ركّز على: الأخطاء المنطقية، الصلاحيات، التحقق من المدخلات، معالجة الأخطاء، والحالات الحدّية.
• تجاهل ملاحظات التنسيق اللي يتكفل بها المنسّق الآلي.
• لكل مشكلة: الملف والسطر، وش المشكلة، ليش مهمة، واقتراح الإصلاح.
• رتّبها: حرجة، مهمة، تحسين.
• لو ما لقيت مشاكل حرجة، قلها صراحة بجملة واحدة بدل ما تخترع ملاحظات.

البند الأخير أهم مما يبدو: الوكيل المطلوب منه «يراجع» يميل يلاقي شيئاً حتى لو ما فيه. السماح له يقول «ما فيه مشاكل حرجة» يخلي تقاريره أصدق.

عبدالله عبدالرحيم بن سنكر الكندي، مؤسس منصة أزهل الرقمية، أتم دورة Introduction to subagents من Anthropic. ولو تبي أمثلة جاهزة، مكتبة «سكيلز» المجانية على موقع أزهل فيها موارد مفتوحة المصدر تقدر تبدأ منها.