Оркестрација AI агената: грешке, одобрења и поновни покушаји

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

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

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

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

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

Погледајмо шта се дешава када оркестратору дате задатак.

Узмимо примјер са Perplexity радионице о Computer-у: израда контролне табле са аналитиком клијентских налога на основу информација из система Salesforce и Snowflake, е-поште, календара и најновијих вијести.

Разумијевање циља и планирање посла. Оркестратор полази од траженог исхода и разлаже га на задатке са експлицитним зависностима. У нашем примјеру контролне табле то подразумијева прикупљање информација из различитих извора и њихово претварање у готов резултат. Планер утврђује који кораци зависе од других, а који се могу извршавати независно.
Усмјеравање задатака ка одговарајућим агентима. Оркестратор препознаје задатке чије су зависности испуњене и додјељује посао специјализованим агентима или моделима. Зависни задаци чекају своје предуслове. Perplexity Computer користи више најнапреднијих модела и усмјерава различите дијелове тока рада ка системима погодним за те задатке. То такође омогућава паралелно извршавање независног посла.
Извршавање позива алата у контролисаним окружењима. Агенти комуницирају са својим окружењем путем алата, као што су веб-претрага, API-ји, повезане апликације, операције са датотекама или извршавање кода. Извршни слој покреће те радње и враћа резултате агентима.
Преношење резултата и контекста између агената. Када агент заврши свој задатак, сљедећем агенту у ланцу потребан је релевантан резултат да би наставио. Запис о примопредаји може да садржи ID задатка, референцу на резултат, верзију шеме и метаподатке о извору. Оркестратор координира те примопредаје и одржава контекст потребан за наредне кораке. Што је важно, агенти не морају да носе цијелу историју рада свих других агената у сопственим контекстним прозорима.
Евидентирање стања извршавања одвојено од контекста агента. Како агенти започињу, завршавају или не успијевају да изврше задатке, механизам за извршавање ажурира трајни запис тока рада са статусима задатака, покушајима извршавања, референцама на резултате и преосталим послом. Тај запис омогућава оркестратору да прати напредак и настави након прекида, без ослањања на LLM да реконструише ток рада из историје разговора.
Провјера резултата и одлучивање о сљедећем кораку. Када задатак врати резултат, слој оркестрације провјерава да ли тај резултат испуњава очекивани уговор и да ли су испуњене зависности сљедећег задатка. Ако се пронађе проблем, ток рада се може вратити на ранији корак ради исправке или се може паузирати. У супротном, наставља ка завршетку.

Иза онога што изгледа као једноставна оркестрација AI агената крије се много покретних дијелова. Начин на који организујете координацију агената одређује колико контроле имате над извршавањем. И наравно, сва та координација доноси додатно оптерећење. Зато се не исплати увијек.

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

Дакле, оркестрација је корисна у три сценарија:

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

Осим у тим случајевима, оркестрација је само скупи тренд. Више агената значи и више координације и потенцијално веће трошкове токена.

„Обично почињем од најједноставније опције и надограђујем од ње. Ако знамо кораке и они се понављају, то је вјероватно ток рада. Разлог за увођење више агената видим само када они имају различите одговорности, дозволе или кориснике“, каже Josh Spilker, руководилац маркетинга за претраживаче у компанији AirOps.

Чак и тада, одмјерите предности у односу на додатне позиве модела, примопредаје, кашњење и тачке отказа.

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

У централизованој оркестрацији процесом управља један оркестратор. Он разлаже задатак, додјељује посао специјализованим агентима, прати њихов напредак и обједињује њихове резултате.

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

Компромис: Централизована координација олакшава праћење извршавања и примјену заједничких правила на једној контролној тачки. Међутим, оркестратор може постати уско грло, а његов отказ може прекинути цијели ток рада, осим ако систем не подржава опоравак.

У децентрализованој оркестрацији агенти координишу рад директније, умјесто да се ослањају на једног менаџера који доноси сваку одлуку. Могу размјењивати поруке, читати заједничко стање и самостално одређивати своје сљедеће кораке.

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

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

Хијерархијска оркестрација проширује приступ са менаџером на више нивоа. Оркестратор највишег нивоа преноси одговорност на подређене оркестраторе, који координишу сопствене групе специјализованих агената.

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

Оваква структура може помоћи када су токови рада преобимни да би их један оркестратор ефикасно водио.

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

Компромис: Хијерархије омогућавају тимовима да подијеле одговорности за координацију и потенцијално рјешавају отказе унутар појединачних грана. Међутим, оне уводе додатне примопредаје, сложеније управљање стањем и веће оперативно оптерећење. Локални опоравак такође зависи од тога како су имплементиране контролне тачке и стање извршавања.

Поређење ових архитектура:

Критеријуми	Централизована	Децентрализована	Хијерархијска
Одговорност за извршавање	Један оркестратор контролише додјељивање задатака	Агенти координишу рад међусобно или путем заједничког стања	Одговорност је распоређена на више нивоа оркестрације
Конзистентност стања	Лакша координација преко једне контролне тачке	Захтијева експлицитну синхронизацију и рјешавање конфликата	Захтијева координацију унутар грана и између њих
Изолација отказа	Централни контролер може постати критична зависност	Појединачни агенти могу отказати независно, али заједничка инфраструктура остаје критична	Откази могу остати ограничени на гране ако је систем пројектован за опоравак
Спровођење политика	Заједничке контроле могу се спроводити централизовано	Политике се морају досљедно спроводити међу свим учесницима	Контроле се могу примјењивати на глобалном нивоу и на нивоу домена
Оперативна сложеност	Углавном мања	Већа сложеност координације	Већа сложеност због више слојева оркестрације

Постоји још једна разлика коју вриједи разумјети. Архитектура одређује ко координира агенте. Образац извршавања одређује како напредују њихови задаци.

Ово су три обрасца извршавања:

Секвенцијални токови рада: Агенти раде унапријед дефинисаним редослиједом, при чему резултат једног агента постаје улаз за други.
Паралелно извршавање: Независни агенти раде истовремено.
Извршавање засновано на предаји: Контрола прелази са једног специјализованог агента на други како задатак напредује. Ово је корисно када је други агент боље опремљен за наредни корак, мада свака предаја мора да сачува информације потребне за наставак.

Ови обрасци се међусобно не искључују и не пресликавају се један-на-један на архитектуре оркестрације. Циљ је изабрати најједноставнију структуру која подржава зависности вашег тока рада, захтјеве за координацијом и прихватљиве оперативне трошкове.

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

Предаје између агената уз губитак информација. Оркестратор прослеђује сажети план специјализованом агенту, али у сажетку изостају ограничења, зависности или детаљи имплементације.
Прерано fan-in извршавање. Низводни агент почиње да обједињује резултате прије него што се заврше сви узводни задаци.
Недетерминистичка ажурирања заједничког стања. Паралелни агенти уписују у исте кључеве стања без јасно дефинисане семантике спајања. У зависности од тога како радни оквир обрађује ажурирања, то може довести до изгубљених уписа, дуплираних података, излаза зависног од редослиједа или конфликтних измјена.
Неусклађеност контролних тачака и споредних ефеката. Задатак изврши спољну операцију, али његово успјешно извршавање није трајно забиљежено прије него што радни процес откаже. Приликом опоравка, оркестратор види недовршен задатак и поново га покреће.
Трке при наставку након људског одобрења. Паузирање и настављање извршавања уноси сопствене проблеме синхронизације.
Петље делегирања и умножавање поновних покушаја. Агенти једни другима изнова предају посао јер им се одговорности преклапају, зависности су кружне или су услови завршетка двосмислени.
Контроле на нивоу инструкција погрешно схваћене као безбједност извршавања. Оркестратор може рећи агентима да не приступају одређеним ресурсима или да не изводе осјетљиве радње, али инструкције модела не намећу дозволе оперативног система, мрежна ограничења нити границе ауторизације. Истраживање безбједносног инжењеринга компаније Perplexity истиче зашто агенти могу прећи безбједносне границе док теже легитимним циљевима, чак и без злонамјерних инструкција

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

Нејасни циљеви и нејасна дефиниција завршеног посла често доводе до разочаравајућих резултата које генеришу агенти. Рјешење је уговор о промпту (обим посла за агента): договорите се о циљу, ограничењима, формату излаза и условима неуспјеха прије него што извршавање почне.

На примјер, ево како бисте могли да дефинишете уговор за агента задуженог за исправљање интеграционог теста који повремено пада:

Циљ: Пронаћи и отклонити узрок нестабилног интеграционог теста за API за наплату (checkout).
Улази: Изворни код теста, евиденције неуспјеха из CI-ја, недавни комитови и релевантан код апликације.
Ограничења: Не искључујте тестове, не ублажавајте провјере (assertions) и не мијењајте неповезано понашање апликације.
Очекивани излаз: Закрпа кода, објашњење основног узрока и резултати извршавања тестова.
Критеријуми прихватања: Тест који је раније падао пролази у 10 узастопних покретања, а релевантни скуп регресионих тестова пролази.
Услови неуспјеха: Основни узрок се не може утврдити, исправка уноси регресије или потребно тестно окружење није доступно.

Али постоји још један важан дио: када агент треба да стане?

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

Вратимо се нашем CI примјеру. Могли бисте дефинисати сљедеће услове заустављања:

Успјех: Исправка пролази 10 узастопних покретања тестова и релевантни скуп регресионих тестова.
Ограничење итерација: Агент може испробати највише двије кандидатске исправке.
Буџет извршавања: Агент мора да стане након 60 минута, чак и ако проблем остане нерјешен.
Ограничење делегирања: Агент може делегирати посао једном специјализованом агенту, без даљег делегирања подагентима.
Дјелимичан завршетак: Ако оба покушаја не успију или истекне временско ограничење, агент враћа своја запажања, покушане измјене и резултате тестова.
Блокирано извршавање: Ако тестно окружење није доступно, агент се зауставља и пријављује препреку умјесто да тврди да је успио.

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

Зато пустите оркестраторе да раде свој посао и спроводите предаје позивањем на конкретне артефакте: првобитни задатак, релевантне улазе, излазне артефакте, статус извршавања и све нерјешене проблеме.

Размотрите овај примјер: status: completed односи се на посао додијељен агенту, а не на цијели ток рада. Пошто су тестови још у статусу pending, оркестратор не би требало да одобри коначни резултат.

json

{
  "task_id": "fix-42",
  "status": "completed",
  "artifact_ref": "patch-17",
  "test_status": "pending",
  "blockers": []
}

Историја разговора агента није поуздан запис о напретку тока рада. Када се његов контекстни прозор попуни, аутоматско сажимање може изоставити важне детаље. А ако радни процес падне, сљедећи агент мора да зна који су кораци заиста завршени.

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

Зато држите стање извршавања одвојено од радног контекста агента. Чувајте статусе задатака, покушаје извршавања, завршене кораке и референце на артефакте у трајном складишту. У међувремену, учитавајте само инструкције, улазе и резултате релевантне за тренутни задатак агента, умјесто да цијелу историју извршавања трпате у његов контекстни прозор.

Рецимо да ваш CI агент покрене тестирање, али API захтјев истекне. Да ли тестирање није успјело да почне или га је CI сервис ставио у ред и изгубио одговор?

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

Пролазне грешке (429, 503): Поновите покушај уз ограничено експоненцијално одлагање и насумично одступање (jitter), поштујући Retry-After када је наведен.
Грешке валидације или дозвола (400, 403): Зауставите се или исправите основни проблем умјесто да понављате исти захтјев.
Двосмислени исходи (истек времена након могућег уписа): Провјерите да ли је операција успјела прије него што је поново покушате.

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

За операције са спољним споредним ефектима, додијелите стабилан кључ идемпотентности свакој логичкој радњи и поново га користите при свим поновним покушајима. Ако API подржава дедупликацију на страни сервера, може препознати поновљене захтјеве без двоструког извршавања радње. Ако не подржава, упитајте спољни систем помоћу ID-ја корелације или друге мјеродавне референце.

Када не можете утврдити шта се догодило, зауставите се и ескалирајте.

Примјер логике поновних покушаја за нашег CI агента, изражен псеудокодом:

python

op_id = get_or_create_operation_id(
    task_id=task_id,
    patch_id=patch_id,
    action="start_ci_run"
)

try:
    return ci.start_run(commit, request_id=op_id)
except TimeoutError:
    run = ci.find_by_request_id(op_id)
    if run:
        return run

    if ci.supports_idempotency:
        return bounded_retry(
            lambda: ci.start_run(commit, request_id=op_id)
        )

    raise NeedsReconciliation(op_id)

Напомена о коду: Примјер претпоставља да CI API подржава претрагу покретања по ID-ју захтјева. Вриједност request_id спречава дупликате само ако добављач изричито гарантује идемпотентност. bounded_retry() је илустративни псеудокод. У продукцији, поновни покушаји треба да буду ограничени и буџетом поновних покушаја по операцији (максималним бројем покушаја или протеклим временом) и општим роком за ток рада.

За дуже токове рада који обухватају више сервиса, размотрите образац Saga за координацију компензационих радњи када каснији кораци не успију. Само имајте на уму да компензација није увијек потпуно враћање на претходно стање. Ажурирање базе података можете поништити, али послату е-поруку не можете вратити.

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

Код избора модела, ускладите способности модела и интензитет расуђивања са сложеношћу задатка — једноставно, али прилично занемарено. Имајте на уму да можете сами да конфигуришете правила усмјеравања и процјењујете моделе или да користите платформу за оркестрацију која бира модел умјесто вас.

На примјер, Effort Mode у Perplexity Computer вам омогућава да изаберете колико напора задатак заслужује без ручног бирања модела. Изаберите Light, Standard, High или Ultra, и Perplexity аутоматски бира оркестрирајући модел и његов ниво расуђивања. Тај оркестратор затим делегира подзадатке помоћним агентима, који могу користити моделе различитих добављача.

Perplexity процјењује конфигурације модела према квалитету и трошковима, дајући предност јефтинијим опцијама које дају упоредиве резултате. Можете користити и контроле Custom ако више волите да сами бирате модел и ниво расуђивања.

Код паралелизма, ограничење треба да произилази из ваше инфраструктуре и спољних зависности. Провјерите ограничења броја захтјева и токена заједничких API-ја, а затим тестирајте оптерећење свог тока рада уз растућу конкурентност. Пратите да ли се пропусност побољшава или захтјеви почињу да чекају у реду, успоравају или враћају грешке 429.

Да би потрошња ресурса остала предвидива, наметните ограничења ресурса и контроле распоређивања:

Контролишите конкурентност и брзину захтјева: Ограничите број истовремених позива по сервису и вишак посла ставите у ред. Имајте на уму да само ограничење конкурентности неће наметнути ограничења броја захтјева у минути или токена у минути.
Пратите буџете токена и трошкова: Урачунајте потрошњу у цијелом току рада, укључујући подагенте, и престаните да покрећете нови посао када преостали буџет није довољан.
Наметните рокове извршавања: Поставите временска ограничења за задатке и ток рада и прослиједите отказивање агентима који раде, гдје је то подржано.
Поштујте зависности: Покрећите низводне задатке тек када су им потребни улази доступни, умјесто да истовремено покрећете све агенте.

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

„Скептичан сам према претјерано компликованим вишеагентским системима, посебно када агенти прегледају и одобравају рад једни другима. Може се десити да неколико агената самоувјерено преноси исту грешку, а да је нико заправо не уочи“, упозорава Спилкер.

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

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

њене параметре
њен циљни ресурс
њен комит или верзију стања
одлуку рецензента

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

Дакле, ако је одобрење одбијено или истекне, захтјев се затвара. Ако се циљни комит, параметри или дозволе промијене прије извршавања, поништите одобрење и затражите ново.

Спилкер такође не подржава идеју да су потпуно аутономни агенти који раде од почетка до краја крајњи циљ. „За мене је бољи приступ изградити неколико фокусираних агената са јасним одговорностима, дефинисаним дозволама и људским прегледом у правим тренуцима. И даље добијате ефикасност, а не одричете се потпуне контроле“, закључује он.

Да ли вам је агент икада пријавио Success, а заправо није успио? То нервира, ако не и излуђује, а рјешење није брзо јер вам завршна порука агента неће нужно рећи гдје је нешто пошло наопако.

Да бисте истражили проблем, пратите шта се дешавало током извршавања и независно провјерите резултате. Зато одвојимо мало времена да изолујемо и ријешимо проблем.

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

Семантичке конвенције за GenAI у OpenTelemetry пружају стандардизован начин описивања ових операција. На примјер, invoke_workflow означава извршавање тока рада, invoke_agent позив агента, а execute_tool позив алата. Свака операција може се забиљежити као span са својим трајањем, статусом и релевантним метаподацима.

Овај корак вам даје траг путање извршавања, тако да можете утврдити гдје је агент запео.

plaintext

invoke_agent  generate_patch   OK
execute_tool  start_ci_run     OK  run_id=9812
execute_tool  get_ci_result    TIMEOUT

agent_response: "Success"

Илустративни траг извршавања.

Користите програмске провјере гдје год је то могуће. Валидирајте излазе у односу на JSON шеме, покрећите јединичне и интеграционе тестове, провјерите да ли потребни артефакти постоје и упитајте спољне системе да бисте потврдили да су радње заиста успјеле.

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

И даље морате валидирати налазе рецензента гдје је то могуће, а ако користите оцјењиваче засноване на LLM-у за поновљене евалуације, калибришите њихове процјене према примјерима које су прегледали људи.

До сада сте пратили шта су агенти извршили и провјерили да ли су њихови резултати тачни. Али шта се дешава када се радни процес сруши усред задатка или када API-ју истекне вријеме чекања након што је прихватио захтјев? Изненађујуће, ваш ток рада може се сасвим добро понашати у нормалним условима, али отказати током опоравка.

Да бисте ово тестирали, намјерно убаците грешке у тестно окружење:

Симулирајте истек времена чекања API-ја
Изазовите пад радних процеса између уписа у спољне системе и контролних тачака
Враћајте неисправне излазе алата
Пустите да одобрења истекну

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

Рецимо да ваш CI агент пошаље захтјев за покретање тестирања, али одговору API-ја истекне вријеме чекања. Агент поново покушава, добија успјешан одговор и пријављује Успјех. Све изгледа у реду док не провјерите CI сервис и не откријете да су креирана два тестна покретања умјесто једног.

Зато треба да провјерите и стање које је ток рада забиљежио и стварне промјене у спољним системима. Тест опоравка треба да прође само када ток рада достигне очекивано стање без нежељених споредних ефеката.

Грешке које откријете додајте у своје регресионе тестове како их будуће промјене не би поново унијеле.

На крају, успјех значи да је ток рада прошао обавезне провјере и да су његови исходи у спољним системима провјерени.

Изоловани агенти могу исправно да заврше своје појединачне задатке, али заједно дају недосљедне резултате. Замислите да агент за продају преузима услове купца у 10:00, агент за цијене израчунава понуду по ажурираним цијенама у 10:05, а правни агент провјерава уговор који је промијењен у 10:07. Сваки агент ради са другачијим снимком стања пословања, па њихови резултати могу бити међусобно противрјечни.

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

Поставите ограничења на више нивоа: максималан број поновних покушаја позива алата, максималан број итерација агента, дубину делегирања и укупни рок за ток рада. Класификујте грешке прије поновног покушаја. За привремене одговоре 429 поштујте Retry-After када је наведен. У супротном, користите ограничено експоненцијално одлагање (backoff) са насумичним варирањем (jitter).

Престаните да поново шаљете непромијењене захтјеве након грешака при валидацији или грешака у дозволама. Ако зависни сервис више пута откаже, заштитни прекидач (circuit breaker) може спријечити агенте да стварају додатно оптерећење.

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

Ако се апликација поново постави док се токови рада још извршавају, сачувано стање и историје извршавања можда више неће бити компатибилни. Temporal ово рјешава помоћу функције Worker Versioning и закрпа тока рада (workflow patching). За системе засноване на контролним тачкама, планирајте миграције шеме и тестирајте опоравак на постојећим сачуваним стањима прије увођења некомпатибилних промјена.

Покрените исте репрезентативне задатке више пута и разликујте pass@k (да ли је бар један од k покушаја успјешан) од pass^k (да ли су сви k покушаји успјешни)

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

Шта је оркестрација AI агената?

Како функционише оркестрација AI агената: поглед у механизам извршавања

Када треба користити оркестрацију AI агената?

Архитектуре оркестрације AI агената и њихови компромиси

Централизована оркестрација

Децентрализована оркестрација

Хијерархијска оркестрација

Секвенцијално и паралелно извршавање и извршавање засновано на предаји

Уобичајени пропусти у оркестрацији AI агената

7 најбољих пракси оркестрације AI агената за поузданост у продукцији

1. Дефинишите експлицитне уговоре о задацима, критеријуме прихватања и услове заустављања

2. Нека оркестратори буду једноставни и спроводите структуриране предаје

3. Трајно чувајте стање тока рада и контролишите раст контекста

4. Осмислите поновне покушаје свјесне грешака и извршавање алата из којег је могућ опоравак

5. Усмјеравајте и паралелизујте посао уз експлицитне буџете ресурса

6. Наметните одобрења и изолујте извршавање агената

7. Независно провјеравајте излазе и тестирајте понашање при опоравку

Пратите ток рада да бисте утврдили шта је пошло наопако

Независно прегледајте излаз

Убаците грешке да бисте тестирали опоравак

Најчешћа питања о оркестрацији AI агената

Зашто изоловани AI агенти закажу на нивоу великих предузећа?

Како спријечити бесконачне петље поновних покушаја код AI агената?

Како наставити ток рада AI агента након пада?

Како тестирати поузданост оркестрације AI агената?