LangGraph или CrewAI: при грешка, 90% наспроти нула менуваат стратегија

21 октомври 2026 г., во 07:00|Автор: Уредувачки тим на QUASA|6 мин. читање

Во бенчмаркот на AIMultiple со 2.000 извршувања вкупно, тестираната конфигурација на LangGraph сменила стратегија во околу 90% од случаите во задачата со грешки во алатка, а конфигурацијата на CrewAI во 0%. Тоа е разлика во однесувањето при една задача, не општа стапка на успешност. Во тестот, алатката последователно враќала мрежна грешка, истек на време и ограничување на повици.

За работен тек што мора да најде друга патека по неуспешен повик и да продолжи од јасно зачувана состојба, LangGraph е посилен почетен избор. CrewAI има смисла кога работата природно се дели меѓу агенти со различни задачи, но за продукциска споредба треба да се земе предвид и неговиот Flow. Изборот зависи од тоа колку одлуки мора да бидат однапред определени, каде се зачувува состојбата и што точно треба да се случи по прекин.

Што навистина било споредено

Бенчмаркот опфатил различни задачи со исти упатства, алатки, модел и поставка за температура за сите рамки. LangGraph бил изграден со StateGraph, а CrewAI со Agent, Task и Crew. Затоа разликата при грешка му припаѓа на однесувањето на тие конфигурации во зададените услови. Таа сама по себе не кажува како би работел CrewAI Flow со експлицитно зададена резервна гранка.

Кога главната алатка откажувала, тестираните LangGraph извршувања често преминувале на посебни алатки за филтрирање и пресметка. Тестираните CrewAI извршувања се задржувале на првичниот план, чекајќи закрепнување на алатката или повторувајќи го обидот. Промена на стратегија тука значи напуштање на проблематичниот пат и составување друг пат до резултатот; не значи автоматски дека секое такво извршување било точно или евтино.

Токенскиот трошок ја менува оценката според видот на задачата. Во едноставните задачи, координацијата меѓу тестираните CrewAI агенти трошела повеќе токени. Во задачата со грешки, алтернативните повици и растечката историја го зголемиле трошокот на LangGraph, додека чекањето кај CrewAI трошело помалку токени, но траело подолго. Затоа просекот за сите задачи би сокрил важна разлика: евтин обид што чека и поскап обид што наоѓа решение не даваат иста вредност.

Зачувана состојба не е исто што и нова стратегија

Документацијата за зачувување состојба на LangGraph опишува checkpoint по секој super-step кога графот е составен со checkpointer. Снимките се врзуваат за идентификатор на извршувањето и овозможуваат увид во претходна состојба, пауза за човечко одобрување и продолжување по грешка. Ако еден јазол откаже, записите од други успешно завршени јазли во истиот чекор може да се задржат, за тие да не се извршуваат повторно при продолжувањето.

Оваа грануларност е значајна кога независни операции се извршуваат паралелно: програмерот може да утврди што веќе завршило и каде треба да продолжи графот. Сепак, зачуваната состојба не ја избира резервната патека наместо апликацијата. Ако одговорот на грешката мора да биде предвидлив, условот за премин кон друга алатка треба да биде дел од логиката на графот, а не само надеж дека моделот ќе го предложи.

Продукциските насоки на CrewAI препорачуваат апликацијата да почне со Flow, кој управува со состојбата и дозволува условни патеки, циклуси и разгранување. Декораторот @persist ја зачувува состојбата на Flow во база за продолжување по пад на процесот или додека се чека човечки внес. Тоа е важна разлика од конфигурацијата Agent–Task–Crew во бенчмаркот: отсуството на промена на стратегија таму не значи дека CrewAI нема механизам за зачувување или контрола на текот.

За продолжување по вистински рестарт е важен и изборот на складиште. Насоките на LangChain за persistence наведуваат дека InMemorySaver ги губи checkpoint-записите кога процесот ќе се рестартира и упатуваат на траен checkpointer за продукција. И кај двете рамки треба одделно да се разгледа надворешното дејство: зачувувањето на внатрешната состојба не гарантира дека повторен повик кон надворешен сервис нема да создаде дупликат.

Каде се разгранува изборот

Ако правилата по грешка се строги, клучно е каде ќе биде запишана одлуката за следниот чекор. LangGraph го изложува текот преку јазли, состојба и врски меѓу нив, што одговара кога треба точно да се следи неуспешниот чекор и резервната патека. CrewAI Flow исто така дозволува условни патеки, додека Crew останува единица за сложена работа внатре во текот. Ниту едната рамка не го прави текот предвидлив само затоа што поддржува разгранување; тоа зависи од правилата што ќе ги изградите.

За чести грешки со повеќе можни обходни патеки: LangGraph е природен избор кога секоја одлука треба да биде видлива во состојбата и врските на графот. Тој пристап помага да се разликува повторен обид од вистинска промена на стратегија.
За работа поделена меѓу специјализирани агенти: CrewAI има јасна организација на агенти и задачи. Кога текот бара стабилно продолжување и условни премини, споредуваната реализација треба да ги вклучи Flow и зачувувањето состојба.
За човечко одобрување: двете рамки имаат начин да паузираат и продолжат. Важно е дали одобрувањето треба да се врзе за конкретна снимка и јазол или за чекор во Flow, како и каква состојба ќе види човекот пред одлуката.
За ограничен токенски буџет: трошокот има смисла да се споредува за успешно завршена и за закрепната задача одделно. Дополнителните повици се оправдани само ако ја подобруваат точноста или можноста работата да заврши.

Локален тест за вашиот работен тек

За споредба што може да се повтори, зададете иста повеќечекорна задача, модел и верзија, упатства, алатки, податоци и ограничување на повторните обиди. Во LangGraph дефинирајте состојба, траен checkpointer и правило за резервна патека. Во CrewAI ставете ги задачите во Flow, дефинирајте го условниот премин и вклучете @persist. Така тестот ќе ги спореди продукциски релевантните реализации на двете рамки.

Потоа раздвојте ги условите: нормално извршување, недостапна алатка, истек на време, прекин на процесот по завршен меѓучекор и пауза за човечко одобрување. За секое извршување забележете дали конечниот одговор е точен, дали патеката се сменила, од која состојба продолжила, кои алатки биле повикани повторно, колку токени се потрошени и колку траела задачата. Повторувањата треба да покажат распределба на исходите, бидејќи еден успешен обид не кажува колку сигурно работи закрепнувањето.

Посебно следете дали прекинот по надворешно дејство предизвикува истото дејство да се изврши повторно. Ако се појави дупликат, потребна е заштита во логиката на апликацијата или во повиканиот сервис. Ако резервната патека редовно дава точен резултат без такво повторување, тогаш нејзиниот дополнителен токенски трошок може да се спореди со конкретната придобивка: завршена задача наместо чекање.

Прочитајте и:

Сподели: