الدردشة مع وكيل ذكاء اصطناعي أم تكليفه بمهمة؟ متى تستخدم أيهما

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

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

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

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

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

المشكلة: وكيل واحد، ونوعان من العمل

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

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

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

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

ما هي محادثة الوكيل في Sharkly؟

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

لدى Sharkly واجهتا دردشة، والوثائق صارمة في الفصل بينهما:

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

ثلاثة حدود تهمّنا هنا، لأن كلًا منها موضع قد يخطئ فيه شخص عاقل التقدير.

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

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

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

وإذا كنت جديدًا على مفهوم الوكيل أساسًا (إعداد عمل محفوظ يتضمّن التعليمات وRuntime والمهارات والمستودعات)، فإن دليل الوكلاء يغطي هذه الأساسيات.

ما الذي تمنحك إياه المهمة ولا تمنحك إياه الدردشة؟

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

تخفي هذه الجملة الواحدة أربعة ضمانات ملموسة لا تستطيع الدردشة تقديمها:

1. المسؤولية. للمهمة مكلَّف بها. وعندما يتعطّل شيء ما، يوجد اسم مسؤول عنه. أما جلسة الدردشة فلها قائمة مشاركين فقط، ولا هيكل مساءلة فيها.
2. الحالة. تنتقل المهمة عبر سير عمل حدّده فريقك: قائمة الانتظار (backlog)، وبدأ، والمراجعة، والانتهاء. ويمكن لأي شخص قراءة اللوحة ومعرفة موقع العمل دون سؤال أحد.
3. سجل التنفيذ. كل تشغيل لمهمة يترك أثرًا: متى انتظر في الطابور، ومتى بدأ، وما الأدوات التي استدعاها، ولماذا فشل. وعندما يتعطّل تشغيل، تقرأ سجل التنفيذ بدل إعادة تركيب الأحداث من الذاكرة.
4. المراجعة. يمكن للوكيل أن يترك المهمة في انتظار رد بشري أو مراجعة بشرية، وتصل هذه الإشارات إلى صندوق الوارد الخاص بالشخص المسؤول. فالقبول خطوة موثّقة، لا مجرد إحساس.

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

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

الدردشة مع الوكيل مقابل إسناد مهمة: جدول القرار

يتلخّص القرار في ما يحتاج العمل إلى تسجيله، لا في حجم العمل.

استخدم الدردشة حين تسأل أو تقارن أو تحقّق أو تبلور فكرة. واستخدم المهمة حين يحتاج العمل إلى مكلَّف به، أو حالة، أو معايير قبول، أو نتيجة يجب أن يوافق عليها أحدهم.

وهناك قاعدتان مضادتان صادقتان تمنعان تحوّل هذا إلى قانون مقدّس:

لا تُنشئ مهمة لكل سؤال. فسؤال «ما وظيفة هذه الوحدة؟» يستحق دردشة لا تذكرة. ولوحة مليئة بمهام على شكل أسئلة ليست إلا ضجيجًا يدفن العمل الحقيقي، والضجيج هو بالضبط ما وُجد نظام إدارة العمل للبشر والوكلاء لمنعه.

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

أوضاع الدردشة الثلاثة: الاستكشاف والتخطيط والتنفيذ

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

الاستكشاف (Explore) هو تحقيق للقراءة فقط. يتفقّد الوكيل ويشرح ويقارن ويلخّص دون إجراء أي تغييرات. أبقِ وضع الاستكشاف مختارًا حين تريد تحليلًا لا غير. وهو الوضع المناسب لطلبات مثل «اشرح لي مسار المصادقة» و«أي من هاتين المكتبتين يعتمد عليها الكود أصلًا؟».

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

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

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

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

كيف تنقل دردشة إلى مهمة

النقل هو النقطة التي تلتقي فيها الواجهتان، وتقدّم وثائق Sharkly تسلسلًا ملموسًا له. فعندما تنتج مناقشة إجراءً يستحق الالتزام به:

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

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

ملاحظة واحدة عن الموضع: المهمة المسندة إلى وكيل لا تبدأ ما دامت في قائمة الانتظار (Backlog). فقائمة الانتظار منطقة انتظار مؤقت. ونقل المهمة خارجها يبدأ تشغيل الوكيل المكلَّف حين يكون Computer وRuntime جاهزين، ما يعني أنك تستطيع تجهيز العمل من الدردشة الآن وإطلاقه حين يصبح الفريق جاهزًا. وأين يجري هذا التنفيذ فعليًا مسألة منفصلة، تُغطّى في الدليل التعريفي بـ Computers.

الدردشات السريعة: سياق المهمة دون مغادرتها

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

لكل دردشة سريعة اسم، وprompt اختياري، ووكيل أو طاقم مختار، وإعداد ظهور. والدردشات السريعة الخاصة لا يراها ولا يشغّلها سوى منشئها. أما الدردشات السريعة المشتركة فيراها كل من في المساحة، لكن منشئها وحده هو من يمكنه تعديلها. واختيار إحداها يفتح عرضًا مقسومًا تكون فيه المهمة على اليسار والدردشة على اليمين، ويُرسل prompt والوكيل وسياق المهمة معًا.

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

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

ماذا لو لم تتضمن منظومتك طبقة للمهام؟

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

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

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

ثلاثة سيناريوهات عملية

الاختبار غير المستقر. تلاحظ مهندسة فشل اختبار بشكل متقطّع. تفتح دردشة مع وكيل قراءة الكود لدى الفريق في وضع الاستكشاف: «لماذا قد يفشل auth_session_test في التشغيلات المتوازية؟» بعد عشر دقائق من القراءة، يشير الوكيل إلى fixture مشترك فيه حالة تسابق (race). الآن صار الأمر التزامًا: تنتقل إلى وضع التخطيط، فيصوغ الوكيل المهمة SH-341 بنطاق الإصلاح ومعيار قبول («ينجح الاختبار في 50 تشغيلًا متوازيًا متتاليًا»)، فتؤكّدها وتبدأها، وتسندها إلى وكيل الإصلاح. يبقى التحقيق في سجل دردشتها، بينما يستقر الإصلاح والـdiff والمراجعة على SH-341.

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

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

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

الخاتمة

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

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

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

هل يمكنني الدردشة مع وكيل حول مهمة دون إسنادها إليه؟

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

هل تظهر رسائل الدردشة في سجل نشاط المهمة؟

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

هل يمكن لزملائي قراءة جلسات محادثاتي المستقلة مع الوكلاء؟

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

ماذا يحدث إذا راسلت وكيلًا غير متصل أو مؤرشفًا؟

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

بأي وضع دردشة أبدأ؟

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

هل تستخدم الدردشة مع الوكيل إعدادات تنفيذ المهام لديّ؟

نعم. تمرّ تشغيلات الدردشة عبر إعداد الوكيل نفسه: تعليماته وRuntime وComputer. وفي وضع التنفيذ يتصرف الوكيل عبر CLI المهيّأ لديه، وهو الآلية نفسها التي تشغّل المهام.

متى ينبغي تحويل الدردشة إلى مهمة؟

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

هل يمكن لشخصين مشاركة جلسة دردشة واحدة مع وكيل؟

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