Всеки екип, който доставя агентна система, в крайна сметка задава същия въпрос, обикновено около третия месец: „трябва ли ни Temporal / Inngest / Restate, или можем просто да добавим retries?“
Отговорът почти винаги е „трябва ви durable orchestrator, но по причина, която не е ‘retries’“.
Какво всъщност решават retries
Retries са правилният инструмент, когато преходен провал е наблюдаван от същия процес, който е направил извикването. Мрежов blip, rate-limit отговор, нестабилен downstream — извикващият има резултата с провала в ръка, знае какво се е опитвал да направи и може просто да опита отново.
За това ви трябва: retry policy с exponential backoff, ограничение на максимални опити и идемпотентност от получаващата страна. Това е библиотека, не система. p-retry, tenacity, tokio-retry — изберете една и продължете.
Какво всъщност решава durable execution
Durable execution е правилният инструмент, когато самият процес може да умре между стъпки. Crash, deploy, k8s изхвърля pod-а, 30-минутно LLM извикване, което надхвърля вашия request timeout — въпросът не е „можем ли да опитаме отново“, а „докъде бяхме стигнали, когато светлините изгаснаха, и как продължаваме без да преработваме частите, които вече са успели?“
Това е фундаментално различен проблем. Той изисква:
- Persistent step state — log на това кои стъпки са завършили, заедно с резултатите им.
- Replayable history — когато процесът се възобнови, той преминава през log-а, прескача завършените стъпки и продължава от първата незавършена.
- Деterministic step boundaries — код, структуриран така, че orchestrator-ът да може да идентифицира стъпките еднозначно при replay.
Можете да напишете това от нулата. Хора го правят. Това са шест месеца дебъгване на race conditions, преди да осъзнаете, че сте построили по-лоша версия на Temporal.
Реалното решение
Ако вашата агентна система има:
- Tool calls, които отнемат повече от няколко секунди индивидуално,
- Workflows с повече от ~3 последователни стъпки,
- Handoff или human-in-the-loop някъде по средата,
- SLA-та, които не могат да понесат deploy restart, причиняващ потребителски видим провал,
…ви трябва durable orchestrator. Не „може би ще го искате за nice-to-haves“. Трябва ви и добавянето му по-късно ще бъде много по-скъпо, отколкото да започнете с него.
Ако вашата система е кратка, синхронна и без състояние (един prompt, един отговор, готово за 5 секунди), retries са достатъчни. Не over-engineer-вайте.
Какво доставяме
На практика нашата default опция е Temporal или Restate (в зависимост от езиковия stack), с workflow код, структуриран така, че всяко LLM извикване, tool invocation и одобрение е отделна стъпка. Цената е известна learning curve и runtime за оперира. Ползата е, че „какво се случва, когато този процес crash-не в средата на workflow“ престава да бъде въпрос, на който трябва да отговаряме за всяка нова функционалност — orchestrator-ът отговаря веднъж завинаги.
Retries решават „това извикване се провали“. Durable execution решава „този workflow трябва да оцелее през провали на това, което го изпълнява“. Те не са алтернативи — повечето production системи се нуждаят и от двете, и втората е тази, която хората подценяват.