Cara guna VM pakai buang untuk ejen pengekodan AI

Mengapa VM pakai buang lebih baik daripada komputer riba anda

Berikan ejen pengekodan sebuah VM pakai buang dan perkara paling buruk yang boleh dilakukannya ialah memusnahkan mesin yang boleh anda bina semula dalam masa sepuluh minit. Ejen tersebut masih mendapat akses root, masih memasang pakej, dan masih menjalankan suite ujian tanpa perlu meminta kebenaran bagi setiap langkah. Perbezaannya terletak pada lokasi kerosakan tersebut berlaku. Pada komputer riba, ejen itu berkongsi direktori home dengan kunci SSH anda, profil pelayar, fail .env anda, dan setiap repositori lain yang pernah anda klon. Pada pelayan pakai buang, ia hanya mempunyai shell, satu checkout, dan tiada apa-apa lagi yang berbaloi untuk diambil.

Itulah keseluruhan hujah tersebut, dan ia merupakan hujah mengenai asimetri dan bukannya kebarangkalian. Ejen yang berhati-hati pada komputer riba yang dikendalikan dengan cermat hampir selalu selamat. Pada satu ketika ia tidak selamat, kosnya bukanlah sekadar commit yang buruk. Ia adalah pemulihan daripada sandaran (backup), jika anda memilikinya.

Tentukan radius letupan sebelum anda berhujah mengenainya

Radius letupan bermaksud set perkara yang boleh dicapai oleh sesuatu proses. Bagi ejen yang berjalan sebagai pengguna biasa pada mesin biasa anda, set tersebut adalah lebih besar daripada yang dibayangkan oleh kebanyakan orang.

Ia termasuk ~/.ssh/id_ed25519, yang biasanya tidak disulitkan kerana anda sudah bosan menaip frasa laluan. Ia termasuk ~/.aws/credentials dan ~/.config/gh/hosts.yml, yang direka bentuk sebagai teks biasa. Ia termasuk setiap repositori adik-beradik di bawah ~/code, termasuk repositori yang mengandungi rentetan sambungan pengeluaran dalam fail env tempatan. Ia termasuk sejarah shell anda, yang menyimpan token yang pernah anda tampal. Ia juga termasuk rangkaian yang diduduki oleh komputer riba anda, yang selalunya merupakan rangkaian rumah atau pejabat dengan perkhidmatan yang tidak disahkan di dalamnya.

Tiada satu pun daripada perkara itu memerlukan ejen berniat jahat. Ia hanya memerlukan satu arahan yang salah tetapi dilakukan dengan yakin. rm -rf dengan pemboleh ubah yang tidak ditetapkan berkembang menjadi /, git clean -xfd dalam direktori yang salah, docker system prune -af --volumes yang membawa pangkalan data tempatan anda bersamanya, atau chmod -R 777 yang membantu pada direktori rumah. Ejen dilatih menggunakan internet yang sama yang mengajar arahan tersebut kepada orang lain.

Mekanisme yang menyelamatkan anda bukanlah pertimbangan ejen tersebut. Ia adalah hakikat bahawa mesin yang menanggung kerosakan itu adalah mesin yang anda sanggup untuk kehilangannya.

Pengiraan kos adalah membosankan, dan itulah tujuannya

VPS kecil berharga beberapa dolar sebulan. Memulihkan komputer riba pembangun mengambil masa sehari, itu pun dalam kes terbaik di mana anda menyedarinya dengan segera dan mempunyai sandaran.

Kira sendiri menggunakan angka anda. Ambil kadar bayaran sejam anda, darabkan dengan jumlah jam yang diperlukan untuk memasang semula sistem pengendalian, memulihkan direktori home, menukar kunci SSH, menukar token akses peribadi, dan mengklon semula dua puluh repositori. Bandingkan dengan kos dua belas bulan pelayan paling kecil yang dijual oleh penyedia anda. Titik pulang modal berada di bawah satu insiden bagi setiap beberapa tahun, dan insiden tersebut tidak perlu menjadi bencana untuk melepasi tahap ini. Satu petang yang hilang akibat persekitaran tempatan yang rosak sudah cukup untuk menampung kos setahun.

Bahagian kedua pengiraan ini ialah snapshot. Snapshot sebelum menjalankan operasi berisiko mengubah hasil buruk daripada "memulihkan seluruh hidup saya" kepada "buat rollback dan cuba arahan lain". Pilihan itu tidak wujud pada komputer riba yang anda gunakan sekarang, kerana anda tidak boleh membuat snapshot mesin semasa anda sedang menggunakannya sebagai meja kerja.

Landskap setakat Julai 2026

Terdapat tiga jawapan jujur bagi persoalan "di manakah ejen harus dijalankan", dan kesemuanya melibatkan pertukaran antara dua perkara: sejauh mana kuatnya sempadan keselamatan, dan berapa banyak persediaan yang anda sanggup lakukan.

Micro VM tempatan. Alat dalam kategori ini memulakan mesin maya sebenar pada perkakasan anda sendiri, melekapkan repositori anda ke dalamnya, dan memberikan akses root kepada ejen di dalam persekitaran tersebut. clawk ialah contoh semasa, dan tumpuan utamanya adalah tepat dengan tesis catatan ini: berikan ejen pengekodan sebuah VM Linux yang boleh dilupuskan, bukan komputer riba anda. Setakat Julai 2026, ia menyasarkan macOS 14 dan versi terkini pada Apple silicon, dengan sokongan Linux eksperimental melalui Firecracker, dan ia dipasang menggunakan brew install clawkwork/tap/clawk. Anda menjalankan clawk di dalam repositori untuk memulakan sandbox dan melampirkan ejen, clawk down untuk menghentikannya, dan clawk destroy untuk membuangnya. Sempadannya ialah hypervisor, yang merupakan tahap keselamatan yang kuat. Hadnya ialah VM tersebut hidup pada mesin yang anda bawa ke mana-mana, jadi ia bersaing untuk mendapatkan memori anda dan ia akan berhenti apabila anda menutup penutup komputer riba.

Kontena. Docker ialah jawapan yang kebanyakan orang sudah pasang, dan ia sememangnya berguna.

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

--rm membuang kontena tersebut semasa keluar dan --network none tidak memberikan sebarang akses rangkaian, yang merupakan tetapan lalai yang baik untuk binaan atau ujian. Fahami dengan jelas perkara yang tidak dilakukan oleh kaedah ini: kontena berkongsi kernel hos, jadi pepijat kernel adalah jalan keluar, dan sempadan tersebut hilang sebaik sahaja anda menambah --privileged atau melekapkan /var/run/docker.sock supaya ejen boleh "menggunakan Docker". Melekapkan soket Docker ke dalam kontena adalah setara dengan memberikan kontena tersebut akses root pada hos.

VPS biasa yang boleh dibina semula. Tiada alat baharu, sempadan kernel sebenar, snapshot pembekal, dan ia terus berjalan apabila anda menutup komputer riba anda. Ini adalah corak yang diterangkan oleh bahagian seterusnya dalam panduan ini, dan ia adalah corak yang bertahan untuk jangka masa ejen yang panjang, kerana tugasan yang mengambil masa empat jam tidak terjejas walaupun anda sudah pulang ke rumah.

Corak VPS: berikan ejen pengguna sendiri

Mulakan daripada pelayan yang telah diperkukuh. Sepuluh minit pertama pada VPS baharu merangkumi bahagian yang tidak khusus untuk ejen: kemas kini, log masuk bukan root, SSH berasaskan kunci sahaja, dan firewall.

Kemudian, cipta akaun yang wujud khusus untuk ejen tersebut, supaya kesilapan di dalamnya tidak menjejaskan bahagian lain pada pelayan.

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 bermaksud tiada kata laluan untuk diteka, dan anda mencapai akaun tersebut dengan sudo -u agent atau kunci SSH. Perhatikan bahawa agent sengaja tidak dimasukkan ke dalam kumpulan sudo. Ejen dengan sudo mempunyai akses root, dan root boleh membaca fail pengguna lain, jadi pengasingan yang baru anda bina hanyalah hiasan. Jika ejen benar-benar perlu memasang pakej, itu adalah alasan untuk menggunakan pelayan khusus, bukan dengan memberikan sudo pada pelayan yang dikongsi. Peraturan umum terdapat dalam prinsip keistimewaan minimum untuk pengguna Linux pada VPS.

Semak sempadan sebelum anda mempercayainya. Sebagai pengguna agent, cuba baca fail milik akaun anda sendiri:

sudo -u agent cat /home/you/.ssh/id_ed25519

Anda sepatutnya melihat cat: /home/you/.ssh/id_ed25519: Permission denied. Jika anda melihat kandungan kunci, direktori home anda berada dalam mod 755 dan pengasingan tersebut belum berkesan. Betulkannya dengan sudo chmod 700 /home/you.

Pastikan kelayakan tidak disimpan langsung pada mesin

Tujuan menggunakan mesin pakai buang akan sia-sia jika anda menyalin rahsia pengeluaran (production secrets) ke dalamnya. Peraturannya mudah: tiada apa-apa pun di dalam kotak itu yang merupakan kelayakan yang anda keberatan untuk ditukar pada petang ini.

Untuk git, lakukan forwarding pada SSH agent anda dan bukannya menyalin kunci. Kunci peribadi (private key) kekal pada komputer riba anda dan hanya permintaan tandatangan yang merentasi sambungan tersebut.

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

Perintah kedua sepatutnya menjawab Hi yourname! You've successfully authenticated, but GitHub does not provide shell access.. Ini membuktikan git push akan berfungsi tanpa fail kunci yang hadir pada pelayan. Jalankan ls -la ~/.ssh pada kotak tersebut selepas itu dan sahkan tiada kunci peribadi di dalamnya.

Agent forwarding mempunyai satu kaveat sebenar, jadi nyatakan dengan jelas: semasa anda disambungkan, sesiapa sahaja yang mempunyai akses root pada pelayan itu boleh menggunakan soket yang diforward untuk mengesahkan identiti sebagai anda. Pada pelayan yang pengguna lain hanyalah anda sendiri, itu adalah pertukaran yang boleh diterima. Pada kotak yang dikongsi, ia bukanlah pilihan yang baik, dan deploy key yang dihadkan kepada satu repositori adalah jawapan yang lebih tepat. Pilihan-pilihan ini diliputi dalam asas pengurusan kunci SSH.

Untuk kunci API, berikan ejen kunci sendiri dengan had perbelanjaan sendiri, yang disimpan dalam fail yang dimiliki oleh pengguna agent pada mod 600. Apabila mesin dimusnahkan, batalkan kunci tersebut daripada tertanya-tanya sama ada ia telah bocor. Memastikan perbelanjaan model dapat dilihat bagi setiap kunci juga merupakan cara angka dalam kawalan kos ejen AI pada VPS kekal boleh diramal.

Hadkan capaian ejen pada rangkaian

Pengasingan sistem fail hanyalah separuh daripada sempadan. Separuh lagi ialah egress: perkara yang dibenarkan untuk dihubungi oleh sesuatu proses. Linux boleh menapis trafik keluar mengikut pengguna yang menciptanya, yang menepati corak ini sepenuhnya.

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

Peraturan dibaca mengikut urutan, jadi REJECT terakhir akan menangkap segala yang tidak dibenarkan oleh baris sebelumnya. Uji peraturan ini sebagai ejen:

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

Tindakan tersebut sepatutnya gagal dengan curl: (7) Failed to connect to example.com port 80: Connection refused, kerana peraturan reject menjawab serta-merta dan tidak membiarkan sambungan tergantung. Permintaan HTTPS ke hos yang sama sepatutnya masih berjaya.

Dua had yang perlu diketahui. Pertama, peraturan ini akan hilang pada but semula seterusnya melainkan anda menyimpannya dengan sudo apt install -y iptables-persistent dan kemudian sudo netfilter-persistent save. Kedua, ini menapis port dan alamat, bukan nama. Peraturan yang membenarkan port 443 membenarkan setiap hos HTTPS di internet, yang mencukupi untuk mencapai API model dan juga mencukupi untuk mencapai pastebin. Senarai putih domain yang sebenar memerlukan trafik melalui proksi yang membaca nama hos yang diminta, yang merupakan mekanisme yang lebih kompleks daripada yang diinginkan oleh kebanyakan persediaan pembangun tunggal. Tuntut hanya apa yang anda miliki: kawalan egress peringkat port, pada mesin yang anda sudah bersedia untuk kehilangan.

Tetapan semula kepada keadaan bersih antara tugasan

Keadaan bersih bagi setiap tugasan merupakan manfaat yang sering dipandang remeh. Ejen yang menghabiskan masa tiga jam pada tiket sebelumnya meninggalkan pakej yang telah dipasang, migrasi yang separuh siap, node_modules yang lapuk, dan git working tree dengan perubahan yang tidak disemak oleh sesiapa. Tugasan seterusnya mewarisi semua itu, dan anda menghabiskan bajet semakan anda untuk menentukan kekacauan mana yang tergolong dalam larian yang mana. Ejen yang lebih khusus meninggalkan kesan yang lebih sedikit sejak awal lagi, jadi menggandingkan mesin pakai buang dengan kemahiran yang mendorong ejen ke arah perubahan terkecil yang berfungsi memastikan kedua-dua diff dan keadaan yang tertinggal cukup kecil untuk disemak.

Versi yang murah ialah melakukan checkout baharu bagi setiap tugasan.

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

Versi yang lebih mantap ialah snapshot penyedia yang diambil sekali, tepat selepas mesin disediakan dan sebelum sebarang ejen menyentuhnya. Memulihkan snapshot tersebut mengembalikan keseluruhan sistem, termasuk pakej, kepada keadaan yang diketahui. Kebanyakan penyedia mendedahkan perkara ini dalam panel kawalan atau melalui API dan bukannya sebagai arahan pada kotak, jadi langkah yang tepat bergantung pada penyedia anda. Disiplinnya adalah dengan mengambil snapshot semasa mesin masih dalam keadaan asal.

Jauhkan apa-apa yang anda pentingkan daripada mesin pakai buang tersebut, yang bermaksud menghantar cawangan (push branches) dan bukannya menyimpannya secara setempat. Jika kotak tersebut akhirnya menyimpan sesuatu yang anda akan rugi jika hilang, buat sandaran dengan betul menggunakan sandaran restic pada VPS. Mesin yang boleh anda musnahkan hanya berguna jika memusnahkannya benar-benar tidak mendatangkan masalah.

Jika anda mahukan beberapa persekitaran terasing tanpa perlu membayar untuk beberapa pelayan, satu VPS yang lebih besar boleh mengehoskan VM tetamu secara terus. Virtualisasi bersarang pada VPS merangkumi cara ia berfungsi, termasuk cara menyemak sama ada penyedia anda membenarkannya. Pengasingan berfungsi dua hala di sini, dan jika anda lebih suka dua ejen pada kotak yang sama berkoordinasi daripada duduk terasing antara satu sama lain, satu sesi Claude Code boleh menghantar teks terus kepada yang lain dan bukannya menghalakan setiap penyerahan melalui anda.

Apabila komputer riba yang dikendalikan dengan cermat sebenarnya selamat

Bersikap jujurlah mengenai perkara ini, kerana keterlaluan dalam menekankan pengasingan akan menyebabkan orang berhenti mendengar.

Jika anda menyemak setiap arahan sebelum ia dijalankan, komputer riba adalah selamat. Gesaan kebenaran (permission prompt) merupakan kawalan yang sebenar, dan menjalankan Claude Code dengan selamat pada pelayan menerangkan perkara yang disekat oleh setiap tahap kawalan tersebut. Jika kerja anda hanyalah satu repositori tunggal tanpa sebarang kelayakan pengeluaran (production credentials) pada mesin tersebut, radius impak sudah pun kecil. Jika sesi ejen anda singkat dan diselia, tempoh pendedahan juga adalah singkat.

Jawapannya berubah sebaik sahaja anda melangkau gesaan tersebut, perkara yang perlu difikirkan sekarang memandangkan mod auto menjadi tetapan lalai Claude Code pada 14 Ogos 2026 dan pemasangan baharu tidak lagi meminta kebenaran sebelum ia menyunting fail atau menjalankan arahan. Pelaksanaan tanpa pengawasan, tugasan semalaman, dan sebarang aliran kerja di mana anda meluluskan pelan lalu meninggalkannya, semuanya menghapuskan semakan manusia yang berfungsi sebagai pengurungan. Pada ketika itulah mesin perlu melakukannya sebagai ganti. Perkara yang sama terpakai kepada apa sahaja yang meluaskan capaian ejen, termasuk menjalankan ejen pengekodan pada VPS merentasi beberapa repositori serentak.

Keputusan ini sebenarnya bukan tentang sejauh mana anda mempercayai model tersebut. Ia adalah tentang apa yang berada di sisinya apabila model itu melakukan kesilapan.

FAQ

Adakah container memberikan pengasingan yang mencukupi untuk ejen pengekodan?

Bagi kebanyakan tugasan, ya, dengan dua syarat. Container tersebut tidak boleh dijalankan dengan --privileged, dan ia tidak boleh mempunyai /var/run/docker.sock yang dimount ke dalamnya, kerana kedua-duanya memberikan proses tersebut laluan untuk menjadi root pada hos. Container berkongsi kernel hos, jadi sempadannya lebih lemah berbanding mesin maya (VM). Jika ejen menjalankan kod yang tidak dipercayai yang diambil dari internet, gunakan VM sebenar atau pelayan berasingan.

Adakah ejen memerlukan sudo pada pelayan?

Tidak, dan memberikan sudo akan membatalkan pengasingan yang telah anda bina, kerana root boleh membaca setiap akaun lain pada mesin tersebut. Cipta pengguna ejen tanpa sudo dan berikan akses tulis hanya kepada direktori kerjanya sendiri. Jika tugasan benar-benar memerlukan pemasangan pakej, berikan ejen mesin penuh miliknya sendiri dan bukannya akses root pada mesin yang dikongsi.

Bagaimana saya membenarkan ejen melakukan push ke git tanpa meletakkan kunci SSH saya pada mesin tersebut?

Forward SSH agent anda dengan ssh -A apabila anda membuat sambungan. Permintaan tandatangan dihantar melalui sambungan tersebut manakala kunci peribadi kekal pada komputer riba anda, jadi ssh -T git@github.com mengesahkan identiti dan git push berfungsi tanpa kunci peribadi pada pelayan. Amaran: root pada pelayan tersebut boleh menggunakan soket yang diforward semasa anda bersambung, jadi gunakan deploy key yang terhad kepada repositori pada mana-mana mesin yang anda kongsi dengan orang lain.

Berapakah saiz VPS yang diperlukan oleh ejen?

Tugasan ejen kebanyakannya melibatkan penyuntingan fail, menjalankan binaan (build), dan menjalankan ujian, jadi tentukan saiz mesin berdasarkan keperluan binaan dan bukannya model. Model yang dihoskan berjalan pada perkakasan penyedia, yang menambah trafik rangkaian tetapi hampir tiada bebanan tempatan. Mulakan dengan 2 GB RAM untuk kerja skrip dan tingkatkan kepada 8 GB jika repositori tersebut membina container atau mengkompilasi sesuatu yang besar.

Berapa kerap saya perlu memusnahkan dan membina semula mesin?

Bina semula apabila keadaan sistem tidak lagi dapat dijelaskan, dan sekurang-kurangnya apabila terdapat kemungkinan kelayakan (credential) pada mesin tersebut terdedah. Melakukan checkout baharu antara tugasan dapat menangani perubahan kecil harian, dan snapshot yang diambil sebelum ejen dijalankan buat kali pertama memberikan anda imej sistem bersih untuk kembali semula. Jika proses membina semula terasa membebankan, itu adalah tanda bahawa sesuatu yang penting sedang disimpan pada mesin yang sepatutnya dianggap sebagai pakai buang.