تتيح الوكلاء الفرعيون (subagents) في Claude Code تفويض المهام بالتوازي عبر مساعدين ذكاء اصطناعي متخصّصين، يمتلك كلٌّ منهم نافذة سياق معزولة، ومجموعة أدوات، وموجّه نظام خاصّ به. يغطّي هذا الدليل إنشاء الوكلاء الفرعيين وضبطهم والعمل معهم بوصفهم ملفات markdown تحتوي على رأسيّة YAML، ويمكن إدارتها عبر رايات سطر الأوامر، أو أدلّة المشروع، أو أدلّة المستخدم عبر مشاريع مختلفة.
يحافظ الوكلاء الفرعيون على نظافة السياق خلال المهام الطويلة، ويتيحون العمل بالتوازي، ويسمحون بتغليف الخبرة المتخصّصة في وكلاء قابلين لإعادة الاستخدام. تشمل خيارات الضبط تقييد الأدوات، واختيار النموذج، والتحكّم في عمق الاستدلال، وإعدادات العزل مثل فصل شجرة العمل (worktree) لتعديل الشيفرة بأمان دون التأثير في شجرة العمل الرئيسية.
الوكلاء الفرعيون في Claude Code يتيحون تفويض المهام بالتوازي. يغطّي هذا الدليل عزل الوكلاء، وسير العمل متعدّد الوكلاء، ومتى ينبغي تفويض العمل إلى الوكلاء الفرعيين.

- الوكلاء الفرعيون في Claude Code: ما الذي ستتعلّمه
- مثال تطبيقي: بناء أول وكيل فرعي
- إنشاء الوكلاء الفرعيين
- خيارات الضبط
- استخدام الوكلاء الفرعيين وربطهم تسلسليًّا
- أمثلة واقعيّة على الوكلاء الفرعيين
- نصائح احترافيّة
- تحدٍّ تطبيقي
- اختبار المعرفة
- س1: ما الميزة الرئيسية للوكلاء الفرعيين مقارنةً بالمحادثة المضمّنة؟
- س2: ما ترتيب الأولويّة لتعريفات الوكلاء؟
- س3: أيّ وكيل فرعي مدمج يستخدم نموذج Haiku ومُحسَّن لاستكشاف الشيفرة بقراءة فقط؟
- س4: كيف تُقيّد الوكلاء الفرعيين الذين يستطيع وكيل منسّق إطلاقهم؟
- س5: ماذا يفعل isolation: worktree لوكيل فرعي؟
- اختبر معرفتك
- مصادر إضافيّة
- الوكلاء الفرعيون في Claude Code: أخطاء شائعة يجب تجنّبها
- الوكلاء الفرعيون في Claude Code: أفضل الممارسات
- الوكلاء الفرعيون في Claude Code: أسئلة شائعة
- واصِل التعلّم
الوكلاء الفرعيون في Claude Code: ما الذي ستتعلّمه
في هذا الدليل إلى الوكلاء الفرعيين في Claude Code، ستمرّ بخطوات عمليّة تطبيقيّة مع أمثلة واقعيّة. يُشرح هذا الموضوع من الأساس حتى تتمكّن من تطبيقه فورًا في مشاريعك الخاصّة.
يتيح الوكلاء الفرعيون لـ Claude تسليم العمل إلى مساعدي ذكاء اصطناعي متخصّصين، يعمل كلٌّ منهم بنافذة سياق معزولة، ومجموعة أدوات، وموجّه نظام خاصّ به. يحافظ هذا الأسلوب على نظافة السياق خلال المهام الطويلة، ويتيح العمل بالتوازي، ويسمح لك بتغليف الخبرة المتخصّصة في وكلاء قابلين لإعادة الاستخدام. يستعرض هذا الدرس إنشاء الوكلاء الفرعيين وضبطهم والعمل معهم.
مثال تطبيقي: بناء أول وكيل فرعي
لتجربة الوكلاء الفرعيين عمليًّا، ابنِ وكيلًا واحدًا محدود الصلاحيات بدل تفويض كل شيء للوكيل الرئيسي.
أنشئ ملف .claude/agents/code-reviewer.md في مشروعك. يبدأ الملف ببيانات أمامية (frontmatter) بصيغة YAML تحدد name وdescription وtools — اجعل tools تقتصر على Read وGrep وGlob فقط، لأن مهمة هذا الوكيل مراجعة الشيفرة قراءةً لا كتابةً. اكتب description دقيقًا وقابلًا للتفعيل التلقائي، مثل Use this agent to review recently changed code for bugs and style issues before committing — فالمنسّق يعتمد على هذا الوصف وحده لتقرير متى يستدعي الوكيل تلقائيًا.
تحت البيانات الأمامية، اكتب موجّه النظام (system prompt) الخاص بالوكيل: ما الذي يبحث عنه بالتحديد، وبأي صيغة يُرجع ملاحظاته. كن محددًا — وكيل بموجّه غامض ينتج مراجعات سطحية.
اختبر الوكيل بطلب صريح أولًا: “استخدم وكيل code-reviewer لمراجعة التغييرات الأخيرة.” راقب كيف يعمل بنافذة سياق معزولة عن محادثتك الرئيسية، ولا يرى من سجلّ الجلسة إلا ما تمرره إليه صراحة.
بعد التأكد من عمله يدويًا، اختبر الاستدعاء التلقائي: نفّذ تعديلًا على ملف ثم اطلب من Claude “راجع ما غيّرته للتو” دون ذكر اسم الوكيل. إن كان الوصف جيدًا، يستدعي المنسّق الوكيل تلقائيًا بالنيابة عنك.
وسّع التجربة بإنشاء وكيل ثانٍ — مثل test-writer بصلاحية الكتابة على ملفات الاختبار فقط — وجرّب ربط الوكيلين تسلسليًّا: راجع الشيفرة أولًا، ثم اكتب اختبارات للمشكلات التي وجدها المراجع. هذا هو نمط سير العمل متعدد الوكلاء الذي يستحق البناء عليه في مشاريع حقيقية.
إنشاء الوكلاء الفرعيين
يُعرَّف الوكلاء الفرعيون بوصفهم ملفات markdown تحتوي على رأسيّة YAML. يمكنك إتاحتهم بعدّة طرق: استخدم راية سطر الأوامر --agents لجلسة واحدة، أو ضعهم في .claude/agents/ لإتاحتهم على مستوى المشروع كلّه (واحفظهم في git)، أو ضعهم في ~/.claude/agents/ للاستخدام الشخصي عبر جميع المشاريع. كما يمكن للإضافات (plugins) أن تحزم وكلاء. ترتيب الأولويّة هو: المُدار (managed) أوّلًا، ثم راية سطر الأوامر، ثم المشروع، ثم المستخدم، وأخيرًا الإضافة. الوكلاء الفرعيون المدمجون موجودون دائمًا ولا يشاركون في نظام تجاوز الأسماء. يفتح الأمر /agents قائمة تفاعليّة لإنشاء وكلائك وتحريرهم وإدارتهم.
تُحدِّد الرأسيّة هويّة الوكيل، بينما يعمل متن markdown موجّهَ النظام الخاصّ به — تخيّله كأنّك تُحاضِر متخصّصًا:
---
name: security-reviewer
description: Security-focused code reviewer. Use proactively after writing authentication, authorization, or data handling code.
tools: Read, Grep, Glob
---
You are a senior security engineer specializing in application security.
Review priorities:
1. Authentication and authorization flaws
2. Injection vulnerabilities (SQL, XSS, command)
3. Data exposure and sensitive information handling
4. Cryptographic weaknesses
5. Insecure direct object references
For each finding, provide: severity (Critical/High/Medium/Low), location (file:line), description, and a concrete fix with code example.
When invoked: run `git diff HEAD` first to focus on changed code.
يُقيّد حقل tools الأدوات التي يمكن للوكيل الوصول إليها. مُراجِع الأمان لا يحتاج إلّا إلى Read وGrep وGlob — دون أيّ صلاحيات كتابة. أمّا وكيل التنفيذ، فيحتاج إلى مجموعة الأدوات الكاملة. يجعل تقييد الأدوات الوكلاء أكثر أمانًا وأكثر قابليّة للتنبّؤ في آنٍ معًا. وإن أغفلت حقل tools، يرث الوكيل كلّ أداة متاحة.
خيارات الضبط
إلى جانب الوصول الأساسي للأدوات، تدعم الرأسيّة مجموعة من خيارات الضبط القويّة. يختار حقل model النموذج الذي يعمل عليه الوكيل — haiku للمهام السريعة الخفيفة، أو sonnet للأعباء المتوازنة، أو opus للاستدلال المعقّد. استخدم inherit لاعتماد نموذج الوكيل الأب. يتحكّم حقل effort في عمق الاستدلال على النماذج المدعومة، ويقبل القيم low وmedium وhigh وxhigh وmax وauto. يُقيّد maxTurns مدّة تشغيل الوكيل، ويضبط permissionMode مستوى الصلاحيات. وتشمل الحقول الإضافيّة disallowedTools، وskills لتحميل مهارات محدّدة مسبقًا، وmcpServers لوصول MCP المحصور بالوكيل، وinitialPrompt لتقديم الدور الأوّل تلقائيًّا.
يمنح حقل memory الوكلاء تخزينًا دائمًا يبقى عبر الجلسات. تُحمَّل أوّل 200 سطر من ملف MEMORY.md الموجود في دليل ذاكرة الوكيل تلقائيًّا إلى موجّه نظامه — ويكتب Claude إلى هذا الملف وهو يتعلّم:
---
name: researcher
memory: user
description: Long-running research assistant with persistent notes
---
You are a research assistant. Check your MEMORY.md at session start to recall previous findings. Update it with new discoveries.
يمنح ضبط isolation: worktree الوكيلَ شجرة عمل (worktree) وفرعًا خاصّين به في git، فيتمكّن من إجراء التغييرات دون المساس بشجرة عملك الرئيسية. وعند انتهاء الوكيل، يُعيد مسار شجرة العمل واسم الفرع لتراجعهما وتدمجهما. وإن لم تُجرَ أيّ تغييرات، تُنظَّف شجرة العمل تلقائيًّا. وبينما يعمل الوكيل، يقفل Claude شجرة العمل لمنع التنظيف المتزامن، ويُحرّر القفل بمجرّد انتهائه. يتفرّع worktree من الفرع الافتراضي لمستودعك (origin/HEAD) ما لم تضبط worktree.baseRef على head في الإعدادات، ممّا يجعل الوكلاء المعزولين يبدؤون من HEAD المحلّي لديك ويحملون معهم العمل غير المدفوع.
يُجبر ضبط background: true الوكيلَ على العمل دائمًا كمهمّة خلفيّة، ممّا يُحرّر المحادثة الرئيسية. كما يمكنك الضغط على Ctrl+B لإرسال وكيل يعمل حاليًّا في المقدّمة إلى الخلفية.
تُوسِّع رايتان لسطر الأوامر نطاق ما يمكن للجلسة الوصول إليه. تمنح --add-dir <path> صلاحية Read/Edit لأدلّة إضافيّة خارج دليل العمل الأساسي — مفيدة حين تشير شيفرتك إلى مكتبات مشتركة أو حزم monorepo في مجلّدات شقيقة. تُحمَّل المهارات الموجودة في .claude/skills/ داخل الأدلّة المضافة تلقائيًّا. ثبّت هذه الإعدادات عبر permissions.additionalDirectories في الإعدادات. وتُحمِّل --mcp-config <path> تعريفات خوادم MCP من ملفات JSON للجلسة الحاليّة فقط، مدموجةً مع مصادر المستخدم/المشروع لديك. أضف --strict-mcp-config لتجاهل مصادر المستخدم/المشروع واستخدام الملفات المُقدَّمة فحسب:
claude --add-dir ~/projects/shared-types --add-dir ~/projects/design-tokens
claude --mcp-config ./ci-servers.json
استخدام الوكلاء الفرعيين وربطهم تسلسليًّا
يستدعي Claude الوكلاء تلقائيًّا حين تتطابق مهمّة ما مع حقل description الخاصّ بالوكيل. يمكن لعبارات مثل «use proactively» أن تشجّع على التفويض، لكن للحصول على نتائج موثوقة حين تحتاج إلى وكيل بعينه، فإنّ الاستدعاء الصريح هو الطريق الأمثل. استخدم صيغة @"agent-name (agent)" لضمان استخدام وكيل محدّد، متجاوزًا المطابقة التلقائيّة.
يعمل الاستدعاء الصريح باللغة الطبيعيّة أيضًا:
استخدم وكيل security-reviewer لتدقيق وحدة المصادقة الجديدة.
اجعل وكيل test-engineer يكتب اختبارات تكامل لخدمة الدفع.
اطلب من وكيل debugger التحقّق في تسرّب الذاكرة في src/workers/queue.ts.
يمكن ربط الوكلاء تسلسليًّا، بحيث يُغذّي خرج وكيلٍ ما الوكيلَ التالي. يفتح تشغيل claude agents من الطرفيّة عرض الوكلاء (Agent view) — قائمة بجميع جلسات Claude Code تُظهر حالتها (تعمل، تنتظر، اكتملت، فشلت، خاملة، متوقّفة) وآخر نشاط لها. وهذا رائع لمراقبة عدّة وكلاء يعملون بالتوازي. مرّر --cwd <path> لتصفية القائمة بالجلسات التي بدأت ضمن ذلك الدليل — مفيد حين تتعامل مع عدّة مستودعات وتريد عرضًا محصورًا. اضبط CLAUDE_CODE_DISABLE_AGENT_VIEW=1 لتعطيله. كما يمكنك تشغيل جلسة كاملة بوكيل محدّد عبر claude --agent <name>، وتقييد الوكلاء الذين يستطيع المنسّق إطلاقهم باستخدام قوائم السماح لأداة Agent(...).
# Only show agent sessions started under ~/work/api
claude agents --cwd ~/work/api
أمّا السكربتات التي تحتاج إلى استهلاك القائمة — سكربتات الإقلاع على نمط tmux-resurrect، وأشرطة الحالة المخصّصة، ومنتقيات الجلسات — فمرّر --json إلى claude agents للحصول على بيانات قابلة للقراءة آليًّا في صورة مصفوفة بدل العرض التفاعلي. يشمل كلّ مدخل pid وcwd وkind وstartedAt، إضافةً إلى sessionId وname وstatus عند توفّرها. وحين تكون status بقيمة waiting، يُحدّد waitingFor بدقّة ما الذي تنتظره الجلسة، مثل permission prompt أو input needed، ممّا يتيح للسكربتات توجيه تلك الحالات إلى إجراءات مختلفة:
# Wake up every session that's blocked on a permission prompt
claude agents --json | jq -r '.[] | select(.status == "waiting" and .waitingFor == "permission prompt") | .sessionId' | xargs -I {} claude respawn {}
First use the code-analyzer agent to find performance bottlenecks, then use the optimizer agent to fix them.
يتضمّن Claude Code عدّة وكلاء مدمجين لا تحتاج إلى إنشائهم: general-purpose يتولّى المهام العريضة متعدّدة الخطوات، وExplore يستخدم Haiku لتحليل الشيفرة بقراءة فقط وبسرعة، وPlan يبحث في الشيفرة قبل عرض خطط التنفيذ، وclaude-code-guide يُجيب عن الأسئلة المتعلّقة بميزات Claude Code. ويمكن أيضًا استئناف الوكلاء، ممّا يتيح لـ Claude مواصلة محادثة وكيل سابقة عبر المعرّف (ID) حين يمتدّ سير العمل عبر عدّة أدوار.
اضبط CLAUDE_CODE_FORK_SUBAGENT=1 لتفعيل الوكلاء الفرعيين المتفرّعين (forked). يرث الوكيل الفرعي المتفرّع سياق المحادثة الكامل من الجلسة الرئيسية بدل البدء من الصفر. وعند تفعيله، يُطلق /fork وكيلًا فرعيًّا متفرّعًا بدل أن يكون اسمًا بديلًا لـ /branch، وتعمل جميع إطلاقات الوكلاء الفرعيين في الخلفية. ويعمل هذا في الجلسات التفاعليّة، والوضع غير التفاعلي، وفي Agent SDK، وعلى البُنى الخارجيّة:
CLAUDE_CODE_FORK_SUBAGENT=1 claude
تنسّق ميزة فِرَق الوكلاء التجريبيّة (Agent Teams) — التي تتطلّب CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 أو راية سطر الأوامر --agent-teams — بين عدّة نسخ من Claude تعمل بالتوازي عبر قائمة مهام مشتركة وصندوق بريد. وهي مصمّمة للمشاريع الكبيرة متعدّدة الملفات حيث يمكن لوكلاء مستقلّين العمل على أجزاء مختلفة في آنٍ واحد دون أن يتعارضوا.
تستأنف SendMessage الوكلاء المتوقّفين تلقائيًّا عند إرسال رسالة إليهم، فلم تعد بحاجة إلى استئناف وكيل صراحةً قبل التواصل معه. واعتبارًا من الإصدار v2.1.178، أُزيلت أداتا TeamCreate وTeamDelete: فمع ضبط الراية، يكون لكلّ جلسة فريق ضمني واحد بالفعل، إذ تُطلق الزملاء مباشرةً عبر معامل name في أداة Agent — دون خطوة إعداد — ويحدث التنظيف تلقائيًّا عند خروج الجلسة.
أمثلة واقعيّة على الوكلاء الفرعيين
إليك تعريفات وكلاء فرعيين جاهزة للإنتاج يمكنك وضعها في دليل .claude/agents/ الخاصّ بمشروعك:
المثال 1: وكيل مُراجِع الشيفرة
مُراجِع متخصّص يفحص تلقائيًّا الشيفرة المُعدَّلة بحثًا عن الثغرات الأمنيّة، ومشكلات الأداء، ومعايير الجودة:
---
name: code-reviewer
description: Expert code review specialist. Use PROACTIVELY after writing or modifying code.
tools: Read, Grep, Glob, Bash
model: inherit
---
# Code Reviewer Agent
When invoked:
1. Run git diff to see recent changes
2. Focus on modified files
3. Begin review immediately
## Review Priorities (in order)
1. Security Issues - Authentication, authorization, data exposure
2. Performance Problems - O(n^2) operations, memory leaks, inefficient queries
3. Code Quality - Readability, naming, documentation
4. Test Coverage - Missing tests, edge cases
5. Design Patterns - SOLID principles, architectureالمثال 2: وكيل مُحسِّن الأداء
وكيل يُحلّل الأداء (profiles)، ويحدّد عُنُق الزجاجة، وينفّذ التحسينات مع مقاييس قبليّة وبعديّة:
---
name: performance-optimizer
description: Performance analysis and optimization specialist. Use PROACTIVELY after writing or modifying code.
tools: Read, Edit, Bash, Grep, Glob
model: inherit
---
# Performance Optimizer Agent
When invoked:
1. Profile the target code or system
2. Identify the most impactful bottlenecks
3. Propose and implement optimizations
4. Measure and verify improvements
## Common Profiling Commands
# Node.js
node --prof app.js
# Python
python -m cProfile -s cumulative script.py
# Go
go test -cpuprofile=cpu.out ./...
# Database (PostgreSQL)
EXPLAIN ANALYZE SELECT ...;المثال 3: وكيل مهندس الاختبارات
خبير في أتمتة الاختبارات يكتب اختبارات شاملة تتضمّن الحالات الحدّيّة وسيناريوهات الأخطاء:
---
name: test-engineer
description: Test automation expert. Use PROACTIVELY when new features are implemented.
tools: Read, Write, Bash, Grep
model: inherit
---
# Test Engineer Agent
## Coverage Requirements
- Minimum 80% code coverage
- 100% for critical paths (auth, payments, data handling)
## Test Structure Example
describe('Feature: User Authentication', () => {
beforeEach(() => { /* Setup */ });
afterEach(() => { /* Cleanup */ });
it('should authenticate valid credentials', async () => {
// Arrange, Act, Assert
});
it('should reject invalid credentials', async () => {
// Test error case
});
});نصائح احترافيّة
- ابدأ بالتقييد، ووسّع عند الحاجة. امنح الوكيل الفرعي الأدوات التي يحتاجها فعلًا فقط—فمُراجِع الشيفرة مثلًا لا يحتاج إلّا إلى
Read, Grep, Glob. يمكنك دائمًا إضافة أدوات لاحقًا حين تستدعي المتطلّبات ذلك. - اكتب موجّهات مركّزة أحاديّة الغرض. مُراجِع الشيفرة لا ينبغي أن يكتب التوثيق أيضًا. تخلق المسؤوليّات المتداخلة ارتباكًا وتُقلّل معدّلات النجاح. صمّم كلّ وكيل فرعي حول مسؤوليّة واحدة واضحة.
- شجّع الاستدعاء الاستباقي. أضف عبارة «use PROACTIVELY» أو «MUST BE USED» إلى حقل
descriptionليفوّض Claude تلقائيًّا حين ينشأ الموقف، بدل انتظار طلبات صريحة. - أخضِع وكلاء المشروع للتحكّم بالإصدارات. احفظ
.claude/agents/في git ليستفيد فريقك بأكمله من الوكلاء الفرعيين المتخصّصين أنفسهم، ويبقى الضبط متّسقًا. - استخدم الربط التسلسلي لسير العمل المعقّد. اطلب من Claude تشغيل الوكلاء بالتتابع (مثلًا «حلّل أوّلًا بوكيل code-analyzer، ثم أصلح المشكلات بوكيل optimizer») لبناء خطوط معالجة (pipelines) يُغذّي فيها خرج وكيلٍ الوكيلَ التالي.
تحدٍّ تطبيقي
ابنِ فريقًا من الوكلاء الفرعيين المتخصّصين لأتمتة سير عمل مراجعة الشيفرة من بدايته إلى نهايته.
المهمّة
أنشئ فريق وكلاء فرعيين على مستوى المشروع بوكيلين: مُراجِع أمان بقراءة فقط ومهندس اختبارات قادر على كتابة الاختبارات الناقصة. ثم اربطهما تسلسليًّا بحيث تُعالَج النتائج الأمنيّة قبل فحص تغطية الاختبارات.
الخطوات
- أنشئ دليل
.claude/agents/في مشروعك. - اكتب
secure-reviewer.mdبرأسيّة YAML تمنح أدواتRead, Grepفقط، وموجّه نظام يركّز على ثغرات المصادقة، والحقن (injection)، وكشف البيانات. ضمّن عبارة «use PROACTIVELY» في الوصف ليُستدعى تلقائيًّا. - اكتب
test-engineer.mdبأدواتRead, Write, Bash, Grepوموجّه يستهدف تغطية تتجاوز 80% وتحديد الحالات الحدّيّة. - شغّل
/agentsللتحقّق من ظهور كلا الوكيلين في القائمة التفاعليّة. - أجرِ تغييرًا بسيطًا في الشيفرة، ثم اطلب من Claude «استخدم أوّلًا الوكيل الفرعي secure-reviewer لتدقيق التغييرات، ثم استخدم الوكيل الفرعي test-engineer لإضافة أيّ اختبارات ناقصة.»
- تحقّق من أنّ وكيل الأمان لم يستطع تعديل الملفات (قراءة فقط) بينما استطاع وكيل الاختبارات ذلك.
النتيجة المتوقّعة
ملفّا وكيلين فرعيين في .claude/agents/، كلاهما ظاهر في /agents، وتنفيذ مترابط تسلسليًّا يُنتج تقريرًا أمنيًّا متبوعًا بملفات اختبارات جديدة أو محدّثة، وتأكيد على أنّ قيود الأدوات قد طُبِّقت.
تلميح
تذكّر أنّ حقل
toolsيتحكّم في ما يستطيع كلّ وكيل فعله. أغفِله ليرث كلّ شيء، أو اذكر أدوات محدّدة مثلtools: Read, Grepلوكيل بقراءة فقط. استخدم البادئة@(مثلًا@"secure-reviewer (agent)") لضمان استدعاء وكيل بعينه.
اختبار المعرفة
اختبر فهمك للوكلاء الفرعيين في Claude Code بهذه الأسئلة:
س1: ما الميزة الرئيسية للوكلاء الفرعيين مقارنةً بالمحادثة المضمّنة؟
أ) أنّهم أسرع
ب) أنّهم يعملون في نافذة سياق منفصلة ونظيفة تمنع تلوّث السياق
ج) أنّهم يستطيعون استخدام أدوات أكثر
د) أنّ معالجتهم للأخطاء أفضل
الإجابة الصحيحة: ب — يحصل الوكلاء الفرعيون على نافذة سياق جديدة، ولا يتلقّون إلّا ما يمرّره الوكيل الرئيسي. وهذا يمنع تلوّث المحادثة الرئيسية بتفاصيل خاصّة بالمهمّة.
س2: ما ترتيب الأولويّة لتعريفات الوكلاء؟
أ) المشروع > المستخدم > سطر الأوامر
ب) سطر الأوامر > المشروع > المستخدم
ج) المستخدم > المشروع > سطر الأوامر
د) جميعهم بأولويّة متساوية
الإجابة الصحيحة: ب — الوكلاء المُعرَّفون عبر سطر الأوامر (راية --agents) يتجاوزون وكلاء مستوى المشروع (.claude/agents/)، الذين يتجاوزون بدورهم وكلاء مستوى المستخدم (~/.claude/agents/).
س3: أيّ وكيل فرعي مدمج يستخدم نموذج Haiku ومُحسَّن لاستكشاف الشيفرة بقراءة فقط؟
أ) general-purpose
ب) Plan
ج) Explore
د) Bash
الإجابة الصحيحة: ج — يستخدم الوكيل الفرعي Explore نموذج Haiku لاستكشاف الشيفرة بقراءة فقط وبسرعة. وهو يدعم ثلاثة مستويات للدقّة: سريع، ومتوسّط، ودقيق جدًّا.
س4: كيف تُقيّد الوكلاء الفرعيين الذين يستطيع وكيل منسّق إطلاقهم؟
أ) استخدام حقل allowed-agents:
ب) استخدام صيغة Task(agent_name) في حقل tools
ج) ضبط spawn-limit: 2
د) استخدام restrict-agents: [name1, name2]
الإجابة الصحيحة: ب — إضافة Task(worker, researcher) في حقل tools تُنشئ قائمة سماح — إذ لا يستطيع الوكيل إطلاق إلّا وكلاء فرعيين باسم «worker» أو «researcher».
س5: ماذا يفعل isolation: worktree لوكيل فرعي؟
أ) يُشغّل الوكيل في حاوية Docker
ب) يمنح الوكيل شجرة عمل git خاصّة به بحيث لا تؤثّر التغييرات في الشجرة الرئيسية
ج) يمنع الوكيل من قراءة أيّ ملفات
د) يُشغّل الوكيل في صندوق رمليّ (sandbox)
الإجابة الصحيحة: ب — يُنشئ عزل شجرة العمل شجرة عمل git منفصلة. فإن لم يُجرِ الوكيل أيّ تغييرات، تُنظَّف تلقائيًّا. وإن أُجريت تغييرات، يُعاد مسار شجرة العمل والفرع.
اختبر معرفتك
مصادر إضافيّة
| المصدر | النوع | ما الذي ستتعلّمه |
|---|---|---|
| توثيق الوكلاء الفرعيين الرسمي | توثيق | المفاهيم الأساسيّة، وحقول الضبط، ودورة الحياة الكاملة للوكيل الفرعي |
| فِرَق الوكلاء (تجريبي) | توثيق | تنسيق متعدّد الوكلاء بقوائم مهام مشتركة وتراسل بين الوكلاء |
مرجع سطر الأوامر — راية --agents | مرجع | تعريف الوكلاء عبر JSON للاستخدام في جلسة واحدة |
| سجلّ تغييرات Claude Code | سجلّ تغييرات | تداخل الوكلاء الفرعيين (v2.1.172)، والمطابقة غير الحسّاسة لحالة الأحرف (v2.1.140)، ورأسيّات الرصد (v2.1.139) |
| دليل الإضافات | دليل | تحزيم الوكلاء الفرعيين في حزم إضافات قابلة للتوزيع |
الوكلاء الفرعيون في Claude Code: أخطاء شائعة يجب تجنّبها
معظم مشكلات الوكلاء الفرعيين في الإنتاج تنشأ من ضبط الصلاحيات والوصف، لا من منطق الوكيل نفسه.
- منح الوكيل الفرعي كل الأدوات الافتراضية بدل تقييدها بـ
tools: Read, Grepعندما يكفيه القراءة فقط. - كتابة وصف (description) غامض فلا يعرف المنسّق متى يستدعي الوكيل الفرعي تلقائيًا.
- تجاهل تعارض الأسماء بين وكلاء المشروع والمستخدم والإضافات، فيُستدعى تعريف غير المقصود.
- الإفراط في التفويض لمهام صغيرة لا تحتاج عزلًا، فتضيف زمن استجابة دون فائدة تُذكر.
الوكلاء الفرعيون في Claude Code يمنحونك سير عمل متينًا وقابلًا للتكرار. احفظ دليل الوكلاء الفرعيين في Claude Code هذا في مفضّلتك، وعُد إلى الخطوات كلّما احتجت إليها.

الوكلاء الفرعيون في Claude Code: أفضل الممارسات
- فوّض العمل المستقلّ القابل للتوازي إلى الوكلاء الفرعيين؛ وأبقِ العمل التسلسلي في الخيط الرئيسي.
- امنح كلّ وكيل فرعي هدفًا واحدًا واضحًا والسياق الذي يحتاجه.
- استخدم العزل حتى لا تصطدم الوكلاء المتوازية ببعضها في الملفات المشتركة.
- لخّص نتائج الوكلاء الفرعيين عائدًا بها إلى الخيط الرئيسي للحفاظ على إحكام السياق.
- تجنّب الإفراط في التفويض؛ فإطلاق وكلاء لمهام تافهة يضيف عبئًا.

الوكلاء الفرعيون في Claude Code: أسئلة شائعة
ما الوكيل الفرعي؟
الوكيل الفرعي عاملٌ مُفوَّض يتولّى مهمّة مركّزة، بالتوازي مع غيره اختياريًّا.
متى ينبغي أن أفوّض؟
فوّض العمل المستقلّ القابل للتوازي؛ وأبقِ العمل التسلسلي المترابط بإحكام في الخيط الرئيسي.
ما عزل الوكلاء؟
يمنع العزل الوكلاء الفرعيين المتوازين في Claude Code من التداخل فيما بينهم في الملفات المشتركة.
هل يمكنني الإفراط في التفويض؟
نعم — فإطلاق وكلاء لمهام تافهة يضيف عبئًا دون فائدة.
هل يمكن لوكيل فرعي استدعاء وكيل فرعي آخر؟
يمكن للوكيل المنسّق (الرئيسي) استدعاء عدة وكلاء فرعيين وربطهم تسلسليًّا، لكن الوكلاء الفرعيين أنفسهم لا يستدعون بعضهم مباشرة.