Agentin rakentaminen ei ole helppoa.
Vuosi sitten meidän piti itse hallita kontekstia ja muistia, miettiä RAG:ia ja vektorikantoja sekä säätää työkalujen tarkkuutta erittäin huolellisesti. Claude Code / Claude Agent SDK:n tulo muutti tämän kaiken. Nyt yhä useammat tiimit rakentavat agentteja suoraan Claude Agent SDK:n ja VM:n avulla. Onko ongelma siis yksinkertaistunut? Ei.
Claude Coden ajaminen virtuaalikoneissa on edelleen hyvin haastavaa.
-
Jokainen käyttäjäistunto tarvitsee oman virtuaalikoneen. Joissain tilanteissa VM:n pysyvyysominaisuudesta voi olla hyötyä, mutta se tekee myös VM:stä vaikeasti päivitettävän ja orkestroitavan. Esimerkiksi käyttäjän näkökulmasta he toivovat, että VM:ään asennetut ohjelmistot ovat käytettävissä vielä kuukausienkin päästä. Mutta VM:llä olevien orkestrointikerroksen kanssa kommunikoivien osien täytyy myös pystyä päivittymään.
-
Virtuaalikoneiden luominen ja orkestrointi suuressa mittakaavassa. Yksi k8s-klusteri tukee orkestrointia noin muutamalle tuhannelle podille, mikä riittää sovelluspalveluklustereille. Mutta se ei riitä tilanteisiin, joissa jokainen istunto tarvitsee oman claude code -podin.
-
K8s-ratkaisujen käyttö tuo mukanaan k8s:n aiheuttaman viiveen, jolloin suorituskyky alle 1 sekunnissa on vaikea saavuttaa.
-
E2b-ratkaisun käyttö vaatii pysyvyyden toteuttamista itse, ja tiedostojen lataaminen sekä lähettäminen on molemmat hyvin hidasta.
-
E2b-ratkaisu ei täytä tiettyjä verkkoympäristövaatimuksia, ja yksityinen käyttöönotto on hankalaa.
Miten nämä ongelmat ratkaistaan? Otetaan oppia historiasta. Kun kalenteri käännettiin yli kymmenen vuotta taaksepäin, vuonna 2012, serverlessiä ei ollut olemassa, ei ollut k8s:ää eikä dockeria. Taustakehittäjien piti ylläpitää palveluprosessia fyysisellä koneella manuaalisesti palvelun ajamiseksi. Silloin ssh ja ansible olivat palvelininsinöörien perustyökaluja. Palveluprosessit olivat vahvasti riippuvaisia fyysisen koneen erilaisista työkaluympäristöistä. Työkaluympäristöjen yhdenmukaisuuden saavuttaminen fyysisten koneiden välillä oli hyvin haastavaa, ja laajamittainen skaalaus vaati tiimeiltä pitkän valmistautumisen. Muistan yhä, kun eräs insinööri muutti yhden koneen ympäristöä ja unohti synkronoida muutoksen muille koneille, mikä aiheutti tuotannossa erittäin vaikeasti jäljitettävän haamubugin. Se aika oli kivulias ja vanhanaikainen.
Vuonna 2012 docker ilmestyi. Docker paketoi kaikki työkaluympäristöt yhteen imageen, ratkaisten ympäristöjen epäyhtenäisyyden. Yhteisö huomasi vähitellen, että virtuaalikoneessa fyysisellä koneella ajettavaa palveluprosessia voitiin hallita kuin fyysisen koneen prosessia. Mutta dockerin orkestrointi vaati silti kehitystiimeiltä oman orkestrointijärjestelmän rakentamista. Ja kun dockerin sisäinen palveluprosessi kytkeytyi fyysisen koneen verkkoon ja tiedostojärjestelmään, orkestrointi muuttui hyvin hankalaksi.
Vuonna 2014 tilattomat palvelut alkoivat nousta valtavirtaan. Silloin syntyivät Kubernetes ja AWS Lambda. Ne kuvasivat tilattomien palveluiden tulevaisuutta eri näkökulmista. Tilattomat palvelut tarkoittivat, että palvelulogiikka ei enää kytkeytynyt verkko-osoitteisiin eikä ollut paikallisesti riippuvainen pysyvästä tiedostojärjestelmästä.
Sitten tuli 10 pilvinatiivien vuosia, jolloin tilattomien palveluiden aalto synnytti suuren joukon pilvinatiivia infrastruktuuria, kuten:
- Palveluväylät Istio/Linkerd/Envoy/Treafik
- CI/CD-alustat Argo CD / Flux
- Havainnointialustat Prometheus/Grafana/ELK Stack
- Kutsuketjuanalyysi Jaeger/Zipkin/OpenTelemetry
- Tallennus Rook/MinIO/JuiceFS
Ja nyt olemme uuden alun äärellä. Kymmenen vuotta sitten laskentayksikkö oli java/python api -palveluprosessi. Tästä vuodesta alkaen laskentayksikkö on koodausagentti.
ACFS on kuin aika, jolloin palveluprosesseja ylläpidettiin manuaalisesti fyysisillä koneilla. E2B on kuin Docker. Ilman tehtävien orkestrointialustoja, havainnointialustoja ja hajautettua tilan pysyvyyttä skaalaus on edelleen vaikeaa koodausagenteille. Ja Serverless Agent Infra, jota odotan, sisältää nämä ominaisuudet:
- Pystyy sopivasti säilyttämään koodausagentin istunnot ja työskentelyhakemistot ilman kontekstin menetystä.
- Erittäin nopea, koodausagentti toimii 100 ms:n sisällä.
- Agentin käyttäytymisestä löytyy lokitus / metriikka / jäljitys, jotka ovat ihmisille helposti ymmärrettäviä, mikä helpottaa agentin käyttäytymismallien ymmärtämistä ja säätämistä.
- Kehittäjien ei enää tarvitse välittää yksityiskohdista kuten virtuaalikoneista, konteista tai muista ylläpitoyksityiskohdista, mikä tekee laajamittaisesta orkestroinnista hyvin helppoa.
Uskon, että kaikki infrastruktuuri, joka täyttää nämä vaatimukset, on jo olemassa, esimerkiksi firecracker on osoittanut microVM:ien suorituskyvyn ja vakauden, ja hajautettuihin havainnointialustoihin ja tiedostojärjestelmiin on monia vaihtoehtoja. Mutta kehittäjänä, joka on käyttänyt e2b:tä claude coden kapselointiin, näiden yhdistäminen on silti hyvin vaikeaa. Esimerkiksi kun claude code E2B:ssä keskeytyy yllättäen OOM:n vuoksi, insinöörien on vaikea havaita tätä, ja vielä vaikeampaa on saada tilanteen tiedot ja lokit talteen.
Toivon, että kehittäjien vuonna 2026 jälkeen ei tarvitse käydä läpi näin kivuliasta prosessia, aivan kuten useimpien insinöörien vuonna 2026 ei enää tarvitse käyttää ssh:ta fyysisten koneiden manuaaliseen alustamiseen.
Tämä on VM0:n unelma. Toivon, että jonain päivänä voin ohjata koodausagenttia ergonomisen API:n kautta, esimerkiksi näin:
cosnt agent = vm0.run({
framework: 'claude-code',
prompt: 'buy me a coffee'
})
