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

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

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

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

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

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

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

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

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

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

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

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

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

المشهد اعتبارًا من July 2026

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

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

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 على الجهاز بعد ذلك، وتأكد من عدم وجود مفتاح خاص فيه.

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

بالنسبة إلى مفاتيح API، امنح الوكيل مفتاحًا خاصًا به مع حد إنفاق خاص به، وخزّنه في ملف يملكه المستخدم agent وبالوضع 600. عند تدمير الجهاز، ألغِ ذلك المفتاح بدلاً من التساؤل عما إذا كان قد تسرّب. كما أن إبقاء الإنفاق على النماذج ظاهرًا لكل مفتاح هو ما يجعل الأرقام الواردة في التحكم في تكلفة وكيل الذكاء الاصطناعي على 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. تحتاج قائمة السماح الحقيقية بالنطاقات إلى تمرير حركة الشبكة عبر وكيل يقرأ اسم المضيف المطلوب، وهذا يتطلب مكونات أكثر مما تريده معظم إعدادات المطورين الفردية. لا تدّعِ إلا ما توفره فعلًا: التحكم في الاتصالات الصادرة على مستوى المنافذ، على جهاز كنت مستعدًا لفقدانه.

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

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

الخيار البسيط هو إجراء checkout جديد لكل مهمة.

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

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

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

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

متى يكون الحاسوب المحمول مناسبًا فعلًا مع اتخاذ الاحتياطات

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

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

يتغير القرار فورًا عندما تتجاوز المطالبات. فالتشغيل دون إشراف، والمهام الليلية، وأي سير عمل توافق فيه على خطة ثم تبتعد، كلها تلغي المراجعة البشرية التي كانت توفر الاحتواء. عندها يجب أن يتولى الجهاز هذه المهمة بدلًا منك. وينطبق الأمر نفسه على أي شيء يوسع نطاق وصول الوكيل، بما في ذلك تشغيل وكيل برمجي على 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 على ذلك الخادم يستطيع استخدام المقبس المُعاد توجيهه أثناء اتصالك، لذا استخدم مفتاح نشر مخصصًا لمستودع معين على أي جهاز تشاركه مع أشخاص آخرين.

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

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

كم مرة ينبغي أن أتلف الجهاز وأعيد بناءه؟

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