Vercel durable-harness: agent kodujący, który po awarii funkcji nie zaczyna od zera

Agenci kodujący powstawali jako długo żyjące procesy na laptopie. Sesja siedzi w pamięci, historia i pliki leżą na tym samym dysku, a po przerwaniu wystarczy jedno polecenie, żeby wrócić do pracy. W chmurze to przestaje działać. Funkcja ma limit czasu, może się wywrócić, a nawet maszyna z trwałym dyskiem nie wie, które wywołania modelu i narzędzi zdążyły się zakończyć. Nieudany turn oznacza więc utraconą pracę. Vercel próbuje to naprawić pakietem durable-harness, o którym pisze MarkTechPost, a który firma zapowiedziała we wpisie „Making every harness durable”.

Dziennik zamiast pamięci

Pomysł jest prosty. Durable-harness nie zastępuje istniejących harnessów, tylko je opakowuje. Adaptery obejmują Pi, OpenCode, fx, Claude Code i Codex. Każdy krok tury trafia do trwałego logu. Przed wywołaniem modelu lub narzędzia zapisywany jest zamiar, po zakończeniu – wynik. Każdą turę wspiera wiadomość w Vercel Queues, więc gdy funkcja umrze, kolejka przekazuje pracę nowej instancji. Ta czyta log i kontynuuje. Dokumentacja kolejek opisuje to wprost: praca jest dostarczana ponownie, a harness wznawia się z logu sesji.

Po awarii log pokazuje trzy rzeczy: co się skończyło, co było w toku i co jeszcze się nie zaczęło. Zakończone wywołania modelu i narzędzi są odczytywane z logu, a nie wykonywane ponownie, więc te same tokeny nie są rozliczane dwa razy. Pliki sesji samych harnessów też trafiają do logu. Chodzi o transkrypt Claude Code, rollout Codexa i event store OpenCode.

Najciekawsze jest rozróżnienie narzędzi, których wynik w logu się nie zapisał. Każde można oznaczyć jako replay: 'safe' albo replay: 'never'. Pierwsze, jak wyszukanie zamówienia, wolno powtórzyć. Drugie, jak zwrot pieniędzy, nie zostanie uruchomione drugi raz, a model dostaje informację, że wywołanie mogło się wydarzyć. To rozsądne podejście do problemu, którego nie rozwiąże samo „spróbuj jeszcze raz”.

Gdzie leżą pliki i działają komendy

Polecenia wybierane przez model nigdy nie wykonują się na dysku samej funkcji. Do wyboru są trzy typy przestrzeni roboczej:

• virtual() – pliki w logu sesji, powłoka zgodna z bashem, bez dostępu do sieci; mieści około 500 plików,
• virtual({ durable: false }) – pliki tymczasowe w pamięci, czyszczone co turę,
• sandbox() – osobny Vercel Sandbox dla każdej sesji, z katalogiem /workspace na Drive.

W logu żyją też typowane dokumenty JSON, na przykład lista zadań, do 64 KB każdy.

Ograniczenia: Claude Code i Codex tylko w Sandboksie

Pi i OpenCode działają w twojej funkcji, z wirtualną przestrzenią roboczą albo z Sandboksem. Claude Code i Codex to jednoużytkownikowe CLI trzymające stan na dysku, więc każda sesja dostaje własny Vercel Sandbox. Ten wymóg obowiązuje także przy self-hostingu. Adaptery dla tych dwóch narzędzi mają status eksperymentalny, a Pi, OpenCode i fx – wspierany.

Uruchomić można to w trzech miejscach, a kod agenta pozostaje ten sam:

• na Vercelu, na Vercel Functions i Vercel Queues, ze śladami każdej sesji w Agent Runs; Vercel World jest opisywany jako w pełni zarządzany backend,
• lokalnie, na plikach, bez konfiguracji,
• we własnej infrastrukturze, na Node.js 22+ z Postgresem; według dokumentacji self-hostingu wystarczą dwie zmienne środowiskowe, WORKFLOW_TARGET_WORLD i WORKFLOW_POSTGRES_URL. Blog Vercela wymienia też MongoDB, Redis i Turso.

Pod spodem działa ta sama maszyneria co w Workflow SDK. „World” łączy tam storage, kolejkę i strumień za jednym interfejsem. Vercel przypomina, że fx i eve już wcześniej były budowane jako trwałe w chmurze, a durable-harness ma rozciągnąć tę właściwość na dowolny harness. W swoim wpisie na X firma obiecuje, że agenci „automatycznie wznawiają pracę po awariach i działają godzinami, dniami lub miesiącami”. Warto pamiętać, że to deklaracja Vercela.

Nie ma bowiem żadnych opublikowanych benchmarków opóźnień ani przepustowości, a wszystkie twierdzenia o odzyskiwaniu po awarii pochodzą od samego producenta. Pakiet jest w wersji 0.0.x (w obiegu to 0.0.1-beta.6), z eksperymentalnym API. Koszt to czas CPU funkcji oraz zdarzenia i przechowywanie w logu. Najbardziej sensowne zastosowanie w tej chwili to testy na zadaniach, w których utrata pół godziny pracy agenta boli, a nie od razu produkcyjne wdrożenia.