Osvedčené postupy orchestrácie agentov AI: riešenie zlyhaní, schválení a opakovaných pokusov

Viacero agentov pracujúcich na tom istom projekte znie mimoriadne efektívne. Jeden plánuje prácu, ďalší rieši dizajn a tretí píše kód. Funguje to, kým to nefunguje. A zlyhania sa stávajú častejšie, než by ste chceli.

Predchádzanie týmto zlyhaniam si vyžaduje starostlivý návrh pracovných postupov. Pozrime sa preto, čo robí orchestrované pracovné postupy nespoľahlivými, a preskúmajme osvedčené postupy orchestrácie pre spoľahlivosť v produkčnom prostredí.

Čo je orchestrácia AI agentov?

Orchestrácia AI agentov koordinuje viacerých AI agentov, modely a nástroje pri plnení viackrokovej úlohy. Niekto – alebo niečo – však stále musí rozhodnúť, ktorý agent sa spustí ako prvý, aké informácie dostane a čo sa stane po jeho dokončení. To je úloha orchestrátora – AI agenta v úlohe manažéra alebo softvérovo riadenej vykonávacej vrstvy.

Zjednodušene povedané, orchestračná vrstva rozdelí cieľ na menšie úlohy, sleduje závislosti, deleguje vykonanie na správnych agentov, spravuje zdieľaný kontext a spája výstupy.

Ako funguje orchestrácia AI agentov: pohľad do vykonávacieho mechanizmu

Zväčšiť

Pozrime sa, čo sa stane, keď orchestrátoru zadáte úlohu.

Vezmime si príklad z workshopu Perplexity o službe Computer: vytvorenie dashboardu s prehľadom o zákazníckych účtoch na základe informácií zo Salesforce, Snowflake, e-mailu, kalendára a aktuálnych správ.

1. Pochopte cieľ a naplánujte prácu. Orchestrátor začína požadovaným výsledkom a rozkladá ho na úlohy s explicitnými závislosťami. V našom príklade s dashboardom to znamená zhromaždiť informácie z rôznych zdrojov a premeniť ich na hotový výstup. Plánovač určí, ktoré kroky závisia od iných a ktoré môžu bežať nezávisle.
2. Smerujte úlohy k vhodným agentom. Orchestrátor identifikuje úlohy, ktorých závislosti sú splnené, a deleguje prácu na špecializovaných agentov alebo modely. Závislé úlohy čakajú na svoje predpoklady. Perplexity Computer využíva viacero špičkových modelov a smeruje rôzne časti pracovného postupu do systémov vhodných na dané úlohy. Vďaka tomu môže nezávislá práca bežať paralelne.
3. Vykonávajte volania nástrojov v kontrolovaných prostrediach. Agenti interagujú so svojím prostredím prostredníctvom nástrojov, ako je webové vyhľadávanie, API, pripojené aplikácie, operácie so súbormi alebo vykonávanie kódu. Vykonávacia vrstva tieto akcie spúšťa a vracia výsledky agentom.
4. Odovzdávajte výsledky a kontext medzi agentmi. Keď agent dokončí svoju úlohu, ďalší agent v poradí potrebuje relevantný výstup, aby mohol pokračovať. Záznam o odovzdaní môže obsahovať ID úlohy, odkaz na výstup, verziu schémy a metadáta o zdroji. Orchestrátor koordinuje tieto odovzdania a zároveň udržiava kontext potrebný pre ďalšie kroky. Dôležité je, že agenti nemusia vo svojich kontextových oknách niesť celú históriu práce všetkých ostatných agentov.
5. Zaznamenávajte stav vykonávania oddelene od kontextu agentov. Keď agenti úlohy začínajú, dokončujú alebo v nich zlyhávajú, vykonávací mechanizmus aktualizuje trvalý záznam pracovného postupu so stavmi úloh, pokusmi o vykonanie, odkazmi na výstupy a zostávajúcou prácou. Vďaka tomuto záznamu môže orchestrátor sledovať priebeh a po prerušení pokračovať bez toho, aby sa pri rekonštrukcii pracovného postupu z histórie konverzácie spoliehal na LLM.
6. Overte výsledky a rozhodnite, čo nasleduje. Keď sa úloha vráti, orchestračná vrstva skontroluje, či jej výstup spĺňa očakávaný kontrakt a či sú splnené závislosti ďalšej úlohy. Ak sa nájde problém, pracovný postup sa môže vrátiť k skoršiemu kroku na opravu alebo sa pozastaviť. V opačnom prípade pokračuje k dokončeniu.

Za zdanlivo jednoduchou orchestráciou AI agentov sa skrýva množstvo pohyblivých častí. Spôsob, akým zorganizujete koordináciu agentov, určuje, akú kontrolu máte nad vykonávaním. A samozrejme, všetka táto koordinácia pridáva réžiu. Preto sa nie vždy oplatí.

Kedy použiť orchestráciu AI agentov?

Orchestráciu viacerých agentov zvážte vtedy, keď rôzne časti úlohy vyžadujú odlišnú odbornosť, nezávislá práca môže bežať paralelne alebo nedokážete vopred určiť ďalší krok.

Orchestrácia je teda užitočná v troch situáciách:

• Úlohy si vyžadujú rôzne špecializácie. Programátorskému projektu môžu napríklad prospieť samostatní agenti na plánovanie, dizajn, vývoj a kontrolu.
• Nezávislé úlohy môžu bežať paralelne. Namiesto toho, aby jeden agent dokončil všetko postupne, môže viacero agentov pracovať súčasne a vrátiť svoje výsledky orchestrátoru.
• Problém je otvorený. Agenti môžu potrebovať skúmať rôzne prístupy, rozhodovať sa a spolupracovať namiesto toho, aby sledovali vopred definovanú postupnosť.

Inak je orchestrácia len nákladný trend. Viac agentov tiež znamená viac koordinácie a potenciálne vyššie náklady na tokeny.

„Zvyčajne začínam najjednoduchšou možnosťou a od nej staviam ďalej. Ak poznáme kroky a sú opakovateľné, je to pravdepodobne pracovný postup. Dôvod zaviesť viacerých agentov vidím len vtedy, keď majú rôzne zodpovednosti, oprávnenia alebo používateľov,“ hovorí Josh Spilker, vedúci marketingu vo vyhľadávaní v spoločnosti AirOps.

Aj vtedy však zvážte prínosy oproti ďalším volaniam modelov, odovzdaniam, latencii a bodom zlyhania.

Architektúry orchestrácie AI agentov a ich kompromisy

Existujú tri bežné spôsoby, ako štruktúrovať koordináciu agentov – centralizovaná, decentralizovaná a hierarchická orchestrácia. Výber správnej architektúry sa zužuje na jednu otázku: Kto riadi prácu a ako sa agenti medzi sebou koordinujú?

Centralizovaná orchestrácia

Pri centralizovanej orchestrácii riadi proces jeden orchestrátor. Rozloží úlohu, deleguje prácu na špecializovaných agentov, sleduje ich priebeh a spája ich výsledky.

Zväčšiť

Kompromis: Centralizovaná koordinácia uľahčuje sledovanie vykonávania a uplatňovanie spoločných pravidiel v jednom riadiacom bode. Orchestrátor sa však môže stať úzkym hrdlom a jeho zlyhanie môže prerušiť celý pracovný postup, pokiaľ systém nepodporuje obnovu.

Decentralizovaná orchestrácia

Pri decentralizovanej orchestrácii sa agenti koordinujú priamejšie, namiesto toho, aby sa spoliehali na jedného manažéra, ktorý robí každé rozhodnutie. Môžu si vymieňať správy, čítať zdieľaný stav a samostatne určovať svoje ďalšie kroky.

Zväčšiť

Kompromis: Agenti môžu pracovať bez čakania na centrálneho plánovača, vďaka čomu je tento prístup užitočný pri prieskumnej práci a nezávislých príspevkoch. Koordinácia sa však sťažuje, keď sa agenti nezhodnú, aktualizujú zdieľané informácie alebo potrebujú dospieť ku konzistentnému výsledku.

Hierarchická orchestrácia

Hierarchická orchestrácia rozširuje manažérsky prístup na viacero úrovní. Orchestrátor najvyššej úrovne deleguje zodpovednosť na podriadené orchestrátory, ktoré koordinujú vlastné skupiny špecializovaných agentov.

Predstavte si podnikový pracovný postup, do ktorého sú zapojené obchodné, finančné a právne tímy. Orchestrátor najvyššej úrovne by mohol delegovať každý pracovný prúd na koordinátora pre danú oblasť. Títo koordinátori by potom riadili vlastných špecializovaných agentov a podávali by súhrnné výsledky.

Táto štruktúra môže pomôcť, keď sú pracovné postupy príliš rozsiahle na to, aby ich jeden orchestrátor efektívne riadil.

Zväčšiť

Kompromis: Hierarchie umožňujú tímom rozdeliť si koordinačné zodpovednosti a prípadne riešiť zlyhania v rámci jednotlivých vetiev. Prinášajú však ďalšie odovzdania, zložitejšiu správu stavu a vyššiu prevádzkovú réžiu. Lokálna obnova navyše závisí od toho, ako sú implementované kontrolné body a stav vykonávania.

Porovnanie týchto architektúr:

Sekvenčné, paralelné a na odovzdávaní založené vykonávanie

Je tu ešte jeden rozdiel, ktorý stojí za to pochopiť. Architektúra určuje, kto koordinuje agentov. Vzor vykonávania určuje, ako postupujú ich úlohy.

Toto sú tri vzory vykonávania:

• Sekvenčné pracovné postupy: Agenti pracujú vo vopred definovanom poradí a výsledok jedného agenta sa stáva vstupom pre ďalšieho.
• Paralelné vykonávanie: Nezávislí agenti pracujú súčasne.
• Vykonávanie založené na odovzdávaní: Riadenie sa s postupom úlohy presúva medzi špecializovanými agentmi. Je to užitočné, keď je na zvládnutie ďalšieho kroku lepšie vybavený iný agent, hoci každé odovzdanie musí zachovať informácie potrebné na pokračovanie.

Tieto vzory sa navzájom nevylučujú a nezodpovedajú architektúram orchestrácie v pomere jedna k jednej. Cieľom je zvoliť najjednoduchšiu štruktúru, ktorá zvládne závislosti vášho pracovného postupu, požiadavky na koordináciu a prijateľnú prevádzkovú réžiu.

Bežné zlyhania pri orchestrácii agentov AI

Pri orchestrácii sa môže pokaziť čokoľvek – od jednoduchých prehliadnutí až po zložité prekážky. Niekedy sa dokonca môže zdať, že agent svoju prácu robí správne, zatiaľ čo celý pracovný postup zlyháva. Na základe skúseností odborníkov z praxe sme zostavili niekoľko bežných chýb, ktoré stoja za nespoľahlivými orchestrovanými pracovnými postupmi – dávajte si na ne pozor:

• Stratové odovzdávanie medzi agentmi. Orchestrátor odovzdá špecializovanému agentovi zhrnutý plán, ale zo zhrnutia vypadnú obmedzenia, závislosti alebo podrobnosti implementácie.
• Predčasné zlučovanie výsledkov (fan-in). Nadväzujúci agent začne agregovať výsledky skôr, ako sa dokončia všetky predchádzajúce úlohy.
• Nedeterministické aktualizácie zdieľaného stavu. Paralelní agenti zapisujú do rovnakých kľúčov stavu bez jasne definovanej sémantiky zlučovania. V závislosti od toho, ako framework spracúva aktualizácie, to môže viesť k strateným zápisom, duplicitným údajom, výstupu závislému od poradia alebo konfliktným zmenám.
• Rozchod kontrolných bodov a vedľajších účinkov. Úloha vykoná externú operáciu, no jej úspešné vykonanie sa trvalo nezaznamená skôr, ako pracovný proces zlyhá. Pri obnove orchestrátor vidí nedokončenú úlohu a spustí ju znova.
• Súbehy pri obnovení po ľudskom schválení. Pozastavenie a obnovenie vykonávania prináša vlastné problémy so synchronizáciou.
• Slučky delegovania a znásobovanie opakovaných pokusov. Agenti si opakovane odovzdávajú prácu, pretože sa ich zodpovednosti prekrývajú, závislosti sú cyklické alebo podmienky dokončenia sú nejednoznačné.
• Kontroly na úrovni pokynov mylne považované za bezpečnosť vykonávania. Orchestrátor môže agentom prikázať, aby nepristupovali k určitým prostriedkom alebo nevykonávali citlivé akcie, ale pokyny pre model nevynucujú oprávnenia operačného systému, sieťové obmedzenia ani hranice autorizácie. Výskum v oblasti bezpečnostného inžinierstva spoločnosti Perplexity ukazuje, prečo môžu agenti prekračovať bezpečnostné hranice pri sledovaní legitímnych cieľov, a to aj bez škodlivých pokynov

Všimnite si, aké odlišné sú tieto zlyhania. Predčasný prechod plánovača aj nejednoznačný externý zápis môžu viesť k nesprávnemu výsledku, no vznikajú v rôznych častiach životného cyklu vykonávania. Preto spoľahlivá orchestrácia vyžaduje viac než len vylepšovanie promptov alebo pridávanie opakovaných pokusov.

7 osvedčených postupov orchestrácie agentov AI pre spoľahlivosť v produkcii

1. Definujte explicitné zmluvy úloh, kritériá prijatia a podmienky zastavenia

Vágne ciele a nejasná definícia dokončenia (definition of done) často vedú k neuspokojivým výsledkom generovaným agentmi. Riešením je zmluva promptu (rozsah práce pre agenta): dohodnite sa na cieli, obmedzeniach, formáte výstupu a podmienkach zlyhania ešte pred začiatkom vykonávania.

Takto by ste napríklad mohli definovať zmluvu pre agenta zodpovedného za opravu občas zlyhávajúceho integračného testu:

• Cieľ: Identifikovať a odstrániť príčinu nestabilného integračného testu API pokladne.
• Vstupy: Zdrojový kód testu, protokoly zlyhaní CI, nedávne commity a príslušný kód aplikácie.
• Obmedzenia: Nevypínať testy, nezmierňovať asercie ani nemeniť nesúvisiace správanie aplikácie.
• Očakávaný výstup: Oprava kódu (patch), vysvetlenie hlavnej príčiny a výsledky spustenia testov.
• Kritériá prijatia: Predtým zlyhávajúci test prejde v 10 po sebe nasledujúcich behoch a príslušná sada regresných testov prejde.
• Podmienky zlyhania: Hlavnú príčinu nemožno určiť, oprava spôsobí regresie alebo požadované testovacie prostredie nie je dostupné.

Je tu však ešte jedna dôležitá časť: kedy by sa mal agent zastaviť?

Agent by nemal pokračovať v iteráciách donekonečna len preto, že nedosiahol uspokojivý výsledok. Definujte, čo predstavuje úspešné dokončenie, kedy vrátiť čiastočne dokončenú úlohu a kedy sa zastaviť, pretože požiadavku nemožno splniť. Nastavte maximálnu hĺbku delegovania a limity iterácií alebo rozpočty na vykonávanie, aby sa z nevyriešených úloh nestali nekonečné slučky.

Späť k nášmu príkladu s CI. Môžete definovať tieto podmienky zastavenia:

• Úspech: Oprava prejde v 10 po sebe nasledujúcich behoch testov aj v príslušnej sade regresných testov.
• Limit iterácií: Agent môže vyskúšať najviac dve kandidátske opravy.
• Rozpočet na vykonávanie: Agent sa musí zastaviť po 60 minútach, aj keď problém zostane nevyriešený.
• Limit delegovania: Agent môže delegovať prácu na jedného špecializovaného agenta bez ďalšieho delegovania na podagentov.
• Čiastočné dokončenie: Ak oba pokusy zlyhajú alebo uplynie časový limit, agent vráti svoje zistenia, vyskúšané zmeny a výsledky testov.
• Zablokované vykonávanie: Ak testovacie prostredie nie je dostupné, agent sa zastaví a nahlási prekážku namiesto toho, aby tvrdil, že uspel.

2. Udržujte orchestrátory štíhle a vynucujte štruktúrované odovzdávanie

Vývojári niekedy dajú orchestrátoru priveľa zodpovedností a namiesto koordinácie špecializovaných agentov začne sám písať kód, ladiť alebo vykonávať podrobné kontroly. Vzniká tak úzke hrdlo: orchestrátor míňa svoj rozpočet kontextu na podrobnosti implementácie, odďaľuje delegovanie a stiera zodpovednosť za výsledky.

Nechajte teda orchestrátory robiť ich prácu a vynucujte odovzdávanie s odkazmi na konkrétne artefakty: pôvodnú úlohu, relevantné vstupy, výstupné artefakty, stav vykonávania a všetky nevyriešené problémy.

Zoberme si tento príklad: status: completed sa vzťahuje na prácu pridelenú agentovi, nie na celý pracovný postup. Keďže testy sú stále v stave pending, orchestrátor by nemal schváliť konečný výsledok.

3. Uchovávajte stav pracovného postupu a kontrolujte rast kontextu

História konverzácie agenta nie je spoľahlivým záznamom o priebehu pracovného postupu. Keď sa jeho kontextové okno zaplní, automatické zhustenie môže vynechať dôležité podrobnosti. A ak pracovný proces spadne, ďalší agent musí vedieť, ktoré kroky boli skutočne dokončené.

Ak napríklad agent na programovanie vygeneruje opravu (patch) a potom spadne, ďalší pracovný proces by mal načítať uložený artefakt a pokračovať od zaznamenaného stavu pracovného postupu. Ak však agent spustil aj externý beh CI, orchestrátor musí tento beh samostatne zosúladiť skôr, ako akciu zopakuje

Stav vykonávania preto uchovávajte oddelene od pracovného kontextu agenta. Stavy úloh, pokusy o vykonanie, dokončené kroky a odkazy na artefakty ukladajte do trvalého úložiska. Zároveň načítavajte iba pokyny, vstupy a výsledky relevantné pre aktuálnu úlohu agenta, namiesto toho, aby ste do jeho kontextového okna napchali celú históriu vykonávania.

4. Navrhujte opakované pokusy s ohľadom na zlyhania a obnoviteľné vykonávanie nástrojov

Povedzme, že váš agent CI spustí beh testov, ale požiadavke na API vyprší časový limit. Nepodarilo sa beh testov spustiť, alebo ho služba CI zaradila do frontu a stratila odpoveď?

Vypršanie časového limitu nemusí nutne znamenať, že operácia zlyhala. Preto musíte pred rozhodnutím o ďalšom postupe rozlišovať medzi chybami:

• Prechodné chyby (429, 503): Opakujte pokus s ohraničeným exponenciálnym odstupom (backoff) a náhodným rozptylom (jitter) a rešpektujte hlavičku Retry-After, ak je uvedená.
• Chyby overenia alebo oprávnení (400, 403): Zastavte sa alebo opravte základný problém namiesto opakovania tej istej požiadavky.
• Nejednoznačné výsledky (vypršanie časového limitu po možnom zápise): Pred ďalším pokusom overte, či operácia uspela.

Poznámka: Aj chyby, pri ktorých možno pokus zopakovať, potrebujú limity. Nastavte časový limit pre každé volanie nástroja, obmedzte počet opakovaných pokusov aj celkový čas opakovania a vynucujte celkový termín pracovného postupu, aby vnorení agenti nemohli tú istú operáciu donekonečna reštartovať. Ak závislosť opakovane zlyháva, použite istič (circuit breaker) na dočasné zastavenie požiadaviek.

Pri operáciách s externými vedľajšími účinkami priraďte každej logickej akcii stabilný kľúč idempotencie a opakovane ho používajte pri všetkých opakovaných pokusoch. Ak API podporuje deduplikáciu na strane servera, dokáže rozpoznať opakované požiadavky bez toho, aby akciu vykonalo dvakrát. Ak ju nepodporuje, vyhľadajte stav v externom systéme pomocou ID korelácie alebo inej autoritatívnej referencie.

Keď nedokážete zistiť, čo sa stalo, zastavte sa a eskalujte problém.

Príklad logiky opakovaných pokusov pre nášho agenta CI vyjadrený v pseudokóde:

Poznámka ku kódu: Príklad predpokladá, že rozhranie API služby CI podporuje vyhľadávanie behov podľa ID požiadavky. Hodnota request_id zabráni duplicitám, iba ak poskytovateľ výslovne zaručuje idempotenciu. bounded_retry() je ilustračný pseudokód. V produkcii by mali byť opakované pokusy obmedzené rozpočtom opakovaných pokusov pre každú operáciu (maximálny počet pokusov alebo uplynutý čas) aj celkovým termínom pracovného postupu.

Pri dlhších pracovných postupoch, ktoré zahŕňajú viacero služieb, zvážte vzor Saga na koordináciu kompenzačných akcií, keď neskoršie kroky zlyhajú. Len nezabúdajte, že kompenzácia nie je vždy úplným vrátením zmien. Aktualizáciu databázy môžete vrátiť, ale odoslaný e-mail už neodvoláte.

5. Smerujte a paralelizujte prácu s explicitnými rozpočtami prostriedkov

Treba tu vyvážiť dve veci: akú schopnosť modelu každá úloha potrebuje a koľko úloh môžete spustiť súčasne. Ak sa pomýlite v jednom či druhom, riskujete, že agenti budú súperiť o zdieľané kvóty API alebo sa budú spoliehať iba na drahé modely s uvažovaním.

Pri výbere modelu prispôsobte schopnosti modelu a úroveň uvažovania zložitosti úlohy – jednoduché, no často prehliadané. Môžete buď nakonfigurovať pravidlá smerovania a modely hodnotiť sami, alebo použiť orchestračnú platformu, ktorá výber modelu vyrieši za vás.

Napríklad režim úsilia (Effort Mode) v Perplexity Computer vám umožňuje zvoliť, koľko úsilia si úloha zaslúži, bez ručného výberu modelu. Vyberte Light, Standard, High alebo Ultra a Perplexity automaticky zvolí orchestrujúci model a jeho úroveň uvažovania. Tento orchestrátor potom deleguje čiastkové úlohy na podporných agentov, ktorí môžu používať modely od rôznych poskytovateľov.

Perplexity hodnotí konfigurácie modelov z hľadiska kvality a nákladov a uprednostňuje lacnejšie možnosti, ktoré prinášajú porovnateľné výsledky. Ak si chcete model a úroveň uvažovania vybrať sami, môžete použiť aj vlastné nastavenia (Custom).

Pri paralelizácii by mal limit vychádzať z vašej infraštruktúry a externých závislostí. Overte limity rýchlosti požiadaviek a tokenov zdieľaných rozhraní API a potom záťažovo otestujte svoj pracovný postup so zvyšujúcou sa súbežnosťou. Sledujte, či sa priepustnosť zlepšuje, alebo či sa požiadavky začínajú hromadiť vo fronte, spomaľovať alebo vracať chyby 429.

Aby bola spotreba prostriedkov predvídateľná, vynucujte limity prostriedkov a kontroly plánovania:

• Riaďte súbežnosť a rýchlosť požiadaviek: Obmedzte počet prebiehajúcich volaní na službu a nadbytočnú prácu zaraďte do frontu. Pamätajte, že samotný limit súbežnosti nevynúti limity požiadaviek za minútu ani tokenov za minútu.
• Sledujte rozpočty tokenov a nákladov: Započítavajte spotrebu v rámci celého pracovného postupu vrátane podagentov a prestaňte spúšťať novú prácu, keď zostávajúci rozpočet nestačí.
• Vynucujte termíny vykonávania: Nastavte časové limity úloh a pracovných postupov a tam, kde je to podporované, šírte zrušenie na bežiacich agentov.
• Rešpektujte závislosti: Nadväzujúce úlohy spúšťajte, až keď sú k dispozícii ich požadované vstupy, namiesto spúšťania všetkých agentov súčasne.

6. Vynucujte schvaľovanie a izolujte vykonávanie agentov

Nikdy nežiadajte model, aby sám rozhodol, či sú jeho akcie bezpečné. Namiesto toho dajte agentom oprávnenia podľa princípu najnižších privilégií a vynucujte pravidlá schvaľovania založené na riziku v kóde aplikácie. Ak agenti spúšťajú kód, izolujte toto vykonávanie od hostiteľského prostredia a obmedzte prístup k súborom, sieťam a povereniam. Obmedzíte tak škody, ak agent urobí chybu alebo spustí nebezpečný kód.

„Som skeptický voči príliš zložitým multiagentovým systémom, najmä keď agenti kontrolujú a schvaľujú prácu jeden druhého. Môžete skončiť s niekoľkými agentmi, ktorí si sebavedomo posúvajú tú istú chybu bez toho, aby ju niekto skutočne zachytil,“ varuje Spilker.

Zväčšiť

Pri akciách, ktoré vyžadujú ľudské schválenie, pozastavte vykonávanie a uložte presnú navrhovanú operáciu:

• jej parametre
• jej cieľový prostriedok
• jej commit alebo verziu stavu
• rozhodnutie posudzovateľa

Definujte tiež, čo sa stane, ak bude schválenie zamietnuté, vyprší jeho platnosť alebo bude potrebná eskalácia. Pre obnoviteľné frameworky je to nevyhnutné, pretože obnovenie prerušeného uzla znova vykoná kód od začiatku daného uzla. Akékoľvek vedľajšie účinky pred prerušením sa môžu spustiť znova.

Ak je teda schválenie zamietnuté alebo jeho platnosť vyprší, požiadavka sa uzavrie. Ak sa cieľový commit, parametre alebo oprávnenia pred vykonaním zmenia, schválenie zneplatnite a požiadajte o nové.

Spilker tiež nepodporuje predstavu, že cieľom sú plne autonómni agenti typu end-to-end. „Podľa mňa je lepšie vytvoriť niekoľko zameraných agentov s jasnými zodpovednosťami, definovanými oprávneniami a ľudskou kontrolou v správnych bodoch. Stále získate efektivitu bez toho, aby ste sa vzdali úplnej kontroly,“ uzatvára.

7. Nezávisle overujte výstupy a testujte správanie pri obnove

Stalo sa vám niekedy, že agent hlásil Success, hoci v skutočnosti zlyhal? Je to otravné, ak nie priam rozčuľujúce, a oprava nie je rýchla, pretože záverečná správa agenta vám nemusí prezradiť, kde sa stala chyba.

Ak to chcete preskúmať, sledujte, čo sa dialo počas vykonávania, a nezávisle overte výsledky. Venujme teda chvíľu izolovaniu a vyriešeniu problému.

Sledujte priebeh pracovného postupu a zistite, čo sa pokazilo

Skôr než začnete ladiť prompty agenta, zachyťte celú cestu vykonávania. Potrebujete trasovanie, ktoré prepája volania agentov, volania nástrojov, chyby a opakované pokusy v rámci toho istého behu pracovného postupu.

Sémantické konvencie GenAI od OpenTelemetry poskytujú štandardizovaný spôsob opisu týchto operácií. Napríklad invoke_workflow označuje vykonanie pracovného postupu, invoke_agent volanie agenta a execute_tool volanie nástroja. Každú operáciu možno zaznamenať ako span s jej časovaním, stavom a relevantnými metadátami.

Vďaka tomuto kroku získate trasovanie cesty vykonávania, takže dokážete identifikovať, kde sa agent zasekol.

Ilustračné trasovanie vykonávania.

Nezávisle skontrolujte výstup

Kdekoľvek je to možné, používajte programové kontroly. Overujte výstupy podľa schém JSON, spúšťajte jednotkové a integračné testy, kontrolujte, či existujú požadované artefakty, a dopytujte sa externých systémov, aby ste potvrdili, že akcie skutočne uspeli.

Pri výstupoch, ktoré si vyžadujú subjektívny úsudok – a teda ich nemožno posúdiť programovými kontrolami –, zaveďte nezávislého agenta posudzovateľa. Jedným z prístupov je slučka implementátor – posudzovateľ – riešiteľ, v ktorej jeden agent vytvorí artefakt, posudzovateľ s čerstvým kontextom identifikuje problémy a riešiteľ ich odstráni predtým, ako sa overenie spustí znova.

Zistenia posudzovateľa stále musíte podľa možnosti overiť, a ak na opakované hodnotenia používate hodnotiteľov založených na LLM, kalibrujte ich úsudky podľa príkladov skontrolovaných ľuďmi.

Vyvolajte zlyhania a otestujte obnovu

Doteraz ste sledovali, čo agenti vykonali, a kontrolovali ste, či boli ich výstupy správne. Čo sa však stane, keď pracovný proces spadne uprostred úlohy alebo keď API po prijatí požiadavky prekročí časový limit? Váš pracovný postup sa prekvapivo môže za bežných podmienok správať úplne bezchybne, no počas obnovy zlyhať.

Ak to chcete otestovať, zámerne vyvolajte poruchy v testovacom prostredí:

• Simulujte prekročenie časového limitu API
• Nechajte pracovné procesy spadnúť medzi zápismi do externých systémov a kontrolnými bodmi
• Vracajte chybne formátované výstupy nástrojov
• Nechajte vypršať platnosť schválení

Po každom teste preskúmajte záznam priebehu vykonávania, aby ste videli, ktoré kroky prebehli, kde sa pracovný postup obnovil a či sa niektoré akcie zopakovali alebo vynechali. Potom skontrolujte skutočné výsledky.

Povedzme, že váš agent CI odošle požiadavku na spustenie testovacieho behu, ale pri odpovedi API sa prekročí časový limit. Agent to skúsi znova, dostane úspešnú odpoveď a nahlási Success. Všetko vyzerá v poriadku, kým neskontrolujete službu CI a nezistíte, že sa namiesto jedného testovacieho behu vytvorili dva.

Preto by ste mali overiť zaznamenaný stav pracovného postupu aj skutočné zmeny v externých systémoch. Test obnovy by mal prejsť len vtedy, keď pracovný postup dosiahne očakávaný stav bez neúmyselných vedľajších účinkov.

Zlyhania, ktoré odhalíte, pridajte do regresných testov, aby ich budúce zmeny znova nezaviedli.

V konečnom dôsledku úspech znamená, že pracovný postup prešiel požadovanými kontrolami a jeho externé výsledky boli overené.

Časté otázky o orchestrácii agentov AI

Prečo izolovaní agenti AI zlyhávajú v podnikovom meradle?

Izolovaní agenti môžu svoje jednotlivé úlohy splniť správne, no spoločne prinášať nekonzistentné výsledky. Predstavte si agenta pre predaj, ktorý o 10:00 načíta zákaznícke podmienky, agenta pre ceny, ktorý o 10:05 vypočíta cenovú ponuku podľa aktualizovaných cien, a agenta pre právne otázky, ktorý kontroluje zmluvu zmenenú o 10:07. Každý agent pracuje s inou snímkou stavu firmy, takže ich výstupy si môžu navzájom odporovať.

V podnikovom meradle je tento problém ešte výraznejší, pretože agenti interagujú s viacerými systémami, ktoré sa aktualizujú nezávisle, pracujú s rôznymi oprávneniami a nemusia nevyhnutne zdieľať kontext ani stav vykonávania.

Ako zabrániť nekonečným slučkám opakovaných pokusov u agentov AI?

Nastavte limity na viacerých úrovniach: maximálny počet opakovaných volaní nástrojov, maximálny počet iterácií agenta, hĺbku delegovania a celkový termín pre pracovný postup. Pred opakovaním pokusu zlyhania klasifikujte. Pri prechodných odpovediach 429 rešpektujte hodnotu Retry-After, ak je uvedená. V opačnom prípade použite ohraničené exponenciálne odďaľovanie (backoff) s náhodným rozptylom (jitter).

Po chybách overenia alebo oprávnení prestaňte opakovať nezmenené požiadavky. Ak nadväzujúca služba opakovane zlyháva, istič (circuit breaker) môže zabrániť tomu, aby agenti vytvárali ďalšiu záťaž.

Ako obnoviť pracovný postup agenta AI po páde?

Mechanizmus obnovy závisí od použitého behového prostredia. V LangGraph ukladá perzistentný checkpointer, napríklad PostgresSaver, stav grafu pod identifikátorom thread_id, vďaka čomu môže vykonávanie pokračovať z uloženého stavu. V systéme Temporal môže iný pracovný proces (worker) zrekonštruovať pracovný postup prehratím jeho histórie udalostí. Počas prehrávania opätovne používa predtým zaznamenané výsledky aktivít.

Ak sa aplikácia znova nasadí, kým pracovné postupy ešte bežia, uložený stav a histórie vykonávania už nemusia byť kompatibilné. Temporal to rieši pomocou funkcie Worker Versioning a záplatovania pracovných postupov. Pri systémoch založených na kontrolných bodoch naplánujte migrácie schém a pred zavedením nekompatibilných zmien otestujte obnovu na existujúcich uložených stavoch.

Ako testovať spoľahlivosť orchestrácie agentov AI?

Spúšťajte rovnaké reprezentatívne úlohy viackrát a rozlišujte medzi pass@k (či je úspešný aspoň jeden z k pokusov) a pass^k (či sú úspešné všetky k pokusy)

Výsledky merajte podľa kategórie úloh a verzie pracovného postupu namiesto toho, aby ste sa spoliehali na jednu súhrnnú mieru úspešnosti. Sledujte úspešnosť na prvý pokus, konzistentnosť pri opakovaných behoch, latenciu p95, náklady na dokončenú úlohu a podiel úloh vyžadujúcich ľudský zásah. Pri mierach úspešnosti uvádzajte veľkosti vzoriek a intervaly neistoty.