كيف تشغّل Sharkly وكلاءها بالتوازي دون تعارضات الدمج

شغّل وكيلَي برمجة في نسخة العمل نفسها، ولن تمضي ساعة حتى تصطدم بنمط الفشل هذا. أحد الوكيلين يبدّل الفروع بينما الآخر في منتصف تعديله. التغييرات المُجهّزة تختفي داخل commit لا تنتمي إليه. الاختبارات تنجح على ملف أعاد الوكيل الآخر كتابة نصفه. لا شيء من هذا خطأ النموذج؛ فشجرة عمل git حالة مشتركة قابلة للتغيير، وأي عمليتين تعدّلان حالة مشتركة دون تنسيق ستنتهي عاجلًا أو آجلًا إلى إفسادها.

العلاج المعتاد معروف جيدًا: امنح كل وكيل شجرة عمل خاصة به. تتيح أشجار عمل git لمستودع واحد أن يخدم عدة مجلدات مسحوبة في الوقت نفسه، فلا تلمس الفروع المتوازية الملفات ذاتها على القرص. وكثير من الفرق تكتب سكربتات لهذا يدويًا؛ ودليلنا إلى استخدام أشجار عمل git مع وكلاء البرمجة بالذكاء الاصطناعي يشرح ذلك الإعداد اليدوي خطوة بخطوة.

هذا المقال يتناول المسار الآخر: ما يحدث حين تتولّى المنصة — بدلًا من سكربتات shell لديك — أمور العزل وتحضير المجلدات وحدود التزامن والتنظيف.

باختصار

يشغّل Sharkly وكلاء الذكاء الاصطناعي على التوازي دون تعارضات دمج، بأن يمنح كل تشغيل Task مجلدًا معزولًا خاصًا به على Computer متصل. وتتلقّى خدمة محلية على ذلك Computer كل تشغيل مُصطفّ، وتهيّئ مجلد المهمة (وفي العمل المدعوم بمستودع، شجرة عمل git منفصلة لكل تشغيل)، ثم تشغّل Runtime المختار، وتبثّ التقدّم وأحداث التتبّع والنتيجة عائدة إلى Task. وحدود التزامن على Agent وComputer تحدّ عدد التشغيلات المتزامنة، ولا شيء يُدمج من تلقاء نفسه: تعود النتيجة إلى Task، حيث يراجع شخص التغيير ويقرّر خطوة الدمج والإصدار. ولا يتشارك الوكلاء أبدًا شجرة عمل واحدة، لذا لا يمكن أن تطمس Tasks المتوازية تغييرات بعضها.

نمط الفشل الذي بُني Sharkly لمنعه

من المفيد أن نكون دقيقين في تحديد ما يفسد عندما يتشارك الوكلاء نسخة عمل واحدة، لأن كل عَرَض يقابل جزءًا من الحل.

حالة الفرع عامة على مستوى شجرة العمل، لذا حين يسحب الوكيل A فرعه، تتغيّر ملفات الوكيل B تحته في منتصف تشغيله. والفهرس عام أيضًا، فيتشابك git add وgit commit مع أعمال مهام مختلفة. وتتصادم الحالة غير المتتبَّعة: فمخرجات البناء وتثبيتات الاعتماديات من تشغيل ما تلوّث نتائج اختبارات تشغيل آخر. ويتراكم دين التنظيف، لأن كل نسخة مستودع عشوائية تُنشأ للتهرّب من المشكلات الثلاث الأولى تظل على القرص حتى يتذكّر أحدهم وجودها.

المجلد المشترك الواحد لا يستطيع تشغيل أكثر من وكيل واحد بأمان. وإن كنت تتقاسم هذا مع نوافذ tmux وقدر من الانضباط، فمقالنا حول تشغيل عدة وكلاء Claude Code على التوازي يبيّن لماذا يظهر هذا السقف بهذه السرعة.

منظومة التنفيذ: Agent وComputer وRuntime وTask

Sharkly ليس بديلًا عن Claude Code أو Codex أو غيرهما من أدوات التنفيذ. بل يضيف طبقة المهمة المشتركة وComputer والسياق والتحكّم والمراجعة حول الأدوات التي يستعملها فريقك بالفعل. وهذا الموقع في الطبقة هو ما يحدّد شكل التنفيذ المتوازي، لأن مهمة Sharkly هي تنسيق التشغيلات لا كتابة الشيفرة.

أربعة أدوار تتقاسم العمل، ولكل منها وظيفة واحدة فحسب:

• يحدّد Agent كيفية التعامل مع العمل: تعليماته، ومهاراته (Skills)، ومستودعاته، وإعدادات التشغيل. وAgent ليس مضيف التنفيذ.
• يوفّر Computer المضيف والموارد المحلية: جهاز محلي، أو خادم بعيد، أو حاوية، أو مضيف سحابي مدعوم. ويتناول المقال الشقيق حول Computers في Sharkly كيفية ربطها.
• ينفّذ Runtime جلسة الوكيل الفعلية. وهو الأداة المثبّتة على ذلك Computer، مثل Claude Code أو Codex أو Gemini CLI.
• ويظل Task السجل المشترك للفريق: الهدف والحالة والنقاش وأثر التنفيذ والنتيجة.

ويربط بينها جميعًا خدمة محلية صغيرة على Computer. فهي تسجّل Computer، وتكتشف Runtimes المثبّتة، وتتلقّى التشغيلات المُصطفّة، وتهيّئ مجلد المهمة لكل تشغيل، وتشغّل Runtime، وترفع النتائج عائدة. وهي التي تبادر بالاتصال بالخادم، لذا لا يحتاج الإعداد النموذجي إلى منفذ داخل.

هذا الفصل هو ما يجعل التوازي قابلًا للإدارة. ولأن مجلد العمل يُهيّأ لكل تشغيل بواسطة الخدمة المحلية لا باختيار Agent، يستطيع Agentان مُسنَدان إلى Taskين استهداف المستودع نفسه على Computer نفسه دون أن يرى أحدهما ملفات الآخر إطلاقًا. ولمعرفة كيفية تهيئة Agents، راجع Agents في Sharkly.

ماذا يحدث عند بدء تشغيل

أسند Task إلى Agent وأخرجه من Backlog، فيتحقق Sharkly من جاهزية التنفيذ، ويضع تشغيلًا مؤهلًا في قائمة الانتظار، ويرسله إلى Computer المختار. ومن هناك تتولّى الخدمة المحلية المهمة. وقبل أن يبدأ Runtime، قد تحتاج إلى انتظار سعة التزامن، أو تحضير مجلد مؤقت معزول أو انتظار مجلد محدّد متاح، أو جلب المستودعات المُهيّأة، أو إتاحة متغيّرات البيئة المسموح بها، أو بناء استدعاء Runtime.

وعندها فقط يبدأ Runtime. ويمرّ التشغيل بحالات صريحة: Queued، وDispatched، وWaiting for local directory، وRunning، ثم أخيرًا Completed أو Failed أو Canceled. وتظهر هذه الحالات في سجل تنفيذ Task، بحيث يصبح لسؤال «لماذا لم يحدث شيء بعد؟» جواب قابل للفحص بدلًا من التخمين. فالتشغيل المحتجز في Queued بسبب حد تزامن ممتلئ يبدو مختلفًا عن المحتجز في Waiting for local directory، وهذا الفرق يخبرك أي مقبض عليك أن تدوّره.

ولاحظ ما هو غائب: لا يقرّر Agent في أي لحظة أين يعمل. فالوكيل يجلب التعليمات، والبنية التحتية تجلب العزل.

أشجار العمل المعزولة: كيف يعمل نمط Temporary

يدعم Agents نمطي مجلد عمل، والنمط المصمَّم للعمل المتوازي هو Temporary. يحصل كل Task على مجلد معزول، ويمكن للخدمة المحلية في الأعمال المدعومة بمستودع أن تهيّئ شجرة عمل git منفصلة لكل تشغيل انطلاقًا من بيانات المستودع المخزّنة لديها.

هذه الجملة الواحدة تحمل قصة منع التعارضات بأكملها. فشجرة العمل تمنح كل تشغيل مجلده المسحوب الخاص وحالة فرعه الخاصة، مع مشاركة كائنات المستودع الأساسية. وبذلك تختفي أنماط الفشل الأربعة بحكم التصميم: لا مؤشر فرع مشترك، ولا فهرس مشترك، ولا مخرجات بناء مشتركة، ومجلدات تستطيع المنصة تنظيفها لاحقًا. ولأن أشجار العمل تأتي من بيانات مخزّنة لا من استنساخ جديد، تبقى كلفة البدء معقولة، وإن كان التشغيل قد يحتاج مع ذلك إلى اتصال شبكي لتحديث المستودع.

والوثائق صريحة في متى تستخدم هذا: يُوصى بنمط Temporary للتغييرات البرمجية المتوازية، ولأي حالة قد تعدّل فيها عدة Tasks الشيفرة نفسها في وقت واحد.

وثمة حدّ يستحق الذكر بوضوح: العزل يمنع تصادم أشجار العمل، لا التعارضات الدلالية. فإذا أعاد Taskان كتابة الدالة نفسها، فسيُكمل التشغيلان بنظافة داخل شجري عملهما، ومع ذلك يبقى على شخص أن يوفّق بين التداخل عند المراجعة. والحل لذلك هو ضبط نطاق Tasks بحيث لا تستهدف الشيفرة نفسها في اليوم نفسه: قرار تخطيطي لا قرار بنية تحتية.

حين يكون العزل خيارًا خاطئًا: نمط Specified

النمط الثاني موجود لأن مجلدًا جديدًا لكل تشغيل ليس مجانيًا. في نمط Specified يعمل Agent داخل مجلد محلي مطلق واحد مُهيّأ من مجموعته، مع إعادة استخدام المستودع والاعتماديات والذاكرات المؤقتة الموجودة فيه أصلًا. وهو متاح على Computers المحلية فقط.

وللمقايضة نتيجة صلبة: المجلد المحدّد يخدم تشغيلًا واحدًا في المرة، وعندما تكون كل المجلدات المُهيّأة مشغولة، ينتظر التشغيل التالي. وAgent يحتاج إلى تشغيل عدة Tasks في وقت واحد بنمط Specified يجب أن يملك عدة مجلدات في مجموعته.

العزل يشتري الأمان بثمن التحضير، وإعادة الاستخدام تشتري السرعة بثمن التسلسل. ويجعلك Sharkly تختار بوضوح لكل Agent، وهذا أفضل من أن تكتشف المقايضة داخل شجرة عمل مُفسَدة.

حدود التزامن: توازٍ، لكن بحدود

التوازي غير المحدود نمط فشل بحد ذاته. فكل تشغيل متزامن يستهلك المعالج والذاكرة والقرص وسعة مزوّد النموذج وعرض نطاق المستودع؛ وثمانية وكلاء يتنازعون على حاسوب محمول واحد ينتجون نتائج أسوأ من ثلاثة يعملون بارتياح.

ويحدّ Sharkly التزامن على مستويين. فللـ Computer حدّ لتزامن المهام بصفته المضيف، ولكل Agent حدّ أقصى لعدد Tasks العاملة على التوازي إضافة إلى مهلة لكل Task. والإعدادات الافتراضية متحفّظة: في Temporary يحصل Agent على 50 بالمئة من حد Computer؛ وفي Specified يطابق عدد المجلدات المُهيّأة. وإذا رفعت الحد فوق عدد المجلدات، ينبّهك المنتج إلى احتمال تصادم الكتابات بين المهام. وهذا التحذير هو أطروحة هذا المقال مضغوطة في نافذة حوار واحدة.

وإرشاد الوثائق بشأن رفع الحدود هو النوع الرصين: لا ترفع التزامن إلا بعد أن يتعامل Computer وRuntime الحاليان مع عبء العمل القائم بموثوقية.

بثّ التقدّم والمراجعة قبل الدمج

سيكون العزل عبئًا لو كان يعني أيضًا الخفاء. فخمسة وكلاء في خمسة مجلدات مخفية هو بالضبط كيف تختفي الأعمال داخل طرفيات خاصة. لذا كل ما ينتجه التشغيل يعود إلى السجل المشترك.

وبينما يكون التشغيل نشطًا، يعرض Task حالة تنفيذه. ويحمل النشاط التعليقات وتغييرات المهمة في خط زمني؛ ويسجّل سجل التنفيذ وقت بدء التشغيل وانتهائه، واستدعاءات الأدوات وأحداث Runtime، ومصدر التشغيل، وأي تفاصيل فشل؛ ويُحفظ تقرير Agent كتعليق مرتبط بأثر تنفيذه. ويبقى السياق والتقدّم والعوائق والنتائج ظاهرة من الطلب إلى الإصدار، حتى وإن جرت تعديلات الملفات داخل مجلد لم يفتحه بشر قط.

ثم تأتي البوابة. فلا شيء هنا يُدمج من تلقاء نفسه. يبحث الوكلاء وينفّذون ويختبرون ويرفعون التقارير. أما البشر فيحدّدون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. وعند اكتمال التشغيل، يستطيع Agent أن يترك Task في انتظار مراجعة بشرية، وهو ما يظهر في صندوق الوارد (Inbox) لدى الشخص المسؤول. أشجار العمل المعزولة تجعل التنفيذ المتوازي آمنًا، وبوابة المراجعة تجعله موثوقًا.

وهناك قطعة أخيرة تُكمل الدائرة: التنظيف. فتشغيلات الوكيل تترك مجلدات عمل ومخرجات على Computer، والتنظيف القابل للتهيئة يستعيد التشغيلات المنتهية بعد نافذة احتفاظ، مع حدّ أدنى للمساحة الحرة كخط دفاع أخير. ولا يُمسّ أبدًا بالعمل الجاري أو المُصطفّ، ولا بالتشغيلات المثبّتة، ولا بالتشغيلات الفاشلة التي ما زالت تحتاج تحرّيًا. وهذه هي المهمة الروتينية التي تنساها الإعدادات اليدوية بانتظام حتى يمتلئ القرص.

ما يؤتمته Sharkly مقابل الإعداد اليدوي

إن كنت قد قرأت دليل أشجار العمل اليدوي، فالمقابلة مباشرة. فأمر git worktree add الذي تسكربته لكل وكيل يصبح خدمة محلية تهيّئ مجلدًا معزولًا لكل تشغيل. وحكم «كم وكيلًا هو أكثر من اللازم» يصبح حدود تزامن صريحة مع تحذيرات عند إعداد غير آمن. والأمر git worktree prune الذي تنساه يصبح تنظيفًا قائمًا على الاحتفاظ. وأما الجزء الذي لا يمنحك أي سكربت إياه — سجل مشترك يوضّح أي تشغيل فعل ماذا وهل قبِله أحد — فهو Task نفسه.

وينطبق هنا أيضًا زوج القرار الصادق. فمطوّر فردي يشغّل وكيلين على جهاز واحد قد لا يحتاج منصة؛ فسكربت أشجار العمل والانضباط قد يكفيان إلى حد بعيد. والجأ إلى Sharkly عندما تصبح كلفة التنسيق أكبر من كلفة الكتابة: عدة أشخاص يوزّعون العمل، وعدة Computers، وتشغيلات تحتاج إلى اصطفاف ومراجعة. وستحتفظ في الحالتين بـ Runtimes التي لديك بالفعل؛ ويستمر استخدام النماذج عبر الاشتراكات أو مفاتيح API المُهيّأة في تلك الأدوات.

البداية صغيرة عن قصد. اربط Computer واحدًا، وأنشئ Agent واحدًا بنمط Temporary، وأسند إليه Task واحدًا منخفض المخاطر. ودليل البدء يشرح أول حلقة في نحو عشر دقائق، ووثائق Sharkly تغطي كل مفهوم بعمق، وما هو Sharkly يستكمل صورة المنصة المحيطة بالتنفيذ.

الأسئلة الشائعة

كيف يمنع Sharkly تعارضات الدمج بين الوكلاء المتوازين؟

يحصل كل تشغيل Task على مجلد معزول خاص به على Computer، ويمكن للتشغيلات المدعومة بمستودع أن تحصل كل واحدة على شجرة عمل git منفصلة تهيّئها الخدمة المحلية. ولا يتشارك الوكلاء أبدًا نسخة عمل أو فهرسًا أو ملفات غير متتبَّعة، لذا لا يمكن للتشغيلات المتزامنة أن تكتب فوق عمل بعضها الجاري. أما التداخلات التي تغيّر فيها Tasks عن قصد الشيفرة نفسها، فيبقى على شخص التوفيق بينها وقت المراجعة.

هل أحتاج إلى إعداد أشجار عمل git بنفسي لاستخدام Sharkly؟

لا. في نمط Temporary تهيّئ الخدمة المحلية مجلد المهمة لكل تشغيل، بما في ذلك أشجار العمل الخاصة بالأعمال المدعومة بمستودع. وتهيّئ النمط على Agent مرة واحدة؛ ولا وجود لأوامر worktree لكل تشغيل تكتب لها سكربتات. ولفهم الآلية الأساسية، راجع وثائق git worktree.

كم وكيلًا يمكن أن يعمل على التوازي على Computer واحد؟

لـ Computer حدّه الخاص لتزامن المهام، ولكل Agent حدّ أقصى لعدد Tasks العاملة على التوازي. وبشكل افتراضي يحصل Agent في نمط Temporary على 50 بالمئة من حد Computer، وفي نمط Specified على خانة واحدة لكل مجلد مُهيّأ. والتشغيلات التي تتجاوز الحد تنتظر في قائمة الانتظار.

هل يدمج Sharkly تغييرات الوكيل تلقائيًا؟

لا. تعود نتيجة التشغيل وأدلته وأثره إلى Task، ويراجع شخص ملخّص التغيير قبل إصدار أي شيء. فيقبل المراجع أو يطلب تغييرات أو يقرّر خطوة الدمج والإصدار. وتتوقف الأتمتة حيث يلزم حكم الفريق.

متى أستخدم نمط Specified بدلًا من أشجار العمل المعزولة؟

استخدمه عندما يكون تحضير مجلد جديد لكل تشغيل مكلفًا فعلًا: مستودع ضخم جدًا، أو حالة أو ذاكرات مؤقتة مولّدة ومكلفة، أو أدوات مرتبطة بمسار محلي واحد. واقبل أن كل مجلد محدّد يخدم تشغيلًا واحدًا في المرة. وفيما عدا ذلك، فإن نمط Temporary هو الافتراضي الموصى به.