LangGraph или CrewAI: опоравак после грешке преокреће избор

За вишекорачног агента који чека људско одобрење и мора да се опорави после грешке алата, LangGraph је непосреднији избор када програмер жели да унапред одреди место прекида и следећу грану. CrewAI може да води исти процес кроз Flows, али тада треба јасно одвојити одлуке које доноси Flow од оних које доносе агенти у Crew-у.

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

Један захтев открива разлику

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

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

LangGraph: место наставка је део графа

Водич за LangGraph приказује чвор за људску проверу са interrupt(), чување стања преко checkpointer-а и наставак помоћу Command уз исти thread_id. Програмер тако може да представи одобрење као јасну тачку прекида, а грешку алата као податак који усмерава следећи корак. Наставак је могућ и после дужег чекања ако је одабрано складиште стања трајно; MemorySaver из примера чува стање у меморији процеса.

Минимални JavaScript образац је workflow.compile({ checkpointer }), interrupt(...) у чвору за одобрење и app.invoke(new Command({ resume: odluka }), config) за наставак. Исти config садржи configurable.thread_id при оба позива. Одлука човека се зато враћа у конкретно сачувано извршавање, са предлогом који је већ припремљен, уместо да се цео захтев покреће као нов посао.

За пролазни мрежни проблем чвор може да има политику поновног покушаја. Ако алат врати грешку коју агент може да протумачи, чвор може да је упише у стање и врати ток агенту; друга грана може да води ка алтернативном алату или човеку. Та прецизност тражи више пројектовања. LangGraph прави контролне тачке на границама чворова, па се после прекида рад незавршеног чвора може поновити од његовог почетка. Зато спољну радњу треба издвојити од припреме предлога и обезбедити да поновљени позив не произведе дупли ефекат.

CrewAI: сачувано стање и догађајни наставак

Документација CrewAI Flows описује @persist за чување стања, подразумевано у SQLite-у, @human_feedback за људску одлуку и @router за условно усмеравање. Сачувано стање може да се учита помоћу истог идентификатора тока. То омогућава дуготрајан посао, али учитавање података и избор метода који ће се потом извршити треба посматрати као одвојене одлуке у дизајну Flow-а.

Минимални Python образац ставља @persist изнад класе Flow, @start() на улазни метод и @human_feedback(...) на метод чији резултат чека проверу. Наставак после позитивне одлуке може да слуша @listen("approved"), а исход позива алата може да прође кроз @router(call_tool). Позив kickoff(inputs={"id": id_zahteva}) учитава последњи сачувани снимак под истим идентификатором; сам по себи не замењује правило које спречава поновно извршавање већ завршене спољне радње.

У условном процесу Flow треба да носи одобрени предлог, статус одобрења, резултат алата и грану за грешку. Crew има јасну улогу у кораку у ком специјализовани агенти заиста деле посао, на пример при прикупљању података и припреми предлога. Смернице CrewAI за продукциону архитектуру препоручују Flow као структуру за стање и контролу, а Crews као јединице за сложеније подзадатке. Таква подела омогућава да пословно правило после грешке остане у Flow-у, уместо да зависи само од тога шта ће агенти сами покушати.

Мерење показује и цену промене плана

У мерењу AIMultiple на 2.000 извршавања, тестирани CrewAI је у једноставном задатку са једним позивом алата трошио готово три пута више токена од LangChain-а, док је LangGraph после грешака алата променио стратегију у око 90% покретања, а тестирани CrewAI није напустио првобитни план. Исти модел, упити и алати не значе и исту оркестрацију: LangGraph је био подешен као StateGraph, а CrewAI као Agent, Task и Crew.

У задатку са грешкама однос потрошње се окренуо. LangGraph је потрошио највише токена док је тражио алтернативни пут, а CrewAI најмање јер није улазио у дуг заобилазни низ позива алатима. Мања потрошња у том случају прати другачије понашање после грешке; сама по себи не говори који је исход пожељнији за процес у ком се очекује промена алата.

Ово мерење не одређује универзалну цену LangGraph-а и CrewAI-ја. Поређење токена у једноставном задатку односи се на CrewAI и LangChain, док резултат опоравка описује наведене конфигурације LangGraph-а и CrewAI-ја. CrewAI Flow са ручно задатом граном за алтернативни алат није био део тог огледа. Број позива моделу, дужина стања које му се враћа и одлука да ли се после грешке чека или тражи заобилазни пут могу да промене рачун за конкретан процес.

Који оквир одговара овом процесу

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

CrewAI има предност када припрема предлога заиста захтева сарадњу више агената. Flow тада може да чува одлуке и води процес, док Crew решава делегирани подзадатак. Ако је опоравак после отказа алата пресудан, грану за грешку и правило за поновљени позив треба изразити у Flow-у. У оба приступа спољној радњи је потребан поуздан начин да препозна већ обрађен захтев: сачувано стање агента не може само да поништи ефекат позива који је други систем већ извршио.

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

• CrewAI или AutoGen: лакши почетак плаћа се другачијом контролом
• Passkey или лозинка: phishing пада, али опоравак налога остаје слаба тачка
• Redis или Memcached: једноставан cache може да преокрене победника