لماذا تمنح وكيل البرمجة آلة VM مؤقتة؟

لماذا تتفوق آلة VM مؤقتة على حاسوبك المحمول

امنح وكيل البرمجة آلة VM مؤقتة، وأسوأ ما يمكنه فعله هو تدمير آلة يمكنك إعادة بنائها خلال عشر دقائق. سيظل الوكيل يحصل على root، ويثبت الحزم، ويشغّل مجموعة الاختبارات من دون أن يطلب الإذن لكل خطوة. يكمن الاختلاف في المكان الذي يقع فيه الضرر. على الحاسوب المحمول، يشارك الوكيل الدليل المنزلي مع مفاتيح SSH، وملف تعريف المتصفح، وملفات .env، وكل مستودع آخر سبق لك استنساخه. أما على خادم مؤقت، فلديه shell ونسخة checkout، ولا شيء آخر يستحق السرقة.

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

حدّد نطاق الضرر قبل أن تجادل بشأنه

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

تشمل ~/.ssh/id_ed25519، الذي يكون عادةً غير مشفّر لأنك سئمت من كتابة عبارة المرور. وتشمل ~/.aws/credentials و~/.config/gh/hosts.yml، وهما نصّان عاديان بحكم التصميم. وتشمل كل مستودع شقيق ضمن ~/code، بما في ذلك المستودعات التي تحتوي على سلاسل اتصال الإنتاج في ملف بيئة محلي. وتشمل أيضاً سجل الصدفة، الذي يحتفظ بالرموز التي لصقتها مرة واحدة. كما تشمل الشبكة المتصل بها حاسوبك المحمول، وهي غالباً شبكة منزلية أو مكتبية تحتوي على خدمات لا تتطلب مصادقة.

لا يتطلب أي من ذلك وجود وكيل خبيث. يكفي أمر واحد خاطئ بثقة. استخدام rm -rf "$BUILD_DIR"/* مع عدم تعيين BUILD_DIR، ما يؤدي إلى التوسّع إلى /* ويمرّر الأمر عبر رفض GNU rm الافتراضي لحذف / نفسه، أو تنفيذ git clean -xfd في الدليل الخطأ، أو استخدام docker system prune -af --volumes الذي يحذف قاعدة بياناتك المحلية معه، أو تشغيل chmod -R 777 مفيد ظاهرياً على دليل المنزل. تتدرب الوكلاء على الإنترنت نفسه الذي علّم هذه الأوامر للجميع.

الآلية التي تحميك ليست حكم الوكيل. بل إن الجهاز الذي يحتوي الضرر هو جهاز كنت مستعداً لخسارته.

حساب التكلفة ممل، وهذا هو الهدف

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

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

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

المشهد اعتباراً من أكتوبر 2026

هناك ثلاث إجابات صادقة عن سؤال «أين يجب أن يعمل الوكيل؟». وهي توازن بين عاملين نفسيهما: قوة العزل، ومقدار الإعداد الذي تقبله.

آلة افتراضية محلية صغيرة. تشغّل الأدوات في هذه الفئة آلة افتراضية حقيقية على أجهزتك، وتربط مستودعك بها، وتتيح للوكيل استخدام root داخلها. يُعد clawk المثال الحالي، وفكرته الأساسية هي أطروحة هذا المنشور تحديداً: وفّر لوكلاء البرمجة آلة Linux افتراضية مؤقتة، لا حاسوبك المحمول. اعتباراً من أكتوبر 2026، يستهدف macOS 14 والإصدارات الأحدث على Apple silicon، مع دعم تجريبي لـLinux عبر Firecracker، ويُثبَّت باستخدام brew install clawkwork/tap/clawk. شغّل clawk داخل مستودع لإقلاع بيئة العزل وإرفاق وكيل بها، واستخدم clawk down لإيقافها، وclawk destroy لإزالتها. يعتمد العزل هنا على hypervisor، وهو عزل قوي. لكن الآلة الافتراضية تعمل على الجهاز الذي تحمله معك، ولذلك تنافس تطبيقاتك على الذاكرة وتتوقف عند إغلاق الغطاء.

حاوية. يُعد Docker الخيار المتاح لدى معظم المستخدمين، وهو مفيد فعلاً.

docker run --rm -it -v "$PWD:/work" -w /work --network none ubuntu:24.04 bash

يؤدي --rm إلى حذف الحاوية عند الخروج، بينما يمنحها --network none عدم وصول إلى الشبكة تماماً. وهذا إعداد افتراضي جيد لعملية بناء أو تشغيل اختبار. انتبه إلى ما لا يفعله هذا الإعداد: تشارك الحاوية نواة المضيف، ولذلك قد يتيح خلل في النواة الخروج منها. كما يختفي العزل بمجرد إضافة --privileged أو ربط /var/run/docker.sock كي يتمكن الوكيل من «استخدام Docker». ويعادل ربط Docker socket داخل حاوية منح تلك الحاوية صلاحيات root على المضيف.

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

نمط VPS: امنح الوكيل مستخدماً خاصاً به

ابدأ بخادم مُحصّن. يشرح الدقائق العشر الأولى على VPS جديد الأجزاء التي لا تخص الوكيل تحديداً: التحديثات، وتسجيل الدخول بغير root، وSSH باستخدام المفاتيح فقط، وجدار الحماية.

أنشئ بعد ذلك حساباً مخصصاً للوكيل وحده، حتى لا يتمكن خطأ داخل هذا الحساب من التأثير في أي شيء آخر على الخادم.

sudo adduser --disabled-password --gecos "" agent
sudo install -d -m 700 -o agent -g agent /home/agent/work
sudo -u agent -H bash -lc 'id; ls -la ~'

--disabled-password يعني عدم وجود كلمة مرور يمكن تخمينها، وأنك تصل إلى الحساب باستخدام sudo -u agent أو مفتاح SSH. لاحظ أن agent ليس عضواً في مجموعة sudo، وهذا مقصود. الوكيل الذي يملك sudo يملك صلاحيات root، ويمكن لـroot قراءة ملفات جميع المستخدمين الآخرين، لذلك يصبح العزل الذي أنشأته للتو شكلياً. إذا كان الوكيل يحتاج فعلاً إلى تثبيت الحزم، فهذا سبب لاستخدام خادم كامل مخصص له، وليس لمنحه sudo على خادم مشترك. تجد القواعد العامة في مبدأ أقل الصلاحيات لمستخدمي Linux على VPS.

تحقق من حدود العزل قبل أن تثق به. بصفتك المستخدم agent، حاول عرض محتويات الدليل الرئيسي لحسابك:

sudo -u agent ls /home/you

يجب أن ترى ls: cannot open directory '/home/you': Permission denied. إذا رأيت قائمة بالملفات بدلاً من ذلك، فهذا يعني أن المستخدمين الآخرين يستطيعون قراءة دليلك الرئيسي، وأن الوكيل يستطيع قراءة أي ملف فيه لم تُقيَّد صلاحياته بشكل منفصل، مثل ملف .env المقروء عالمياً. أصلح ذلك باستخدام sudo chmod 700 /home/you. لا يحمي هذا الاختبار مفتاح SSH الخاص بك: يتجاهل ssh ملف المفتاح الخاص الذي يستطيع المستخدمون الآخرون الوصول إليه، ولذلك فإن أي مفتاح يعمل معك غير قابل للقراءة أصلاً من جانب agent، مهما كانت صلاحيات دليلك الرئيسي.

أبقِ بيانات الاعتماد خارج الجهاز بالكامل

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

بالنسبة إلى git، مرّر SSH agent بدلاً من نسخ مفتاح. يبقى المفتاح الخاص على حاسوبك المحمول، ولا تعبر الاتصال إلا طلبات التوقيع.

ssh -A agent@203.0.113.10
ssh -T git@github.com

يجب أن يُظهر الأمر الثاني Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. يثبت ذلك أن git push سيعمل من دون وجود ملف مفتاح على الخادم. شغّل ls -la ~/.ssh على الجهاز بعد ذلك، وتأكد من عدم وجود مفتاح خاص فيه.

يوجد تحذير فعلي واحد بشأن تمرير SSH agent، لذا اذكره بوضوح: أثناء اتصالك، يمكن لأي شخص يملك صلاحيات root على ذلك الخادم استخدام المقبس المُمرَّر للمصادقة بهويتك. إذا كان المستخدم الآخر الوحيد على الخادم هو أنت، فهذه مقايضة مقبولة. أما على جهاز مشترك، فليست مقبولة، ويكون deploy key المقيّد بمستودع واحد خياراً أفضل. تتناول أساسيات إدارة مفاتيح SSH هذه الخيارات.

بالنسبة إلى مفاتيح API، امنح الوكيل مفتاحاً خاصاً به مع حد إنفاق خاص به، وخزّنه في ملف يملكه المستخدم agent وبالوضع 600. عند تدمير الجهاز، ألغِ ذلك المفتاح بدلاً من محاولة معرفة ما إذا كان قد تسرّب. كما أن إبقاء إنفاق النماذج ظاهراً لكل مفتاح هو ما يجعل الأرقام الواردة في التحكم في تكلفة وكيل AI على VPS قابلة للتنبؤ.

قيِّد ما يمكن للوكيل الوصول إليه عبر الشبكة

عزل نظام الملفات هو نصف الحد الفاصل. والنصف الآخر هو الاتصالات الصادرة: أي الجهات التي يُسمح للعملية بالاتصال بها. يستطيع Linux تصفية حركة البيانات الصادرة وفق المستخدم الذي أنشأها، وهذا يطابق هذا النمط تماماً.

sudo iptables -A OUTPUT -m owner --uid-owner agent -o lo -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p udp --dport 53 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -p tcp --dport 443 -j ACCEPT
sudo iptables -A OUTPUT -m owner --uid-owner agent -j REJECT

تُقرأ القواعد بالترتيب، لذلك يطابق REJECT الأخير كل ما لم تسمح به الأسطر السابقة. اختبر ذلك بصفتك الوكيل:

sudo -u agent curl -sS -m 5 http://example.com

يجب أن يفشل ذلك فوراً مع خطأ curl: (7) Failed to connect to example.com، ثم تظهر صياغة تختلف باختلاف إصدار curl لديك، لأن قاعدة الرفض تستجيب فوراً بدلاً من ترك الاتصال معلّقاً. ويجب أن يظل طلب HTTPS إلى المضيف نفسه ناجحاً.

هناك حدّان واضحان. أولاً، تُفقد هذه القواعد عند إعادة التشغيل التالية ما لم تحفظها باستخدام sudo apt install -y iptables-persistent ثم sudo netfilter-persistent save. ثانياً، تعمل هذه التصفية على المنافذ والعناوين، لا على الأسماء. تسمح قاعدة تتيح المنفذ 443 بالوصول إلى كل مضيف HTTPS على الإنترنت، وهذا يكفي للوصول إلى model API، ويكفي أيضاً للوصول إلى pastebin. يتطلب إنشاء قائمة سماح حقيقية للنطاقات تمرير حركة البيانات عبر proxy يقرأ اسم المضيف المطلوب، وهذا يضيف مكونات أكثر مما تريده معظم إعدادات المطور الواحد. اذكر فقط ما تملكه فعلاً: التحكم في الاتصالات الصادرة على مستوى المنافذ، على جهاز كنت مستعداً لفقدانه.

إعادة النظام إلى حالة نظيفة بين المهام

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

الخيار الأرخص هو إنشاء checkout جديد لكل مهمة.

sudo -u agent -H bash -lc 'rm -rf ~/work/repo && git clone git@github.com:you/repo.git ~/work/repo'

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

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

إذا أردت عدة بيئات معزولة دون دفع تكلفة عدة خوادم، فيمكن لـVPS أكبر واحد استضافة guest VMs مباشرة. يشرح الافتراضية المتداخلة على VPS طريقة عمل ذلك، بما في ذلك كيفية التحقق مما إذا كان مزوّد الخدمة يسمح بها. يعمل العزل في الاتجاهين هنا، وإذا كنت تفضّل أن ينسّق agentان على الجهاز نفسه بدل أن يبقيا معزولين عن بعضهما، فيمكن لـجلسة Claude Code واحدة إرسال النص مباشرة إلى جلسة أخرى بدل تمرير كل عملية تسليم عبرك.

متى يكون استخدام حاسوب محمول مزوّد بعزل مناسب آمناً فعلاً

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

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

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

لا يتعلق القرار فعلياً بمدى ثقتك بالنموذج. بل يتعلق بما يوجد بجانبه عندما يخطئ النموذج.

FAQ

هل يوفر container عزلاً كافياً لوكيل برمجي؟

نعم، في معظم الأعمال، بشرطين. يجب ألا يعمل container باستخدام --privileged، ويجب ألا يكون /var/run/docker.sock موصولاً به، لأن أيّاً منهما يمنح العملية مساراً إلى root على المضيف. يشترك container في نواة المضيف، لذلك يكون العزل أضعف من العزل الذي توفره آلة افتراضية. إذا كان الوكيل يشغّل تعليمة برمجية غير موثوقة جُلبت من الإنترنت، فاستخدم آلة افتراضية فعلية أو خادماً منفصلاً.

هل يحتاج الوكيل إلى sudo على الخادم؟

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

كيف أسمح للوكيل بإجراء push إلى git من دون وضع مفتاح SSH الخاص بي على الخادم؟

مرّر SSH agent باستخدام ssh -A عند الاتصال. تنتقل طلبات التوقيع عبر الاتصال، بينما يبقى المفتاح الخاص على حاسوبك المحمول، لذلك تُجري ssh -T git@github.com المصادقة ويعمل git push من دون وجود مفتاح خاص على الخادم. لكن root على ذلك الخادم يستطيع استخدام المقبس المُمرَّر أثناء اتصالك. لذلك استخدم deploy key مقيداً بمستودع معين على أي آلة تتشاركها مع أشخاص آخرين.

ما حجم VPS الذي يحتاج إليه الوكيل؟

تتركز أعمال الوكيل في تحرير الملفات وتشغيل عمليات البناء والاختبارات، لذلك حدّد حجم الآلة وفق متطلبات البناء، لا وفق النموذج. يعمل النموذج المستضاف على أجهزة موفر الخدمة، ما يضيف network traffic ولا يسبب تقريباً أي حمل محلي. لكن الوكيل نفسه يفرض حداً أدنى للموارد. اعتباراً من October 20, 2026، تسرد متطلبات النظام في Claude Code سعة 4 GB من RAM بوصفها الحد الأدنى. ابدأ بسعة 4 GB حتى في أعمال البرمجة النصية، وانتقل إلى 8 GB إذا كان المستودع يبني containers أو يترجم مكونات كبيرة.

كم مرة ينبغي لي تدمير الآلة وإعادة بنائها؟

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