باختصار: لتشغيل عدة وكلاء من Claude Code بالتوازي، امنح كل جلسة شجرة عمل git (git worktree) خاصة بها (الأمر claude -w <name> ينجز ذلك عبر خيار واحد)، وأرسل الجلسات التي لا تتابعها إلى الخلفية باستخدام claude --bg، وحدد ترتيب الدمج قبل أن ينتهي الوكلاء من عملهم، لأن الفروع المعزولة تظل عرضة للتعارض عند دمجها. مشاركة جلستين لمجلد عمل واحد (checkout) هي السبب وراء احتواء إيداع (commit) أحد الوكلاء على كود غير مكتمل كتبه وكيل آخر. هذا الدليل موجه للمطورين الذين يستخدمون Claude Code بالفعل ويرغبون في تشغيل جلستين إلى خمس جلسات في الوقت نفسه.
يبدأ الأمر بفتح نافذة طرفية ثانية. يكون Claude Code يعيد صياغة وحدة المصادقة في النافذة الأولى، فتفتح نافذة أخرى وتطلب من جلسة جديدة إصلاح اختبار التاريخ غير المستقر (flaky date test). ثم تفتح نافذة ثالثة للتوثيق. بعد عشرين دقيقة، تجد ثلاث جلسات تكتب في دليل عمل واحد، ويُظهر أمر git status قائمة بملفات لا تتذكر أنك طلبت تعديلها، ولا أحد يستطيع تحديد أي جلسة قامت بتعديل config.ts.
تشغيل عدة وكلاء من Claude Code أمر سهل: افتح مزيداً من النوافذ الطرفية. لكن تشغيلهم دون أن تُفسد الجلسات عمل بعضها يتطلب ثلاثة قرارات: أين تتواجد ملفات كل جلسة، وكيف تتابع الجلسات التي لا تشاهدها حالياً، وبأي ترتيب سيتم دمج فروعها. يغطي هذا المقال هذه النقاط الثلاث بالاعتماد على أوامر Claude Code المدمجة، وحالتي فشل قمنا بإعادة إنتاجهما على مستودع تجريبي. إذا كانت أشجار العمل (worktrees) جديدة عليك، فاقرأ أولاً دليلنا حول أشجار عمل git مع وكلاء البرمجة بالذكاء الاصطناعي، أو مرجع git worktree.
لماذا يتسبب تشغيل عدة وكلاء من Claude Code في إفساد مجلد العمل المشترك
يعني تشغيل عدة وكلاء من Claude Code بالتوازي وجود جلستين أو أكثر تعملان على المستودع نفسه في الوقت ذاته، ولكل منها مهمتها الخاصة ونافذة السياق (context window) الخاصة بها. لا تعلم هذه الجلسات شيئاً عن بعضها البعض. فكل جلسة تقرأ الملفات وتعدلها وتجري الاختبارات وتجري الإيداعات (commits) وكأنها تعمل وحدها تماماً.
يحتوي مجلد العمل (checkout) على دليل عمل واحد وفهرس (index) واحد ومؤشر HEAD واحد، لذلك فإن العمل "وكأن الجلسة وحدها" سرعان ما يفشل. لقد أعدنا إنتاج السيناريو الأكثر شيوعاً على مستودع بايثون تجريبي، مع استخدام عمليتي كتابة في الطرفية كبديلين عن الوكيلين. قام الوكيل B بحفظ دالة truncate() غير مكتملة في textutils.py. أنهى الوكيل A مهمته في ملف مختلف وقام بالإيداع بالطريقة التي تمليها عليه العديد من الأوامر التوجيهية (prompts)، عبر git add -A && git commit:
$ git show --stat --format='%an: %s' HEAD
agent-a: add slugify
slug.py | 2 ++
textutils.py | 4 ++++
2 files changed, 6 insertions(+)
$ python3 -m pytest -q
1 error in 0.09s
تضمن إيداع الوكيل A دالة الوكيل B غير المكتملة، وباتت حزمة الاختبارات تعجز حتى عن استيراد الملفات. لم يُستبدل أي محتوى أو يُكتب فوقه. لكن نظراً لأن الفهرس كان مشتركاً، فقد جرف إيداع A عمل B الذي كان قيد التنفيذ، وبات سجل التعديلات يُظهر أن الوكيل A هو من كتب كوداً معطوباً. تم تناول هذه المشكلة عندما تحدث على الملف نفسه في مقالنا: ماذا يحدث عندما يقوم وكيلا برمجة بتعديل الملف ذاته.
تشغيل عدة وكلاء من Claude Code مع تخصيص شجرة عمل مستقلة لكل وكيل
الحل هو تخصيص دليل عمل مستقل لكل جلسة، وتوفر Claude Code ذلك كخيار مدمج:
# interactive sessions, one task each, each in its own worktree
claude -w auth-refactor
claude -w flaky-date-test --tmux # opens the session in its own tmux or iTerm2 pane
# fire-and-forget work: starts in the background and prints an id
claude --bg "update the README examples for the new config format"
وفقاً لـ توثيق أشجار العمل (worktrees)، ينشئ الأمر claude -w <name> شجرة عمل في .claude/worktrees/<name>/ على فرع جديد باسم worktree-<name>، وتحصل نافذة طرفية ثانية باسم مختلف على جلسة ثانية معزولة. وعندما اختبرنا ذلك، صنّف git شجرة العمل الجديدة بأنها locked (مقفلة)، مما يمنع أمر git worktree prune من حذفها أثناء عمل الجلسة. كما أن جلسات الخلفية التي تبدأ بـ --bg أو /bg تنتقل إلى شجرة عمل خاصة بها ضمن .claude/worktrees/ قبل إجراء أي تعديل، وفقاً لما ورد في صفحة عرض الوكلاء (agent view).
ثلاث تفاصيل في الإعداد ستوفر عليك ساعات من تصحيح الأخطاء:
- تجاهل المجلد: تتواجد أشجار العمل داخل المستودع، لذا سيُظهر أمر
git statusفي الدليل الرئيسي مجلد.claude/كملف غير متتبع (untracked) ما لم تقم بإضافة.claude/worktrees/إلى.gitignore، وهو ما تنصح به الوثائق الرسمية أيضاً. - توقع نسخة عمل نظيفة تماماً: لا تحتوي شجرة العمل الجديدة على
node_modulesأو بيئة وهمية (virtualenv) أو ملف.env. حدد الملفات المتجاهلة في git التي تحتاج لنسخها، مثل.env، في ملف.worktreeinclude، وتوقع تخصيص وقت لخطوة التثبيت (install) في كل شجرة عمل. - نظف الجلسات التي تعمل دون واجهة بنفسك: تعرض الجلسات التفاعلية خيار حذف شجرة العمل الخاصة بها عند الخروج. أما الجلسات التي تبدأ عبر
claude -pفلا تقوم بالتنظيف تلقائياً على الإطلاق، لذا ستحتاج إلى إزالتها يدوياً باستخدامgit worktree unlockثمgit worktree remove.
تتم إدارة جلسات الخلفية من خلال الطرفية (shell). هذه التوصيفات مأخوذة من أمر claude --help في الإصدار 2.1.283:
| الأمر | ما يقوم به |
|---|---|
claude --bg "<task>" |
يبدأ الجلسة في الخلفية ويعود فوراً، مع طباعة معرّف الجلسة (id) |
claude agents |
يفتح واجهة عرض الوكلاء، وهي قائمة بالجلسات قيد التشغيل (--json للسكربتات) |
claude logs <id> |
يطبع أحدث مخرجات الطرفية لجلسة الخلفية |
claude attach <id> |
يفتح جلسة الخلفية في النافذة الطرفية الحالية |
claude stop <id> |
يوقف الجلسة؛ مع الاحتفاظ بالمحادثة، ويمكن للأمر claude attach <id> إعادة فتحها |
لا يمكن دمج --bg مع -p. ولتنفيذ مهام برمجية متعددة وموزعة تلقائياً عبر سكربت (scripted fan-out)، يوضح دليل العمل مع Claude Code من Anthropic كيفية إنشاء حلقة تكرارية في الطرفية تستدعي claude -p مع --allowedTools و--permission-mode dontAsk. اجمع ذلك مع الخيار -w حتى يحصل كل تشغيل على دليله الخاص.
الوكلاء المعزولون في Claude Code يظلون عرضة للتعارض عند الدمج
تمنع أشجار العمل الجلسات من التداخل فيما بينها أثناء كتابة الكود، لكنها لا تجعل التعديلات متوافقة تلقائياً. لقد قمنا بتطبيق النوع ذاته من التغييرات على فرعين في شجرتي عمل منفصلتين، حيث أضاف كل منهما دالة في نهاية ملف textutils.py، ثم قمنا بدمج الفرعين:
$ git merge agent/slugify
Fast-forward
$ git merge agent/truncate
Auto-merging textutils.py
CONFLICT (content): Merge conflict in textutils.py
Automatic merge failed; fix conflicts and then commit the result.
لم يرتكب أيٌّ من الوكيلين أي خطأ. كلاهما أضاف كوداً في الموضع نفسه، ولا يستطيع git اختيار الترتيب تلقائياً. في المشاريع البرمجية الحقيقية مع تشغيل أربع أو خمس جلسات، يعد هذا السيناريو أمراً اعتيادياً لأي ملف تتقاطع عنده التعديلات: جداول التوجيه (route tables)، وتصديرات __init__.py، وسجلات التغييرات (changelogs)، وملفات القفل (lockfiles). الفارق هنا عن مجلد العمل المشترك هو أن التعارض أصبح الآن واضحاً وصريحاً ويمكن تتبعه وتحديد مصدره. وهناك ثلاث ممارسات تحد من حجم هذه التعارضات:
- قسّم المهام حسب الملفات، لا حسب الميزات: إذا كانت هناك مهمتان تحتاجان معاً لتعديل موجه المسارات (router)، فاجعلهما مهمة واحدة، أو شغلهما بالتتابع واحدة تلو الأخرى.
- ادمج بترتيب محدد وأعد مواءمة الباقي (rebase): ادمج الفرع الأول، ثم اطلب من الجلسة التالية تنفيذ rebase على فرع
mainوإعادة تشغيل اختباراتها قبل أن تبدأ بمراجعتها. فالجلسة التي كتبت الكود تمتلك السياق الكافي لحل التعارض الخاص بها. - سمِّ كل شجرة عمل باسم المهمة الموكلة إليها: استخدام
claude -w fix-date-testأفضل بكثير منclaude -w agent2عندما تراجع مخرجات أمرgit worktree listبعد ساعة من بدء العمل.
العائق الحقيقي في الغالب ليس أداة git، بل قدرتك أنت على قراءة ومراجعة خمسة فروقات برمجية (diffs) في آن واحد. يوضح مقالنا حول لماذا تعد المراجعة البشرية هي عنق الزجاجة للوكلاء المتوازيين كيفية تنظيم طابور المراجعة هذا بصورة مناسبة.
الوكلاء الفرعيون، أو فرق الوكلاء، أو الجلسات المستقلة لتشغيل عدة وكلاء من Claude Code
يوفر Claude Code حالياً عدة طرق لتشغيل المهام بالتوازي، ويسرد الدليل الشامل للوكلاء المتوازيين هذه الخيارات جنباً إلى جنب. هذه الخيارات ليست متطابقة في الوظيفة، والمعيار الأكثر أهمية بينها هو مستوى العزل:
| الخيار | ما الذي يعمل | عزل الملفات | متى يُستخدم |
|---|---|---|---|
| Subagents | مساعدون داخل جلسة واحدة، لكل منهم نافذة سياق خاصة به | مجلد عمل مشترك، ما لم يحدد الوكيل الفرعي isolation: worktree |
عندما تتطلب مهمة واحدة إجراء بحث جانبي، أو جولة مراجعة، أو قراءات متوازية |
/batch |
تعديل واحد مقسم على 5 إلى 30 وكيلاً فرعياً | شجرة عمل مستقلة لكل وكيل فرعي | تعديل آلي واسع النطاق يتوزع على العديد من الملفات |
| فرق الوكلاء (Agent teams) | جلسة رئيسية مع زملاء فريق يتشاركون قائمة مهام ويتبادلون الرسائل | لا يوجد عزل: تنصح الوثائق بتقسيم نطاق العمل | عندما يحتاج زملاء الفريق إلى التواصل أثناء المهمة؛ ميزة تجريبية، معطلة افتراضياً |
جلسات منفصلة (-w، و--bg، وتطبيق سطح المكتب) |
جلسات مستقلة | شجرة عمل مستقلة لكل جلسة | مهام مستقلة تراجعها واحدة تلو الأخرى |
جلسات السحابة (claude --cloud) |
جلسات في أجهزة افتراضية معزولة تستنسخ الفرع الذي قمت بدفعه | جهاز افتراضي مستقل لكل جلسة | المهام التي لا ينبغي أن تستهلك موارد حاسوبك المحمول |
للمهام المستقلة، استخدم جلسات منفصلة مع أشجار العمل. واستخدم فرق الوكلاء عندما تكون الأجزاء معتمدة على بعضها ويحتاج أعضاء الفريق إلى التنسيق، مع إسناد ملفات مختلفة لكل عضو، إذ إن صفحة فرق الوكلاء واضحة وصريحة تماماً في هذا الشأن: "تعديل عضوين للملف نفسه يؤدي إلى الكتابة فوق التعديلات واستبدالها". وأياً كان خيارك، فإن الاستهلاك مشترك؛ وتلخص وثائق عرض الوكلاء ذلك بوضوح: "تشغيل عشرة وكلاء بالتوازي يستهلك الحصة المخصصة بسرعة تزيد بنحو عشرة أضعاف مقارنة بتشغيل وكيل واحد".
دور Sharkly عند تشغيل عدة وكلاء من Claude Code
إذا كنت تشغل جلستين أو ثلاث على حاسوبك المحمول وتراجع كل تغيير بنفسك، فإن الأوامر المذكورة أعلاه تكفيك تماماً وقد لا تحتاج إلى Sharkly. لكن المعادلة تتغير عندما تعود الجلسات لأكثر من شخص، أو عندما يستغرق البحث عن إجابة لسؤال "أي جلسة تتضمن إصلاح اختبار التاريخ؟" وقتاً أطول مما استغرقه كتابة الإصلاح نفسه.
أنت تمتلك بالفعل وكلاء برمجة، وتعمل منصة Sharkly على تحويلهم إلى فريق عمل متكامل. يتحول كل جزء من العمل إلى مهمة (Task)، تُسندها إلى وكيل يعمل على بيئة تشغيل Claude Code Runtime على أحد أجهزتك، ويؤدي تعيين الشخص المسؤول إلى بدء التشغيل. من خلال دليل العمل الافتراضي، Create temporary directory، تحصل كل مهمة على دليل خاص بها وتتلقى عمليات التشغيل المرتبطة بالمستودع شجرة عمل git معزولة: وهو مستوى العزل نفسه الذي يوفره claude -w، دون الحاجة لتسمية أشجار العمل يدوياً. وعندما يضطر الوكيل لإعادة استخدام بيئة موجودة مسبقاً على جهاز محلي، يوفر خيار Run in isolated worktrees نتيجة كل مهمة على فرعها الخاص بصيغة agent/<agent>/<task>. كما يضع خيار Max concurrency (assigned tasks) لدى الوكيل حداً أقصى لعدد العمليات المتزامنة في آن واحد، وهو ما يمثل سقف المراجعة المذكور سابقاً، معلناً بوضوح أمام الفريق بأكمله.
تُسجَّل نسبة التقدم وسجل التشغيل والنتائج مباشرة في المهمة، ويصل كل ما يتطلب تدخلاً بشرياً إلى صندوق الوارد (Inbox). لا شيء يُدمج تلقائياً: بل يراجع المطور التغييرات في شجرة العمل، ويقرر الإبقاء عليها أو دمجها أو استبعادها، ثم يحدد حالة المهمة بأنها مكتملة (Done). تظل تكاليف التشغيل تُحسب على خطتك الخاصة في Claude Code، لأن Sharkly لا تبيع رموز المعالجة (tokens). توضح صفحة ميزات الوكلاء خطوات الإعداد، بينما يغطي مقال كيف تشغل Sharkly الوكلاء بالتوازي الجانب التنفيذي بالتفصيل.
إذا تجاوزت مرحلة إدارة ثلاث نوافذ طرفية وترغب في جمع نتائج كل جلسة من جلسات Claude Code في مكان مركزي واحد يسهل على المراجع معالجتها، فهذه هي المشكلة التي صُممت Sharkly خصيصاً لحلها.
الأسئلة الشائعة
كم عدد وكلاء Claude Code الذين يمكنني تشغيلهم في الوقت نفسه؟ لا تضع الوثائق حداً أقصى لعدد الجلسات المنفصلة. يعمل الوكلاء الفرعيون افتراضياً بحد أقصى يصل إلى 20 وكيلاً في الوقت ذاته، وتقترح صفحة فرق الوكلاء البدء بـ 3 إلى 5 أعضاء فريق. أما الحدود الفعلية فتتمثل في حصة الاستخدام المتاحة في خطتك، وموارد المعالج والذاكرة في حاسوبك، وعدد النتائج التي يمكنك مراجعتها خلال اليوم؛ ويستحق حساب سعة المراجعة التفكير فيه جيداً قبل تشغيل جلسة سادسة.
هل تتشارك جلسات Claude Code المتوازية حدود الاستخدام الخاصة بي؟ نعم. في باقتي Pro وMax، تكون حدود الاستخدام مشتركة بين Claude وClaude Code، بنطاق زمني مدته خمس ساعات وحد أسبوعي، وتستهلك كل جلسة متوازية من الرصيد نفسه. وفي حال تعيين ANTHROPIC_API_KEY، يقوم Claude Code باحتساب التكلفة عبر واجهة برمجة التطبيقات (API) بدلاً من ذلك.
هل ينسخ الأمر claude --worktree ملف .env والتبعيات البرمجية؟ لا. كل شجرة عمل هي نسخة عمل نظيفة تماماً. أضف الملفات المتجاهلة في git التي تحتاج إليها، مثل .env، إلى ملف .worktreeinclude، وقم بتنفيذ خطوة التثبيت في كل شجرة عمل.
هل يمكنني تشغيل Claude Code وCodex بالتوازي على المستودع نفسه؟ نعم، مع تطبيق القاعدة ذاتها: شجرة عمل مستقلة لكل جلسة وتحديد ترتيب الدمج. يغطي دليلنا حول تشغيل Claude Code وCodex معاً على قاعدة كود واحدة كيفية توجيه المهام بينهما.
