LangGraph ці CrewAI: розніца ў 82 мс не выбірае архітэктуру агента

Калі маршрут агента трэба дакладна задаць праз стан, умовы пераходу і паўзы, выбірайце LangGraph. Калі працу натуральна падзяліць на задачы агентаў з рознымі ролямі, пачынайце з CrewAI. У мікрабенчмарку Tacavar сярэдні цыкл склаў 943 мс для LangGraph і 861 мс для CrewAI: розніца ў 82 мс атрымана з пяці запускаў кожнага фрэймворка.

Гэты вынік апісвае кароткі цыкл з выклікам інструмента і адказам мадэлі, а не кошт аркестрацыі ў чыстым выглядзе. Да таго ж CrewAI мае не толькі каманды агентаў, але і Flows для кіраваных маршрутаў. Таму для прататыпа і вытворчага працэсу вырашальнымі становяцца форма працы, мяжа аднаўлення пасля збою і патрэба ў пацвярджэнні чалавека.

Граф крокаў, каманда роляў і кіраваны паток

У дапаможніку LangGraph працэс складаецца з вузлоў, пераходаў паміж імі і агульнага стану, які вузлы чытаюць і абнаўляюць. У прыкладзе апрацоўкі звароту кліента асобнымі крокамі становяцца класіфікацыя ліста, пошук звестак, падрыхтоўка адказу і перадача складанага выпадку чалавеку. Такая будова дазваляе вызначыць, якія даныя патрэбныя для наступнага рашэння і дзе маршрут можа змяніцца.

У дакументацыі CrewAI Crews галоўнымі элементамі выступаюць агенты, прызначаныя ім задачы і працэс іх выканання; для каманды апісаны паслядоўны і іерархічны рэжымы. Гэта блізка да задачы, дзе адзін агент збірае матэрыял, другі аналізуе яго, а наступны рыхтуе вынік. Распрацоўшчык задае ролі і чаканыя вынікі задач, не абавязкова выносячы кожную ўмову пераходу ў асобны крок.

Дакументацыя CrewAI Flows апісвае запуск метадаў па падзеях, умоўную маршрутызацыю праз @router і стан у выглядзе слоўніка або структуры Pydantic. У паток можна ўключыць асобнага агента ці каманду. Калі патрэбны і спецыялізаваныя ролі, і кіраваныя развілкі, параўноўваць LangGraph варта з такім спалучэннем магчымасцей CrewAI, а не толькі з камандай, якая выконвае задачы па чарзе.

Што застанецца пасля збою

Для доўгага працэсу істотна, з якога месца пачнецца паўтор. LangGraph захоўвае стан на межах вузлоў: пасля перапынення або збою выкананне пачынаецца з пачатку вузла, на якім яно спынілася. Калі ў адным вузле злучыць пошук у вонкавым сэрвісе, генерацыю адказу і адпраўку паведамлення, збой напрыканцы можа паўтарыць усю гэтую працу. Асобныя вузлы дазваляюць ізаляваць аперацыі з рознымі правіламі паўтору.

У CrewAI мяжа залежыць ад абранага механізму. Для Crews можна ўключыць кантрольныя кропкі пасля завершаных задач і аднавіць каманду з захаванай кропкі. У Flows дэкаратар @persist захоўвае стан на ўзроўні ўсяго класа або асобных метадаў; паток можа загрузіць апошні здымак па сваім ідэнтыфікатары. Гэта дае аднаўленне, але распрацоўшчык усё роўна вырашае, пасля якой працы вынік павінен быць захаваны.

Захаванне стану ў любым фрэймворку не адмяняе пабочных дзеянняў у іншай сістэме. Умоўна, агент мог ужо адправіць ліст, а працэс спыніўся да запісу выніку. Паўтор кроку тады можа прывесці да другой адпраўкі. Для такога дзеяння патрэбны ўласны ідэнтыфікатар аперацыі або праверка яе выніку; размяшчэнне кантрольнай кропкі само па сабе не гарантуе аднаразовага выканання.

Паўза для чалавека і бачнасць рашэння

У LangGraph пацвярджэнне можна зрабіць асобным вузлом: interrupt() спыняе выкананне, а пасля атрымання адказу працэс працягваецца з захаваным станам. Пры аднаўленні код вузла да перапынення запускаецца зноў. Таму ў прыкладзе са зваротам кліента падрыхтаваны тэкст захоўваецца раней, а вузел пацвярджэння не адпраўляе паведамленне да рашэння чалавека.

У CrewAI Flows для такой мяжы ёсць @human_feedback. Ён прыпыняе паток для водгуку; вынік можа вызначыць наступны маршрут, напрыклад ухваленне або вяртанне на дапрацоўку. Практычнае адрозненне тут у тым, як паўза ўпісваецца ў астатнюю мадэль: у LangGraph яна частка маршруту вузлоў, у CrewAI Flows — частка падзейнага патоку, які можа запускаць і каманду агентаў.

Трасіроўка таксама павінна адпавядаць прычыне магчымай памылкі. Для графа карысна бачыць стан да вузла і пасля яго, а таксама абраны пераход. Для каманды патрэбна бачнасць задачы, перададзенага паміж агентамі выніку і рашэння, прынятага ў патоку. CrewAI прадугледжвае трасіроўку каманды, але наяўнасць гэтай магчымасці не вызначае, ці будзе канкрэтны запіс змяшчаць патрэбныя для расследавання даныя.

Што азначаюць вымераныя мілісекунды

У мікрабенчмарку выкарыстоўвалі адну кароткую задачу з дэтэрмінаваным выклікам інструмента і жывым запытам да gpt-4o-mini. Замяралі поўны цыкл, таму ў час увайшлі сеткавы запыт і адказ API мадэлі. Аўтар адносіць невялікі разрыў паміж сярэднімі да ваганняў API. Малая выбарка не дазваляе пераносіць гэты парадак хуткасцей на іншы набор мадэляў, інструментаў і крокаў.

Халодны старт у тым жа тэсце вымяралі асобна, пры запуску новага працэсу. CrewAI пачынаў павольней за LangGraph, але для кожнага фрэймворка гэта быў толькі адзін запуск. Для кароткіх задач, якія часта стартуюць нанова, такая затрымка можа быць важнейшай за розніцу паміж ужо запушчанымі цыкламі. У доўгім патоку на агульны час дадаткова ўплываюць колькасць зваротаў да мадэлі, паўторныя крокі і чаканне адказу чалавека.

На той жа старонцы побач з вымераным мікрабенчмаркам захаваны ранейшыя сінтэтычныя ацэнкі шматкрокавага працэсу. Яны апісваюць іншую нагрузку і маюць іншы статус, таму складаць з іх адзін рэйтынг хуткасці было б памылкай. Для выбару архітэктуры карысней параўноўваць час поўнага маршруту, які сапраўды будзе выконваць ваша сістэма, разам з коштам паўтораў пасля збою.

Выбар для прататыпа і вытворчага працэсу

Калі асноўная складанасць — загадзя вызначаныя ўмовы, асобныя інтэграцыі і магчымасць аднавіць працу з канкрэтнага кроку, LangGraph дае прамую мадэль гэтага працэсу. Гэта патрабуе яўна апісаць стан, вузлы і пераходы. Такая праца апраўданая, калі межы крокаў адначасова служаць межамі назірання і аднаўлення.

Калі вынік атрымліваецца праз падзел працы паміж спецыялізаванымі агентамі, CrewAI Crews можа быць прасцейшым адпраўным пунктам. Калі пазней з’яўляюцца развілкі, захаваны стан і абавязковае пацвярджэнне, іх можна мадэляваць праз Flows. Гэта асобны архітэктурны выбар у межах CrewAI: трэба вырашыць, дзе заканчваецца задача каманды і пачынаецца кіраванне ўсім працэсам.

Для вытворчага запуску найважнейшая праверка — паводзіны пры рэальным перапыненні: які вынік ужо захаваны, якая аперацыя паўторыцца і што ўбачыць чалавек перад ухваленнем. Пасля гэтага мае сэнс вымяраць халодны старт і поўны час свайго маршруту. Так хуткасць застаецца крытэрыем выбару, але яе ацэньваюць для таго працэсу і тых умоў збою, з якімі сістэма сапраўды сутыкнецца.

Чытайце таксама:

• PostgreSQL ці MySQL: адзін бенчмарк не выбірае базу на гады
• ETF ці ўзаемны фонд: розніца ў 0,01% можа быць не галоўнай
• Gumroad ці Lemon Squeezy: 5% розніцы не паказваюць поўную цану