المهام المتوازية: تشغيل عدة نسخ من Claude في نفس الوقت بدلاً من الانتظار
📚 دليل السلسلة: الدرس السابق 40 Chrome: دعه يتحكم في المتصفح علمك كيفية إدخال يد Claude إلى المتصفح للضغط على الصفحات وملء النماذج تلقائياً. هذا الدرس يغير البعد — بدلاً من جعل Claude واحد يقوم بمهام متعددة، سنجعل عدة مهام تبدأ بالعمل في نفس الوقت. سنوضح ثلاث وسائل: عزل git worktree، المحادثات المتعددة في الخلفية، والتشغيل الجماعي غير التفاعلي (headless)، بالإضافة للشرط الأهم: متى يكون التوازي مفيداً حقاً، ومتى يسبب الفوضى فقط.
من المحرج قول ذلك، ولكن في المرة الأولى التي فكرت فيها بـ "العمل المتوازي"، قمت بحركة غبية: فتحت طرفيتين، وانتقلت في كلتيهما إلى نفس مجلد المشروع (cd)، وطلبت من Claude في إحداهما تعديل صفحة تسجيل الدخول للواجهة الأمامية، وطلبت منه في الأخرى إصلاح خطأ في الواجهة الخلفية بالمرة.
وكنت سعيداً جداً وأفكر: "أليست هذه كفاءة مضاعفة؟"
والنتيجة كانت — كلا الجانبين كانا يعدلان ملف package.json، والاعتماديات التي كتبها أحد الجانبين للتو تم تجاوزها والتراجع عنها بسبب تعديل الجانب الآخر؛ وعند كتابة git status وجدت بيئة العمل فوضوية تماماً، ولم أستطع تمييز من قام بتعديل أي سطر. وقضيت في ذلك اليوم وقتاً أطول بكثير مما لو كنت قد "أنجزت المهام واحدة تلو الأخرى بهدوء" حتى استطعت فرز التعديلات يدوياً، وكنت غاضباً جداً. منذ تلك المرة فهمت: التوازي ليس مجرد "فتح نوافذ متعددة"، بل جوهره هو "عدم السماح لها بلمس نفس المكان".
في الواقع، يوفر Claude Code أدوات توازي حقيقية وجاهزة — حيث يمنحك --worktree نسخة معزولة من الكود لكل محادثة، ويرسل --bg المهام إلى الخلفية لتعمل جماعياً، ويعطيك claude agents لوحة تحكم مركزية لمراقبة حركتها. في هذا الدرس، سنقوم بحل هذه المشكلة من جذورها، ونأخذك لتجربة هذه الوسائل بنفسك.
بعد قراءة هذا الدرس، ستحصل على:
- شرح مبسط لـ "لماذا التوازي"، والشرطان الأساسيان له: استقلالية المهام، وعدم التنافس على نفس الملف
- مقارنة بين أربعة طرق توازي رسمية (الوكيل الفرعي / واجهة الوكيل / فرق الوكلاء / تدفقات العمل الديناميكية) في جدول واحد لتختار منها المناسب
- استخدام
--worktreeلمنح كل محادثة نسخة معزولة تمنع التداخل — مع تنبيهات حول.worktreeincludeوعمليات التنظيف - استخدام
claude agentsو--bgلإرسال المهام إلى الخلفية ومراقبة تقدمها من شاشة واحدة والتدخل عند الحاجة فقط - استخدام
claude -p(الوضع غير التفاعلي، headless) لكتابة المهام في سيناريوهات لتشغيلها جماعياً، مع--bareللتشغيل الأسرع - الحد الحاسم والأهم: متى يستحق الأمر التوازي، ومتى يسبب لك التعقيد فقط
01 فكر جيداً: ما المشكلة التي يحلها التوازي، وما هو شرطه الأساسي
الخلاصة أولاً: يحل التوازي مشكلة "المهام المتعددة غير المرتبطة التي لا نريد انتظار دورها لتنفيذها واحدة تلو الأخرى"؛ ولكن نجاحه يعتمد بالكامل على شرط واحد — ألا تتنافس هذه المهام على نفس الملف.
تذكر الدروس الأربعين السابقة، كنا نعمل دائماً داخل "محادثة واحدة" — نفتح Claude واحد، ونوجه له التعليمات، ويعمل خطوة بخطوة. هذا النمط كافٍ لـ 90% من المهام. ولكن هناك حالتان تشعر فيهما بأنه بطيء.
الأولى: المهام قابلة للتفكيك بطبيعتها ولا تعتمد على بعضها. مثل "تعديل مظهر الواجهة الأمامية" و "إصلاح خطأ في الواجهة الخلفية" و "إضافة اختبارات وحدة"، فهذه المهام الثلاث لا علاقة لها ببعضها، ولكن عليك انتظار دورها: تعديل الواجهة الأمامية أولاً ثم الخلفية. بالرغم من إمكانية عملها معاً، إلا أنك مجبر على تسييرها بالتوالي.
الثانية: المهمة كبيرة جداً لدرجة لا تستطيع محادثة واحدة تحملها. مثل "استبدال واجهة API قديمة بواحدة جديدة في مستودع الكود بالكامل"، وهي مهمة تشمل عشرات أو مئات الملفات، فإذا قامت محادثة واحدة بتعديلها من البداية للنهاية، فإن السياق (context، أي ذاكرة العمل للذكاء الاصطناعي، راجع الدرس 19 بالتفصيل) سيمتلئ بسرعة، ويبدأ بنسيان الأشياء كلما تقدم في العمل.
تشبيه: الدفع في السوبرماركت. إذا كان هناك مسار دفع واحد، وعشرة أشخاص يقفون بعربات التسوق في طابور طويل، فسيضطر الشخص العاشر للانتظار حتى ينتهي الأشخاص التسعة أمامه — وهذا هو التوالي. أما السوبرماركت الذكي فسيقوم بفتح عدة منافذ للدفع، ويتوزع الأشخاص العشرة على ثلاثة أو أربعة طوابير للدفع معاً، مما يقلل الوقت الإجمالي فوراً. والعمل المتوازي هو بمثابة "فتح عدة منافذ": توزيع المهام المستقلة على عدة نسخ من Claude لتتم معالجتها معاً بدلاً من حشرها في طابور واحد.
ولكن فتح عدة منافذ للدفع يعتمد على شرط خفي: أن يكون كل طابور مستقلاً ولا يتداخل مع الآخر. فإذا كان ثلاثة موظفين يستخدمون نفس صندوق المال ويضعون ويسحبون المال منه في نفس الوقت، فستحدث فوضى فورية — وهذا هو الفخ الذي ذكرته في البداية. لذلك فإن قاعدة التوازي الصارمة هي واحدة:
هل تلمس المهام نفس الملفات؟ استخدم worktrees لعزل العمل.
وفي السيناريوهات الحقيقية التي ستواجهها، تبدو المهام القابلة للتوازي هكذا:
- "إصلاح الأخطاء في هذه الوحدات الثلاث غير المرتبطة بشكل منفصل" — توزيعها على ثلاث محادثات لإصلاحها معاً دون تداخل
- "البحث عن الكود الميت غير المستخدم في مجلد
utils/بالكامل" — إرسال subagent للبحث، لمنع امتلاء المحادثة الرئيسية بالملفات الكثيرة (راجع الدرس 23 بالتفصيل) - "تشغيل نفس التعديل على 30 ملفاً باستخدام نفس السيناريو" — كتابتها كمهام headless لتشغيلها جماعياً وتدع الآلة تقوم بالعمل
💡 خلاصة القول في جملة واحدة: التوازي يهدف لجعل المهام المستقلة لا تنتظر في طابور (مثل فتح عدة منافذ دفع)، ولكن القاعدة الذهبية لنجاحه هي ألا تتنافس على نفس الملف، وإلا زادت الفوضى مع التوازي.
02 أربعة طرق توازي رسمية: تعرف عليها أولاً ولا تشتت نفسك في البداية
لا يقتصر التوازي في Claude Code على طريقة واحدة. تفرد الوثائق الرسمية صفحة بعنوان "تشغيل الوكلاء بالتوازي" للمقارنة بينها، والفارق الجوهري يكمن في سؤال واحد: من الذي ينسق هذه المهام؟ هل يقوم Claude بتوزيع وجمع المهام داخل محادثة واحدة، أم تقوم أنت بإرسالها ومراجعتها لاحقاً، أم يعمل Claude كقائد لتنسيق فريق كامل.
تعرف على الطرق الأربعة في جدول واحد أولاً، فهذا القسم يمثل الخريطة، وسنتعمق في الأقسام التالية:
| الطريقة | ما هي | من ينسق | متى تستخدم |
|---|---|---|---|
| الوكيل الفرعي (Subagent) | عامل يتم إرساله داخل نفس المحادثة، ليعمل في سياقه الخاص ويعود بالخلاصة | يقوم Claude بتوزيع المهام وجمعها داخل المحادثة | عندما تمتلئ المحادثة الرئيسية بنتائج البحث أو السجلات لمهام مساعدة، بينما لن تحتاج لمراجعة التفاصيل |
| واجهة الوكيل (Agent view) | شاشة واحدة لجدولة ومراقبة محادثات متعددة في الخلفية، تفتح عبر claude agents (نسخة تجريبية) | تقوم أنت بإرسال المهام ومتابعتها لاحقاً | عندما تملك عدة مهام مستقلة وتريد إرسالها ومتابعة حالتها والتدخل عند الحاجة فقط |
| فرق الوكلاء (Agent teams) | محادثات متعددة تنسق العمل معاً، وتتشارك قوائم المهام وتتبادل الرسائل تحت إدارة قائد (تجريبي، مغلق افتراضياً) | يعمل Claude كقائد لتنسيق الفريق | عندما تريد من Claude تقسيم المشروع لعدة أجزاء وتوزيعها ومزامنة العمال (راجع الدرس 29 بالتفصيل) |
| تدفقات العمل الديناميكية (Workflows) | سيناريو لتشغيل عدد كبير من الوكلاء الفرعيين والتحقق المتبادل من النتائج (نسخة تجريبية) | يتم عبر السيناريو وليس تفكير Claude خطوة بخطوة | عندما تكون المهمة كبيرة جداً لدرجة لا تستطيع عدة محادثات تنسيقها، أو عند الحاجة للتحقق المتبادل من النتائج: فرز مستودع كامل، أو ترحيل 500 ملف |
⚠️ تنبيه للميزات التجريبية: واجهة الوكيل (agent view) وتدفقات العمل الديناميكية (workflows) في الجدول أعلاه هي نسخ تجريبية أولية (research preview)، وفرق الوكلاء (agent teams) هي ميزة تجريبية مغلقة افتراضياً — وقد تتغير الواجهة واختصارات لوحة المفاتيح والسلوك لاحقاً. تأكد من الإصدار باستخدام
claude --versionقبل البدء. أما الوكيل الفرعي فهو ميزة مستقرة.
لا تحتاج لحفظ هذا الجدول، تذكر جملة واحدة: "من ينسق" هو الحد الفاصل — تنسيق Claude ومباشرة داخل المحادثة ← وكيل فرعي؛ إرسال المهام ومتابعتها بنفسك ← واجهة الوكيل؛ تولي Claude القيادة وفريق العمل ← فرق الوكلاء; تشغيل جماعي منظم عبر سيناريو ← تدفقات عمل ديناميكية.
وهناك أداتان ليستا "طرق توازي" بحد ذاتهما، بل هما أدوات مساعدة للتوازي، وسيركز هذا الدرس على الأولى:
- Worktrees: تمنح كل محادثة نسخة git مستقلة، لضمان عدم تعديل المحادثات المتوازية لنفس الملف. وهذا هو الحل الحقيقي للفخ المذكور في البداية، وسنشرحه في القسم 03.
/batch: مهارة (skill) تجعل Claude يقسم تعديلاً كبيراً إلى ما بين 5 و 30 وكيلاً فرعياً معزولاً باستخدام worktree، ليرسل كل منها طلب سحب (PR). وهي طريقة مدمجة لـ "الوكيل الفرعي + worktree"، وليست أسلوب تنسيق منفصل.
لقد شرحنا الوكيل الفرعي (الدرس 23) وفرق الوكلاء (الدرس 29) بالتفصيل سابقاً، ولن نكررهما هنا — بل سيركز هذا الدرس على الجوانب التي لم نلمسها بعد: عزل worktree، محادثات الخلفية المتعددة، والتشغيل غير التفاعلي (headless).
💡 خلاصة القول في جملة واحدة: هناك أربعة طرق توازي رئيسية، و "من ينسق" هو الفارق الجوهري؛ وتعتبر worktree و
/batchأدوات مساعدة وليست طرقاً منفصلة؛ ويركز هذا الدرس على عزل worktree ومحادثات الخلفية والتشغيل headless.
03 العزل باستخدام worktree: منح كل محادثة "نسخة خاصة بها"
هذا القسم هو الحل الحقيقي للفخ المذكور في البداية، وهو الجزء الأهم الذي يجب فهمه واستيعابه في هذا الدرس.
أولاً، لنوضح أين يكمن الفخ: فتح محادثتين داخل نفس المجلد يشبه قيام شخصين بالكتابة على نفس الورقة في نفس الوقت، فمن الطبيعي أن يغطي ما يكتبه الأخير على ما كتبه الأول وتحدث الفوضى. وأداة git worktree (شجرة العمل، وهي قدرة مدمجة في git) هي العلاج الجذري لهذه المشكلة.
تشبيه: تصوير نفس الورقة لعدة نسخ، ليعمل كل شخص على نسخته الخاصة. إذا كانت هناك ورقة تصميم أصلية واحدة، ويريد ثلاثة أشخاص وضع ملاحظاتهم عليها، فإن كتابتهم معاً على نفس الورقة سيشوهها بالتأكيد. التصرف الصحيح هو تصوير ثلاث نسخ — ليأخذ كل شخص نسخة ويعدلها بحرية، ثم يتم دمج التعديلات لاحقاً. هذا ما يفعله git worktree بالضبط: يسحب لك عدة مجلدات عمل مستقلة من نفس تاريخ المستودع، لكل منها ملفاتها وفروعها الخاصة، ولكنها تتشارك في سجل الالتزام والمستودع البعيد. والتعديلات التي تجريها إحدى المحادثات في نسختها الخاصة لن تلمس ملفات المحادثة الأخرى أبداً.
توضح الوثائق الرسمية هذه الميزة القيمة بوضوح:
تشغيل كل جلسة لـ Claude Code في worktree خاص بها يعني أن التعديلات في جلسة ما لن تلمس أبداً الملفات في جلسة أخرى، لذا يمكنك جعل Claude يبني ميزة في طرفية أولى بينما يقوم بإصلاح خطأ في طرفية ثانية.
أمر واحد لفتح محادثة معزولة
الاستخدام الأسهل: أضف --worktree (أو الاختصار -w) عند التشغيل، متبوعاً بالاسم. سيقوم Claude بتشغيل مجلد عمل معزول والبدء بالعمل فيه تلقائياً. ويوضع مجلد العمل هذا افتراضياً داخل مجلد المستودع الرئيسي تحت المسار .claude/worktrees/<name>/ وباسم فرع worktree-<name>:
claude --worktree feature-authتريد فتح محادثة مستقلة ثانية؟ افتح طرفية أخرى، وغير الاسم، وشغّل نفس الأمر:
claude --worktree bugfix-123الآن تعمل كل محادثة في نسختها الخاصة، واحدة تبني الميزات والأخرى تصلح الأخطاء، دون أن تلمس ملفات الأخرى أبداً — وزالت مشكلة "التغطية المتبادلة" المذكورة في البداية تماماً. لا تجد اسماً مناسباً؟ تجاوزه وسيقوم Claude بإنتاج اسم تلقائي مثل bright-running-fox:
claude --worktreeويمكنك مطالبته بالدخول إلى worktree مؤقتاً أثناء المحادثة — قل له ببساطة "اعمل في worktree"، وسيستخدم أداة EnterWorktree لإنشائه لك.
قبل تشغيل
--worktreeلأول مرة داخل مجلد ما، يجب عليك تشغيلclaudeبشكل عادي مرة واحدة فيه، للموافقة على صندوق حوار الثقة بمساحة العمل. وإذا لم توافق على الثقة، فسيقوم--worktreeبعرض خطأ ويطلب منك تشغيلclaudeبشكل عادي أولاً — وينطبق هذا على وضع-pأيضاً.
ثلاثة فخاخ يجب على المبتدئين تجنبها
الفخ الأول: يجب إضافة .claude/worktrees/ إلى ملف .gitignore. وإلا فإن محتويات مجلدات العمل هذه ستظهر كملفات "غير متبعة" داخل مجلدك الرئيسي، وهو مظهر مزعج. وتنبه الوثائق الرسمية على هذا الأمر بشكل خاص.
الفخ الثاني: مجلد العمل هو نسخة نظيفة وجديدة، ولا يحتوي على ملف .env الخاص بك. يعتبر مجلد العمل بمثابة عملية سحب جديدة تماماً، والملفات التي لا يتبعها git في المستودع الرئيسي (مثل .env و .env.local) لن تنتقل إليه افتراضياً — والنتيجة هي فشل المحادثة الجديدة بسبب غياب المتغيرات البيئية. والحل هو وضع ملف باسم .worktreeinclude في المجلد الرئيسي للمشروع، لتحديد الملفات المحلية التي تريد نسخها تلقائياً إلى كل مجلد عمل، بنفس طريقة كتابة .gitignore:
.env
.env.local
config/secrets.jsonلقد وقعت في هذا الفخ بنفسي: فتحت محادثة باستخدام -w بحماس لبدء تعديل الواجهة الخلفية، وبدأ Claude بالعمل ولكنه استمر في إظهار خطأ بعدم القدرة على الاتصال بقاعدة البيانات، وظللت أصحح الخطأ لوقت طويل بل وشككت في تعطل قاعدة البيانات — لتتضح لي الحقيقة لاحقاً بأن ملف .env لم يُنسخ لمجلد العمل، ولم يستطع قراءة نص الاتصال على الإطلاق. ومنذ ذلك الوقت، أضع ملف .worktreeinclude في المجلد الرئيسي لكل مشروع كخطوة تلقائية، ولم أقع في هذا الخطأ مجدداً.
الفخ الثالث: تذكر اختيار "الحفظ أو الحذف" عند الخروج. القواعد الرسمية للتنظيف واضحة وعملية:
- إذا لم تعدل شيئاً (لا توجد تعديلات غير ملتزمة، ولا ملفات غير متبعة، ولا التزامات جديدة): سيتم حذف مجلد العمل وفرعه تلقائياً؛ ولكن إذا كانت المحادثة قد سميت مسبقاً (
--name)، فسيقوم Claude بعرض تنبيه لتحديد الحفظ أو الحذف. - إذا عدلت شيئاً: سيقوم Claude بسؤالك "هل تريد الحفظ أم الحذف" — فاختيار الحفظ يبقي على المجلد والفرع لتعود وتكمل العمل لاحقاً، واختيار الحذف يرمي المجلد مع التعديلات غير الملتزمة.
- مجلدات العمل الناتجة عن التشغيل غير التفاعلي (
-p) لا يتم تنظيفها تلقائياً لعدم وجود تنبيه خروج، ويجب حذفها يدوياً باستخدامgit worktree remove.
إذا كنت لا تريد البناء التلقائي لـ Claude، يمكنك القيام به يدوياً
إذا كنت تريد التحكم الكامل في مكان وضع مجلد العمل والفرع المستخدم، يمكنك إنشاؤه بنفسك باستخدام أوامر git (وسنفصل ذلك في الدرس 43 المتعلق بـ git):
# إنشاء مجلد عمل على فرع جديد
git worktree add ../project-feature-a -b feature-a
# الدخول إليه وتشغيل Claude
cd ../project-feature-a && claude
# عرض جميع مجلدات العمل المفتوحة
git worktree list
# حذف مجلد العمل بعد الانتهاء
git worktree remove ../project-feature-aوتنبه الوثائق الرسمية إلى نقطة يسهل نسيانها: كل مجلد عمل جديد هو عملية سحب مستقلة، لذا تذكر إعادة تثبيت الاعتماديات وإعداد البيئات الافتراضية فيه — ولا تتوقع أن يرث المجلد node_modules المثبت في المجلد الرئيسي.
💡 خلاصة القول في جملة واحدة: تمنح worktree كل محادثة نسخة مستقلة من الكود (مثل تصوير ورقة التصميم للتعديل بشكل منفصل)، ويفتح الأمر
claude --worktree <name>محادثة معزولة بفرع مستقل؛ وتذكر الفخاخ الثلاثة — إضافة.claude/worktrees/لـ.gitignore، ونسخ.envعبر.worktreeinclude، واختيار "الحفظ / الحذف" عند الخروج.
04 التوازي متعدد المحادثات: إرسال المهام للخلفية ومراقبة تقدمها من شاشة واحدة
تحل worktree مشكلة "عدم تداخل الملفات"، ولكن تتبقى مشكلة أخرى: إذا فتحت ثلاث أو خمس محادثات، هل يجب فتح ثلاث أو خمس طرفيات للتبديل بينها ومراقبتها واحدة تلو الأخرى؟ هذا أمر متعب. وهنا يأتي دور "واجهة الوكيل (agent view)".
تشبيه: لوحة حركة الرحلات في برج مراقبة المطار. لا يقوم برج المراقبة بتعيين شخص لكل طائرة — بل تظهر حالة جميع الرحلات بوضوح على شاشة كبيرة واحدة: الطائرة التي تسير على المدرج، والتي تنتظر التعليمات، والتي هبطت بالفعل. ويقوم المراقب بإلقاء نظرة سريعة على الشاشة، ولا يتحدث في اللاسلكي إلا مع الطائرة التي تحتاج لقراره. وتوفر لك claude agents شاشة مراقبة كهذه: حيث ترتب جميع محادثات الخلفية في أسطر، وتظهر حالاتها بنظرة سريعة، وتتدخل مع المحادثة التي تحتاج إليك فقط.
⚠️ نسخة تجريبية أولية: واجهة الوكيل (agent view) هي ميزة تجريبية أولية بحسب التصنيف الرسمي، وتتطلب إصداراً حديثاً من Claude Code، وقد تتغير الواجهة واختصارات لوحة المفاتيح لاحقاً. تأكد من الإصدار باستخدام
claude --version.
إرسال المهام إلى الخلفية
ميزة محادثات الخلفية هي: أنها لا ترتبط بالطرفية الخاصة بك — فإغلاق الشاشة، أو إغلاق shell، أو فتح محادثة تفاعلية أخرى لن يمنعها من الاستمرار في العمل. وهناك عدة طرق لإرسالها.
الأولى: الإرسال مباشرة من shell بإضافة المعامل --bg:
claude --bg "调查一下 SettingsChangeDetector 这个不稳定的测试为啥老挂"بعد الإرسال، سيقوم Claude بطباعة المعرف القصير (ID) لهذه المحادثة والأوامر المتاحة لإدارتها، وتكون بالشكل التالي تقريباً:
backgrounded · 7c5dcf5d
claude agents list sessions
claude attach 7c5dcf5d open in this terminal
claude logs 7c5dcf5d show recent output
claude stop 7c5dcf5d stop this sessionالثانية: الإرسال من داخل المحادثة الحالية: اكتب /bg (اختصار لـ /background) لنقل المحادثة الحالية للخلفية.
إدارتها باستخدام شاشة المراقبة claude agents
افتح لوحة التحكم المركزية:
claude agentsستملأ الشاشة الطرفية بالكامل، وتعرض جميع محادثات الخلفية مرتبة ومجمعة بحسب حالتها — "تحتاج لمدخلات" و "تعمل حالياً" و "مكتملة". وتظهر أيقونة في بداية كل سطر، ويعبر لونها وحركتها عن حالة المحادثة:
| الحالة | الأيقونة | المعنى |
|---|---|---|
| تعمل حالياً | وميض متحرك | تقوم بتشغيل أدوات أو إنتاج إجابة حالياً |
| تحتاج لمدخلات | أصفر | تنتظر إجابتك أو موافقتك على الأذونات |
| مكتملة | أخضر | نجحت في إنهاء المهمة المطلوبة |
| فشلت | أحمر | انتهت بسبب حدوث خطأ |
تتكون العمليات الأساسية في شاشة المراقبة من ثلاثة عناصر، ويكفي المبتدئين تذكر هذه العناصر الثلاثة:
Space(نظرة سريعة): حدد سطراً واضغط مسافة لفتح نافذة صغيرة تعرض المخرجات الأخيرة أو المشكلة التي تقف عندها المحادثة — وفي معظم الحالات لن تحتاج للدخول للمحادثة الكاملة، بل تكفي نظرة سريعة.- الرد: اكتب ردك مباشرة داخل نافذة النظرة السريعة واضغط
Enterلإرساله، دون الحاجة لمغادرة شاشة المراقبة. Enter/→(ضم المحادثة): إذا أردت الدخول للمحادثة والتحدث فيها بشكل كامل، اضغطEnterلـ "ضمها"، لتتحول لمحادثة تفاعلية كاملة؛ واضغط←في صندوق المدخلات الفارغ للعودة لشاشة المراقبة مجدداً.
وهنا تفصيل خفي ومهم جداً يربط هذا القسم بالقسم السابق المتعلق بـ worktree: قبل أن تقوم محادثة الخلفية بتعديل أي ملف، سيقوم Claude بنقلها تلقائياً إلى مجلد عمل معزول تحت .claude/worktrees/. وهذا يعني — أن استخدام واجهة الوكيل لإرسال المهام بالتوازي يضمن لك عزل الملفات تلقائياً دون الحاجة للقيام به يدوياً. وتؤكد الوثائق الرسمية أن واجهة الوكيل تنشئ مجلدات عمل مستقلة تلقائياً عند توزيع المهام.
لنتخيل تركيبة توازي شائعة: إرسال ثلاث مهام للخلفية معاً — واحدة لإصلاح اختبار غير مستقر، وواحدة لمراجعة طلب سحب (PR)، وواحدة لكتابة توثيق. وتستمر أنت بالقيام بأعمالك، وتلقي نظرة على شاشة claude agents بين الحين والآخر — فالمهمة التي تظهر باللون الأخضر تذهب لاعتمادها، والتي تظهر بالأصفر تذهب لاتخاذ قرار بشأنها. هذا الأسلوب أسهل بكثير من فتح عدة طرفيات والتبديل بينها.
⚠️ حقيقة تؤثر على رصيدك المالي: تستهلك محادثات الخلفية والمحادثات التفاعلية رصيد اشتراكك بنفس الطريقة. وتشغيل عشر محادثات بالتوازي يعني استهلاك الرصيد بسرعة تقارب عشرة أضعاف تشغيل محادثة واحدة. فلا تفتح عدداً كبيراً من المهام دون تفكير لمجرد سهولة تشغيلها في الخلفية.
💡 خلاصة القول في جملة واحدة: يرسل
--bgالمهمة للخلفية، وينقل/bgالمحادثة الحالية للخلفية، وتعطيكclaude agentsشاشة مراقبة (مثل لوحة الرحلات في المطار) — وتستخدمSpaceللنظرة السريعة والرد المباشر، وEnterللضم؛ ويتم عزل الملفات تلقائياً باستخدام worktree في محادثات الخلفية، وتذكر أن زيادة التوازي تزيد من استهلاك الرصيد.
05 التشغيل headless جماعياً: كتابة المهام في سيناريوهات لتشغيلها دون مراقبة
الوسيلتان السابقتان مخصصتان لـ "جلوسك أمام الطرفية للمراقبة". ولكن هناك فئة من المهام لا تريد مراقبتها إطلاقاً — وهي تشغيل نفس العملية على مجموعة من الملفات بشكل متكرر؛ أو إدخال Claude داخل عمليات البناء المستمر (CI) أو داخل السيناريوهات، ليتم استدعاؤه تلقائياً كأداة سطر أوامر. وهذا هو وضع التشغيل غير التفاعلي (headless، أي تشغيل المهمة دون واجهة تفاعلية والخروج فور الانتهاء).
تشبيه: كتابة الطلب في ورقة ووضعها في آلة الخدمة الذاتية لتخرج النتيجة. لن تجلس أمام آلة البيع الذاتي لتراقب كيفية إخراج السلعة — تضع النقود، تضغط الزر، وتخرج السلعة، دون الحاجة للمراقبة. التشغيل headless هو هذا العمل "دون مراقبة": تكتب التوجيهات والمعاملات كاملة دفعة واحدة، وتلقمها للأمر claude -p، ليقوم بالعمل ويخرج النتيجة لتستخدمها مباشرة.
يتطلب هذا الوضع إضافة معامل أساسي واحد: -p (أو --print). وبإضافته، يقوم claude بالتشغيل لمرة واحدة دون تفاعل ثم يخرج:
claude -p "找出 auth.py 里的 bug 并修掉" --allowedTools "Read,Edit,Bash"ويعتبر المعامل --allowedTools هنا هو الموافقة المسبقة على الأدوات التي يستطيع استخدامها — لعدم وجود شخص يضغط على موافقة أثناء العمل، فيجب عليك إخباره مسبقاً بـ "استخدم هذه الأدوات بحرية ولا تتوقف لتسألني" (راجع الدرسين 20 و 35 لتفاصيل وضع الأذونات).
ثلاثة إضافات تجعله مفيداً حقاً
الإضافة الأولى: تمرير البيانات عبر الأنابيب (pipes). يستطيع وضع headless قراءة المدخلات القياسية (stdin)، لذا يمكنك تمرير البيانات إليه باستخدام الأنابيب كما تفعل مع أي أداة سطر أوامر. كأن تمرر له أخطاء البناء ليقوم بتفسيرها وحفظ النتيجة في ملف:
cat build-error.txt | claude -p "简明扼要说清这个构建错误的根因" > output.txtوعند تتبع أسباب فشل البناء، يمكنك إرسال هذا السطر مباشرة — وهو أسرع بكثير من نسخ الخطأ ولصقه داخل محادثة تفاعلية.
الإضافة الثانية: استخدام --bare لتسريع التشغيل. يقوم claude -p افتراضياً بتحميل نفس السياق الذي تحمله المحادثة التفاعلية (قراءة hooks و skills و plugins و MCP و CLAUDE.md بالكامل)، وهذا يستغرق وقتاً طويلاً عند التشغيل في السيناريوهات، وقد يتأثر بالإعدادات الموجودة في ~/.claude لأجهزة زملائك. وتضيف --bare لتجاوز هذا الكشف التلقائي، مما يسرع التشغيل ويضمن ثبات النتائج عبر الأجهزة المختلفة:
claude --bare -p "总结这个文件" --allowedTools "Read"وتوضح الوثائق الرسمية ذلك صراحة:
يعتبر
--bareهو الوضع الموصى به لاستدعاءات السيناريوهات و SDK، وسيكون القيمة الافتراضية للمعامل-pفي الإصدارات المستقبلية.
الإضافة الثالثة: استخدام --output-format json للحصول على نتائج منظمة. لتسهيل قراءة مخرجات Claude داخل السيناريوهات، يصعب التعامل مع النصوص العادية. وبإضافة --output-format json، يعود المخرج بصيغة JSON تحتوي على بيانات وصفية (النتيجة، معرف الجلسة، و total_cost_usd لتكلفة هذه العملية)، ويمكن استخلاصها بسهولة باستخدام jq:
claude -p "总结这个项目" --output-format json | jq -r '.result'تجميع وضع headless لعملية "جماعية"
استخدام أمر -p منفرد لا يعتبر تشغيلاً جماعياً. التشغيل الجماعي الحقيقي هو إحاطته بحلقة تكرار (loop) في shell — لتشغيل نفس العملية على مجموعة من الملفات. كأن تطلب كتابة وصف في سطر واحد لكل ملف .py داخل مجلد معين:
for f in src/*.py; do
claude --bare -p "用一句话说明 $f 是干什么的" --allowedTools "Read"
doneهذا هو الشكل الأولي لـ "التشغيل الجماعي دون مراقبة": حلقة تكرار، -p، و --bare كتركيبة ثلاثية. وبالطبع، إذا كانت المهمة تشمل عشرات أو مئات الملفات وتريد التحقق المتبادل من النتائج، فمن الأفضل استخدام تدفقات العمل الديناميكية أو /batch المذكورة في القسم 02 — وجوهرها هو إضفاء الطابع الهندسي والمنظم على هذا التشغيل الجماعي.
⚠️ تنبيه لتغير طريقة الاحتساب المالي: توضح الوثائق الرسمية أنه بدءاً من 15 يونيو 2026، سيتم احتساب استهلاك استخدام Agent SDK وأمر
claude -pتحت اشتراكات المستخدمين من رصيد شهري مستقل مخصص لـ Agent SDK، ويتم احتسابه بشكل منفصل عن استهلاك المحادثات التفاعلية. ضع هذا في الحسبان قبل تشغيل سيناريوهات جماعية كبيرة (راجع الدرس 06 لتفاصيل الرسوم).
💡 خلاصة القول في جملة واحدة: يستخدم وضع headless الأمر
claude -pللتشغيل مرة واحدة دون تفاعل ثم الخروج (مثل آلة الخدمة الذاتية دون مراقبة)، مع إقرانه بـ--allowedToolsللموافقة على الأدوات، و--bareللتسريع، و--output-format jsonللحصول على مخرجات منظمة؛ وتعتبر إحاطته بحلقةforفي shell هي الشكل الأولي لـ "التشغيل الجماعي".
06 القسم الأكثر أهمية: متى يجب ألا تستخدم التوازي
لقد شرحنا ثلاث طرق للتوازي، ولكن هذا القسم هو الأهم على الإطلاق — لأن الكثير من المستخدمين يتحمسون للتوازي بمجرد تعلمه ويريدون تقسيم كل شيء، والنتيجة هي زيادة الفوضى وزيادة التكاليف المالية.
لنضع الخط الحاسم أولاً. لكي يستحق الأمر استخدام التوازي، يجب توفر شرطين معاً: أن تكون المهام مستقلة عن بعضها (لا تعتمد مهمة A على نتائج مهمة B)، وألا تتنافس على نفس الملف (أو يتم عزلها باستخدام worktree). وإذا غاب أحد الشرطين، فإن التوازي سيتحول لفخ تحفره لنفسك.
قارن بين الحالات لمعرفة ما يجب توازيه وما يجب تسييره بالتوالي:
| السيناريو | هل نستخدم التوازي؟ | السبب |
|---|---|---|
| ثلاثة أخطاء في وحدات غير مرتبطة نريد إصلاحها | ✅ توازي | المهام مستقلة ولا تتنافس على الملفات، وهي حالة نموذجية للتوازي |
| تشغيل نفس التعديل على 30 ملفاً | ✅ توازي (headless / /batch) | المهام لا تعتمد على بعضها، والتشغيل الآلي هو الأوفر جهداً |
| "إعادة هيكلة الوحدة A أولاً، ثم بناء B بناءً على A الجديدة" | ❌ توالي | تعتمد مهمة B على نتائج A، والتوازي سيجعل B تعمل على نسخة A القديمة |
محادثتان تريدان تعديل ملف package.json معاً | ❌ توالي (أو عزل صارم باستخدام worktree) | تنافس على نفس الملف، وهي نفس الفوضى المذكورة في البداية |
| تعديل بسيط يستغرق خمس دقائق لإنجازه | ❌ توالي | تكلفة التفكير في التقسيم وفتح المحادثات ودمجها أكبر من الوقت المستقطع للتعديل |
| تحتاج المهام لتبادل النتائج الوسيطة باستمرار | ⚠️ بحسب الحالة | تكلفة التواصل عالية، ومن الأفضل إنجازها في محادثة واحدة بالتوالي |
سأهديك ثلاث قواعد عملية نتجت عن تجارب سابقة لتستفيد منها.
الأولى: لا تستخدم التوازي أبداً للمهام التي تملك اعتماديات متتالية. مثل "إعادة هيكلة الوحدة الأساسية أولاً، ثم جعل الوحدات الأخرى تتوافق مع الواجهة الجديدة"، فهذه الخطوة الثانية تنتظر انتهاء الخطوة الأولى — وإذا قمت بالتوازي، فستعمل الخطوة الثانية على الإصدار القديم، لتكتشف لاحقاً وجوب إعادة العمل بالكامل. والقيام بذلك يعني هدر رصيد محادثتين دون فائدة.
الثانية: لا تقم بتقسيم المهام الصغيرة. التعديلات التي تستغرق خمس دقائق لإنجازها، ستستهلك منك وقتاً أطول في "التفكير بكيفية تقسيمها وفتح المجلدات المعزولة ودمجها لاحقاً". عملية التقسيم بحد ذاتها لها تكلفة، وتقسيم المهام الصغيرة خسارة بحتة.
الثالثة: زيادة التوازي تزيد من استهلاك الرصيد المالي. نكرر التنبيه المذكور في القسم 04: تشغيل عشر محادثات بالتوازي يستهلك الرصيد بسرعة تقارب عشرة أضعاف. والأسلوب الآمن هو — إبقاء التوازي اليدوي في حدود ثلاث إلى خمس محادثات كحد أقصى، وإذا تطلب الأمر تشغيلاً جماعياً كبيراً (عشرات أو مئات) فأسنده لأمر /batch أو لتدفقات العمل الديناميكية بدلاً من فتح عدد كبير من المحادثات يدوياً.
ببساطة، التوازي هو سلاح ذو حدين: فاستخدامه في المكان الصحيح يضاعف الكفاءة مرات عديدة؛ واستخدامه في المكان الخاطئ يجعل العمل أبطأ وأكثر تكلفة وفوضى من التوالي. وتحديد "هل نستخدم التوازي أم لا" هو المهارة الأكثر قيمة دائماً.
💡 خلاصة القول في جملة واحدة: قاعدة التوازي الذهبية هي "الاستقلالية + عدم التنافس على الملفات"، وإذا غاب أحد الشرطين فلا تقسم العمل؛ وتجنب التوازي للمهام ذات الاعتماديات المتتالية وللمهام الصغيرة؛ وتذكر أن التوازي يزيد من استهلاك الرصيد، لذا أبقه في حدود 3 إلى 5 محادثات، وأسند التشغيل الكبير لـ
/batch.
07 العمل: تجربة عزل worktree وإرسال المهام للخلفية بنفسك
الكلام بدون تطبيق لا يفيد. سنقوم الآن بتشغيل سلسلة خطوات عملية تعتمد على مستودع git واحد، وإذا لم تكن تملك واحداً فأنشئ مستودعاً للتجربة. الأوامر حقيقية وقابلة للتشغيل، وقد قدمنا النتائج المتوقعة لكل خطوة لتتبعها وتبني ذاكرتك العضلية.
المتطلبات: مستودع git؛ وتتطلب محادثات الخلفية إصداراً حديثاً من Claude Code (واجهة الوكيل هي نسخة تجريبية)، فتأكد من الإصدار عبر
claude --version. لا تتطلب الأوامر أدناه استخدام شبكة خاصة.
الخطوة الأولى: الدخول لمشروع git والموافقة على حوار الثقة أولاً
cd 你的某个git项目
claudeبعد الدخول اسأله سؤالاً بسيطاً (مثل "ما هو هذا المشروع") ثم اخرج. هذه الخطوة تهدف لإعطاء صلاحية الثقة بمساحة العمل — وبدونها، سيعرض أمر --worktree في الخطوة التالية خطأ مباشرة.
الخطوة الثانية: فتح محادثة معزولة باستخدام --worktree
claude --worktree test-parallelالمتوقع: يقوم Claude بإنشاء مجلد عمل معزول تحت المسار .claude/worktrees/test-parallel/ والبدء فيه. وأي تعديل للملفات داخل هذه المحادثة سيقتصر على هذه النسخة فقط، ويظل المجلد الرئيسي دون تغيير. وعند الخروج وإذا كنت قد عدلت شيئاً، سيسألك "هل تريد الحفظ أم الحذف" — وللتدريب اختر الحذف.
الخطوة الثالثة: التأكد من إنشاء مجلد العمل بالفعل (افتح طرفية أخرى، وعد للمجلد الرئيسي للمشروع)
git worktree listالمتوقع: بالإضافة للمجلد الرئيسي للمستودع، يظهر سطر إضافي يشير للمسار .../.claude/worktrees/test-parallel مع فرعه الخاص. ظهور هذا السطر = تم إنشاء النسخة المعزولة بنجاح.
الخطوة الرابعة: إرسال مهمة إلى الخلفية
claude --bg "列出这个项目所有 markdown 文件的标题"المتوقع: تطبع الطرفية سطراً مثل backgrounded · <ID القصير>، يليه بعض أوامر الإدارة مثل claude attach و claude logs و claude stop. رؤية هذه السطور = تم إرسال المهمة للخلفية وتعمل حالياً، وتصبح طرفيتك جاهزة للقيام بأمور أخرى فوراً.
الخطوة الخامسة: فتح شاشة المراقبة لمتابعة المهمة
claude agentsالمتوقع: تمتلئ الطرفية بالكامل بواجهة الوكيل (agent view)، وتظهر المهمة التي أرسلتها للتو كسطر في القائمة مع حالتها (تعمل / اكتملت). حددها واضغط على زر المسافة Space لإلقاء نظرة سريعة على المخرجات، واضغط Esc لإغلاق نافذة النظرة السريعة، واضغط Esc مجدداً للخروج من شاشة المراقبة. رؤية هذه الواجهة المجمعة تعني قدرتك على إدارة عدة محادثات خلفية من شاشة واحدة.
الخطوة السادسة: التنظيف
# إيقاف محادثة الخلفية (استبدل ID القصير بالمعرف المطبوع في الخطوة الرابعة)
claude stop <ID القصير>
# حذف مجلد العمل التجريبي (قم به داخل المجلد الرئيسي للمشروع)
git worktree remove .claude/worktrees/test-parallelالمتوقع: يطبع أمر claude stop تأكيد الإيقاف؛ وعند تشغيل git worktree list بعد حذف مجلد العمل، يختفي السطر الخاص بـ test-parallel. إتمام التنظيف = نجاح تشغيل السلسلة كاملة.
بتشغيل هذه الخطوات الست، تكون قد مررت بالمسار الكامل للتوازي المتمثل في "فتح محادثة معزولة ← التأكد من النسخة ← الإرسال للخلفية ← المراقبة من شاشة واحدة ← التنظيف". وفي المستقبل، ستكون كل عمليات التوازي مبنية على هذا المسار، مع تغيير المهام وزيادة عدد المحادثات.
💡 خلاصة القول في جملة واحدة: يتكون مسار التوازي العملي من ست خطوات — تشغيل
claude(للموافقة على الثقة) ← فتح محادثة معزولة عبر--worktree← التأكد عبرgit worktree list← إرسال مهمة للخلفية عبر--bg← المراقبة عبرclaude agents← التنظيف باستخدامstopوgit worktree remove؛ وتشغيلها لمرة واحدة أفضل من حفظ عشرة أوامر.
08 خلاصة
لقد أخذك هذا الدرس في موضوع "تشغيل عدة نسخ من Claude معاً" من البداية المتمثلة في "لماذا التوازي" وحتى النهاية المتمثلة في "متى يجب تجنب التوازي"، مع توضيح ثلاث وسائل عملية للتشغيل.
لنلخص النقاط الأساسية معاً:
| ما تريد فعله | الأداة المستخدمة | النقاط الرئيسية |
|---|---|---|
| فهم أسباب التوازي | شرطا "الاستقلالية + عدم التنافس" | مثل فتح عدة منافذ دفع في السوبرماركت، بشرط استقلالية كل طابور |
| التعرف على طرق التوازي | أربعة طرق في جدول واحد | "من ينسق" هو الحد الفاصل؛ وتعتبر واجهة الوكيل وتدفقات العمل نسخاً تجريبية، وفرق الوكلاء ميزة تجريبية |
| منع تداخل الملفات في المحادثات | --worktree / git worktree | تمنح كل محادثة نسخة مستقلة من الكود، وتذكر عواقب .gitignore و .worktreeinclude والتنظيف |
| إرسال المهام للخلفية ومراقبتها | --bg + claude agents | لا ترتبط محادثات الخلفية بالطرفية، ويتم عزل الملفات تلقائياً باستخدام worktree؛ وتوفر Space للنظرة السريعة و Enter للضم |
| تشغيل المهام تلقائياً عبر سيناريوهات | claude -p (headless) | تقرن بـ --allowedTools للموافقة المسبقة، و --bare للتسريع، و --output-format json للحصول على JSON |
| تحديد متى تتجنب التوازي | قاعدة "الاستقلالية + عدم التنافس" الصارمة | تجنب التوازي للمهام ذات الاعتماديات المتتالية وللمهام الصغيرة؛ والتوازي يستهلك الرصيد المالي لذا أبقه في حدود 3 إلى 5 محادثات |
يجب أن تكون قادراً الآن على: فهم أسباب التوازي وقاعدته الذهبية المتمثلة في "الاستقلالية وعدم التنافس على الملفات"؛ والتمييز بين الطرق الأربعة المتاحة واختيار المناسب منها؛ واستخدام --worktree لفتح محادثات معزولة لتجنب التداخل الحادث في البداية؛ واستخدام --bg و claude agents لإرسال المهام للخلفية ومراقبتها من شاشة واحدة؛ واستخدام claude -p لتشغيل المهام جماعياً عبر السيناريوهات؛ والأهم من ذلك — التفكير بهدوء عند استلام مهمة لمعرفة "هل تستحق التوازي أم لا" بدلاً من التسرع في تقسيمها.
إذا نظرت للخلف إلى الحركة الغبية المتمثلة في "تعديل نفس المجلد من طرفيتين"، ستجد أن السبب كان غياب العزل وعدم التفكير في الاعتماديات. والآن بعد أن امتلكت مفتاح العزل المتمثل في worktree وقاعدة التقييم الحاسمة، ستتمكن من اختصار الكثير من الخطوات الخاطئة مقارنة بغيرك.
الدرس القادم 42 "المتغيرات البيئية" — واجهنا في هذا الدرس العديد من المتغيرات البيئية: مثل CLAUDE_CODE_SIMPLE الذي يقف خلف --bare، و CLAUDE_CODE_DISABLE_BACKGROUND_TASKS لإيقاف مهام الخلفية، و CLAUDE_CONFIG_DIR لتغيير مجلد الإعدادات... وهي أشبه بـ "مفاتيح تبديل" خفية خلف الكواليس، تغير سلوك Claude Code بهدوء. الدرس القادم سيكشف هذه المفاتيح واحداً تلو الآخر، ويوضح وظيفة كل منها والجدير بالتعديل. فكر في الأمر: نفس الأمر قد يختلف سلوكه بين جهازك وجهاز البناء المستمر (CI) — وغالباً ما يكمن الفارق في هذه المتغيرات البيئية المحددة.