في درس الفروع والـ worktrees، أبقينا عمل الوكيلين على ميزتَي اللعبة في مجلدين منفصلين، وراجعنا تغييراتهما، ثم دمجناهما في الفرع main. هكذا استطعنا العمل على ميزتين في الوقت نفسه دون خلط تعديلاتهما. يشرح هذا الفيديو كيف نفعل ذلك في Claude Code. سنتناول الوكلاء الفرعيين، وتشغيل عدة جلسات جنبًا إلى جنب، وكيف أن وقتكم المتاح للإجابة عن الأسئلة ومراجعة النتائج يحدّ من عدد الوكلاء الذين يفيدكم تشغيلهم.
في هذا المثال شخص واحد فقط يدير العمل: أنتم. أما المشاركون الآخرون فهم وكلاء تشغّلونهم بأنفسكم، أو تطلبون من وكيل آخر تشغيلهم.
الطريقة الأولى تبقى داخل جلسة واحدة. الوكيل الذي تتحدثون إليه هو الوكيل الرئيسي، ويمكنه تشغيل وكلاء آخرين لأجزاء من العمل. يُسمّى هؤلاء وكلاء فرعيين. تعطون المهمة للوكيل الرئيسي، وهو ينسّق عملهم.
الطريقة الثانية أن تفتحوا عدة جلسات بأنفسكم، كلًّا في طرفية، وتشغّلوها جنبًا إلى جنب. كل منها جلسة عادية لها وكيلها الخاص، وتتحدثون إلى كل واحدة منها مباشرة.
هاتان الطريقتان لتشغيل عدة وكلاء تناسبان مهام مختلفة. في نهاية الفيديو، ستتمكنون من الاختيار بين تفويض مهمة، ومتابعتها بأنفسكم في جلسة منفصلة.
هذه جلستكم. الوكيل الذي تتحدثون إليه فيها هو الوكيل الرئيسي. له نافذة السياق الخاصة به، وفيها المحادثة حتى الآن، وعندما يكون لديه سؤال، يتوقف ويسألكم.
عندما يفوّض الوكيل الرئيسي مهمة، يشغّل وكيلًا ثانيًا ويعطيه موجزًا يصف العمل. بالنسبة لوكيل فرعي جديد، يقدّم هذا الموجز الخلفية الخاصة بالمهمة من محادثتكم.
للوكيل الفرعي الجديد نافذة سياق خاصة به. فهو لا يرث محادثتكم السابقة، ولا محتويات الملفات التي قرأها الوكيل الرئيسي. كما يمنحه إعداده تعليمات وأدوات، وقد يحمّل تعليمات المشروع. لذلك يجب أن يتضمّن الموجز القرارات السابقة التي تخصّ هذه المهمة.
يعتمد الوكيل الفرعي العادي على هذا الموجز وعلى المعلومات التي يقرؤها بنفسه. ولا يمكنه استخدام أداة الأسئلة المعتادة ليتوقف ويسألكم. إذا ترك الموجز قرارًا مفتوحًا، فقد يفترض شيئًا من عنده، أو يبلّغ بأنه لم يستطع إنهاء المهمة.
عندما ينتهي، يرسل تقريرًا إلى الوكيل الرئيسي، لا إليكم. يقرأ الوكيل الرئيسي التقرير ويقرّر ما يخبركم به. هذا الوكيل الثاني هو ما نسمّيه وكيلًا فرعيًا. إنه وكيل ثانٍ يشغّله الوكيل الرئيسي لمهمة واحدة مفوَّضة.
تظهر فائدة النافذة المنفصلة حين ترون ما يضعه الوكيل الفرعي فيها. فهي تبدأ بالموجز.
ثم يقرأ ملفات، ويشغّل أوامر، ويواجه أخطاء، ويحاول من جديد. كل ذلك يتراكم في نافذته الخاصة، وعندما ينتهي، قد تكون النافذة ممتلئة إلى حدّ كبير.
يعود التقرير إلى نافذة الوكيل الرئيسي. أما قراءة الملفات والأوامر والأخطاء والمحاولات المتكررة، فتبقى في سياق الوكيل الفرعي المنفصل، ولا تُنسخ إلى المحادثة الرئيسية. وقد يبقى نصّ محادثته متاحًا إذا احتجنا إلى فحص العمل أو استئنافه.
هذا الفصل مفيد لأن نافذة السياق محدودة. قد تحتوي قاعدة كود كبيرة على معلومات أكثر بكثير مما تتّسع له نافذة واحدة. يمكن لكل مهمة فرعية أن تجمع السياق الذي تحتاجه، بينما يحتفظ الوكيل الرئيسي بالاستنتاجات التي يحتاجها لتنسيق العمل. لذلك يساعد الوكلاء الفرعيون في إدارة السياق حتى عندما يعملون على مهمة واحدة في كل مرة. وتشغيل المهام الفرعية المستقلة بالتوازي قد يوفّر الوقت أيضًا.
هناك نقطتا انطلاق يجب التمييز بينهما. يبدأ الوكيل الفرعي الجديد بموجز المهمة وبالتعليمات المعدّة له، دون المحادثة السابقة. وهذا يناسب مهمة مستقلة تحتاج إلى سياق صغير ومركّز.
النوع الآخر يُسمّى fork. يبدأ الـ fork بنسخة من المحادثة كلها حتى الآن. له المحادثة السابقة والأدوات والنموذج نفسها التي لدى الوكيل الرئيسي، لذا يمكنكم أن تعطوه مهمة تعتمد على كل ما نوقش من قبل، دون أن تكتبوا شيئًا من ذلك في موجز. في الإصدار المعروض هنا، يمكنكم تشغيل fork بكتابة /subtask ثم المهمة. ويمكن للوكيل الرئيسي أيضًا تشغيل fork عندما يحتاج العمل إلى المحادثة كاملة.
في الحالتين، تبقى قراءات الـ fork وتجاربه وأخطاؤه خارج نافذة الوكيل الرئيسي، ولا تعود منه إلا النتيجة. إذن، الاختيار يتعلّق بنقطة الانطلاق. المهمة القائمة بذاتها تذهب إلى وكيل فرعي جديد. والمهمة التي تحتاج إلى ما توصّلتم إليه معًا تذهب إلى fork.
إذن، كيف تطلبون عدة وكلاء فرعيين؟ تطلبونهم بكلام عادي. هذا prompt لموقع ويب نبنيه. رجاءً شغّل أربعة وكلاء فرعيين، واحدًا لكل تصميم لصفحة الهبوط: بسيط، جريء، داكن، ومرح. شغّلهم بالتوازي، كلًّا في فرعه الخاص وفي worktree خاص به، وأبلغني عندما ينتهي الأربعة.
يشغّل الوكيل الرئيسي الوكلاء الفرعيين الأربعة، ويكتب موجزًا لكل تصميم. يمكنكم أن تطلبوا ذلك بلغة عادية، ثم تحقّقوا من أن المهام الأربع والـ worktrees المنفصلة تطابق طلبكم.
لنرَ ما الذي يُطلقه هذا الـ prompt الواحد. طلب أربعة تصاميم بالتوازي، لكل منها وكيل فرعي، كلٌّ في فرعه الخاص وفي worktree خاص به، دون المساس بالفرع main.
يشغّل الوكيل الرئيسي أربعة وكلاء فرعيين، ويحصل كل منهم على موجز يصف تصميمه.
يعمل كل وكيل فرعي في فرعه الخاص وفي worktree خاص به. اطلبوا من الوكيل الرئيسي تجهيز هذه المجلدات قبل أن يبدأ الوكلاء الفرعيون التعديل. هذا هو الفصل نفسه الذي استخدمناه مع ميزتَي اللعبة في درس الفروع والـ worktrees. لدينا هنا أربع صفحات هبوط بديلة، لذا يمكننا مقارنتها واختيار ما نحتفظ به. ولا حاجة إلى دمج البدائل الأربعة كلها.
التعليمات هي إبقاء الفرع main دون تغيير، وانتظار مراجعتكم قبل الدمج. راجعوا النتائج الأربع، واختاروا العمل الذي تحتفظون به. أعطوا كل وكيل فرعي موجزًا كاملًا كي يعمل دون الحاجة إلى محادثة. إذا تركتم القرار نفسه مفتوحًا، فقد يتخذ الوكلاء الأربعة أربعة قرارات مختلفة.
أثناء عمل الوكلاء الفرعيين، يمكنكم رؤيتهم في مكانين. الأول هو نصّ المحادثة. يظهر فيه صفّ اسمه Agent والمهمة بين قوسين، وتحته سطر تقدّم يبيّن عدد الأدوات التي استخدمها وعدد الـ tokens التي استهلكها.
الثاني لوحة تظهر تحت سطر الإدخال أثناء عمل الوكلاء الفرعيين. فيها صفّ للوكيل الرئيسي، وصفّ لكل وكيل فرعي، ولكل صفّ حالته. مفتاحا السهم لأعلى ولأسفل ينقلانكم بين الصفوف، وEnter يفتح نصّ محادثة الوكيل الفرعي المحدد، وx يوقفه، وEsc يعيدكم إلى سطر الإدخال.
تعرض اللوحة الوكلاء الفرعيين الذين يعملون في هذه الجلسة. الوكيل الفرعي الذي ينتهي بنجاح يختفي من اللوحة، ويصل تقريره إلى الوكيل الرئيسي.
هناك قائمة أخرى، ولا تقتصر على الوكلاء الفرعيين. الأمر /tasks يعرض كل الأعمال التي تشغّلها الجلسة في الخلفية. ويشمل ذلك الوكلاء الفرعيين الذين يعملون أو انتهوا للتو، وأوامر الخلفية أيضًا، مثل بناء المشروع أو تشغيل الاختبارات، حين يبدؤه الوكيل ولا ينتظره.
استخدموا /tasks عندما تريدون الاطلاع على العمل الجاري في الخلفية والمرتبط بهذه الجلسة، بما في ذلك أوامرها ووكلاؤها الفرعيون.
لا يزال بإمكانكم تصحيح وكيل فرعي أثناء عمله. افتحوا صفّه بالمفتاح Enter، واقرؤوا نصّ محادثته، واكتبوا رسالة. يستلم الوكيل الفرعي هذه الرسالة، ويمكنه الاستفادة منها وهو يتابع.
وكذلك الوكيل الرئيسي. أثناء عمل الوكيل الفرعي، يستطيع الوكيل الرئيسي مراسلته، وعندما ينتهي الوكيل الفرعي، يتلقى الوكيل الرئيسي إشعارًا ويستلم تقريره. بهذه الطريقة، حين تصحّحون الوكيل الرئيسي، يمكن للتصحيح أن يصل إلى وكيل فرعي في منتصف عمله.
وقد يحتاج الوكيل الفرعي إلى إذن لتنفيذ إجراء. يظهر طلب الإذن هذا في جلستكم الرئيسية مع اسم الوكيل الفرعي. يمكنكم الموافقة على الإجراء أو رفضه. إذا رفضتموه، فقد يجد الوكيل طريقة أخرى، أو يبلّغ بأنه لا يستطيع المتابعة.
الموجز الكامل يتيح للوكيل الفرعي العادي العمل دون أن يسألكم، بينما تتيح الرسائل لكم أو للوكيل الرئيسي تصحيحه أثناء التشغيل. يحتفظ الـ fork بكل أدوات الوكيل الرئيسي، بما فيها أداة الأسئلة التي يفقدها الوكيل الفرعي العادي.
الطريقة الثانية لتشغيل عدة وكلاء أبسط في وصفها. تفتحون أكثر من جلسة. هذه واحدة، في طرفية خاصة بها، تعمل على استمارة التواصل في الموقع.
وهاتان جلستان أخريان، كلٌّ في طرفية خاصة بها، واحدة على صفحة الأسعار، وأخرى على تخطيط المدوّنة. هذه جلسات عادية، تمامًا مثل الجلسة التي تستخدمونها منذ الأسبوع الأول، لكن عددًا منها يعمل في الوقت نفسه.
لكل جلسة طرفيتها ونافذة سياقها ووضع صلاحياتها. إحداها في وضع التخطيط، وأخرى في وضع قبول التعديلات. هذه الجلسات تعمل باستقلال عن بعضها، لذا عليكم إبلاغ كل واحدة بالقرارات التي تؤثّر في مهمتها.
الجلسة التي تتابعونها يمكنها أن تتوقف وتنتظر كلما احتاجت إلى إجابتكم. جلستان من الجلسات الثلاث هنا في حالة انتظار، واحدة عند طلب إذن، وأخرى عند سؤال.
لمساعدتكم على متابعة عدة جلسات، يوفّر Claude Code شاشة اسمها agent view. الضغط على السهم الأيسر في سطر إدخال فارغ ينقل الجلسة الحالية إلى الخلفية ويفتح هذه الشاشة. وتظهر فيها جلسات الطرفيات الأخرى بعد نقلها إلى الخلفية. كل صفّ جلسة، والجلسات مجمّعة حسب حالتها. تعرض الصفوف الأولى الجلسات التي تنتظر ردّكم، والتي ما زالت تعمل.
الضغط على Enter في صفّ يفتح تلك الجلسة في طرفيتكم، والسهم الأيسر في سطر إدخال فارغ يعيدكم إلى القائمة. أما الضغط على Space فيعرض لمحة عن آخر مُخرَجات الجلسة، ويمكنكم كتابة ردّ هناك مباشرة دون مغادرة القائمة. ومن الشاشة نفسها يمكنكم أيضًا بدء جلسة جديدة. تكتبون مهمة في الأسفل وتضغطون Enter، فتبدأ جلسة جديدة بالعمل عليها. وقبل أن تعدّل أي شيء، تنتقل إلى worktree خاص بها.
تفقّدوا بانتظام المجموعة التي تنتظر ردّكم. هذه الجلسات توقفت عند سؤال أو طلب إذن، لذا حين تجيبون عنها تستأنف عملها.
إذا عدّلت جلستان المجلد نفسه، فقد تغيّران الملفات نفسها في الوقت نفسه. قد تكتب إحداهما فوق تغيير أجرته الأخرى للتو، أو تتابع العمل على محتويات تغيّرت بالفعل. وقد يصبح الملف المدمَج شيئًا لم يقصده أيّ من الوكيلين.
مع worktree لكل جلسة، يعدّل كل وكيل ملفات العمل الخاصة به في فرعه الخاص. تتشارك الـ worktrees سجلّ المستودع ومراجعه (references)، لكن تعديل الملفات في مجلد عمل لا يغيّر ملفات العمل في المجلد الآخر. وأنتم من يقرّر متى تُدمج تغييراتهم. الـ worktree يفصل التعديلات، لكنه ليس بيئة معزولة لأغراض الأمان.
اطلبوا من الوكيل إعداد الـ worktree الخاص به قبل بدء المهمة. وتحقّقوا من المجلد قبل أن يعدّل، لأن إنشاء worktree لاحقًا لا يفصل التغييرات التي أجراها بالفعل في المجلد المشترك.
الآن، أي المهام تذهب إلى وكيل فرعي، وأيها تحصل على جلسة خاصة بها؟ المهمة ذات الموجز الكامل توزَّع على وكلاء فرعيين. إذا استطعتم وصف تذييل للصفحة فيه العنوان، أو أيقونة الموقع، أو شريط الـ cookies، بوضوح يغني عن أي سؤال، فيمكن لوكيل فرعي بناؤه دونكم.
المهمة التي ستحتاج إلى محادثة تحصل على جلسة تتابعونها. صفحة الأسعار تثير أسئلة يجب حسمها قبل بنائها، ومسار التسجيل يحتاج إلى قرارات أثناء العمل، ونظام الألوان يجب أن يُعرض عليكم ويُعدَّل. هذه تحتاج إلى مشاركتكم، لذا أعطوا كلًّا منها جلسة وابقوا معها.
السؤال ببساطة: هل ستحتاج المهمة إليكم أثناء عملها؟ إن لم تحتج، فوّضوها. وإن احتاجت، فأبقوها حيث يمكنكم الإجابة.
يوضّح هذا المخطط كيف يمكن للأسئلة أن تحدّ من العمل المتوازي. المقاطع الزرقاء تمثّل عمل الوكيل، والمقاطع الكهرمانية تمثّل انتظار إجابتكم. مع جلسة واحدة في هذا المثال، تجيبون بسرعة وتكون فترات الانتظار قصيرة.
مع ثلاث جلسات في المثال، تجيبون عن واحدة بينما تنتظر الأخريان. وتطول فترات انتظارها لأن أسئلتها تنضمّ إلى طابور واحد ينتظر انتباهكم.
مع خمس جلسات في المثال، تقضي الجلستان الأخيرتان معظم وقتهما في الانتظار. الخامسة طرحت سؤالًا مبكرًا، ولم تتلقَّ إجابة بعد. فتح هذه الجلسات الإضافية لم يُضف إلا القليل من العمل المنجَز.
عندما تتوقف جلسة بانتظار إجابتكم أو موافقتكم، ينتظر ذلك العمل حتى تردّوا. إذا احتاجتكم عدة جلسات في الوقت نفسه، فإضافة المزيد قد تطيل الطابور بدل أن تزيد العمل المنجَز. انتباهكم إذن حدّ من حدود التوازي المفيد، إلى جانب سعة الأداة وحدود الاستخدام. جرّبوا أعدادًا مختلفة من الجلسات، واعرفوا كم جلسة تستطيعون الردّ عليها ومراجعتها دون تراكم.
الأمر /cost يعرض معلومات عن استخدام الجلسة. يتضمّن المثال تكلفة تقديرية قدرها 55 سنتًا، ومدّتين. إذا كان الاستخدام مشمولًا في اشتراككم، فالتقدير بأسعار الـ API ليس فاتورة إضافية، لكن الاستخدام الإضافي، إن فعّلتموه، قد تترتّب عليه رسوم. تساعدنا المدّتان على فهم كيف قضت الجلسة وقتها.
مدة API تقيس الوقت المستغرق في طلبات النموذج، بينما تقيس مدة wall الوقت الفعلي المنقضي في الجلسة. وهما هنا 6 دقائق و20 ثانية، و41 دقيقة و10 ثوانٍ. وتُظهر الشاشة أيضًا إضافة 212 سطرًا وحذف 38 سطرًا.
الفرق 34 دقيقة و50 ثانية، أي نحو 35 دقيقة خارج طلبات النموذج. قد يشمل ذلك انتظاركم، لكنه يشمل أيضًا تنفيذ الأدوات وتأخيرات أخرى، لذا فهو ليس مقياسًا مباشرًا لسرعة ردّكم. سجّلوا هذه المدد لكل جلسة من الجلسات المتوازية، وقارنوها بالأسئلة التي بقيت دون إجابة. ومعًا تساعدكم على تقدير عدد الجلسات التي يمكنكم متابعتها.
الوكيل الفرعي مفيد عندما تستطيعون إعطاءه مهمة كاملة ومراجعة تقريره. والجلسة المنفصلة مفيدة عندما تتوقعون محادثة، وتريدون أن تحسموا القرارات حين تظهر. كما يُبقي الوكلاء الفرعيون عملهم التفصيلي خارج سياق الوكيل الرئيسي.
للتعديل المتوازي، أعطوا كل وكيل worktree خاصًا به قبل أن يغيّر الملفات. ثم راقبوا حجم العمل الذي ينتظر إجاباتكم ومراجعتكم، لأن الوكلاء الإضافيين لا يفيدون إلا إذا استطعتم مجاراة تلك القرارات. يمكنكم الآن اختيار طريقة تقسيم العمل: فوّضوا المهام ذات الموجزات الواضحة، وتابعوا المهام التي تحتاج إلى نقاش في جلسات منفصلة، واستخدموا الـ worktrees لإبقاء تعديلاتها منفصلة حتى المراجعة.