Agent bezserwerowy

Budowanie Agenta nie jest łatwe.

Rok temu musieliśmy sami zarządzać kontekstem i pamięcią, myśleć o RAG i bazach wektorowych oraz bardzo precyzyjnie dostrajać dokładność korzystania z narzędzi. Pojawienie się Claude Code / Claude Agent SDK wszystko to zmieniło. Coraz więcej zespołów zaczyna teraz bezpośrednio budować Agentów przy użyciu Claude Agent SDK + VM. Czy problem stał się prostszy? Nie.

Uruchamianie Claude Code na VM-ach nadal jest bardzo wymagające.

1. Każda sesja użytkownika wymaga niezależnej maszyny wirtualnej. W niektórych scenariuszach trwałość VM-ów może być przydatna, ale jednocześnie utrudnia ich aktualizację i orkiestrację. Na przykład z perspektywy użytkownika oczekuje się, że oprogramowanie zainstalowane na VM będzie dostępne nawet po kilku miesiącach. Jednak elementy na VM, które komunikują się z warstwą orkiestracji, również muszą umożliwiać wdrażanie aktualizacji.

2. Tworzenie i orkiestracja VM-ów na dużą skalę. Pojedynczy klaster k8s obsługuje orkiestrację kilku tysięcy podów, co wystarcza dla klastrów usług aplikacyjnych. Jednak nie jest to wystarczające w scenariuszach, gdzie każda sesja musi uruchomić pod z claude code.

3. Korzystanie z rozwiązań k8s wiąże się z opóźnieniami generowanymi przez k8s, co utrudnia osiągnięcie wydajności w czasie 1 sekundy.

4. Rozwiązania e2b wymagają samodzielnego zapewnienia trwałości, a przesyłanie i pobieranie plików jest bardzo powolne.

5. Rozwiązanie e2b nie spełnia wymagań dotyczących specyficznych środowisk sieciowych, a wdrożenie prywatne jest uciążliwe.

Jak rozwiązać te problemy? Uczmy się z historii. Cofnijmy się ponad dekadę, do roku 2012, kiedy nie było jeszcze bezserwerowości, k8s ani dockera. Inżynierowie backendu musieli ręcznie utrzymywać procesy usług na fizycznych maszynach, aby uruchomić usługę. W tamtym czasie ssh i ansible były standardowymi narzędziami inżynierów serwerowych. Procesy usług silnie zależały od różnych środowisk narzędziowych na fizycznej maszynie. Zapewnienie spójnej konfiguracji środowisk narzędziowych na wielu maszynach było bardzo trudne, a skalowanie na dużą skalę wymagało od zespołów długotrwałych przygotowań. Pamiętam, jak inżynier zmienił środowisko na jednej maszynie i zapomniał zsynchronizować je z innymi, co spowodowało trudny do wykrycia błąd produkcyjny. To był bardzo bolesny okres.

W roku 2012 pojawił się docker. Docker spakował wszystkie środowiska narzędziowe w jeden obraz, rozwiązując problem niespójności środowisk. Społeczność stopniowo zdała sobie sprawę, że proces usługi uruchamiany w maszynie wirtualnej na fizycznej maszynie można zarządzać jak procesem na fizycznej maszynie. Jednak orkiestracja dockera nadal wymagała od zespołów inżynierskich budowy własnego systemu orkiestracji. A gdy proces usługi wewnątrz dockera był powiązany z siecią i systemem plików fizycznej maszyny, orkiestracja stawała się bardzo trudna.

W roku 2014 usługi bezstanowe zaczęły być głównym nurtem. Wtedy narodziły się Kubernetes i AWS Lambda. Każde z nich opisywało przyszłość usług bezstanowych z innej perspektywy. Usługi bezstanowe oznaczały, że logika usługi unikała powiązań z adresami sieciowymi i nie polegała już lokalnie na trwałych systemach plików.

Następnie nadeszły lata 10 cloud native, a fala usług bezstanowych dała początek wielu rozwiązaniom infrastrukturalnym cloud native, takim jak:

• Bramki usług Istio/Linkerd/Envoy/Treafik
• Platformy CI/CD Argo CD / Flux
• Platformy obserwowalności Prometheus/Grafana/ELK Stack
• Analiza ścieżek wywołań Jaeger/Zipkin/OpenTelemetry
• Przechowywanie Rook/MinIO/JuiceFS

Teraz jesteśmy u nowego początku. Dziesięć lat temu jednostką obliczeniową był proces usługi api java/python. Od tego roku tą jednostką stał się agent kodujący.

ACFS przypomina erę ręcznego utrzymywania procesów usług na fizycznych maszynach. E2B jest jak Docker. Bez platform orkiestracji zadań, platform obserwowalności i rozproszonego trwałego przechowywania stanu, skalowalność nadal jest trudna dla agentów kodujących. A oczekiwana przeze mnie infrastruktura Serverless Agent Infra powinna mieć takie możliwości:

1. Umie odpowiednio utrwalać sesje agenta kodującego i katalogi robocze bez utraty kontekstu.
2. Bardzo szybka, pozwalająca uruchomić agenta kodującego w ciągu 100 ms.
3. Posiada logowanie / metryki / śledzenie zachowań Agenta w sposób zrozumiały dla ludzi, co ułatwia zrozumienie i dostosowanie wzorców zachowań Agenta.
4. Programiści nie muszą już przejmować się szczegółami maszyn wirtualnych, kontenerów i innymi detalami operacyjnymi, co bardzo ułatwia orkiestrację na dużą skalę.

Uważam, że cała infrastruktura spełniająca te wymagania już istnieje, na przykład firecracker potwierdził wydajność i stabilność microVM-ów, a rozwiązań do rozproszonej obserwowalności i przechowywania plików jest wiele. Jednak jako programista, który korzystał z e2b do opakowania claude code, wiem, że integracja tych elementów nadal jest bardzo trudna. Na przykład, gdy claude code w E2B zostanie niespodziewanie przerwany przez OOM, inżynierom trudno to monitorować, a jeszcze trudniej uzyskać stan i logi z tego momentu.

Mam nadzieję, że programiści po roku 2026 nie będą musieli przechodzić przez tak bolesny proces, tak jak większość inżynierów w roku 2026 nie musi już używać ssh do ręcznej inicjalizacji fizycznych maszyn.

To jest marzenie VM0. Mam nadzieję, że pewnego dnia będę mógł sterować agentem kodującym przez ergonomic API, na przykład:

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