Berikan Ejen Pengekodan VM Boleh Lupus

Mengapa VM boleh lupus lebih baik daripada komputer riba anda

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

Itulah keseluruhan hujahnya. Hujah ini berkaitan dengan ketaksimetrian, bukannya kebarangkalian. Ejen yang berhati-hati pada komputer riba yang dikendalikan dengan berhati-hati biasanya tidak menimbulkan masalah. Namun, apabila masalah berlaku, kosnya bukan sekadar commit yang buruk. Anda perlu memulihkan sistem daripada sandaran, jika anda mempunyai sandaran.

Namakan radius kesan sebelum anda mempertikaikannya

Radius kesan ialah set perkara yang boleh dicapai oleh sesuatu proses. Bagi ejen yang berjalan sebagai pengguna biasa anda pada mesin biasa anda, set itu lebih besar daripada gambaran 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 sememangnya direka bentuk sebagai teks biasa. Ia termasuk setiap repositori seinduk di bawah ~/code, termasuk repositori yang mempunyai rentetan sambungan pengeluaran dalam fail env tempatan. Ia juga termasuk sejarah shell anda, yang mengandungi token yang pernah anda tampal. Ia turut termasuk rangkaian tempat komputer riba anda disambungkan, yang selalunya ialah rangkaian rumah atau pejabat dengan perkhidmatan tanpa pengesahan padanya.

Semua itu tidak memerlukan ejen berniat jahat. Satu arahan yang salah dengan penuh keyakinan sudah memadai. rm -rf dengan pemboleh ubah yang tidak ditetapkan berkembang menjadi /, git clean -xfd dalam direktori yang salah, docker system prune -af --volumes yang turut memadam pangkalan data tempatan anda, atau chmod -R 777 yang membantu dalam direktori rumah. Ejen dilatih menggunakan internet yang sama, yang mengajar arahan tersebut kepada orang lain.

Mekanisme yang melindungi anda bukan pertimbangan ejen. Sebaliknya, mesin yang menanggung kerosakan itu ialah mesin yang anda sanggup kehilangan.

Pengiraan kos memang membosankan, dan itulah tujuannya

VPS kecil berharga beberapa dolar sebulan. Memulihkan komputer riba pembangun mengambil masa sehari, dan itu ialah keadaan yang baik, apabila anda menyedarinya dengan segera serta mempunyai sandaran.

Buat pengiraan menggunakan angka anda sendiri. Ambil kadar sejam anda dan darabkan dengan jumlah jam yang diperlukan untuk memasang semula sistem pengendalian, memulihkan direktori rumah, menggilirkan kunci SSH, menggilirkan token akses peribadi, serta mengklon semula dua puluh repositori. Bandingkan jumlah itu dengan kos selama dua belas bulan bagi pelayan terkecil yang ditawarkan oleh penyedia anda. Titik pulang modal adalah kurang daripada satu insiden dalam tempoh beberapa tahun, dan insiden itu tidak perlu menjadi bencana untuk melepasi jumlah tersebut. Kehilangan satu petang akibat persekitaran setempat yang rosak sudah cukup untuk menampung kos setahun.

Separuh lagi pengiraan itu berkaitan dengan snapshot. Snapshot sebelum pelaksanaan berisiko mengubah hasil yang buruk daripada "pulihkan seluruh persekitaran saya" kepada "kembalikan keadaan dan cuba prompt yang berbeza". Pilihan itu tidak tersedia pada komputer riba yang anda gunakan untuk menaip ini, kerana anda tidak boleh membuat snapshot pada mesin yang sedang digunakan sebagai tempat kerja anda.

Keadaan setakat Julai 2026

Terdapat tiga jawapan yang munasabah untuk soalan "di manakah ejen patut dijalankan", dan semuanya melibatkan pertukaran antara dua perkara yang sama: kekuatan sempadan pengasingan dan jumlah persediaan yang sanggup anda lakukan.

Mikro VM tempatan. Alat dalam kategori ini memulakan mesin maya sebenar pada perkakasan anda sendiri, memasang repositori anda ke dalamnya dan membenarkan ejen mempunyai akses root di dalam mesin maya tersebut. clawk ialah contoh semasa, dan cadangannya selaras dengan tesis siaran ini: berikan ejen pengekodan VM Linux yang boleh dilupuskan, bukan komputer riba anda. Setakat Julai 2026, alat ini menyasarkan macOS 14 dan versi lebih baharu pada Apple silicon, dengan sokongan Linux percubaan melalui Firecracker, dan dipasang menggunakan brew install clawkwork/tap/clawk. Jalankan clawk dalam repositori untuk memulakan kotak pasir dan melampirkan ejen, clawk down untuk menghentikannya dan clawk destroy untuk mengalih keluarnya. Sempadan pengasingannya ialah hipervisor, yang kukuh. Hadnya ialah VM tersebut berada pada mesin yang anda bawa bersama, jadi ia menggunakan memori anda dan berhenti apabila anda menutup komputer riba.

Bekas. Docker ialah pilihan yang kebanyakan orang sudah pasang, dan ia memang berguna.

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

--rm membuang bekas apabila keluar, manakala --network none tidak memberikan bekas itu sebarang akses rangkaian. Ini ialah tetapan lalai yang baik untuk binaan atau pelaksanaan ujian. Fahami perkara yang tidak dilakukan oleh pendekatan ini: bekas berkongsi kernel hos, jadi pepijat kernel boleh menjadi laluan keluar, dan sempadan pengasingan hilang sebaik sahaja anda menambah --privileged atau memasang /var/run/docker.sock supaya ejen boleh "menggunakan Docker". Memasang soket Docker ke dalam bekas bersamaan dengan memberikan bekas itu akses root pada hos.

VPS biasa yang boleh dibina semula. Tiada alat baharu diperlukan, terdapat sempadan kernel sebenar dan syot kilat penyedia, serta ia terus berjalan apabila anda menutup komputer riba. Inilah corak yang diterangkan oleh panduan ini, dan corak ini sesuai untuk pelaksanaan ejen yang lama kerana kerja yang mengambil masa empat jam tidak terjejas walaupun anda sudah pulang.

Corak VPS: berikan ejen pengguna sendiri

Mulakan dengan pelayan yang telah dikukuhkan. sepuluh minit pertama pada VPS baharu merangkumi perkara yang tidak khusus kepada ejen: kemas kini, log masuk bukan root, SSH dengan kunci sahaja dan tembok api.

Kemudian buat akaun yang hanya digunakan oleh ejen. Dengan cara ini, kesilapan dalam akaun tersebut tidak boleh menjejaskan perkara 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 mengakses akaun itu menggunakan sudo -u agent atau kunci SSH. Perhatikan bahawa agent sengaja tidak berada dalam kumpulan sudo. Ejen dengan sudo mempunyai akses root, dan root boleh membaca fail semua pengguna lain. Maka, pengasingan yang baru anda bina hanya bersifat luaran. Jika ejen benar-benar perlu memasang pakej, itu ialah alasan untuk menggunakan seluruh pelayan yang dimilikinya, bukan untuk memberikannya sudo pada pelayan yang dikongsi. Peraturan umum diterangkan dalam keistimewaan minimum untuk pengguna Linux pada VPS.

Uji sempadan tersebut sebelum 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 bahan kunci, direktori rumah anda mempunyai mod 755 dan pengasingan itu belum benar-benar berfungsi. Betulkan dengan sudo chmod 700 /home/you.

Jangan simpan bukti kelayakan pada mesin sama sekali

Tujuan menggunakan mesin sementara akan gagal jika anda menyalin rahsia pengeluaran ke dalamnya. Peraturannya mudah: tiada apa-apa pada mesin itu boleh menjadi bukti kelayakan yang anda keberatan untuk menukarnya pada petang ini.

Untuk git, majukan ejen SSH anda dan bukannya menyalin kunci. Kunci persendirian kekal pada komputer riba anda, manakala hanya permintaan tandatangan merentasi sambungan.

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

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

Pemajuan ejen mempunyai satu risiko sebenar, jadi nyatakan dengan jelas: semasa anda disambungkan, sesiapa yang mempunyai akses root pada pelayan itu boleh menggunakan soket yang dimajukan untuk mengesahkan identiti sebagai anda. Pada pelayan yang hanya mempunyai anda sebagai pengguna lain, pertukaran ini boleh diterima. Pada mesin yang dikongsi, ia tidak boleh diterima, dan kunci deployment yang terhad kepada satu repositori ialah pilihan yang lebih baik. Pilihan ini diterangkan dalam Asas pengurusan kunci SSH.

Untuk kunci API, berikan ejen itu kunci sendiri dengan had perbelanjaan sendiri, yang disimpan dalam fail milik pengguna agent dengan mod 600. Apabila mesin itu dimusnahkan, batalkan kunci tersebut dan bukannya tertanya-tanya sama ada kunci itu telah bocor. Memastikan perbelanjaan model kelihatan bagi setiap kunci juga merupakan cara angka dalam Kawalan kos ejen AI pada VPS kekal boleh dijangka.

Hadkan perkara yang boleh dicapai oleh ejen melalui rangkaian

Pengasingan sistem fail hanya merangkumi separuh daripada sempadan. Separuh lagi ialah egress: destinasi yang boleh dihubungi oleh proses. Linux boleh menapis trafik keluar berdasarkan pengguna yang menciptanya, dan ini sepadan dengan corak tersebut.

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 turutan, jadi REJECT terakhir menangkap semua perkara yang tidak dibenarkan oleh baris sebelumnya. Ujinya sebagai ejen:

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

Percubaan itu sepatutnya gagal dengan curl: (7) Failed to connect to example.com port 80: Connection refused kerana peraturan reject memberikan jawapan serta-merta dan bukannya membiarkan sambungan tergantung. Permintaan HTTPS kepada hos yang sama sepatutnya masih berjaya.

Terdapat dua batasan yang perlu dinyatakan. Pertama, peraturan ini hilang selepas but semula seterusnya jika anda tidak menyimpannya menggunakan sudo apt install -y iptables-persistent dan kemudian sudo netfilter-persistent save. Kedua, penapisan ini hanya meliputi port dan alamat, bukan nama. Peraturan yang membenarkan port 443 membenarkan setiap hos HTTPS di internet. Ini mencukupi untuk mencapai API model, tetapi juga membolehkan capaian kepada pastebin. Senarai benarkan domain sebenar memerlukan trafik melalui proksi yang membaca nama hos yang diminta. Konfigurasi ini lebih rumit daripada yang biasanya dikehendaki oleh kebanyakan persediaan pembangun tunggal. Nyatakan hanya perkara yang benar-benar anda sediakan: kawalan egress pada peringkat port, pada mesin yang anda bersedia untuk kehilangan.

Tetapkan semula keadaan bersih antara tugas

Keadaan bersih bagi setiap tugas ialah manfaat yang sering dipandang rendah. Ejen yang menghabiskan tiga jam untuk tiket sebelumnya mungkin telah meninggalkan pakej yang dipasang, migrasi yang dilaksanakan separuh, node_modules yang lapuk dan working tree git dengan perubahan yang belum disemak oleh sesiapa. Tugas seterusnya mewarisi semua itu, dan anda menggunakan peruntukan masa semakan untuk menentukan masalah yang berkaitan dengan setiap pelaksanaan.

Cara yang mudah ialah menggunakan checkout baharu bagi setiap tugas.

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

Cara yang lebih kukuh ialah mengambil snapshot provider sekali, sejurus selepas mesin disediakan dan sebelum mana-mana ejen menggunakannya. Pemulihan snapshot itu mengembalikan keseluruhan sistem, termasuk pakej, kepada keadaan yang diketahui. Kebanyakan provider menyediakan fungsi ini dalam panel kawalan atau melalui API, bukannya sebagai arahan pada mesin tersebut. Oleh itu, langkah tepat bergantung pada provider anda. Amalan penting ialah mengambil snapshot ketika mesin masih belum mengalami perubahan.

Simpan apa-apa yang penting kepada anda di luar mesin pakai buang itu. Biasanya, ini bermaksud menolak branch dan bukannya menyimpannya secara berlebihan secara setempat. Jika mesin itu akhirnya menyimpan sesuatu yang akan anda kehilangan, buat sandaran dengan betul menggunakan sandaran restic pada VPS. Mesin yang boleh anda musnahkan hanya berguna jika proses pemusnahannya benar-benar tidak menimbulkan masalah.

Jika anda mahukan beberapa persekitaran terasing tanpa membayar beberapa server, satu VPS yang lebih besar boleh mengehos VM tetamu secara terus. Virtualisasi bersarang pada VPS menerangkan cara fungsi ini beroperasi, termasuk cara menyemak sama ada provider anda membenarkannya.

Apabila komputer riba benar-benar memadai dengan langkah berjaga-jaga

Jelaskan perkara ini dengan jujur. Tuntutan pengasingan yang berlebihan menyebabkan orang tidak lagi memberi perhatian.

Jika anda menyemak setiap perintah sebelum perintah itu dijalankan, komputer riba memadai. Gesaan kebenaran ialah kawalan sebenar, dan menjalankan Claude Code dengan selamat pada pelayan menerangkan perkara yang sebenarnya disekat oleh setiap tahap kawalan itu. Jika kerja anda hanya melibatkan satu repositori dan tiada bukti kelayakan pengeluaran pada komputer tersebut, skop kesannya sudah kecil. Jika sesi ejen anda singkat dan dipantau, tempoh pendedahan juga singkat.

Keadaan berubah sebaik sahaja anda melangkau gesaan. Pelaksanaan tanpa pengawasan, tugas semalaman dan apa-apa aliran kerja yang membolehkan anda meluluskan pelan lalu meninggalkannya akan menghapuskan semakan manusia yang sebelum ini membendung risiko. Pada ketika itu, komputer perlu melaksanakan kawalan tersebut. Perkara yang sama terpakai pada apa-apa yang meluaskan capaian ejen, termasuk menjalankan ejen pengekodan pada VPS merentasi beberapa repositori serentak.

Keputusan ini sebenarnya bukan tentang sejauh mana anda mempercayai model. Keputusan ini tentang perkara yang berada di sebelah model apabila model itu tersilap.

FAQ

Adakah kontena menyediakan pengasingan yang mencukupi untuk ejen pengekodan?

Untuk kebanyakan kerja, ya, dengan dua syarat. Kontena tidak boleh dijalankan dengan --privileged, dan /var/run/docker.sock tidak boleh dipasang ke dalamnya, kerana salah satu daripadanya memberikan proses laluan ke root pada hos. Kontena berkongsi kernel hos, jadi sempadannya lebih lemah berbanding mesin maya. Jika ejen menjalankan kod tidak dipercayai yang diperoleh dari internet, pilih mesin maya sebenar atau pelayan berasingan.

Adakah ejen memerlukan sudo pada pelayan?

Tidak. Pemberian sudo akan membatalkan pengasingan yang anda bina, kerana root boleh membaca akaun lain pada mesin tersebut. Cipta pengguna ejen tanpa sudo dan berikan akses tulis hanya kepada direktori kerjanya sendiri. Jika tugas benar-benar memerlukan pemasangan pakej, berikan ejen sebuah mesin sepenuhnya yang berada di bawah kawalannya, bukannya akses root pada mesin yang dikongsi.

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

Majukan ejen SSH anda dengan ssh -A apabila anda membuat sambungan. Permintaan tandatangan dihantar melalui sambungan, manakala kunci persendirian kekal pada komputer riba anda. Oleh itu, ssh -T git@github.com melakukan pengesahan dan git push berfungsi tanpa kunci persendirian pada pelayan. Perlu diingat bahawa root pada pelayan tersebut boleh menggunakan soket yang dimajukan semasa anda bersambung. Oleh itu, gunakan kunci deploy yang terhad kepada repositori pada mana-mana mesin yang anda kongsi dengan orang lain.

Apakah saiz VPS yang diperlukan oleh ejen?

Kerja ejen kebanyakannya melibatkan penyuntingan fail, menjalankan binaan dan menjalankan ujian. Oleh itu, tentukan saiz mesin berdasarkan keperluan binaan, bukan model. Model yang dihoskan berjalan pada perkakasan penyedia, yang menambah trafik rangkaian tetapi hampir tiada beban setempat. Mulakan dengan 2 GB RAM untuk kerja penskripan dan beralih kepada 8 GB jika repositori membina kontena atau menyusun apa-apa yang besar.

Berapa kerapkah saya patut memusnahkan dan membina semula mesin?

Bina semula apabila keadaan sistem tidak lagi dapat dijelaskan. Sekurang-kurangnya, bina semula setiap kali kelayakan pada mesin tersebut mungkin telah terdedah. Checkout baharu antara tugas mengurus perubahan harian. Syot kilat yang diambil sebelum ejen dijalankan buat kali pertama memberikan anda imej sistem bersih untuk dipulihkan. Jika pembinaan semula terasa mahal, itu menandakan sesuatu yang penting berada pada mesin yang anda anggap boleh guna semula.