Kotak pasir pelaksanaan untuk ejen AI: seni bina, risiko dan corak dunia sebenar

Laman Utama » Python » Kotak pasir pelaksanaan untuk ejen AI: seni bina, risiko dan corak dunia sebenar

Membiarkan ejen AI menjalankan kod, menyentuh fail, membuka pelayar dan menekan API mengubahnya daripada pelengkap automatik yang mewah menjadi sesuatu yang lebih hampir seperti jurutera junior dengan root pada mesin. Kuasa tambahan itulah sebabnya ia terasa ajaib – dan mengapa ia boleh berbahaya. Ejen yang tidak sejajar atau hanya mempunyai pepijat boleh memadam pangkalan data, membocorkan kunci API ke internet atau menggunakan binaan yang rosak ke dalam pengeluaran tanpa benar-benar "memahami" apa yang salah.

Persoalan sebenar bukan lagi “seberapa tepatkah model itu?” tetapi “apakah yang boleh dicapainya apabila ia salah, ditipu atau terlalu yakin?”. Kotak pasir pelaksanaan untuk ejen ialah jawapan kejuruteraan: persekitaran berskop ketat di mana ejen boleh membaca dan menulis kod, menjalankan shell, melancarkan pelayan atau mengaktifkan pelayar, sementara anda mengawal sistem fail, rangkaian, kelayakan dan kitaran hayat dengan ketat. Daripada mempercayai model, anda mengehadkan jejari letupan.

Mengapa ejen pengekodan memerlukan kotak pasir pelaksanaan khusus

Ejen pengekodan moden seperti Claude Code, LangChain Deep Agents, kotak pasir pengekodan Docker dan alatan serupa tidak lagi berfungsi seperti chatbot mudah dengan akses fail. Mereka membaca keseluruhan repositori, mengedit fail, menjalankan arahan shell, memanipulasi Git, memulakan binaan Docker, bercakap dengan API luaran dan juga mengendalikan persekitaran seperti desktop penuh melalui pelayar. Dokumen vendor sangat jelas tentang perkara ini: Claude Code dibentangkan sebagai pembantu pembangunan tangkas yang boleh memeriksa pangkalan kod anda, membuat suntingan dan menjalankan arahan; LangChain Deep Agents melayan backend kotak pasir sebagai tempat mereka melaksanakan arahan shell, mengurus sistem fail dan mewakilkan kerja kepada sub-ejen untuk pengasingan.

Set keupayaan inilah yang menjadikan ejen-ejen ini berguna – dan berisiko dari segi operasi. Sebaik sahaja model boleh dijalankan pytest, memasang pakej npm, membuka cawangan atau menyahpepijat kegagalan binaan, ia hanya beberapa panggilan alat sahaja lagi daripada mengubah suai skrip penggunaan, menolak imej yang rosak, mengubah suai konfigurasi CI atau mengeluarkan token melalui permintaan HTTP. Panduan keselamatan ejen OpenAI sendiri dan kerja NIST mengenai rampasan ejen kedua-duanya menekankan suntikan segera: arahan berniat jahat yang tersembunyi dalam fail, halaman web atau log boleh mengarahkan ejen secara senyap-senyap ke dalam tindakan yang anda tidak pernah bermaksud untuk benarkan.

Banyak pasukan bermula dengan aliran "minta-untuk-kelulusan" yang naif untuk setiap arahan dan dengan cepat mendapati ia tidak berskala. Anthropic telah berkongsi secara terbuka bahawa pengguna telah meluluskan 93% gesaan kebenaran Claude Code; Kotak pasir Claude Docker juga melancarkan Claude Code dengan --skip-permissions secara lalai, bergantung pada pengasingan masa jalan dan bukannya ribut dialog. Orang ramai mengalami keletihan kelulusan, terutamanya apabila menjalankan berbilang ejen secara selari dan penukaran konteks merentasi banyak gesaan. Pada ketika itu, dialog pengesahan menjadi upacara, bukan kawalan yang boleh dipercayai.

Kotak pasir pelaksanaan mengubah model keselamatan daripada "percayai pengguna untuk membaca setiap gesaan" kepada "anggap beberapa arahan akan salah atau bertentangan, dan hadkan kerosakan yang boleh mereka lakukan". Kotak pasir menjadi sempadan keras di sekitar fail, proses, rangkaian dan rahsia yang boleh disentuh oleh ejen, walaupun ia dimanipulasi melalui suntikan segera atau hanya melakukan kesilapan.

Terdapat juga hujah asas antara pembangun dan pengalaman: ejen memerlukan ruang yang cukup untuk benar-benar berfungsi. Jika anda terlalu banyak menggunakan sekatan kasar, arahan mudah seperti binaan atau ujian akan sentiasa gagal pada ralat kebenaran yang tidak jelas. Sistem terbaik, seperti yang digunakan oleh Cursor pada macOS/Linux/Windows atau oleh Cloudflare, Heroku dan Google Cloud untuk beban kerja yang dihoskan, bertujuan untuk memberikan ejen rasa "komputer sebenar" di dalam perimeter yang sempit.

Apa yang sebenarnya diasingkan oleh kotak pasir pelaksanaan untuk ejen

Kotak pasir ejen yang betul bukan sekadar "tempat lain untuk menjalankan kod" – ia merupakan himpunan sempadan eksplisit yang menentukan jejari letupan. Anda boleh memikirkan lima had utama yang muncul berulang kali dalam platform terkemuka seperti Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B atau Daytona.

Pertama, sempadan sistem fail: ejen hanya perlu melihat ruang kerja yang anda kongsikan secara sengaja. Dokumen LangChain membingkaikan kotak pasir sebagai penghalang yang menjauhkan ejen daripada fail hos; Model kotak pasir Docker jelas sekali bahawa microVM hanya melihat direktori projek yang dipasang secara eksplisit. Apa-apa sahaja di luar pokok itu tidak kelihatan atau baca sahaja, jadi ejen tidak boleh membaca secara sambil lewa. ~/.ssh atau menulis semula konfigurasi sistem.

Kedua, sempadan proses dan kernel: beban kerja ejen tidak sepatutnya berkongsi kernel hos mentah atau jadual proses. Seni bina kotak pasir Docker mengasingkan setiap persekitaran dengan cara tersendiri microVM dan kernel LinuxFirecracker (digunakan secara rahsia oleh beberapa penyedia) menganggap sempadan VM tersebut sebagai lapisan pengasingan pertama, kemudian menambah seccomp, ruang nama, kumpulan c dan sekatan seperti jail di bahagian atas. GKE Agent Sandbox Google mencapai kesan yang serupa di dalam Kubernetes menggunakan gVisor: lapisan "sentry" memintas panggilan sistem dan menjadi perantara akses kepada nod yang mendasarinya.

Ketiga, sempadan rangkaian: tanpa dasar rangkaian, ejen kotak pasir masih merupakan mesin pengekstrakan data. Kebanyakan platform yang serius kini dihantar dengan "deny-all egress" secara lalai. Docker Sandbox, sebagai contoh, menyekat HTTP/HTTPS sehingga dibenarkan secara eksplisit, memotong TCP/UDP/ICMP mentah dan tidak membenarkan trafik ke julat IP peribadi dan localhost melainkan anda mengkonfigurasi pengecualian. Cloudflare, Google dan lain-lain mereka bentuk sandbox mereka supaya panggilan keluar melalui proksi boleh atur cara di mana anda boleh menyuntik auth, menapis destinasi dan mengaudit penggunaan.

Keempat, sempadan kelayakan: pendedahan rahsia mentah di dalam kotak pasir harus dianggap sebagai jalan terakhir, bukan langkah lalai. Reka bentuk Docker menghalakan panggilan HTTP melalui proksi bahagian hos yang boleh melampirkan token atau kunci API pada permintaan tanpa meletakkan nilai mentah tersebut di dalam VM. Kotak Pasir Cloudflare juga menyuntik kelayakan pada lapisan rangkaian, bukan melalui env vars. Dengan cara itu, walaupun suntikan segera meyakinkan ejen untuk "mencetak semua pembolehubah persekitaran", tiada apa yang menarik untuk dicuri.

Kelima, sempadan kitaran hayat: ruang kerja ejen jarang digunakan untuk satu arahan; ia memerlukan semantik eksplisit untuk mula, jeda, snapshot, fork dan teardown. E2B mendedahkan sistem fail terpencil, arahan latar belakang dan volum yang boleh bertahan melebihi jangka hayat kotak pasir tunggal. Freestyle memberi tumpuan kepada putaran, penggantungan dan penyambungan semula VM yang sangat pantas dengan snapshotting dan percabangan keadaan dalam memori. Daytona menambah kotak pasir berasaskan snapshot serta dasar henti automatik, arkib automatik dan padam automatik supaya anda boleh memastikan sesetengah persekitaran tahan lama dan melayan persekitaran lain sebagai pakai buang.

Sebaik sahaja anda melihat lima paksi ini – sistem fail, proses, rangkaian, kelayakan dan kitaran hayat – anda boleh membaca mana-mana halaman produk kotak pasir sebagai satu siri pertukaran. Kontena kernel kongsi dengan pemasangan hos yang besar tetapi peraturan keluar yang ketat adalah sangat berbeza daripada microVM tanpa pemasangan hos tetapi rangkaian yang lebih permisif. Bagi ejen pengekodan yang perlu memasang kebergantungan, menjalankan pelayar atau membina imej docker, sempadan gaya VM yang lebih kukuh cenderung menjadi lalai yang lebih selamat.

Sandboxing pada macOS, Linux dan Windows untuk ejen pengekodan tempatan

Pada komputer riba pembangun, anda tidak selalu boleh menghasilkan kotak pasir mikroVM kelas berat, jadi pasukan terpaksa menjadi kreatif dengan pengasingan OS asli. Kerja Cursor baru-baru ini pada kotak pasir setempat merupakan contoh yang baik dalam menyesuaikan diri dengan spesifikasi macOS, Linux dan Windows sambil mengekalkan API terpadu untuk lapisan ejen.

Pada macOS, beberapa pilihan telah dinilai: App Sandbox, bekas generik, VM penuh dan teknologi yang tahan lama tetapi "tidak digunakan lagi" yang dipanggil Seatbelt. App Sandbox memerlukan penandatanganan setiap binari yang mungkin dilaksanakan oleh ejen, meningkatkan kerumitan secara mendadak dan juga memberikan kepercayaan transitif binari yang dijana. Kontena Linux akan memaksa pengguna macOS ke dalam binari Linux sahaja, dan VM sepenuhnya mempunyai latensi but dan overhed memori yang tidak boleh diterima untuk aliran pengekodan interaktif.

Tali pinggang keledar, diakses melalui sandbox-exec, akhirnya menjadi pilihan pragmatik meskipun usianya sudah lanjut. Ia membolehkan anda menjalankan arahan di bawah profil kotak pasir yang mengekang keseluruhan pokok proses dengan bahasa dasar yang terperinci: anda boleh menyenaraihitamkan atau menyekat sistem tertentu dan mengehadkan kebenaran baca/tulis kepada fail atau direktori yang disasarkan. Kursor menjana dasar ini secara dinamik semasa masa jalan berdasarkan ruang kerja dan tetapan pentadbir serta tetapan pengguna .cursorignore, jadi laluan yang diabaikan menjadi terlarang dalam kotak pasir.

Pada Linux, kernel mendedahkan primitif yang betul – seccomp untuk penapisan syscall dan Landlock untuk sekatan sistem fail – tetapi membiarkan komposisi terpulang kepada ruang pengguna. Daripada bergantung pada pembalut OSS sedia ada yang tidak menyokong pengabaian khusus repo seperti .cursorignore, Cursor memilih untuk mengatur Landlock dan seccomp secara langsung. Seccomp mengharamkan panggilan sistem berbahaya; Landlock menguatkuasakan peraturan baca/tulis berasaskan laluan, malah membiarkannya menimpa ruang kerja pengguna supaya fail yang diabaikan tidak dapat diakses sepenuhnya atau digantikan dengan salinan yang dilindungi yang tidak dapat dibaca atau diubah suai oleh proses yang dikotak pasir.

Satu kehalusan pada Linux ialah prestasi: pemasangan semula atau penulisan semula semua fail yang diabaikan adalah bahagian paling perlahan dalam persediaan kotak pasir. Penapisan tertunda gaya macOS yang dapat melihat laluan fail yang tepat pada masa syscall akan memudahkan perkara ini, tetapi seccomp-bpf Linux tidak memudahkan pemeriksaan laluan itu, jadi terdapat pertukaran kejuruteraan sebenar antara pengasingan ketat dan kelajuan permulaan.

Pada Windows, membina kotak pasir asli yang benar-benar setara masih lebih sukar kerana kebanyakan primitif pengasingan dioptimumkan untuk pelayar dan bukan perkakasan pembangunan tujuan umum. Kursor kini menjalankan sandbox Linux di dalam WSL2 untuk pengguna Windows, pada dasarnya menyokong pengasingan Linux sehingga primitif yang lebih kaya tersedia. Mereka sedang bekerjasama dengan Microsoft untuk mendedahkan keupayaan yang betul supaya, dari semasa ke semasa, ejen Windows dapat menikmati sandboxing asli kelas pertama tanpa WSL sebagai penopang.

Benang merah merentasi pendekatan khusus OS ini ialah API kotak pasir bersatu di bahagian atas. Dari sudut pandangan ejen, terdapat "alat shell" dengan keupayaan dan peraturan yang jelas. Di bawah hud, pengasingan berasaskan Tali Pinggang Keledar, Landlock/seccomp atau WSL2 menguatkuasakan peraturan tersebut secara berbeza setiap platform.

Ejen pengajaran untuk memahami dan menghormati sandbox

Kotak pasir hanya membantu jika ejen boleh menjangka apa yang akan berfungsi di dalamnya dan bila ia perlu meningkatkan keistimewaan atau meninggalkan kotak. Itu kedengaran jelas, tetapi dalam praktiknya ia memerlukan beberapa lelaran reka bentuk alat dan gesaan yang mendalam untuk ejen pengekod penghantaran vendor.

Langkah pertama yang diambil oleh banyak pasukan ialah menambah baik penerangan alat, terutamanya untuk pelaksanaan shell. Daripada alat "run_shell_command" generik, penerangan tersebut menyatakan secara eksplisit sumber yang boleh diakses: sama ada arahan tersebut mempunyai akses sistem fail, akses Git, akses rangkaian atau persekitaran luar talian sepenuhnya bergantung pada konfigurasi pengguna. Ia juga mendokumentasikan bagaimana ejen boleh meminta hak yang dipertingkatkan (contohnya, untuk mencapai internet awam) apabila perlu. Kerja kejuruteraan segera ini cenderung sangat empirikal: pasukan menjalankan aliran penggunaan biasa, memerhatikan di mana model salah meramal keupayaan, melaraskan penerangan alat dan mengulanginya.

Penanda aras dalaman seperti "Cursor Bench" atau suit penilaian yang serupa kemudiannya digunakan untuk membandingkan prestasi ejen dengan dan tanpa sandboxing. Satu mod kegagalan awal adalah sangat konsisten: ejen akan mencuba semula arahan terminal yang gagal secara membuta tuli berulang kali dan bukannya menyedari ia telah mencapai sekatan kotak pasir. Tanpa isyarat yang jelas tentang mengapa arahan itu gagal, model tidak dapat mempelajari coraknya.

Penyelesaiannya adalah untuk menonjolkan ralat kotak pasir secara eksplisit dalam output alat, selalunya dengan isyarat tentang apa yang perlu dilakukan seterusnya. Apabila arahan disekat kerana sistem fail atau peraturan rangkaian, alat shell mula memasukkan penjelasan ringkas seperti "disekat oleh kotak pasir: akses rangkaian keluar dinyahdayakan untuk sesi ini" dan, dalam beberapa kes, petunjuk bahawa ejen boleh meminta kebenaran yang lebih tinggi. Selepas perubahan ini, ejen menjadi lebih berdaya tahan: mereka berhenti mengulangi arahan yang sia-sia dan sama ada melaraskan pelan mereka atau meminta keupayaan yang diperlukan.

Penilaian luar talian memang membantu, tetapi ia hanya menceritakan sebahagian daripada cerita. Untuk benar-benar mengetahui sama ada sandboxing menjejaskan pengalaman pengguna, pasukan telah melancarkan sokongan sandbox secara beransur-ansur dalam pengeluaran dan memerhatikan kadar ralat, masa penyiapan dan saluran maklum balas. Dalam praktiknya, vendor melaporkan bahawa sebahagian besar pertanyaan pada platform yang serasi kini dijalankan sepenuhnya di dalam sandbox – dengan pelanggan perusahaan seperti NVIDIA antara pengguna awal – dan ejen sandboxing sebenarnya berhenti seketika untuk kelulusan sekitar 40% kurang kerap dalam aliran kerja sebenar, menjimatkan masa semakan manual sambil mengurangkan risiko.

Menjelang masa hadapan, terdapat banyak minat terhadap "ejen kotak pasir asli" – model yang dilatih secara langsung mengenai kekangan persekitaran mereka. Daripada menganggap shell, pelayar atau sistem fail sebagai alat abstrak, ejen-ejen ini akan memahami bahawa mereka hidup dalam runtime yang berskop ketat, boleh menulis skrip dan program yang tahan lama, dan mesti menghormati syarat sempadan seperti "tiada rangkaian keluar" atau "ruang kerja adalah baca sahaja". Latihan itu boleh menjadikan mereka jauh lebih baik dalam merancang urutan tindakan yang selamat dan cekap tanpa melanggar dinding yang tidak kelihatan.

Kotak pasir awan: Cloudflare, Google Cloud, Heroku dan lain-lain

Di luar komputer riba pembangun, gelombang besar penyedia infrastruktur berlumba-lumba untuk menawarkan kotak pasir yang dihoskan yang ditala khusus untuk ejen AI. Matlamat mereka adalah sama – pengasingan, kawalan dan prestasi – tetapi imbangannya kelihatan sedikit berbeza pada skala awan.

Kotak Pasir Cloudflare, yang dibina di atas Kontena Cloudflare dan kini tersedia secara umum, bertujuan untuk kelihatan dan terasa seperti persekitaran pembangunan penuh untuk ejen. Setiap kotak pasir ialah ruang kerja yang berterusan dan terpencil yang anda namakan. Jika ia tidur, ia berputar apabila diminta; jika ia melahu, ia akan digantung secara automatik untuk menyimpan pengiraan dan menyambung semula pada permintaan seterusnya. Pembangun (atau ejen) boleh berinteraksi dengannya melalui kaedah yang ditaip seperti exec, gitCheckout, writeFile, dan banyak lagi, menggunakan SDK JavaScript/TypeScript.

Salah satu masalah awan yang paling sukar ialah pengesahan selamat daripada kotak pasir ejen dalam. Ejen sering perlu mengakses perkhidmatan persendirian, tetapi anda tidak mahu kelayakan mentah terbiar dalam pembolehubah persekitaran. Cloudflare menyuntik kelayakan pada lapisan proksi rangkaian, memetakan permintaan keluar oleh hos kepada logik tersuai yang melampirkan token daripada storan selamat. Proses kotak pasir tidak pernah melihat rahsia sebenar, tetapi panggilan masih disahkan. Reka bentuk ini menyokong suntikan kelayakan dinamik yang menyedari identiti dan berfungsi dengan baik dengan pengikatan Pekerja.

Untuk aliran kerja yang padat dengan terminal, Cloudflare telah menambah pengalaman PTY (pseudo-terminal) penuh yang disambungkan melalui WebSockets dan xterm.js. Ejen dan manusia boleh membuka sesi shell langsung, mengganggu proses, menyambung semula kemudian dan memainkan semula output yang lalu. Setiap PTY mempunyai direktori dan persekitaran kerjanya sendiri, dan output ditimbal pada pelayan supaya klien yang menyambung semula boleh mengejar log yang terlepas.

Selain akses shell mentah, Cloudflare juga menawarkan "konteks pelaksanaan kod" yang berterusan untuk bahasa seperti Python, JavaScript dan TypeScript. Tidak seperti kebanyakan pelari coretan yang melaksanakan setiap fragmen secara berasingan, konteks ini menyimpan pembolehubah, import dan keadaan merentasi panggilan, seperti buku nota Jupyter. Ejen boleh memuatkan data dalam satu panggilan, mengubahnya dalam panggilan lain dan memaparkan carta atau jadual HTML tanpa sentiasa menghuraikan semula dan mengimport semula semuanya.

Untuk tugasan pembangunan web, kotak pasir Cloudflare menyokong proses latar belakang, pemeriksaan kesihatan dan URL pratonton langsung. Ejen boleh mula npm run dev sebagai kerja latar belakang, pantau log sehingga pelayan bersedia, dan kemudian dedahkan port di sebalik URL pratonton awam. Kaedah seperti waitForPort() or waitForLog() biarkan ejen menyusun tindakan berdasarkan isyarat kesediaan sebenar dan bukannya naif sleep(2s) tekaan.

Aliran kerja dipacu peristiwa mendapat rangsangan daripada primitif pemantauan fail yang disokong oleh mekanisme inotify Linux. Ejen boleh melanggan perubahan di bawah /workspace/src dan menjalankan semula ujian atau binaan secara automatik apabila fail TypeScript diubah suai. Ini adalah gelung maklum balas yang sama yang diandalkan oleh pembangun manusia, tetapi dibuat berasaskan ejen melalui API seperti sandbox.watch() dan strim peristiwa yang dihantar oleh pelayan.

Untuk menutup gelung kitaran hayat, Cloudflare melancarkan snapshot sebenar – tangkapan keadaan peringkat VM yang boleh dipulihkan dalam beberapa saat daripada storan R2. Gambaran ringkas mengekalkan keadaan sistem fail, konfigurasi OS, kebergantungan yang dipasang dan fail data; versi akan datang juga akan memulihkan keadaan memori langsung untuk resume segera. Ejen (atau pengaturcara) boleh mencetuskan gambaran ringkas secara pengaturcaraan untuk pusat pemeriksaan atau senario fan-out, kemudian menggabungkan berbilang kotak pasir daripada gambaran ringkas yang sama untuk meneroka hipotesis selari secara berasingan.

Dari segi harga, Cloudflare telah beralih kepada model “CPU aktif sahaja”: anda akan dibilkan untuk kitaran CPU yang sebenarnya digunakan, bukan untuk masa terbiar sementara ejen menunggu LLM. Digabungkan dengan had serentak yang besar untuk contoh "ringan" dan lebih besar, ini menjadikannya mudah untuk menjalankan armada ejen yang besar tanpa membazirkan wang untuk kontena tidur.

Sebaliknya, GKE Agent Sandbox Google Cloud sangat bersepadu dengan Kubernetes dan gVisor. Ideanya adalah untuk membolehkan anda menjalankan beban kerja ejen dalam pod terpencil di dalam kluster anda sendiri. Anda mencipta kluster GKE (Autopilot boleh mendayakan gVisor secara automatik, manakala kluster Standard memerlukan kelas runtime eksplisit dan kolam nod yang didayakan gVisor), kemudian menggunakan pengawal Kotak Pasir Ejen melalui manifes versi.

Dua sumber teras tersuai memacu model ini: SandboxTemplate dan SandboxWarmPool. SandboxTemplate bertindak sebagai pelan tindakan yang boleh diguna semula yang menentukan templat pod (imej, port, sumber, runtimeClassName: gvisor, dll.) untuk masa jalan berpasir, seperti persekitaran Python. SandboxWarmPool memastikan bilangan pod yang telah dipanaskan terlebih dahulu bersedia untuk dituntut hampir serta-merta, mengelakkan permulaan sejuk apabila ejen memerlukan persekitaran yang segar dalam masa kurang daripada sesaat.

A Sandbox Router perkhidmatan kemudiannya bertindak sebagai pintu masuk untuk trafik antara pelanggan dan pod terpencil ini. Dalam pembangunan, anda boleh menyorong trafik melalui kubectl port-forward tanpa mendedahkan IP awam. Dalam pengeluaran, anda biasanya akan mengetuai penghala dengan kemasukan dan mTLS yang betul. Di bahagian klien, Google menyediakan pustaka Python "Agentic Sandbox" yang merangkumi kitaran hayat penuh: cipta tuntutan sandbox daripada templat, tunggu sehingga ia siap, jalankan arahan shell dan bersihkan apabila selesai.

Semua ini masih "hanya Kubernetes" di sebalik hud, tetapi dibungkus ke dalam cerita yang koheren untuk runtime ejen. gVisor memberikan pengasingan proses dan sistem, SandboxTemplate menyeragamkan konfigurasi, WarmPool menyelesaikan latensi permulaan dan klien penghala serta Python menjadikannya mudah untuk aplikasi yang berpusatkan LLM.

Heroku, sebaliknya, bergantung pada blok binaan yang sangat matang: dyno sekali sahaja. Selama bertahun-tahun, pengguna Heroku telah menjalankan kerja ad hoc – migrasi, skrip penyelenggaraan, tugas pentadbir – dalam dinas sementara yang berputar mengikut permintaan dan mati apabila selesai. Heroku menggunakan semula infrastruktur ini sebagai kotak pasir pelaksanaan kod, yang dilancarkan bersama tawaran Inferens Terurus dan Ejen mereka. Ejen menulis coretan Python, Ruby, Node atau Go; Heroku melaksanakannya di dalam dinas jangka pendek dan menstrimkan hasil kembali, mengehadkan jejari letupan kepada bekas sementara.

Anda boleh mengakses kotak pasir ini sama ada melalui alat terbina dalam API Ejen Heroku atau dengan menggunakan pelayan Protokol Konteks Model (MCP) sumber terbuka. Pelayan MCP mendedahkan titik akhir alat piawai, jadi klien seperti Agentforce, Claude Desktop atau Cursor boleh melayan kotak pasir Heroku sebagai backend pelaksanaan kod jarak jauh generik. Setiap pelayan menyokong had khusus masa jalan (seperti max_calls setiap gelung ejen) untuk mengelakkan ejen daripada berputar dalam gelung yang ketat dan mahal.

Ejen Dalam LangChain menambah satu lagi dimensi dengan berintegrasi dengan penyedia kotak pasir pihak ketiga seperti Runloop, Daytona dan Modal. Coraknya mudah: Deep Egent terus berjalan di mana sahaja anda mahu (tempatan atau awan), tetapi apabila ia perlu menjalankan arahan, mencipta fail atau melaksanakan kod, operasi tersebut akan dihantar ke kotak pasir jauh. Skrip persediaan boleh memuatkan pembolehubah persekitaran terlebih dahulu, mengklon repo, memasang perkakasan dan banyak lagi, jadi setiap ejen mendapat persekitaran yang bersih dan terkawal. Pengurus konteks kemudian mengendalikan penciptaan dan pembersihan, walaupun dokumen tersebut sangat mengesyorkan pemantauan papan pemuka penyedia untuk sebarang kotak pasir yang telah lama berjalan yang dilupakan.

Prestasi, keadaan dan percabangan: mengapa kelajuan penting untuk ejen

Kotak pasir yang perlahan tetapi ultra selamat akan dipintas dalam praktiknya; alat pembangun hidup atau mati pada kependaman. Ejen pengekodan tidak bertindak seperti kerja kelompok setiap malam. Mereka menjalankan gelung interaktif: membaca beberapa kod, mencadangkan suntingan, menjalankan ujian, menganalisis log, memanggil alatan, menunggu manusia, kemudian mengulanginya. Dalam sesi sebenar, mereka juga meneroka pelbagai cabang masalah, meninggalkan beberapa laluan dan kembali kepada yang lain kemudian.

Inilah sebabnya platform seperti Freestyle terlalu mementingkan masa kitaran hayat VM sub-saat dan semantik keadaan yang kaya. VM mereka ialah mesin Linux penuh dengan akses root, perkhidmatan systemd, sokongan virtualisasi bersarang dan rangkaian penuh. Dokumentasi mendakwa peruntukan dalam masa kurang daripada 800 ms daripada panggilan API kepada VM yang dijalankan, gantung/sambung semula dalam masa kurang daripada 100 ms dan keupayaan untuk snapshot atau fork VM di pertengahan pelaksanaan dengan prestasi minimum. Mereka secara eksplisit memanggil keadaan pelayar sebagai benefisiari: jika ejen telah memacu pelayar ke dalam keadaan yang menarik, ia boleh fork VM tersebut sebanyak 20 kali daripada snapshot yang sama dan bukannya mencipta semula keadaan itu dari awal.

SandboxWarmPool Google untuk GKE menyatakan idea yang sama dalam istilah Kubernetes: pastikan terdapat sekumpulan pod yang telah dipanaskan terlebih dahulu supaya ejen tidak membayar penalti permulaan sejuk penuh untuk setiap larian baharu. Ruang kerja berasaskan snapshot Daytona serta dasar auto-henti/arkib/padam melaraskan kitaran hayat untuk pelbagai jenis sesi: persekitaran pembangunan aktif, eksperimen sementara dan garis dasar yang tahan lama.

Penekanan E2B terhadap kerja latar belakang, direktori yang boleh ditonton, sistem fail terpencil dan jilid yang boleh diguna semula adalah sisi lain daripada syiling yang sama. Ciri-ciri ini membolehkan ejen memastikan pelayan pembangunan atau abah-abah ujian berjalan sambil meneroka perubahan kod atau berkongsi volum berterusan merentasi berbilang kotak pasir sementara dari semasa ke semasa. Tanpa ini, ejen akhirnya akan menjalankan arahan sekali sahaja dan kehilangan konteks, yang akan menjejaskan produktiviti.

Satu cara yang berguna untuk menilai sebarang sandbox untuk kerja ejen adalah dengan menanyakan beberapa soalan terus terang. Bolehkah saya melancarkan persekitaran baharu dalam masa kurang daripada sesaat? Bolehkah saya menyimpan dan memulihkan keadaan dengan bersih, termasuk binaan separa atau sesi pelayar? Bolehkah saya menggunakan keadaan fork untuk penerokaan selari? Bolehkah saya mengekalkan ruang kerja yang tahan lama tetapi cekap sumber untuk aliran "kembali kemudian"? Lebih banyak jawapan "ya" yang anda dapat, lebih banyak ejen anda boleh bertindak seperti jurutera sebenar dan bukannya pelari skrip tanpa keadaan.

Rahsia, dasar rangkaian dan ruang kerja dipercayai sebagai satah kawalan sebenar

Walaupun dengan pengasingan hos yang sempurna, mudah untuk membina sistem yang tidak selamat jika anda mengabaikan rahsia, dasar rangkaian dan kepercayaan ruang kerja. Dokumen kotak pasir Docker sangat jelas dalam hal ini. MicroVM dan daemon Docker peribadinya membentuk sempadan kepercayaan utama dengan hos. Walau bagaimanapun, di dalam VM itu, ejen mempunyai kawalan peringkat akar penuh dan ruang kerja kongsi dipasang baca-tulis. Secara lalai, sebarang suntingan fail akan dicerminkan pada hos dengan serta-merta. Keluar rangkaian ditolak secara lalai dan hanya dibenarkan melalui peraturan eksplisit dan permintaan HTTP menggunakan proksi bahagian hos yang boleh menyuntik kelayakan tanpa mendedahkan rahsia mentah kepada VM.

Ini bermakna mengasingkan hos hanyalah langkah pertama; anda masih perlu memikirkan apa yang boleh dilakukan oleh ejen terhadap ruang kerja dan dunia luar. Dokumen Docker secara eksplisit memberi amaran bahawa jika ejen mengedit skrip, manusia akan melaksanakannya kemudian – Cangkuk Git, konfigurasi CI, definisi tugas IDE, Makefile sasaran, package.json skrip – kerosakan boleh "melompat" kembali ke sistem hos atau CI apabila skrip tersebut dijalankan. Ia juga menyerlahkan bahawa Git menyangkut dalam .git/ jangan muncul dalam git diff, menjadikan kegigihan logik berniat jahat secara senyap lebih mudah.

Proksi kelayakan adalah berkuasa tetapi halus. Proksi keluar Docker memastikan rahsia kekal di luar VM, tetapi masih membenarkan ejen bertindak menggunakan identiti tersebut terhadap hos yang dibenarkan. Sesetengah aliran – seperti menulis var persekitaran tersuai ke dalam fail seperti /etc/sandbox-persistent.sh – pecahkan sempadan ini dengan sengaja menyimpan rahsia di dalam VM, yang hanya selamat jika anda benar-benar mempercayai ejen dan kotak pasir.

Skop konfigurasi sama pentingnya dengan rahsia. Soalan Lazim Docker menyatakan bahawa konfigurasi peringkat pengguna seperti ~/.claude or ~/.codex pada hos tidak disalin ke dalam kotak pasir; hanya konfigurasi skop projek dalam ruang kerja kongsi yang boleh dilihat. Dokumen konfigurasi Anthropic mengukuhkan bahawa tetapan peringkat projek – alatan, kebenaran, pelayan MCP, cangkuk – mengatasi tetapan peringkat pengguna dan dikongsi merentas pasukan. Dalam erti kata lain, apa sahaja dasar, arahan dan pemalam yang anda lampirkan pada repo menjadi kawasan permukaan utama yang dilihat oleh ejen.

Panduan Kemahiran OpenAI menekankan perkara yang serupa dalam perbendaharaan kata yang sedikit berbeza. Kemahiran (pakej alat) boleh memperkenalkan risiko pengekstrakan data yang didorong oleh suntikan gesaan. Dokumen tersebut memberi amaran agar tidak mendedahkan pasaran Kemahiran awam yang tidak dikawal selia secara langsung kepada pengguna akhir, kerana fail SKILL.md yang berniat jahat boleh mengatasi dasar, mencetuskan tindakan yang merosakkan atau membocorkan data peribadi. Mereka mengesyorkan agar Kemahiran pembangun diperiksa, diskopkan kepada aliran kerja tertentu, menyembunyikan tindakan berimpak tinggi di sebalik kelulusan tambahan dan semakan dasar, dan menganggap Kemahiran sebagai sebahagian daripada model ancaman anda.

Apabila anda menggabungkan kepingan-kepingan itu, satah kawalan "sebenar" untuk kotak pasir ejen merangkumi empat lapisan. Pengasingan hos melindungi mesin dan nod kluster anda. Kepercayaan ruang kerja melindungi manusia atau CI masa depan yang akan menjalankan fail yang dihasilkan di dalam kotak pasir. Dasar rangkaian melindungi sistem luaran dan sumber data peribadi. Pengurusan kelayakan melindungi identiti yang melaluinya ejen boleh bertindak. Reka bentuk yang mantap mempunyai jawapan untuk keempat-empatnya, bukan hanya yang pertama.

Selain itu, anda masih memerlukan skeptisisme yang sihat tentang suntikan segera dan rampasan ejen. NIST, OWASP dan OpenAI semuanya menerangkan varian corak yang sama: input yang tidak dipercayai – README, halaman web, fail log – membenamkan arahan berniat jahat yang mengalihkan tingkah laku ejen. Penjanaan dan penalaan halus yang ditambah dengan pengambilan tidak menyelesaikan perkara ini secara ajaib. Kotak pasir yang diinstrumenkan dengan baik serta dasar yang baik tidak dapat menghalang model daripada tertipu, tetapi ia boleh mengurangkan kelemahan secara mendadak apabila ia tertipu.

Platform awan dan masa jalan ejen mula mengekod pelajaran ini. Proksi rahsia, domain keluar yang disenarai dibenarkan, konfigurasi skop repo, subagen dengan keupayaan yang lebih sempit, aliran kelulusan berasaskan cangkuk dan kotak pasir yang boleh dihasilkan semula semuanya merupakan kepingan teka-teki yang sama: terimalah bahawa model boleh salah dan merekayasa persekitaran supaya kos kebolehsalahan itu kekal terhad.

Merentasi persediaan tempatan dan awan, kotak pasir pelaksanaan untuk ejen paling baik dianggap sebagai garisan yang dilukis dengan teliti: ia tidak menjadikan model lebih pintar, malah menjadikan kesilapannya kurang bencana dan lebih mudah diperhatikan. Dengan gabungan kawalan sistem fail, proses, rangkaian, rahsia dan kitaran hayat yang betul, serta pengajaran pintar ejen tentang persekitarannya, anda boleh membiarkan sistem AI mengklon repo, menjalankan ujian, melancarkan pelayar dan juga menyentuh sistem seperti pengeluaran – tanpa menyerahkan kunci kepada semua yang anda pentingkan kepada mereka.

Ini bermakna mengasingkan hos hanyalah langkah pertama; anda masih perlu memikirkan apa yang boleh dilakukan oleh ejen terhadap ruang kerja dan dunia luar, termasuk riesgos como pelaksanaan kod jauh. Dokumen Docker secara eksplisit memberi amaran bahawa jika ejen mengedit skrip, manusia akan melaksanakannya kemudian – Cangkuk Git, konfigurasi CI, definisi tugas IDE, Makefile sasaran, package.json skrip – kerosakan boleh "melompat" kembali ke sistem hos atau CI apabila skrip tersebut dijalankan.