# الوكلاء الفرعيون في Claude Code: البنية وخمسة أدوار والتنسيق > ملف الوكيل، والوصف، وخمسة قوالب كاملة، والتنفيذ المتوازي، وManaged Agents، والقيود والتكلفة، مع الحفاظ على الأمثلة. Source: https://ailoot.ai/blog/ar/claude-code-subagents/ Canonical: https://ailoot.ai/blog/ar/claude-code-subagents/ Language: ar Publisher: Ailoot (https://ailoot.ai/) Translation: guide-222 Revision: sha256-f7d89496a14b5df32d1d85944a006be59b16e786fdc07fdc5e5a5580d6bf60ba
الخلاصات الأساسية الوكيل الفرعي في Claude Code هو مساعد ذكاء اصطناعي متخصص له سياقه الخاص ومجموعة أدواته وموجّه النظام الخاص به. تقرر المحادثة الرئيسية من تلقاء نفسها ما إذا كانت ستفوّض إليه مهمة، أو يمكنك استدعاؤه بالاسم باستخدام `@agent-`. يتولى الوكيل الفرعي مهمة محددة من دون إرباك المحادثة الرئيسية، ولا يعيد سوى ملخص نهائي. أشرح في هذا الدليل كيف يختلف الوكيل الفرعي عن Skill، وكيف تكتب وصفًا يجعل Claude يستدعيه فعلًا، وأعدّ 5 أدوار عملية في 30 دقيقة.
تجد التعليمات العملية للعمل مع Ailoot في [التوثيق](https://ailoot.ai/docs/).
## ما الوكيل الفرعي في Claude Code، ولماذا ليس «مجرد Skill أخرى»؟
الخلاصات الأساسية الوكيل الفرعي مساعد ذكاء اصطناعي متخصص له سياقه الخاص وموجّه النظام الخاص به ومجموعة أدواته. تصفه وثائق Anthropic الرسمية بأنه مساعد يتولى مهمة جانبية في سياق منفصل، ولا يعيد سوى ملخص للنتيجة. وعلى خلاف [Skills](https://ailoot.ai/blog/ar/claude-code-skills-library/)، التي تُحمّل في المحادثة الرئيسية وتعمل بذاكرتها، يعمل الوكيل الفرعي في عزلة، وهذه هي ميزته الأساسية.
تعرّف وثائق Claude Code الوكيل الفرعي على النحو الآتي:

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

— توثيق Claude Code، https://code.claude.com/docs/en/sub-agents
وبعبارات يفهمها رائد الأعمال: تخيّل وكالة عقارية. فيها مدير ومسوق ومحامٍ ومديرو مبيعات. إن تنقّل موظف واحد بين كل هذه الأدوار لا يصنع فريقًا؛ بل يجعل شخصًا واحدًا مثقلًا بالعمل. يتكوّن الفريق عندما يكون لكل شخص سياقه الخاص ومجال مسؤوليته، بينما يوزّع المدير المهام ويجمع النتائج فحسب. تعمل الوكلاء الفرعيون في Claude Code بالطريقة نفسها. المحادثة الرئيسية هي المدير. والوكيل الفرعي متخصص بمهمة محددة وسياق ومجموعة أدوات خاصة به. عندما تتوافق المهمة مع وصف متخصص ما، يفوّضها إليه المدير، ولا يغرق في التفاصيل. ### 5 أهداف صممت Anthropic الوكلاء الفرعيين لتحقيقها تسرد وثائق Anthropic خمسة أسباب بالضبط لإنشاء وكيل فرعي خاص بك:

تساعدك الوكلاء الفرعيون على الحفاظ على السياق بإبقاء البحث والتنفيذ خارج المحادثة الرئيسية؛ وفرض القيود من خلال حصر الأدوات التي يمكن للوكيل الفرعي استخدامها؛ وإعادة استخدام الإعدادات بين المشاريع عبر الوكلاء الفرعيين على مستوى المستخدم؛ وتخصيص السلوك لمجالات محددة عبر موجّهات نظام مركزة؛ والتحكم في التكلفة بتوجيه المهام إلى نماذج أسرع وأقل تكلفة مثل Haiku.

— توثيق Claude Code، https://code.claude.com/docs/en/sub-agents
أكثر نقطة عملية في هذه القائمة لغير المبرمجين هي **التحكم في التكلفة**. يمكنك إرسال مهمة بحث مكثفة إلى نموذج Haiku منخفض التكلفة، مع مواصلة المحادثة الرئيسية على Sonnet أو Opus. ويتناسب توفير الرموز تناسبًا مباشرًا مع ذلك. ### تحقق من دعم التداخل في إصدارك المثبت تستخدم قوالب الدليل جلسة رئيسية تفوض العمال مباشرة. لا تعتبر توثيقًا قديمًا يقول «لا يمكن للوكلاء الفرعيين إطلاق آخرين» قاعدة دائمة؛ يتوقف سلوك التداخل على الإصدار المثبت والأدوات المسموحة. يناقش [دليل الوكلاء الفرعيين المتداخلين](https://ailoot.ai/blog/ar/claude-code-nested-subagents/) وصفة خاصة بإصدار. تحقق من الدعم في تثبيتك قبل تخطيط تفويض أعمق. ## ما الفرق بين الوكيل الفرعي وSkill وأمر الشرطة المائلة وHook؟
الخلاصات الأساسية لدى Claude Code أربع آليات للتوسعة، وهي ليست قابلة للتبادل. تمثل CLAUDE.md معرفة دائمة تُحمّل دائمًا. أما Skills فهي منهجيات جاهزة تُحمّل في المحادثة الرئيسية عند استدعائها. وأوامر الشرطة المائلة أزرار `/command` صريحة لتنفيذ إجراء لمرة واحدة. والوكلاء الفرعيون متخصصون يفوض إليهم سياق المحادثة الرئيسية المهام. وأكثر الأخطاء شيوعًا هو إنشاء وكيل فرعي عندما تكون الحاجة إلى Skill.
يوضح الدليل السابق عن [Skills](https://ailoot.ai/blog/ar/claude-code-skills-library/) أن Skills وأوامر الشرطة المائلة في Claude Code اندمجت فعليًا في تنسيق واحد. لكن الوكيل الفرعي كيان مختلف، وليس «Skill أكبر» فحسب. جدول موجز للآليات الأربع: | الميزة | CLAUDE.md | Skill | أمر الشرطة المائلة | الوكيل الفرعي | |----|----|----|----|----| | وقت التحميل | دائمًا | عند تفعيل الوصف | عند إصدار أمر صريح `/name` | عند التفويض أو `@agent-name` | | مكان العمل | في السياق الرئيسي | في السياق الرئيسي | في السياق الرئيسي | في سياقه المعزول الخاص | | النموذج | نفسه المستخدم في المحادثة الرئيسية | نفسه | نفسه | أي نموذج: Haiku أو Sonnet أو Opus أو وراثة النموذج | | الأدوات | كل الأدوات المتاحة | يرث الأدوات | يرث الأدوات | يمكن حصرها باستخدام `tools:` | | ما يعيده | \- | ضمن المحادثة الرئيسية | ضمن المحادثة الرئيسية | الملخص النهائي فقط | | التوازي | \- | لا | لا | نعم، عدة وكلاء بالتوازي | | الذاكرة بين الجلسات | الملفات القريبة | الملفات القريبة | الملفات القريبة | الحقل `memory: user/project/local` | يمكن التعبير عن ذلك جيدًا في دليل باللغة الإنجليزية: Skills وصفات، والوكلاء الفرعيون زملاء متخصصون. ضعها ببساطة: المهارات وصفات، والوكلاء الفرعيون زملاء متخصصون. عمليًا، تسير الأمور هكذا: تُفعّل Skills تلقائيًا عندما يطابق وصفها المهمة، بينما يُستدعى الوكلاء الفرعيون صراحةً، إما عندما تقرر المحادثة الرئيسية التفويض أو عندما تستدعي أحدهم بالاسم. ### شجرة القرار: «أي خيار أختار؟» عندما تفكر: «أحتاج إلى أن ينفذ Claude كذا»، مرّر الأمر عبر هذه الأسئلة الأربعة: 1. **هل هذه معرفة ينبغي أن تكون متاحة دائمًا؟** مثلًا: «نترجم إلى اللغة التي يفضلها المستخدم» أو «لا نستخدم الشرطات الطويلة». ضعها في `CLAUDE.md`. 2. **هل هذه منهجية تُستدعى عند تحقق شرط، وتنفذها يدويًا الآن؟** مثلًا: «أكتب تقرير مبيعات كل يوم اثنين». أنشئ **Skill**. 3. **هل ستستهلك هذه المهمة سياق المحادثة الرئيسية، أم يمكن تنفيذها بالتوازي؟** مثلًا: «بحث معمّق في 30 مصدرًا» أو «تدقيق أمني بينما أكتب ميزة جديدة». أنشئ **وكيلًا فرعيًا**. 4. **هل تحتاج إلى استجابة تلقائية لحدث في Claude Code؟** مثلًا: «شغّل أداة فحص الشيفرة بعد كل Edit». اكتب **Hook**. تقع 90% من مهام رواد الأعمال ضمن الفئتين الأوليين. الوكلاء الفرعيون أداة متقدمة، تُستخدم عند الانتقال من «مهمة واحدة في كل مرة» إلى التنسيق. ## أين توجد ملفات الوكلاء الفرعيين، وأيها له الأولوية؟
الخلاصات الأساسية توجد وكلاء Claude Code الفرعيون في خمسة أماكن ذات أولويات مختلفة، بدءًا من الإعدادات المُدارة للمؤسسة وصولًا إلى الإضافات. إذا تطابقت أسماء ملفين، يفوز الملف الأعلى أولوية. وأكثر إعداد شيوعًا لرائد أعمال يعمل منفردًا هو `~/.claude/agents/` للوكلاء الشخصيين متعددي الأغراض، و`.claude/agents/` داخل مشروع محدد للوكلاء الخاصين بذلك المشروع.
يتضمن تسلسل الوكلاء الفرعيين خمسة مستويات، مرتبة من أعلى أولوية إلى أدناها: | المستوى | المسار | نطاق التطبيق | الأولوية | |----|----|----|----| | المؤسسة | الإعدادات المُدارة للمؤسسة | جميع موظفي الشركة | 1 (الأعلى) | | الجلسة | خيار CLI ‏`--agents` مع JSON | الجلسة الحالية فقط | 2 | | المشروع | `.claude/agents/name.md` | هذا المشروع فقط | 3 | | الشخصي | `~/.claude/agents/name.md` | جميع مشاريعك | 4 | | الإضافة | `/agents/name.md` | حيثما تكون الإضافة مفعّلة | 5 (الأدنى) | منطق الأولوية مماثل لمنطق Skills وCLAUDE.md: تتقدم إعدادات المؤسسة على CLI، ويتقدم CLI على المشروع، ويتقدم المشروع على الإعدادات الشخصية، وتتقدم الشخصية على الإضافة. ### ما ينبغي معرفته عن التحميل تُحمّل الوكلاء الفرعيون عند بدء جلسة Claude Code. إذا عدّلت ملف وكيل يدويًا على القرص، فلن تُطبّق التغييرات حتى تعيد تشغيل الجلسة. أما التعديلات عبر واجهة `/agents` التفاعلية فتُطبّق فورًا. وكيل فرعي واحد لكل نطاق يعني ملفًا واحدًا. إذا احتوى `.claude/agents/` على `code-reviewer.md` وملف آخر بالاسم نفسه بجانبه (مثلًا من نسخة احتياطية قديمة)، فسيتجاهل Claude Code أحدهما بصمت. ولن يظهر أي إشعار. أما وكلاء الإضافات الفرعيون فلهم وضع مختلف. إذ تفرض عليهم قيود أمنية: **لا يدعمون** حقول `hooks` و`mcpServers` و`permissionMode`. يمنع هذا تثبيت إضافة من طرف ثالث من منحها إذنًا لتشغيل شيفرة عشوائية على جهازك. ## انشاء وكيل ذكاء اصطناعي فرعي في Claude Code: Frontmatter والمتن {#بنية-ملف-الوكيل-الفرعي-frontmatter-والمتن}
الخلاصات الأساسية الوكيل الفرعي ملف Markdown واحد، في أوله YAML frontmatter وتحته موجّه النظام. الحد الأدنى يتكون من حقلين: `name` (أحرف صغيرة مع شرطات) و`description` (متى ينبغي لـ Claude التفويض). يتضمن المخطط الكامل 16 حقلًا: tools وdisallowedTools وmodel وpermissionMode وmaxTurns وskills وmcpServers وhooks وmemory وbackground وeffort وisolation وcolor وinitialPrompt. توصي Anthropic بإبقاء الوصف موجزًا؛ فكلما كان المحفّز أوضح، زادت دقة تفعيل Claude له.
مثال بسيط من الوثائق الرسمية، لا يتجاوز 9 أسطر: ```markdown --- name: code-reviewer description: يراجع الشيفرة من حيث الجودة وأفضل الممارسات tools: Read, Glob, Grep model: sonnet --- أنت مراجع شيفرة. عند استدعائك، حلّل الشيفرة وقدّم ملاحظات محددة وقابلة للتنفيذ حول الجودة والأمان وأفضل الممارسات. ``` هذا كافٍ. إذا قال مستخدم «راجع طلب السحب الخاص بي» في المحادثة الرئيسية، يطابق Claude بين «مراجع / شيفرة / جودة» والوصف، ويفوّض المهمة إلى الوكيل الفرعي. يقرأ الوكيل الفرعي الفروق، ويكتب التعليقات، ويعيد ملخصًا إلى المحادثة الرئيسية. ولا تمتلئ المحادثة الرئيسية بالسجلات والتحليلات الوسيطة. ### المخطط الكامل لـ Frontmatter | الحقل | مطلوب | وظيفته | |----|----|----| | `name` | نعم | معرّف فريد، أحرف صغيرة مع شرطات. لا يلزم أن يطابق اسم الملف | | `description` | نعم | متى يفوض Claude. هذا هو محفّز الأتمتة | | `tools` | لا | قائمة الأدوات المسموح بها. إذا أُغفل، يرث جميع أدوات الوكيل الأب | | `disallowedTools` | لا | قائمة الحظر. تُطبّق أولًا، ثم `tools` | | `model` | لا | `haiku` / `sonnet` / `opus` / المعرّف الكامل / `inherit` (افتراضيًا) | | `permissionMode` | لا | `default` / `acceptEdits` / `auto` / `dontAsk` / `bypassPermissions` / `plan` | | `maxTurns` | لا | حدّ للخطوات قبل التوقف | | `skills` | لا | Skills التي تُحمّل في سياق الوكيل الفرعي عند بدء التشغيل | | `mcpServers` | لا | خوادم MCP المتاحة لهذا الوكيل الفرعي فقط | | `hooks` | لا | ‏PreToolUse / PostToolUse / Stop، محددة لهذا الوكيل الفرعي | | `memory` | لا | `user` / `project` / `local` — مجلد للذاكرة بين الجلسات | | `background` | لا | `true` — التشغيل دائمًا في الخلفية. القيمة الافتراضية `false` | | `effort` | لا | `low` / `medium` / `high` / `xhigh` / `max` — مستوى الاستدلال | | `isolation` | لا | `worktree` — التشغيل في شجرة عمل منفصلة لـ git | | `color` | لا | لون واجهة المستخدم: red / blue / green / yellow / purple / orange / pink / cyan | | `initialPrompt` | لا | أول عبارة يراها الوكيل الفرعي عند تشغيله عبر `--agent` | الحقل `model: haiku` هو تحديدًا مثال «التحكم في التكلفة» المذكور ضمن الأهداف الخمسة. إذا كان لديك وكيل بحث يقرأ 50 صفحة من الوثائق، فشغّله على Haiku لتوفير ما يعادل 5–7 مرات مقارنةً بـ Opus. يحل حقل `isolation: worktree` مشكلة مهمة: قد يجري الوكيل الفرعي تغييرات خطرة محتملة، مثل إعادة الهيكلة أو الترحيل، بينما لا تريد أن يمس نسخة عملك. اضبط `isolation: worktree`، وسيُنشئ Claude Code نسخة مؤقتة من المشروع عبر git؛ يعمل الوكيل الفرعي فيها ويعيد الفروق لمراجعتها. ### متن الملف هو موجّه النظام ما يأتي بعد frontmatter هو Markdown عادي، أي موجّه النظام الخاص بالوكيل الفرعي. لا يلزم تنسيق خاص، لكن هذا النمط مجرّب: 1. **من تكون** — جملة واحدة: «أنت مراجع شيفرة» أو «أنت مدقق أمني» أو «أنت مسؤول صيانة الوثائق». 2. **متى تُستدعى وما أول ما تفعله** — أول إجراءين أو ثلاثة بعد استلام المهمة. 3. **قائمة تحقق من الفحوص أو الخطوات** — من 5 إلى 10 نقاط يتبعها الوكيل الفرعي. 4. **ما الذي تعيده** — تنسيق التقرير النهائي. وهذا مهم: إذا لم تحدد تنسيقًا، فسيكتب الوكيل الفرعي «مقالة» بدلًا من ملخص منظم. 5. **ما الذي لا تفعله** — قيود واضحة. من دون هذا القسم، يبدأ الوكيل الفرعي بالارتجال. أبقِ متن الملف بين 200 و500 سطر. إذا طال أكثر من ذلك، فانقل المراجع الطويلة إلى ملفات قريبة منفصلة واربطها في الموجّه. ## كيف تكتب وصفًا يجعل Claude يستدعي الوكيل الفرعي بالتأكيد
الخلاصات الأساسية الوصف هو الحقل الوحيد الذي يراه Claude عند بدء الجلسة، ويستخدمه ليقرر ما إذا كان سيفوّض. وأكثر شكوى شيوعًا في المنتديات هي: «كتبت وكيلًا فرعيًا، لكن Claude لا يستدعيه». الحل صيغة من ثلاثة أجزاء: ما الذي يفعله + عبارات محفّزة بين علامتي اقتباس + متى لا ينبغي استخدامه. وتوصي Anthropic صراحةً بتضمين عبارات مثل “use proactively” أو “use immediately after” في الوصف لتشجيع Claude على استدعائه.
من المشكلات الشائعة إعداد وكيل فرعي لمراجعة الشيفرة، ثم ملاحظة أن Claude ينفذ كل شيء بنفسه دون استخدام الوكيل. والسبب غالبًا واحد: كُتب الوصف بصيغة «مساعد لمراجعة الشيفرة». لا يفهم Claude متى ينبغي تفعيله. ### صيغة الوصف الفعال (3 أجزاء) **الجزء 1 — ما الذي يفعله.** جملة واحدة عن النتيجة، لا عن العملية. لا تكتب «يحلل الشيفرة»، بل «يعثر على الثغرات في الشيفرة ويعيد قائمة بها، مع مستوى خطورتها وطريقة إصلاحها». **الجزء 2 — متى يُفعّل.** اكتب 3–5 عبارات بين علامتي اقتباس، على نحو يشبه طلبات المستخدمين الفعلية. لا تخمّن؛ راجع سجل محادثاتك والصياغات الحقيقية. **الجزء 3 — متى لا ينبغي تفعيله.** اكتب عبارة أو عبارتين عن مهام مشابهة لا ينبغي لهذا الوكيل الفرعي أن يستجيب لها. ومن دون هذا القسم، يتعارض وكيلان متشابهان باستمرار. ### العبارة السحرية “Use Proactively” تقدم الوثائق الرسمية لـ Anthropic توصية مباشرة:

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

— توثيق Claude Code، https://code.claude.com/docs/en/sub-agents
بعبارة أخرى، يميل Claude إلى **عدم** استدعاء وكيل فرعي افتراضيًا إذا لم يتضمن الوصف إشارات واضحة. أضف “use proactively” أو “use immediately after writing code”، وسيرتفع معدل التفعيل بشكل ملحوظ. ### هكذا يبدو الوصف القوي yaml ``` description: | متخصص خبير في مراجعة الشيفرة. يراجع الشيفرة استباقيًا من حيث الجودة، والأمان، وقابلية الصيانة. استخدمه فورًا بعد كتابة الشيفرة أو تعديلها. يعيد قائمة مرتبة بالأولويات تتضمن المشكلات ودرجات خطورتها وتوصيات الإصلاح. لا تستدعه عند إجراء تغييرات في الوثائق أو تعديلات README أو إعادة كتابة رسائل الإيداع؛ فهذه مهام يتولاها doc-maintainer. ``` ما الذي ينجح هنا: - تحدد أفعال «يراجع» و«يعيد» نتيجة ملموسة، لا عملية. - تمثل «استباقيًا» و«فورًا بعد» محفّزين واضحين. - تمنع عبارة «لا تستدعِ عند...» التعارض مع وكيل فرعي مشابه. - استخدام الإنجليزية في الوصف أمر معتاد. فمطابقة Claude تكون أفضل بالإنجليزية. ## 5 أدوار جاهزة للاستخدام لوكلاء فرعيين تعمل في 10 دقائق
الخلاصات الأساسية لتجنب كتابة أول وكيل فرعي من الصفر، استخدم أنماطًا مجرّبة وعدّلها. أعددت 5 أدوار تغطي المهام المعتادة: code-reviewer (مراجعة الشيفرة بعد التغييرات)، وsecurity-auditor (العثور على الثغرات والتسريبات)، وresearch-agent (بحث معمّق عبر 8+ مصادر)، وdoc-maintainer (مزامنة الوثائق مع الشيفرة)، وrefactor-agent (إعادة هيكلة آمنة عبر شجرة عمل git). ويأتي كل دور مع قالب جاهز للاستخدام يمكنك لصقه وتعديله.
كل دور أدناه عبارة عن ملف واحد: `.claude/agents/.md`. بعد إنشاء الملف، أعد تشغيل Claude Code، وافتح `/agents`، وتحقق من ظهور الوكيل الجديد في القائمة. بعد ذلك يمكنك استدعاؤه باستخدام `@agent-name`. ### 1. code-reviewer — مراجعة الشيفرة بعد كل تغيير هذا هو المثال الرسمي من وثائق Anthropic، وقد عُدّل ليناسب سير عمل: ```markdown --- name: code-reviewer description: | متخصص خبير في مراجعة الشيفرة. يراجع الشيفرة استباقيًا من حيث الجودة، والأمان، وقابلية الصيانة. استخدمه فورًا بعد كتابة الشيفرة أو تعديلها. tools: Read, Grep, Glob model: inherit color: blue --- أنت مراجع شيفرة خبير، وتضمن معايير عالية لجودة الشيفرة. عند استدعائك: 1. اقرأ الفروق وقائمة الملفات المعدلة المقدمتين من الجلسة الرئيسية. إذا غابتا، فاطلبهما منها. 2. استخدم Read وGrep وGlob لفحص الملفات المناسبة. 3. أعد النتائج دون تغيير ملفات أو تنفيذ أوامر صدفة. قائمة تحقق المراجعة: - الشيفرة واضحة وسهلة القراءة - أسماء الدوال والمتغيرات ملائمة - لا يوجد شيفرة مكررة - معالجة الأخطاء سليمة - لا توجد أسرار أو مفاتيح API مكشوفة - التحقق من صحة المدخلات مطبّق - تغطية الاختبارات كافية - أُخذ الأداء في الحسبان قدّم الملاحظات مرتبة حسب الأولوية: - مشكلات حرجة (يجب إصلاحها قبل الدمج) - تحذيرات (ينبغي إصلاحها) - اقتراحات (يمكن التفكير في تحسينها) التنسيق: لكل مشكلة، اذكر الملف:السطر + جملة واحدة توضّح المشكلة + إصلاحًا ملموسًا. ``` المفتاح `tools: Read, Grep, Glob`: للمراجع أدوات قراءة وبحث دون وصول Bash أو Write أو Edit. تعد الجلسة الرئيسية الفروق وتمررها إليه. تعليم الوكيل بأن ينفذ `git diff` فقط لا يقيّد أداة Bash ممنوحة بالكامل. ### 2. security-auditor — العثور على الثغرات والتسريبات يستخدم الدور `opus` لاستدلال أعمق وقيد أدوات Read وGrep وGlob نفسه. حُذفت الذاكرة الدائمة من قالب القراءة فقط، لأن تفعيل ذاكرة الوكيل يمنحه قدرة الكتابة إلى الذاكرة أيضًا: ```markdown --- name: security-auditor description: | متخصص في التدقيق الأمني. استخدمه استباقيًا للعثور على ثغرات OWASP Top 10، والأسرار المكشوفة، ومخاطر الحقن، ومشكلات المصادقة. شغّله قبل أي نشر أو دمج في main. tools: Read, Grep, Glob model: opus color: red --- أنت مدقق أمني. ابحث عن ثغرات قابلة للاستغلال، لا مشكلات أسلوبية. قائمة التدقيق: - حقن SQL / NoSQL - XSS (مخزن أو منعكس أو قائم على DOM) - مخاطر CSRF / SSRF - الأسرار المضمّنة في الشيفرة (مفاتيح API ورموز وكلمات مرور) - خلل المصادقة / إدارة الجلسات - إلغاء التسلسل غير الآمن - غياب التحقق من صحة المدخلات - اجتياز المسارات - عمليات إعادة التوجيه المفتوحة - مراجع الكائنات المباشرة غير الآمنة (IDOR) لكل نتيجة: - الخطورة: حرجة / عالية / متوسطة / منخفضة - الملف:السطر - سيناريو الهجوم في جملتين أو جملة واحدة - توصية إصلاح مع مثال شيفرة تجاهل ضجيج أدوات الفحص الأسلوبي أو مشكلات التنسيق. أبلغ فقط عن المشكلات القابلة للاستغلال. ``` هذا الدور يستخدم أدوات للقراءة فقط، مع `model: opus` للتحقق من مسائل معقدة مثل سلاسل الثغرات. ### 3. research-agent — بحث معمّق عبر 8+ مصادر ورد هذا النمط في مقالة Anthropic نفسها عن نظام البحث متعدد الوكلاء. والمفتاح هو تحديد تنسيق صريح للناتج ومنع تفريغ النتائج الخام: ```markdown --- name: research-agent description: | متخصص في البحث العميق على الويب. استخدمه استباقيًا للتحقق من الحقائق، والتحليل التنافسي، وجمع الوثائق الخارجية، ومقارنة الأساليب عبر مصادر متعددة. tools: WebFetch, WebSearch, Read, Write model: sonnet maxTurns: 30 color: purple --- أنت محلل أبحاث. الهدف: موجز مركّب، لا تفريغات بحث خام. العملية: 1. قسّم السؤال إلى 3–5 استعلامات فرعية 2. استخدم WebSearch لكل استعلام فرعي، واجلب أفضل 3–5 مصادر لكل استعلام 3. تحقّق من الادعاءات بمقارنتها عبر مصدرين مستقلين على الأقل 4. ارفض مواقع المحتوى المحشو لأغراض تحسين محركات البحث ومواقع التجميع؛ وفضّل المصادر الأولية 5. اقتبس النص حرفيًا مع ذكر رابط المصدر لأي ادعاء محدد 6. أعد: خلاصة في 3 نقاط + النتائج + المصادر (8 نطاقات على الأقل) أنماط ينبغي تجنبها: - لا تستشهد بحقيقة من مصدر واحد - لا تعِد صياغة الاقتباسات وكأنها حرفية - لا تُعد إلى الوكيل الأب تفريغات خام لنتائج البحث - لا تضف مقدمات أو خواتيم حشوًا («آمل أن يكون هذا مفيدًا») ``` يحمي `maxTurns: 30` من تحوّل البحث إلى تكرارات لا تنتهي. وتشير Anthropic إلى هذا الرقم في نظامها متعدد الوكلاء:

تفوق نظام متعدد الوكلاء، يتولى فيه Claude Opus 4 دور الوكيل القائد ويعمل Claude Sonnet 4 وكلاء فرعيين، على Claude Opus 4 المنفرد بنسبة 90.2%.

— هندسة Anthropic، https://www.anthropic.com/engineering/multi-agent-research-system
تشير نسبة التسعين بالمئة إلى مهام معيارية للبحث. ويكون المكسب في مهام الأعمال أصغر عمليًا، لكن حجمه العام مماثل. ### 4. doc-maintainer — إبقاء الوثائق متزامنة مع الشيفرة يستخدم هذا الدور `model: haiku`، وهو مثال نموذجي على «التحكم في التكلفة». لا تتطلب الوثائق Opus؛ إذ ينجز Haiku المهمة بثلث السعر: ```markdown --- name: doc-maintainer description: | متخصص في مزامنة الوثائق. استخدمه بعد دمج الميزات لتحديث README وAPI docs وCHANGELOG. يقرأ عمليات الإيداع الأخيرة، ويحدد التغييرات غير الموثقة، ويحدّث الوثائق استباقيًا. tools: Read, Write, Edit, Glob, Grep, Bash model: haiku memory: project color: green --- أنت تحافظ على تزامن الوثائق مع الشيفرة. عند استدعائك: 1. شغّل `git log --since="last release"` لمراجعة التغييرات الأخيرة 2. اقرأ README.md وdocs/ وCHANGELOG.md 3. حدّد الثغرات: ميزات جديدة بلا توثيق، وواجهات API محذوفة ما زالت موثقة، واختلافات الإصدارات الناتج: - الملفات المحدّثة (استخدم Edit، لا Write، حفاظًا على البنية الحالية) - إدخال في CHANGELOG.md بتنسيق Keep-A-Changelog - قائمة بالتغييرات التي أجريتها (ملخص للفروق الفعلية، لا إعادة صياغة) قواعد الأسلوب: - استخدم صيغة المبني للمعلوم وزمن المضارع - يجب أن تكون أمثلة الشيفرة قابلة للنسخ واللصق - لا تستخدم لغة تسويقية («قوي» أو «متين» أو «سلس») - تجنب الحشو («سيساعدك هذا الدليل على...») ``` ### 5. refactor-agent — إعادة هيكلة آمنة عبر شجرة عمل يستخدم هذا الدور `isolation: worktree`، أي يعمل الوكيل الفرعي في نسخة منفصلة من المستودع، ولا تدمج العمل إلا إذا كان مناسبًا: ```markdown --- name: refactor-agent description: | متخصص في إعادة الهيكلة الآمنة. استخدمه لإعادة التسمية والاستخراج والتضمين التي ينبغي ألا تمس نسخة العمل حتى تراجعها. يعمل في شجرة عمل git مؤقتة. tools: Read, Edit, Write, Bash, Grep, Glob model: sonnet isolation: worktree permissionMode: acceptEdits color: yellow --- أنت تعيد هيكلة الشيفرة من دون تغيير سلوكها. قواعد صارمة: 1. يجب أن تنجح الاختبارات قبل إعادة الهيكلة وبعدها. إذا فشلت الاختبارات قبل إعادة الهيكلة، فتوقف وأبلغ عن ذلك. 2. نفّذ إعادة هيكلة ذرية واحدة لكل إيداع (استخراج أو إعادة تسمية أو تضمين). 3. لا تغيّر الواجهات العامة دون تعليمات صريحة. 4. لا تعدّل الاختبارات إلا إذا كانت تختبر التنفيذ المُعاد هيكلته مباشرةً. العملية: - شغّل مجموعة الاختبارات ← خط الأساس - نفّذ إعادة هيكلة ذرية - شغّل مجموعة الاختبارات ← للتحقق - نفّذ الإيداع برسالة وفق النمط التقليدي: refactor(scope): ما الذي تغيّر أعد: ملخصًا بالتغييرات + مسار شجرة العمل كي يتمكن المستخدم من المقارنة والدمج. ``` بهذا الدور، تختفي أكثر مشكلات إعادة الهيكلة إيلامًا، وهي «كسرت شيئًا ولا أعرف كيف أتراجع عنه»: تبقى النسخة الأصلية كما هي، ويعمل الوكيل الفرعي في شجرة عمل معزولة. هل تريد ألا تكتفي بنسخ وكلاء فرعيين جاهزين، بل تكوّن **مجموعة تجعل Claude أداة مستقرة**؟ الوكلاء الفرعيون جزء من **نسختك الذكية بالذكاء الاصطناعي**: طريقة لمنح Claude فريقًا متخصصًا يعمل وفق منطقك. وترتكز المنهجية على ثلاثة أعمدة: **نسختك الذكية بالذكاء الاصطناعي** (Skills + Subagents) + **[الدماغ الثاني](https://ailoot.ai/blog/ar/claude-code-second-brain/)** + **هندسة السياق**. يحوّل هذا المزيج Claude من مساعد يخمّن إلى أداة تفكر وفق منطقك. ## تشغيل 5 وكلاء فرعيين بالتوازي: المنسّق والعاملون
الخلاصات الأساسية القوة الأساسية للوكلاء الفرعيين هي التنفيذ المتوازي. تحتفظ المحادثة الرئيسية بالخطة، بينما يعمل خمسة (أو عشرة) وكلاء فرعيين متخصصين في الوقت نفسه على مراحل مختلفة، ولكل منهم سياقه الخاص. تجمع المحادثة الرئيسية النتائج وتتحقق منها. يسرّع هذا العمل 3–5 مرات مقارنةً بالعمل المتسلسل، ويقضي أيضًا على «تلوث السياق» الذي يحدث عندما تمتلئ المحادثة الرئيسية بالسجلات والتحليلات الوسيطة.
يقوم التنسيق المتوازي على مبدأ «قائد أوركسترا + عازفون». يحتفظ القائد بالخطة، ولا يعزف النغمات، ويتحقق مما يعزفه الموسيقيون. وإذا عزف أحدهم نغمة خاطئة، يطلب منه القائد إعادة عزفها بدلًا من محاولة إكمال العزف مكانه. أما بالنسبة إلى رائد الأعمال، فالتشبيه الأقرب هو وكالة تسويق تُعدّ استراتيجية لعميل جديد. يجري أحد المحللين تحليل SWOT، ويحلل آخر المنافسين، ويعدّ ثالث ملفًا للجمهور، وينقّح محلل أقدم الفرضيات التي لا تناسب الميزانية، ثم يجمع مدير المشروع العرض النهائي. في Claude Code، يبدأ هذا المسار بجملة واحدة، ويكون الناقد جزءًا من العملية بدلًا من أن يصل بعد انتهائها. ### موجّه تنسيق بسيط تكفي جملة واحدة في المحادثة الرئيسية: ``` شغّل خمسة وكلاء فرعيين بالتوازي: ثلاثة من نوع research-agent يبحث كل منهم في مصادر مختلفة (وثائق Anthropic ومستودعات GitHub ومدونات الذكاء الاصطناعي)، وواحد من نوع critic-agent لاستبعاد الاستنتاجات الضعيفة، وواحد من نوع summary-agent لإعداد الوثيقة النهائية. السياق: أكتب دليلًا عن X. الطول المستهدف: 2,000 كلمة مع مصادر. قبل البدء، يقرأ كل واحد منهم CLAUDE.md. ``` بعد ذلك يفوّض Claude المهام إلى الوكلاء الخمسة. يعمل كل واحد في سياقه الخاص: تستخدم وكلاء البحث مصادرها المحددة، وينقّح الناقد النتائج، ويعدّ وكيل الملخص الوثيقة. ولا يعود إلى المحادثة الرئيسية سوى الملخصات النهائية. ### متى يكون التوازي مفيدًا ليس في كل الحالات. لا يكون التنفيذ المتوازي منطقيًا إلا عندما: 1. تكون المهام **مستقلة**. إذا كان research-agent رقم 2 ينتظر نتيجة research-agent رقم 1، فلن يكون هناك توازٍ، وسيعملان فعليًا بالتتابع. 2. تستغرق المهام **وقتًا طويلًا**. لا فائدة من تنفيذ «إزالة المسافات البيضاء في نهاية السطر» بالتوازي؛ فتكلفة تشغيل الوكلاء الفرعيين ستلتهم المكسب. 3. تتوفر لديك **حدود كافية**. سنتناول ذلك في قسم منفصل أدناه: الوكلاء الفرعيون المتوازيون يستهلكون الرموز بسرعة. ### نظام Anthropic متعدد الوكلاء v2: خطوة أبعد في مايو 2026، أصدرت Anthropic الإصدار v2 من تنسيق الوكلاء المتعددين، مع ثلاثة اختلافات مهمة عن النهج التقليدي لإطلاق وكلاء فرعيين بالتوازي. المزيد في القسم التالي. ## ما الجديد في الإصدار v2 من التنسيق متعدد الوكلاء: التنسيق والنتائج والحلم
الخلاصات الأساسية في 6 مايو 2026، خلال مؤتمر Code with Claude في سان فرانسيسكو، أعلنت Anthropic عن ثلاث ميزات لـ Managed Agents v2، وجميعها في مرحلة تجريبية عامة. تتيح ميزة Multi-Agent Orchestration للوكيل القائد تقسيم العمل والتفويض إلى متخصصين بالتوازي مع نظام ملفات مشترك. وتتيح ميزة Outcomes كتابة معايير نجاح، ثم يتحقق من النتيجة وكيل تقييم منفصل. أما Dreaming فتشبه نوم حركة العين السريعة: إذ تقرأ عملية مجدولة الجلسات السابقة، وتبحث عن الأنماط، ثم تحدّث ذاكرة الوكيل.
### Multi-Agent Orchestration: نظام ملفات مشترك + مراجعات أثناء سير العمل تصف Anthropic الميزة هكذا:

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

— Anthropic - جديد في Claude Managed Agents، https://claude.com/blog/new-in-claude-managed-agents
الاختلاف الأساسي عن الوكلاء الفرعيين التقليديين هو **نظام الملفات المشترك**. سابقًا، كان كل وكيل فرعي يعمل في عزلة تامة، ولا يحدث التبادل إلا عبر الملخص الذي يعيده. أما الآن، فيمكن للمتخصصين الكتابة في مجلد مشترك، ويقرأ الوكيل القائد النتائج أثناء تقدم العمل، لا في نهايته فحسب. يحل هذا مشكلة «عمل الجميع طوال اليوم، ثم اتضح في النهاية أن شخصين اتبعا نهجين متعارضين». والاختلاف الثاني هو **المراجعات أثناء سير العمل**. يمكن للوكيل القائد التوقف وسؤال أي متخصص: «كيف يسير العمل؟»، ثم تعديل الخطة العامة. وهذا قريب من طريقة عمل مدير فريق حقيقي. ### Outcomes: معايير بدلًا من تعليمات خطوة بخطوة مع Outcomes، تكتب معايير النجاح، ويجد الوكيل طريقة لتحقيقها. ويتحقق وكيل تقييم منفصل من النتيجة في سياقه الخاص، كي لا «يتلوث» باستدلال الوكيل الرئيسي.

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

— Anthropic - جديد في Claude Managed Agents، https://claude.com/blog/new-in-claude-managed-agents
زيادة عشرة بالمئة في المهام الصعبة مكسب كبير. ويبرز ذلك خصوصًا عند صياغة المهمة على النحو الآتي: «أعدّ مقالة مطوّلة تستوفي معايير الجودة هذه»، بدلًا من «اتبع الخطوات من 1 إلى 7». ### Dreaming: الوكلاء يراكمون الخبرة بين الجلسات هذه أكثر الميزات جدة من الناحية المفاهيمية. يراجع الوكيل الجلسات السابقة، ويبحث عن أنماط النجاح والأخطاء، ثم يحدّث مخزن الذاكرة. يمكنك إعداد مراجعة يدوية قبل تطبيق التغييرات، أو تركه يعدّل الذاكرة بنفسه. تشير Anthropic إلى أن Harvey (شركة تكنولوجيا قانونية) شهدت زيادة تقارب ستة أضعاف في نجاح مهام صياغة المستندات القانونية بعد تطبيق Dreaming. وهذه الميزة تعمل بالفعل في الإنتاج، وليست مجرد عرض تجريبي. ### ما الذي يعنيه هذا لرواد الأعمال غير المبرمجين تتوفر Multi-Agent Orchestration حاليًا عبر Claude Agent SDK، وليس مباشرةً في CLI الخاص بـ Claude Code. لكن الاتجاه واضح: ينتقل التنسيق من «تشغّل يدويًا N من الوكلاء الفرعيين» إلى «تصف المهمة، ويقرر الوكيل القائد من يفوّض إليه وكيف». إذا كنت تبدأ للتو باستخدام الوكلاء الفرعيين، فلا تقلق بشأن v2 بعد. تعلّم النمط التقليدي «محادثة رئيسية واحدة + 3–5 وكلاء فرعيين بأدوار مختلفة»، وبعد 3–6 أشهر يمكنك الانتقال بسلاسة إلى Managed Agents. ## 7 أخطاء تعطل الوكلاء الفرعيين تمامًا
الخلاصات الأساسية أكثر مشكلات الوكلاء الفرعيين شيوعًا ليست أخطاء في Claude، بل أخطاء في إعداد الوكلاء أنفسهم. من بينها: أوصاف تفتقر إلى العبارات المحفّزة، ومحاولة استخدام وكيل فرعي لمهمة تناسب Skill، وتشغيل 60 وكيلًا بالتوازي «لأن ذلك رائع»، ومنح كل وكيل جميع الأدوات، وعدم تحديد تنسيق صريح للناتج، وطلبات تفويض مبهمة، وبنية قائمة على الأدوار بدلًا من المهام. يُفسد كل خطأ منها إما التفعيل أو نتائج الوكيل الفرعي.
### الخطأ 1. أوصاف «مساعد لـ X» لا تؤدي إلى التفعيل العَرَض: كتبت وكيلًا فرعيًا، وتحققت من بنيته، وكل شيء صحيح، لكن Claude لا يستدعيه عند تلقي طلبات المستخدم. والسبب دائمًا تقريبًا واحد: الوصف مجرد، مثل «مساعد لمراجعة الشيفرة». الحل: اكتب 3–5 عبارات حقيقية للمستخدمين بين علامتي اقتباس داخل الوصف، وأضف “use proactively” / “use immediately after”. ### الخطأ 2. إنشاء وكيل فرعي عندما تكون الحاجة إلى Skill يكلف الوكيل الفرعي أكثر من Skill؛ إذ ينشئ سياقه الخاص، ويحمل موجّه النظام الخاص به، ويستخدم رموزًا أكثر. إذا كانت المهمة قصيرة ولن تستهلك السياق الرئيسي ويمكن إنجازها في تمريرة واحدة، فينبغي استخدام Skill بدلًا من وكيل فرعي. مثال على نمط سيئ: وكيل فرعي باسم `format-validator` يتحقق من مخطط JSON وفق 20 قاعدة. الأنسب هو Skill: نموذج واحد، ولا حاجة إلى العزل أو تحميل سياق إضافي. ### الخطأ 3. تشغيل «60 وكيلًا بالتوازي» من البداية هذا هو الوهم الأكثر انتشارًا. ترى منشورًا يقول: «لدي 1,500 وكيل يعملون»، فتفكر: «ينبغي أن أفعل ذلك أيضًا». عمليًا، يستهلك 60 وكيلًا حدود خطة Pro خلال ساعة، ويولّدون كومة من النتائج المتعارضة، ثم تنتهي اليوم من دون إنجاز أي شيء. ويصف أحد الممارسين على Medium الأمر هكذا: الحل: ابدأ بوكيل فرعي واحد لمهمة واحدة. وبعد أن تتقن ذلك، أضف وكيلًا ثانيًا بدور مختلف. وبعد أن تتقن تنسيق وكيلين، انتقل إلى فريق من 3–5. والانتقال من «ثبّت Claude Code أمس» إلى «20 وكيلًا بالتوازي اليوم» سيؤدي حتمًا إلى إفساد الشيفرة واستنزاف الحدود. ### الخطأ 4. منح كل وكيل جميع الأدوات إذا كان مراجع الشيفرة لديك قادرًا على استخدام Bash وWrite وWebFetch، فهذه ثغرة كبيرة في الأمن والتكلفة. لا ينبغي أن يُسمح للمراجع بكتابة الملفات، فضلًا عن الوصول إلى الإنترنت. الحل: حصر `tools` بدقة. لا يحصل مراجع الشيفرة إلا على `Read, Grep, Glob`. ويحصل المدقق الأمني على أدوات القراءة والبحث نفسها وفروق توفرها الجلسة الرئيسية. منح Bash يتيح الصدفة؛ ولا يحصر الوكيل تلقائيًا في `git diff`. ويحصل وكيل البحث على `WebFetch, WebSearch, Read, Write`. لا تمنح الوكيل الفرعي صلاحيات أكثر مما يحتاج إليه لمهمة محددة واحدة. ### الخطأ 5. يعيد الوكيل الفرعي النتائج الخام إلى السياق الرئيسي إذا أعاد وكيل البحث إلى المحادثة الرئيسية عبارة «إليك كل الصفحات الثلاثين التي عثرت عليها؛ دبّر الأمر بنفسك»، فقد فقدت أكبر ميزة للوكلاء الفرعيين: عزل الضجيج. الحل: اطلب صراحةً تنسيقًا محددًا للناتج في موجّه نظام الوكيل الفرعي. «أعد فقط: خلاصة من 3 نقاط + قائمة من 5 مصادر. لا تعرض تفريغات الشيفرة ولا نتائج البحث الخام». وينبغي أن يكون التنسيق **صارمًا**، وألا يُترك للوكيل الفرعي مجال «لتحويله إلى مقالة». ### الخطأ 6. طلبات تفويض مبهمة: تعليمات غير واضحة لا يستطيع الوكيل الفرعي **رؤية** سجل الحوار الرئيسي. يبدأ بسياق نظيف + CLAUDE.md + ما كتبته إليه صراحةً. إذا كتبت «أصلح المصادقة»، فسيختلق الوكيل الفرعي التفاصيل. اكتب بدلًا من ذلك: «أصلح حلقة إعادة التوجيه في OAuth؛ فبعد تسجيل الدخول بنجاح، يُعاد توجيه المستخدم إلى /login بدلًا من /dashboard. الملف: src/lib/auth.ts.» قاعدة واضحة: عند التفويض، قدّم إلى الوكيل الفرعي قدر السياق نفسه الذي ستعطيه لمتعاقد جديد انضم إلى المشروع للتو. ### الخطأ 7. وكلاء مبنيون على الأدوار بدلًا من المهام من الأنماط المغرية: «لننشئ مطور واجهة أمامية ومطور خلفية ومهندس ضمان جودة، وليعملوا معًا كفريق». لكنه لا ينجح. يفقد كل «دور» سياق المشروع بأكمله، ولا يستطيعون الاتفاق على التفاصيل لأنهم لا يرون عمل بعضهم. الحل: ينبغي للوكيل الفرعي أن يتولى **مهمة** متكررة ذات ناتج واضح، لا **دورًا**. لا تنشئ وكيلًا باسم «مطور واجهة أمامية»، بل «استكشف شجرة واجهة المستخدم» أو «أعد هيكلة المكوّن» أو «دقّق إمكانية الوصول». ينفذ كل وكيل قائم على مهمة عملًا محددًا، ويعيد نتيجة محددة. ## ما تكلفة الوكلاء الفرعيين المتوازيين، ومتى يكونون مجديين؟
الخلاصات الأساسية يستهلك الوكلاء الفرعيون المتوازيون الرموز بسرعة تفوق العمل المتسلسل 3–5 مرات. في خطة Pro (\$20 شهريًا)، يؤدي تشغيل 5 وكلاء فرعيين متوازيين إلى استهلاك المخصص في غضون ساعة. وتُعد Max 5x (\$100 شهريًا) الحد الأدنى الواقعي للعمل المتوازي المنتظم. يكون الوكيل الفرعي مجديًا في المهام التي تتطلب 10 دقائق على الأقل من العمل المركّز؛ أما تشغيل واحد لمجرد تصحيح خطأ مطبعي في README فسيستهلك رموزًا أكثر من الوقت الذي يوفره.
| الإعداد | الاستخدام اليومي مع العمل النشط | |----|----| | جلسة واحدة في Claude Code | ~\$13 | | 3 وكلاء فرعيون متوازون | ~\$30-40 | | 5–10 بالتوازي | \$50-130 | | 30 وكيلًا (10 مطورين × 3 وكلاء فرعيين) | \$300-400 | ستنتهي حصة Pro في غضون ساعة إذا شغّلت 5 وكلاء فرعيين متوازيين لمهام معقدة. وتُعد Max 5x (\$100) الحد الأدنى الواقعي للعمل المتوازي المنتظم. وبالنسبة إلى الفرق والمؤسسات، تُعالج مسألة التكلفة أصلًا على مستوى ميزانية الأدوات. للمزيد حول توفير الرموز في Claude Code، راجع [الدليل المنفصل حول الحدود](https://ailoot.ai/blog/ar/claude-code-token-limits-saving/). والقاعدة الأساسية للوكلاء الفرعيين هي أن يكون العمل الذي يتولونه بحاجة إلى **10 دقائق على الأقل** من التركيز. إذا كانت المهمة أقصر، فلا تنشئ وكيلًا فرعيًا؛ بل نفذها في المحادثة الرئيسية أو باستخدام Skill. ## كيف تدمج الوكلاء الفرعيين في نسختك الذكية بالذكاء الاصطناعي والدماغ الثاني؟
الخلاصات الأساسية الوكلاء الفرعيون هم الخطوة الرابعة في منهجية Claude Code. والتسلسل المنطقي هو: أولًا [CLAUDE.md](https://ailoot.ai/blog/ar/claude-md-template/) (السياق الدائم)، ثم [Skills](https://ailoot.ai/blog/ar/claude-code-skills-library/) (منهجيات جاهزة)، ثم [الدماغ الثاني](https://ailoot.ai/blog/ar/claude-code-second-brain/) (بنية المعرفة للمشروع)، وأخيرًا الوكلاء الفرعيون (عاملون متخصصون). عكس هذا الترتيب يمنحك ضجة بلا نتائج. فالوكيل الفرعي من دون CLAUDE.md يختلق المعلومات؛ ومن دون Skills يكرر العمل نفسه من الصفر في كل مرة؛ ومن دون بنية معرفية يقدم إجابة عادية.
يعتمد الوكيل الفرعي على ثلاثة أمور ينبغي أن تتوفر في مشروعك قبل إنشاء أول متخصص: 1. **ملف [CLAUDE.md](https://ailoot.ai/blog/ar/claude-md-template/) مناسب.** يقرأ الوكيل الفرعي CLAUDE.md قبل البدء؛ فهو بمثابة «عقد عمله». ومن دونه، لا يعرف الوكيل الفرعي سياق المشروع أو قيوده أو نبرته، وسيختلق المعلومات. 2. **[Skills](https://ailoot.ai/blog/ar/claude-code-skills-library/) أساسية.** الـ Skill منهجية معبأة. لا يحمّل الوكيل الفرعي إلا ما يحتاج إليه من Skills، لا كل شيء دفعة واحدة. ومن دون Skills، يكرر الوكيل الفرعي العمل نفسه من الصفر في كل مرة. 3. **[الدماغ الثاني](https://ailoot.ai/blog/ar/claude-code-second-brain/): بنية معرفية.** مجلد `business/`، أو ما يعادله في مجالك، مكتبة يرجع إليها جميع الوكلاء الفرعيين. ومن دونها، يقدم الوكيل الفرعي إجابة عادية من ChatGPT لا تميّزه عن إجابات الآخرين. عكس هذا الترتيب يعني ضجة بلا نتائج. فقولك «لدي 60 وكيلًا فرعيًا متوازيًا» مع مجلد `business/` فارغ يعني 60 جلسة ChatGPT عادية تتبع النهج نفسه. يمثل المزيج الكامل، **النسخة الذكية بالذكاء الاصطناعي + الدماغ الثاني + هندسة السياق**، **الأعمدة الثلاثة** التي تجعل Claude متسقًا. والوكلاء الفرعيون جزء من النسخة الذكية بالذكاء الاصطناعي: طريقة لمنح Claude فريقًا متخصصًا يعمل وفق منطقك.
### المصادر - [إنشاء وكلاء فرعيين مخصصين - توثيق Claude Code](https://code.claude.com/docs/en/sub-agents) - [تمكين Claude Code من العمل باستقلالية أكبر - أخبار Anthropic](https://www.anthropic.com/news/enabling-claude-code-to-work-more-autonomously) - [كيف أنشأنا نظام البحث متعدد الوكلاء - هندسة Anthropic](https://www.anthropic.com/engineering/multi-agent-research-system) - [تجهيز الوكلاء للعالم الحقيقي باستخدام Agent Skills - هندسة Anthropic](https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills) - [الجديد في Claude Managed Agents (Multi-Agent v2 وOutcomes وDreaming) - مدونة Anthropic](https://claude.com/blog/new-in-claude-managed-agents)
أسرع طريقة للبدء هي نسخ `code-reviewer` من المثال الأول أعلاه إلى `.claude/agents/code-reviewer.md`، ثم إعادة تشغيل Claude Code واستدعاؤه باستخدام `@agent-code-reviewer` عند الإيداع التالي. خلال 5 دقائق، ستعرف ما إذا كنت بحاجة إلى وكلاء فرعيين أو ما إذا كانت المحادثة الرئيسية كافية.
يمكنك مواصلة استكشاف Ailoot عبر [ailoot.ai](https://ailoot.ai/).
## أسئلة شائعة ### هل ينفذ المراجع git diff فقط لأن طلبه يقول ذلك؟ لا. منح أداة Bash يمنح قدرة الصدفة؛ والطلب ليس قائمة أوامر مسموحة. يحذف قالب المراجع للقراءة فقط Bash وWrite وEdit ويتلقى الفروق من الجلسة الرئيسية. ### كيف يفحص مراجع بلا Bash التغييرات الحديثة؟ توفر الجلسة الرئيسية الفروق وقائمة الملفات المعدلة عند التفويض. يقرأ المراجع تلك الملفات ويبحث فيها باستخدام Read وGrep وGlob، ويعيد النتائج دون تعديلها. ## Ailoot · الشركة ومحفظة مشاريعها تستند Ailoot إلى خبرة تشغيلية متراكمة وقاعدة عملاء واسعة وخدمة مستقرة ومراقبة مستمرة لمؤشرات الأداء KPI. الشركة ومحفظة مشاريعها: ملايين العملاء؛ مبيعات بالمليارات شهريًا. توظف Ailoot هذه الخبرة التشغيلية لإتاحة الوصول عبر API إلى قدرات الذكاء الاصطناعي في منتجات العملاء ووكلائهم وتطبيقاتهم وعمليات الأتمتة.