الـ fan out للوكلاء الفرعيين في Claude Code، ثم التحقق مما يعود

يكتب الناس "claude fan out subagents" في Google، ويضيف كثير منهم كلمة "command" في النهاية، كأن هناك مفتاحًا يكفي أن تضغطه. هناك أسلوب، وهناك أيضًا أمر. تحققنا من الاثنين على Claude Code 2.1.301 وفي وثائق Anthropic يوم 16 أكتوبر 2026.

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

الإجابة المختصرة

الـ fan out يعني أن تقسّم جلسة واحدة عملًا إلى شرائح لا تعتمد إحداها على الأخرى، وتسلّم كل شريحة إلى وكيل فرعي، وتتركها تعمل في الوقت نفسه، ثم تدمج ما يعود. في Claude Code يمكنك فعل ذلك بثلاث طرق.

يتناول باقي هذه الصفحة كل طريقة، ثم الفحوص التي نجريها على الـ fan out الخاص بنا.

ما يستطيع الوكيل الفرعي رؤيته وما لا يستطيع

ثلاث حقائق من الوثائق تحدد طريقة تقسيم العمل.

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

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

هناك حدود. افتراضيًا، يمكن تشغيل 20 وكيلًا فرعيًا في الوقت نفسه داخل الجلسة. يفشل الحادي والعشرون برسالة Concurrent subagent limit reached، ويطلب الخطأ من Claude ألا يعيد المحاولة. يمكنك رفع هذا الحد أو خفضه عبر CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS. ويمكن للوكلاء الفرعيين تشغيل وكلاء فرعيين خاصين بهم، حتى ثلاثة مستويات تحت المحادثة الرئيسية، ولا حد للعدد الإجمالي خلال الجلسة.

الطريقة 1: اطلبه بكلمات بسيطة

أبسط fan out هو جملة واحدة. المثال الوارد في وثائق Anthropic:

Research the authentication, database, and API modules in parallel using separate subagents

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

الكلمات البسيطة تترك القرار لـ Claude. إذا عرّفت وكيلًا فرعيًا مخصصًا في .claude/agents/، فإن ذكره بـ @ يضمن أن يعمل في هذه المهمة. تشرح صفحتنا عن الوكلاء الفرعيين في Claude Code كيف تعمل هذه الملفات.

الطريقة 2: /batch، أقرب شيء إلى أمر fan out

/batch مهارة مدمجة في Claude Code. تعطيها تعليمة:

/batch migrate src/ from JavaScript to TypeScript

تستكشف قاعدة الكود، وتقسّم العمل إلى 5 إلى 30 وحدة مستقلة، وتعرض عليك خطة. بعد موافقتك، تشغّل وكيلًا فرعيًا في الخلفية لكل وحدة، كل واحد في worktree git معزول. ينفّذ كل وكيل فرعي وحدته، ويشغّل الاختبارات، وينشر تغييره. تحتاج إلى مستودع git، أو إلى خطاف WorktreeCreate ينشئ الـ worktrees لنظام آخر لإدارة الإصدارات.

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

الطريقة 3: حلقة على claude -p

حين يكون العمل قائمة ملفات وتريد التحكم في كل استدعاء، تصف أفضل ممارسات Anthropic حلقة. أولًا، اطلب من Claude أن يكتب القائمة (list all 2,000 Python files that need migrating and save the list to files.txt). ثم:

for file in $(cat files.txt); do
  claude -p "Migrate $file from Python 2 to Python 3. Return OK or FAIL." \
    --allowedTools "Edit,Bash(git commit *)" \
    --permission-mode dontAsk
done

ثلاث تفاصيل في هذا المثال تستحق أن تنقلها.

• الإجابة قابلة للقراءة آليًا. "Return OK or FAIL" تعني أن سكربتك يستطيع عدّ الإخفاقات دون قراءة نص.
• الأذونات تُحدَّد مسبقًا. يوافق --allowedTools على ما يحتاجه الترحيل بالضبط، ويرفض --permission-mode dontAsk كل ما عدا ذلك بدل انتظار شخص غير موجود.
• تبدأ بملفين أو ثلاثة. تقولها الوثائق بوضوح: حسّن المطالبة بناءً على ما يفشل مع الملفات الأولى، ثم شغّل القائمة كاملة.

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

للـ CI، توصي الوثائق بإضافة --bare، الذي يتخطى الخطافات والمهارات وخوادم MCP وCLAUDE.md حتى يحصل كل جهاز على التشغيل نفسه. لا يستخدم وضع bare تسجيل الدخول باشتراكك: يحتاج إلى ANTHROPIC_API_KEY.

كيف ننفّذ fan out كل ليلة

هذا هو الـ fan out الذي نشغّله فعلًا. يكتب فريق SEO الليلي لدينا كل مقال جديد بالإنجليزية والفرنسية يدويًا. ثم يترجمه وكيل ثانٍ إلى سبع عشرة لغة أخرى بوكلاء Claude Code الفرعيين، ويولّد الصينية التقليدية من الصينية المبسطة بسكربت بدل ترجمتها. مرّ أحد عشر مقالًا بهذه العملية منذ 13 سبتمبر 2026، وكل واحد منها يصل في عشرين ملفًا.

الشرائح

ستة وكلاء فرعيين، ثلاث لغات لكل واحد (لغتان للأخير): الإسبانية والبرتغالية والإيطالية؛ الألمانية والهولندية والبولندية؛ الروسية والأوكرانية والتركية؛ اليابانية والكورية والصينية؛ التايلاندية والفيتنامية والإندونيسية؛ العربية والهندية. لا تعتمد أي لغة على أخرى، وهذا ما يجعل هذا الـ fan out نظيفًا.

يحمل كل تكليف الأشياء الخمسة نفسها، لأن الوكيل الفرعي لا يرى شيئًا غيرها:

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

الفحص يُكتب قبل التشغيل

الفحص سكربت، لا رأي وكيل فرعي. لكل لغة يقارن الملف بالمصدر الإنجليزي:

• الـ slug نفسه والتاريخ نفسه، والعنوان مطابق للـ H1؛
• العدد نفسه من الأقسام والأقسام الفرعية والصور والروابط وصفوف الجدول، وعدد إجابات الأسئلة الشائعة في المتن مساوٍ لعدد الأسئلة في البيانات الوصفية؛
• روابط مطابقة بايتًا ببايت، ومقاطع كود مطابقة بايتًا ببايت؛
• أسماء العلامات التجارية معدودة، ولا تقل أبدًا عن عددها في الإنجليزية؛
• طول ضمن حدود معايَرة لكل لغة، لأن الصينية تقول الشيء نفسه بنحو 36% من الحروف التي تحتاجها الإنجليزية، واليابانية بنحو نصفها؛
• العلامات المميِّزة فوق الحروف وتحتها موجودة حيث تملكها اللغة (البولندية والتركية والفيتنامية).

ينهي كل وكيل فرعي عمله بصيغة ما من "تم، كل الفحوص ناجحة". الحكم الوحيد الذي نعمل به هو السكربت نفسه، تعيد الجلسة الرئيسية تشغيله على كل الملفات دفعة واحدة.

ما اكتشفه الفحص المركزي ولم تذكره التقارير الذاتية

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

الفحص الخاص بنا كان خاطئًا. في 6 سبتمبر، أبلغ فحص طول معايَر على النص القديم الذي كنا نستبدله عن 11 وكيلًا فرعيًا من أصل 17. وكان الأحد عشر كلهم على حق: كان يُفترض أن يكون النص الجديد أطول. وحين عايرناه على الفرنسية المصحّحة، لم يبلّغ عن أي واحد. الفحص المركزي يمكن أن يخطئ هو أيضًا، والطريقة لرؤية ذلك هي تشغيله أولًا على تسليم تعرف أنه سليم.

الاتساق بين الشرائح. في 15 أكتوبر، على صفحة ميزة جديدة تُرجمت بالطريقة نفسها، أكّد فحص الدمج أن النصوص المتوقعة وحدها تغيّرت عبر 90 ملفًا. لكن الوكلاء الفرعيين المكلّفين باليابانية والكورية والصينية اختار كل منهم لعبارة "You may also like" عنوانًا غير العنوان الذي تستعمله لغته بالفعل في صفحة مجاورة. كان كل اختيار ترجمة صحيحة. ولم يكن أي منها متسقًا مع الموقع. لم يكن بوسع أي وكيل فرعي رؤية ذلك من داخل شريحته: وحدها مراجعة للنتيجة المدموجة تكشفه.

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

التبليغات من خارج الشريحة. في 15 أكتوبر، أبلغ الوكيل الفرعي المكلّف بالتركية أن الموقع يكتب "ajans"، أي وكالة، بدل "agent" في 97 نصًا موجودًا. لم يلمسها، لأن تكليفه منعه من ذلك. فتحنا تذكرة وخرج الإصلاح في اليوم التالي. سؤال الوكلاء الفرعيين عمّا رأوه، لا عمّا فعلوه فقط، قليل الكلفة ويؤتي ثماره.

الدمج يحدث في مكان واحد

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

متى لا تستخدم الـ fan out

• الشرائح تعتمد على بعضها. إذا احتاجت الشريحة B إلى مخرجات الشريحة A، فشغّلهما بالترتيب.
• العمل صغير. كل وكيل فرعي يبدأ من الصفر ويعيد قراءة ما يحتاج إليه. في مهمة من عشر دقائق، تكلّف البدايات الجديدة أكثر مما توفّر.
• لا تستطيع كتابة الفحص. إذا لم تكن هناك طريقة للتمييز بين شريحة جيدة وأخرى سيئة دون أن تقرأ كل شيء بنفسك، فالدمج هو المكان الذي ستقضي فيه وقتك.
• الحصة ضيقة. كل وكيل فرعي يستهلك رموزه الخاصة. يمنحك الـ fan out وقتًا وسياقًا رئيسيًا نظيفًا، لا فاتورة أصغر.

أين يأتي دور AgentsRoom

يعيش الوكلاء الفرعيون داخل جلسة Claude Code واحدة. ترى نتائجهم، لا عملهم، ولا يمكنك توجيه أحدهم في منتصف الطريق. حين تريد أن تكون كل شريحة وكيلًا تستطيع متابعته والرد عليه ومراجعة عمله على حدة، شغّل جلسات منفصلة بدلًا من ذلك: كل تذكرة في worktree git خاص بها، وAgent Teams حين تسلّم الشرائح العمل بعضها لبعض. يمكن أن تحمل خطوة الفريق أمر فحص، ورمز خروجه، لا ما يدّعيه الوكيل، هو ما يقرر إن كان التشغيل سيتقدم. إنها القاعدة نفسها المذكورة أعلاه، يفرضها المشغّل. يعمل ذلك مع Claude Code وCodex وواجهات CLI الأخرى للوكلاء التي يدعمها AgentsRoom.

إن كنت لا تزال تختار بين الوكلاء الفرعيين وAgent Teams، فإن هذه المقارنة تشرح الغرض من كل منهما.