تفتح نافذة طرفية (terminal) لـ Claude Code، وأخرى لـ Codex، وربما ثالثة لـ Gemini CLI. كل واحد منها يكتب الشيفرة البرمجية بكفاءة، لكن لا أحد منها يمكنه إخبارك بأي وكيل يعمل على أي مهمة، أو ما الذي اكتمل تنفيذه أثناء وجودك في اجتماع، أو ما الذي فشل في صمت، أو ما التعديلات التي تقبع الآن في فرع برمجي (branch) بانتظار مراجعة بشرية. في هذه الفجوة تحديداً يبرز دور إدارة وكلاء البرمجة، وهذه هي المعضلة التي يفصّلها هذا المقال.
وسرعان ما تتجلى هذه الفجوة؛ إذ يبدو تشغيل أول وكيل في نافذة طرفية ثانية مكسباً خالصاً، ولكن بحلول الوكيل الخامس، تجد نفسك تتنقل باستمرار بين النوافذ لتتذكر ما كان يفعله كل وكيل، وتنظف مساحات العمل (worktrees) يدوياً، وتعاود قراءة فروقات الشيفرة (diffs) التي راجعتها بالفعل. إن أدوات التنفيذ بارعة في إنجاز مهامها، لكنها لم تُصمَّم قط لتنسيق العمل فيما بينها.
صُممت منصة Sharkly لتكون طبقة التنسيق تلك، وهي بيئة العمل التي نعتمد عليها كنموذج تطبيقي في هذا المقال. لا تكتب Sharkly الشيفرة ولا تحل محل الوكلاء الذين تستخدمهم بالفعل، بل تقع في مستوى أعلى منهم: أنت تحتفظ بـ Claude Code وCodex، بينما تتولى Sharkly إدارة المهام، والسياق، والتقدم، والعوائق، والنتائج، والمراجعة البشرية المحيطة بها. يوضح الجزء المتبقي من هذا المقال ما يعنيه مفهوم «الإدارة» من هذا المنظور وكيف تحدد ما إذا كنت بحاجة إليها الآن.
ماذا تعني إدارة وكلاء البرمجة؟
إدارة وكلاء البرمجة (Coding agent management) هي ممارسة تعيين وتتبع وعزل ومراجعة عمل وكلاء البرمجة المتعددين المدعومين بالذكاء الاصطناعي من منصة مركزية مشتركة بدلاً من فتح طرفية مستقلة لكل وكيل. إنها تمثل طبقة علوية، وليست أداة تنافس الوكلاء الذين يعملون تحت مظلتها.
يسهل فهم هذه المنظومة البرمجية عند استعراضها من الأعلى إلى الأسفل:
Models Claude / GPT / Gemini (reason and generate)
Coding agents Claude Code / Codex / Gemini CLI (execute tasks)
Management layer Sharkly (assign, track, isolate, review)
Team you and other developers (set direction, accept results)
لكل صف مهمة محددة؛ فالنموذج يتولى التفكير والاستنتاج، ووكيل البرمجة يحوّل الطلب إلى ملفات معدلة وأوامر منفذة وفروقات برمجية (diff)، بينما تحدد طبقة الإدارة أي وكيل يستلم أي مهمة، وتمنع تعارض تعديلاتهم، وتحتفظ بالسجل المرجعي الذي يراجعه الجميع. أما دورك فيتمثل في تحديد المسار واعتماد النتائج. وعندما يصف الناس الوكلاء بأنهم زملاء عمل وليسوا مجرد أدوات للإكمال التلقائي، فهذا هو الهيكل التنظيمي الذي يقصدونه، وطبقة الإدارة هي الحلقة التي كانت مفقودة في معظم بيئات العمل.
إن وجود هذه الطبقة ككيان منفصل أمر بالغ الأهمية؛ فوكيل البرمجة لا يملك أي دراية بحالة الوكلاء الآخرين. فليس لدى Claude Code أدنى فكرة عما إذا كان Codex يعدل الملف نفسه في مجلد مجاور. وإدارة هذا التنسيق ليست من اختصاص الوكيل، والطلب من وكيل مراقبة بقية الوكلاء لا يحل المشكلة، بل ينقل الفوضى من مكان إلى آخر فحسب.
المشكلة التي تعجز الأدوات الأساسية عن حلها
تأمل بصدق ما يحدث في فترة ما بعد ظهيرة مزدحمة بالعمل مع تشغيل ثلاثة أو أربعة وكلاء في آن واحد: أي وكيل يعمل على ماذا؟ وأيها ينبغي أن يستلم المهمة التالية؟ وما الذي اكتمل وما الذي فشل؟ وما التعديل الذي يتطلب مراجعة بشرية قبل دمجه؟ أضف إلى ذلك التفاصيل التقنية المعقدة في الخلفية: نوافذ طرفية متعددة، ومساحات عمل (worktrees) متفرقة، وفروع ومستودعات برمجية متعددة، واشتراكات مدفوعة تُحسب تكاليفها تباعاً في الخلفية.
لا يُعزى أي من ذلك إلى قصور في Claude Code أو Codex، بل هو ضريبة تشغيل عدة أدوات تنفيذ عالية الكفاءة معاً دون وجود مظلة تديرها. فالعمل حقيقي ويجري بالتوازي، لكنه يظل غير مرئي؛ إذ لا تكتشف أن وكيلاً قد سلك مساراً خاطئاً إلا عندما تنتقل في النهاية إلى نافذته، لا في اللحظة التي وقع فيها الخطأ.
هذا هو التحدي الحقيقي الذي يستحق التسمية: ليس منتجاً منافساً، بل «فوضى الوكلاء». ففي اللحظة التي يبدأ فيها سير عملك وكأنه جدار من النوافذ الطرفية التي تخشى إغلاقها، تكون قد تجاوزت مرحلة تشغيل الوكلاء فرادى. ويواجه معظم المطورين هذه العقبة عند محاولة تشغيل عدة وكلاء من Claude Code معاً أو تشغيل Claude Code وCodex معاً على قاعدة برمجية واحدة، حيث تظهر معضلة الإدارة وتفرض نفسها قبل أن تجني ثمار الإنتاجية المرجوة.
المسؤوليات الأساسية لطبقة الإدارة
إذا جردت هذه الطبقة إلى مهامها الجوهرية، فستجد أربع مهام رئيسية: التعيين، والعزل، والرؤية، والمراجعة. وإتقان هذه المهام هو جوهر ما تعنيه أوركسترا وكلاء الذكاء الاصطناعي وتنسيقهم من الناحية العملية.
التعيين. يتحول العمل هنا إلى «مهمة» (Task)، والمهمة هي الوحدة المستقلة التي تسندها إلى الوكيل، وليست مجرد مطالبة نصية تلصقها في أي نافذة طرفية تفتحها أمامك. تحمل المهمة هدفها الخاص، وسياقها الكامل، ومعايير قبول نتائجها، مما يتيح للوكيل الانطلاق مباشرة من الوضع الراهن للعمل بدلاً من البدء من محادثة فارغة.
العزل. لا بأس بعمل وكيلين على مستودع برمجي واحد حتى يبدأ كلاهما بتعديل الملفات نفسها. والحل يكمن في تخصيص مساحة عمل مستقلة (worktree) لكل مهمة، بحيث يحصل كل وكيل على نسخته الخاصة المعزولة ولا تتعارض تعديلاتهم أثناء التشغيل. يمكنك إعداد ذلك بنفسك باستخدام Git، لكن مهمة طبقة الإدارة هي إنشاء وتتبع وتنظيف تلك مساحات العمل المعزولة تلقائياً لتجنيبك عناء القيام بذلك يدوياً.
الرؤية والشفافية. تعود تفاصيل التنفيذ والعوائق والنتائج والنقاشات اللاحقة كلها لتصب في المخطط الزمني للمهمة، بدلاً من أن تتلاشى في طرفية قمت بإغلاقها لاحقاً. مكان واحد يقدم إجابة واضحة على سؤال: «ما الذي يفعله كل وكيل في هذه اللحظة بالضبط؟»، وهو تحديداً ما ينبغي أن تعرضه لك لوحة تحكم وكلاء الذكاء الاصطناعي.
المراجعة. يبحث الوكلاء وينفذون ويختبرون ويرفعون التقارير، بينما يحدد البشر التوجهات ويمنحون الصلاحيات ويعتمدون النتائج. وأهم حد فاصل تضعه طبقة الإدارة هو أن الأتمتة تتوقف عند النقطة التي تتطلب حكماً بشرياً من الفريق؛ إذ يمكن للوكيل إعداد التعديلات وتشغيل الاختبارات وإرفاق الأدلة الداعمة، ولكن القرار النهائي بالدمج يعود للإنسان دائماً. فهذه المحطة الرقابية القائمة على التدخل البشري في المسار (human-in-the-loop) تُعد ميزة محورية وليست عائقاً يبطئ العمل.
إليك المعادلة الصريحة لاتخاذ القرار: إذا كنت تستخدم وكيلاً برمجياً واحداً، وتعمل عبر طرفية واحدة، وتنهي كل مهمة قبل الانتقال إلى التالية، فأنت لست بحاجة إلى طبقة إدارة، وإضافتها ستكون عبئاً لا داعي له. لكن المعادلة تنقلب تماماً بمجرد تشغيل وكيلين أو أكثر عبر عدة مهام أو مساحات عمل أو مستودعات، أو عندما يحتاج مطور آخر للاطلاع على ما أنجزه الوكلاء؛ فهنا تحديداً تبدأ طبقة الإدارة في إثبات جدواها الفعلية وتوفير وقتك وجهدك.
إدارة وكلاء البرمجة باستخدام Sharkly
بما أن Sharkly تمثل طبقة الإدارة في نموذجنا التطبيقي، فإليك الصورة العملية لكيفية عملها.
تبدأ بربط جهاز كمبيوتر (Computer)، وهو أي جهاز (سواء كان حاسوبك المحمول أو خادماً أو كليهما) يمكن لجلسة الوكيل أن تعمل عليه. ثم تعرّف الوكيل (Agent)، وهو إعداد مسبق قابل لإعادة الاستخدام يحدد كيفية التعامل مع العمل، وليس نموذجاً جديداً للذكاء الاصطناعي. كما تحتفظ باشتراكاتك الخاصة كما هي؛ إذ يظل استخدام النماذج مرتبطاً بحسابات Claude Code أو Codex أو Gemini التي تدفع اشتراكاتها بالفعل. دور Sharkly يقتصر على التنسيق والإدارة، ولا تقوم بإعادة بيع خدمات تشغيل النماذج (inference).
بعد ذلك، تقوم بتعيين المهمة (Task). فلنفرض مثلاً أن المهمة SH-312 هي «إصلاح اختبار صفحة الدفع المتقلب (flaky test) وزيادة نسبة التغطية الاختبارية». تسند هذه المهمة إلى وكيل مدعوم بـ Claude Code، أو تقسم هدفاً أكبر على فريق وكلاء (Crew)، حيث يتولى وكيل قيادي فهم نطاق العمل وجمع نتائج الوكلاء الآخرين في مهمة واحدة. وتعمل المهمة في مساحة عمل مستقلة (worktree) على جهاز كمبيوتر متصل. وأثناء التنفيذ، تُسجَّل التحديثات ومراحل التقدم والعوائق وفروقات الشيفرة (diff) مباشرة في المخطط الزمني للمهمة. وعند الانتهاء، يرفق الوكيل ملخص التغييرات ونتائج الاختبارات والقيود المعروفة، لتدخل المهمة مرحلة المراجعة؛ فتطلع عليها، وتطلب تعديلات إن لزم، أو تعتمد الدمج.
لا يتطلب منك سير العمل هذا بأي حال التخلي عن Claude Code أو Codex، بل كل ما تفعله هو توجيه الوكلاء الذين تعتمد عليهم بالفعل عبر مساحة عمل مركزية واحدة، بحيث يكون العمل قابلاً للتعيين والتتبع بدلاً من تشتته عبر نوافذ طرفية خاصة ومنعزلة. وإذا أردت الاطلاع على المشهد الكامل للخيارات المتاحة، فقد قمنا بمقارنة أفضل الأدوات لإدارة وكلاء البرمجة المتوازيين بدلاً من الادعاء بأن أسلوب عمل واحداً يناسب الجميع.
لماذا تتفوق أهمية طبقة الإدارة على هوية الوكيل الفائز؟
إليك هذا التوقع، ولنسمّه صراحة توقعاً: لقب «أفضل وكيل برمجي» سيبقى في تغير مستمر، وربط سير عملك بالوكيل المتصدر حالياً هو رهان محفوف بالمخاطر؛ إذ ستتبادل أدوات مثل Claude Code وCodex وGemini، وكل ما سيُطلق مستقبلاً، الصدارة مهمة تلو الأخرى وربعاً سنوياً تلو الآخر. وبناء منظومة عملك بالكامل حول أداة واحدة منها يعني أنك ستضطر لإعادة بنائها من الصفر في كل مرة تتبدل فيها المراتب.
طبقة الإدارة هي الجزء الوحيد الصامد في وجه هذا التغير المتسارع. فإذا كانت مهامك، وسياق العمل، وعزل التعديلات، وعمليات المراجعة تدار من مستوى أعلى من الوكلاء، فسيكون بإمكانك استبدال الوكيل الذي ينفذ مهمة معينة دون المساس بالطريقة التي يعتمدها فريقك في تعيين المهام ومراجعتها. إن الحياد تجاه مزودي النماذج ليس مجرد خيار تكميلي، بل هو بوليصة تأمين ضد تقلبات سوق يعيد تشكيل نفسه كل بضعة أشهر.
لا ندعي هنا أن Sharkly تكتب شيفرة برمجية أفضل من الوكلاء الذين تديرهم، فهي لا تفعل ذلك إطلاقاً؛ فالوكلاء هم من ينفذون، والطبقة هي التي تنسق. والرهان الحقيقي الذي يستحق اتخاذه اليوم ليس على وكيل بعينه، بل على بيئة وسير العمل التي تحيط بهم جميعاً: حدد المهام التي ترغب في تشغيلها بالتوازي على أية حال، وثبّت طبقة إدارة فعلية فوقها قبل أن تفقد السيطرة على زحام النوافذ الطرفية.
إذا كنت تشغّل بالفعل عدة وكلاء برمجيين، فإن Sharkly تمنحك منصة موحدة لتعيين مهامهم، وعزل بيئات عملهم، ومراجعة نتائجهم. يمكنك بناء معظم هذه المنظومة بنفسك عبر مساحات العمل (worktrees) والانضباط الصارم، أو يمكنك تشغيل وكلائك البرمجيين الحاليين عبر Sharkly وترك عبء التنسيق لتتولاه هذه الطبقة نيابة عنك.
