ما هو Sharkly؟

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

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

الخلاصة السريعة

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

ما هو Sharkly؟

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

أوضح طريقة لتحديد موقع Sharkly هي النظر إلى ما لا يفعله. فمن الأسئلة الشائعة الخاصة بالمنتج:

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

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

هذا الحدّ مهم، لأن أكثر افتراض خاطئ شيوعًا حول أداة في هذه الفئة هو أنها تنافس وكيلك. وهي لا تفعل ذلك. فأنت تحتفظ بإعداد Claude Code الخاص بك، وإعداد Codex الخاص بك، واشتراكاتك ومفاتيح API لديك. يجلس Sharkly فوقها جميعًا ويجعل تشغيلاتها قابلة للإسناد والتتبّع.

استخدم اشتراكك الخاص

لا وجود لإعادة بيع الرموز (tokens) هنا. فاستخدام النماذج يستمر عبر الاشتراكات أو مفاتيح API المضبوطة في أدوات البرمجة التي تربطها. وتعتمد حصتك من النماذج على أدوات البرمجة بالذكاء الاصطناعي والخطط وحسابات API التي يربطها فريقك، لا على Sharkly. وهذا التوصيف يحفظ لهذه الطبقة نزاهتها: فـ Sharkly يستحق مكانه بفضل التنسيق، لا بالوقوف بينك وبين النموذج.

المشكلة التي يحلّها Sharkly: الوكلاء يتوسّعون، أما التنسيق فلا

وكيل واحد يحتاج إلى مطالبة (prompt) جيدة. أما عدة وكلاء فيحتاجون إلى مدير. هذا التحوّل هو ما يوقع الفرق في المشكلات، ويحدث بسرعة بمجرد أن يُثبت الوكلاء فائدتهم.

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

• التصادمات. وكيلان يعدّلان المستودع نفسه فيكتب أحدهما فوق الآخر. يختفي العمل غير المثبّت (uncommitted) وتتشابك حالة git.
• العمى. مع وجود الوكلاء في ستة تبويبات طرفية، لن تعرف أي مهمة انتهت، وأيها عالقة، وأيها يعمل بهدوء على النهج الخطأ.
• فقدان السياق. الهدف والفرق والنقاش والمراجعة لكل تشغيل تعيش في جلسات خاصة منفصلة. لا يستطيع زميل أن يكمل من حيث توقفت، لأنه لا يوجد شيء مشترك ليكمل منه.

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

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

المفاهيم الأساسية، مشروحة

مفردات Sharkly قليلة، وكل كلمة منها تعني شيئًا واحدًا. تعلّم هذه الخمسة وستقرأ بقية المنتج بوضوح.

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

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

متى تستخدم وكيلًا واحدًا، ومتى تستخدم طاقمًا

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

سير العمل: من الطلب إلى الإصدار في أربع مراحل

يؤطّر Sharkly عمل المنتج في أربع مراحل. وهذا هو العمود الفقري للمنصّة بأكملها، وهو ينطبق بوضوح على الطريقة التي يُصدر بها الفريق عمله بالفعل.

المرحلة 1: الوصف والبحث

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

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

المرحلة 2: التطوير المتوازي التلقائي

يستلم الوكلاء المهام الجاهزة ويعملون في git worktrees معزولة. فتتقدّم الواجهة الأمامية والخلفية وإصلاح الأخطاء وتغطية الاختبارات في الوقت نفسه، كل منها في مساحة عمل خاصة على حواسيبك أنت. ومساحة العمل (worktree) هي ما يجعل التوازي آمنًا: مجلد عمل مرتبط يشارك مستودعًا واحدًا في تاريخه لكنه يحتفظ بفرعه وملفاته الخاصة. خمسة وكلاء، وخمس مساحات عمل، وخمسة فروع، وبلا أي تصادم.

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

المرحلة 3: الاختبار والقبول البشري

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

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

المرحلة 4: المشاريع والسبرنتات

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

العقد بين الإنسان والوكيل

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

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

من أين تأتي ميزة الفريق

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

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

لست مضطرًا لإعادة بناء عملياتك

اعتماد Sharkly ليس مشروع ترحيل. احتفظ بالأدوات التي يستخدمها فريقك بالفعل، مع جعل التشغيلات قابلة للإسناد والتتبّع. صِل حاسوبًا، واضبط الوكلاء، وابدأ بتوجيه العمل دون إعادة بناء العمليات التي يفهمها فريقك بالفعل.

إذا كنت تعمل داخل Jira، فاحتفظ بالمشاريع والمهام والحالات وسير العمل الذي يقرأه فريقك بالفعل. وصِل Sharkly ليبقى النظام القائم في مكانه بينما يدفع تنفيذ الوكلاء العمل إلى الأمام داخله. فالهدف هو إضافة تنفيذ مرئي قابل للمراجعة إلى إعدادك الحالي، لا استبداله بإعداد جديد يتعيّن على الجميع إعادة تعلّمه.

Sharkly مقابل حلٍّ تصنعه بنفسك

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

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

لمن صُمِّم Sharkly

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

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

وإذا لم ينطبق عليك أيٌّ من هذه الأمثلة بعد، فهذا جواب حقيقي أيضًا. فـ Sharkly يستحق مكانه عندما يصبح التنسيق هو عنق الزجاجة. أما دون ذلك، فيكفي وكيل واحد وطرفية واحدة.

البدء

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

ومن هناك، أضف وكيلًا ثانيًا لتشغيل شيء بالتوازي، ثم ضمّ زميلًا إلى اللوحة. فكل خطوة تضيف تنسيقًا كنت تقوم به يدويًا.

للبدء: نزّل Sharkly، وصِل حاسوبًا، ووجّه مهمتك الأولى. وتغطي الوثائق كل مفهوم بمزيد من التفصيل على docs.sharkly.ai.

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

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

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

هل يجب أن أدفع ثمن النماذج عبر Sharkly؟ لا. فاستخدام النماذج يستمر عبر الاشتراكات أو مفاتيح API المضبوطة في أدوات البرمجة التي تربطها. وتعتمد حصتك من النماذج على الخطط وحسابات API التي يملكها فريقك بالفعل.

أين يعمل كود الوكيل فعليًا؟ على حواسيب توصلها أنت، محليًا عبر Sharkly Desktop أو عن بُعد عبر Sharkly CLI. ويحصل كل تشغيل على مساحة عمل git worktree معزولة، فلا تتصادم الوكلاء المتوازية وتبقى التغييرات محصورة حتى تقبلها.

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

هل هذه استقلالية كاملة؟ هل يدمج الوكلاء تغييراتهم بأنفسهم؟ لا. فالوكلاء يبحثون وينفّذون ويختبرون ويقدّمون تقاريرهم، والبشر يحدّدون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. وتبقى قرارات القبول النهائي والإصدار بيد شخص.

هل يمكنني الاستمرار في استخدام Jira؟ نعم. احتفظ بالمشاريع والمهام والحالات وسير العمل الذي يستخدمه فريقك بالفعل، وصِل Sharkly ليدفع تنفيذ الوكلاء العمل إلى الأمام داخل النظام الذي تقرأه بالفعل.