Sharkly Crews: فرق وكلاء الذكاء الاصطناعي بقيادة قائد يفوّض المهام

أول Agent ينضم إلى الفريق يرفع معدّل الإنتاج. أما الثاني فيخلق مشكلة تنسيق. لا بد أن يقرر أحدهم من يتولى تعديل الـ API، ومن يكتب الاختبارات، وهل تنتظر إعادة الهيكلة ترحيل المخطط، ومن يتحقق من النتيجة المجمّعة قبل أن يقبلها إنسان. في معظم الفرق، هذا «أحدهم» هو مهندس أول يمسك بطرفية في كل يد، وهذا الدور لا يتوسّع.

وُجدت Sharkly Crews لهذه اللحظة بالتحديد. الـ Crew مجموعة قابلة لإعادة الاستخدام من الأشخاص والـ Agents ينسّقها Agent قائد واحد، وهي تعيش داخل Sharkly، المنصة التي تُبقي عمل الـ Agents داخل نظام مهام مشترك. فبدل أن يوزّع إنسان كل مهمة فرعية بيده، تُسند الـ Task إلى الـ Crew. يقرأ الـ leader Agent الهدف، ويحدد الأعضاء الذين يجب أن يساهموا، ثم يعيد نتائجهم إلى مكان واحد يستطيع فريقك مراجعته.

يغطي هذا الدليل ماهية الـ Crew، ومتى يكون الـ Agent الواحد الخيار الأفضل، وكيف يسير التنفيذ بقيادة الـ leader من تشغيل إلى آخر، وكيف تُنشئ Crew سيظل فريقك يستخدمه بعد ثلاثة أشهر.

باختصار

الـ Crew في Sharkly مجموعة قابلة لإعادة الاستخدام من الأشخاص والـ Agents ينسّقها Agent قائد واحد. تُسند Task إلى الـ Crew، فيبدأ الـ leader أولًا، ويفسّر الهدف، ويوزّع الأجزاء على أعضاء الـ Agent بذكرهم بالإشارة، ثم يجمع نتائجهم على الـ Task. الـ Agents تبحث وتنفّذ وتختبر وترفع تقاريرها. أما الأشخاص فيحددون الاتجاه، ويمنحون الصلاحية، ويقبلون النتيجة.

ما هو الـ Crew في Sharkly؟

الـ Crew فريق مُسمّى وقابل لإعادة الاستخدام: أشخاص وAgents يتجمّعون حول نوع ثابت من العمل، مع Agent قائد واحد ينسّق التنفيذ. وبينما يكون الـ Agent الواحد إعدادًا عملًا محفوظًا لدور واحد، يوثّق الـ Crew كيفية تعاون عدة أدوار معًا، بحيث يمكن إسناد Task معقّدة إلى الفريق بدل إسنادها إلى منفّذ واحد.

يتضمّن كل Crew ما يلي:

• اسمًا ووصفًا وتعليمات Crew اختيارية
• مالكًا واحدًا (Owner)، وهو شخص في المؤسسة يتولى إدارة الـ Crew
• leader واحدًا، ويجب أن يكون Agent داخل الـ Space الخاص بالـ Crew
• أعضاء من الـ Agents والأشخاص يمكنهم المشاركة في ذلك الـ Space
• Space واحدًا مالكًا
• ظهورًا شخصيًا (Personal) أو على مستوى الـ Space
• إعدادًا اختياريًا لدليل Tasks مشترك

هناك حدّان مهمّان قبل أي شيء آخر.

الـ Owner ليس هو الـ leader. الـ Owner شخص يدير الـ Crew: عضويته وإعداداته وظهوره. أما الـ leader فهو Agent، وهو الذي ينسّق التنفيذ. واعتبار الـ Owner بديلًا عن الـ leader Agent سوء فهم للدورين معًا.

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

يُضاف الـ leader كعضو تلقائيًا، ويحمل دور الـ leader، ولا يمكن إزالته ما دام يقود الـ Crew. أما بقية الأعضاء فيمكنهم حمل تسميات أدوار تصف مساهمتهم، مثل backend أو tests أو docs، ما يمنح الـ leader معطيات ملموسة يعتمد عليها عند التوزيع.

متى تستخدم Crew بدلًا من Agent واحد؟

هذا الاختيار مأخوذ مباشرة من وثائق Sharkly، ويستحق أن يؤخذ على حرفيته. فالمهام الصغيرة المحددة بوضوح تُسند مباشرة إلى Agent واحد. أما الـ Crew فيُستخدم عندما يحتاج الـ leader إلى تفسير الهدف، وإشراك أعضاء Agent آخرين، وجمع نتائجهم في Task أو محادثة واحدة.

الـ Agent الواحد هو الخيار الصحيح عندما:

1. يقع العمل داخل دور واحد، مثل إصلاح خطأ في خدمة واحدة.
2. يكون النطاق واضحًا أصلًا ولا حاجة إلى تفكيكه.
3. تريد أقل عدد ممكن من العناصر المتحركة بين الإسناد والمراجعة.
4. تكون لا تزال تضبط تعليمات Agent معيّن وتريد إشارة نظيفة.

أما الـ Crew فيستحق مكانه عندما:

1. يمتد الهدف عبر أدوار متعددة، مثل ميزة تحتاج تغييرات في الـ backend والـ frontend والاختبارات.
2. يجب أن يقرر أحدهم ترتيب المساهمات، وتريد أن يكون هذا «أحدهم» Agent لا شخصًا يفتح طرفيتين.
3. تتكرر تشكيلة المتخصصين ذاتها مع كل طلب جديد.
4. يجب أن تصل نتائج عدة Agents إلى Task واحدة بدل أن تتفرّق في جلسات خاصة.

وإذا كان فريقك لا يزال يقرر ما إذا كان العمل متعدد الـ Agents يستحق التنظيم أصلًا، فإن المقدمة حول تنسيق الـ AI agents تشرح المقايضات من مبادئها الأولى. والخلاصة السريعة: إضافة Agent ثانٍ رخيصة، أما التنسيق غير المُدار بين الـ Agents فليس كذلك.

كيف يعمل التنفيذ بقيادة الـ leader أولًا

عند إسناد Task إلى Crew، يتبع التنفيذ تسلسلًا يبدأ بالـ leader:

1. تُسند الـ Task إلى الـ Crew عبر أداة Assignee، مثل أي Assignee آخر.
2. إذا كانت الـ Task في حالة قابلة للتنفيذ وكان الـ leader جاهزًا، يبدأ الـ leader Agent أولًا.
3. يقرأ الـ leader سياق الـ Task وتعليمات الـ Crew.
4. ثم إما يتولى العمل بنفسه، وإما يذكر أعضاء Agent مؤهلين للإشارة بمساهمات محددة.
5. يُشغَّل أعضاء الـ Agent المذكورون على الـ Task نفسها ويضيفون نتائجهم إلى محادثتها.
6. يواصل الـ leader التنسيق ويجمع النتائج.

الهدف التصميمي وراء هذا التسلسل هو ضبط النفس. فالتنفيذ بقيادة الـ leader أولًا يمنع جميع أعضاء الـ Agent من البدء دفعة واحدة. كما يمنح الـ leader فرصة لرصد السياق الناقص، واختيار المشاركين المناسبين، والتحكم في ترتيب العمل. والـ Crew بدون leader سيكون مجرد زر توزيع؛ أما مع leader فهو فريق يفكّر قبل أن يوزّع العمل.

ويتصرف الـ Backlog بالطريقة نفسها التي يتصرف بها مع الـ Agents الفردية: إسناد Task في الـ Backlog لا يبدأ الـ leader. فالـ Backlog منطقة انتظار يُحضَّر فيها العمل، ونقل الـ Task إلى حالة قابلة للتنفيذ هو الفعل الذي يبدأ الـ Crew. والإسناد لا يُطلق العمل من تلقاء نفسه أبدًا.

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

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

الملكية والظهور ومن يمكنه استخدام Crew

يمكن للأشخاص الذين يملكون صلاحية إنشاء موارد مشتركة داخل Space أن ينشئوا Crew فيه. وينتمي كل Crew إلى Space واحد، وظهوره هو ما يحدد من يمكنه العثور عليه واستخدامه:

ينطبق الظهور على الـ Crew نفسه، وعلى محادثة الـ Crew، وعلى اختياره كـ Task Assignee. والـ Crew الشخصي يديره الـ Owner الخاص به، وبعد تغيّر Owner الـ Crew الخاص، يفقد الـ Owner السابق صلاحية الإدارة. وقاعدة التسليم هذه مهمة عندما ينتقل الشخص الذي بنى الـ Crew إلى فريق آخر: انقل الملكية عن قصد بدل أن تكتشف الفجوة لاحقًا.

وعندما ينتهي دور الـ Crew، أرشِفه بدل حذف سجله. فالـ Crew المؤرشف يتوقف عن استقبال إسنادات جديدة مع بقاء سجله متاحًا. وقبل الأرشفة، تحقّق مما إذا كانت Tasks أو Automations حالية لا تزال تستخدم الـ Crew، وانقل ذلك العمل إلى Assignee آخر أولًا. وينطبق فحص التبعيات نفسه قبل أرشفة Agent ينتمي إلى Crew.

محادثة الـ Crew: التنسيق قبل وجود Task

ليست كل مناقشة تستحق Task من اليوم الأول. فمحادثة الـ Crew موجودة لتلك المحادثة التي تسبق بند العمل: استكشاف مشكلة، وتحديد المشاركين المناسبين، وبلورة خطة.

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

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

كما تحتوي تفاصيل الـ Task على محادثات سريعة في شريط الأدوات العلوي. المحادثة السريعة تشغّل Agent أو Crew مختارًا مع الـ Task الحالية كسياق، في عرض مقسوم إلى جانب الـ Task. وهي طريقة مفيدة لسؤال Crew «ما الذي ستفعله بهذا؟» قبل إسناده رسميًا.

تقنيات متقدمة في الـ Crew

Agents حصرية للـ Crew: متخصصون لا يعملون في أي مكان آخر

بعض الـ Agents لا معنى لها إلا داخل فريقها. فمنسّق الدمج الذي يفترض وجود ثلاثة أعضاء آخرين، أو المراجع المضبوط على أعراف Crew واحد بعينه، لا ينبغي أن يظهر في قائمة الـ Agent العامة للمؤسسة حيث قد يُسند إليه أحدهم عملًا فرديًا لم يُصمَّم له أصلًا.

ووسم Agent كحصري للـ Crew يحصر استخدامه في ذلك الـ Crew. وبعد تفعيل الإعداد:

• لا يمكن استدعاء الـ Agent إلا داخل الـ Crew الحالي
• لا يمكن استخدامه في محادثة خاصة ولا إسناد Task إليه بمفرده
• يختفي من My Agents، ومن الدليل، ومن قائمة Agents الخاصة بالمؤسسة، ومن أداة اختيار الـ Assignee

الحصرية حدّ على نطاق الـ Agent، وليست دورًا داخل الـ Crew. فتسمية الدور تصف ما يفعله العضو؛ أما الحصرية فتصف أين يمكن استدعاء الـ Agent. والـ Agent الحصري للـ Crew ينتمي إلى Crew واحد على الأكثر في الوقت نفسه، فإن كان موجودًا أصلًا في Crew آخر فأزله منه أولًا. ورفع الحصرية يعيد الظهور والإسناد العاديين، وتبقى الـ Tasks والمحادثات السابقة قائمة في الحالتين. فالمحظور هو المحادثات الخاصة الجديدة والإسنادات الفردية الجديدة.

دليل الـ Task المشترك: عندما يتعين على الأعضاء البناء على الملفات نفسها

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

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

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

كتابة تعليمات Crew تصمد

تعليمات الـ Crew هي دليل التشغيل الذي يتبعه الـ leader في التنسيق. والوثائق دقيقة بشأن ما ينتمي إليها: كيف يقرر الـ leader إشراك Agent آخر، وما الأدوار المتاحة، وكيف ينبغي جمع النتائج، ومتى يجب أن يتخذ شخص قرارًا.

أبقِ الطبقات منفصلة. فمتطلبات الـ Task المحددة تبقى في وصف الـ Task وتعليقاتها. والإجراء القابل لإعادة الاستخدام الذي تشترك فيه عدة Agents مكانه Skill. وتنقل تعليمات كل عضو Agent دوره الفردي. أما تعليمات الـ Crew فتغطي قواعد التعاون فقط، ما يجعلها قصيرة بما يكفي ليتّبعها الـ leader في كل تشغيل. وتكرار تعليمات كل عضو داخل الـ Crew هو أكثر ما يجعل التوزيع غير متوقع.

وهذا هيكل عملي للبدء:

# Crew: Checkout Feature Crew

## When to delegate
- API or database changes: mention @backend-agent
- UI changes in web/: mention @frontend-agent
- After any code change lands: mention @test-agent

## Order
Backend before frontend when a contract changes.
Tests run last, against the combined changes.

## Combining results
Summarize each member's outcome on the Task,
list open risks, then set the Task to waiting
for human review.

## Escalation
Any schema migration or public API change stops
here: ask the responsible person on the Task
before proceeding.

وهذا القسم الخاص بالتصعيد هو العقد بين الإنسان والـ Agent مكتوبًا داخل الفريق نفسه. الـ Agents تبحث وتنفّذ وتختبر وترفع تقاريرها. والأشخاص يحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. والـ Crew لا يغيّر هذا العقد؛ بل يمنح الجانب الخاص بالـ agents أيديَ أكثر.

إعداد أول Crew لديك

تصف الوثائق تسلسل إعداد نموذجيًا، وهو يعادل نحو خمس عشرة دقيقة من العمل إذا كانت الـ Agents لديك موجودة بالفعل:

1. حدّد نوع العمل الثابت الذي سيتولاه الـ Crew. «كل شيء» ليس نوعًا من العمل؛ أما «التغييرات على مسار الدفع» فهو كذلك.
2. اختر الظهور والـ Owner. ابدأ بـ Personal أثناء الضبط، وانتقل إلى ظهور Space عندما يستحق الإعداد إعادة الاستخدام.
3. اختر Agent ليكون leader. اختر من تثق بحكمه في توجيه العمل، لا بالضرورة من يكتب أكبر قدر من الكود.
4. أضف أعضاء الأشخاص والـ Agents الذين يحتاجهم العمل، وامنح الأعضاء تسميات أدوار يستطيع الـ leader الاستناد إليها. في صفحة Members يمكنك إضافة عدة أعضاء دفعة واحدة، ويمكن لقائمة الصف تعيين leader جديد أو إزالة عضو لاحقًا.
5. اكتب تعليمات الـ Crew للتنسيق والمخرجات، وفق قواعد الطبقات أعلاه.
6. لا تفعّل دليل الـ Task المشترك إلا عندما يكون سلوك إعادة الاستخدام هو ما تريده فعلًا. وعند الشك، اتركه معطّلًا.

ثم أسند Task حقيقية واحدة. شيء مثل SH-312: «أضف حقل سبب الإلغاء إلى مسار إلغاء الاشتراك، في الـ API والـ UI، مع اختبارات.» راقب بدء الـ leader، واقرأ كيف يوزّع العمل، وراجع ما يعود إلى الـ Task. فأول تشغيل لـ Crew يعلّمك عن تعليماتك أكثر مما تعلّمك أي مراجعة مسبقة. ولا يزال كل عضو Agent يعمل على الـ Runtime المُهيّأ له، سواء كان Claude Code أو Codex أو أي أداة CLI أخرى يدفع فريقك مقابلها بالفعل، لأن Sharkly يبقى طبقة التنسيق حول هذه الأدوات لا بديلًا عنها.

أنماط Crew جديرة بالنسخ

هذه أنماط إعداد وليست دراسات حالة؛ وكل نمط منها يركّب سلوكًا موثّقًا.

Crew الميزات. leader Agent يخطّط، مع أعضاء في الـ backend والـ frontend والاختبارات بتسميات أدوار مطابقة. يفكّك الـ leader المتطلب، ويرتّب الـ backend قبل الـ frontend عند تغيّر العقود، ويذكر عضو الاختبار أخيرًا. هذا هو النمط الذي يصفه هيكل الإعداد أعلاه، وهو يناسب الفرق التي تتجاوز متطلباتها حدود الأدوار بانتظام.

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

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

Crew دعم الـ Sprint. خلال Sprint، يتولى Crew العمل المتكرر ومحدود النطاق: تحديثات التبعيات، وحجر الاختبارات المتقلّبة، وانحراف الوثائق. ومهمة الـ leader الأساسية هي رفض العمل الخارج عن النطاق، ما يجعل إنتاجية الـ Crew متوقعة بما يكفي للتخطيط حولها.

وأيًا كان النمط الذي تبدأ به، ابدأ بنمط واحد. فالفريق الذي يدير Crew واحدًا بإتقان يكتسب عادات التنسيق التي تجعل الثاني رخيصًا.

متى لا يكون الـ Crew هو الحل

قائمة حدود صادقة، لأن أسرع طريقة لتنفير فريق من العمل متعدد الـ Agents هي استخدامه حيث ينتقص من القيمة.

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

محفّزات متكررة، Automations. إذا كان العمل ينطلق وفق جدول زمني أو حدث لا وفق حكم بشري، فالـ Automation أداة أدق. فالـ Crews تقرر، والـ Automations تكرر. وهما يتكاملان جيدًا، لكنهما ليسا بديلين أحدهما عن الآخر.

التفكيك داخل التشغيل، الـ subagents وقت التشغيل. أدوات مثل Claude Code قادرة على توليد subagents داخل تشغيل واحد. وهذا مكمّل لا منافس: فالـ subagents وقت التشغيل تقسّم عمل Agent واحد داخل جلسته، بينما ينسّق الـ Crew Agents وRuntimes ونتائج منفصلة على مستوى الـ Task حيث يستطيع الفريق رؤيتها. وإن كنت تشغّل اليوم عدة Agents من Claude Code عبر سكربتات وtmux، فالـ Crew هو مسار الانتقال الطبيعي للنصف التنسيقي من ذلك الإعداد.

مجموعة دردشة بخطوات إضافية. إن كنت تريد نقاشًا، فاستخدم محادثة الـ Crew وتوقف عند ذلك. لا تُنشئ Crew مهمته الوحيدة الإجابة عن أسئلة يستطيع Agent واحد الإجابة عنها.

ولا شيء من هذا يطلب منك إعادة بناء أي شيء. فالأعضاء يحتفظون بـ Runtimes ومستودعاتهم واشتراكاتهم؛ والـ Crew طبقة تنسيق فوق Agents هيّأتها بالفعل، ويستمر استخدام النماذج عبر الاشتراكات ومفاتيح الـ API المُهيّأة في تلك الأدوات.

الخلاصة

الـ Crew هو جواب Sharkly على السؤال الذي يصطدم به كل فريق بعد نجاح أول Agent لديه: كيف نشغّل عدة Agents دون تعيين إنسان يتولى تنظيم المرور؟ الآلية هي leader Agent واحد بقواعد تنسيق مكتوبة، وأعضاء بأدوار واضحة، وTask تعود إليها كل النتائج. وضبط النفس مبني في التصميم: تنفيذ بقيادة الـ leader أولًا، وBacklog لا يبدأ شيئًا تلقائيًا، وعزل افتراضي، وأشخاص يمسكون بالقبول في النهاية.

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

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

ما هو الـ Crew في Sharkly؟

الـ Crew مجموعة قابلة لإعادة الاستخدام من الأشخاص والـ Agents ينسّقها Agent قائد واحد. وله Owner يديره، وSpace واحد مالك، وظهور Personal أو على مستوى Space، وتعليمات Crew اختيارية. أسند Task إلى الـ Crew، وسينسّق الـ leader من يساهم وكيف تُجمع النتائج.

متى أستخدم Crew بدلًا من Agent واحد؟

أسند العمل الصغير المحدد بوضوح مباشرة إلى Agent واحد. واستخدم الـ Crew عندما يحتاج الهدف إلى تفسير، أو يمتد عبر عدة أدوار، أو يتطلب عودة نتائج من عدة Agents إلى Task واحدة. وإذا كانت المجموعة ذاتها من المتخصصين تتكرر مع كل طلب، فذلك التكرار هو الإشارة إلى جعل الفريق قابلًا لإعادة الاستخدام.

هل يؤدي إسناد Task إلى Crew إلى بدء كل الأعضاء دفعة واحدة؟

لا. التنفيذ بقيادة الـ leader أولًا: يبدأ الـ leader Agent، ويقرأ سياق الـ Task وتعليمات الـ Crew، ثم يذكر أعضاء Agent مؤهلين لمساهمات محددة. بعدها يعمل الأعضاء المذكورون على الـ Task نفسها. وهذا يمنع الاندفاع الجماعي ويمنح الـ leader التحكم في الترتيب والمشاركة.

هل يمكن للأشخاص أن يكونوا أعضاء في Crew؟

نعم. عضوية الأشخاص توثّق من يشارك، ويمكن للأعضاء من البشر في Crew شخصي الوصول إليه والمحادثة فيه. لكن أعضاء الـ Agent وحدهم يمكنهم بدء تشغيلات الـ Agent. أما الأشخاص فيساهمون عبر تعليقات الـ Task والقرارات والمراجعة، وهذا هو الجانب البشري من العقد.

ما هو الـ Agent الحصري للـ Crew؟

الـ Agent الحصري للـ Crew محصور في Crew واحد: لا يمكن استدعاؤه إلا داخله، ولا يمكنه إجراء محادثات خاصة أو تولّي إسنادات Tasks فردية، ويبقى خارج قوائم الـ Agents على مستوى المؤسسة. وهو حدّ على النطاق لا دور، ورفعه يعيد للـ Agent ظهوره العادي.

هل يمكن لأعضاء الـ Crew مشاركة الملفات أثناء الـ Task؟

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

هل تُنشئ محادثة الـ Crew Tasks تلقائيًا؟

لا. محادثة الـ Crew مخصصة لاستكشاف مشكلة أو بلورة خطة، ويكون الـ leader شريك المحادثة الأول. وعندما يتحول النقاش إلى عمل ملموس، تُنشئ Task وتُسند الـ Crew إليه لتبقى الحالة والتشغيلات والقبول مرتبطة ببند العمل.