Serverless agent

Vytvořit agenta není snadné.

Ještě před rokem jsme museli sami spravovat kontext a paměť, řešit RAG a vektorové databáze a velmi pečlivě ladit přesnost používání nástrojů. S příchodem Claude Code / Claude Agent SDK se toto vše změnilo. Stále více týmů začíná stavět agenty přímo pomocí Claude Agent SDK + VM. Je tedy problém jednodušší? Ne.

Provozovat Claude Code ve VM je stále velmi náročné.

1. Každá uživatelská relace potřebuje samostatnou VM. V některých scénářích je perzistence VM užitečná, ale zároveň ztěžuje jejich aktualizaci a orchestraci. Například uživatelé očekávají, že software nainstalovaný ve VM bude dostupný i po několika měsících. Ale části VM, které komunikují s vrstvou orchestrace, musí být zároveň schopné přijímat aktualizace.

2. Vytváření a orchestraci VM ve velkém měřítku. Jeden k8s cluster zvládne orchestraci několika tisíc podů, což stačí pro aplikační služby. Ale nestačí to pro scénáře, kde každá relace potřebuje spustit claude code pod.

3. Použití k8s řešení přináší latenci způsobenou k8s, což ztěžuje dosažení výkonu do 1 sekundy.

4. Řešení e2b vyžaduje vlastní perzistenci a nahrávání/sdílení souborů je velmi pomalé.

5. Řešení e2b nesplňuje specifické požadavky na síťové prostředí a privátní nasazení je složité.

Jak tyto problémy řešit? Poučme se z historie. Před více než deseti lety, v roce 2012, neexistoval serverless, k8s ani docker. Backend inženýři museli ručně spravovat procesy služeb na fyzických serverech. Tehdy byly ssh a ansible standardními nástroji serverových inženýrů. Procesy služeb silně závisely na různých nástrojích a prostředích na fyzickém stroji. Dosáhnout konzistentního nastavení prostředí napříč servery bylo velmi náročné a škálování do většího rozsahu vyžadovalo dlouhodobou přípravu. Pamatuji si, jak jeden inženýr změnil prostředí na jednom stroji a zapomněl jej synchronizovat na ostatní, což způsobilo těžko odhalitelnou chybu v produkci. Bylo to velmi bolestivé období.

V roce 2012 se objevil docker. Docker zabalil všechna prostředí do jednoho image a vyřešil problém nekonzistence prostředí. Komunita si postupně uvědomila, že proces služby běžící ve virtuálním stroji na fyzickém serveru lze spravovat jako proces na fyzickém stroji. Ale orchestraci dockeru musely týmy stále řešit samy. A jakmile se proces uvnitř dockeru provázal se sítí nebo souborovým systémem fyzického stroje, orchestraci to velmi zkomplikovalo.

V roce 2014 se začaly prosazovat bezstavové služby. Tehdy vznikly Kubernetes a AWS Lambda. Každý z těchto projektů popsal budoucnost bezstavových služeb z jiného úhlu. Bezstavové služby znamenaly, že logika služby se vyhýbala vazbě na síťové adresy a již nebyla závislá na lokálním perzistentním úložišti.

Pak přišla léta 10 cloud native, vlna bezstavových služeb přinesla řadu cloud native infrastruktur, například:

• Service gateways Istio/Linkerd/Envoy/Treafik
• CI/CD platformy Argo CD / Flux
• Platformy pro pozorovatelnost Prometheus/Grafana/ELK Stack
• Analýza volání Jaeger/Zipkin/OpenTelemetry
• Úložiště Rook/MinIO/JuiceFS

A nyní jsme na novém začátku. Před deseti lety byla výpočetní jednotkou java/python api služba. Od letoška se touto jednotkou stává coding agent.

ACFS je jako éra ruční správy procesů na fyzických serverech. E2B je jako Docker. Bez platforem pro orchestraci úloh, pozorovatelnost a distribuovanou perzistenci je škálování coding agentů stále obtížné. A Serverless Agent Infra, kterou očekávám, má tyto schopnosti:

1. Umí vhodně perzistovat relace a pracovní adresáře coding agenta bez ztráty kontextu.
2. Je extrémně rychlá, coding agent je připraven do 100 ms.
3. Má logování / metriky / tracing chování agenta, které jsou snadno pochopitelné pro lidi, což usnadňuje pochopení a úpravu vzorců chování agenta.
4. Vývojáři se už nemusí starat o detaily jako VM, kontejnery a další provozní záležitosti, což výrazně zjednodušuje orchestraci ve velkém měřítku.

Myslím, že infrastruktura splňující tyto požadavky už existuje – například firecracker prokázal výkon a stabilitu microVM, a existuje mnoho možností pro distribuovanou pozorovatelnost a souborová úložiště. Ale jako vývojář, který má zkušenost s použitím e2b pro zabalení claude code, vím, že integrace těchto prvků je stále velmi obtížná. Například když je claude code v E2B nečekaně ukončen kvůli OOM, je pro inženýry těžké to monitorovat a ještě těžší získat tehdejší stav a logy.

Doufám, že vývojáři po roce 2026 už nebudou muset procházet tak bolestivým procesem, stejně jako většina inženýrů v roce 2026 už nemusí ručně inicializovat fyzické servery přes ssh.

To je sen VM0. Doufám, že jednoho dne budu moci ovládat coding agenta přes ergonomické API, například:

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