كيفية تفويض مهمة كبيرة في Claude Code باستخدام الوكلاء الفرعيين المتداخلين

ما الذي تغيّر في Claude Code v2.1.172؟#

إذا قرأت أي شيء عن وكلاء الذكاء الاصطناعي في Claude Code خلال الأشهر القليلة الماضية، فلا بد أنك صادفت العبارة نفسها. تظهر في الوثائق الرسمية، وفي دليلي عن الوكلاء الفرعيين، وفي تحليلات المنافسين كافة. وتقول: «لا يمكن لوكيل فرعي إنشاء وكيل فرعي آخر». وحتى 11 يونيو 2026، لا تزال هذه العبارة موجودة في ثلاثة مواضع مختلفة على code.claude.com/docs/en/sub-agents. ببساطة، لم تحدّثها Anthropic بعد.

في 10 يونيو، الساعة 20:44 بالتوقيت العالمي المنسق، ظهر Claude Code v2.1.172 على GitHub Releases. وكان أهم بند في سجل التغييرات سطرًا واحدًا:

أصلح هذا الإصدار أيضًا خطأً لا يمكن أن يحدث إلا مع التداخل: إذ ظل وكيل فرعي يعمل في الخلفية مميزًا بوصفه نشطًا في لوحة الوكلاء بعد إيقاف الوكيل الفرعي المتداخل الذي أطلقه.

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

كيف يختلف الوكلاء الفرعيون المتداخلون عن الوكلاء المتوازيين والمتتابعين؟#

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

العرض—الوكلاء الفرعيون المتوازيون. تطلق المحادثة الرئيسية N من الوكلاء الفرعيين المستقلين على المستوى نفسه. يتلقى كل واحد منهم مهمة محددة النطاق، ويعمل في نافذته المعزولة، ولا يعيد سوى النتيجة. يحل العرض مشكلة السرعة: فخمسة وكلاء فرعيين يعملون بالتوازي ينجزون المهمة في الوقت الذي يستغرقه وكيل واحد لتنفيذها بالتتابع. هذا هو النموذج الذي تناولته في دليلي عن الوكلاء الفرعيين المتوازيين باستخدام worktrees.

الطول—سلسلة من الوكلاء الفرعيين. يعمل A، ويسلّم النتيجة إلى B؛ ثم يعمل B ويسلّمها إلى C. يرى كل واحد منهم المدخلات الواردة من الوكيل السابق. يحدد الطول ترتيب التنفيذ: لا يستطيع B البدء حتى يحصل على بيانات من A. مثال شائع: يجمع وكيل فرعي للبحث المصادر أولًا، ثم يكتب وكيل فرعي للتحرير مقالًا استنادًا إليها، وبعد ذلك يتحقق وكيل فرعي لتدقيق الحقائق من المقال. إنها سلسلة مسطحة، وتحتفظ المحادثة الرئيسية بالقصة كاملة.

العمق—الوكلاء الفرعيون المتداخلون. يطلق A الوكيل B، ويطلق B الوكيل C، ويطلق C الوكيل D. يعمل كل ابن داخل والده، في نافذته المعزولة، ويعيد النتيجة فقط إلى والده. لا ترى المحادثة الرئيسية أيًا مما يجري لدى الأبناء أو الأحفاد أو أبناء الأحفاد. وهذا هو الجديد في v2.1.172.

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

أزال الإصدار 2.1.172 القاعدة التي كانت تمنع الوكيل الفرعي من إنشاء وكيل فرعي آخر.

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

ما معنى «عمق 5 مستويات» عمليًا؟#

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

إنه حد أقصى، لا إعداد.

الحد مضمّن في جهة الخادم. ولم يعثر الفحص العكسي للعميل v2.1.172 على ثابت MAX_DEPTH. وهذا يعني أن التحقق يجري في موضع ما من Anthropic API، وليس محليًا على جهازك. لا يمكنك تعيين --max-depth 7 لجعل الشجرة أعمق. كما لا يمكنك تعيين --max-depth 2 لفرض حد أدنى وأكثر أمانًا. عنصر التحكم الوحيد المتاح لك هو قائمة السماح Agent(agent_type) في الترويسة الأمامية، لكنها تحدد أنواع الوكلاء الأبناء لا العمق.

لم تحدد Anthropic معنى «5» بدقة. وهذه هي النقطة المهمة الثانية:

لم تحدد المصادر الرسمية ما إذا كان depth=5 يعني خمسة مستويات تحت الجذر أو خمسة وكلاء إجمالًا، بما في ذلك الجذر.

تفسر عمليات التكامل التابعة لجهات خارجية هذا الأمر بطرق مختلفة حاليًا. يفترض ADR-147 في مشروع ruvnet/ruflo أن «خمسة مستويات فرعية تحت الجذر = ستة وكلاء في السلسلة». وأستخدم الاصطلاح نفسه في تجاربي: المحادثة الرئيسية في المستوى 0، وأبناؤها المباشرون في المستوى 1، وهكذا حتى المستوى 5. لكن هذا الاصطلاح غير موثق في الوثائق العامة.

الحد مفعّل بالفعل، من دون علامات. لست بحاجة إلى تفعيل أي شيء. بعد تحديث Claude Code إلى v2.1.172، يمكنك إضافة Agent إلى tools لدى وكيل فرعي، وسيطلق وكيلًا فرعيًا آخر. المهم أن يسمح الوكيل الأب بذلك (tools: Agent(...)).

أين يحدث التفويض لديك اليوم: في العرض أم الطول أم العمق؟#

راجع آخر 5 مطالبات أرسلتها. كم مرة فعلت هذا: تبدأ مهمة، فيبدأ Claude بالبحث في الملفات باستخدام grep، وينفذ 10 طلبات على الويب، ثم يملأ السياق بجدار كامل من السجلات، وبعد 20 دقيقة تكتشف أن النافذة امتلأت. ويُكتب الجواب النهائي بميزانية رموز ضئيلة لأن 70 بالمئة من السياق استهلكتها التفريغات الوسيطة.

هذا سيناريو تحتاج فيه إلى العمق. لا إلى التوازي أو السلسلة، بل إلى العمق. ينبغي للمحادثة الرئيسية أن تفوض «البحث» إلى وكيل فرعي واحد، ثم يطلق ذلك الوكيل أبناءه من داخله لإجراء عمليات بحث محددة على الويب، وقراءة الملفات، والبحث باستخدام grep. يعيد الأبناء أحكامًا موجزة فقط. يخبر الحفيد والده: «وجدته، وتم التحقق»، أو «لم أجده، والسبب هو X». يجمع الوالد ذلك في ملخص واحد ويعيده إليك. وتظل المحادثة الرئيسية مرتبة.

قبل 9 يونيو، كنت أحاكي ذلك يدويًا. فتحت نسخة ثانية من Claude Code، ونسخت المطالبة «ابحث في هذا»، وشغّلتها، ثم نقلت النتيجة يدويًا إلى النافذة الرئيسية. مع v2.1.172، يمكنك وصفه مباشرة في مطالبة النظام الخاصة بالمنسق، وسيبني Claude الشجرة بنفسه.

في أي 3 سيناريوهات تكون الوكلاء الفرعيون المتداخلون مفيدين فعلًا؟#

السيناريو 1. البحث المتعمق مع التحقق من الحقائق

لنفترض أنك تجمع مواد لمقال أو عرض مبيعات. تحتاج أولًا إلى استخراج 5–10 ادعاءات من مصادر عامة، ثم التحقق من كل منها: العثور على المصدر الأصلي، والتأكد من دقة الاقتباس، وحساب الأرقام الفعلية.

قبل v2.1.172، كان أمامك خياران. إما أن تنفذ كل ذلك باستخدام وكيل فرعي واحد، فيشق طريقه عبر 30 طلبًا على الويب ويملأ سياقه بكل شيء، أو أن تقسّم المهمة يدويًا: مطالبة لاستخراج الادعاءات، ثم تكرار العملية على الادعاءات، مع إطلاق وكيل فرعي مستقل لكل واحد منها. وكانت المحادثة الرئيسية ستمتلئ بجدران من القوائم الوسيطة.

في الوصفة أدناه، تفوض المحادثة الرئيسية research-orchestrator (المستوى 1). يستخرج المنسق الادعاءات بنفسه، ويرسل كلًا منها إلى fact-verifier (المستوى 2)، ويفوض كل متحقق بحثًا مركزًا إلى web-deep-search (المستوى 3). لا تتلقى المحادثة الرئيسية سوى مصفوفة من الادعاءات المتحقق منها مع مصادرها. ويبقى كل ما عدا ذلك في نوافذ الأبناء ولا يدخل سياقك.

السيناريو 2. تحليل مستودع كبير

أُحيل إليك مشروع يحتوي على 200 ملف. تحتاج إلى فهم بنيته، والعثور على الوحدات الرئيسية، وتقييم الدين التقني. نفّذ Glob يدويًا مع اثني عشر استدعاءً لـRead، وستملأ النافذة خلال 10 دقائق.

يحل العمق المشكلة على النحو التالي: تطلق المحادثة الرئيسية وكيلًا فرعيًا باسم «architect». وينشئ architect داخليًا ثلاثة أبناء: يفحص الأول بنية المجلدات (يشغّل Glob ويلخّصها)، ويقرأ الثاني 5 ملفات إعداد رئيسية، ويبحث الثالث باستخدام grep عن الأنماط الرئيسية. يعيد كل واحد ملخصًا موجزًا إلى architect. يجمع architect الصورة كاملة ويقدم للمحادثة الرئيسية تقريرًا نهائيًا لا يتجاوز نصف شاشة. تحصل على خريطة للمشروع من دون إغراق السياق بجدار من مخرجات cat لجميع الملفات.

السيناريو 3. تحليل التبعيات من البداية إلى النهاية

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

مع استخدام العمق، تطلق المحادثة الرئيسية وكيلًا باسم “impact-analyzer” (المستوى 1). ويطلق هذا الوكيل dependency-tracer لكل ملف متأثر (المستوى 2). ثم يطلق كل tracer داخليًا consumer-finder (المستوى 3)، الذي يبحث باستخدام grep في قاعدة الشيفرة عن الجهات التي تعتمد على هذه التبعية. بعد ذلك يعيد كل واحد منهم خلاصة فقط: «ستتأثر هذه المواضع الثلاثة». تجمع المحادثة الرئيسية جدولًا بعنوان «الملفات المتأثرة → الأثر» من دون الاطلاع على نتائج grep.

كيفية إعداد الوكلاء الفرعيين المتداخلين في 10 دقائق#

الخطوة 1. تأكد من استخدام الإصدار v2.1.172 أو أحدث.

claude --version

إذا كان إصدارك أقدم، فحدّثه. الميزة الرئيسية في الإصدار سطر واحد في سجل التغييرات: «يمكن للوكلاء الفرعيين الآن إنشاء وكلائهم الفرعيين حتى 5 مستويات عمق» (النص الكامل).

الخطوة 2. أنشئ وكيلًا أبًا يستطيع إنشاء أبناء.

الملف .claude/agents/research-orchestrator.md:

---
name: research-orchestrator
description: يفوّض البحث مع تدقيق عميق للحقائق
tools: Agent(fact-verifier), Read, WebFetch
model: opus
---

أنت منسق بحث. عند تلقي موضوع:
1. اقرأ المادة المقدمة أو اجلب روابط المصادر العامة المقدمة.
   استخرج بنفسك حتى 5 ادعاءات محددة. سجّل لكل منها نص الادعاء،
   ورابط مصدره أو ملفه، والمقطع الداعم المطابق.
   إذا لم تقدم مادة مصدرية، فاطلبها قبل التفويض.
2. استدعِ fact-verifier لكل ادعاء، وهو ينشئ بنفسه
   وكلاءه الفرعيين لإجراء البحث على الويب والتحقق.
3. سيعيد إليك fact-verifier الأحكام النهائية فقط.
   لا تحمّل التفريغات الوسيطة إلى سياقك.

التقرير النهائي: مصفوفة فقط بالصيغة { claim, sources[], confidence }.

يجيز سطر tools نوع الابن fact-verifier فقط. استخراج الادعاءات أول خطوة للمنسق نفسه، فلا يلزم ملف claim-extractor غير معرّف. تقيد قائمة أنواع مسموحة نوع الابن الممكن استدعاؤه؛ ولا تحد عدد إطلاقاته. أبق الوصفة محدودة بخمسة ادعاءات مستخرجة على الأكثر.

الخطوة 3. أنشئ وكيلًا فرعيًا يستطيع بنفسه إنشاء أحفاد.

الملف .claude/agents/fact-verifier.md:

---
name: fact-verifier
description: يتحقق من الادعاء من خلال عمليات بحث ويب فرعية
tools: Agent(web-deep-search), Read
model: sonnet
---

أنت مدقق حقائق. عند تلقي ادعاء:
1. صغ 2-3 استعلامات بحث.
2. شغّل web-deep-search لكل استعلام؛ فهو ينفذ بنفسه
   WebSearch وWebFetch ويعيد مقتطفات تم التحقق منها.
3. لخّص النتائج في verdict واحد: { claim, sources[], confidence }.

هل لاحظت الجزء المهم؟ يشير tools مرة أخرى إلى Agent(web-deep-search). وهذا يعني أن fact-verifier (المستوى 2 في شجرتنا) يستطيع بنفسه إطلاق وكيل فرعي آخر (المستوى 3). في السابق، لم يكن لهذا السطر أي أثر؛ فلا تزال الوثائق تتضمن العبارة التالية:

مع v2.1.172، أصبحت هذه العبارة قديمة. الصياغة نفسها، لكنها تعمل الآن عند أي عمق في الشجرة.

الخطوة 4. أنشئ حفيدًا.

الملف .claude/agents/web-deep-search.md:

---
name: web-deep-search
description: يجري بحثًا على الويب ويعيد مقتطفات
tools: WebSearch, WebFetch
model: haiku
---

تلقيت استعلام بحث. نفّذ WebSearch، واختر أفضل 3 عناوين URL ذات صلة، واستخرج عبر WebFetch
اقتباسات حرفية تؤكد الادعاء. أعد مصفوفة بالصيغة { url, snippet, supports_claim: yes|no }.

لا يحتوي tools لدى الحفيد على Agent، لذا لا ينشئ وكلاء في مستويات أدنى من الشجرة.

الخطوة 5. شغّل المنسق.

claude --agent research-orchestrator

ثم قدم نص المصادر أو روابطها العامة في المحادثة: «استخرج وتحقق من حتى 5 ادعاءات محددة من هذه المصادر؛ وأعد الادعاءات والمصادر والثقة». مع --agent research-orchestrator، تكون الجلسة نفسها المنسق، ويضيف المتحققون وأبناء البحث مستويين مفوضين تحتها. أما إذا فوضت جلسة رئيسية عادية هذا المنسق، فهناك ثلاثة مستويات تفويض تحت الجلسة الرئيسية.

ما الأنماط المضادة الخمسة التي تهدر الرموز وتدمر إمكانية تتبع ما يحدث؟#

النمط المضاد 1. المهمة تناسب نافذة واحدة.

إذا كان بإمكان وكيل فرعي واحد التعامل معها من دون ضجيج، فلا تضف مستويات: فالتداخل يضيف تكلفة وتأخيرًا بلا فائدة.

النمط المضاد 2. تريد السرعة لا العزل.

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

النمط المضاد 3. العمل سطحي بطبيعته.

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

النمط المضاد 4. المطالبات في المستوى الأول مبهمة.

هذا هو السيناريو الأخطر. إذا قدمت للمنسق في المستوى 1 مطالبة مبهمة، فسيتضاعف الغموض. تتحول مطالبة واحدة مبهمة في المستوى 1 إلى 4 مطالبات مبهمة في المستوى 2 و16 في المستوى 3. وعندما يبدأ الأحفاد العمل، لن يعرفوا حتى ما الذي يبحثون عنه.

النمط المضاد 5. النمو الهندسي للتكلفة.

الحجة الاقتصادية الرئيسية: التداخل يضاعف استخدام الرموز، ويتراكم هذا التضاعف مع العمق.

حساب تقريبي: تعني سلسلة بعمق 3 وتفرّع مقداره 3 في كل مستوى وجود 27 وكيلًا فرعيًا. وهذا يستهلك رموزًا أكثر بـ27 مرة على الأقل مقارنة بطلب بسيط. وفي خطة Claude Pro، يستنفد هذا الحساب الحد اليومي خلال بضع ساعات. وإذا كنت على خطة Max، فستستهلك حصة أسبوع كامل في يوم واحد.

نمط مضاد إضافي (من تجربتي): «50 وكيلًا ينفذون أعمالًا بلا جدوى».

عندما أطلع على مشاريع الآخرين، أرى هذا كثيرًا: «لدي 50 وكيلًا يعملون». أسأل: ماذا يفعلون؟ فإذا كان هؤلاء الوكلاء الخمسون ينفذون أعمالًا بلا جدوى. ينتجون أكوامًا من المخرجات غير الضرورية، وملخصات خامًا كثيرة، ومحتوى مكررًا، وجدرانًا من السجلات. ينفذ كل منهم شيئًا «مفيدًا عمومًا»، والنتيجة سياق يغرق في التفاصيل وفاتورة رموز بحجم فاتورة شركة صغيرة. لا يحل العمق 5 هذه المشكلة، بل يجعلها أسوأ. إذا لم يكن واضحًا أصلًا عند المستوى 1 من يفعل ماذا، فسيعني العمق 5 خمسة مستويات من الارتباك.

قبل إطلاق أي وكيل فرعي، اختبر الفكرة بالإجابة عن أربعة أسئلة خلال نصف دقيقة:

• ما الذي يفعله بالضبط (في جملة واحدة)؟
• ما الملفات التي يتعامل معها؟
• ماذا يعيد إلى والده؟
• من يتحقق من عمله؟

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

لماذا يؤدي التداخل من دون هندسة للسياق إلى 5 مستويات من الهلوسة؟#

هنا يسأل الناس كثيرًا: «حدّثت Claude Code وأضفت Agent إلى tools، والشجرة تُبنى، لكن الإجابة النهائية لا تزال بعيدة عن المطلوب. لماذا؟»

الإجابة بسيطة. يبدأ كل وكيل فرعي في Claude Code من الصفر. من الوثائق الرسمية:

في المستوى 1، يمكن إدارة الأمر: يمرر المنسق وصفًا موجزًا للمهمة إلى ابنه. لكن في المستوى 3، يتلقى الحفيد رسالة تفويض من والده، الذي لم يتلقَّ هو الآخر سوى رسالة تفويض. ولا ينقل كل مستوى إلا جزءًا مما وصله. وفي المستوى 5، يصبح لديك وكيل فرعي لا تحتوي نافذته إلا على عبارة «تحقق من الادعاء X»، ولا شيء سواها. فهو لا يعرف المشروع الذي يعمل فيه، ولا المهمة التي يحلها، ولا ما ينبغي أن يركز عليه.

من دون CLAUDE.md، يشبه حفيد المستوى الخامس موظفًا يحضر إلى المكتب لأول مرة في حياته من دون أي توجيه. سينفذ شيئًا ما لأنه تلقى مهمة، لكنه لن ينفذ ما يحتاج إليه المشروع.

لهذا السبب، الإعداد ضروري. العمق 5 من دون إعداد CLAUDE.md وbusiness/ وخط أنابيب للمهارات على نحو سليم أشبه بكازينو. ومعها يصبح أداة.

ما الذي تغيّر أيضًا في v2.1.172 إلى جانب التداخل؟#

افتح سجل التغييرات الكامل لـv2.1.172 وسترى أن الإصدار كله يدور حول الوكلاء الفرعيين.

الإصلاح 1. لم يعد الوكيل الفرعي الذي يعمل في الخلفية يظل «عالقًا» بوصفه نشطًا في لوحة الوكلاء بعد إيقاف الوكيل الفرعي المتداخل الذي أطلقه. لا يمكن أن يحدث هذا الخطأ إلا مع التداخل.

الإصلاح 2. تنطبق الآن قيود availableModels على الوكلاء الفرعيين أيضًا. في السابق، إذا قيّدت النماذج التي يمكن للفريق استخدامها (مثل منع opus لتوفير المال)، أمكن للوكلاء الفرعيين تجاوز القاعدة باستخدام إعداد تجاوز في إعداداتهم الخاصة. ومنذ v2.1.172، تنطبق القاعدة في كل مكان.

الإصلاح 3. يعرض السهم للأعلى في سجل المطالبات الآن مطالبات علامة التبويب الحالية للوكيل الفرعي، لا مطالبات الوكيل الرئيسي. تحسين لإمكانية التتبع.

الإصلاح 4. انخفض استهلاك وحدة المعالجة المركزية في وضع الخمول: لم يعد مؤشر /goal يعيد رسم الطرفية 5 مرات في الثانية أثناء الخمول، كما تعيد الواجهة الرسم بوتيرة أقل أثناء عمل الوكلاء الفرعيين المتوازيين.

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

قائمة تحقق: متى يساعد التداخل ومتى يضر؟#

استخدم التداخل إذا:

• كانت المهمة تتضمن عملًا فرعيًا فيه عدد كبير من طلبات الويب أو عمليات grep أو قراءات الملفات.
• كان من المقبول فقدان ذلك العمل الفرعي (إذا أعاد الحفيد «لم أجد شيئًا»، يستطيع المنسق مواصلة العمل).
• لم تكن بحاجة إلى النتائج الوسيطة في النافذة الرئيسية.
• كان لديك CLAUDE.md وسياق مشروع مُعدّ يمكن للوكيل الفرعي الاعتماد عليه.
• استطعت أن تصف بوضوح ما سيعيده كل مستوى (المدخلات والمخرجات والتنسيق).
• كنت تستخدم خطة Max أو لديك هامش لتحمّل ×27 من الرموز.

لا تستخدم التداخل إذا:

• كان وكيل فرعي واحد قادرًا على حل المهمة من دون ضجيج.
• كنت تحتاج إلى النتائج الوسيطة في النافذة الرئيسية (ما يعني أنك تريد التوازي).
• لم يكن للمشروع ملف CLAUDE.md أو لم يتضمن سوى قدر قليل من سياق العمل.
• كانت مطالبات المستوى 1 مبهمة (فهذا الغموض سيتضاعف أُسّيًا عبر الشجرة).
• كنت تحتاج إلى السرعة؛ فالتوازي أسرع من العمق للحصول على نتيجة مماثلة.
• كنت تستخدم خطة Pro وتعمل طوال اليوم؛ فستستنفد الحد خلال بضع ساعات.

تتوفر مواد إضافية على Ailoot.