Vercels durable-harness macht Claude Code, Codex und Pi absturzsicher

Warum Harnesses in der Cloud Dauerhaftigkeit brauchen

Entwickler führen Coding-Agenten üblicherweise lokal über Harnesses wie Pi und Claude Code aus. Damit solche Agenten rund um die Uhr arbeiten, braucht es laut Vercel einen Rechner, der dauerhaft eingeschaltet und wach bleibt. Das habe zu den Memes über aufgeklappte Laptops und zu einem Anstieg der Nachfrage nach dem Mac mini geführt. Harness-Workloads wandern nach Angaben des Unternehmens inzwischen in die Cloud.

Vercel verweist auf einzelne Entwickler, die dauerhaft laufende Coding-Agent-Workflows bereitstellen, auf Projekte wie OpenWork und HanaAgent, die Open-Source-Harnesses als Motor ihrer Apps nutzen, sowie auf Ingenieure, die eigene Harness-Produkte bauen. Agentenaufgaben laufen oft Minuten oder Stunden.

Lokal hat ein Harness durchgehend Zugriff auf den Workspace und den Sitzungsverlauf auf demselben Datenträger, sodass ein einfacher Prompt genügt, um unterbrochene Arbeit wieder aufzunehmen. In der Cloud lässt sich dieses Setup zwar mit einer VM mit persistentem Speicher nachbilden, doch laut Vercel erfasst die VM nicht, welche Modell- und Tool-Aufrufe abgeschlossen wurden, und setzt unterbrochene Turns nach einem Absturz nicht fort. Ein fehlgeschlagener Turn oder ein Netzwerkfehler bedeutet verlorene Arbeit.

So funktioniert durable-harness

Vercel hat eve und fx bereits so gebaut, dass sie in der Cloud dauerhaft laufen. durable-harness erweitert dies auf andere Harnesses und nutzt dieselbe Technik wie das Workflow SDK. Es besteht aus einer Reihe von Adaptern und Hilfsfunktionen, die eine Harness-Sitzung in einer World ablegen, dem dauerhaften Backend des Workflow SDK.

Das Paket schreibt jeden Schritt eines Turns in ein dauerhaftes Log. Bevor ein Modell- oder Tool-Aufruf läuft, hält es eine Absicht fest, und wenn der Aufruf endet, das Ergebnis. Zusätzlich wird der Turn durch eine Queue-Nachricht abgesichert. Stirbt die Funktion, übergibt die Queue den Turn an eine neue Funktion, die das Log liest und weitermacht.

• Abgeschlossene Aufrufe laufen nie erneut, weil ihre Ergebnisse aus dem Log stammen. Laut Vercel werden Nutzern die Tokens eines abgeschlossenen Modellaufrufs nie doppelt berechnet.
• Unterbrochene Tools, die mit replay: 'safe' markiert sind, laufen erneut.
• Jedes andere Tool wird dem Modell als möglicherweise ausgeführt gemeldet, und das Modell entscheidet, ob es nachprüft.

Bei Harnesses, die eigene Sitzungsdateien führen, etwa das Transkript von Claude Code, der Rollout von Codex und der Event-Store von OpenCode, wird jeder Eintrag in das Log gespiegelt. Eine neue Funktion oder Sandbox kann sie daraus wiederherstellen. Bei fx und eve ist Dauerhaftigkeit fest eingebaut, bei den übrigen ergänzt durable-harness sie von außen, ohne den Harness zu verändern.

Tools, Dateien und Laufumgebung

Jedes Tool legt fest, was geschehen soll, wenn ein Absturz es unterbricht. Ein „safe“-Tool, etwa eine Abfrage, kann erneut laufen. Ein „never“-Tool, etwa eine Rückerstattung, läuft nie zweimal, und das Modell erfährt, dass der Aufruf möglicherweise stattgefunden hat, damit es zuerst nachprüfen kann.

Für Harnesses, die eine Shell und Dateien benötigen, ist es laut Vercel nicht sicher, sie direkt auf einem gemeinsam genutzten Serverless-Function-Host auszuführen. durable-harness bietet drei Optionen:

• virtual() hält Dateien im Log der Sitzung, mit einer Bash-kompatiblen Shell, die weder auf die Dateien der Funktion noch auf das Netzwerk zugreifen kann. Es eignet sich für kurze Aufgaben und kleine Workspaces.
• virtual({ durable: false }) hält Dateien für Zwischenarbeit im Arbeitsspeicher und löscht sie nach jedem Turn.
• sandbox() gibt der Sitzung eine eigene Vercel Sandbox, wobei /workspace auf einem Drive liegt, der jede Sandbox und jede Funktion überdauert. Es eignet sich für echte Projekte und lang laufende Aufgaben.

Da das Paket in die World-Schnittstelle schreibt, kann derselbe Agent ohne Codeänderungen zwischen Backends wechseln. Auf Vercel nutzt er die Vercel World, in der Entwicklung Dateien auf dem lokalen Rechner, und auf selbst gehosteten Servern kann er Postgres, MongoDB, Redis oder Turso verwenden. Zwei Umgebungsvariablen, WORKFLOW_TARGET_WORLD und WORKFLOW_POSTGRES_URL, stellen jeden Agenten mit durable-harness auf Postgres um.

Was das für Entwickler bedeutet

Entwickler können unterstützte Harnesses dauerhaft auf Vercel betreiben, mit einer eigenen Postgres-Instanz selbst hosten, einen lokalen Harness-Workflow dauerhaft machen oder einen eigenen durablen Harness bauen. Die Ansicht „Agent Runs“ von Vercel zeigt den Trace jeder Sitzung, einschließlich jedes Modell- und Tool-Aufrufs. Turns, die nach einem Absturz fortgesetzt wurden, erscheinen im selben Trace, sodass Nutzer sehen können, wo einer stehen blieb und wieder aufgenommen wurde.

Für Teams, die lange Agentenaufgaben in der Cloud betreiben, besteht der von Vercel beschriebene praktische Effekt darin, dass ein Timeout oder eine unterbrochene Verbindung keinen manuellen Neustart und keine wiederholte Arbeit mehr erzwingt. Anleitungen zur Einrichtung für jeden Harness finden sich in der Vercel-Dokumentation.