وكلاء فرعيون لـ Claude Code: كيفية ومتى تشغيل فرق الوكلاء

آخر تحديث: June 28, 2026

يُعد وكيل Claude Code الفرعي (subagent) جلسة Claude منفصلة يقوم الوكيل الرئيسي بتشغيلها لمهمة مركزة واحدة، ثم يدمج النتيجة في عملك. لقد قمت بنشر ثلاثة منها بالتوازي الأسبوع الماضي لتقسيم عملية إعادة هيكلة إلى مخطط (schema)، وواجهة API، واختبارات، وقد انتهت قبل أن تنهي جلسة طويلة واحدة التخطيط. تغطي هذه المقالة كيفية تعريف ونشر الوكلاء الفرعيين، وأنماط التنسيق التي أستخدمها لمحاكاة فريق صغير، والحد الصادق الذي تتجاوز فيه تكلفة الوكلاء الفرعيين ما يوفرونه من توفير.

إجابة سريعة: ما هو وكيل Claude Code الفرعي؟

الوكيل الفرعي هو مثيل (instance) لـ Claude يمتلك نافذة سياق خاصة به، وموجه نظام خاص به، ومجموعة أدوات ضيقة. لا يفقد الجلسة الرئيسية السياق عند تشغيل الوكيل الفرعي، لأن الوكيل يعمل في عزلة ويعيد فقط ملخصًا. فكر فيه على أنه تفويض مهمة إلى زميل فريق لا يقطع شاشتك أبدًا.

الآلية الرسمية بسيطة. تقوم بإسقاط ملف markdown في المجلد .claude/agents/ مع مقدمة YAML، ويمكن لـ Claude Code استدعائه عبر أداة Task عندما تتطابق المهمة مع وصفه. يعد توثيق الوكلاء الفرعيين هو المصدر الحقيقي للحقول، ويقوم مستودع Claude Code بتتبع التغييرات في التنسيق.

يبدو تعريف الوكيل الفرعي الأدنى (minimal subagent definition) كالتالي:

---
name: migration-writer
description: Writes and runs database migrations for this repo. Use for schema changes.
tools: Read, Edit, Bash
model: inherit
---
You are a migration specialist. Always check existing migrations first, never drop columns without a confirmation step, and run the migration against the local DB before reporting done.

بمجرد وجود هذا الملف، أطلب من الوكيل الرئيسي "استخدم وكيل migration-writer الفرعي لإضافة جدول الطلبات" ويقوم بنشر عامل (worker) محدود النطاق بدلاً من التخبط فيه بشكل مضمّن (inline). يحافظ السطر model: inherit على تكلفة وجودة متوازنة مع الجلسة الرئيسية؛ وتثبيت نموذج أرخص مثل haiku لوكيل فرعي يعتمد على القراءة المكثفة هو رافعة حقيقية عندما تقوم بتشغيل العديد منها.

متى يجب أن تلجأ إلى الوكلاء الفرعيين بدلاً من جلسة واحدة؟

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

أستخدم الوكلاء الفرعيين للمهام التي من شأنها خلاف ذلك أن تلوث سياقي الرئيسي بالسجلات (logs)، أو القراءات الكبيرة، أو التجربة والخطأ. يعد التدقيق على مستوى قاعدة التعليمات البرمجية بالكامل الذي يستخدم grep على 200 ملف مرشحًا مثاليًا، لأن الوكيل الفرعي يقرأها كلها ويعيد ملخصًا من فقرتين بينما تظل جلستي الرئيسية نظيفة.

إذا كنت جديدًا على الوكيل نفسه، فإن الدليل الشامل لـ Claude Code يغطي الأساسيات قبل أن تضيف الوكلاء الفرعيين فوقها.

كيف تنشر (dispatch) الوكلاء الفرعيين في Claude Code؟

يتم النشر بطريقتين. يمكن للوكيل الرئيسي استدعاء أداة Task بمفرده عندما تتناسب مهمة ما مع وصف وكيل فرعي، أو يمكنك تسميته صراحةً في الموجه (prompt) الخاص بك. أنا أفضل التسمية، لأن النشر الضمني يتخطى أحيانًا وكيلاً كنت أريده.

بعض الأنماط التي أقوم بتشغيلها بانتظام:

• "استخدم وكيل code-reviewer على الاختلاف (diff) في هذا الفرع، ثم طبق اقتراحاته."
• "انشر migration-writer لإضافة عمود users.email_verified، وانشر test-writer لتغطيته. قم بتشغيل كليهما."
• "قم بتشغيل وكيل api-docs على src/routes/ وأعد فقط هيكل OpenAPI الهيكلي (skeleton)."

يعمل الوكيل الفرعي في سياقه الخاص، لذلك لا يمكنه رؤية محادثتك الجارية ما لم تمرر التفاصيل في الموجه. هذه العزلة هي الهدف. عندما ينتهي، تحصل على نتيجة، وليس تيارًا من الضوضاء الوسيطة.

الأنماط التي أستخدمها لسير العمل الشبيه بالفريق

الحيلة هي نسخ كيفية تقسيم فريق حقيقي للعمل، ثم تعيين كل دور لوكيل فرعي. فيما يلي الأنماط التي أعود إليها باستمرار.

البحث، ثم التفرع. أقوم بنشر وكيل فرعي واحد لجمع السياق، وأقرأ ملخصه، ثم أنشر عدة وكلاء تنفيذيين ضد واجهة مشتركة. هذا يحاكي قائد تقني يحدد نطاق العمل قبل توزيع المهام (tickets).

البناء خلف عقد (contract). قم بتعريف واجهة API أو خصائص المكون أولاً، ثم قم بتشغيل وكيل فرعي للواجهة الخلفية ووكيل فرعي للواجهة الأمامية بالتوازي ضد هذا العقد. لا يعيق أحدهما الآخر، ونادرة التعارضات لأنها تلمس ملفات مختلفة.

المراجعة كدور منفصل. أحافظ على وكيل code-reviewer الفرعي بأدوات قراءة فقط. بعد أي تغيير غير تافه، أقوم بتشغيله ضد الاختلاف (diff). تقييد أدواته يعني أنه لا يمكنه التعديل حرفيًا، مما يحافظ على نزاهة المراجعة.

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

مثال عملي: الطلبات والمدفوعات

في الشهر الماضي، قمت بتقسيم ميزة تتضمن الطلبات والمدفوعات إلى ثلاثة وكلاء فرعيين ضد عقد محدد النوع (typed contract). كان العقد عبارة عن واجهة TypeScript واحدة لـ Order تحتوي على status وtotalCents وpaymentId. قمت بنشر: وكيل فرعي للواجهة الخلفية لتنفيذ إنشاء الطلب وتغييرات الحالة؛ ووكيل مدفوعات لتوصيل استدعاء Stripe وتخزين paymentId؛ ووكيل اختبار لتغطية المسار السعيد وحالة الحجز (refund) الخاصة. لمس الثلاثة ملفات مختلفة، لذلك كان الدمج ثلاث عمليات نسخ ولصق نظيفة بدلاً من جلسة لحل التعارضات. استغرق التشغيل بأكمله 14 دقيقة؛ بينما استغرقت نفس المهمة في جلسة متسلسلة واحدة 41 دقيقة الأسبوع الذي سبقه، لأن السياق الوحيد كان يعيد تحميل وثائق Stripe باستمرار.

كيف تنسق العمل المتوازي دون فقدان السياق؟

الجلسة الرئيسية هي المنسق الخاص بك. وظيفتها هي تقسيم العمل، وتوزيع موجهات محدودة النطاق، وإعادة تجميع النتائج معًا. حافظ على المنسق خفيفاً ودع الوكلاء الفرعيين يتحملون القراءات الثقيلة.

يبدو تشغيل متوازٍ نموذجي بالنسبة لي كالتالي:

1. كتابة العقد وحدود الملف في الجلسة الرئيسية.
2. نشر ما بين اثنين إلى أربعة وكلاء فرعيين، لكل منهم شريحة وشرط نجاح واضح.
3. قراءة كل ملخص عند عودته، وليس أثناء التشغيل.
4. الدمج في الجلسة الرئيسية، وحل الدرزات بنفسك.
5. تشغيل وكيل الاختبار أخيرًا ضد النتيجة المدمجة.

لا يثمر التوازي إلا عندما تكون الشرائح مستقلة حقًا. إذا قام وكيلان فرعيان بتعديل schema.prisma، فأنت لم تقسم العمل، بل خلقت مشكلة دمج (merge problem). ارسم الحدود عند الملفات والعقود، ثم فرضها في الموجه.

متى تضيف الوكلاء الفرعيين عبئًا إضافيًا أكثر مما يوفرونه؟

يضيف الوكلاء الفرعيون زمن انتقال (latency)، ورموز (tokens)، وتكلفة تنسيق. يفقد تسليم الملخص التفاصيل، لذا فإن أي شيء يحتاج إلى استمرارية عميقة هو غير مناسب. كن صادقاً بشأن المقايضة قبل أن تلجأ إليهم.

لقد أجريت مقياساً مرجعياً لفرع ميزة ذات مرة: وكيل فرعي لكل خدمة مصغرة مقابل جلسة واحدة تمر بها بالترتيب. بالنسبة لخمس خدمات مفككة بشكل غير متصل، فاز التوازي بنحو 40% من وقت الساعة. أما للخدمات الثلاث التي تشترك في نموذج بيانات، فقد كانت الجلسة الواحدة أسرع، لأن الدمج وإعادة الشرح استهلكا مكاسب التوازي.

الدرس المستفاد: التوازي يكافئ الاستقلال ويعاقب الارتباط (coupling). إذا كانت شرائحك تتشارك الحالة، فلا تقم بتوازيها.

ما هي الأخطاء الشائعة؟

• الكثير من الوكلاء الفرعيين. أقتصر التشغيل على ثلاثة إلى خمسة. بعد ذلك، تفوق تكلفة التنسيق على مكسب التوازي.
• الموجهات الغامضة. "إصلاح المصادقة" يفشل. "إضافة نقطة نهاية تحديث JWT عند /auth/refresh، وإرجاع { token }، مع اختبار" ينجح.
• لا معايير للنجاح. حدد ما يعنيه الانتهاء. "تم تطبيق الترحيل محليًا واختبار التراجع" يتفوق على "التعامل مع المخطط".
• مجموعة أدوات خاطئة. أعطِ المراجع أدوات قراءة فقط. وأعطِ وكيل النشر الأوامر الدقيقة التي يحتاجها، لا شيء أوسع.
• تجاهل الإخفاقات. إذا أعاد الوكيل الفرعي خطأً، فاقرأه. إعادة المحاولة العمياء تحرق الرموز وتخفي مشكلة حقيقية.
• تخطي الدمج. تعيد الوكلاء الفرعيون النتائج؛ لكنك لا تزال مسؤولاً عن التكامل. خصص وقتًا فعليًا لذلك.

الخطأ الأكثر تكلفة هو التعامل مع الوكلاء الفرعيين على أنهم توازي مجاني لأي شيء. إنهم عمال محدودو النطاق خلف حدود ملخص، وهذا الحد له تكلفة.

الملخص

تحول الوكلاء الفرعيون (Subagents) Claude Code إلى شيء يشبه فريقًا صغيرًا: منسق خفيف ينشر عمالاً محدودين النطاق يحمل كل منهم سياقه الخاص ويقدم نتيجة. عرّفها في .claude/agents/، وانشرها باستخدام أداة Task، وحافظ على جلستك الرئيسية نظيفة عن طريق دفع القراءات الثقيلة والأدوار المتكررة إلى الوكلاء الفرعيين.

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

تحذير حقيقي واحد: الوكلاء الفرعيون يضاعفون الإنتاجية (throughput)، وليس الحكم. سيبنون بسعادة الشيء الخاطئ بالتوازي عبر أربعة سياقات معزولة. يبقى عمل التنسيق، وتعريف العقد، والمراجعة النهائية عليك، لذا لا يظهر الرافعة إلا عندما تكون الشرائح مستقلة حقًا ومعايير النجاح دقيقة. إذا كنت تريد الخلفية الأعمق حول البروتوكول الذي يشغل الكثير من توصيلات الأدوات هذه، فإن مُفسِّر MCP هو قراءة جيدة تالية، وتوثيق Claude Code يغطي الإعدادات التي لم أكررها هنا.

حقوق صور التغطية (Image credits)

• A team of developers working together at computers in a modern tech office — photo by Rebrand Cities on Pexels
• Colorful programming code on a computer monitor — photo by inna mykytas on Pexels
• A developer writing code on a laptop in front of multiple monitors — photo by Christina Morillo on Pexels
• Two programmers focused on coding side by side in a modern office — photo by Rebrand Cities on Pexels