الوكلاء الفرعيون (Subagents): أسند المهام للآخرين، ولا تتحمل كل شيء بنفسك
📚 التنقل في السلسلة: المقال السابق 22 MCP يعلمك كيفية ربط Claude بأدوات خارجية، ليتمكن من الاستعلام في قواعد البيانات، والاتصال بـ GitHub. هذا المقال يغير طريقة التفكير——ليس «إضافة أدوات» إليه، بل يعلمك كيفية إسناد المهام للخارج: الوكيل الفرعي (Subagent)، مساعد متخصص بسياق مستقل، صلاحيات مستقلة، وشخصية مستقلة، يعود إليك بالاستنتاجات فقط بعد إنهاء العمل.
يقال دائماً أن subagent قوي، وهو «الاستخدام المتقدم» في Claude Code. الكثيرون عندما عرفوا هذه الميزة لأول مرة، تحمسوا جداً، وتمنوا تقسيم مهمة واحدة إلى خمسة أو ستة وكلاء فرعيين لتعمل في نفس الوقت، ظناً منهم أن هذا «أكثر احترافية، وأكثر كفاءة».
ولكن لقول الحقيقة: بالنسبة لمعظم الناس البدء بالتقسيم فوراً هو خطأ.
هذا الأمر يحتاج لبعض الوقت من الاستخدام لفهمه. لاحقاً سأشرح بالتفصيل لماذا——لكن سأضع النتيجة هنا أولاً: الوكيل الفرعي ليس «كلما زادت المهام وجب التقسيم»، بل هو أداة لها سيناريوهات استخدام واضحة، استخدامه بشكل صحيح يوفر العناء، واستخدامه بشكل خاطئ يجعله بطيئاً ومكلفاً. التفكير بوضوح في «متى يجب التقسيم» أهم بكثير من تعلم «كيفية التقسيم».
في هذا المقال لن أعلمك فقط كيفية إنشاء وكيل فرعي، وتشغيله، بل الأهم من ذلك مساعدتك في بناء خط التقييم: متى يجب إسناد المهمة للخارج، ومتى يكون القيام بها بنفسك أسرع.
بعد قراءة هذا المقال، ستحصل على:
- ما هو الوكيل الفرعي بالضبط——سياق مستقل، أدوات مستقلة، شخصية مستقلة، شرح مفصل للفرق بينه وبين المحادثة الرئيسية في جملة واحدة
- المشاكل الثلاث التي يحلها حقاً (عزل السياق، التخصص في المهام، وإمكانية التوازي)، والفخ الذي يتعارض مع الإجماع: متى لا يجب التقسيم
- استخدام
/agentsللإنشاء التفاعلي، أو كتابة ملف التكوين.claude/agents/name.mdيدوياً، وما هي وظيفة كل حقل - طريقتان للتشغيل: التفويض التلقائي عبر
descriptionمقابل التحديد المباشر بالاسم - تدريب عملي يمكنك اتباعه وتشغيله، مع مخرجات متوقعة: أنشئ أصغر وكيل فرعي بيدك واجعله يعمل
01 افهم أولاً: ما هو الوكيل الفرعي بالضبط
الخلاصة أولاً: الوكيل الفرعي هو مجرد مساعد متخصص يستأجره Claude مؤقتاً——إنه يعمل في غرفته الخاصة، وبعد الانتهاء يسلمك الاستنتاج فقط، ولا يشغل مساحة مكتبك بكمية المعلومات التي يبحث فيها أثناء العملية.
تشبيه: إسناد مهمة إلى مساعد متخصص. لديك الكثير من المهام، ومن بينها مهمة مثل «ابحث في هذه الألف سطر من السجلات، واستخرج الأسطر التي تحتوي على أخطاء» وهي مهمة مزعجة وتأخذ مساحة، ولا ترغب في القيام بها بنفسك على طاولة عملك الرئيسية——لأن ذلك سيملأ مكتبك. لذا تسندها لمساعد متخصص للقيام بذلك: إنه يقرأ في غرفته الخاصة، وعلى طاولته الخاصة، الألف سطر من السجلات؛ وبعد الانتهاء، لن يجلب لك الألف سطر الأصلية، بل يسلمك ورقة صغيرة فقط: «الأخطاء موجودة في هذه الأسطر الثلاثة فقط، وهي في الأسطر 207، 589، 903». سيبقى مكتبك نظيفاً دائماً.
هذا المساعد يمتلك ثلاثة أشياء «خاصة به»، وهي معزولة تماماً عنك (المحادثة الرئيسية). الوثائق الرسمية تصف ذلك بشكل حاسم، ويستحق التذكر:
يعمل كل subagent في نافذة context window الخاصة به، ويحتوي على موجه نظام مخصص، وصلاحيات وصول محددة للأدوات، وأذونات مستقلة.
بتفصيل ذلك، نجد ثلاثة جوانب «مستقلة»:
| البعد | المحادثة الرئيسية (أنت) | الوكيل الفرعي (المساعد الخارجي) |
|---|---|---|
| السياق | كل التاريخ الذي تحدثت فيه مع Claude | ورقة بيضاء تماماً، يتلقى فقط جملة «إسناد المهمة»، ولا يرى ما تحدثتم عنه سابقاً |
| موجه النظام (الشخصية) | الإعداد الافتراضي لـ Claude Code | الشخصية المخصصة التي كتبتها له، مثل «أنت مراجع شفرة يبحث عن الأخطاء فقط» |
| الأدوات / الصلاحيات | جميع الأدوات التي صرحت بها | يمكن تقليصها، مثل «للقراءة فقط، ولا يُسمح بالكتابة» |
الأهم، والذي يسهل تجاهله هو السطر الأول: يبدأ الوكيل الفرعي من ورقة بيضاء. الوثائق الرسمية تقولها بشكل مباشر——إنه «لا يمكنه رؤية تاريخ المحادثة، أو المهارات التي قمت باستدعائها، أو الملفات التي قرأها Claude بالفعل». سيقوم Claude بكتابة «إسناد المهمة» ورميها إليه، وسيبدأ العمل من تلك الجملة.
هذه النقطة تحدد «ما يبرع فيه الوكيل الفرعي، وما لا يبرع فيه»، وسنعتمد عليها في التقييم في القسم التالي.
💡 ملخص في جملة: الوكيل الفرعي = سياق مستقل + شخصية مستقلة + أدوات مستقلة للمساعد الخارجي، يعمل في غرفته الخاصة، ويعود بالاستنتاجات فقط؛ تذكر أنه يبدأ من ورقة بيضاء، ولا يرى محادثاتكم السابقة.
02 ماذا يحل——والفخ الذي يتعارض مع الإجماع
بعد معرفة «ما هو»، يجب فهم «لماذا يوجد». يحل الوكيل الفرعي بالفعل ثلاث مشاكل، سأتحدث عنها واحدة تلو الأخرى، وفي النقطة الثالثة سأكشف الفخ الذي يتعارض مع الإجماع والمذكور في البداية.
المشكلة الأولى: عزل السياق، لعدم تلويث المسار الرئيسي
هذا هو الاستخدام الأساسي والأكثر قيمة للوكيل الفرعي.
السياق——«طاولة عمل» Claude محدودة، كلما تحدثت معه أكثر وقرأت ملفات أكثر، زحمت الطاولة، وعندما تمتلئ سيبدأ بنسيان الأشياء ويصبح بطيئاً. بعض المهام تستهلك الطاولة بشكل جنوني، لكن المخرجات الوسيطة الناتجة لن تنظر إليها مرة ثانية إطلاقاً.
مثلاً «قم بتشغيل مجموعة الاختبارات بالكامل، وأخبرني بالتي فشلت». تشغيل الاختبارات سيخرج مئات أو آلاف الأسطر، لكن ما تحتاجه حقاً هو جملة واحدة: «فشلت هذه الاختبارات الثلاثة، والخطأ هو XXX». إذا قمت بتشغيلها مباشرة في المحادثة الرئيسية، فإن المئات من الأسطر ستملأ طاولتك.
في هذا الوقت، أسندها للوكيل الفرعي: سيتحمل هو تلك المئات من الأسطر في غرفته، وسيعود إليك بجملة «ما الذي فشل» فقط. ستظل طاولة المحادثة الرئيسية الخاصة بك نظيفة كما كانت. تضع الوثائق الرسمية هذا الاستخدام كواحد من «الاستخدامات الأكثر فعالية» للوكيل الفرعي:
قد تستهلك مهام مثل تشغيل الاختبارات، أو جلب الوثائق، أو معالجة ملفات السجلات قدراً كبيراً من السياق. من خلال تفويض ذلك إلى subagent، يتم الاحتفاظ بالمخرجات المفصلة في سياق الـ subagent، ويتم إرجاع الملخص ذي الصلة فقط إلى محادثتك الرئيسية.
سيناريو حقيقي: عند اختبار SDK لجهة خارجية، يجب عليك تكرار curl الخاص بالـ API الخاص بها لرؤية الاستجابة، وفي كل مرة تخرج شاشة مليئة بـ JSON. بعد بضع عشرات من الجولات، ستمتلئ المحادثة الرئيسية بـ JSON لدرجة نسيان المتطلبات الأصلية. قم بتغيير الطريقة——اجعل وكيلاً فرعياً متخصصاً يذهب إلى «اختبار هذه الواجهة، وأخبرني فقط كيف تبدو الحقول»، وستصبح المحادثة الرئيسية نظيفة فوراً، ولن تنقطع أفكارك.
المشكلة الثانية: التخصص في نوع معين من المهام
الاستخدام الثاني: للمهام التي تتكرر باستمرار، عيّن «شخصاً متخصصاً للقيام بها».
إذا اكتشفت أنك تكرر نفس النوع من التعليمات——بعد كل كتابة للشفرة تطلب من Claude «تولي دور مراجع خبير للبحث عن الأخطاء، وركز على الأمان والتسميات»——فمن الأفضل تثبيت هذه التعليمات كوكيل فرعي، وسمّه code-reviewer، وبعد ذلك يمكنك استدعاؤه بجملة واحدة. الكلمات الأصلية الرسمية: «عندما تقوم باستمرار بإنشاء نفس النوع من العمال واستخدام نفس التعليمات، حدد subagent مخصصاً.»
إنه «متخصص» في مكانين: الأول هو الشخصية الحصرية (مكتوبة بشكل ثابت في موجه النظام «أنت مراجع يبحث عن الأخطاء فقط»)، والثاني هو الأدوات الحصرية (يجب أن يقرأ المراجع فقط ولا يكتب، لذا اقطع عنه Write و Edit، ولن يتمكن من التعديل حتى لو أراد).
المشكلة الثالثة: إمكانية التوازي
الاستخدام الثالث: يمكن إسناد عدة مهام غير مرتبطة ببعضها إلى عدة وكلاء فرعيين لتعمل في نفس الوقت.
مثلاً «ابحث في وحدات المصادقة، وقواعد البيانات، والـ API كل على حدة»——هذه الوحدات الثلاث لا تعتمد على بعضها البعض، لذا افتح ثلاثة وكلاء فرعيين لاستكشافها في نفس الوقت، وفي النهاية سيقوم Claude بتجميع الاستنتاجات الثلاثة لك. التسلسل سيتطلب ثلاث جولات، التوازي ينجزها في جولة واحدة.
الفخ الذي يتعارض مع الإجماع: ليس كلما زاد التقسيم كان أفضل
حسناً، بعد تمهيد الاستخدامات الثلاثة، لنعد إلى الجملة في البداية——لماذا البدء بالتقسيم فوراً هو خطأ؟
لأن المبتدئين عموماً لديهم سوء فهم: «التقسيم الدقيق = أكثر احترافية = أسرع». العكس تماماً. للوكيل الفرعي ثلاثة تكاليف خفية، وبمجرد تقسيم المهام البسيطة، ستظهر جميع التكاليف:
| عنصر المقارنة | المهام البسيطة تتم مباشرة في المحادثة الرئيسية | المهام البسيطة يتم تقسيمها قسراً للوكيل الفرعي |
|---|---|---|
| تكلفة البدء | لا توجد، افتح فمك واعمل | يبدأ الوكيل الفرعي من ورقة بيضاء، ويجب أن يقضي وقتاً في «جمع السياق» لمعرفة الوضع |
| التواصل المتبادل | جملة منك وجملة منه، ويمكن التعديل في أي وقت | إذا لم توضح جيداً يجب إعادة العمل، الوكيل الفرعي لا يرى محادثاتكم السابقة |
| التكلفة | حصة واحدة من الـ token | فتح سياق إضافي = استهلاك المزيد من الـ token، كلما فتحت أكثر استهلكت أكثر |
| إرجاع النتائج | غير موجود | كل وكيل فرعي سيعيد النتائج المفصلة إلى المحادثة الرئيسية، وفتح الكثير منها سيملأ الطاولة مرة أخرى |
قدمت الوثائق الرسمية قائمة تقييم حول «متى تستخدم المحادثة الرئيسية أو الوكيل الفرعي»، ولخصتها في جملة: المهام التي تتطلب التواصل المتكرر، ومشاركة السياق، والتعديلات السريعة الصغيرة، وتهتم بالسرعة، اتركها في المحادثة الرئيسية؛ أما المهام التي تنتج الكثير من المخرجات الوسيطة التي لا تريد رؤيتها، أو التي تحتاج إلى قفل صلاحيات الأدوات، أو التي يمكن أن تحتوي نفسها وتعيد استنتاجاً واحداً فقط، فأسندها للخارج.
كما أشارت الوثائق الرسمية إلى تفصيل يتعارض مع الحدس——الوكيل الفرعي في السيناريوهات التي يهم فيها «الكمون (latency)» يعتبر عيباً:
الكمون مهم. تبدأ Subagents من الصفر، وقد تستغرق وقتاً لجمع السياق.
سيناريو حقيقي: إذا كنت عنيداً، وحتى «تغيير اسم متغير» يتطلب فتح وكيل فرعي، «ليبدو احترافياً». النتيجة؟ سيتعين عليه إعادة قراءة الملف أولاً (لأنه لا يملك سياقك الحالي)، وبعد التعديل البطيء سيعيد النتيجة، وهذا أبطأ بكثير من قول «غيّر اسم هذا المتغير» في المحادثة الرئيسية مباشرة، واستهلك المزيد من الـ token. لذا هناك قاعدة ذهبية تستحق التذكر: المهام التي يمكن توضيحها في جملة واحدة، والتعديلات الموجودة أمامك، لا يتم إسنادها للخارج أبداً.
💡 ملخص في جملة: يحل الوكيل الفرعي ثلاث مشاكل «عزل السياق، التخصص في المهام، وإمكانية التوازي»؛ لكن القيام بالمهام البسيطة مباشرة يكون أسرع وأرخص——التقسيم الكثير ≠ الاحتراف، التقسيم المفرط سيجعل العمل أبطأ وأكثر تكلفة ويعيد ملء الطاولة.
توضح هذه الصورة مفهوم «إسناد المهام للخارج»: المحادثة الرئيسية هي طاولة عملك، حيث ترمي مهمة قذرة ستنتج كمية كبيرة من المخرجات الوسيطة (تشغيل الاختبارات / قراءة السجلات) للوكيل الفرعي؛ يتحمل الوكيل الفرعي جميع التفاصيل في غرفة سياقه المستقلة، وفي النهاية يعود «ملخص الاستنتاج» فقط في سطر واحد إلى المسار الرئيسي، لتبقى طاولتك نظيفة دائماً.
03 كيفية الإنشاء: إنشاء تفاعلي عبر /agents
بعد الحديث عن «متى نستخدمه»، دعنا ننشئ واحداً عملياً. الطريقة الأسهل هي استخدام أمر /agents، وهو تفاعلي بالكامل، ولا تحتاج إلى كتابة كلمة واحدة من التكوين يدوياً.
في محادثة Claude Code اكتب:
/agentsستنبثق واجهة إدارة. لإنشاء واحد جديد، فإن العملية التي توصي بها الوثائق الرسمية هي كالتالي (سأعيد سرد الشرح الرسمي، ويمكنك اتباعه):
- اختر الموقع: انتقل إلى علامة التبويب Library ← Create new agent ← اختر Personal. سيؤدي اختيار Personal إلى حفظه في
~/.claude/agents/، ويمكن استخدامه في جميع المشاريع؛ بينما يؤدي اختيار Project إلى استخدامه في المشروع الحالي فقط، ويمكن إرساله مع git للفريق (الفرق بينهما سيتم شرحه بالتفصيل في القسم التالي). - دع Claude يساعدك في الإنشاء: اختر Generate with Claude، ثم استخدم لغة بسيطة لوصف نوع المساعد الذي تريده. مثلاً: «مساعد لمراجعة الشفرة، يمسح الملفات، ويقدم اقتراحات للتحسين من ثلاث زوايا: سهولة القراءة، الأداء، وأفضل الممارسات، يوضح المشكلة لكل نقطة، ويلصق الشفرة الحالية، ثم يعطي النسخة المحسنة.» سيقوم Claude تلقائياً بكتابة الاسم والوصف وموجه النظام لتحديد الشخصية بالنيابة عنك.
- اختر الأدوات: يجب أن يقرأ المراجع فقط، ولا يكتب، لذا حدد Read-only tools فقط، وألغِ تحديد الباقي. تذكّر الوثائق الرسمية بنقطة حاسمة: «إذا أبقيت جميع الأدوات محددة، فسيرث subagent جميع الأدوات المتاحة للمحادثة الرئيسية.»——إذا لم تقطع الصلاحيات بشكل فعال، فسيتمكن من فعل أي شيء.
- اختر النموذج: اختر له نموذجاً منفصلاً. لمهام المراجعة هذه، تختار الأمثلة الرسمية Sonnet (للتوازن بين القدرة التحليلية والسرعة).
- حفظ: ألقِ نظرة على ملخص التكوين، واضغط
sأوEnterللحفظ، ويمكنك استخدامه فوراً. (في الواجهة الفعلية، سيطلب منك أيضاً اختيار لون الخلفية ونطاق الذاكرة memory scope؛ اللون عشوائي، والذاكرة تكفي على None افتراضياً، يمكن للمبتدئين تخطيه.)
تشبيه: ملء «نموذج طلب وظيفة خارجية». لا تحتاج إلى معرفة كيفية كتابة العقد، مكتب الاستقبال (واجهة /agents) يأخذ النموذج ويسألك بنداً بنداً: ما اسم هذا المنصب، وماذا سيفعل، وما الأدوات التي يمكنه استخدامها، وأي مستوى من الأشخاص تريد——بمجرد أن تملأه، سيكون قد أنشأ هذا «المنصب» لك. Generate with Claude يشبه وجود مدير موارد بشرية (HR) بجانبك يساعدك في ملء النموذج بشكل جميل.
سيناريو حقيقي: هكذا يتم إنشاء وكيل فرعي دائم ذو قيمة كبيرة——test-runner، مخصص لـ «تشغيل الاختبارات، والتبليغ فقط عن الاختبارات التي فشلت + رسائل الخطأ». عند إنشائه، نمنحه Read و Bash فقط عن قصد، ولا نمنحه Write، وذلك خوفاً من أن يتلاعب بشفرتك أثناء التشغيل. أنشئه مرة واحدة، واستخدمه كل يوم بعد ذلك.
💡 ملخص في جملة:
/agentsهي الطريقة الموصى بها لإنشاء وكيل فرعي، فهي تعتمد على ملء النماذج بشكل تفاعلي بالكامل، ويمكنك أن تطلب من Claude إنشاء الشخصية لك؛ تذكر قطع صلاحيات الأدوات بفعالية، وإلا فإنه سيرث جميع الصلاحيات من المحادثة الرئيسية.
04 كيفية الإنشاء: كتابة ملف التكوين يدوياً
بعد الإنشاء التفاعلي، ما يتم حفظه على القرص هو في الواقع ملف Markdown واحد. بمجرد أن تفهم هذا الملف، يمكنك كتابته يدوياً، أو تعديل ملفات الآخرين.
يبدو ملف الوكيل الفرعي هكذا——القسم العلوي عبارة عن ترويسة YAML (frontmatter) تدير التكوين، والنص أدناه هو شخصيته (موجه النظام):
---
name: code-reviewer
description: Reviews code for quality and best practices
tools: Read, Glob, Grep
model: sonnet
---
You are a code reviewer. When invoked, analyze the code and provide
specific, actionable feedback on quality, security, and best practices.تشبيه: إعطاء بطاقة عمل + وصف وظيفي للمساعد الخارجي. ترويسة YAML هي المعلومات الصلبة الموجودة على بطاقة العمل——الاسم، والوظيفة، والأدوات التي يمكنه استخدامها، والمستوى (name/description/tools/model)؛ النص أسفل الخط هو الوصف الوظيفي الذي يتم تقديمه له، «من أنت، وماذا ستفعل عند وصولك، وما هي المعايير التي ستعمل وفقاً لها». عندما يتولى الوظيفة سينظر فقط إلى هذين الأمرين، ولن يرى الفوضى الأخرى في شركتك.
توضح الوثائق الرسمية أنه فقط name و description هما إلزاميان، ويمكن الاستغناء عن الباقي. دعونا نوضح الحقول الشائعة:
| الحقل | إلزامي | الوظيفة | نقاط للمبتدئين |
|---|---|---|---|
name | نعم | معرّف فريد، أحرف صغيرة مع واصلة (مثل code-reviewer) | تجنب تكرار الأسماء في جميع المشاريع، إذا تكررت فسيتم حذف أحدهم بصمت |
description | نعم | إخبار Claude «ما هي المهام التي يجب إرسالها إليه» | كلما كُتب بوضوح أكبر، كان التفويض التلقائي أدق، وهذا هو مفتاح التشغيل |
tools | لا | الأدوات التي يمكنه استخدامها | الإغفال = وراثة جميع الأدوات في المحادثة الرئيسية؛ إذا أردت تحديد الصلاحيات فقم بإدراج قائمة السماح هنا |
model | لا | النموذج المستخدم | sonnet/opus/haiku/inherit، الافتراضي هو inherit (نفس النموذج للمحادثة الرئيسية) |
permissionMode | لا | وضع الصلاحيات الخاص به | الخيارات: default/acceptEdits/auto/dontAsk/bypassPermissions/plan |
مكان وضع الملف مهم، الموقع يحدد «من يمكنه استخدامه». حددت الوثائق الرسمية عدة مستويات، وللمبتدئين يكفي تذكر المستويين الأكثر استخداماً:
| الموقع | من يمكنه الاستخدام | مناسب لـ |
|---|---|---|
~/.claude/agents/ | جميع مشاريعك | مساعد شخصي عام، مثل مراجع شفرة ترغب في استخدامه أينما ذهبت |
.claude/agents/ | المشروع الحالي فقط | مساعد مخصص للمشروع؛ يمكن إرساله مع git ومشاركته مع الفريق |
الاقتراح الرسمي لهذا المستوى الخاص بالمشروع عملي جداً:
Project subagents (
.claude/agents/) تعتبر مثالية لـ subagents الخاصة بقاعدة الشفرة. قم بإضافتها إلى نظام التحكم في الإصدار بحيث يمكن لفريقك التعاون في استخدامها وتحسينها.
آخر فخ سيقع فيه المبتدئون حتماً، استخدمت الوثائق الرسمية ملاحظة (Note) للتذكير به تحديداً——بعد الكتابة اليدوية أو التعديل المباشر للملف على القرص، يجب إعادة تشغيل الجلسة حتى يتم تحميله؛ ولكن الملفات التي يتم إنشاؤها عبر واجهة /agents لا تحتاج إلى إعادة تشغيل ويسري مفعولها فوراً. عند كتابة وكيل فرعي يدوياً لأول مرة، من السهل مواجهة موقف حيث تقوم باستدعائه لفترة طويلة دون استجابة، وتظن أنك كتبت شيئاً خاطئاً، في حين أنك نسيت إعادة التشغيل فقط.
💡 ملخص في جملة: الوكيل الفرعي هو مجرد ملف Markdown، ترويسة YAML تدير التكوين (الإلزامي هو
name/descriptionفقط)، والنص هو الشخصية؛ ضعه في~/.claude/agents/ليكون متاحاً بشكل عام، وضعه في.claude/agents/للمشاركة داخل المشروع؛ تذكر إعادة تشغيل الجلسة عند تعديل الملف يدوياً.
05 كيفية التشغيل: التفويض التلقائي مقابل التحديد المباشر
بعد إنشاء الوكيل الفرعي، كيف نجعله يعمل؟ هناك طريقان: ينظر Claude إلى «الوصف الوظيفي» ويقوم بتوزيع المهام تلقائياً، أو تقوم أنت بتحديده بالاسم مباشرة.
الطريق الأول: التفويض التلقائي الموجه بـ description
تقوم أنت بتقديم طلبك بشكل عادي، وسيأخذ Claude هذه الجملة ويقارنها بـ description الخاص بكل وكيل فرعي، وإذا وجد تطابقاً فسيقوم بإرسال المهمة إليه تلقائياً. لن تحتاج حتى إلى معرفة وجود مثل هذا الوكيل الفرعي.
هذا هو السبب وراء التأكيد المتكرر في القسم السابق على كتابة description بوضوح——إنه الأساس الوحيد الذي يعتمد عليه Claude في توزيع المهام. أعطت الوثائق الرسمية حيلة صغيرة لزيادة «المبادرة»: أضف عبارات مثل «استخدمه بشكل استباقي» (use proactively) في الوصف، وسيكون Claude أكثر استعداداً لتفويضه استباقياً. على سبيل المثال، إذا كان وصف المراجع مكتوباً كـ «المراجعة الاستباقية الفورية بعد كتابة أو تعديل الشفرة»، فبمجرد انتهائك من تعديل الشفرة قد يقوم باستدعاء المراجع بنفسه.
تشبيه: ما إذا كان الوصف الوظيفي مكتوباً بشكل جيد، يحدد ما إذا كان مدير الموارد البشرية سيكلفه بالمهمة الصحيحة. الـ description هو «إعلان التوظيف» لهذا المنصب الخارجي. إذا كان الإعلان غامضاً («التعامل مع بعض المهام»)، فلن يعرف الموارد البشرية (Claude) أي نوع من المهام يجب أن يعهد بها إليه؛ وإذا كان مكتوباً بدقة («مخصص لمراجعة أمان الشفرة والتسميات، والتصرف بشكل استباقي بعد الانتهاء من الشفرة»)، فحينما تأتي المهمة المناسبة سيفكر فيه الموارد البشرية بشكل طبيعي.
الطريق الثاني: التحديد المباشر بالاسم
عندما لا يكون التفويض التلقائي موثوقاً، أو كنت ترغب فقط في تحديد وكيل فرعي معين، قم بتسميته بنفسك. تقدم الوثائق الرسمية عدة طرق من الأسهل للأكثر تعقيداً، وللمبتدئين يكفي تذكر أول طريقتين:
التحديد باللغة الطبيعية——فقط اذكر اسمه مباشرة في الجملة، بدون قواعد تركيب خاصة:
استخدم الوكيل الفرعي code-reviewer لإلقاء نظرة على التغييرات الأخيرةالتحديد بـ @——اكتب @ واختر من القائمة المنبثقة (بعد التحديد سيتم إدخال كتابة بشكل @"code-reviewer (agent)")، ويمكن أيضاً تجاوز القائمة وكتابة @agent- يدوياً متبوعاً بالاسم. هذا «يضمن» استخدامه، ولا يترك حق الاختيار لـ Claude:
@agent-code-reviewer ألقِ نظرة على التغييرات المتعلقة بالمصادقة هذه المرةتشرح الوثائق الرسمية الفرق بينهما بشكل واضح جداً: اللغة الطبيعية تعني «عادةً ما يقوم Claude بالتفويض»، بينما @ تعني «تأكد من تشغيل subagent محدد». العادة الآمنة——للوكلاء الفرعيين الذين تم إنشاؤهم حديثاً ولم تفهم طباعهم بعد، استخدم دائماً @ للتحديد، وذلك لتجنب ألا يقوم Claude بتفويضه من تلقاء نفسه، وتظن أنت أن الوكيل الفرعي معطل.
كيف تعود الاستنتاجات
بغض النظر عن طريقة التشغيل، بعد أن ينهي الوكيل الفرعي عمله، سيعيد فقط «الاستنتاج» إلى المحادثة الرئيسية، وتبقى العملية كلها في غرفته الخاصة. هذا هو بالضبط تحقيق التشبيه في القسم 01: يقرأ المساعد الألف سطر من السجلات، ويعيد فقط ورقة تقول «الأخطاء موجودة في هذه الأسطر الثلاثة». العبارة الرسمية: إنه «يعمل بشكل مستقل ويعيد النتائج»، و«يتم الاحتفاظ بالمخرجات المفصلة في سياق subagent، بينما يعود الملخص ذو الصلة فقط إلى محادثتك الرئيسية».
⚠️ لكن يوجد هنا فخ للكمية، حذرت منه الوثائق الرسمية تحديداً: إذا قمت بفتح العديد من الوكلاء الفرعيين، وكل واحد يعيد كتلة كبيرة من النتائج المفصلة، فإن ذلك سيملأ طاولة المحادثة الرئيسية بنفس القدر. لذا لا تطمع في الكثير من التوازي——بالعودة إلى القاعدة في القسم 02: فقط المهام التي يمكنها احتواء نفسها، وتعيد استنتاجاً واحداً فقط هي التي تستحق أن تسند للخارج.
💡 ملخص في جملة: ينقسم التشغيل إلى طريقين——الاعتماد على
descriptionليقوم Claude بتوزيع المهام تلقائياً (يجب أن يكون الوصف دقيقاً)، أو التحديد بالاسم باستخدام اللغة الطبيعية /@(@يضمن استخدامه)؛ يعيد الوكيل الفرعي فقط الاستنتاجات للمسار الرئيسي، لكن الإرجاع الزائد سيملأ الطاولة بنفس القدر.
06 تدريب عملي: أنشئ أصغر وكيل فرعي في 5 دقائق واجعله يعمل
القراءة وحدها لا تكفي. سأقودك أدناه لكتابة أصغر وكيل فرعي يدوياً، ثم جعله يعمل فعلياً، لتشهد بنفسك مسار «إسناد المهمة ← العودة بالاستنتاج فقط». العملية برمتها لا تعتمد على أي بيئة معقدة.
سننشئ الأبسط: «معلق شفرة» للقراءة فقط، مخصص لقراءة الملفات وإعطاء نصائح للتحسين، لكن لا يُسمح له بتعديل حرف واحد (نعطيه Read فقط، ولا نعطيه Write/Edit).
الخطوة الأولى: أنشئ مشروعاً تجريبياً ودليلاً للوكيل الفرعي (Mac / Linux)
mkdir sub-demo
cd sub-demo
mkdir -p .claude/agentsالمتوقع: في مجلد sub-demo يوجد مستوى دليل .claude/agents/. بكتابة ls .claude سترى وجود agents.
الخطوة الثانية: اكتب ملف تكوين الوكيل الفرعي يدوياً
باستخدام المحرر المفضل لديك، أنشئ sub-demo/.claude/agents/code-reviewer.md وألصق فيه:
---
name: code-reviewer
description: معلق شفرة للقراءة فقط، يقرأ الملف المحدد ويقدم اقتراحات للتحسين من زاوية سهولة القراءة، التسميات، والأخطاء المحتملة. استخدمه بشكل استباقي عند مراجعة أي شفرة.
tools: Read, Grep, Glob
---
أنت مراجع شفرة خبير، تبحث عن الأخطاء فقط، ولا تعدل الشفرة.
عند الاستدعاء:
1. اقرأ الملف الذي حدده المستخدم
2. اذكر المشاكل بناءً على ثلاث فئات: سهولة القراءة، التسميات، الأخطاء المحتملة
3. قدم اقتراحات تحسين محددة لكل مشكلة، لكن لا تقم بتعديل الملف مباشرة
قم بتجميعها حسب درجة الخطورة: يجب التعديل، يُنصح بالتعديل، يمكن التفكير فيه.لاحظ أنه لم يتم إعطاء حقل model هنا——وفقاً للافتراضي الرسمي، سيتم توريثه inherit (نفس النموذج المستخدم في محادثتك الرئيسية). tools يدرج فقط ثلاث أدوات للقراءة فقط، حتى لو أراد الكتابة فلن يتمكن.
الخطوة الثالثة: اصنع جزءاً من الشفرة «فيه مجال للتحسين» ليعلق عليه
echo 'def f(a, b):
return a / b' > calc.pyاسم الدالة f وأسماء المعلمات a/b سيئة جداً، ولم يتم معالجة القسمة على صفر——وهو مناسب تماماً ليلتقطه المعلق.
المتوقع: يوجد في sub-demo ملف calc.py بمحتوى السطرين أعلاه.
الخطوة الرابعة: شغّل Claude وحدّد الوكيل الفرعي ليعمل
claudeبعد الدخول، استخدم @ للتحديد المباشر بالاسم (لضمان استخدامه وتجنب أن يتصرف Claude من تلقاء نفسه). اكتب يدوياً @agent-code-reviewer، أو اكتب @ ثم اختر code-reviewer من القائمة المنبثقة:
@agent-code-reviewer قم بتقييم calc.pyالمتوقع: سترى أن Claude يفوض الأمر للوكيل الفرعي code-reviewer (ستحدد الواجهة أن هذا الوكيل الفرعي يعمل، ربما بكتلة ملونة). في سياقه الخاص سيقرأ calc.py، ثم يعيد فقط «استنتاج التقييم» للمحادثة الرئيسية——وسيشير تقريباً إلى أن: اسم الدالة f والمعلمات a/b غير معبرة، ويفتقر لمعالجة القسمة على 0، وينصح بالتغيير لأسماء أوضح مع إضافة فحص للحدود. لاحظ أنه يقدم اقتراحات فقط ولم يلمس ملفك (لأنك لم تمنحه أداة Write).
الخطوة الخامسة: تحقق من أنه لم يقم بتعديل الملف فعلاً
اخرج من Claude (اكتب exit أو اضغط Ctrl+D)، وعد إلى الطرفية لترى:
cat calc.py(استخدم type calc.py في Windows PowerShell)
المتوقع: ملف calc.py لم يُمَس، ولا يزال يحتفظ بالسطرين——هذه هي قوة «تقييد الصلاحيات»: لقد منحته أدوات للقراءة فقط، وحتى لو أراد مساعدتك في التعديل فلن يستطيع سوى التحدث.
من خلال تنفيذ هذه الخطوات الخمس، تكون قد تحققت بنفسك من المسار الكامل «كتابة التكوين ← التحميل ← التحديد للتشغيل ← عمل الوكيل الفرعي في سياق مستقل ← إرجاع الاستنتاج فقط دون تجاوز الصلاحيات». بالنسبة لأي وكيل فرعي في المستقبل، الجوهر هو تغيير الشخصية وضبط الأدوات بناءً على هذه الآلية.
⚠️ إذا لم يكن موجوداً في القائمة عند كتابة
@agent-code-reviewer، فالأرجح أن تحميل ملف الوكيل الفرعي لم يسري مفعوله——الملفات المكتوبة يدوياً تتطلب إعادة تشغيل الجلسة (الفخ في القسم 04). اخرج وادخل مجدداً، أو استخدم ببساطة واجهة/agentsللإنشاء (لا تتطلب إعادة تشغيل).
💡 ملخص في جملة: كتابة معلق يُمنح أداة Read فقط يدوياً، واستخدام
@لتحديده وتشغيله، ثم تأكيدcatبأن الملف لم يُمس——تجربة المسار «العمل المستقل + تقييد الصلاحيات لعدم التجاوز» بنفسك، أنفع من تذكر عشرات الحقول.
07 الخلاصة
في هذا المقال، تحدثنا عن «الوكيل الفرعي» بدءاً من «متى يجب استخدامه» وصولاً إلى «كيفية الإنشاء، والتشغيل، والتحقق»——الهدف ليس تعليمك كيفية التقسيم ببراعة، بل مساعدتك على بناء خط التقييم «هل أسند المهمة أم أقوم بها بنفسي».
نلخص النقاط الأساسية:
| ما تريد فهمه | الإجابة | النقطة الأساسية |
|---|---|---|
| ما هو الوكيل الفرعي | مساعد خارجي ذو سياق + شخصية + أدوات مستقلة | يبدأ من ورقة بيضاء، ولا يرى محادثاتكم السابقة |
| ماذا يحل | عزل السياق، التخصص في المهام، وإمكانية التوازي | الأكثر قيمة هو «ترك المهام القذرة في غرفته، وإعادة الاستنتاجات فقط» |
| متى لا نستخدمه | المهام البسيطة، التي تتطلب تواصلاً متكرراً، وتهتم بالسرعة | التقسيم الكثير ≠ احترافية، التقسيم المفرط يجعله بطيئاً ومكلفاً |
| كيفية الإنشاء | الإنشاء التفاعلي بـ /agents، أو كتابة .claude/agents/name.md يدوياً | الإلزامي هو name/description فقط؛ التعديل اليدوي يتطلب إعادة التشغيل |
| كيفية التشغيل | التفويض التلقائي بـ description / اللغة الطبيعية / التحديد بـ @ | @ يضمن استخدامه؛ وصف واضح لتفويض دقيق |
يجب أن تكون قادراً الآن على: الحكم على ما إذا كان يجب إسناد المهمة للوكيل الفرعي (بدلاً من التقسيم بحماس)، واستخدام /agents أو كتابة ملف لإنشاء وكيل فرعي ذو شخصية حصرية وأدوات مقيدة، واستخدام التفويض التلقائي أو @ لتشغيله، مع تسليم الاستنتاج النظيف للمسار الرئيسي. هذا الشعور بالتوازن بين «متى نسند المهمة، ومتى نقوم بها بأنفسنا» هو العتبة الحقيقية للوكيل الفرعي——يمكنك تعلم الميزة في عشر دقائق، لكن التوازن يكتسب بالممارسة.
تذكر العبارة التي تتعارض مع الإجماع في البداية: الوكيل الفرعي قوي، لكن قوته تكمن في «استخدامه في السيناريو الصحيح»، وليس في «كثرة التقسيم».
💡 ملخص في جملة: العتبة الحقيقية للوكيل الفرعي ليست «معرفة كيفية الإنشاء»، بل «معرفة متى يجب الإنشاء»——المهام القذرة، التي تحتوي نفسها، أو تتطلب قفل الصلاحيات يتم إسنادها؛ والمهام البسيطة، السريعة، وذات التواصل المتكرر تقوم بها بنفسك.
المقال التالي 24 «الإضافات (Plugins)»——هنا أصبحت تملك المزيد والمزيد من «الملحقات»: CLAUDE.md، أوامر slash، Skill، والآن أضفت Subagent. تجهيز كل واحد على حدة يبدو متناثراً أليس كذلك؟ المقال التالي سيعلمك كيفية تجميع هذه المكونات في إضافة (Plugin) واحدة، وتثبيتها أو مشاركتها بنقرة واحدة، وحتى استخدام المكونات الجاهزة من «سوق الإضافات». فكر في ذلك: هل يمكن نقل الوكلاء الفرعيين والأوامر التي ضبطها الآخرون إليك بنقرة واحدة؟