الوكيل البرمجي لا يكون متاحًا إلا بقدر الجهاز الذي يعمل عليه. ابدأ عملية إعادة هيكلة طويلة باستخدام Claude Code أو Codex، ثم أغلق الغطاء للحاق بقطار، فتضيع الجلسة مع انقطاع اتصال SSH. شغّل وكيلين على الحاسوب المحمول نفسه، فتدور المراوح بجنون بينما يتلعثم محررك. عند نقطة ما، يتوقف السؤال عن كونه «أي وكيل» ليصبح «أين يعمل الوكيل فعليًا».
الإجابة عادةً واحدة من ثلاثة: أبقِه على حاسوبك المحمول، أو انقله إلى خادم بعيد، أو وزّع العمل بين الاثنين. كل خيار يقايض الراحة بالموثوقية. الحاسوب المحمول في متناول يدك لكنه ينام ويخفض أداءه وينقطع اتصاله. الخادم يبقى مستيقظًا ويمتلك نوى أكثر، لكنه يضيف إعدادًا وطبقة من التساؤل «ما الذي يفعله الآن على أي حال». أما الجمع بين الاثنين فيمنحك أفضل ما فيهما، مع عناء إدارة كليهما.
تستعرض هذه المقالة إعداد الوكيل البعيد من البداية إلى النهاية: مسار التنفيذ الذاتي بأوامر حقيقية، وأنماط الفشل التي تنتظرك في كل خطوة، وأين يزيل Computer المتصل في Sharkly الجزء الذي يظل يتعطل. أنت تملك وكلاء برمجيين بالفعل. المشكلة هي تشغيلهم في مكان دائم ومعرفة ما حدث حين تشيح بنظرك.
لماذا تنقل الوكيل بعيدًا عن حاسوبك المحمول
الحاسوب المحمول هو الخيار الافتراضي لأنه المكان الذي تكتب فيه. لكنه أيضًا أسوأ مضيف لأي شيء يعمل أطول من مدى انتباهك. نظام macOS ينام عند إغلاق الغطاء. وضع البطارية يخفض أداء المعالج. شبكات VPN المؤسسية تنقطع. كل حدث من هذه يقتل الوكيل في منتصف مهمته، والوكيل لا يدري أنه قُوطِع؛ بل تكتشف ذلك حين تعيد فتح الطرفية لتجد موجهًا ميتًا وبلا ملخص.
المضيف البعيد يحل مشكلات الفيزياء هذه. جهاز افتراضي سحابي أو صندوق Linux احتياطي يبقى مشتغلًا، ويحافظ على شبكته، ويملك نوى إضافية للعمل المتوازي. الثمن أن الوكيل يعمل الآن في مكان لا تراه. تسجل الدخول عبر SSH للاطلاع عليه، وتمرر السجل لتخمين مدى تقدمه، وتبقى النتائج على ذلك الصندوق حتى تنسخها منه.
تشغيل الاثنين هو الحالة النهائية الصادقة لمعظم الناس. تبقي التعديلات السريعة التفاعلية على الحاسوب المحمول حيث تكون التغذية الراجعة فورية، وتدفع المهام الطويلة أو المتوازية إلى الخادم حيث يمكنها العمل ساعة كاملة دون رقابة. الحيلة هي جعل مضيف واحد أو خمسة يبدو كمكان واحد، لا كجدول بيانات من عناوين IP.
إعداد الوكيل البعيد بنفسك، وأين تتعطل كل خطوة
المسار اليدوي معروف جيدًا. إليك النسخة المختصرة، مع نمط الفشل الذي يظهر في كل خطوة.
جهّز المضيف وانقل الوكيل إليه:
ssh you@build-server
# install the agent's CLI, e.g. Claude Code or Codex
# authenticate it with your own subscription or API key
git clone [email protected]:your-org/your-repo.git
cd your-repo
claude
نمط الفشل: يصادق الوكيل على حسابك أنت على صندوق قد يصل إليه آخرون، وتبقى بيانات الاعتماد في سجل تلك الصدفة وإعداداتها. لا يوجد سجل يوضح أي مضيف يحتفظ بأي مفاتيح.
أبقِ التشغيل حيًا بعد انتهاء جلسة SSH:
tmux new -s agent
claude # start the long task
# Ctrl-b d to detach, close the laptop, reconnect later
tmux attach -t agent
نمط الفشل: يصمد tmux أمام انقطاع اتصال SSH، لكنه لا يصمد أمام إعادة تشغيل الخادم، أو قتل العملية بسبب نفاد الذاكرة، أو نسيانك أي جلسة من ست جلسات على أي خادم من ثلاثة تحمل التشغيل الذي يهمك. فصل الجلسة ليس كالاستدامة.
استرجع النتائج واطّلع على ما حدث:
scp you@build-server:~/your-repo/CHANGES.md .
ssh you@build-server 'cd your-repo && git diff'
نمط الفشل: الفرق موجود على الصندوق؛ والتفكير في مخزن سجل مُقتطع مسبقًا؛ و«السبب» ضاع. اضرب هذا في وكيلين على مضيفين، وستعيد بناء الحالة يدويًا في كل مرة تطّلع فيها.
لا شيء من هذه الخطوات صعب. المشكلة أنها لا تتكامل. كل مضيف جديد وكل وكيل جديد يمثل هدف SSH آخر، وجلسة tmux أخرى، ومكانًا آخر يعيش فيه سرّ ما، وسجلًا آخر عليك قراءته للإجابة عن سؤال «هل انتهى؟».
ما الذي يغيّره Computer متصل
Sharkly يسمّي الشيء الذي كنت ترتجله. Computer هو جهاز متصل أو خادم أو حاوية يشغّل فيها Agent العمل؛ فهو يوفر نظام التشغيل والملفات وبيانات الاعتماد والوصول إلى الشبكة والأدوات التي يحتاجها Agent. يشمل هذا التعريف خياراتك الثلاثة كلها: «يمكن أن يكون حاسوبًا محليًا، أو خادمًا بعيدًا، أو حاوية، أو مضيفًا سحابيًا مدعومًا».
تسجّل المضيف مرة واحدة بدلًا من الدخول إليه عبر SSH في كل مرة. أنشئ رمز تثبيت لمرة واحدة من Settings، Computers على الجهاز المستهدف، ثم نفّذ:
sharkly computer register --install-token <install-token>
الرمز قصير الأجل وللاستخدام مرة واحدة، لذا لا مكان له في صورة أو نص برمجي. بعد ذلك، تعمل خدمة محلية خلفية على Computer. فهي تسجّل المضيف، وتكتشف أدوات الوكيل المثبتة وتُبلّغ عن كل منها كـ Runtime، وترسل نبضات الحياة، وتستقبل التشغيلات المصطفّة، وتجهّز المجلدات، وتبلّغ عن التقدم والنتائج.
ثمة حدّان يجدر ذكرهما بوضوح، لأنهما موضع الافتراضات الخاطئة. أولًا، الخدمة المحلية هي التي تبدأ الاتصال بالخادم، لذا لا يتطلب الإعداد المعتاد منفذًا واردًا؛ فأنت لا تفتح صندوق البناء لديك على الإنترنت. ثانيًا، ظهور Computer بحالة Online يعني فقط أن خدمته المحلية ترسل نبضات الحياة. لا يعني أن Runtime قادر على تنفيذ Task. إذا لم يبدأ التشغيل على مضيف متصل، فتحقق من حالة قدرات Runtime قبل أن تلمس الشبكة.
من هنا يصبح لأنماط الفشل السابقة عناوين. بيانات الاعتماد تخص المضيف وتقتصر عليه. والتشغيل يبقى حيًا بعد انتهاء طرفيتك لأن الخدمة المحلية تملكه، لا جلسة tmux. أما الفرق والملخص والتفكير فتعود إلى Task بدلًا من أن تبقى في مخزن سجل على صندوق عليك الدخول إليه عبر SSH.
حاسوب محمول أم خادم أم الاثنان: كيف تختار فعليًا
المزيد من المضيفين ليس أفضل تلقائيًا، لذا اختر حسب طبيعة العمل.
استخدم حاسوبك المحمول حين تكون المهمة قصيرة وتفاعلية وتريد متابعتها. سجّله كـ Computer شخصي، وفي Sharkly Desktop فعّل Prevent sleep كي لا تُقطع مهمة سريعة بسبب نوم النظام. لاحظ أن Prevent sleep يظهر فقط على الجهاز المحلي في تطبيق سطح المكتب؛ وهو غير متاح على Computer مشترك أو بعيد. إذا كانت كل أعمالك تنتهي خلال استراحة قهوة ولا تحتاج أبدًا إلى الصمود بعد إغلاق الغطاء، فأنت لا تحتاج خادمًا بعد، وإضافته مجرد صيانة ستستثقلها.
استخدم خادمًا بعيدًا حين تكون المهام طويلة، أو تحتاج نوى أكثر، أو لا ينبغي أن تتنافس مع محررك على الموارد. مضيف Linux مسجَّل أو جهاز افتراضي سحابي يبقى مستيقظًا افتراضيًا ويمنح الوكلاء المتوازيين مساحة للعمل. وهنا أيضًا يبرز حدّ التزامن للمهام لكل مضيف في Computer، ورؤية Organization أو Space: فالصندوق وبيانات اعتماده مقصودان للمشاركة، وSharkly يتعامل معهما على هذا الأساس.
استخدم الاثنين حين تريد التعديلات التفاعلية محليًا والتشغيلات الثقيلة عن بُعد دون الاحتفاظ بنموذجين ذهنيين. سجّل الحاسوب المحمول والخادم، ثم أسنِد كل Task إلى Computer وRuntime المناسبين. وعزل worktree الذي يمنع تصادم الوكلاء المتوازيين يعمل بالطريقة نفسها سواء تقاسم الوكلاء مضيفًا واحدًا أو امتدوا على عدة مضيفات، لذا فإن خيار «الاثنين» يكلفك الاختيار فقط، لا سير عمل ثانيًا.
أين يتوقف التنفيذ الذاتي عن التوسع، وما الذي يضيفه لوح المهام
إعداد SSH وtmux يفي بالغرض لوكيل واحد على مضيف واحد. لكنه يتوقف في اللحظة التي تملك فيها عدة وكلاء على عدة أجهزة، لأنه لا توجد إجابة مشتركة عن «أي وكيل على أي شيء، وما الذي انتهى، وما الذي فشل، وما الذي يحتاج مراجعتي». هذا السؤال هو السبب الكامل وراء تشغيل أكثر من وكيل في الوقت نفسه، وهو بالضبط ما لا تستطيع كومة من الطرفيات الإجابة عنه.
لوح المهام يغيّر الوحدة من «جلسة على مضيف» إلى «Task له سجل». يبحث الوكلاء وينفذون ويختبرون ويُبلّغون؛ أما البشر فيحددون الاتجاه ويمنحون الصلاحية ويقبلون النتيجة. يعود التنفيذ والعوائق والنتائج والنقاش اللاحق إلى الجدول الزمني لـ Task، فتصبح متابعة تشغيل بعيد فتح Task، لا الدخول عبر SSH إلى تخمين. وتتوقف الأتمتة عند حدود الحكم البشري: يسلّمك الوكيل تغييرًا مع ملخصه وأدلته، ويبقى قرار الدمج والإصدار لك.
هذا هو الخط الفاصل بين المقاربتين. التنفيذ الذاتي يشغّل الوكيل عن بُعد. أما لوح المهام فيُبقي السياق والتقدم والعوائق والنتائج والمراجعة البشرية ظاهرة من الطلب حتى الإصدار، أيًا كان المضيف الذي قام بالعمل.
قائمة التحقق التي يمكنك تنفيذها اليوم
اعمل على هذه القائمة بالتتابع على أي مضيفات تخطط لاستخدامها:
- [ ] اختر مضيفاتك بصدق: الحاسوب المحمول للتفاعلي، والخادم للطويل أو المتوازي، والاثنان إن كنت تحتاجهما فعلاً.
- [ ] ثبّت Runtime وكيل مدعومًا على كل مضيف وصادقه على اشتراكك أو مفتاح API الخاص بك.
- [ ] سجّل كل مضيف مرة واحدة باستخدام
sharkly computer register --install-token <token>بدلًا من الدخول عبر SSH لكل تشغيل. - [ ] تأكد من ظهور كل Computer بحالة Online و وجود Runtime واحد على الأقل يُبلّغ عن حالة Available؛ فالاتصال وحده لن يشغّل Task.
- [ ] اضبط رؤية Computer على Personal لحاسوبك المحمول، وOrganization أو Space للخادم المشترك.
- [ ] فعّل Prevent sleep على الحاسوب المحمول للتشغيلات التي يجب أن تصمد بعد إغلاق الغطاء.
- [ ] أسنِد مهمة صغيرة ومملة إلى مضيف بعيد وتأكد من أن النتيجة تعود إلى Task، لا إلى مخزن سجل.
- [ ] استخدم
sharkly computer listوsharkly daemon disk-usageلمتابعة المضيفات واستعادة المساحة.
يمكنك بناء الإعداد البعيد يدويًا باستخدام SSH وtmux وworktrees، أو يمكنك تسجيل مضيفاتك الحالية كـ Computers وترك الخدمة المحلية تتولى التشغيلات. إذا كنت تشغّل بالفعل عدة وكلاء برمجيين عبر أكثر من جهاز، فإن Sharkly يمنحك مكانًا واحدًا لإدارة مهامهم ونتائجهم. اربط Computer واحدًا، وأنشئ Agent واحدًا، وأسنِد إليه مهمة مملة أولًا.
