Serverless-agent

At bygge en agent er ikke let.

For et år siden skulle vi selv håndtere kontekst og hukommelse, tænke på RAG og vektordatabaser og meget nøje justere værktøjspræcision. Fremkomsten af Claude Code / Claude Agent SDK ændrede alt dette. Nu begynder flere og flere teams at bygge agenter direkte med Claude Agent SDK + VM. Er problemet så blevet enklere? Nej.

At køre Claude Code i VM'er er stadig en meget udfordrende opgave.

1. Hver brugersession kræver en uafhængig VM. I nogle scenarier kan VM'ers persistens være nyttig, men det gør også VM'er svære at opgradere og orkestrere. For eksempel håber brugerne, at software installeret på VM'en stadig er tilgængelig måneder senere. Men de dele på VM'en, der kommunikerer med orkestreringslaget, skal også kunne opgraderes løbende.

2. Oprettelse og orkestrering af VM'er i stor skala. Et enkelt k8s-kluster understøtter orkestrering af et par tusinde pods, hvilket er nok til applikationsserviceklustre. Men det er ikke helt nok til scenarier, hvor hver session skal starte en claude code pod.

3. Brug af k8s-løsninger medfører den latenstid, k8s giver, hvilket gør det svært at opnå ydeevne inden for 1 sekund.

4. Brug af e2b-løsninger kræver, at man selv håndterer persistens, og upload/download af filer er begge meget langsomme.

5. E2b-løsningen kan ikke opfylde specifikke krav til netværksmiljø, og privat udrulning er besværlig.

Hvordan løser vi disse problemer? Lad os lære af historien. For over et årti siden, i 2012, fandtes der ikke serverless, ingen k8s og ingen docker. Backend-udviklere skulle manuelt vedligeholde en serviceproces på en fysisk maskine for at køre en tjeneste. Dengang var ssh og ansible standardværktøjer for serverteknikere. Serviceprocesser var stærkt afhængige af forskellige værktøjsmiljøer på den fysiske maskine. At opnå ensartede værktøjsmiljøkonfigurationer på tværs af fysiske maskiner var meget udfordrende, og skalering i stor skala krævede omfattende forberedelse. Jeg husker stadig, da en udvikler ændrede miljøet på én maskine og glemte at synkronisere det til de andre maskiner, hvilket forårsagede en meget svær spøgelsesfejl at fejlfinde i produktionen. Den periode var en meget smertefuld tid.

I 2012 dukkede docker op. Docker pakkede alle værktøjsmiljøer i ét enkelt image og løste problemet med miljøinkonsistens. Fællesskabet indså gradvist, at en serviceproces, der kører i en virtuel maskine på en fysisk maskine, kunne administreres som en proces på den fysiske maskine. Men docker-orkestrering krævede stadig, at udviklingsteams byggede et orkestreringssystem. Og når serviceprocessen inde i docker blev koblet til den fysiske maskines netværk og filsystem, blev orkestrering meget besværligt.

I 2014 begyndte stateless-tjenester at blive den dominerende trend. Det år blev Kubernetes og AWS Lambda født. De beskrev hver især fremtiden for stateless-tjenester fra forskellige vinkler. Stateless-tjenester betød, at servicelogik undgik kobling til netværksadresser og ikke længere var afhængig af lokale persistente filsystemer.

Så kom 10-årene med cloud native, hvor bølgen af stateless-tjenester gav anledning til en stor mængde cloud native-infrastruktur, såsom:

• Servicegateways: Istio/Linkerd/Envoy/Treafik
• CI/CD-platforme: Argo CD / Flux
• Observabilitetsplatforme: Prometheus/Grafana/ELK Stack
• Kaldkædeanalyse: Jaeger/Zipkin/OpenTelemetry
• Lagring: Rook/MinIO/JuiceFS

Og vi står nu ved en ny begyndelse. For ti år siden var en compute-enhed en java/python api-serviceproces. Fra i år er denne compute-enhed blevet en coding agent.

ACFS svarer til tiden, hvor man manuelt vedligeholdt serviceprocesser på fysiske maskiner. E2B svarer til Docker. Uden task-orkestreringsplatforme, observabilitetsplatforme og distribueret persistenslagring er skalerbarhed stadig svært for coding agents. Og den Serverless Agent Infra, jeg forventer, har disse egenskaber:

1. Kan passende persistere coding agent-sessioner og arbejdsmapper uden at miste kontekst.
2. Superhurtig, kan få en coding agent i gang på under 100 ms.
3. Har Logging / Metric / Tracing for agentadfærd, der er let for mennesker at forstå, så det er lettere at forstå og justere agentens adfærdsmønstre.
4. Udviklere behøver ikke længere bekymre sig om detaljer som virtuelle maskiner, containere og andre driftsdetaljer, hvilket gør orkestrering i stor skala meget let.

Jeg mener, at al den infrastruktur, der kan opfylde disse egenskaber, allerede er klar – for eksempel har firecracker valideret ydeevne og stabilitet for microVMs, og der er mange muligheder for distribuerede observabilitetsplatforme og filsystemer. Men som udvikler, der har prøvet at indkapsle claude code med e2b, er det stadig meget svært at integrere det hele. For eksempel, når claude code i E2B uventet afbrydes af OOM, er det svært for udviklere at overvåge dette, og endnu sværere at få adgang til situationen og loggene på det tidspunkt.

Jeg håber, at udviklere efter 2026 ikke skal igennem en så smertefuld proces, ligesom de fleste udviklere i 2026 ikke længere behøver at bruge ssh til manuelt at initialisere fysiske maskiner.

Dette er VM0's drøm. Jeg håber, at jeg en dag kan styre en coding agent gennem et ergonomisk API, som:

cosnt agent = vm0.run({
	framework: 'claude-code',
	prompt: 'buy me a coffee'
})