LangGraph of CrewAI: herstel na een crash

Voor een langdurige workflow met menselijke goedkeuring is LangGraph een logische keuze wanneer je precies wilt bepalen welke stap na een crash opnieuw begint. De LangGraph-uitleg over nodegrenzen beschrijft dat een onderbroken uitvoering vanaf het begin van de betrokken node hervat. Door conceptvorming, goedkeuring en verzending in afzonderlijke nodes te plaatsen, bepaal je welk werk opnieuw mag lopen.

CrewAI Flows is eveneens geschikt voor een workflow die op een beslissing moet wachten en later verdergaat. De documentatie van CrewAI Flows beschrijft statusopslag met @persist op klasse- of methodeniveau en het laden van de laatst opgeslagen toestand via dezelfde flow-ID. Het verschil zit daarom vooral in de herstelgrens die je ontwerpt; geen van beide mechanismen garandeert op zichzelf dat een externe schrijfactie na een storing maar eenmaal plaatsvindt.

Een goedgekeurd bericht als proef voor herstel

Neem een hypothetische klantenserviceworkflow. Een agent stelt een antwoord op, een medewerker keurt de definitieve tekst goed en daarna vraagt de applicatie een externe e-maildienst het bericht te verzenden. Na een herstart moeten het concept, de beslissing en de voortgang nog beschikbaar zijn. De ontvanger mag het bericht slechts eenmaal krijgen.

Daarvoor zijn drie grenzen van belang. Valt het proces stil tijdens het opstellen, dan kan die stap opnieuw beginnen. Valt het stil terwijl de medewerker nog moet beslissen, dan moet de aanvraag met hetzelfde concept kunnen blijven wachten. De lastige situatie ontstaat nadat de e-maildienst de verzending heeft aanvaard, maar voordat de workflow het resultaat heeft opgeslagen: de lokale toestand vertelt dan niet met zekerheid wat buiten de applicatie is gebeurd.

Waar blijft de toestand na een herstart?

In LangGraph bevat de graph-toestand de gegevens die latere nodes nodig hebben, zoals het concept en de goedkeuringsbeslissing. Een checkpointer bewaart momentopnamen per thread; de applicatie gebruikt een thread-ID om dezelfde uitvoering terug te vinden. De uitleg over LangGraph-checkpointers maakt een cruciale opslagkeuze concreet: MemorySaver bewaart checkpoints in het werkgeheugen en verliest ze bij een procesherstart, terwijl een persistente checkpointer daarvoor wel bedoeld is.

Ook de schrijfsnelheid van checkpoints telt mee. LangGraph schrijft ze standaard asynchroon, zodat een node al verder kan voordat het checkpoint op de opslag staat; de uitvoeringsmodus kan op synchroon schrijven worden gezet wanneer een voltooide stap pas verder mag na die opslag. Een getekende graph met een thread-ID is dus nog geen volledige herstelarchitectuur. De gekozen opslag en het moment waarop een checkpoint duurzaam is, bepalen welke laatst voltooide stap een crash overleeft.

Bij CrewAI Flows bewaart @persist de Flow-toestand; de standaardimplementatie gebruikt een lokale SQLite-database. Op klasseniveau geldt de decorator voor alle Flow-methoden, op methodeniveau voor de gekozen methoden. De flow-ID laat een nieuwe uitvoering de laatst opgeslagen toestand terughalen. Voor het voorbeeld betekent dit dat het concept, de goedkeuring en een vaste identificatie van de verzending expliciet in die toestand moeten worden opgenomen. Toestand bewaren binnen een Flow maakt de aanroep naar een e-maildienst nog niet tot één transactie met die opslag.

Menselijke goedkeuring is een eigen hervatpunt

LangGraph kan met interrupt() pauzeren en later via dezelfde thread-ID de beslissing ontvangen. Omdat code in een onderbroken node bij hervatten opnieuw vanaf het begin loopt, hoort een onomkeerbare actie niet vóór de interrupt in diezelfde node. In het voorbeeld bewaart een node het concept, wacht een volgende node op goedkeuring en verzendt pas een afzonderlijke node het goedgekeurde bericht.

CrewAI Flows biedt hiervoor @human_feedback. De handleiding voor menselijke feedback beschrijft een niet-blokkerende route waarbij een aangepaste provider de Flow pauzeert, de toestand automatisch wordt opgeslagen en de applicatie later met de flow-ID en de ontvangen feedback hervat. De documentatie raadt bovendien aan de afhandeling van die feedback idempotent te maken, zodat een herhaalde callback geen ongewenste herhaling veroorzaakt.

Beide ontwerpen kunnen dus op een medewerker wachten zonder het hele proces actief te houden. Het relevante onderscheid is waar de ontwikkelaar de vervolgstap afbakent. Bij LangGraph is het opnieuw uitvoeren van de onderbroken node een gedocumenteerde eigenschap. Bij CrewAI Flows organiseer je de goedkeuringsroute en de opgeslagen Flow-toestand rond de methoden die erop reageren. De keuze moet passen bij de plek waar jouw applicatie een herhaalde uitvoering kan opvangen.

De crash na verzending

Stel nu dat de externe e-maildienst het goedgekeurde bericht accepteert en het proces direct daarna uitvalt. Het checkpoint of de opgeslagen Flow-toestand kan nog steeds aangeven dat verzending moet plaatsvinden. Een herstart kan dezelfde aanroep dan opnieuw doen, hoewel de eerste al is verwerkt. Dit is geen uitzonderlijk gedrag van één framework: de externe dienst en de lokale toestand hebben geen gezamenlijke, ondeelbare opslaghandeling.

De LangGraph-richtlijn voor idempotente acties benoemt dat een begonnen maar niet afgeronde taak opnieuw kan lopen en adviseert een idempotentiesleutel of controle van een bestaand resultaat. Hetzelfde risico moet in een CrewAI Flow worden afgevangen wanneer de verzendmethode na herstel opnieuw wordt aangeroepen. Een statusvlag die pas na de externe aanroep wordt opgeslagen, laat precies tussen acceptatie en lokale opslag een gat open.

In het hypothetische voorbeeld krijgt elk goedgekeurd bericht daarom vóór verzending een vaste verzend-ID, die bij elke poging gelijk blijft. Ondersteunt de e-maildienst een idempotentiesleutel, dan kan zij herhaalde verzoeken met die ID als dezelfde opdracht behandelen. Anders heeft de applicatie een opvraagbaar bericht-ID of een andere betrouwbare manier nodig om de eerdere uitkomst vast te stellen. Een eigen registratie helpt alleen wanneer zij die uitkomst werkelijk kan koppelen aan wat de externe dienst heeft aanvaard; een lokale markering alleen kan dat crashvenster niet sluiten.

Welke keuze volgt uit die grens?

LangGraph past goed wanneer je de herstelpunten zelf scherp wilt vastleggen: een node voor het concept, een node voor de onderbreking en een node voor de verzending. Die controle brengt ontwerpwerk mee voor graph-toestand, thread-ID, checkpointopslag en de manier waarop checkpoints duurzaam worden geschreven. Ze is vooral waardevol wanneer de stappen verschillende regels voor herhaling hebben.

CrewAI Flows past wanneer agentrollen en taken centraal staan en een Flow de duurzame volgorde en goedkeuring organiseert. Dan moet @persist op de relevante methoden of de klasse staan en moet de flow-ID beschikbaar blijven voor herstel. De externe verzending vraagt in beide architecturen om dezelfde afzonderlijke beslissing: hoe herkent de applicatie een opdracht die de e-maildienst al heeft verwerkt, terwijl haar eigen laatste opgeslagen toestand dat nog niet laat zien?