Orkestracija AI agenata: greške, odobrenja i ponovni pokušaji

Više agenata koji rade na istom projektu zvuči izuzetno efikasno. Jedan planira posao, drugi se bavi dizajnom, a treći piše kod. Sve funkcioniše dok ne prestane da funkcioniše. A do neuspeha dolazi češće nego što biste želeli.

Sprečavanje ovih otkaza zahteva pažljivo projektovanje radnih tokova. Zato hajde da raščlanimo šta orkestrirane radne tokove čini nepouzdanim i istražimo najbolje prakse orkestracije za pouzdanost u produkciji.

Orkestracija AI agenata koordiniše više AI agenata, modela i alata radi izvršavanja zadatka u više koraka. Ali neko — ili nešto — i dalje mora da odluči koji se agent pokreće prvi, koje informacije dobija i šta se dešava kada završi. To je uloga orkestratora — AI agenta koji deluje kao menadžer ili softverski kontrolisanog sloja izvršavanja.

Jednostavno rečeno, sloj orkestracije deli cilj na manje zadatke, prati zavisnosti, delegira izvršavanje odgovarajućim agentima, upravlja deljenim kontekstom i objedinjuje rezultate.

Dijagram mehanizma za izvršavanje orkestracije: cilj i plan, usmeravanje ka agentima, izolovano izvršavanje alata, strukturirani rezultati, trajno stanje radnog toka i korak validacije i odlučivanja koji ponavlja pokušaj, vraća na prethodni korak, pauzira, čeka ili prelazi na sledeći zadatak.

Pogledajmo šta se dešava kada orkestratoru date zadatak.

Razmotrimo primer iz Perplexity radionice o proizvodu Computer: izrada kontrolne table sa analitikom o klijentima na osnovu informacija iz sistema Salesforce i Snowflake, e-pošte, kalendara i najnovijih vesti.

Razumevanje cilja i planiranje posla. Orkestrator polazi od traženog ishoda i razlaže ga na zadatke sa eksplicitnim zavisnostima. U našem primeru kontrolne table to podrazumeva prikupljanje informacija iz različitih izvora i njihovo pretvaranje u gotov rezultat. Planer utvrđuje koji koraci zavise od drugih, a koji mogu da se izvršavaju nezavisno.
Usmeravanje zadataka ka odgovarajućim agentima. Orkestrator identifikuje zadatke čije su zavisnosti ispunjene i delegira posao specijalizovanim agentima ili modelima. Zavisni zadaci čekaju svoje preduslove. Perplexity Computer koristi više najnaprednijih modela i usmerava različite delove radnog toka ka sistemima koji odgovaraju tim zadacima. To takođe omogućava da se nezavisni poslovi izvršavaju paralelno.
Izvršavanje poziva alata u kontrolisanim okruženjima. Agenti komuniciraju sa svojim okruženjem putem alata, kao što su veb-pretraga, API-ji, povezane aplikacije, operacije sa datotekama ili izvršavanje koda. Sloj izvršavanja pokreće te radnje i vraća rezultate agentima.
Prosleđivanje rezultata i konteksta između agenata. Kada agent završi svoj zadatak, sledećem agentu u nizu potreban je relevantan izlaz da bi nastavio. Zapis o predaji može da sadrži ID zadatka, referencu na izlaz, verziju šeme i metapodatke o izvoru. Orkestrator koordiniše te predaje i istovremeno održava kontekst potreban za naredne korake. Važno je da agenti ne moraju da nose celu istoriju rada svih ostalih agenata u sopstvenim kontekstnim prozorima.
Beleženje stanja izvršavanja odvojeno od konteksta agenta. Kako agenti započinju, završavaju ili ne uspevaju da izvrše zadatke, mehanizam za izvršavanje ažurira trajni zapis radnog toka sa statusima zadataka, pokušajima izvršavanja, referencama na izlaze i preostalim poslom. Ovaj zapis omogućava orkestratoru da prati napredak i nastavi rad nakon prekida, bez oslanjanja na LLM da rekonstruiše radni tok iz istorije razgovora.
Validacija rezultata i odlučivanje o sledećem koraku. Kada zadatak vrati rezultat, sloj orkestracije proverava da li njegov izlaz ispunjava očekivani ugovor i da li su zavisnosti sledećeg zadatka ispunjene. Ako se pronađe problem, radni tok može da se vrati na raniji korak radi ispravke ili da se pauzira. U suprotnom, nastavlja ka završetku.

Iza onoga što izgleda kao jednostavna orkestracija AI agenata krije se mnogo pokretnih delova. Način na koji organizujete koordinaciju agenata određuje koliko kontrole imate nad izvršavanjem. I naravno, sva ta koordinacija donosi dodatno opterećenje. Zato se ne isplati uvek.

Razmotrite orkestraciju više agenata kada različiti delovi zadatka zahtevaju posebnu stručnost, kada nezavisni poslovi mogu da se izvršavaju paralelno ili kada ne možete unapred da odredite sledeći korak.

Dakle, orkestracija je korisna u tri scenarija:

Zadaci zahtevaju različite specijalizacije. Na primer, programerski projekat može imati koristi od zasebnih agenata za planiranje, dizajn, razvoj i pregled.
Nezavisni zadaci mogu da se izvršavaju paralelno. Umesto da jedan agent sve završava redom, više agenata može da radi istovremeno i vraća rezultate orkestratoru.
Problem je otvorenog tipa. Agenti će možda morati da istražuju različite pristupe, donose odluke i sarađuju umesto da prate unapred definisan redosled.

Osim u tim slučajevima, orkestracija je samo skup trend. Više agenata znači i više koordinacije i potencijalno veće troškove tokena.

„Obično počinjem od najjednostavnije opcije i nadograđujem odatle. Ako znamo korake i oni se ponavljaju, to je verovatno radni tok. Razlog za uvođenje više agenata vidim samo kada oni imaju različite odgovornosti, dozvole ili korisnike“, kaže Josh Spilker, šef marketinga za pretragu u kompaniji AirOps.

Čak i tada odmerite prednosti u odnosu na dodatne pozive modela, predaje, kašnjenje i tačke otkaza.

Tri uobičajena načina za strukturiranje koordinacije agenata su centralizovana, decentralizovana i hijerarhijska orkestracija. Izbor prave arhitekture svodi se na jedno pitanje: Ko kontroliše posao i kako agenti međusobno koordinišu rad?

U centralizovanoj orkestraciji jedan orkestrator upravlja procesom. On razlaže zadatak, delegira posao specijalizovanim agentima, prati njihov napredak i objedinjuje njihove rezultate.

Dijagram centralizovane orkestracije: jedan orkestrator prima zahtev korisnika i delegira posao agentima za istraživanje, analizu i dizajn, od kojih svaki koristi sopstvene alate, a njihovi rezultati se objedinjuju u konačnu kontrolnu tablu.

Kompromis: Centralizovana koordinacija olakšava praćenje izvršavanja i primenu zajedničkih pravila na jednoj kontrolnoj tački. Međutim, orkestrator može postati usko grlo, a njegov otkaz može prekinuti ceo radni tok, osim ako sistem ne podržava oporavak.

U decentralizovanoj orkestraciji agenti koordinišu direktnije, umesto da se oslanjaju na jednog menadžera koji donosi svaku odluku. Mogu da razmenjuju poruke, čitaju deljeno stanje i samostalno određuju svoje sledeće korake.

Dijagram decentralizovane orkestracije: agenti za istraživanje, analizu, dizajn i pregled komuniciraju direktno jedni sa drugima, kao i sa deljenim stanjem i alatima, kako bi napravili konačnu kontrolnu tablu.

Kompromis: Agenti mogu da rade bez čekanja na centralnog planera, što ovaj pristup čini korisnim za istraživački rad i nezavisne doprinose. Ali koordinacija postaje teža kada se agenti ne slažu, ažuriraju deljene informacije ili treba da postignu dosledan rezultat.

Hijerarhijska orkestracija proširuje pristup sa menadžerom na više nivoa. Orkestrator najvišeg nivoa delegira odgovornost podređenim orkestratorima, koji koordinišu sopstvene grupe specijalizovanih agenata.

Zamislite radni tok u preduzeću koji uključuje timove za prodaju, finansije i pravne poslove. Orkestrator najvišeg nivoa mogao bi da delegira svaki radni tok koordinatoru specijalizovanom za određeni domen. Ti koordinatori bi zatim upravljali sopstvenim specijalizovanim agentima i izveštavali o objedinjenim rezultatima.

Ova struktura može da pomogne kada su radni tokovi preobimni da bi ih jedan orkestrator efikasno vodio.

Dijagram hijerarhijske orkestracije: orkestrator najvišeg nivoa delegira posao orkestratorima za prodaju, finansije i pravne poslove, od kojih svaki upravlja sa dva specijalizovana agenta, a njihov rad se objedinjuje u konsolidovani izlaz.

Kompromis: Hijerarhije omogućavaju timovima da podele odgovornosti za koordinaciju i potencijalno obrađuju otkaze unutar pojedinačnih grana. Međutim, one uvode dodatne predaje, složenije upravljanje stanjem i veće operativno opterećenje. Lokalni oporavak takođe zavisi od toga kako su implementirane kontrolne tačke i stanje izvršavanja.

Poređenje ovih arhitektura:

Kriterijumi	Centralizovana	Decentralizovana	Hijerarhijska
Odgovornost za izvršavanje	Jedan orkestrator kontroliše delegiranje	Agenti koordinišu putem drugih agenata ili deljenog stanja	Odgovornost je raspoređena na nivoe orkestracije
Doslednost stanja	Lakša koordinacija preko jedne kontrolne tačke	Zahteva eksplicitnu sinhronizaciju i rešavanje konflikata	Zahteva koordinaciju unutar grana i između njih
Izolacija otkaza	Centralni kontroler može postati kritična zavisnost	Pojedinačni agenti mogu otkazati nezavisno, ali deljena infrastruktura ostaje kritična	Otkazi mogu ostati ograničeni na grane ako je sistem projektovan za oporavak
Sprovođenje politika	Zajedničke kontrole mogu se sprovoditi centralizovano	Politike se moraju dosledno sprovoditi kod svih učesnika	Kontrole se mogu primenjivati na globalnom nivou i na nivou domena
Operativna složenost	Uglavnom niža	Veća složenost koordinacije	Veća složenost zbog više slojeva orkestracije

Postoji još jedna razlika koju vredi razumeti. Arhitektura određuje ko koordinira agente. Obrazac izvršavanja određuje kako napreduju njihovi zadaci.

Ovo su tri obrasca izvršavanja:

Sekvencijalni radni tokovi: Agenti rade unapred definisanim redosledom, pri čemu rezultat jednog agenta postaje ulaz za drugog.
Paralelno izvršavanje: Nezavisni agenti rade istovremeno.
Izvršavanje zasnovano na predaji zadataka: Kontrola prelazi sa jednog specijalizovanog agenta na drugi kako zadatak napreduje. Ovo je korisno kada je neki drugi agent bolje opremljen za sledeći korak, mada svaka predaja mora da sačuva informacije potrebne za nastavak.

Ovi obrasci se međusobno ne isključuju i ne odgovaraju jedan-na-jedan arhitekturama orkestracije. Cilj je odabrati najjednostavniju strukturu koja podržava zavisnosti vašeg radnog toka, zahteve za koordinaciju i prihvatljive operativne troškove.

Kod orkestracije svašta može da pođe naopako, od jednostavnih propusta do složenih prepreka. Ponekad agent može čak da deluje kao da ispravno obavlja svoj posao, dok ceo radni tok ne uspeva. Na osnovu iskustava praktičara sastavili smo neke od čestih grešaka koje stoje iza nepouzdanih orkestriranih radnih tokova — obratite pažnju na njih:

Predaje između agenata uz gubitak informacija. Orkestrator prosleđuje sažeti plan specijalizovanom agentu, ali u sažetku izostaju ograničenja, zavisnosti ili detalji implementacije.
Preuranjeno objedinjavanje rezultata (fan-in). Agent nizvodno počinje da objedinjuje rezultate pre nego što se završe svi uzvodni zadaci.
Nedeterministička ažuriranja deljenog stanja. Paralelni agenti upisuju u iste ključeve stanja bez jasno definisane semantike spajanja. U zavisnosti od toga kako okvir obrađuje ažuriranja, to može dovesti do izgubljenih upisa, dupliranih podataka, izlaza koji zavisi od redosleda ili konfliktnih izmena.
Razilaženje kontrolnih tačaka i sporednih efekata. Zadatak izvršava spoljnu operaciju, ali njeno uspešno izvršavanje nije trajno zabeleženo pre nego što radni proces otkaže. Pri oporavku, orkestrator vidi nezavršen zadatak i ponovo ga pokreće.
Trke pri nastavljanju nakon ljudskog odobrenja. Pauziranje i nastavljanje izvršavanja donosi sopstvene probleme sinhronizacije.
Petlje delegiranja i umnožavanje ponovnih pokušaja. Agenti iznova prebacuju posao jedni drugima jer im se odgovornosti preklapaju, zavisnosti su kružne ili su uslovi završetka dvosmisleni.
Kontrole na nivou instrukcija pogrešno shvaćene kao bezbednost izvršavanja. Orkestrator može da kaže agentima da ne pristupaju određenim resursima ili da ne izvršavaju osetljive radnje, ali instrukcije modelu ne nameću dozvole operativnog sistema, mrežna ograničenja ni granice autorizacije. Istraživanje bezbednosnog inženjeringa kompanije Perplexity ističe zašto agenti mogu da pređu bezbednosne granice dok teže legitimnim ciljevima, čak i bez zlonamernih instrukcija

Primetite koliko su ovi neuspesi različiti. Preuranjeni prelaz planera ili dvosmislen spoljni upis mogu da dovedu do pogrešnog ishoda, ali potiču iz različitih delova životnog ciklusa izvršavanja. Zato pouzdana orkestracija zahteva više od poboljšavanja promptova ili dodavanja ponovnih pokušaja.

Nejasni ciljevi i nejasna definicija završenog posla često dovode do razočaravajućih rezultata koje generišu agenti. Rešenje je ugovor o promptu (opis obima posla za agenta): dogovorite cilj, ograničenja, format izlaza i uslove neuspeha pre početka izvršavanja.

Na primer, evo kako biste mogli da definišete ugovor za agenta zaduženog za popravku integracionog testa koji povremeno ne prolazi:

Cilj: Pronaći i otkloniti uzrok nestabilnog integracionog testa za API za završetak kupovine.
Ulazi: Izvorni kod testa, logovi neuspeha u CI-ju, nedavni komitovi i relevantni kod aplikacije.
Ograničenja: Ne onemogućavajte testove, ne ublažavajte provere (assertions) i ne menjajte nepovezano ponašanje aplikacije.
Očekivani izlaz: Zakrpa koda, objašnjenje osnovnog uzroka i rezultati izvršavanja testova.
Kriterijumi prihvatanja: Test koji je ranije padao prolazi u 10 uzastopnih pokretanja, a prolazi i relevantni skup regresionih testova.
Uslovi neuspeha: Osnovni uzrok ne može da se utvrdi, popravka uvodi regresije ili potrebno testno okruženje nije dostupno.

Ali postoji još jedan važan deo: kada agent treba da stane?

Agent ne bi trebalo da nastavi da iterira u nedogled samo zato što nije dao zadovoljavajući rezultat. Definišite šta se smatra uspešnim završetkom, kada treba vratiti delimično završen zadatak i kada treba stati jer zahtev ne može da se ispuni. Postavite maksimalnu dubinu delegiranja i ograničenja broja iteracija ili budžete izvršavanja kako nerešeni zadaci ne bi postali beskonačne petlje.

Vratimo se našem CI primeru. Mogli biste da definišete sledeće uslove zaustavljanja:

Uspeh: Popravka prolazi 10 uzastopnih pokretanja testa i relevantni skup regresionih testova.
Ograničenje iteracija: Agent može da pokuša najviše dve potencijalne popravke.
Budžet izvršavanja: Agent mora da stane nakon 60 minuta, čak i ako problem ostane nerešen.
Ograničenje delegiranja: Agent može da delegira posao jednom specijalizovanom agentu, bez daljeg delegiranja podagentima.
Delimičan završetak: Ako oba pokušaja ne uspeju ili istekne vremensko ograničenje, agent vraća svoje nalaze, pokušane izmene i rezultate testova.
Blokirano izvršavanje: Ako testno okruženje nije dostupno, agent se zaustavlja i prijavljuje prepreku umesto da tvrdi da je uspeo.

Programeri ponekad orkestratoru daju previše odgovornosti, pa umesto da koordinira specijalizovane agente, on počinje sam da piše kod, otklanja greške ili obavlja detaljne preglede. To stvara usko grlo: orkestrator troši svoj budžet konteksta na detalje implementacije, odlaže delegiranje i zamagljuje odgovornost za rezultate.

Zato pustite orkestratore da rade svoj posao i sprovodite predaje pozivanjem na konkretne artefakte: prvobitni zadatak, relevantne ulaze, izlazne artefakte, status izvršavanja i sve nerešene probleme.

Razmotrite ovaj primer: status: completed se odnosi na posao dodeljen agentu, a ne na ceo radni tok. Pošto su testovi i dalje u statusu pending, orkestrator ne bi trebalo da odobri konačni rezultat.

json

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

Istorija razgovora agenta nije pouzdan zapis napretka radnog toka. Kada se njegov kontekstni prozor popuni, automatsko sažimanje može da izostavi važne detalje. A ako radni proces padne, sledeći agent mora da zna koji su koraci zaista završeni.

Na primer, ako agent za kodiranje generiše zakrpu, a zatim padne, sledeći radni proces treba da preuzme sačuvani artefakt i nastavi od zabeleženog stanja radnog toka. Ali ako je agent pokrenuo i spoljno CI pokretanje, orkestrator mora zasebno da usaglasi to pokretanje pre nego što ponovi radnju

Zato držite stanje izvršavanja odvojeno od radnog konteksta agenta. Statuse zadataka, pokušaje izvršavanja, završene korake i reference na artefakte čuvajte u trajnom skladištu. U međuvremenu, učitavajte samo instrukcije, ulaze i rezultate relevantne za trenutni zadatak agenta, umesto da u njegov kontekstni prozor trpate celu istoriju izvršavanja.

Recimo da vaš CI agent pokrene testiranje, ali API zahtevu istekne vreme. Da li testiranje nije uspelo da se pokrene ili ga je CI servis stavio u red i izgubio odgovor?

Isticanje vremena ne znači nužno da operacija nije uspela. Zato morate da razlikujete greške pre nego što odlučite šta sledi:

Prolazne greške (429, 503): Pokušajte ponovo uz ograničeno eksponencijalno odlaganje i nasumično odstupanje (jitter), poštujući Retry-After kada je naveden.
Greške validacije ili dozvola (400, 403): Zaustavite se ili otklonite osnovni problem umesto da ponavljate isti zahtev.
Dvosmisleni ishodi (isticanje vremena nakon mogućeg upisa): Proverite da li je operacija uspela pre nego što je ponovo pokušate.

Napomena: Čak i greške nakon kojih je moguć ponovni pokušaj zahtevaju ograničenja. Postavite vremensko ograničenje za svaki poziv alata, ograničite broj ponovnih pokušaja i njihovo ukupno trajanje i sprovedite ukupni rok za radni tok kako ugnežđeni agenti ne bi mogli iznova da pokreću istu operaciju. Ako neka zavisnost uzastopno otkazuje, upotrebite prekidač strujnog kola (circuit breaker) da biste privremeno zaustavili zahteve.

Za operacije sa spoljnim sporednim efektima dodelite stabilan ključ idempotentnosti svakoj logičkoj radnji i ponovo ga koristite u svim ponovnim pokušajima. Ako API podržava deduplikaciju na strani servera, može da prepozna ponovljene zahteve bez dvostrukog izvršavanja radnje. Ako ne podržava, pošaljite upit spoljnom sistemu pomoću ID-ja korelacije ili druge merodavne reference.

Kada ne možete da utvrdite šta se dogodilo, zaustavite se i eskalirajte.

Primer logike ponovnih pokušaja za našeg CI agenta, izražen kao pseudokod:

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)

Napomena o kodu: Primer pretpostavlja da CI API podržava pretragu pokretanja po ID-ju zahteva. Parametar request_id sprečava duplikate samo ako dobavljač izričito garantuje idempotentnost. bounded_retry() je ilustrativni pseudokod. U produkciji, ponovni pokušaji treba da budu ograničeni i budžetom ponovnih pokušaja po operaciji (maksimalan broj pokušaja ili proteklo vreme) i ukupnim rokom radnog toka.

Za duže radne tokove koji obuhvataju više servisa razmotrite obrazac Saga za koordinaciju kompenzacionih radnji kada kasniji koraci ne uspeju. Samo imajte na umu da kompenzacija nije uvek potpuno vraćanje na prethodno stanje. Možete da poništite ažuriranje baze podataka, ali ne možete da opozovete poslati imejl.

Ovde treba uravnotežiti dve stvari: koliko mogućnosti modela je potrebno svakom zadatku i koliko zadataka možete da pokrenete istovremeno. Ako pogrešite u bilo čemu od toga, rizikujete da se agenti takmiče za deljene API kvote ili da se oslanjate samo na skupe modele za rezonovanje.

Kada je reč o izboru modela, uskladite mogućnosti modela i intenzitet rezonovanja sa složenošću zadatka — jednostavno, ali često zanemareno. Imajte na umu da možete sami da konfigurišete pravila usmeravanja i procenjujete modele ili da koristite platformu za orkestraciju koja umesto vas bira model.

Na primer, Effort Mode u okviru Perplexity Computer vam omogućava da izaberete koliko truda zadatak zaslužuje bez ručnog biranja modela. Izaberite Light, Standard, High ili Ultra, a Perplexity automatski bira model za orkestraciju i njegov nivo rezonovanja. Taj orkestrator zatim delegira podzadatke pomoćnim agentima, koji mogu da koriste modele različitih dobavljača.

Perplexity procenjuje konfiguracije modela prema kvalitetu i ceni, dajući prednost jeftinijim opcijama koje daju uporedive rezultate. Možete da koristite i kontrole Custom ako želite sami da izaberete model i nivo rezonovanja.

Kada je reč o paralelizmu, ograničenje treba da proistekne iz vaše infrastrukture i spoljnih zavisnosti. Proverite ograničenja broja zahteva i tokena deljenih API-ja, a zatim testirajte opterećenje svog radnog toka uz sve veću konkurentnost. Pratite da li se propusnost poboljšava ili zahtevi počinju da čekaju u redu, usporavaju ili vraćaju greške 429.

Da bi potrošnja resursa ostala predvidiva, sprovodite ograničenja resursa i kontrole raspoređivanja:

Kontrolišite konkurentnost i učestalost zahteva: Ograničite broj istovremenih poziva po servisu i višak posla stavite u red. Imajte na umu da samo ograničenje konkurentnosti neće sprovesti ograničenja broja zahteva u minuti ili tokena u minuti.
Pratite budžete tokena i troškova: Uračunajte potrošnju u celom radnom toku, uključujući podagente, i prestanite da pokrećete novi posao kada preostali budžet nije dovoljan.
Sprovodite rokove izvršavanja: Postavite vremenska ograničenja za zadatke i radne tokove i prosledite otkazivanje agentima koji su pokrenuti, gde je to podržano.
Poštujte zavisnosti: Pokrećite zadatke nizvodno tek kada su dostupni ulazi koji su im potrebni, umesto da istovremeno pokrećete sve agente.

Nikada ne tražite od modela da sam odluči da li su njegove radnje bezbedne. Umesto toga, dajte agentima dozvole po principu najmanjih privilegija i sprovodite pravila odobravanja zasnovana na riziku u kodu aplikacije. Ako agenti izvršavaju kod, izolujte to izvršavanje od svog okruženja domaćina i ograničite pristup datotekama, mrežama i akreditivima. Tako se ograničava šteta ako agent pogreši ili izvrši nebezbedan kod.

„Skeptičan sam prema preterano složenim sistemima sa više agenata, naročito kada agenti pregledaju i odobravaju rad jedni drugih. Može se desiti da nekoliko agenata samouvereno prosleđuje istu grešku dalje, a da je niko zapravo ne uoči“, upozorava Spilker.

Dijagram toka odobravanja: agent predlaže operaciju sa parametrima, ciljnim resursom i verzijom stanja; čovek je odobrava ili odbija; odobrene operacije se ponovo validiraju i pokreću u izolovanom okruženju sa ograničenim pristupom datotekama, mreži i akreditivima. Odbijeni zahtevi i zahtevi kojima je istekao rok se zatvaraju, a izmenjeni zahtevi zahtevaju novo odobrenje.

Za radnje koje zahtevaju ljudsko odobrenje pauzirajte izvršavanje i sačuvajte tačnu predloženu operaciju:

njene parametre
njen ciljni resurs
njen komit ili verziju stanja
odluku recenzenta

Takođe, definišite šta se dešava ako je odobrenje odbijeno, ako istekne ili ako zahteva eskalaciju. Ovo je neophodno za okvire koji podržavaju nastavljanje, jer se pri nastavljanju prekinutog čvora kod ponovo izvršava od početka tog čvora. Svi sporedni efekti pre prekida mogu ponovo da se izvrše.

Dakle, ako je odobrenje odbijeno ili istekne, zahtev se zatvara. Ako se ciljni komit, parametri ili dozvole promene pre izvršavanja, poništite odobrenje i zatražite novo.

Spilker takođe ne podržava ideju da su potpuno autonomni agenti koji sve obavljaju od početka do kraja cilj kome treba težiti. „Za mene je bolji pristup napraviti nekoliko fokusiranih agenata sa jasnim odgovornostima, definisanim dozvolama i ljudskim pregledom u pravim trenucima. I dalje dobijate efikasnost, a da se ne odričete potpune kontrole“, zaključuje on.

Da li vam se ikada desilo da agent prijavi Uspeh, a zapravo nije uspeo? To je iritantno, ako ne i izluđujuće, a rešenje nije brzo jer vam konačna poruka agenta ne mora nužno reći gde je nešto pošlo naopako.

Da biste to istražili, pratite šta se dešavalo tokom izvršavanja i nezavisno proverite rezultate. Zato hajde da odvojimo malo vremena za izolovanje i rešavanje problema.

Pre nego što počnete da otklanjate greške u promptovima agenta, zabeležite celu putanju izvršavanja. Potreban vam je trag (trace) koji povezuje pozive agenata, pozive alata, greške i ponovne pokušaje u okviru istog pokretanja radnog toka.

OpenTelemetry nudi semantičke konvencije za GenAI, koje pružaju standardizovan način za opisivanje ovih operacija. Na primer, invoke_workflow označava izvršavanje radnog toka, invoke_agent poziv agenta, a execute_tool poziv alata. Svaka operacija može da se zabeleži kao span sa svojim vremenom, statusom i relevantnim metapodacima.

Ovaj korak vam daje trag putanje izvršavanja, pa možete da utvrdite gde je agent zapeo.

plaintext

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

agent_response: "Success"

Ilustrativni trag izvršavanja.

Kad god je moguće, koristite programske provere. Validirajte izlaze prema JSON šemama, pokrećite jedinične i integracione testove, proverite da li potrebni artefakti postoje i pošaljite upite spoljnim sistemima da biste potvrdili da su radnje zaista uspele.

Za izlaze koji zahtevaju subjektivnu procenu — i stoga ne mogu da se procene programskim proverama — uvedite nezavisnog agenta recenzenta. Jedan pristup je petlja implementator–recenzent–razrešivač, u kojoj jedan agent pravi artefakt, recenzent sa svežim kontekstom pronalazi probleme, a razrešivač ih rešava pre nego što se validacija ponovo pokrene.

I dalje morate da validirate nalaze recenzenta kad god je moguće, a ako koristite ocenjivače zasnovane na LLM-u za ponovljene evaluacije, kalibrišite njihove procene prema primerima koje su pregledali ljudi.

Do sada ste pratili šta su agenti izvršili i proveravali da li su njihovi izlazni rezultati tačni. Ali šta se dešava kada se radni proces sruši usred zadatka ili kada API-ju istekne vreme nakon što je prihvatio zahtev? Iznenađujuće, vaš radni tok može savršeno da funkcioniše u normalnim uslovima, ali da zakaže tokom oporavka.

Da biste ovo testirali, namerno ubacite greške u testnom okruženju:

Simulirajte istek vremena za API
Srušite radne procese između upisa u spoljne sisteme i kontrolnih tačaka
Vraćajte neispravno formatirane izlaze alata
Pustite da odobrenja isteknu

Nakon svakog testa pregledajte trag izvršavanja da biste videli koji su koraci pokrenuti, gde je radni tok nastavljen i da li su neke radnje ponovljene ili preskočene. Zatim pregledajte stvarne rezultate.

Recimo da vaš CI agent pošalje zahtev za pokretanje testiranja, ali odgovoru API-ja istekne vreme. Agent ponovi pokušaj, dobije uspešan odgovor i prijavi Uspeh. Sve izgleda u redu dok ne proverite CI servis i otkrijete da su kreirana dva pokretanja testova umesto jednog.

Zato treba da proverite i stanje koje je radni tok zabeležio i stvarne promene u spoljnim sistemima. Test oporavka treba da prođe samo kada radni tok dostigne očekivano stanje bez neželjenih sporednih efekata.

Greške koje otkrijete dodajte u regresione testove kako ih buduće izmene ne bi ponovo uvele.

Na kraju krajeva, uspeh znači da je radni tok prošao obavezne provere i da su njegovi ishodi u spoljnim sistemima provereni.

Izolovani agenti mogu ispravno da obave svoje pojedinačne zadatke, ali da zajedno daju nedosledne rezultate. Zamislite prodajnog agenta koji preuzima uslove kupca u 10:00, agenta za cene koji izračunava ponudu na osnovu ažuriranih cena u 10:05 i pravnog agenta koji proverava ugovor izmenjen u 10:07. Svaki agent radi sa drugačijim snimkom stanja poslovanja, pa njihovi rezultati mogu biti međusobno protivrečni.

Problem postaje izraženiji na nivou velikih preduzeća jer agenti komuniciraju sa više sistema koji se ažuriraju nezavisno, rade sa različitim dozvolama i ne dele nužno kontekst ili stanje izvršavanja.

Postavite ograničenja na više nivoa: maksimalan broj ponovnih pokušaja poziva alata, maksimalan broj iteracija agenta, dubinu delegiranja i ukupni rok za radni tok. Klasifikujte greške pre ponovnog pokušaja. Za privremene odgovore 429 poštujte Retry-After kada je naveden. U suprotnom, koristite ograničeno eksponencijalno odlaganje (backoff) sa nasumičnim odstupanjem (jitter).

Prestanite da ponavljate nepromenjene zahteve nakon grešaka validacije ili dozvola. Ako nizvodni servis uzastopno otkazuje, mehanizam za prekid kola (circuit breaker) može da spreči agente da stvaraju dodatno opterećenje.

Mehanizam oporavka zavisi od vašeg okruženja za izvršavanje. Kod LangGraph-a, trajni checkpointer kao što je PostgresSaver čuva stanje grafa pod identifikatorom thread_id, što omogućava da se izvršavanje nastavi od sačuvanog stanja. Kod Temporal-a, drugi radni proces može da rekonstruiše radni tok ponovnim izvođenjem njegove istorije događaja. Tokom ponovnog izvođenja koriste se prethodno zabeleženi rezultati aktivnosti.

Ako se aplikacija ponovo implementira dok su radni tokovi još u toku, sačuvano stanje i istorije izvršavanja možda više neće biti kompatibilni. Temporal to rešava pomoću funkcije Worker Versioning i zakrpa radnih tokova (workflow patching). Kod sistema zasnovanih na kontrolnim tačkama, planirajte migracije šeme i testirajte oporavak na postojećim sačuvanim stanjima pre uvođenja nekompatibilnih izmena.

Pokrenite iste reprezentativne zadatke više puta i razlikujte pass@k (da li uspe bar jedan od k pokušaja) od pass^k (da li uspeju svi k pokušaji)

Merite rezultate po kategoriji zadatka i verziji radnog toka umesto da se oslanjate na jednu zbirnu stopu uspešnosti. Pratite uspešnost iz prvog pokušaja, doslednost tokom ponovljenih pokretanja, p95 latenciju, trošak po završenom zadatku i udeo zadataka koji zahtevaju ljudsku intervenciju. Navedite veličine uzoraka i intervale nesigurnosti za stope uspešnosti.

Šta je orkestracija AI agenata?

Kako funkcioniše orkestracija AI agenata: unutar mehanizma za izvršavanje

Kada treba koristiti orkestraciju AI agenata?

Arhitekture orkestracije AI agenata i njihovi kompromisi

Centralizovana orkestracija

Decentralizovana orkestracija

Hijerarhijska orkestracija

Sekvencijalno i paralelno izvršavanje i izvršavanje zasnovano na predaji zadataka

Česti neuspesi u orkestraciji AI agenata

7 najboljih praksi orkestracije AI agenata za pouzdanost u produkciji

1. Definišite eksplicitne ugovore o zadacima, kriterijume prihvatanja i uslove zaustavljanja

2. Neka orkestratori budu jednostavni i sprovodite strukturisane predaje

3. Trajno čuvajte stanje radnog toka i kontrolišite rast konteksta

4. Osmislite ponovne pokušaje svesne neuspeha i izvršavanje alata koje omogućava oporavak

5. Usmeravajte i paralelizujte posao uz eksplicitne budžete resursa

6. Sprovodite odobrenja i izolujte izvršavanje agenata

7. Nezavisno proverite izlaze i testirajte ponašanje pri oporavku

Pratite radni tok da biste utvrdili šta je pošlo naopako

Nezavisno pregledajte izlaz

Ubacujte namerne kvarove da biste testirali oporavak

Česta pitanja o orkestraciji AI agenata

Zašto izolovani AI agenti zakazuju na nivou velikih preduzeća?

Kako sprečiti beskonačne petlje ponovnih pokušaja kod AI agenata?

Kako nastaviti radni tok AI agenta nakon pada?

Kako testirati pouzdanost orkestracije AI agenata?