وكلاء Claude Code الفرعيون: ما تعلمناه من تشغيل 18 وكيلًا في الإنتاج

ثمانية عشر وكيلًا فرعيًا (subagents) من Claude Code يشحنون كل منشور على هذا الموقع، بما فيه هذا المنشور نفسه. ستة منها تعمل على Opus، وأحد عشر على Sonnet، وواحد على Haiku. وكيل researcher وحده جمع 74 ملف ذاكرة منذ أن بدأنا. لا يتحدث أي منها إلى الآخر. هذا هو الجزء الذي فاجأنا أكثر من أي شيء: الوكيل الفرعي لا يرى محادثتك أبدًا، ولا يرى محادثة وكيل فرعي آخر أيضًا. لذلك بُني خط الأنابيب (pipeline) بأكمله حول ملفات على القرص بدلًا من ذلك. إليك الأسطول، وتوزيع النماذج، وإعداد الذاكرة، والأشياء التي تعطّلت في الطريق.

الخلاصة السريعة:

• يعمل الوكيل الفرعي داخل نافذة سياق (context window) خاصة به، بمطالبة نظام (system prompt) وأدوات وصلاحيات خاصة به.
• نُشغّل 18 وكيلًا فرعيًا: 6 على Opus، و11 على Sonnet، وواحد على Haiku.
• تُسلّم الوكلاء العمل عبر ملفات على القرص، لا عبر سياق مشترك أبدًا.
• اعتبارًا من v2.1.198، اختفى معالج الإنشاء /agents. اكتب الملف بنفسك.

ما هو الوكيل الفرعي (Subagent) في Claude Code؟

الوكيل الفرعي (subagent) في Claude Code هو مساعد متخصص يعمل داخل نافذة سياق (context window) خاصة به، بمطالبة نظام مخصصة، ووصول محدد للأدوات، وصلاحيات مستقلة. ينجز مهمة جانبية دون أن يُغرق محادثتك الرئيسية، ثم يُعيد فقط ملخصه. تُكتب التعريفات كملفات Markdown بترويسة أمامية (frontmatter) بصيغة YAML داخل .claude/agents/، وموثّقة في مرجع الوكلاء الفرعيين من Anthropic.

يُفوّض Claude المهمة إلى وكيل فرعي تلقائيًا. فهو يقرأ حقل description لكل وكيل فرعي يستطيع رؤيته، وعندما تتطابق مهمة معه، يُسلّم العمل دون أن يسألك أولًا. واعتبارًا من v2.1.198، تعمل هذه الوكلاء الفرعية في الخلفية افتراضيًا، لذلك يحدث التفويض غالبًا بينما لا تزال تكتب. يمكنك أيضًا استدعاء وكيل باسمه عندما تريد عاملًا محددًا لمهمة محددة.

يأتي Claude Code مع ثلاثة وكلاء مدمجين: Explore للبحث في قاعدة الكود بوضع القراءة فقط، وPlan لتخطيط العمل، وgeneral-purpose لكل ما عدا ذلك.

تفصيلة تسمية واحدة تُوقع الأدلة القديمة وملفات الإعداد القديمة في الخطأ: الأداة التي تُطلق وكيلًا فرعيًا تُسمى Agent، لا Task. أُعيدت تسميتها في v2.1.63، وتؤكد الوثائق أن مراجع Task(...) القائمة ما زالت تعمل كأسماء بديلة (aliases). نستخدم Agent في هذا المنشور بأكمله.

بقية هذا المنشور ليست مرجعًا. وثائق Anthropic تؤدي هذه المهمة أصلًا بشكل أفضل مما يمكننا، بنحو 8,000 كلمة مع حواشٍ توثّق الإصدارات حتى v2.1.212. ما يلي هو شكل ثمانية عشر وكيلًا فرعيًا فعليًا حين تعمل كل يوم.

أسطولنا المكوّن من 18 وكيلًا: كيف يبدو الإعداد الحقيقي على القرص

يحتوي دليلنا .claude/agents/ على 18 ملف تعريف وكيل فرعي، كل منها ملف Markdown بترويسة أمامية YAML. تُشغّل هذه الملفات معًا خط أنابيب المحتوى بأكمله لهذا الموقع: البحث، وكتابة الملخص التوجيهي (brief)، والكتابة، والتحقق من الجودة، والترجمة إلى تسع لغات، وتوليد الصور، والنشر. ستة تعمل على Opus، وأحد عشر على Sonnet، وواحد على Haiku.

كل دليل عن الوكلاء الفرعيين في الصفحة الأولى لنتائج Google يشرح بالمثال نفسه، code-reviewer، المنسوخ من الوثائق. إليك شكل ثمانية عشر وكيلًا فرعيًا حين يُنجزون العمل فعليًا.

.claude/agents/
├── abc-link-checker.md
├── brief-creator.md
├── content-gap-finder.md
├── content-refresher.md
├── content-writer.md
├── image-handler.md
├── language-translator.md
├── payload-publisher.md
├── pipeline-manager.md
├── rank-checker.md
├── rescue-diagnoser.md
├── rescue-prioritizer.md
├── researcher.md
├── sanity-publisher.md
├── seo-auditor.md
├── sitemap-checker.md
├── translation-coordinator.md
└── validator.md

تنقسم هذه الوكلاء إلى أربع مجموعات وظيفية. إنتاج المحتوى يمرّ عبر researcher ثم brief-creator ثم content-writer ثم validator. التوزيع يشمل translation-coordinator وlanguage-translator وimage-handler وpayload-publisher وsanity-publisher. الصيانة تشمل content-refresher وrank-checker وrescue-diagnoser وrescue-prioritizer وseo-auditor وsitemap-checker وabc-link-checker. أما التنسيق فيتولاه pipeline-manager وcontent-gap-finder.

ملفان من هذه الملفات، منسوخان حرفيًا من القرص، يحملان حجة التكلفة بأكملها:

# .claude/agents/researcher.md
name: researcher
tools: Read, Write, Glob, Grep, WebSearch, WebFetch, Bash
model: opus
memory: project
skills:
  - seo
  - competitor-analysis

# .claude/agents/sitemap-checker.md
name: sitemap-checker
tools: Read, Write, Edit, Glob, Grep, WebFetch
model: haiku

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

يُحمّل حقل skills: في researcher مسبقًا تعريفي مهارتين في مطالبة نظام ذلك الوكيل الفرعي وقت إطلاقه، وهذه هي الطريقة التي يعرف بها أعرافنا الخاصة بالسيو دون أن يُخبَر بها في كل تشغيل. إن لم تكن قد كتبت مهارة من قبل، فقد شرحنا كيف تكتب مهارة Claude في منشور منفصل، ولن نكرر ذلك هنا.

إن أردت كتالوجًا يمكنك تصفّحه لتعريفات جاهزة للنسخ، فمجموعة المجتمع awesome-claude-code-subagents هي ما يبحث عنه الناس فعليًا. اقرأها للاطلاع على الأشكال والأنماط، لا على حداثة المعلومات: بعض المُدخلات فيها أقدم من إعادة تسمية Agent.

كيف تُنشئ وكيلًا فرعيًا؟ (معالج /agents اختفى)

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

1. أنشئ الملف. .claude/agents/{name}.md لوكيل فرعي على مستوى المشروع يُشحن ضمن نظام التحكم بالإصدارات، أو ~/.claude/agents/{name}.md لوكيل يرافقك عبر كل مشاريعك.
2. اكتب name وdescription. يحدد description أكثر من أي شيء آخر في الملف، لأنه ما يطابقه Claude عند اختيار ما إذا كان سيفوّض المهمة. اكتبه كقاعدة توجيه (routing rule)، لا كمسمى وظيفي.
3. اضبط tools وmodel. tools قائمة سماح (allowlist)؛ احذفها فيرث الوكيل الفرعي أدوات المحادثة الرئيسية. model يتجاوز نموذج جلستك.
4. اكتب مطالبة النظام (system prompt) كمتن Markdown أسفل الترويسة الأمامية. يستقبل الوكيل الفرعي هذه المطالبة فقط بالإضافة إلى تفاصيل بيئة أساسية، لا مطالبة نظام Claude Code الكاملة.
5. استدعِه. تلقائيًا، بترك description يتطابق، أو صراحةً بطلبه باسمه.

---
name: changelog-writer
description: Writes release notes from merged pull requests. Use when the user asks for a changelog, release notes, or a summary of what shipped.
tools: Read, Grep, Glob, Bash
model: sonnet
---

You write release notes. Read the merged PRs since the last tag with `git log`,
group them into Added / Changed / Fixed, and write one line per change in past
tense. Never invent a change that is not in the log. Return only the markdown.

لا تزال عدة أدلة مصنَّفة حاليًا في محركات البحث تخبر القراء بتشغيل /agents لفتح واجهة الإدارة. تلك التعليمة لم تعد صالحة. مأزق آخر تنص عليه الوثائق صراحة: مراقب الملفات (file watcher) يغطي فقط الأدلة (directories) الموجودة عند بدء الجلسة، لذا يحتاج أول ملف وكيل في دليل agents/ جديد تمامًا إلى إعادة تشغيل Claude Code قبل أن يُحمَّل.

وكيل فرعي أم مهارة أم فريق وكلاء أم Fork: أيّها تحتاج فعليًا؟

اختر وكيلًا فرعيًا حين تكون المهمة الجانبية ستُغرق محادثتك الرئيسية وتحتاج فقط إلى الملخص. اختر مهارة (skill) حين تريد تعليم Claude إجراءً يُشغّله داخل سياقك الحالي. اختر فريق وكلاء (agent team) حين يجب على العمّال التنسيق مع بعضهم. اختر Fork حين تحتاج المهمة الجانبية إلى تاريخ محادثتك.

تُقدّم الوكلاء الفرعية تقاريرها إليك، ولا تتراسل مع بعضها أبدًا. فرق الوكلاء (agent teams) تتراسل مباشرة مع بعضها. هذا الفارق الوحيد هو ما يحدد أيّ نمط أساسي (primitive) تحتاجه.

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

اختيار النموذج: أيّ الوكلاء يوضَع على Haiku وSonnet وOpus

اضبط model في الترويسة الأمامية لأي وكيل فرعي على haiku أو sonnet أو opus أو معرّف نموذج محدد، وسيتجاوز ذلك الوكيل الفرعي نموذج جلستك. توزيعنا الفعلي عبر الوكلاء الـ18 هو ستة على Opus، وأحد عشر على Sonnet، وواحد على Haiku، مُوزَّعة بحسب مقدار الحُكم (judgment) الذي تتطلبه مخرجات الوكيل فعليًا.

ثلاث قواعد نُقدّمها لأي شخص يُدرّج أسطولًا في فئات. ضع وكيلًا على Haiku حين تكون مخرجاته محددة سلفًا ومُدخله صغيرًا: الجلب، والتحليل النحوي (parsing)، والعدّ، وإعادة التنسيق. ضع وكيلًا على Sonnet حين تكون المهمة طويلة ومحددة جيدًا، لكن شخصًا ما قرر مسبقًا كيف تبدو "الإجابة الصحيحة"، وهذا يغطي معظم أعمال التنفيذ بما فيها كل عمّال الترجمة التسعة. احفظ Opus للوكلاء الذين لن يُعيد أحد لاحقًا في خط الأنابيب النظر في مخرجاتهم.

هذه القاعدة الأخيرة هي سبب وضع validator على Opus رغم أنه يُنتج تقريرًا قصيرًا. لا أحد يراجع المراجِع.

ملاحظة نسخة واحدة تُغيّر الحساب: منذ v2.1.198، لم يعد الوكيل الفرعي المدمج Explore يعمل دائمًا على Haiku، بل يرث نموذج الجلسة. أي وكيل فرعي على مستوى المستخدم أو المشروع باسم Explore يتجاوز المدمج ويحتفظ بحقل model الخاص به، لذا عرّف واحدًا بـmodel: haiku إن أردت إبقاء الاستكشاف على نموذج رخيص.

عقود الملفات: كيف تُسلّم وكلاؤنا العمل دون مشاركة السياق

لا يرى الوكيل الفرعي تاريخ محادثتك، ولا يرى تاريخ أي وكيل فرعي آخر. لذلك فإن التسليم داخل الذاكرة (in-memory) بين الوكلاء مستحيل بنيويًا. الحل هو جعل كل عملية تسليم أثرًا (artifact) على القرص، بحيث يقرأ الوكيل التالي ملفًا بدلًا من أن يرث سياقًا لن يملكه أبدًا.

techsy.community/posts/claude-code-subagents/
├── research.md      # researcher       → SERP analysis, keyword data, gaps
├── brief.md         # brief-creator    → section-by-section spec
├── en.md            # content-writer   → the post you are reading
├── de.md            # language-translator (one subagent per language)
├── hero.webp        # image-handler
├── validation.md    # validator
└── meta.json        # pipeline stage, updated by a PostToolUse hook

خمسة آثار (artifacts)، كل منها يكتبه وكيل مختلف، ويقرؤه الوكيل التالي، وكلها قابلة للقراءة من إنسان ومتتبَّعة في git. يصمد خط الأنابيب أمام حدود السياق لأن أي وكيل لا يحتاج أبدًا إلى سياق وكيل آخر. هو يحتاج فقط إلى ملف الوكيل السابق.

أوضح مكسب لهذا هو الترجمة. يقرأ translation-coordinator ملف en.md، ثم يُطلق وكيلًا فرعيًا واحدًا من language-translator لكل لغة، تسعة أو عشرة في آنٍ واحد. في مستودعنا، تتوقف إمكانية التشغيل المتزامن على إصدار كل استدعاءات الإطلاق ضمن رسالة واحدة: هذا سلوك لاحظناه في إعدادنا لا شيء تنص عليه الوثائق، لكنه كان ثابتًا بما يكفي لأن يُكتب المنسّق (coordinator) ليفعل ذلك عن قصد. يكتب كل مترجم ملف {lang}.md الخاص به، ولا يستطيع أي منهم رؤية عمل الآخرين، وهذا لا بأس به، لأن العقد هو الملف والملف مكتمل بالفعل.

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

كيف تتذكر الوكلاء الفرعية الأشياء بين الجلسات؟

فقط إن ضبطت حقل memory، الذي يقبل ثلاثة نطاقات: user يكتب إلى ~/.claude/agent-memory/<name>/، وproject يكتب إلى .claude/agent-memory/<name>/، وlocal يكتب إلى .claude/agent-memory-local/<name>/. من دونه، يبدأ كل استدعاء فارغًا. يُعلن 12 من وكلائنا الثمانية عشر memory: project.

بعد نحو أربعين منشورًا، أصبحت هذه الأدلة (directories) كبيرة فعلًا. يحمل researcher 74 ملف ذاكرة، وvalidator 66، وbrief-creator 65. هي ليست سجلات (logs). إنها أحكام متراكمة: أنماط العناوين H1 التي لم تُحقق أداءً جيدًا، والادعاءات عن العملاء التي لا يمكننا كتابتها، وأشكال SERP التي تُكافئ جدولًا بدلًا من نص نثري.

إليك القيد الذي يُشكّل كل هذا. يحصل الوكيل الفرعي المُفعَّلة له الذاكرة على أول 200 سطر فقط أو 25 كيلوبايت من MEMORY.md تُحقن في مطالبة نظامه، أيهما أسبق. هذا القيد الوحيد هو سبب احتفاظ كل وكيل من وكلائنا بفهرس بدلًا من سجل يومي.

# Researcher Memory

## Reusable post patterns
- [Challenger H1 pattern](feedback_challenger_h1_pattern.md): when a question-shaped H1 earns the click
- [Sponsored post research](feedback_sponsored_post_research.md): H1 must be category-shaped, never a review
- [Claude Skills tutorial](project_claude_skills_tutorial.md): docs own the top two slots, target the long tail

سطر واحد لكل مُدخل، وتفاصيله مدفوعة إلى ملف الموضوع المرتبط، الذي يقرؤه الوكيل عند الحاجة باستخدام أداة Read الخاصة به. يبقى MEMORY.md فهرسًا يتسع ضمن ميزانية الحقن بينما ينمو المتن الكامن خلفه دون حد.

نستخدم project بدلًا من user في كل شيء تقريبًا، لأن ذاكرة المشروع تعيش في المستودع وتنتقل عبر نظام التحكم بالإصدارات. حين يسحب (pull) أحد أعضاء الفريق، فهو يسحب حُكم الوكيل المتراكم مع الكود. أما local فموجود للحالات التي تريد فيها الملاحظات دون الالتزام (commit).

ما الذي تعطّل: أنماط الفشل، الأسماء المكررة، واسم بديل قديم في مستودعنا نفسه

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

مشكلة الاسم المكرر أسوأ مما تبدو عليه. تُحرّر ملفًا، ولا يتغير السلوك، ولا يظهر أي خطأ في أي مكان، لأن ملفًا آخر يحمل الاسم نفسه فاز بترتيب القراءة.

ساعدتنا الخطافات (hooks) أكثر مما توقعنا في معالجة الإخفاقات التي ليست أخطاء بالمرة، بل مجرد خطوات ينساها الإنسان. خطافنا بسيط عن قصد:

"SubagentStop": [
  {
    "matcher": "content-writer",
    "hooks": [
      {
        "type": "command",
        "command": "echo 'Content writer finished. Run /validate to check quality and SEO compliance.'"
      }
    ]
  }
]

والآن الجزء الصادق. أثناء كتابة هذا المنشور، بحثنا (grepped) في أسطولنا نفسه ووجدنا هذا لا يزال قابعًا في translation-coordinator.md:

# .claude/agents/translation-coordinator.md
name: translation-coordinator
tools: Read, Write, Glob, Grep, Task
model: sonnet

Task، لا Agent. هذا الحقل بالٍ منذ v2.1.63 ولم يفشل ولو مرة واحدة، لأن Anthropic أبقت على الاسم البديل. لم ننظّفه بعد. إن كانت ملفات وكلائك الخاصة لا تزال تكتب Task، فهي ليست معطّلة، بل قديمة فقط، والاسم البديل يقوم بعمل صامت في كثير من المستودعات الآن.

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

ما تكلفه الوكلاء الفرعية، ومتى لا تستخدم واحدًا

كل عملية إطلاق لوكيل فرعي تُنشئ نافذة سياق جديدة، لذا فإن التفويض ليس مجانيًا أبدًا. يُفيد فريق الهندسة في Anthropic أن الوكلاء تستهلك توكنات أكثر بنحو 4 أضعاف من تفاعلات الدردشة، وأن أنظمة الوكلاء المتعددة تستهلك أكثر بنحو 15 ضعفًا، وأن استهلاك التوكنات وحده يُفسّر 80% من تباين الأداء الذي قاسوه.

ليس لدينا قياسات توكنات خاصة بنا نضيفها، لذا تعامل مع أي مُضاعِف محدد تقرأه حول هذا الموضوع، بما في ذلك أرقام 4x إلى 7x المُتداولة في منشورات مدونات أخرى، على أنه رقم ذلك الكاتب لا معيارًا مرجعيًا. تقرير نظام البحث متعدد الوكلاء من Anthropic هو المصدر الوحيد هنا المدعوم ببيانات حقيقية، ووجدت الدراسة نفسها أن وكيلًا قائدًا على Opus مع وكلاء فرعيين على Sonnet تفوّق على وكيل Opus وحيد بنسبة 90.2% في تقييمهم الداخلي. تلك النتيجة، لا عدد التوكنات، هي الحجة الداعمة لتوزيع الفئات (tiering).

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

سقف الـ200 لكل جلسة يستحق معرفته قبل أن تُصمم عملية تفريع (fan-out). إنه سقف حقيقي على التفويض الجامح، ورفعه فعل متعمّد لا إعداد افتراضي.

عن الكاتب

مرت باتور (Mert Batur) يبني في Techsy، حيث يشحن الفريق وكلاء ذكاء اصطناعي، وأنظمة أتمتة، ومسارات صوت وSDR لعملاء B2B. يكتب عن حزمة أدوات LLM ومهارات Claude (Claude Skills) التي يستخدمها فريق Techsy فعليًا في الإنتاج.

Techsy — جامعة برمنغهام (University of Birmingham) · LinkedIn

الأسئلة الشائعة

ما هي الوكلاء الفرعية في Claude Code؟

الوكلاء الفرعية في Claude Code مساعدون متخصصون يعمل كل منهم داخل نافذة سياق خاصة به، بمطالبة نظام مخصصة، ووصول مقيَّد للأدوات، وصلاحيات مستقلة. تُعرّف واحدًا منها كملف Markdown بترويسة أمامية YAML داخل .claude/agents/. يُنجز الوكيل الفرعي مهمة جانبية ويُعيد فقط ملخصها إلى محادثتك الرئيسية.

هل يستخدم Claude Code الوكلاء الفرعية تلقائيًا؟

نعم. يقرأ Claude حقل description لكل وكيل فرعي متاح له، ويُفوّض المهمة عند تطابقها دون أن يسألك أولًا. اعتبارًا من v2.1.198، تعمل الوكلاء الفرعية في الخلفية افتراضيًا، لذا يحدث العمل المُفوَّض غالبًا بينما تستمر في الكتابة في المحادثة الرئيسية.

أين تُخزَّن ملفات الوكلاء الفرعية؟

تُخزَّن الوكلاء الفرعية على مستوى المشروع في .claude/agents/، وعلى مستوى المستخدم في ~/.claude/agents/. يُمسح كلا الموقعين بشكل تكراري (recursively)، فالمجلدات الفرعية لا تُشكّل مشكلة. تأتي الهوية فقط من حقل name في الترويسة الأمامية، لا من المسار أبدًا. الوكلاء الفرعية المُدارة التي ينشرها مسؤول النظام لها الأولوية على تعريفات المشروع والمستخدم التي تشارك الاسم نفسه.

كيف أستدعي وكيلًا فرعيًا صراحةً؟

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

هل يستطيع الوكيل الفرعي إطلاق وكلاء فرعيين خاصين به؟

نعم، منذ Claude Code v2.1.172. الأدلة المكتوبة قبل ذلك الإصدار تنص على استحالة التداخل (nesting)، وهي بالية. يُحسب العمق بعدد المستويات أسفل المحادثة الرئيسية وهو ثابت عند خمسة: الوكيل الفرعي عند العمق الخامس لا يحصل على أداة Agent. الحد غير قابل للتهيئة.

هل تتذكر الوكلاء الفرعية أي شيء بين الجلسات؟

فقط إن ضبطت حقل memory. يقبل user لـ~/.claude/agent-memory/<name>/، وproject لـ.claude/agent-memory/<name>/، وlocal لـ.claude/agent-memory-local/<name>/. من دونه، يبدأ كل استدعاء فارغًا. يستخدم 12 من وكلائنا الثمانية عشر memory: project حتى تنتقل ملاحظاتها عبر نظام التحكم بالإصدارات.

هل يمكن للوكيل الفرعي استخدام نموذج مختلف عن جلستي؟

نعم. اضبط model في الترويسة الأمامية على haiku أو sonnet أو opus أو معرّف نموذج محدد، وسيتجاوز نموذج جلستك لذلك الوكيل الفرعي. يتوزع أسطولنا على ستة على Opus، وأحد عشر على Sonnet، وواحد على Haiku، بحسب مقدار الحُكم الذي تتطلبه مخرجات كل وكيل.

لماذا لا يظهر وكيلي الفرعي الجديد؟

ثلاثة أسباب معتادة. لم يكن دليل agents موجودًا عند بدء الجلسة، فلم يلتقطه المراقب أبدًا: أعد تشغيل Claude Code. أو يشترك ملفان في الاسم name نفسه ولا يُحمَّل سوى أحدهما. أو لا شيء في قائمة tools قابل للحل، وهذا منذ v2.1.208 يرفض الإطلاق برسالة خطأ تُسمّي المشكلة.

هل ما زال Task اسم أداة صالحًا؟

نعم، كاسم بديل. أُعيدت تسمية أداة Task إلى Agent في v2.1.63، وما زالت مراجع Task(...) القائمة تعمل في الإعدادات وتعريفات الوكلاء. اكتب Agent في الملفات الجديدة. ملفنا translation-coordinator.md ما زال يُعلن Task، وهو ما وجدناه أثناء كتابة هذا المنشور ولم ننظّفه بعد.

ثلاثة أشياء يجب أن تأخذها معك

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

استكشف المكتبة الكاملة للاطلاع على المواصفات الكامنة خلف خط الأنابيب هذا.