جلسة Gemini CLI واحدة تعني وكيلاً واحداً يعمل في مجلد واحد. وبمجرد أن ترغب في تنفيذ مهمة ثانية في الوقت نفسه، مثل إصلاح خطأ أثناء تشغيل إعادة هيكلة، أو كتابة اختبارات أثناء إضافة ميزة، تفتح طرفية أخرى. ثم ثالثة. وخلال ساعة ستجد نفسك أمام أربع تبويبات وأربعة مجلدات عمل، دون إجابة واضحة على سؤال بسيط: أي وكيل يفعل ماذا، وأي واحد لمس للتو الملف الذي كنت على وشك تعديله.
تشغيل عدة مهام Gemini جنباً إلى جنب ليس صعباً في البداية. الصعب هو إبقاء الأمور مرتبة. كل نسخة سريعة بمفردها؛ لكن التكلفة تكمن في التنسيق، والتنسيق هو الجزء الذي لا تمنحك إياه الطرفية أبداً.
تستعرض هذه المقالة الإعداد اليدوي لوكلاء Gemini CLI المتوازيين، وتذكر نمط الفشل الذي ينتظرك عند كل خطوة، وتوضح أين يتولى لوح المهام القيادة. ذلك اللوح هو Sharkly، منصة متكاملة لإدارة أوامر الوكلاء والتحكم بها. Sharkly ليس بديلاً عن Gemini CLI، بل يضيف طبقة المهام المشتركة وأجهزة الكمبيوتر والسياق والمراجعة حول بيئات التشغيل التي يستخدمها فريقك بالفعل، لتبقى عمليات التشغيل المتوازية قابلة للإسناد والتتبع بدلاً من أن تتناثر بين التبويبات.
ماذا يعني "الوكلاء المتوازيون" مع Gemini CLI
يشغّل Gemini CLI وكيلاً واحداً لكل عملية. يقرأ المجلد الحالي، ويحمّل أي ملف سياق GEMINI.md، وينفّذ طلبك داخل شجرة عمل واحدة. لا يوجد مُوزِّع مدمج يوزّع هدفاً على عدة وكلاء فرعيين ويدمج أعمالهم لك.
لذا فإن "وكلاء Gemini المتوازيين" تعني شيئاً واحداً عملياً: عدة عمليات gemini تعمل في الوقت نفسه، كل منها في بيئة معزولة خاصة بها، وكل منها في مهمتها الخاصة. إن Gemini CLI مفتوح المصدر ومجاني للاستخدام مع حساب Google شخصي، وهذا بالضبط سبب تشغيل الناس لأربع نسخ في وقت واحد. لم تكن العقبة يوماً في تشغيلها، بل في منع أربع عمليات مستقلة من التصادم في المستودع نفسه، وفي معرفة ما أنتجته كل واحدة بعد ساعة.
هذه هي مشكلة التنسيق ذاتها التي تواجهها مع Claude Code أو Codex. بيئة التشغيل تتغير؛ أما الفوضى فلا.
الإعداد اليدوي خطوة بخطوة
إليك أصغر نسخة عاملة من Gemini CLI المتوازي، مع الشيء الذي ينكسر عند كل خطوة.
الخطوة 1: امنح كل وكيل شجرة عمل خاصة به. لا تشغّل وكيلين في المجلد نفسه. استخدم git worktree لكل مهمة حتى تكون كل نسخة منفصلة فعلياً:
git worktree add ../repo-auth feature/auth
git worktree add ../repo-tests chore/tests
git worktree add ../repo-bugfix fix/login-redirect
نمط الفشل إذا تجاهلت ذلك: وكيلان يعدّلان نسخة عمل واحدة يكتب أحدهما فوق الآخر في منتصف التشغيل. يعيد أحدهم تنسيق ملف بينما الآخر في منتصف تعديله، ويتركان الشجرة في حالة لم يقصدها أي منهما. تمنح الـ worktrees كل وكيل فرعاً نظيفاً ومجلداً نظيفاً. نتعمق في هذا في git worktrees لوكلاء البرمجة بالذكاء الاصطناعي.
الخطوة 2: شغّل جلسة Gemini CLI واحدة لكل worktree. افتح طرفية في كل مجلد وابدأ جلسة:
cd ../repo-auth && gemini
لعمليات التشغيل غير المراقَبة، استخدم الوضع غير التفاعلي حتى يأخذ الوكيل طلباً واحداً ثم يخرج:
cd ../repo-tests && gemini -p "Add unit tests for the session module. Run the suite before finishing."
نمط الفشل: تتوقف جلسة تفاعلية عند أول طلب إذن وتنتظر. تعود بعد عشرين دقيقة لتجد وكيلاً لم يفعل شيئاً لأنه كان بحاجة إلى موافقة. حدّد مسبقاً أي عمليات تشغيل تفاعلية وأيها بلا واجهة، وامنح العمليات بلا واجهة طلباً يتضمن خطوة تحقق خاصة به.
الخطوة 3: اعزل السياق لكل مهمة. يمكن لكل worktree أن يحمل ملف GEMINI.md خاصاً به بقواعد تلك المهمة: ما يجب تعديله، وما يجب تركه، وكيفية تشغيل الاختبارات.
نمط الفشل: ملف سياق مشترك واحد لكل الوكلاء يعني أن تعليمة مقصودة لمهمة المصادقة تتسرب إلى مهمة الاختبار. اجعل السياق مقتصراً على الشجرة التي ينتمي إليها.
الخطوة 4: راقب الحصة. كل نسخة عاملة تستهلك من حدود الحساب نفسه. أربعة وكلاء يستهلكون إعادة هيكلة كبيرة يصلون إلى حدود المعدل أسرع من وكيل واحد، والوكيل المُقيَّد يفشل بصمت في تبويب لا تنظر إليه.
نمط الفشل: تتوقف عملية تشغيل بسبب خطأ في الحصة ولا تلاحظ ذلك حتى تتفقد ذلك التبويب. لا توجد واجهة مشتركة تخبرك بأن وكيلاً توقف. وإذا كنت توائم المهام الأثقل مع النموذج المناسب، فإن أي نموذج لأي مهمة برمجية يغطي هذه المقايضة.
مع ثلاث أو أربع مهام، ينجح هذا. فروع حقيقية، وعزل حقيقي، وتوازٍ حقيقي، دون أدوات إضافية.
أين يتوقف الإعداد اليدوي عن التوسّع
لا ينكسر الإعداد اليدوي في التنفيذ بل في كل ما يحيط به. راقب ما يحدث مع تصاعد عدد المهام.
تفقد الخريطة. مع أربع طرفيات يمكنك الاحتفاظ بها في ذهنك. أما عند ثمانٍ، عبر مستودعين، فلا تستطيع. أي تبويب هو وكيل المصادقة؟ هل انتهى تشغيل الاختبارات أم مات بسبب خطأ في الحصة؟ إن مراقبة وكلاء البرمجة الذين يعملون بالتوازي مهمة لم تُبنَ الطرفية يوماً للقيام بها.
تتناثر النتائج. يترك كل وكيل عمله كفرق (diff) على فرع وجدار من النصوص المتراكمة في تبويب ستغلقه. لا يوجد سجل مشترك لما غيّرته كل عملية، ولماذا، أو ما إذا نجحت في اختباراتها. وعندما يسأل زميل عن ما فعله إصلاح تسجيل الدخول، تكون الإجابة في طرفية لم تعد موجودة.
المراجعة بلا موطن. ينتج الوكلاء المتوازيون فروقاً متوازية، وكل واحد منها لا يزال بحاجة إلى إنسان لقبوله. قراءة أربعة فروع دون ملخص، ودون نتائج تحقق، ودون سياق أبطأ مما كان عليه الوكلاء. السرعة التي كسبتها في التنفيذ تستردّها في المراجعة.
إليك زوج القرار الصادق. إذا كنت تشغّل ثلاث أو أربع مهام Gemini من حين لآخر، فابقَ على إعداد الـ worktree أعلاه؛ فهو بسيط ويعمل، ولوح المهام سيكون عبئاً لا تحتاجه. والجأ إلى لوح المهام عندما تصبح العمليات المتوازية أمراً معتاداً: عدة وكلاء، وأكثر من مستودع، وأكثر من شخص يحتاج إلى رؤية التقدم، ومراجعة يجب أن تكون قابلة للتتبع لا معتمدة على الذاكرة. إن مقارنة الأدوات التي تدير الوكلاء المتوازيين تستحق العناء عند هذه النقطة.
ما يضيفه لوح المهام
يغيّر لوح المهام وحدة العمل من "تبويب طرفية" إلى "مهمة". هذا التحوّل الواحد هو ما ينقص الإعداد اليدوي.
مع Sharkly، تُسند مهمة إلى وكيل مدعوم بـ Gemini CLI. يتولى الوكيل المهمة، ويعمل في worktree معزول، وتعود عمليات التنفيذ والعوائق والنتائج والنقاش اللاحق إلى الجدول الزمني للمهمة بدلاً من أن تختفي في طرفيات خاصة. شغّل عدة مهام في وقت واحد وكل واحدة منها صف يمكنك رؤيته، لا تبويب عليك البحث عنه. لا يزال Gemini CLI يقوم بالبرمجة؛ أما Sharkly فيدير الإسناد وأجهزة الكمبيوتر المتصلة والسياق والمراجعة عبر كل عملية تشغيل.
يبقى تقسيم العمل واضحاً. يبحث الوكلاء وينفّذون ويختبرون ويقدّمون تقارير. أما البشر فيحدّدون الاتجاه، ويمنحون الصلاحية، ويقبلون النتيجة. تتوقف الأتمتة حيث يلزم حكم الفريق، وتعود كل عملية تشغيل بملخص تغييرات ونتائج تحقق خاصة بها، بحيث يقتصر قبول الفرق أو رفضه على نظرة سريعة بدلاً من حفر أثري. يبقى السياق والتقدم والعوائق والنتائج ومراجعة البشر ظاهرة من الطلب حتى الإصدار.
تحتفظ بما لديك بالفعل. لا يطلب منك Sharkly مغادرة Gemini CLI، أو الالتزام ببيئة تشغيل واحدة. ولأنه محايد تجاه المزوّدين، يشغّل لوح المهام نفسه وكلاء Claude Code وCodex إلى جانب وكلاء Gemini لديك، فتصمد سير عملك أياً كان أفضل وكيل قادم. هذا الحياد هو المقصد: أنت تدير وكلاءك في مكان واحد، بدلاً من تبديل الأنظمة البيئية كلما صدر نظام جديد.
قائمة التحقق التي يمكنك تنفيذها اليوم
نفّذ هذا قبل دفعتك التالية من مهام Gemini المتوازية:
- [ ] worktree واحد من git لكل مهمة؛ لا وكيلين في نسخة عمل واحدة أبداً.
- [ ] ملف
GEMINI.mdمخصّص لكل مهمة، وليس ملفاً مشتركاً واحداً بينها جميعاً. - [ ] العمليات بلا واجهة تستخدم
gemini -pمع خطوة تحقق مدمجة حتى لا تتوقف عند طلب. - [ ] سقف معروف لعدد النسخ المتزامنة حتى لا تخنق الحصة المشتركة عملية تشغيل لا تراها.
- [ ] مكان واحد يجيب عن سؤال "أي وكيل على أي مهمة، وما الذي انتهى" دون فتح كل تبويب.
- [ ] كل عملية مكتملة تترك ملخص تغييرات ونتائج اختبار يمكن لإنسان مراجعتها، لا مجرد فرق على فرع.
الأربعة الأولى يمكنك تنفيذها الليلة عبر الـ worktrees والطرفيات. أما الأخيرتان فهنا ينفد الإعداد اليدوي. إذا كنت تشغّل بالفعل عدة وكلاء Gemini CLI في وقت واحد، يمنحك Sharkly مكاناً واحداً لإسناد مهامهم ومتابعة تقدمهم ومراجعة نتائجهم. يمكنك بناء طبقة التنسيق بنفسك، أو تشغيل وكلاء البرمجة الحاليين لديك عبر Sharkly والانتقال مباشرة إلى الجزء الذي يتوسّع.
