Odolnost agenta je vlastnost logu, ne stroje
Na laptopu je obnovení session triviální. Stav je v paměti a v souborech a když proces spadne, načteš ho znovu. V cloudu to nefunguje ani s perzistentním diskem. Virtuální stroj si sám nezapamatuje, která volání modelu a nástrojů doběhla, a přerušený tah po pádu nedokončí. Vercel to řeší knihovnou durable-harness, ale důležitější než knihovna je princip. Zdrojem pravdy o tahu agenta je log, ne proces, který tah právě provádí.
Záměr před voláním, výsledek po něm
Každý krok tahu se zapisuje do trvalého logu ve dvou fázích. Před voláním modelu nebo nástroje se zapíše záměr. Po dokončení výsledek. Je to stejný vzorec jako write-ahead log v databázi, jen jednotkou není zápis stránky, ale volání nástroje.
Každý tah navíc jistí zpráva ve frontě. Když funkce zemře, fronta předá tah nové funkci, ta přečte log a pokračuje. Dokončená volání se nespouští znovu, výsledek se vezme z logu. Hotové volání modelu se tedy neplatí dvakrát a model vidí svá předchozí volání, takže je neopakuje.
Stejně se zachází i se stavem mimo konverzaci. Seznam úkolů je v logu typovaný JSON dokument a jeho úprava se zapíše atomicky spolu s výsledkem nástroje, který ji způsobil. Dokument a historie nástrojů se tak nemůžou rozejít.
Nejtěžší je záměr bez výsledku
Záznam záměru bez výsledku je nejednoznačný. Nástroj mohl doběhnout a pád přišel těsně před zápisem výsledku. Nebo nedoběhl vůbec. U čtení je to jedno. U poslání e-mailu nebo platby ne.
Knihovna to neřeší obecně, protože obecně to vyřešit nejde. Každý nástroj deklaruje, jak se chová po pádu. Nástroj s replay: 'safe' se po přerušení prostě spustí znovu. U ostatních rozhoduje model: vidí, že volání možná proběhlo, a může si ověřit stav, než ho zopakuje. To funguje jen tehdy, když nástroj nabízí způsob, jak stav ověřit. A deklarace je jen tak dobrá jako skutečná idempotence nástroje. Špatně označený nástroj udělá vedlejší efekt dvakrát.
Všimni si rozdělení odpovědnosti. Model uvažuje nad tím, co se stalo. Runtime rozhoduje, co se znovu vykoná. Ty dvě vrstvy se nemíchají.
Co si z toho odnést
Až budeš stavět agenta, který běží déle než jeden request, nepočítej s tím, že proces vydrží. Zapisuj záměr před každou akcí a výsledek po ní a stav rekonstruuj z logu. U každého nástroje se výslovně rozhodni, jestli je bezpečné ho zopakovat, a u těch, které nejsou, dej modelu nástroj na ověření stavu. Je to stejná disciplína jako u workflow enginů a platebních systémů. Agent ji potřebuje víc, protože jeho kroky jsou drahé a nedeterministické.