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

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

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

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

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

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

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

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

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

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

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

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

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

المشهد في يوليو 2026

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

آلة افتراضية محلية صغيرة. تشغّل الأدوات في هذه الفئة آلة افتراضية حقيقية على أجهزتك، وتربط مستودعك بها، وتمنح الوكيل صلاحيات root داخلها. يُعد clawk المثال الحالي، وفكرته تطابق أطروحة هذا المنشور تماماً: امنح وكلاء البرمجة آلة افتراضية Linux مؤقتة، لا حاسوبك المحمول. اعتباراً من يوليو 2026، يستهدف clawk نظام 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 cat /home/you/.ssh/id_ed25519

ينبغي أن ترى cat: /home/you/.ssh/id_ed25519: Permission denied. إذا رأيت مواد المفاتيح بدلاً من ذلك، فإن الدليل الرئيسي مضبوط على الوضع 755، والعزل غير فعلي بعد. أصلح ذلك باستخدام sudo chmod 700 /home/you.

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

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

بالنسبة إلى 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 port 80: Connection refused، لأن قاعدة الرفض تستجيب فوراً بدلاً من ترك الاتصال معلّقاً. ويُفترض أن يظل طلب 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 في 14 August 2026، وبعد أن لا يطلب التثبيت الجديد الإذن قبل تعديل الملفات أو تشغيل الأوامر. تؤدي عمليات التشغيل غير المراقبة، والمهام الليلية، وأي سير عمل توافق فيه على خطة ثم تبتعد، إلى إزالة التحقق البشري الذي كان يحدّ من الضرر. عندها يجب أن يتولى الجهاز هذه المهمة بدلاً منك. وينطبق الأمر نفسه على أي شيء يوسّع نطاق وصول الوكيل، بما في ذلك تشغيل وكيل برمجي على VPS عبر عدة مستودعات في الوقت نفسه.

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

FAQ

هل تكفي الحاوية لتوفير عزل لوكيل برمجي؟

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

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

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

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

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

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

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

كم مرة ينبغي أن أدمر الآلة وأعيد بناءها؟

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