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

Više agenata koji rade na istom projektu zvuči iznimno učinkovito. Jedan planira posao, drugi se bavi dizajnom, a treći piše kôd. Funkcionira sve dok ne prestane funkcionirati. A neuspjesi se događaju češće nego što biste željeli.

Sprječavanje takvih neuspjeha zahtijeva pažljivo osmišljene tijekove rada. Pogledajmo zato što orkestrirane tijekove rada čini nepouzdanima i istražimo najbolje prakse orkestracije za pouzdan rad u produkciji.

Orkestracija AI agenata koordinira više AI agenata, modela i alata kako bi se dovršio zadatak od više koraka. No netko – ili nešto – i dalje mora odlučiti koji se agent pokreće prvi, koje informacije prima i što se događa nakon što završi. To je uloga orkestratora, bilo AI agenta koji djeluje kao upravitelj, bilo softverski upravljanog izvršnog sloja.

Jednostavno rečeno, orkestracijski sloj rastavlja cilj na manje zadatke, prati ovisnosti, delegira izvršavanje odgovarajućim agentima, upravlja zajedničkim kontekstom i objedinjuje rezultate.

Dijagram izvršnog mehanizma orkestracije: cilj i plan, usmjeravanje agentima, izolirano izvršavanje alata, strukturirani rezultati, trajno stanje tijeka rada te korak provjere i odlučivanja koji ponavlja pokušaj, vraća, pauzira, čeka ili prelazi na sljedeći zadatak.

Pogledajmo što se događa nakon što orkestratoru zadate zadatak.

Uzmimo primjer iz radionice o Computeru tvrtke Perplexity: izrada nadzorne ploče s podacima o klijentskim računima pomoću informacija iz sustava Salesforce i Snowflake, e-pošte, kalendara i nedavnih vijesti.

Razumijevanje cilja i planiranje posla. Orkestrator polazi od traženog ishoda i rastavlja ga na zadatke s eksplicitnim ovisnostima. U našem primjeru nadzorne ploče to uključuje prikupljanje informacija iz različitih izvora i njihovo pretvaranje u gotov rezultat. Planer utvrđuje koji koraci ovise o drugima, a koji se mogu izvoditi neovisno.
Usmjeravanje zadataka odgovarajućim agentima. Orkestrator prepoznaje zadatke čije su ovisnosti zadovoljene i delegira posao specijaliziranim agentima ili modelima. Ovisni zadaci čekaju svoje preduvjete. Perplexity Computer koristi više najnaprednijih modela i usmjerava različite dijelove tijeka rada sustavima prikladnima za te zadatke. To također omogućuje paralelno izvođenje neovisnog posla.
Izvršavanje poziva alata u kontroliranim okruženjima. Agenti komuniciraju sa svojim okruženjem putem alata kao što su pretraživanje weba, API-ji, povezane aplikacije, operacije s datotekama ili izvršavanje koda. Izvršni sloj izvodi te radnje i vraća rezultate agentima.
Prosljeđivanje rezultata i konteksta između agenata. Kada agent završi svoj zadatak, sljedeći agent u nizu treba relevantne rezultate kako bi nastavio. Zapis o predaji mogao bi sadržavati ID zadatka, referencu na rezultat, verziju sheme i metapodatke o izvoru. Orkestrator koordinira te predaje i pritom održava kontekst potreban za sljedeće korake. Važno je da agenti ne moraju nositi cijelu povijest rada svih ostalih agenata u vlastitim kontekstnim prozorima.
Bilježenje stanja izvršavanja odvojeno od konteksta agenta. Dok agenti započinju, dovršavaju ili ne uspijevaju izvršiti zadatke, izvršni mehanizam ažurira trajni zapis tijeka rada sa statusima zadataka, pokušajima izvršavanja, referencama na rezultate i preostalim poslom. Taj zapis omogućuje orkestratoru da prati napredak i nastavi nakon prekida, bez oslanjanja na LLM koji bi rekonstruirao tijek rada iz povijesti razgovora.
Provjera rezultata i odlučivanje o sljedećem koraku. Kada se zadatak vrati, orkestracijski sloj provjerava ispunjava li njegov rezultat očekivani ugovor i jesu li zadovoljene ovisnosti sljedećeg zadatka. Ako se otkrije problem, tijek rada može se vratiti na raniji korak radi ispravka ili se pauzirati. U suprotnom, nastavlja prema dovršetku.

Iza naizgled jednostavne orkestracije AI agenata krije se mnogo pokretnih dijelova. Način na koji organizirate koordinaciju agenata određuje koliko kontrole imate nad izvršavanjem. I naravno, sva ta koordinacija stvara dodatno opterećenje. Zato se ne isplati uvijek.

Razmislite o orkestraciji više agenata kada različiti dijelovi zadatka zahtijevaju različita stručna znanja, kada se neovisni posao može izvoditi paralelno ili kada ne možete unaprijed odrediti sljedeći korak.

Stoga je orkestracija korisna u tri scenarija:

Zadaci zahtijevaju različite specijalizacije. Programerski projekt, na primjer, mogao bi imati koristi od zasebnih agenata za planiranje, dizajn, razvoj i pregled.
Neovisni zadaci mogu se izvoditi paralelno. Umjesto da jedan agent sve dovršava redom, više agenata može raditi istodobno i vraćati svoje rezultate orkestratoru.
Problem je otvorenog tipa. Agenti će možda morati istraživati različite pristupe, donositi odluke i surađivati umjesto da slijede unaprijed definirani slijed.

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

„Obično počinjem s najjednostavnijom opcijom i nadograđujem od toga. Ako znamo korake i ponovljivi su, to je vjerojatno tijek rada. Razlog za uvođenje više agenata vidim samo kada oni imaju različite odgovornosti, dopuštenja ili korisnike“, kaže Josh Spilker, voditelj marketinga za pretraživanje u tvrtki AirOps.

Čak i tada odvagnite koristi u odnosu na dodatne pozive modela, predaje, latenciju i točke kvara.

Tri uobičajena načina strukturiranja koordinacije agenata su centralizirana, decentralizirana i hijerarhijska orkestracija. Odabir prave arhitekture svodi se na jedno pitanje: Tko upravlja poslom i kako se agenti međusobno koordiniraju?

U centraliziranoj orkestraciji jedan orkestrator upravlja procesom. Rastavlja zadatak, delegira posao specijaliziranim agentima, prati njihov napredak i objedinjuje njihove rezultate.

Dijagram centralizirane orkestracije: jedan orkestrator prima korisnikov zahtjev i delegira ga agentima za istraživanje, analizu i dizajn, od kojih svaki koristi vlastite alate, a njihovi se rezultati objedinjuju u konačnu nadzornu ploču.

Kompromis: Centralizirana koordinacija olakšava praćenje izvršavanja i primjenu zajedničkih pravila na jednoj kontrolnoj točki. Međutim, orkestrator može postati usko grlo, a njegov kvar može prekinuti cijeli tijek rada, osim ako sustav ne podržava oporavak.

U decentraliziranoj orkestraciji agenti se koordiniraju izravnije umjesto da se oslanjaju na jednog upravitelja koji donosi svaku odluku. Mogu razmjenjivati poruke, čitati zajedničko stanje i samostalno određivati svoje sljedeće korake.

Dijagram decentralizirane orkestracije: agenti za istraživanje, analizu, dizajn i pregled komuniciraju izravno jedni s drugima te sa zajedničkim stanjem i alatima kako bi izradili konačnu nadzornu ploču.

Kompromis: Agenti mogu raditi bez čekanja na središnjeg planera, zbog čega je ovaj pristup koristan za istraživački rad i neovisne doprinose. No koordinacija postaje teža kada se agenti ne slažu, ažuriraju zajedničke informacije ili trebaju postići dosljedan rezultat.

Hijerarhijska orkestracija proširuje pristup s upraviteljem na više razina. Orkestrator najviše razine delegira odgovornost podređenim orkestratorima, koji koordiniraju vlastite skupine specijaliziranih agenata.

Zamislite poslovni tijek rada koji uključuje prodajni, financijski i pravni tim. Orkestrator najviše razine mogao bi svako područje rada delegirati koordinatoru specijaliziranom za određenu domenu. Ti bi koordinatori zatim upravljali vlastitim specijaliziranim agentima i izvještavali o objedinjenim rezultatima.

Ova struktura može pomoći kada su tijekovi rada preopsežni da bi njima jedan orkestrator mogao učinkovito upravljati.

Dijagram hijerarhijske orkestracije: orkestrator najviše razine delegira orkestratorima za prodaju, financije i pravne poslove, od kojih svaki upravlja s dva specijalizirana agenta, a njihov se rad objedinjuje u konsolidirani rezultat.

Kompromis: Hijerarhije omogućuju timovima da podijele odgovornosti za koordinaciju i potencijalno obrađuju pogreške unutar pojedinih grana. Međutim, one uvode dodatne primopredaje, složenije upravljanje stanjem i veće operativno opterećenje. Lokalni oporavak također ovisi o tome kako su implementirane kontrolne točke i stanje izvršavanja.

Usporedba ovih arhitektura:

Kriteriji	Centralizirana	Decentralizirana	Hijerarhijska
Odgovornost za izvršavanje	Jedan orkestrator upravlja delegiranjem	Agenti se koordiniraju putem drugih agenata ili zajedničkog stanja	Odgovornost je raspodijeljena na razine orkestracije
Dosljednost stanja	Lakša koordinacija putem jedne kontrolne točke	Zahtijeva eksplicitnu sinkronizaciju i rješavanje sukoba	Zahtijeva koordinaciju unutar grana i između njih
Izolacija kvarova	Središnji kontroler može postati kritična ovisnost	Pojedinačni agenti mogu zakazati neovisno, ali zajednička infrastruktura ostaje kritična	Kvarovi mogu ostati ograničeni na grane ako je sustav osmišljen za oporavak
Provedba pravila	Zajedničke kontrole mogu se provoditi centralizirano	Pravila se moraju dosljedno provoditi kod svih sudionika	Kontrole se mogu primijeniti na globalnoj razini i na razini domene
Operativna složenost	Općenito niža	Veća složenost koordinacije	Veća složenost zbog više slojeva orkestracije

Postoji još jedna razlika koju vrijedi razumjeti. Arhitektura određuje tko koordinira agente. Obrazac izvršavanja određuje kako napreduju njihovi zadaci.

Ovo su tri obrasca izvršavanja:

Sekvencijalni tijekovi rada: Agenti rade unaprijed određenim redoslijedom, pri čemu rezultat jednog agenta postaje ulaz za drugog.
Paralelno izvršavanje: Neovisni agenti rade istodobno.
Izvršavanje temeljeno na predaji: Kontrola prelazi između specijaliziranih agenata kako zadatak napreduje. To je korisno kada je drugi agent bolje opremljen za sljedeći korak, iako svaka predaja mora sačuvati informacije potrebne za nastavak.

Ti se obrasci međusobno ne isključuju i ne odgovaraju jedan na jedan arhitekturama orkestracije. Cilj je odabrati najjednostavniju strukturu koja podržava ovisnosti vašeg tijeka rada, zahtjeve koordinacije i prihvatljive operativne troškove.

Svašta može poći po zlu s orkestracijom, od jednostavnih propusta do složenih prepreka. Ponekad se čak može činiti da agent ispravno obavlja svoj posao, dok cjelokupni tijek rada ne uspijeva. Na temelju iskustava stručnjaka iz prakse prikupili smo neke od čestih pogrešaka koje stoje iza nepouzdanih orkestriranih tijekova rada — pripazite na njih:

Predaje između agenata uz gubitak informacija. Orkestrator prosljeđuje sažeti plan specijaliziranom agentu, ali u sažetku izostanu ograničenja, ovisnosti ili pojedinosti implementacije.
Preuranjeno objedinjavanje rezultata (fan-in). Nizvodni agent počinje objedinjavati rezultate prije nego što su svi uzvodni zadaci završeni.
Nedeterministička ažuriranja zajedničkog stanja. Paralelni agenti zapisuju u iste ključeve stanja bez jasno definirane semantike spajanja. Ovisno o tome kako okvir obrađuje ažuriranja, to može dovesti do izgubljenih zapisa, dupliciranih podataka, izlaza koji ovisi o redoslijedu ili sukobljenih promjena.
Razilaženje kontrolnih točaka i popratnih učinaka. Zadatak izvodi vanjsku operaciju, ali njezino uspješno izvršavanje nije trajno zabilježeno prije nego što radni proces zakaže. Pri oporavku orkestrator vidi nedovršen zadatak i ponovno ga pokreće.
Uvjeti utrke pri nastavku nakon ljudskog odobrenja. Pauziranje i nastavljanje izvršavanja donosi vlastite probleme sinkronizacije.
Petlje delegiranja i umnožavanje ponovnih pokušaja. Agenti jedni drugima opetovano prosljeđuju posao jer im se odgovornosti preklapaju, ovisnosti su kružne ili su uvjeti dovršetka nejasni.
Kontrole na razini uputa pogrešno shvaćene kao sigurnost izvršavanja. Orkestrator može agentima reći da ne pristupaju određenim resursima ili da ne izvode osjetljive radnje, ali upute modelu ne provode dopuštenja operacijskog sustava, mrežna ograničenja ni granice autorizacije. Istraživanje sigurnosnog inženjerstva tvrtke Perplexity ističe zašto agenti mogu prijeći sigurnosne granice dok teže legitimnim ciljevima, čak i bez zlonamjernih uputa

Primijetite koliko su te pogreške različite. Preuranjeni prijelaz u raspoređivaču ili dvosmisleni vanjski zapis mogu dovesti do pogrešnog ishoda, ali potječu iz različitih dijelova životnog ciklusa izvršavanja. Zato pouzdana orkestracija zahtijeva više od poboljšavanja upita ili dodavanja ponovnih pokušaja.

Nejasni ciljevi i nejasna definicija dovršenosti često dovode do razočaravajućih rezultata koje generiraju agenti. Rješenje je ugovor upita (opseg posla za agenta): dogovorite cilj, ograničenja, format izlaza i uvjete neuspjeha prije početka izvršavanja.

Na primjer, ovako biste mogli definirati ugovor za agenta zaduženog za popravak integracijskog testa koji povremeno ne prolazi:

Cilj: Pronaći i ukloniti uzrok nestabilnog integracijskog testa API-ja za naplatu.
Ulazi: Izvorni kod testa, zapisnici neuspjeha CI-ja, nedavni commitovi i relevantni kod aplikacije.
Ograničenja: Ne onemogućavati testove, ne ublažavati provjere niti mijenjati nepovezano ponašanje aplikacije.
Očekivani izlaz: Zakrpa koda, objašnjenje temeljnog uzroka i rezultati izvršavanja testova.
Kriteriji prihvaćanja: Test koji prethodno nije prolazio prolazi u 10 uzastopnih pokretanja, a prolazi i relevantni skup regresijskih testova.
Uvjeti neuspjeha: Temeljni uzrok ne može se utvrditi, popravak uvodi regresije ili potrebno testno okruženje nije dostupno.

No postoji još jedan važan dio: kada bi se agent trebao zaustaviti?

Agent ne bi trebao beskonačno ponavljati iteracije samo zato što nije dao zadovoljavajući rezultat. Definirajte što se smatra uspješnim dovršetkom, kada vratiti djelomično dovršen zadatak i kada se zaustaviti jer se neki zahtjev ne može ispuniti. Postavite najveću dubinu delegiranja i ograničenja iteracija ili proračune izvršavanja kako se neriješeni zadaci ne bi pretvorili u beskonačne petlje.

Vratimo se našem primjeru s CI-jem. Mogli biste definirati sljedeće uvjete zaustavljanja:

Uspjeh: Popravak prolazi 10 uzastopnih pokretanja testa i relevantni skup regresijskih testova.
Ograničenje iteracija: Agent može isprobati najviše dva moguća popravka.
Proračun izvršavanja: Agent se mora zaustaviti nakon 60 minuta, čak i ako problem ostane neriješen.
Ograničenje delegiranja: Agent može delegirati posao jednom specijaliziranom agentu, bez daljnjeg delegiranja podagentima.
Djelomični dovršetak: Ako oba pokušaja ne uspiju ili istekne vremensko ograničenje, agent vraća svoje nalaze, pokušane promjene i rezultate testova.
Blokirano izvršavanje: Ako testno okruženje nije dostupno, agent se zaustavlja i prijavljuje prepreku umjesto da tvrdi da je uspio.

Ponekad razvojni programeri orkestratoru dodijele previše odgovornosti, pa umjesto da koordinira specijalizirane agente, sam počne pisati kod, otklanjati pogreške ili provoditi detaljne preglede. To stvara usko grlo: orkestrator troši svoj proračun konteksta na pojedinosti implementacije, odgađa delegiranje i zamagljuje odgovornost za rezultate.

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

Razmotrite ovaj primjer: status: completed odnosi se na posao dodijeljen agentu, a ne na cijeli tijek rada. Budući da su testovi još u statusu pending, orkestrator ne bi trebao odobriti konačni rezultat.

json

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

Povijest razgovora agenta nije pouzdan zapis napretka tijeka rada. Kada se njegov kontekstni prozor popuni, automatsko sažimanje može izostaviti važne pojedinosti. A ako radni proces padne, sljedeći agent mora znati koji su koraci zaista dovršeni.

Na primjer, ako agent za kodiranje generira zakrpu, a zatim padne, sljedeći radni proces trebao bi dohvatiti spremljeni artefakt i nastaviti od zabilježenog stanja tijeka rada. No ako je agent pokrenuo i vanjsko CI pokretanje, orkestrator mora zasebno uskladiti to pokretanje prije ponavljanja radnje

Zato držite stanje izvršavanja odvojeno od radnog konteksta agenta. Statuse zadataka, pokušaje izvršavanja, dovršene korake i reference na artefakte spremajte u trajnu pohranu. Istodobno učitavajte samo upute, ulaze i rezultate relevantne za trenutačni zadatak agenta, umjesto da u njegov kontekstni prozor trpate cijelu povijest izvršavanja.

Recimo da vaš CI agent pokrene testiranje, ali za API zahtjev istekne vrijeme. Je li se testiranje uopće uspjelo pokrenuti ili ga je CI usluga stavila u red čekanja i izgubila odgovor?

Istek vremena ne znači nužno da operacija nije uspjela. Zato morate razlikovati pogreške prije nego što odlučite što slijedi:

Prolazne pogreške (429, 503): Ponovite pokušaj s ograničenim eksponencijalnim odgađanjem i nasumičnim odstupanjem (jitter), poštujući Retry-After kada je naveden.
Pogreške provjere valjanosti ili dopuštenja (400, 403): Zaustavite se ili ispravite temeljni problem umjesto ponavljanja istog zahtjeva.
Dvosmisleni ishodi (istek vremena nakon mogućeg zapisa): Provjerite je li operacija uspjela prije nego što je ponovno pokušate.

Napomena: Čak i pogreške koje dopuštaju ponovni pokušaj zahtijevaju ograničenja. Postavite vremensko ograničenje za svaki poziv alata, ograničite broj ponovnih pokušaja i njihovo ukupno trajanje te provedite ukupni rok za tijek rada kako ugniježđeni agenti ne bi mogli stalno iznova pokretati istu operaciju. Ako neka ovisnost opetovano zakazuje, upotrijebite prekidač strujnog kruga (circuit breaker) kako biste privremeno zaustavili zahtjeve.

Za operacije s vanjskim popratnim učincima svakoj logičkoj radnji dodijelite stabilan ključ idempotentnosti i ponovno ga upotrebljavajte u svim ponovnim pokušajima. Ako API podržava deduplikaciju na strani poslužitelja, može prepoznati ponovljene zahtjeve bez dvostrukog izvođenja radnje. Ako ne podržava, pošaljite upit vanjskom sustavu pomoću korelacijskog ID-a ili druge mjerodavne reference.

Kada ne možete utvrditi što se dogodilo, zaustavite se i eskalirajte.

Primjer 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: Primjer pretpostavlja da CI API podržava traženje pokretanja prema ID-u zahtjeva. Vrijednost request_id sprječava duplikate samo ako pružatelj izričito jamči idempotentnost. bounded_retry() ilustrativni je pseudokod. U produkciji ponovni pokušaji trebaju biti ograničeni i proračunom ponovnih pokušaja po operaciji (najvećim brojem pokušaja ili proteklim vremenom) i ukupnim rokom tijeka rada.

Za dulje tijekove rada koji obuhvaćaju više usluga razmotrite obrazac Saga za koordinaciju kompenzacijskih radnji kada kasniji koraci ne uspiju. Samo imajte na umu da kompenzacija nije uvijek potpuno vraćanje na prethodno stanje. Ažuriranje baze podataka možete poništiti, ali poslanu e-poruku ne možete vratiti.

Ovdje treba uravnotežiti dvije stvari: koliko mogućnosti modela svaki zadatak treba i koliko zadataka možete izvoditi istodobno. Ako pogriješite u bilo čemu od toga, riskirate da se agenti natječu za zajedničke API kvote ili da se oslanjate isključivo na skupe modele za rasuđivanje.

Kod odabira modela uskladite mogućnosti modela i razinu rasuđivanja sa složenošću zadatka — jednostavno, ali često zanemareno. Imajte na umu da možete sami konfigurirati pravila usmjeravanja i procjenjivati modele ili upotrijebiti platformu za orkestraciju koja odabir modela obavlja umjesto vas.

Na primjer, način rada Effort Mode u usluzi Perplexity Computer omogućuje vam da odaberete koliko truda zadatak zaslužuje bez ručnog odabira modela. Odaberite Light, Standard, High ili Ultra i Perplexity automatski odabire model koji orkestrira i njegovu razinu rasuđivanja. Taj orkestrator zatim delegira podzadatke pomoćnim agentima, koji mogu koristiti modele različitih pružatelja.

Perplexity procjenjuje konfiguracije modela s obzirom na kvalitetu i trošak te daje prednost jeftinijim opcijama koje daju usporedive rezultate. Možete upotrijebiti i prilagođene kontrole (Custom) ako radije sami birate model i razinu rasuđivanja.

Kod paralelizma ograničenje bi trebalo proizlaziti iz vaše infrastrukture i vanjskih ovisnosti. Provjerite ograničenja broja zahtjeva i tokena zajedničkih API-ja, a zatim provedite testiranje opterećenja tijeka rada uz sve veću istodobnost. Pratite poboljšava li se propusnost ili se zahtjevi počinju gomilati u redu čekanja, usporavati ili vraćati pogreške 429.

Kako bi potrošnja resursa ostala predvidljiva, provodite ograničenja resursa i kontrole raspoređivanja:

Kontrolirajte istodobnost i učestalost zahtjeva: Ograničite broj aktivnih poziva po usluzi, a višak posla stavite u red čekanja. Imajte na umu da samo ograničenje istodobnosti neće provesti ograničenja broja zahtjeva ili tokena u minuti.
Pratite proračune tokena i troškova: Uzmite u obzir potrošnju u cijelom tijeku rada, uključujući podagente, i prestanite pokretati novi posao kada preostali proračun nije dovoljan.
Provodite rokove izvršavanja: Postavite vremenska ograničenja za zadatke i tijek rada te, gdje je to podržano, proslijedite otkazivanje agentima koji se izvode.
Poštujte ovisnosti: Pokrećite nizvodne zadatke tek kada su dostupni ulazi koji su im potrebni, umjesto da sve agente pokrenete istodobno.

Nikada ne tražite od modela da sam odluči jesu li njegove radnje sigurne. Umjesto toga, dodijelite agentima dopuštenja prema načelu najmanjih ovlasti i provodite pravila odobravanja temeljena na riziku u kodu aplikacije. Ako agenti izvršavaju kod, izolirajte to izvršavanje od okruženja domaćina i ograničite pristup datotekama, mrežama i vjerodajnicama. Time se ograničava šteta ako agent pogriješi ili izvrši nesiguran kod.

„Skeptičan sam prema pretjerano složenim višeagentnim sustavima, osobito kada agenti međusobno pregledavaju i odobravaju rad. Može se dogoditi da nekoliko agenata samouvjereno prosljeđuje istu pogrešku, a da je nitko zapravo ne uoči“, upozorava Spilker.

Dijagram tijeka odobravanja: agent predlaže operaciju s parametrima, ciljnim resursom i verzijom stanja; čovjek je odobrava ili odbija; odobrene operacije ponovno se provjeravaju i izvode u izoliranom okruženju s ograničenim pristupom datotekama, mreži i vjerodajnicama. Odbijeni zahtjevi i zahtjevi kojima je istekao rok zatvaraju se, a promijenjeni zahtjevi trebaju novo odobrenje.

Za radnje koje zahtijevaju ljudsko odobrenje pauzirajte izvršavanje i spremite točnu predloženu operaciju:

njezine parametre
njezin ciljni resurs
njezin commit ili verziju stanja
odluku recenzenta

Također definirajte što se događa ako je odobrenje odbijeno, ako istekne ili zahtijeva eskalaciju. To je ključno za okvire koji podržavaju nastavak izvršavanja jer se nastavkom prekinutog čvora kod ponovno izvršava od početka tog čvora. Svi popratni učinci prije prekida mogli bi se ponovno izvesti.

Dakle, ako je odobrenje odbijeno ili istekne, zahtjev se zatvara. Ako se ciljni commit, parametri ili dopuštenja promijene prije izvršavanja, poništite odobrenje i zatražite novo.

Spilker također ne podržava ideju da bi cilj trebali biti potpuno autonomni, cjeloviti (end-to-end) agenti. „Za mene je bolji pristup izgraditi nekoliko fokusiranih agenata s jasnim odgovornostima, definiranim dopuštenjima i ljudskim pregledom u pravim trenucima. I dalje postižete učinkovitost, a da se ne odričete potpune kontrole“, zaključuje.

Je li vam se ikad dogodilo da agent prijavi Success, a zapravo nije uspio? Iritantno, ako ne i izluđujuće, a popravak nije brz jer vam završna poruka agenta neće nužno reći gdje je nešto pošlo po zlu.

Da biste to istražili, pratite što se dogodilo tijekom izvršavanja i neovisno provjerite rezultate. Zato odvojimo malo vremena za izoliranje i rješavanje problema.

Prije otklanjanja pogrešaka u upitima agenta zabilježite cijeli put izvršavanja. Potreban vam je trag (trace) koji povezuje pozive agenata, pozive alata, pogreške i ponovne pokušaje unutar istog pokretanja tijeka rada.

Semantičke konvencije za GenAI projekta OpenTelemetry pružaju standardizirani način opisivanja tih operacija. Na primjer, invoke_workflow označava izvršavanje tijeka rada, invoke_agent poziv agenta, a execute_tool poziv alata. Svaka se operacija može zabilježiti kao span s vremenom, statusom i relevantnim metapodacima.

Ovaj vam korak daje trag puta izvršavanja kako biste mogli utvrditi gdje 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.

Gdje god je moguće, koristite programske provjere. Provjeravajte izlaze prema JSON shemama, pokrećite jedinične i integracijske testove, provjerite postoje li potrebni artefakti i šaljite upite vanjskim sustavima kako biste potvrdili da su radnje zaista uspjele.

Za izlaze koji zahtijevaju subjektivnu prosudbu — pa ih programske provjere ne mogu obuhvatiti — uvedite neovisnog agenta recenzenta. Jedan je pristup petlja implementator–recenzent–rješavatelj, u kojoj jedan agent izrađuje artefakt, recenzent sa svježim kontekstom utvrđuje probleme, a rješavatelj ih otklanja prije nego što se provjera ponovno pokrene.

I dalje morate provjeravati nalaze recenzenta gdje je to moguće, a ako za opetovane evaluacije koristite ocjenjivače temeljene na LLM-ovima, kalibrirajte njihove prosudbe prema primjerima koje su pregledali ljudi.

Dosad ste pratili što su agenti izvršili i provjeravali jesu li njihovi rezultati bili točni. No što se događa kada se radni proces sruši usred zadatka ili kada API-ju istekne vrijeme čekanja nakon što je prihvatio zahtjev? Iznenađujuće, vaš tijek rada može savršeno funkcionirati u normalnim uvjetima, ali zakazati tijekom oporavka.

Da biste to testirali, namjerno ubacite pogreške u testnom okruženju:

Simulirajte istek vremena čekanja API-ja
Srušite radne procese između vanjskih zapisivanja i kontrolnih točaka
Vratite neispravno oblikovane izlaze alata
Neka odobrenja isteknu

Nakon svakog testa pregledajte trag izvršavanja kako biste vidjeli koji su se koraci izvršili, gdje je tijek rada nastavljen te jesu li neke radnje ponovljene ili preskočene. Zatim pregledajte stvarne rezultate.

Recimo da vaš CI agent pošalje zahtjev za pokretanje testnog izvođenja, ali odgovoru API-ja istekne vrijeme čekanja. Agent pokuša ponovno, primi uspješan odgovor i prijavi Uspjeh. Sve izgleda u redu dok ne provjerite CI uslugu i otkrijete da su stvorena dva testna izvođenja umjesto jednog.

Zato biste trebali provjeriti i zabilježeno stanje tijeka rada i stvarne promjene u vanjskim sustavima. Test oporavka trebao bi proći samo kada tijek rada dosegne očekivano stanje bez neželjenih nuspojava.

Pogreške koje otkrijete dodajte u regresijske testove kako ih buduće promjene ne bi ponovno uvele.

U konačnici, uspjeh znači da je tijek rada prošao potrebne provjere i da su njegovi vanjski ishodi potvrđeni.

Izolirani agenti mogu ispravno izvršiti svoje pojedinačne zadatke, ali zajedno davati nedosljedne rezultate. Zamislite prodajnog agenta koji u 10:00 dohvaća uvjete za kupca, agenta za cijene koji u 10:05 izračunava ponudu na temelju ažuriranih cijena i pravnog agenta koji provjerava ugovor koji se promijenio u 10:07. Svaki agent radi s drukčijom snimkom stanja poslovanja, pa si njihovi rezultati mogu međusobno proturječiti.

Problem postaje izraženiji na razini velikih poduzeća jer agenti komuniciraju s više sustava koji se ažuriraju neovisno, rade s različitim dopuštenjima i ne dijele nužno kontekst ni stanje izvršavanja.

Postavite ograničenja na više razina: najveći broj ponovnih pokušaja poziva alata, najveći broj iteracija agenta, dubinu delegiranja i ukupni rok za tijek rada. Prije ponovnog pokušaja klasificirajte pogreške. Za privremene odgovore 429 poštujte Retry-After ako je naveden. U suprotnom upotrijebite ograničeno eksponencijalno odgađanje sa slučajnim odstupanjem (jitter).

Prestanite ponavljati nepromijenjene zahtjeve nakon pogrešaka validacije ili dopuštenja. Ako nizvodna usluga opetovano zakazuje, prekidač kruga (circuit breaker) može spriječiti da agenti stvaraju dodatno opterećenje.

Mehanizam oporavka ovisi o vašem okruženju za izvođenje. U LangGraphu trajni mehanizam za kontrolne točke (checkpointer) kao što je PostgresSaver pohranjuje stanje grafa pod thread_id, što omogućuje nastavak izvršavanja iz pohranjenog stanja. U Temporalu drugi radni proces može rekonstruirati tijek rada ponovnom reprodukcijom njegove povijesti događaja. Tijekom reprodukcije ponovno upotrebljava prethodno zabilježene rezultate aktivnosti.

Ako se aplikacija ponovno implementira dok se tijekovi rada još izvode, spremljeno stanje i povijesti izvršavanja možda više neće biti kompatibilni. Temporal to rješava pomoću značajke Worker Versioning i zakrpa tijeka rada (workflow patching). Za sustave temeljene na kontrolnim točkama planirajte migracije sheme i testirajte oporavak na postojećim spremljenim stanjima prije uvođenja nekompatibilnih promjena.

Pokrenite iste reprezentativne zadatke više puta i razlikujte pass@k (uspijeva li barem jedan od k pokušaja) od pass^k (uspijevaju li svi k pokušaji)

Mjerite rezultate prema kategoriji zadatka i verziji tijeka rada umjesto da se oslanjate na jednu ukupnu stopu uspješnosti. Pratite uspješnost iz prvog pokušaja, dosljednost u ponovljenim izvođenjima, latenciju p95, trošak po dovršenom zadatku i udio zadataka koji zahtijevaju ljudsku intervenciju. Navedite veličine uzoraka i intervale nesigurnosti za stope uspješnosti.

Što je orkestracija AI agenata?

Kako funkcionira orkestracija AI agenata: unutar izvršnog mehanizma

Kada biste trebali koristiti orkestraciju AI agenata?

Arhitekture orkestracije AI agenata i njihovi kompromisi

Centralizirana orkestracija

Decentralizirana orkestracija

Hijerarhijska orkestracija

Sekvencijalno izvršavanje, paralelno izvršavanje i izvršavanje temeljeno na predaji

Česte pogreške u orkestraciji AI agenata

7 najboljih praksi orkestracije AI agenata za pouzdanost u produkciji

1. Definirajte eksplicitne ugovore zadataka, kriterije prihvaćanja i uvjete zaustavljanja

2. Rasteretite orkestratore i provodite strukturirane predaje

3. Trajno pohranjujte stanje tijeka rada i kontrolirajte rast konteksta

4. Osmislite ponovne pokušaje svjesne kvarova i izvršavanje alata koje omogućuje oporavak

5. Usmjeravajte i paralelizirajte rad uz eksplicitne proračune resursa

6. Provodite odobrenja i izolirajte izvršavanje agenata

7. Neovisno provjeravajte izlaze i testirajte ponašanje pri oporavku

Pratite tijek rada kako biste utvrdili što je pošlo po zlu

Neovisno pregledajte izlaz

Ubacite kvarove kako biste testirali oporavak

Česta pitanja o orkestraciji AI agenata

Zašto izolirani AI agenti zakazuju na razini velikih poduzeća?

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

Kako nastaviti tijek rada AI agenta nakon rušenja?

Kako testirati pouzdanost orkestracije AI agenata?