LangGraph eller CrewAI: felhantering väger tyngre än enkel start

För ett fleragentflöde där avbrott, återstart och spårbara beslut är centrala är LangGraph ofta det tydligare valet. I dess dokumenterade arbetsmodell delas arbetet upp i noder med gemensamt tillstånd, kontrollpunkter och särskilda vägar för olika slags fel. Fördelen uppstår när teamet faktiskt definierar dessa vägar; den följer inte automatiskt av att ramverket installeras.

CrewAI kan ge en kortare väg till agentsamarbete med roller och uppgifter. För ett produktionsflöde är den relevanta jämförelsen ändå LangGraph mot CrewAI Flows, som erbjuder händelsestyrning, förgreningar, beständigt tillstånd och återupptagning. Valet gäller därför hur noggrant teamet behöver styra vad som händer när en agent, ett verktyg eller en mänsklig granskare stoppar arbetet.

Vad finns kvar efter ett avbrott?

LangGraph skapar kontrollpunkter vid nodgränser när en beständig lagring används. Efter ett avbrott börjar den avbrutna noden om från början, medan tidigare färdiga steg kan ligga kvar i tillståndet. Nodernas storlek får därmed en konkret följd: om sökning, utkast och utskick läggs i samma nod kan ett sent fel upprepa arbete som redan var klart.

CrewAI Flows kan i stället spara tillstånd för ett helt Flow eller för utvalda metoder. Tillståndet kan vara fritt uppbyggt eller följa ett schema, och en ny körning kan läsa in den senaste sparade versionen med flödets identifierare. Det gör beständighet till ett verkligt alternativ, men kräver att teamet väljer vilka metodgränser som ska sparas och hur körningen ska fortsätta därifrån.

Anta ett villkorligt kundärende: en agent klassificerar ett inkommande mejl, en annan hämtar underlag och en tredje skriver ett svar innan tjänsten för utskick slutar svara. I LangGraph kan de momenten ha separata noder, så att återstarten koncentreras till den felande delen. I CrewAI kan ett Flow skilja metoderna åt och bevara deras tillstånd. Inget sparat internt tillstånd garanterar dock att ett externt mejl inte skickas två gånger om själva utskicket upprepas; applikationen behöver känna igen ett redan utfört utskick.

Felstrategin är viktigare än den lyckade körningen

Ett tillfälligt nätverksfel lämpar sig för ett nytt försök. Ett verktyg som ger ett oanvändbart resultat kan kräva en annan väg, medan ett oväntat fel bör bli synligt för den som ansvarar för driften. LangGraph låter utvecklaren koppla återförsök till en nod, föra ett hanterbart fel tillbaka till agentens tillstånd eller låta körningen stanna. Den uppdelningen gör beteendet möjligt att granska, men teamet måste själv välja gränser och återhämtningsvägar.

I AIMultiples jämförelse ingick 2 000 körningar fördelade på flera uppgifter och ramverk; vid ett enkelt verktygsanrop använde den testade CrewAI-konfigurationen nära tre gånger så många token som LangChain, medan LangGraph bytte strategi i omkring 90 procent av körningarna med verktygsfel och den testade CrewAI-konfigurationen inte gjorde det i någon observerad körning. I feluppgiften kom nätverksfel, timeout och begränsning av anrop i följd. LangGraph-konfigurationen valde oftare andra verktyg för att nå resultatet, men använde då fler token än CrewAI-konfigurationen, som oftare väntade på det ursprungliga verktyget.

Resultatet gäller dessa konfigurationer och uppgifter, inte alla CrewAI Flows. Ett Flow kan uttryckligen styra vad som ska ske efter ett misslyckat agentsteg. Skillnaden för ett långvarigt företagsflöde är därför var besluten ligger: i en graf med definierade noder och övergångar, eller i ett Flow som omger de samarbetande agenterna. Om olika fel ska leda till olika åtgärder måste de vägarna finnas i den valda lösningen.

Ett mänskligt stopp behöver överleva väntan

Godkännande är ett särskilt fall av återstart. Ett utkast kan vänta medan granskaren är frånvarande eller tjänsten startas om, och svaret måste höra till rätt körning. LangGraph kan pausa vid ett avbrott, spara tillståndet och fortsätta med granskarens beslut. Arbete som ligger före avbrottet i samma nod kan köras om vid återupptagning, vilket gör placeringen av stoppet viktig före en extern åtgärd.

CrewAI:s stöd för mänsklig återkoppling kan också pausa ett Flow och välja väg efter godkännande, avslag eller begäran om ändring. En anpassad leverantör kan lämna körningen väntande utan att hålla en konsolprocess öppen; det väntande tillståndet sparas och flödet kan återupptas när svaret kommer. Standardbeteendet väntar däremot på inmatning i konsolen, så en långvarig produktionsprocess behöver en lämplig kanal för svaret.

För båda alternativen ligger behörighet och kopplingen mellan beslut, utkast och ärende hos applikationen. Ett godkännande bör avse den version som faktiskt ska skickas, och ett upprepat svar får inte utlösa samma externa åtgärd igen. CrewAI Flows har uppgifter om tidigare återkoppling som kan användas för en granskningslogg; LangGraphs sparade tillstånd och uttryckliga övergångar ger en annan grund för att följa beslutet genom körningen.

Tokenkostnad beror på felvägen

Det enkla verktygsanropet i jämförelsen visar kostnaden för just den testade uppgiften. Det är ingen prisprognos för ett helt fleragentflöde. Roller och omprövningar kan göra en Crew dyr i vardagsfall, medan en LangGraph-agent som tar en lång omväg efter ett fel kan skicka växande historik till modellen och förbruka fler token. Den snabbaste vägen tillbaka till ett svar behöver alltså inte vara den billigaste mätt i token.

En mer användbar enhet är kostnad per korrekt avslutat ärende. Då räknas även anrop som upprepas efter återstart, körningar som fastnar, mänsklig granskning och ärenden som måste göras om. För att jämförelsen ska säga något om ramverken behöver modellen, verktygen, uppgiften och felvillkoren vara desamma. Svarstid och tokenåtgång bör hållas isär: ett flöde som väntar på att ett verktyg återhämtar sig kan vara långsamt utan att använda många token.

Beslutsmatris för ett långt produktionsflöde

Det avgörande är vilket beteende som måste vara synligt och återställbart i det egna ärendet. Matrisen väger arkitekturen mot den publicerade mätningens tydliga begränsning: testet jämförde agentkonfigurationer, inte alla sätt att bygga ett CrewAI Flow.

• Tillstånd: LangGraph passar när varje arbetssteg och övergång ska kunna följas var för sig. CrewAI Flows passar när händelsestyrda metoder kan bära tillståndet runt samarbetande Crews.
• Återstart: I LangGraph avgör nodgränsen vilket arbete som kan upprepas. I CrewAI Flows avgör de sparade metodtillstånden vad nästa körning kan läsa in. Externa åtgärder behöver i båda fallen skydd mot dubbel utföring.
• Felstrategi: Om ett verktygsfel ska leda till en bestämd alternativ väg ger LangGraph en tydlig plats för den övergången. CrewAI kan göra samma val i ett omgivande Flow, men testresultatet för en Crew utan sådan styrning ska inte tillskrivas Flow.
• Mänskligt beslut: Båda kan vänta på återkoppling och fortsätta. Bedöm hur godkännande, avslag och ett återkommande svar knyts till rätt ärende och tillstånd.
• Kostnad: Jämför avslutade ärenden under samma villkor. Ett lågt tokenantal i en felkörning kan åtföljas av längre väntan, medan ett strategibyte kan öka tokenåtgången men få arbetet vidare.

När avbrott, revision och skilda felvägar är centrala talar den explicita styrningen ofta för LangGraph. När värdet främst ligger i agentsamarbetet kan CrewAI vara ett rimligt val, förutsatt att ett Flow bär den styrning som produktionen kräver.

Läs också:

• Cursor eller GitHub Copilot: arbetsuppgiften väger tyngre än månadspriset
• Jira eller Linear: enkel start kan bli dyr när teamen växer
• Plausible eller Matomo: enkel trafikmätning möter full analyssvit