تشغّل وكيلًا برمجيًا على مهمة حقيقية، ثم تُغلق الحاسوب وتذهب لتناول الغداء. هذا الجزء سهل. أما الجزء الصعب فهو ما تجده عند عودتك: طرفية تجاوز محتواها أعلى الشاشة، وdiff لم تشهد كتابته، ولا إجابة واضحة عن السؤال الوحيد المهم: هل هذا العمل جيد بما يكفي للإبقاء عليه؟
ينقسم تشغيل وكيل دون إشراف إلى نصفين، ومعظم الإعدادات لا تحل إلا النصف الأول. النصف الأول هو إبقاء العملية حيّة ومنتجة بينما لا يراقبها أحد. والنصف الثاني هو قائمة انتظار المراجعة: كومة التشغيلات المنتهية وأنصاف المنتهية والفاشلة التي تنتظر قرارًا بشريًا عند عودتك. وإذا تجاهلت النصف الثاني، فلن تفعل الوكلاء غير المشرف عليها سوى نقل عنق الزجاجة من كتابة الشيفرة إلى إعادة تركيب ما حدث.
يتناول هذا المقال النصفين معًا: كيف تُعِدّ تشغيلًا دون إشراف بنفسك، ونمط الفشل في كل خطوة، والنقطة التي يتوقف عندها هذا الإعداد اليدوي عن التوسّع. وعندما تتحول طرفية واحدة إلى خمس، تأتي لوحة مهام مثل Sharkly فوق وكلائك البرمجيين. تُبقي Claude Code أو Codex أو Gemini CLI يقوم بالعمل، بينما تحتفظ Sharkly بالمهمة والتشغيل والمراجعة في مكان واحد بدلًا من تشتتها بين طرفيات أغلقتها بالفعل.
ما الذي يعنيه تشغيل وكيل دون إشراف فعليًا
التشغيل دون إشراف هو وكيل برمجي ينفّذ مهمة على مضيف لا تراقبه بنشاط، مع التقاط مخرجاته لمراجعتها لاحقًا. ولهذا التعريف ثلاثة أجزاء جوهرية: مهمة يستطيع الوكيل إنجازها من دونك، ومضيف يظل يعمل عند انقطاع اتصالك، وسجل يمكنك قراءته بعد ذلك.
السجل هو الجزء الذي يستهين به الناس. فعندما تراقب وكيلًا مباشرةً، تكون أنت السجل: تراه يختار الملف الخطأ، فتقاطعه، وتصحّح المسار. أما دون إشراف فلا يحدث أي من ذلك. وكل ما فعله الوكيل يجب أن يبقى في شكل يمكنك فحصه ببرود، بعد ساعات، دون أي ذكر لما طلبته. الوكلاء يبحثون وينفّذون ويختبرون ويقدّمون تقارير. والبشر يحدّدون الاتجاه، ويمنحون الصلاحية، ويقبلون النتيجة. ولا يصمد هذا التعاقد إلا إذا كان التقرير حقيقيًا وكاملًا عند عودتك إليه.
إذن الهدف ليس «اجعل الوكيل يعمل من دوني»، بل «اجعل الوكيل يعمل من دوني ويعيد إليّ شيئًا يمكنني مراجعته». هاتان مشكلتان مختلفتان، والثانية هي حيث تنهار سير العمل دون إشراف عادةً.
إعداد تشغيل دون إشراف بنفسك
إليك النسخة اليدوية الدنيا، مع نمط الفشل الذي ينقّ عليك في كل خطوة.
الخطوة 1: اعزل العمل. امنح التشغيل نسخة سحب خاصة به حتى لا يتصادم مع محرّرك أو مع وكيل آخر.
git worktree add ../task-auth-refactor -b task/auth-refactor
cd ../task-auth-refactor
نمط الفشل: إذا تجاهلت هذه الخطوة، فسيطمس تشغيلان في المجلد نفسه تغييرات بعضهما غير المُودَعة. راجع نسخة سحب واحدة لكل مهمة لمعرفة سبب كون worktrees، وليس الفروع وحدها، هي حدود العزل.
الخطوة 2: افصل العملية. ستُغلق جلسة SSH أو الطرفية، والعملية في المقدمة تموت معها (SIGHUP). أبقِها حيّة باستخدام nohup أو جلسة tmux:
nohup claude -p "Refactor auth to use the new token service; run the tests" \
> run.log 2>&1 &
نمط الفشل: شغّله في صدفة أمامية عادية، وسيقتل إغلاق الغطاء الوكيل في منتصف تعديل متعدد الملفات، تاركًا شجرة معطوبة. يحل nohup مشكلة عمر العملية لكنه لا يمنحك طريقة للعودة إلى الداخل؛ أما tmux فيتيح لك إعادة الاتصال ورؤية ما يجري.
الخطوة 3: التقط كل شيء. الأمر > run.log 2>&1 أعلاه ليس اختياريًا. إنه قائمة انتظار المراجعة في أبسط صورها الخام.
نمط الفشل: من دون سجل ملتقط، لا يمكنك الإجابة عن سؤال «لماذا توقف؟». وأكثر تعطّل صامت شيوعًا هو وكيل ينتظر إلى الأبد مطالبة تفاعلية لن يجيب عنها أحد، لأن «دون إشراف» تعني أنه لا يوجد من يكتب «نعم». شغّله في وضع غير تفاعلي، ووافق مسبقًا على المجموعة الضيقة من الإجراءات التي تحتاجها المهمة.
الخطوة 4: حدّد نطاق التأثير. قرّر قبل أن تبتعد ما الذي يجوز للوكيل فعله بمفرده وما الذي يحتاج إليك. قيّد نطاق الملفات، وامنع force-push، ولا تدع أي تشغيل دون إشراف يدمج إلى فرع محمي أبدًا.
نمط الفشل: تشغيل ممنوح صلاحيات مفرطة يدفع مباشرةً إلى main ليس مكسبًا في الإنتاجية، بل حادث. بوابات الموافقة موجودة ليتوقف الوكيل عند آخر نقطة آمنة وينتظر.
الخطوة 5: اعرف متى انتهى، وكيف. تحقق من رمز الخروج، وأرسل لنفسك إشارة حتى لا تتفقد السجل يدويًا:
claude -p "..." > run.log 2>&1; echo "exit $?" | mail -s "auth run done" [email protected]
نمط الفشل: من دون إشارة إتمام، يتحول «دون إشراف» إلى «أتفقد الطرفية كل عشرين دقيقة»، وهذا مجرد إشراف مع زمن استجابة إضافي.
أين يتوقف الإعداد اليدوي عن التوسّع
وكيل واحد، وworktree واحدة، وملف سجل واحد: هذا ينجح، ولتشغيل واحد لا تحتاج إلى أي شيء أثقل. لكن الإعداد ينهار لحظة وجود أكثر من واحد.
شغّل ثلاثة وكلاء على ثلاث مهام، وسيصبح لديك ثلاث worktrees وثلاثة ملفات سجلات وثلاثة رموز خروج وثلاث رسائل بريد عن الإتمام ستخطئ في قراءتها بنظرة سريعة. العزل ما زال قائمًا. أما الذي ينهار فهو قائمة انتظار المراجعة. لا شيء يخبرك أي تشغيل انتهى بنظافة، وأيها فشل في الاختبارات، وأيها ينتظر بهدوء مطالبةً ما. أنت تعيد تركيب ذلك يدويًا، بقراءة السجلات واحدًا تلو الآخر، وهو بالضبط العمل الذي كنت تحاول تفويضه.
هذه هي التكلفة الحقيقية، ويسهل تفويتها لأن كل قطعة تبدو سليمة بمفردها. تصبح مراقبة عدة تشغيلات متوازية مشكلة حقيقية بمجرد أن يتجاوز العدد ما تعرضه شاشة واحدة. ملف السجل يجيب عن سؤال «ماذا طبّع هذا التشغيل»، لا عن سؤال «من بين تشغيلاتي الستة، أيها ثلاثة تحتاج إليّ الآن». وإشارات الحالة والفشل التي يستحق التقاطها لا تنظّم نفسها في قائمة انتظار. وقائمة الانتظار هي جوهر العمل أثناء غيابك: تريد قائمة قرارات مرتّبة بالأولوية، لا مجلدًا من المخرجات الخام.
ما الذي تغيّره لوحة المهام
لوحة المهام هي حيث يُحل النصف الثاني من المشكلة. التشغيل دون إشراف ما زال يجري على Computer تتصل به، مع Runtime الحالي الذي يقوم بالبرمجة. ما يتغيّر هو المكان الذي تصل إليه النتيجة.
في Sharkly، يعيش العمل والتشغيل والمراجعة على Task واحدة. تُسند المهمة إلى Agent، وهو إعداد محفوظ من التعليمات وRuntime والمستودعات، لا مجرد مطالبة عابرة تعيد كتابتها. يستحوذ الوكيل على المهمة، ويعمل في worktree معزولة، وتعود تفاصيل تنفيذه وعوائقه ونتائجه إلى الخط الزمني للمهمة. وعندما تعود، لا تبحث بـgrep في ستة ملفات سجلات، بل تفتح اللوحة وتقرأ قائمة الانتظار: ما انتهى، وما فشل، وما ينتظرك.
هذا حدّ يستحق التوضيح صراحةً. Sharkly ليست بديلًا عن Claude Code أو Codex أو أدوات التنفيذ الأخرى. إنها تضيف طبقة المهمة المشتركة وComputer والسياق والمراجعة حول الأدوات التي يستخدمها فريقك بالفعل. الوكيل ما زال يكتب الشيفرة. وتحرص Sharkly على أن الشيفرة، خلال غيابك، قد عادت إلى مكان تستطيع رؤيتها فيه، مع ملخص التغييرات ونتائج الاختبارات مرفقة، وأن القبول النهائي يظل قرارًا بشريًا. تتوقف الأتمتة عند النقطة التي يلزم فيها الحكم.
يمكنك بناء كل هذا يدويًا باستخدام worktrees وnohup وأمر بريد. وقاعدة القرار الصادقة: إذا كنت تشغّل وكيلًا واحدًا من حين إلى آخر، فالإعداد اليدوي كافٍ وSharkly عبء إضافي لا تحتاجه. لكن المعادلة تتغير عندما تعمل عدة وكلاء عبر مهام ومستودعات متعددة، وتصبح قائمة انتظار المراجعة هي ما تقضي فيه صباحك. وإذا أردت الاستمرار في استخدام عدة وكلاء برمجيين بدل الالتزام بمنظومة واحدة، فتلك القائمة هي المشكلة التي صُممت Sharkly حولها.
قائمة انتظار المراجعة هي عنق الزجاجة الحقيقي
إليك الافتراض الذي يستحق التشكيك: الناس يحسّنون التشغيل دون إشراف ويعاملون المراجعة كفكرة لاحقة. هذا مقلوب. تشغيل الوكلاء بالتوازي أثناء نومك ليس مكسبًا إلا إذا كانت مراجعة مخرجاتهم في الصباح التالي أسرع مما لو أنجزت العمل بنفسك. وعندما تنتهي خمسة وكلاء بين ليلة وضحاها وتستغرق مراجعة diffs الخمسة وقتًا أطول من كتابة اثنين منها، فالتوازي لم ينتج شيئًا.
لذا صمّم قائمة انتظار المراجعة أولًا. حدّد ما الذي يجب أن يتضمنه «الإنجاز» قبل أن يصل إليك التشغيل: اختبارات ناجحة، وفحص أنواع، وملخص تغييرات، وملاحظة بالحدود المعروفة. ورتّب القائمة حسب المخاطر لا حسب وقت الانتهاء، حتى يحظى التشغيل الذي مسّ المصادقة باهتمامك قبل ذاك الذي أصلح خطأً مطبعيًا. واجعل «طلب تغييرات» بسهولة «الموافقة»، لأن نصف التشغيلات دون إشراف ستكون قريبة لكن غير صحيحة. المراجعة هي عنق الزجاجة في أي سير عمل بوكلاء متوازيين، والمكان الذي تعمل فيه الوكلاء فعليًا، خادمك أو حاسوبك المحمول أو كليهما، أقل أهمية بكثير من وصول مخرجاتهم في صورة قائمة يمكنك إفراغها.
قائمة تحقق يمكنك تطبيقها اليوم
قبل أن تبتعد عن وكيل، تأكد من:
- العزل: للتشغيل worktree خاصة به، لا نسخة سحبك العاملة.
- العمر الافتراضي: تنجو العملية من انقطاع الاتصال (
nohupأوtmuxأو Computer مُدار)، فإغلاق الغطاء لا يقتلها في منتصف التعديل. - الالتقاط: يذهب stdout وstderr إلى سجل دائم أو خط زمني لمهمة يمكنك قراءته ببرود.
- غير تفاعلي: لن يتعطل الوكيل على مطالبة لا يوجد من يجيب عنها.
- نطاق التأثير: نطاق الملفات محدود، وforce-push معطّل، ولا يدمج أي تشغيل دون إشراف إلى فرع محمي.
- إشارة الإتمام: يُبلَّغ لك عند الانتهاء وما إذا كان قد نجح، دون تفقّد دوري.
- تعاقد المراجعة: يصل كل تشغيل منتهٍ مصحوبًا بالاختبارات وملخص التغييرات والحدود المعروفة، ويبقى القبول قرارك.
البنود الستة الأولى تجعل التشغيل دون إشراف. والبند الأخير يجعله يستحق العناء. وإذا كنت تدير بالفعل عدة وكلاء، ومراجعة الصباح هي ما يستهلك وقتك، فشغّل وكلاءك البرمجيين الحاليين عبر Sharkly لتصلك القائمة منظّمة بدل أن تكون مشتّتة.
