Serverloser Agent

Einen Agenten zu bauen ist nicht einfach.

Vor einem Jahr mussten wir Kontext und Gedächtnis selbst verwalten, über RAG und Vektordatenbanken nachdenken und die Tool-Nutzungsgenauigkeit sehr sorgfältig anpassen. Das Erscheinen von Claude Code / Claude Agent SDK hat all das verändert. Immer mehr Teams beginnen, Agenten direkt mit Claude Agent SDK + VM zu bauen. Hat sich das Problem vereinfacht? Nein.

Claude Code in VMs zu betreiben ist immer noch eine sehr anspruchsvolle Aufgabe.

1. Jede Benutzersitzung benötigt eine unabhängige VM. In manchen Szenarien kann die Persistenzfähigkeit von VMs nützlich sein, aber sie macht VMs auch schwer zu upgraden und zu orchestrieren. Zum Beispiel hoffen Benutzer, dass auf der VM installierte Software auch Monate später noch verfügbar ist. Aber die Teile auf der VM, die mit der Orchestrierungsschicht kommunizieren, müssen auch in der Lage sein, Upgrades auszurollen.

2. VMs in großem Maßstab erstellen und orchestrieren. Ein einzelner k8s-Cluster unterstützt die Orchestrierung für etwa einige tausend Pods, was für Anwendungs-Service-Cluster ausreichend ist. Aber es reicht nicht ganz für Szenarien, in denen jede Sitzung einen Claude Code Pod starten muss.

3. Die Verwendung von k8s-Lösungen sieht sich mit der Latenz von k8s konfrontiert, was es schwer macht, Leistung innerhalb von 1 Sekunde zu erreichen.

4. Bei der Verwendung von e2b-Lösungen muss die Persistenz selbst übernommen werden, und das Hochladen/Herunterladen von Dateien ist sehr langsam.

5. Die e2b-Lösung kann spezifische Netzwerkumgebungsanforderungen nicht erfüllen, und die private Bereitstellung ist umständlich.

Wie lösen wir diese Probleme? Lernen wir von der Geschichte. Als der Kalender auf vor über einem Jahrzehnt zurückdrehte, im Jahr 2012, gab es kein Serverless auf der Welt, kein k8s, und kein Docker. Backend-Ingenieure mussten einen Service-Prozess auf einer physischen Maschine manuell warten, um einen Service zu betreiben. Zu dieser Zeit waren SSH und Ansible Standard-Tools für Server-Ingenieure. Service-Prozesse hingen stark von verschiedenen Tool-Umgebungen auf der physischen Maschine ab. Konsistente Tool-Umgebungskonfigurationen über physische Maschinen hinweg zu erreichen war sehr herausfordernd, und groß angelegtes Skalieren war ein bedeutendes Unterfangen, auf das Teams weit im Voraus vorbereitet sein mussten. Ich erinnere mich noch, als ein Ingenieur die Umgebung einer Maschine änderte und vergaß, sie mit den anderen Maschinen zu synchronisieren, was einen sehr schwer zu verfolgenden Ghost-Bug in der Produktion verursachte. Das war eine sehr schmerzhafte alte Zeit.

Im Jahr 2012 erschien Docker. Docker verpackte alle Tool-Umgebungen in ein einzelnes Image und löste damit das Problem der Umgebungsinkonsistenz. Die Community erkannte allmählich, dass ein Service-Prozess, der in einer virtuellen Maschine auf einer physischen Maschine läuft, wie ein Prozess auf der physischen Maschine verwaltet werden könnte. Aber Docker-Orchestrierung erforderte immer noch, dass Engineering-Teams ein Orchestrierungssystem aufbauten. Und sobald der Service-Prozess innerhalb von Docker mit dem Netzwerk und dem Dateisystem der physischen Maschine gekoppelt wurde, wurde die Orchestrierung zu einer sehr schmerzhaften Sache.

Im Jahr 2014 begannen zustandslose Dienste zum Mainstream-Trend zu werden. In diesem Jahr wurden Kubernetes und AWS Lambda geboren. Sie beschrieben jeweils die Zukunft zustandsloser Dienste aus verschiedenen Blickwinkeln. Zustandslose Dienste bedeuteten, dass Service-Logik die Kopplung mit Netzwerkadressen vermied und nicht mehr lokal von persistenten Dateisystemen abhängig war.

Dann kamen die 10 Jahre Cloud Native, die Welle zustandsloser Dienste gebar eine große Charge Cloud-Native-Infrastruktur, wie zum Beispiel:

• Service-Gateways Istio/Linkerd/Envoy/Traefik
• CI/CD-Plattformen Argo CD / Flux
• Observability-Plattformen Prometheus/Grafana/ELK Stack
• Call-Chain-Analyse Jaeger/Zipkin/OpenTelemetry
• Storage Rook/MinIO/JuiceFS

Und wir stehen jetzt an einem neuen Anfang. Vor zehn Jahren war eine Compute-Einheit ein Java/Python-API-Service-Prozess. Ab diesem Jahr ist diese Compute-Einheit ein Coding-Agent geworden.

ACFS ist wie das Zeitalter der manuellen Wartung von Service-Prozessen auf physischen Maschinen. E2B ist wie Docker. Ohne Task-Orchestrierungsplattformen, Observability-Plattformen und verteilte Statuspersistenz-Speicherkapazitäten ist die Skalierbarkeit für Coding-Agenten immer noch eine schwierige Sache. Und die Serverless Agent Infra, die ich erwarte, hat diese Fähigkeiten:

1. In der Lage, die Sitzungen und Arbeitsverzeichnisse des Coding-Agenten angemessen zu persistieren, ohne Kontext zu verlieren.
2. Super schnell, in der Lage, einen Coding-Agenten in 100ms zum Laufen zu bringen.
3. Hat Logging / Metric / Tracing für Agentenverhalten, das für Menschen leicht verständlich ist, und macht es für Menschen einfacher, Agenten-Verhaltensmuster zu verstehen und anzupassen.
4. Entwickler müssen sich nicht mehr um Details wie virtuelle Maschinen, Container und andere Ops-Details kümmern, was die groß angelegte Orchestrierung sehr einfach macht.

Ich glaube, all die Infrastruktur, die diese Fähigkeiten erfüllen kann, ist bereits bereit. Beispielsweise hat Firecracker die Leistung und Stabilität von MicroVMs validiert, und es gibt viele Möglichkeiten für verteilte Observability-Plattformen und Dateispeichersysteme. Aber als Entwickler, der e2b verwendet hat, um Claude Code zu kapseln, ist die Integration all dieser Elemente immer noch sehr schwierig. Zum Beispiel ist es für Ingenieure schwer, zu überwachen, wenn Claude Code in E2B unerwartet durch OOM unterbrochen wird, und es ist noch schwerer, die Szene und Protokolle zu diesem Zeitpunkt zu erhalten.

Ich hoffe, dass Entwickler nach 2026 nicht durch einen so schmerzhaften Prozess gehen müssen, genau wie die meisten Ingenieure im Jahr 2026 keine SSH mehr verwenden müssen, um physische Maschinen manuell zu initialisieren.

Das ist VM0s Traum. Ich hoffe, eines Tages einen Coding-Agenten über eine ergonomische API steuern zu können, wie:

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