Serverlös agent

Att bygga en agent är inte lätt.

För ett år sedan behövde vi själva hantera kontext och minne, tänka på RAG och vektordatabaser, och mycket noggrant justera verktygsanvändningens noggrannhet. Framväxten av Claude Code / Claude Agent SDK förändrade allt detta. Nu börjar fler och fler team bygga agenter direkt med Claude Agent SDK + VM. Har problemet blivit enklare? Nej.

Att köra Claude Code i VMs är fortfarande mycket utmanande.

1. Varje användarsession kräver en egen VM. I vissa scenarier kan VM:ers persistensförmåga vara användbar, men det gör också VMs svåra att uppgradera och orkestrera. Till exempel hoppas användare att programvara installerad på VM:n fortfarande är tillgänglig månader senare. Men de delar på VM:n som kommunicerar med orkestreringslagret måste också kunna uppgraderas.

2. Att skapa och orkestrera VMs i stor skala. Ett enda k8s-kluster stödjer orkestrering för några tusen pods, vilket räcker för applikationsservicekluster. Men det är inte tillräckligt för scenarier där varje session behöver starta en claude code-pod.

3. Att använda k8s-lösningar innebär latens från k8s, vilket gör det svårt att uppnå prestanda inom 1 sekund.

4. Att använda e2b-lösningar kräver att du själv hanterar persistens, och att ladda upp/ned filer går mycket långsamt.

5. E2b-lösningen kan inte möta specifika krav på nätverksmiljö, och privat installation är omständlig.

Hur löser vi dessa problem? Låt oss lära av historien. För över ett decennium sedan, i 2012, fanns det inget serverless, ingen k8s och ingen docker. Backend-utvecklare behövde manuellt underhålla en tjänsteprocess på en fysisk maskin för att köra en tjänst. Då var ssh och ansible standardverktyg för serveringenjörer. Tjänsteprocesser var starkt beroende av olika verktygsmiljöer på den fysiska maskinen. Att uppnå konsekventa verktygsmiljöer över flera fysiska maskiner var mycket utmanande, och storskalig uppskalning krävde lång förberedelse. Jag minns fortfarande när en ingenjör ändrade miljön på en maskin och glömde synka till de andra, vilket orsakade en svårfelsökt spökbugg i produktion. Den perioden var en smärtsam gammal tid.

I 2012 dök docker upp. Docker paketerade alla verktygsmiljöer i en enda image och löste problemet med inkonsekventa miljöer. Communityn insåg gradvis att en tjänsteprocess som körs i en virtuell maskin på en fysisk maskin kunde hanteras som en process på den fysiska maskinen. Men docker-orkestrering krävde fortfarande att utvecklingsteam byggde ett orkestreringssystem. Och när tjänsteprocessen i docker blev kopplad till den fysiska maskinens nätverk och filsystem blev orkestreringen mycket smärtsam.

I 2014 började stateless-tjänster bli den dominerande trenden. Det året föddes Kubernetes och AWS Lambda. De beskrev framtiden för stateless-tjänster ur olika perspektiv. Stateless-tjänster innebar att tjänstelogik undvek koppling till nätverksadresser och inte längre var lokalt beroende av persistenta filsystem.

Sedan kom 10-åren med cloud native, där vågen av stateless-tjänster gav upphov till en mängd cloud native-infrastruktur, såsom:

• Tjänstegateways Istio/Linkerd/Envoy/Treafik
• CI/CD-plattformar Argo CD / Flux
• Observabilitetsplattformar Prometheus/Grafana/ELK Stack
• Spårningsanalys Jaeger/Zipkin/OpenTelemetry
• Lagring Rook/MinIO/JuiceFS

Och nu står vi inför en ny början. För tio år sedan var en beräkningsenhet en java/python api-tjänsteprocess. Från och med i år har denna beräkningsenhet blivit en kodande agent.

ACFS liknar tiden då man manuellt underhöll tjänsteprocesser på fysiska maskiner. E2B är som Docker. Utan plattformar för uppgiftsorkestrering, observabilitet och distribuerad lagring av tillstånd är skalbarhet fortfarande svårt för kodande agenter. Och den serverlösa agentinfrastruktur jag förväntar mig har dessa egenskaper:

1. Kan på lämpligt sätt lagra kodagentens sessioner och arbetskataloger utan att tappa kontext.
2. Supersnabb, kan få en kodagent att arbeta inom 100 ms.
3. Har loggning/metrics/spårning för agentbeteende som är lätt för människor att förstå, vilket gör det enklare för människor att förstå och justera agentens beteendemönster.
4. Utvecklare behöver inte längre bry sig om detaljer som virtuella maskiner, containrar och annan drift, vilket gör storskalig orkestrering mycket enkel.

Jag anser att all infrastruktur som kan möta dessa krav redan finns, till exempel har firecracker visat prestanda och stabilitet för microVMs, och det finns många val för distribuerade observabilitetsplattformar och filsystem. Men som utvecklare som har erfarenhet av att använda e2b för att kapsla in claude code är det fortfarande mycket svårt att integrera allt detta. Till exempel, när claude code i E2B oväntat avbryts av OOM är det svårt för ingenjörer att övervaka detta, och ännu svårare att få tillgång till situationen och loggarna vid det tillfället.

Jag hoppas att utvecklare efter 2026 inte behöver gå igenom en så smärtsam process, precis som de flesta ingenjörer i 2026 inte längre behöver använda ssh för att manuellt initiera fysiska maskiner.

Detta är VM0:s dröm. Jag hoppas att jag en dag kan styra en kodande agent via ett ergonomiskt API, som:

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