Tehisintellekti agentide täitmiskeskkonnad: arhitektuur, riskid ja reaalse maailma mustrid

Viimane uuendus: 05/11/2026
  • Täitmisliivakastid määratlevad failidele, protsessidele, võrgule ja saladustele ranged piirid, et kodeerijad saaksid käivitada võimsaid toiminguid ilma hosti- või tootmissüsteeme ohtu seadmata.
  • Kaasaegsed platvormid ühendavad operatsioonisüsteemi primitiivid (Seatbelt, Landlock, gVisor, microVM-id) kõrgema taseme abstraktsioonidega, nagu hetktõmmised, soojad basseinid, köited ja PTY-d, et hoida liivakastid nii turvalised kui ka kiired.
  • Saladused, võrgupoliitika, tööruumi usaldus ja kiire süstimise kaitse moodustavad tegeliku juhtimistasandi; ainuüksi hosti isoleerimisest ei piisa agendi turvaliseks käivitamiseks.
  • Pilve- ja kohalikud ökosüsteemid (Cloudflare, GKE, Heroku, Docker, Freestyle, E2B, Daytona, Cursor, LangChain) koonduvad liivakastikeskkondadesse kui vaikimisi viisi usaldamatu agendi loodud koodi käitamiseks.

Tehisintellekti agendi täitmise liivakast

Tehisintellekti agentide koodi käivitamise, failidega ühenduse loomise, brauserite avamise ja API-de kasutamise võimaldamine muudab nad uhkest automaatse täitmise funktsioonist palju sarnasemaks nooremale insenerile, kellel on masinas root õigused. See lisavõimsus ongi just see, miks nad tunduvad maagilised – ja just see, miks nad võivad olla ohtlikud. Valesti joondatud või lihtsalt vigane agent saab andmebaasi tühjendada, API-võtme internetti lekitada või katkise versiooni tootmiskeskkonda juurutada ilma tegelikult „arusaamata“, mis valesti läks.

Tegelik küsimus ei ole enam „kui täpne on mudel?“, vaid „kuhu see jõuda võib, kui see eksib, on petetud või liiga enesekindel?“. Agentide täitmisliivakastid on insenerilahendus: kitsa ulatusega keskkonnad, kus agendid saavad koodi lugeda ja kirjutada, kestasid käitada, servereid käivitada või brausereid käivitada, samal ajal kui teie rangelt kontrollite failisüsteeme, võrku, volitusi ja elutsüklit. Mudeli usaldamise asemel piirate te plahvatusraadiust.

Miks kodeerijad vajavad spetsiaalset täitmisliivakasti?

Liivakasti arhitektuur kodeerimisagentidele

Kaasaegsed kodeerimisagendid nagu Claude Code, LangChain Deep Agents, Dockeri kodeerimisliivakastid ja sarnased tööriistad ei käitu enam nagu lihtsad failidele juurdepääsuga vestlusrobotid. Nad loevad terveid repositooriume, muudavad faile, käivitavad shellikäsklusi, manipuleerivad Gitiga, käivitavad Dockeri järke, suhtlevad väliste API-dega ja haldavad brauseri kaudu isegi täielikke töölaualaadseid keskkondi. Tarnijate dokumentatsioon on selles osas väga selge: Claude'i koodi esitletakse agiilse arendusassistendina, mis saab teie koodibaasi kontrollida, muudatusi teha ja käske käivitada; LangChaini süvaagendid käsitlevad liivakasti serveriserverit kohana, kus nad täidavad shellikäsklusi, haldavad failisüsteeme ja delegeerivad tööd alamagentidele isoleerimiseks.

See võimete komplekt on just see, mis muudab need agendid kasulikuks – ja operatiivselt riskantseks. Kui mudel saab töötada pytest, npm-pakettide installimist, harude avamist või ehitusvigade silumist – vaid mõne tööriistakõne kaugusel on juurutusskriptide muutmine, vigaste piltide edastamine, CI-konfiguratsioonide kohendamine või tokenite väljafiltreerimine HTTP-päringute kaudu. Nii OpenAI enda agendi ohutusjuhised kui ka NIST-i töö agentide kaaperdamise alal rõhutavad kiiret süstimist: failidesse, veebilehtedele või logidesse peidetud pahatahtlikud juhised saavad agendi vaikselt suunata toimingutele, mida te pole kunagi tahtnud lubada.

Paljud meeskonnad alustavad iga käsu puhul naiivsete „küsi kinnitust” protsessidega ja avastavad kiiresti, et need ei ole skaleeritavad. Anthropic on avalikult jaganud, et kasutajad kiitsid heaks 93% Claude Code'i loataotlustest; Dockeri Claude'i liivakast käivitab Claude Code'i isegi koos --skip-permissions Vaikimisi toetub see pigem käitusaja isolatsioonile kui dialoogide tulvale. Inimestel tekib kinnitusväsimus, eriti kui käitatakse paralleelselt mitut agenti ja vahetatakse konteksti paljude viipade vahel. Sel hetkel muutuvad kinnitusdialoogid tseremooniaks, mitte usaldusväärseks kontrolliks.

Täitmisliivakast nihutab turvamudelit põhimõttelt „usalda kasutajat iga käsu lugemisel“ põhimõttele „eelda, et mõned käsud on valed või vastased, ja piira nende tekitatavat kahju“. Liivakastist saab karm piir failide, protsesside, võrkude ja saladuste ümber, mida agent puutuda saab, isegi kui seda manipuleeritakse kiire süstimise või lihtsalt vigade tegemise teel.

Samuti on olemas arendajakogemuse põhiline argument: agendid vajavad piisavalt ruumi, et tegelikult töötada. Kui liigkast keskkonnas katsetada tooreid piiranguid, siis lihtsad käsud, nagu versiooniuuendused või testid, ebaõnnestuvad pidevalt arusaamatute lubade vigade tõttu. Parimad süsteemid, näiteks need, mida Cursor macOS-is/Linuxis/Windowsis või Cloudflare, Heroku ja Google Cloud majutatud töökoormuste jaoks juurutab, püüavad anda agentidele kitsastes tingimustes „päris arvuti“ tunde.

Mis agentide jaoks mõeldud liivakast tegelikult isoleerib

Tehisintellekti agentide isoleeritud keskkond

Korralik agendi liivakast ei ole lihtsalt „kusagil mujal koodi käivitamiseks” – see on kogum selgeid piire, mis määravad plahvatusraadiuse. Võite mõelda viiele peamisele piirangule, mis ilmnevad ikka ja jälle juhtivatel platvormidel nagu Docker Sandboxes, Cloudflare Sandboxes, GKE Agent Sandbox, Freestyle VMs, E2B või Daytona.

Esiteks failisüsteemi piir: agent peaks nägema ainult seda tööruumi, mida te tahtlikult jagate. LangChaini dokumentatsioon kirjeldab liivakasti kui barjääri, mis hoiab agendid hostifailidest eemal; Dockeri liivakasti mudel on kristallselge, et mikrovirtuaalmasin näeb ainult selgesõnaliselt ühendatud projektikataloogi. Kõik väljaspool seda puud on nähtamatu ehk kirjutuskaitstud, seega ei saa agent seda juhuslikult lugeda. ~/.ssh või kirjutage süsteemi konfiguratsioonid ümber.

Teiseks, protsessi ja kerneli piir: agendi töökoormused ei tohiks jagada toorest hosti kerneli ega protsesside tabelit. Dockeri liivakasti arhitektuur isoleerib iga keskkonna omaette microVM ja Linuxi kernelFirecracker (mida mitmed pakkujad varjatult kasutavad) käsitleb seda virtuaalmasina piiri esimese isolatsioonikihina, seejärel lisab peale seccomp'i, nimeruumid, cgroup'id ja vanglasarnased piirangud. Google'i GKE Agent Sandbox saavutab Kuberneteses gVisori abil sarnase efekti: „sentry“ kiht pealtkuulab süsteemikõnesid ja vahendab juurdepääsu alussõlmele.

Kolmandaks, võrgu piir: ilma võrgupoliitikata on liivakastis olev agent ikkagi andmete väljavoolu masin. Enamik tõsisemaid platvorme tarnitakse nüüd vaikimisi valikuga „keela kõik väljuvad kõned“. Näiteks Dockeri liivakastid blokeerivad HTTP/HTTPS-i, kuni see on selgesõnaliselt lubatud, katkestavad toored TCP/UDP/ICMP-d ja keelavad liikluse privaatsetesse IP-vahemikesse ja localhost'i, kui te ei konfigureeri erandeid. Cloudflare, Google ja teised kujundavad oma liivakastid nii, et väljaminevad kõned läbivad programmeeritavaid puhverservereid, kuhu saate sisestada autentimist, filtreerida sihtkohti ja auditeerida kasutust.

Neljandaks, volituste piir: toorsaladuste avalikustamist liivakastis tuleks käsitleda viimase abinõuna, mitte vaikimisi. Dockeri disain suunab HTTP-kõned läbi hostipoolse puhverserveri, mis saab päringutele lisada märke või API-võtmeid ilma neid tooreid väärtusi virtuaalmasinasse paigutamata. Cloudflare Sandboxes süstivad sarnaselt volikirju võrgukihis, mitte keskkonnamuutujate kaudu. Nii pole midagi väärtuslikku varastada, isegi kui kiire süstimine veenab agenti „kõiki keskkonnamuutujaid printima“.

Viiendaks, elutsükli piir: agendi tööruumid elavad harva ühe käsu jaoks; nad vajavad selget semantikat käivitamiseks, pausiks, hetktõmmiseks, harutamiseks ja lahtiühendamiseks. E2B pakub isoleeritud failisüsteeme, taustakäsklusi ja draive, mis suudavad ellu jääda kauem kui ühe liivakasti eluiga. Freestyle keskendub virtuaalmasinate väga kiirele käivitamisele, peatamisele ja jätkamisele hetktõmmiste tegemise ja mälusisese oleku hargnemise abil. Daytona lisab hetktõmmisel põhinevad liivakastid ning automaatse peatamise, automaatse arhiveerimise ja automaatse kustutamise poliitikad, et saaksite mõnda keskkonda pikaks ajaks säilitada ja teisi käsitleda ühekordselt kasutatavatena.

Kui olete näinud neid viit telge – failisüsteem, protsess, võrk, volikirjad ja elutsükkel –, saate mis tahes liivakasti tootelehte lugeda kompromisside jadana. Jagatud kerneli konteiner suure hostiühendusega, kuid rangete väljumisreeglitega on väga erinev mikrovirtuaalmasinast, millel pole hostiühendusi, kuid on leebem võrk. Kodeerimisagentide jaoks, kes peavad installima sõltuvusi, käitama brausereid või looma dockeri kujutisi, on tugevamad virtuaalmasina stiilis piirid tavaliselt turvalisem vaikesäte.

Liivakastikeskkond macOS-is, Linuxis ja Windowsis kohalike kodeerimisagentide jaoks

Arendajate sülearvutites ei saa alati raskekaalulisi microVM-liivakaste käivitada, seega on meeskonnad pidanud operatsioonisüsteemi natiivse isolatsiooniga loomingulised olema. Cursori hiljutine töö kohalike liivakastide kallal on hea näide macOS-i, Linuxi ja Windowsi eripäradele kohandamisest, säilitades samal ajal agendi kihi jaoks ühtse API.

macOS-is hinnati mitmeid võimalusi: rakenduste liivakast, üldised konteinerid, täielikud virtuaalmasinad ja pikaajaline, kuid „aegunud” tehnoloogia nimega Seatbelt. Rakenduste liivakast oleks nõudnud iga agendi käivitatava binaarfaili allkirjastamist, mis oleks dramaatiliselt suurendanud keerukust ja andnud genereeritud binaarfailidele isegi transitiivse usalduse. Linuxi konteinerid oleksid sundinud macOS-i kasutajaid kasutama ainult Linuxile loodud binaarfaile ning täisfunktsionaalsetel virtuaalmasinatel oleks interaktiivsete kodeerimisvoogude jaoks vastuvõetamatu käivituslatentsus ja mälukoormus.

Turvavöö, ligipääsetav läbi sandbox-exec, osutus oma vanusest hoolimata pragmaatiliseks valikuks. See võimaldab teil käivitada käsu liivakasti profiili all, mis piirab kogu protsessipuud detailse poliitikakeelega: saate lisada valgesse nimekirja või blokeerida teatud süsteemikõnesid ja piirata lugemis-/kirjutamisõigusi sihtfailidele või -kataloogidele. Kursor genereerib need poliitikad dünaamiliselt käitusajal, lähtudes tööruumi ja administraatori sätetest ning kasutaja... .cursorignore, seega muutuvad ignoreeritud teed liivakastis keelatud.

Linuxis pakub kernel küll õigeid primitiive – seccomp süsteemikõnede filtreerimiseks ja Landlock failisüsteemi piirangute jaoks –, aga jätab kompositsiooni kasutajaruumi hooleks. Selle asemel, et tugineda olemasolevatele OSS-ümbristele, mis ei toetanud repo-spetsiifilisi ignoreerimisi, näiteks .cursorignoreCursor otsustas Landlocki ja seccompi otse koordineerida. Seccomp keelab ohtlikud süsteemikõned; Landlock jõustab teekonnapõhised lugemis-/kirjutamisreeglid, lubades neil isegi kasutaja tööruumide kattumist, nii et ignoreeritud failid on täielikult ligipääsmatud või asendatakse kaitstud koopiatega, mida liivakastiprotsessid ei saa lugeda ega muuta.

Üks Linuxi peensus on jõudlus: kõigi ignoreeritud failide uuesti paigaldamine või ümberkirjutamine on liivakasti seadistamise kõige aeglasem osa. macOS-stiilis edasilükatud filtreerimine, mis näeb täpset failiteed süsteemikõne ajal, lihtsustaks seda, kuid Linuxi seccomp-bpf ei tee seda tee kontrollimist lihtsaks, seega on tegemist tõelise inseneritöö kompromissiga tiheda isolatsiooni ja käivituskiiruse vahel.

Windowsis on tõeliselt samaväärse natiivse liivakasti loomine endiselt keerulisem, kuna enamik isolatsiooniprimitiividest on optimeeritud brauseritele, mitte üldotstarbelistele arendustööriistadele. Cursor käitab praegu Windowsi kasutajatele WSL2 sees Linuxi liivakasti, tuginedes sisuliselt Linuxi isolatsioonile, kuni rikkamad primitiivid on saadaval. Nad teevad Microsoftiga koostööd, et paljastada õiged võimalused, et Windowsi agendid saaksid aja jooksul nautida esmaklassilist natiivset liivakasti ilma WSL-ita.

Nende operatsioonisüsteemipõhiste lähenemisviiside ühine joon on ühtne liivakasti API. Agendi seisukohast on tegemist lihtsalt selgete võimaluste ja reeglitega „kestatööriistaga“. Kapoti all jõustavad Seatbelt, Landlock/seccomp või WSL2-põhine isolatsioon neid reegleid platvormiti erinevalt.

Õpetajad liivakasti mõistmiseks ja austamiseks

Liivakast on abiks ainult siis, kui agent oskab ette näha, mis selles töötab ja millal on vaja õigusi laiendada või kastist lahkuda. See kõlab ilmselgelt, kuid praktikas nõudis see kodeerimisagente saatvatelt müüjatelt üllatavalt põhjalikku viipade ja tööriistade disaini iteratsiooni.

Esimene samm, mida paljud meeskonnad tegid, oli tööriistade kirjelduste täiustamine, eriti shelli täitmise osas. Üldise tööriista „run_shell_command” asemel on kirjelduses selgesõnaliselt kirjas, millised ressursid on ligipääsetavad: kas käsul on juurdepääs failisüsteemile, Gitile, võrgule või täielikult võrguühenduseta keskkond, olenevalt kasutaja konfiguratsioonist. Samuti dokumenteeritakse, kuidas agent saab vajadusel taotleda kõrgendatud õigusi (näiteks avaliku internetiühenduse loomiseks). See kiire inseneritöö kipub olema väga empiiriline: meeskonnad käitavad ühiseid juurutamisvooge, jälgivad, kus mudel ennustab võimeid valesti, kohandavad tööriistade kirjeldusi ja kordavad.

Seejärel kasutatakse agendi jõudluse võrdlemiseks liivakasti tehnoloogiaga ja ilma selleta sisemisi võrdlusnäitajaid, näiteks „Cursor Bench” või sarnaseid hindamiskomplekte. Üks varajane rikkerežiim oli väga järjepidev: agent proovis pimesi ikka ja jälle sama ebaõnnestunud terminalikäsku, selle asemel, et aru saada, et see põrkab kokku liivakasti piiranguga. Ilma selge signaalita käsu ebaõnnestumise põhjuse kohta ei suutnud mudel mustrit õppida.

Parandus seisnes liivakasti vigade otseses esiletoomises tööriistade väljundites, sageli koos soovitusega, mida edasi teha. Kui käsk blokeeriti failisüsteemi või võrgureegli tõttu, hakkas shelli tööriist lisama lühikest selgitust, näiteks „liivakasti poolt blokeeritud: väljaminev võrguühendus on selle seansi jaoks keelatud” ja mõnel juhul vihjet, et agent võiks küsida kõrgendatud õigusi. Pärast seda muudatust muutusid agendid palju vastupidavamaks: nad lõpetasid lootusetute käskude tsüklilise täitmise ja kas kohandasid oma plaani või taotlesid vajalikku võimalust.

Offline-hinnangud on abiks, kuid need räägivad ainult osa loost. Et täpselt teada saada, kas liivakastipõhine tehnoloogia halvendab kasutajakogemust, on meeskonnad liivakastipõhise tehnoloogia tuge järk-järgult tootmiskeskkonnas kasutusele võtnud ning jälginud veamäärasid, täitmisaegu ja tagasisidekanaleid. Praktikas teatavad müüjad, et märkimisväärne osa päringutest ühilduvatel platvormidel töötab nüüd täielikult liivakastipõhiselt – kusjuures ettevõttekliendid, nagu NVIDIA, on esimeste kasutuselevõtjate seas – ja et liivakastipõhised agendid peavad reaalsetes töövoogudes kinnitamiseks pausi tegema umbes 40% harvemini, säästes tunde käsitsi ülevaatamisest ja vähendades riski.

Tulevikku vaadates on suur huvi nn natiivsete liivakasti agentide vastu – mudelite vastu, mida treenitakse otse oma keskkonna piirangute järgi. Selle asemel, et käsitleda kesta, brauserit või failisüsteemi abstraktsete tööriistadena, mõistaksid need agendid, et nad elavad kitsa ulatusega käituskeskkonnas, saavad kirjutada pikaealisi skripte ja programme ning peavad järgima piirtingimusi, näiteks „väljaminevat võrku ei ole” või „tööruum on kirjutuskaitstud”. See koolitus võiks aidata neil palju paremini planeerida turvalisi ja tõhusaid toimingute järjestusi ilma nähtamatute seinte vastu rabelemata.

Pilve liivakastid: Cloudflare, Google Cloud, Heroku ja teised

Arendaja sülearvuti kõrval võistleb suur hulk infrastruktuuri pakkujaid, et pakkuda spetsiaalselt tehisintellekti agentidele häälestatud hostitud liivakaste. Nende eesmärgid on samad – isoleerimine, kontroll ja jõudlus –, kuid kompromissid näevad pilvemastaabis veidi erinevad välja.

Cloudflare'i konteinerite baasil loodud ja nüüd üldiselt saadaval olevad Cloudflare'i liivakastid on loodud agentidele täisväärtuslike arenduskeskkondadena. Iga liivakast on püsiv, isoleeritud tööruum, millele annate nime. Kui see on unerežiimis, käivitub see nõudmisel; kui see on jõudeolekus, peatab see automaatselt töö arvutusvõimsuse säästmiseks ja jätkab tööd järgmise päringu korral. Arendajad (või agendid) saavad sellega suhelda tüüpitud meetodite abil, näiteks exec, gitCheckout, writeFileja palju muud, kasutades JavaScripti/TypeScripti SDK-d.

Üks keerulisemaid pilveprobleeme on turvaline autentimine agentide liivakastide seest. Agendid peavad sageli kasutama privaatseid teenuseid, kuid te ei soovi, et toorandmed keskkonnamuutujates vedeleksid. Cloudflare sisestab volikirjad võrgu puhverserveri kihile, kaardistades hosti väljaminevad päringud kohandatud loogikaga, mis lisab turvalisest salvestusruumist tokenid. Liivakasti protsess ei näe kunagi tegelikke saladusi, kuid kõne autentitakse ikkagi. See disain toetab dünaamilist, identiteeditundlikku volikirja sisestamist ja sobib hästi töötajate sidumisega.

Terminalirohkete töövoogude jaoks lisas Cloudflare täieliku PTY (pseudo-terminali) kogemuse, mis on ühendatud WebSocketsi ja xterm.js-i kaudu. Agendid ja inimesed saavad avada reaalajas seansse, katkestada protsesse, hiljem uuesti ühenduda ja varasemat väljundit taasesitada. Igal PTY-l on oma töökataloog ja keskkond ning väljund puhverdatakse serveris, et taasühendavad kliendid saaksid järele jõuda puuduvate logidega.

Lisaks toorele shellile juurdepääsule pakub Cloudflare ka püsivaid „koodi täitmise kontekste” sellistele keeltele nagu Python, JavaScript ja TypeScript. Erinevalt paljudest koodijuppide käivitajatest, mis käivitavad iga fragmendi eraldi, säilitavad need kontekstid muutujad, imporditud andmed ja oleku kõigis kõnedes, sarnaselt Jupyteri märkmikuga. Agendid saavad andmeid laadida ühe kõnega, teisendada neid teises ning renderdada diagramme või HTML-tabeleid ilma pidevalt kõike uuesti parsimata ja importimata.

Veebiarendusülesannete puhul toetavad Cloudflare'i liivakastid taustaprotsesse, tervisekontrolle ja reaalajas eelvaate URL-e. Agent saab alustada npm run dev taustatööna jälgige logisid, kuni server on valmis, ja seejärel avaldage port avaliku eelvaate URL-i taga. Meetodid nagu waitForPort() or waitForLog() laske agentidel toiminguid järjestada reaalsete valmisolekusignaalide, mitte naiivsete põhjal sleep(2s) oletused.

Sündmustepõhised töövood saavad hoogu failide jälgimise primitiividest, mida toetab Linuxi inotify mehhanism. Agent saab muudatustele registreeruda jaotises /workspace/src ja käivitavad testid või järkud automaatselt uuesti, kui TypeScript-faile muudetakse. See on sama tagasisideahel, millele inimarendajad toetuvad, kuid mis on muudetud agendipõhiseks API-de kaudu, näiteks sandbox.watch() ja serveri saadetud sündmuste vooge.

Elutsükli lõpetamiseks võtab Cloudflare kasutusele tõelised hetktõmmised – virtuaalmasina tasemel oleku jäädvustused, mida saab R2 salvestusruumist sekunditega taastada. Hetktõmmised säilitavad failisüsteemi oleku, operatsioonisüsteemi konfiguratsiooni, installitud sõltuvused ja andmefailid; tulevased versioonid taastavad ka reaalajas mälu oleku koheseks jätkamiseks. Agendid (või orkestreerijad) saavad programmiliselt käivitada hetktõmmiseid kontrollpunktide või hajutatud stsenaariumide jaoks ning seejärel samast hetktõmmisest mitu liivakasti eraldada, et uurida paralleelseid hüpoteese eraldi.

Hinnakujunduse osas läks Cloudflare üle „ainult aktiivse protsessori” mudelile: arveldatakse tegelikult kasutatud protsessoritsüklite, mitte jõudeaja eest, mil agendid LLM-e ootavad. Koos suurte samaaegsuse piirangutega „kergetele” ja suurematele instantsidele muudab see teostatavaks suure agentide laevastiku käitamise ilma magamiskoteineritele raha kulutamata.

Google Cloudi GKE Agent Sandbox on seevastu sügavalt integreeritud Kubernetesi ja gVisoriga. Idee on võimaldada teil käitada agentide töökoormusi isoleeritud pod'ides oma klastrite sees. Loote GKE klastri (Autopilot saab gVisori automaatselt lubada, samas kui standardklastrid vajavad selgesõnalisi käitusaja klasse ja gVisori toega sõlmekogumeid) ning seejärel juurutate versioonitud manifestide kaudu agendi liivakasti kontrolleri.

Mudelit juhivad kaks peamist kohandatud ressurssi: SandboxTemplate ja SandboxWarmPool. SandboxTemplate toimib korduvkasutatava plaanina, mis määrab podi malli (pilt, pordid, ressursid, runtimeClassName: gvisorjne) liivakastikeskkonna, näiteks Pythoni keskkonna jaoks. SandboxWarmPool hoiab konfigureeritud arvu eelsoojendatud pod'e peaaegu koheseks kasutamiseks valmis, vältides külmkäivitusi, kui agent vajab värsket keskkonda vähem kui sekundiga.

A Sandbox Router Seejärel toimib teenus väravana klientide ja nende isoleeritud podide vahelise liikluse jaoks. Arenduses saate tunneli liiklust läbida kubectl port-forward ilma avalikke IP-aadresse paljastamata. Tootmises keskkonnas suunatakse ruuter tavaliselt õige sisenemisandme ja mTLS-iga. Kliendi poolel pakub Google Pythoni „Agentic Sandbox” teeki, mis hõlmab kogu elutsüklit: looge malli põhjal liivakasti nõue, oodake, kuni see on valmis, käivitage shellikäsklused ja puhastage pärast lõpetamist.

Kõik see on kapoti all ikka veel „lihtsalt Kubernetes“, kuid pakitud agentide käitusaegade jaoks sidusaks looks. gVisor pakub protsesside ja süsteemikõnede isolatsiooni, SandboxTemplate standardiseerib konfiguratsioonid, WarmPool lahendab käivituslatentsuse ning ruuter ja Pythoni klient muudavad selle mugavaks LLM-kesksete rakenduste jaoks.

Heroku seevastu tugineb väga küpsele ehitusplokile: ühekordsetele dünamodele. Aastaid on Heroku kasutajad käivitanud ad hoc töid – migratsioone, hooldusskripte, administraatori ülesandeid – lühiajalistes dünaamilistes keskkondades, mis käivituvad nõudmisel ja surevad pärast valmimist. Heroku taaskasutas seda infrastruktuuri koodi käivitamise liivakastidena, mis käivitati koos oma hallatavate järelduste ja agentide pakkumistega. Agent kirjutab Pythoni, Ruby, Node'i või Go koodijuppe; Heroku käivitab need lühiajalistes dünaamilistes keskkondades ja voogedastab tulemusi tagasi, piirates plahvatusraadiust ajutise konteinerini.

Nendele liivakastidele pääsete ligi kas Heroku agentide API sisseehitatud tööriistade kaudu või avatud lähtekoodiga Model Context Protocol (MCP) serverite juurutamise kaudu. MCP-serverid pakuvad standardiseeritud tööriistade lõpp-punkte, nii et kliendid nagu Agentforce, Claude Desktop või Cursor saavad Heroku liivakasti käsitleda üldise kaugkoodi käivitamise taustaprogrammina. Iga server toetab käitusajapõhiseid piiranguid (nt max_calls agendi tsükli kohta), et agendid ei satuks kitsastesse ja kulukatesse tsüklitesse.

LangChaini süvaagendid lisavad uue dimensiooni, integreerudes kolmandate osapoolte liivakastiteenuse pakkujatega nagu Runloop, Daytona ja Modal. Muster on lihtne: süvaagent jätkab töötamist kõikjal, kus soovite (lokaalselt või pilves), kuid alati, kui see vajab käskude käivitamist, failide loomist või koodi käivitamist, edastatakse need toimingud kaugliivakasti. Installi skriptid saavad keskkonnamuutujaid eelnevalt laadida, repositooriume kloonida, tööriistu installida ja palju muud, nii et iga agent saab puhta ja kontrollitud keskkonna. Seejärel tegelevad kontekstihaldurid loomise ja puhastamisega, kuigi dokumentatsioon soovitab tungivalt jälgida pakkujate armatuurlaudu unustatud pikalt töötavate liivakastide suhtes.

Jõudlus, olek ja hargnemine: miks kiirus agentide jaoks oluline on

Aeglane, aga üliturvaline liivakast jääb praktikas vahele; arendustööriistad elavad või surevad latentsuse tõttu. Kodeerimisagendid ei käitu nagu öised partiitööd. Nad käitavad interaktiivseid tsükleid: loevad koodi, pakuvad muudatusi, käivitavad teste, analüüsivad logisid, kutsuvad tööriistu, ootavad inimesi ja kordavad seejärel. Päris seanssides uurivad nad ka probleemi mitut haru, loobuvad mõnest marsruudist ja naasevad hiljem teiste juurde.

Seepärast keskenduvad sellised platvormid nagu Freestyle alla sekundi kestvatele virtuaalmasinate elutsükli aegadele ja rikkalikule oleku semantikale. Nende virtuaalmasinad on täisfunktsionaalsed Linuxi masinad, millel on juurjuurdepääs, systemd teenused, pesastatud virtualiseerimise tugi ja täielik võrgustamine. Dokumentatsiooni kohaselt kulub API-kõnest töötava virtuaalmasinani alla 800 ms, peatamine/taaskäivitamine alla 100 ms ning võimalus virtuaalmasinaid käivitamise ajal hetktõmmiseks teha või forkida minimaalse jõudlustakistusega. Nad nimetavad brauseri olekut selgesõnaliselt soodustatud isikuks: kui agent on viinud brauseri huvitavasse olekusse, saab ta selle virtuaalmasina samast hetktõmmisest 20 korda forkida, selle asemel, et seda olekut nullist uuesti luua.

Google'i SandboxWarmPool GKE jaoks väljendab sama ideed Kubernetesi terminites: hoidke eelnevalt soojendatud podide kogumit, et agendid ei peaks iga uue käivitamise eest täielikke külmkäivituse trahve maksma. Daytona hetktõmmistel põhinevad tööruumid koos automaatse peatamise/arhiveerimise/kustutamise poliitikatega häälestavad elutsüklit erinevat tüüpi seansside jaoks: aktiivsed arenduskeskkonnad, ajutised katsed ja pikaajalised baasjooned.

E2B rõhuasetus taustatöödele, jälgitavatele kataloogidele, isoleeritud failisüsteemidele ja korduvkasutatavatele köidetele on sama mündi teine ​​külg. Need funktsioonid võimaldavad agendil hoida arendusserverit või testimisraamistikku töös, samal ajal uurides koodimuudatusi või jagada püsivat mahtu mitme ajutise liivakasti vahel aja jooksul. Ilma selleta käivitavad agendid ühekordseid käske ja kaotavad konteksti, mis vähendab tootlikkust.

Kasulik viis agentide töö liivakasti hindamiseks on esitada paar otsekohest küsimust. Kas ma saan luua värske keskkonna tunduvalt vähem kui sekundiga? Kas ma saan olekut puhtalt salvestada ja taastada, sealhulgas osalisi järke või brauseriseansse? Kas ma saan olekut paralleelseks uurimiseks harutada? Kas ma saan säilitada pikaealisi, kuid ressursisäästlikke tööruume „tule hiljem tagasi” voogude jaoks? Mida rohkem jaatavaid vastuseid saate, seda enam saavad teie agendid käituda nagu päris insenerid, mitte nagu olekuta skriptide käivitajad.

Saladused, võrgupoliitika ja tööruumi usaldus kui tegelik juhtimistasand

Isegi täiusliku hostiisolatsiooni korral on lihtne luua ebaturvalist süsteemi, kui ignoreerida saladusi, võrgupoliitikat ja tööruumi usaldust. Dockeri liivakasti dokumentatsioon on selles osas värskendavalt avameelne. Mikrovirtuaalmasin ja selle privaatne Dockeri deemon moodustavad hostiga peamise usalduspiiri. Selle virtuaalmasina sees on agendil aga täielik juurkasutaja tasemel kontroll ning jagatud tööruum on ühendatud lugemis- ja kirjutamisõigusega. Vaikimisi kajastuvad kõik failimuudatused hostis kohe. Võrgu väljuv ühendus on vaikimisi keelatud ja lubatud ainult selgesõnaliste reeglite alusel ning HTTP-päringud kasutavad hostipoolset puhverserverit, mis saab sisestada volikirju ilma virtuaalmasinale tooreid saladusi avaldamata.

See tähendab, et hosti isoleerimine on alles esimene samm; peate ikkagi mõtlema, mida agent saab tööruumi ja välismaailmaga teha. Dockeri dokumentatsioon hoiatab selgesõnaliselt, et kui agent muudab skripte, mida inimesed hiljem käivitavad – Giti konksud, CI-konfiguratsioonid, IDE-ülesannete definitsioonid, Makefile sihtmärgid package.json skriptid – kahjustus võib nende skriptide käivitamisel „hüpata“ tagasi hosti või CI-süsteemidesse. Nad rõhutavad isegi, et Git haakub .git/ ära ilmu kohale git diff, muutes pahatahtliku loogika vaikse jätkamise lihtsamaks.

Volituste puhverserveri kasutamine on võimas, kuid peen. Dockeri väljaminev puhverserver tagab, et saladused jäävad virtuaalmasinast väljapoole, kuid lubab agendil siiski nende identiteetide abil lubatud hostide vastu tegutseda. Mõned vood – näiteks kohandatud keskkonnamuutujate kirjutamine failidesse, näiteks /etc/sandbox-persistent.sh – murra see piir, salvestades saladusi tahtlikult virtuaalmasinasse, mis on turvaline ainult siis, kui sa agenti ja liivakasti siiralt usaldad.

Konfiguratsiooni ulatus on sama oluline kui saladused. Dockeri KKK märgib, et kasutajataseme konfiguratsioonid, näiteks ~/.claude or ~/.codex Hostilt pärit andmeid ei kopeerita liivakasti; nähtav on ainult jagatud tööruumis olev projekti ulatusega konfiguratsioon. Anthropicu konfiguratsioonidokumentatsioon rõhutab, et projektitaseme sätted – tööriistad, õigused, MCP-serverid, konksud – tühistavad kasutajataseme sätted ja neid jagatakse meeskondade vahel. Teisisõnu, kõik poliitikad, juhised ja pluginad, mille repositooriumile lisate, saavad agendi peamiseks pinnaks.

OpenAI oskuste juhised toovad esile sarnaseid punkte veidi erinevas sõnavaras. Oskused (tööriistapaketid) võivad kaasa tuua kiire süstimise teel juhitud andmete väljavoolu riske. Dokumentatsioonis hoiatatakse kureerimata avaliku oskuste turuplatsi otse lõppkasutajatele paljastamise eest, kuna pahatahtlikud SKILL.md-failid võivad tühistada poliitikaid, käivitada hävitavaid toiminguid või lekitada privaatseid andmeid. Nad soovitavad arendajate oskusi kontrollida, piirata neid konkreetsete töövoogudega, peita suure mõjuga toimingud täiendavate kinnituste ja poliitikakontrollide taha ning käsitleda oskusi osana oma ohumudelist.

Kui tükid kokku panna, hõlmab agentide liivakastide „päris” juhtimistasand nelja kihti. Hostiisolatsioon kaitseb teie masinaid ja klastri sõlmi. Tööruumi usaldus kaitseb tulevast inimest või CI-d, kes käitab liivakastis loodud faile. Võrgupoliitika kaitseb väliseid süsteeme ja privaatseid andmeallikaid. Volituste haldus kaitseb identiteete, mille kaudu agent saab tegutseda. Tugev disain pakub vastuseid kõigile neljale, mitte ainult esimesele.

Lisaks on teil vaja tervet skepsist kiire süstimise ja agentide kaaperdamise suhtes. NIST, OWASP ja OpenAI kirjeldavad kõik sama mustri variante: ebausaldusväärne sisend – README, veebileht, logifail – sisaldab pahatahtlikke juhiseid, mis suunavad agendi käitumist. Otsingu abil laiendatud genereerimine ja peenhäälestamine seda maagiliselt ei lahenda. Hästi instrumenteeritud liivakast koos hea poliitikaga ei saa takistada mudeli petmist, kuid need võivad negatiivseid tagajärgi dramaatiliselt vähendada, kui neid petetakse.

Pilveplatvormid ja agentide käituskeskkonnad hakkavad neid õppetunde kodeerima. Salajased puhverserverid, lubatud nimekirjas olevad väljaminevad domeenid, repo ulatusega konfiguratsioonid, kitsamate võimalustega alamagendid, konksupõhised kinnitusvood ja reprodutseeritavad liivakastid on kõik sama pusle tükid: tuleb aktsepteerida, et mudelid on ekslikud, ja kujundada keskkond nii, et selle ekslikkuse hind jääks piiratudks.

Nii kohalikes kui ka pilvepõhistes seadistustes on agentide täitmisliivakasti kõige parem käsitleda hoolikalt tõmmatud piirina: see ei muuda mudelit nutikamaks, vaid muudab selle vead vähem katastroofilisteks ja paremini jälgitavaks. Õige failisüsteemi, protsessi, võrgu, salajase võtme ja elutsükli kontrolli kombinatsiooniga ning agendi nutika õpetamisega oma keskkonna kohta saate lasta tehisintellekti süsteemidel kloonida repositooriume, käivitada teste, käivitada brausereid ja isegi puudutada tootmislaadseid süsteeme – ilma et peaksite neile andma võtmeid kõige jaoks, mis teile oluline on.

See tähendab, et hosti isoleerimine on alles esimene samm; peate ikkagi mõtlema, mida agent saab tööruumi ja välismaailmaga teha, sealhulgas riesgos como. koodi kaugkäivitamine. Dockeri dokumentatsioon hoiatab selgesõnaliselt, et kui agent muudab skripte, mida inimesed hiljem käivitavad – Giti konksud, CI-konfiguratsioonid, IDE-ülesannete definitsioonid, Makefile sihtmärgid package.json skriptid – kahjustus võib skriptide käivitamisel tagasi host- või CI-süsteemidesse „hüpata“.

trampa de dependencias de modelos de lenguaje
Seotud artikkel:
La trampa de dependencia de los LLM: límites, sesgos ja riesgos
Seonduvad postitused: