Osvědčené postupy orchestrace AI agentů: zvládání selhání, schvalování a opakovaných pokusů

Několik agentů pracujících na stejném projektu zní nesmírně efektivně. Jeden plánuje práci, druhý se stará o návrh a třetí píše kód. Funguje to – dokud to nepřestane fungovat. A k selháním dochází častěji, než by se vám líbilo.

Předcházení těmto selháním vyžaduje pečlivý návrh pracovních postupů. Pojďme si proto rozebrat, proč jsou orchestrované pracovní postupy nespolehlivé, a podívat se na osvědčené postupy orchestrace pro spolehlivost v produkčním prostředí.

Co je orchestrace AI agentů?

Orchestrace AI agentů koordinuje více AI agentů, modelů a nástrojů při plnění vícekrokového úkolu. Někdo – nebo něco – ale stále musí rozhodnout, který agent poběží jako první, jaké informace dostane a co se stane po jeho dokončení. To je úloha orchestrátoru – AI agenta v roli manažera nebo softwarově řízené prováděcí vrstvy.

Zjednodušeně řečeno orchestrační vrstva rozdělí cíl na menší úkoly, sleduje závislosti, deleguje provádění na správné agenty, spravuje sdílený kontext a spojuje výstupy dohromady.

Jak funguje orchestrace AI agentů: pohled do prováděcího jádra

Zvětšit

Podívejme se, co se stane, když orchestrátoru zadáte úkol.

Vezměme si příklad z workshopu Perplexity o Computeru: vytvoření dashboardu s přehledem o klientských účtech z informací ze Salesforce, Snowflake, e-mailu, kalendáře a aktuálních zpráv.

1. Pochopení cíle a plánování práce. Orchestrátor vychází z požadovaného výsledku a rozkládá ho na úkoly s explicitními závislostmi. V našem příkladu s dashboardem to znamená shromáždit informace z různých zdrojů a proměnit je v hotový výstup. Plánovač určí, které kroky závisejí na jiných a které mohou běžet nezávisle.
2. Směrování úkolů k vhodným agentům. Orchestrátor identifikuje úkoly, jejichž závislosti jsou splněny, a deleguje práci na specializované agenty nebo modely. Závislé úkoly čekají na své předpoklady. Perplexity Computer využívá více špičkových modelů a jednotlivé části pracovního postupu směruje k systémům, které se pro dané úkoly hodí. Díky tomu může nezávislá práce probíhat paralelně.
3. Provádění volání nástrojů v kontrolovaných prostředích. Agenti pracují se svým prostředím prostřednictvím nástrojů, jako je vyhledávání na webu, rozhraní API, připojené aplikace, operace se soubory nebo spouštění kódu. Prováděcí vrstva tyto akce spouští a vrací výsledky agentům.
4. Předávání výsledků a kontextu mezi agenty. Jakmile agent dokončí svůj úkol, další agent v řetězci potřebuje relevantní výstup, aby mohl pokračovat. Záznam o předání může obsahovat ID úkolu, odkaz na výstup, verzi schématu a metadata zdroje. Orchestrátor tato předání koordinuje a zároveň udržuje kontext potřebný pro následující kroky. Důležité je, že agenti nemusejí ve svých kontextových oknech nést celou historii práce všech ostatních agentů.
5. Zaznamenávání stavu provádění odděleně od kontextu agentů. Jak agenti úkoly zahajují, dokončují nebo v nich selhávají, prováděcí jádro aktualizuje trvalý záznam pracovního postupu o stavy úkolů, pokusy o provedení, odkazy na výstupy a zbývající práci. Díky tomuto záznamu může orchestrátor sledovat postup a po přerušení pokračovat, aniž by se spoléhal na to, že LLM zrekonstruuje pracovní postup z historie konverzace.
6. Ověření výsledků a rozhodnutí o dalším postupu. Když se úkol vrátí, orchestrační vrstva zkontroluje, zda jeho výstup splňuje očekávaný kontrakt a zda jsou splněny závislosti dalšího úkolu. Pokud se zjistí problém, pracovní postup se může vrátit k dřívějšímu kroku kvůli opravě nebo se pozastavit. V opačném případě pokračuje k dokončení.

Za zdánlivě jednoduchou orchestrací AI agentů se skrývá mnoho vzájemně provázaných částí. Způsob, jakým uspořádáte koordinaci agentů, určuje, jakou kontrolu nad prováděním máte. A veškerá tato koordinace samozřejmě přináší dodatečnou režii. Proto se to ne vždy vyplatí.

Kdy použít orchestraci AI agentů?

Orchestraci více agentů zvažte, když různé části úkolu vyžadují odlišné odborné znalosti, nezávislá práce může probíhat paralelně nebo když nemůžete další krok určit předem.

Orchestrace je tedy užitečná ve třech situacích:

• Úkoly vyžadují různé specializace. Programátorskému projektu mohou například prospět samostatní agenti pro plánování, návrh, vývoj a kontrolu.
• Nezávislé úkoly mohou běžet paralelně. Místo toho, aby jeden agent dokončil vše postupně, může současně pracovat více agentů a vracet své výsledky orchestrátoru.
• Problém je otevřený. Agenti možná budou muset zkoumat různé přístupy, rozhodovat se a spolupracovat, místo aby se drželi předem definovaného postupu.

Kromě těchto případů je orchestrace jen nákladný trend. Více agentů také znamená více koordinace a potenciálně vyšší náklady na tokeny.

„Obvykle začínám tou nejjednodušší možností a stavím na ní. Pokud známe kroky a jsou opakovatelné, jde nejspíš o pracovní postup. Důvod zavádět více agentů vidím jen tehdy, když mají různé odpovědnosti, oprávnění nebo uživatele,“ říká Josh Spilker, vedoucí marketingu ve vyhledávání ve společnosti AirOps.

I tehdy ale zvažte přínosy oproti dalším voláním modelů, předáním, latenci a místům možného selhání.

Architektury orchestrace AI agentů a jejich kompromisy

Existují tři běžné způsoby, jak strukturovat koordinaci agentů – centralizovaná, decentralizovaná a hierarchická orchestrace. Volba správné architektury se scvrkává na jedinou otázku: Kdo řídí práci a jak se agenti mezi sebou koordinují?

Centralizovaná orchestrace

Při centralizované orchestraci řídí proces jeden orchestrátor. Rozloží úkol, deleguje práci na specializované agenty, sleduje jejich postup a spojuje jejich výsledky.

Zvětšit

Kompromis: Centralizovaná koordinace usnadňuje sledování provádění a uplatňování společných pravidel v jediném kontrolním bodě. Orchestrátor se však může stát úzkým hrdlem a jeho selhání může přerušit celý pracovní postup, pokud systém nepodporuje obnovu.

Decentralizovaná orchestrace

Při decentralizované orchestraci se agenti koordinují více napřímo, místo aby se spoléhali na jednoho manažera, který činí každé rozhodnutí. Mohou si vyměňovat zprávy, číst sdílený stav a samostatně určovat své další kroky.

Zvětšit

Kompromis: Agenti mohou pracovat, aniž by čekali na centrálního plánovače, takže je tento přístup vhodný pro průzkumnou práci a samostatné příspěvky. Koordinace se ale komplikuje, když se agenti neshodnou, aktualizují sdílené informace nebo potřebují dospět ke konzistentnímu výsledku.

Hierarchická orchestrace

Hierarchická orchestrace rozšiřuje manažerský přístup na více úrovní. Orchestrátor nejvyšší úrovně deleguje odpovědnost na podřízené orchestrátory, které koordinují vlastní skupiny specializovaných agentů.

Představte si firemní pracovní postup, do kterého jsou zapojeny obchodní, finanční a právní týmy. Orchestrátor nejvyšší úrovně by mohl každý pracovní proud delegovat na koordinátora specializovaného na danou oblast. Tito koordinátoři by pak řídili vlastní specializované agenty a hlásili souhrnné výsledky.

Tato struktura může pomoci, když jsou pracovní postupy příliš rozsáhlé na to, aby je jeden orchestrátor efektivně zvládl.

Zvětšit

Kompromis: Hierarchie umožňují týmům rozdělit odpovědnost za koordinaci a případně řešit selhání v rámci jednotlivých větví. Přinášejí však další předávání, složitější správu stavu a vyšší provozní režii. Lokální obnova navíc závisí na tom, jak jsou implementovány kontrolní body a stav provádění.

Srovnání těchto architektur:

Sekvenční a paralelní provádění a provádění s předáváním

Existuje ještě jeden rozdíl, kterému stojí za to porozumět. Architektura určuje, kdo agenty koordinuje. Vzor provádění určuje, jak postupují jejich úlohy.

Toto jsou tři vzory provádění:

• Sekvenční pracovní postupy: Agenti pracují v předem definovaném pořadí a výsledek jednoho agenta se stává vstupem dalšího.
• Paralelní provádění: Nezávislí agenti pracují současně.
• Provádění s předáváním: Řízení přechází mezi specializovanými agenty podle toho, jak úloha postupuje. To se hodí, když je na další krok lépe vybaven jiný agent, i když každé předání musí zachovat informace potřebné k pokračování.

Tyto vzory se vzájemně nevylučují a neodpovídají orchestračním architekturám jedna ku jedné. Cílem je zvolit nejjednodušší strukturu, která podporuje závislosti vašeho pracovního postupu, požadavky na koordinaci a přijatelnou provozní režii.

Běžná selhání při orchestraci agentů AI

Při orchestraci se může pokazit cokoli, od drobných přehlédnutí po složité překážky. Někdy se dokonce může zdát, že agent dělá svou práci správně, zatímco celý pracovní postup selhává. Na základě zkušeností odborníků z praxe jsme sestavili některé z běžných chyb, které stojí za nespolehlivými orchestrovanými pracovními postupy – dávejte si na ně pozor:

• Ztrátová předávání mezi agenty. Orchestrátor předá specializovanému agentovi shrnutý plán, ale ve shrnutí chybí omezení, závislosti nebo podrobnosti implementace.
• Předčasné slučování výsledků (fan-in). Navazující agent začne agregovat výsledky dříve, než jsou dokončeny všechny předcházející úlohy.
• Nedeterministické aktualizace sdíleného stavu. Paralelní agenti zapisují do stejných klíčů stavu bez jasně definované sémantiky slučování. V závislosti na tom, jak framework zpracovává aktualizace, to může vést ke ztraceným zápisům, duplicitním datům, výstupu závislému na pořadí nebo konfliktním změnám.
• Nesoulad kontrolních bodů a vedlejších efektů. Úloha provede externí operaci, ale její úspěšné provedení se trvale nezaznamená dříve, než pracovní proces selže. Při obnově orchestrátor uvidí nedokončenou úlohu a spustí ji znovu.
• Souběhy při obnovení po lidském schválení. Pozastavení a obnovení provádění přináší vlastní problémy se synchronizací.
• Smyčky delegování a zesilování opakovaných pokusů. Agenti si opakovaně přehazují práci, protože se jejich odpovědnosti překrývají, závislosti jsou cyklické nebo jsou podmínky dokončení nejednoznačné.
• Kontroly na úrovni instrukcí zaměňované za zabezpečení provádění. Orchestrátor může agentům nařídit, aby nepřistupovali k určitým prostředkům nebo neprováděli citlivé akce, ale instrukce modelu nevynucují oprávnění operačního systému, síťová omezení ani hranice autorizace. Výzkum v oblasti bezpečnostního inženýrství od Perplexity ukazuje, proč mohou agenti při sledování legitimních cílů překročit bezpečnostní hranice, a to i bez škodlivých instrukcí

Všimněte si, jak odlišná tato selhání jsou. Předčasný přechod plánovače i nejednoznačný externí zápis mohou vést k nesprávnému výsledku, ale vznikají v různých částech životního cyklu provádění. Proto spolehlivá orchestrace vyžaduje víc než jen vylepšování promptů nebo přidávání opakovaných pokusů.

7 osvědčených postupů orchestrace agentů AI pro spolehlivý provoz v produkčním prostředí

1. Definujte explicitní kontrakty úloh, kritéria přijetí a podmínky zastavení

Vágní cíle a nejasná definice hotového často vedou k neuspokojivým výsledkům generovaným agenty. Řešením je kontrakt promptu (rozsah práce pro agenta): dohodněte se na cíli, omezeních, formátu výstupu a podmínkách selhání dříve, než začne provádění.

Například takto byste mohli definovat kontrakt pro agenta, který má opravit občas selhávající integrační test:

• Cíl: Identifikovat a opravit příčinu nestabilního integračního testu API pokladny.
• Vstupy: Zdrojový kód testu, protokoly selhání CI, nedávné commity a relevantní kód aplikace.
• Omezení: Nevypínejte testy, nezmírňujte aserce ani neměňte nesouvisející chování aplikace.
• Očekávaný výstup: Patch kódu, vysvětlení hlavní příčiny a výsledky spuštění testů.
• Kritéria přijetí: Dříve selhávající test projde v 10 po sobě jdoucích bězích a projde i příslušná sada regresních testů.
• Podmínky selhání: Nelze určit hlavní příčinu, oprava způsobí regrese nebo není k dispozici požadované testovací prostředí.

Je tu ale ještě další důležitá věc: kdy by se měl agent zastavit?

Agent by neměl iterovat donekonečna jen proto, že ještě nevytvořil uspokojivý výsledek. Definujte, co se považuje za úspěšné dokončení, kdy vrátit částečně dokončenou úlohu a kdy se zastavit, protože požadavek nelze splnit. Nastavte maximální hloubku delegování a limity iterací nebo rozpočty na provádění, aby se z nevyřešených úloh nestaly nekonečné smyčky.

Zpět k našemu příkladu s CI. Mohli byste definovat tyto podmínky zastavení:

• Úspěch: Oprava projde v 10 po sobě jdoucích bězích testu a projde i příslušná sada regresních testů.
• Limit iterací: Agent smí vyzkoušet nejvýše dvě kandidátní opravy.
• Rozpočet na provádění: Agent se musí zastavit po 60 minutách, i když problém zůstane nevyřešen.
• Limit delegování: Agent může delegovat práci na jednoho specializovaného agenta, bez dalšího delegování na subagenty.
• Částečné dokončení: Pokud oba pokusy selžou nebo vyprší časový limit, agent vrátí svá zjištění, provedené pokusy o změny a výsledky testů.
• Zablokované provádění: Pokud testovací prostředí není k dispozici, agent se zastaví a místo vykázání úspěchu nahlásí, co ho blokuje.

2. Udržujte orchestrátory štíhlé a vynucujte strukturovaná předávání

Vývojáři někdy svěří orchestrátoru příliš mnoho odpovědností a ten pak místo koordinace specializovaných agentů začne sám psát kód, ladit nebo provádět podrobné revize. Tím vzniká úzké hrdlo: orchestrátor spotřebovává rozpočet kontextu na podrobnosti implementace, odkládá delegování a rozmazává odpovědnost za výsledky.

Nechte proto orchestrátory dělat jejich práci a vynucujte předávání s odkazy na konkrétní artefakty: původní úlohu, relevantní vstupy, výstupní artefakty, stav provádění a všechny nevyřešené problémy.

Vezměte si tento příklad: status: completed se vztahuje k práci přidělené agentovi, nikoli k celému pracovnímu postupu. Protože testy jsou stále ve stavu pending, orchestrátor by neměl schválit konečný výsledek.

3. Ukládejte stav pracovního postupu trvale a kontrolujte růst kontextu

Historie konverzace agenta není spolehlivým záznamem o průběhu pracovního postupu. Když se jeho kontextové okno zaplní, automatická komprimace může vypustit důležité podrobnosti. A pokud pracovní proces spadne, další agent potřebuje vědět, které kroky byly skutečně dokončeny.

Pokud například kódovací agent vygeneruje patch a pak spadne, další pracovní proces by měl načíst uložený artefakt a pokračovat od zaznamenaného stavu pracovního postupu. Pokud však agent také spustil externí běh CI, musí orchestrátor tento běh před opakováním akce samostatně sesouhlasit

Udržujte proto stav provádění odděleně od pracovního kontextu agenta. Stavy úloh, pokusy o provedení, dokončené kroky a odkazy na artefakty ukládejte do trvalého úložiště. Zároveň načítejte jen instrukce, vstupy a výsledky relevantní pro aktuální úlohu agenta, místo abyste do jeho kontextového okna cpali celou historii provádění.

4. Navrhujte opakované pokusy s ohledem na selhání a obnovitelné spouštění nástrojů

Řekněme, že váš agent CI spustí běh testů, ale u požadavku API vyprší časový limit. Nepodařilo se běh testů spustit, nebo ho služba CI zařadila do fronty a odpověď se ztratila?

Vypršení časového limitu nemusí nutně znamenat, že operace selhala. Proto musíte chyby rozlišit dřív, než rozhodnete, co bude následovat:

• Přechodné chyby (429, 503): Opakujte pokus s omezeným exponenciálním odstupem (backoff) a náhodným rozptylem (jitter) a respektujte hlavičku Retry-After, pokud je uvedena.
• Chyby ověření nebo oprávnění (400, 403): Zastavte se nebo opravte příčinu problému, místo abyste opakovali stejný požadavek.
• Nejednoznačné výsledky (vypršení časového limitu po možném zápisu): Než operaci zopakujete, ověřte, zda byla úspěšná.

Poznámka: I chyby, u kterých lze pokus opakovat, potřebují limity. Nastavte časový limit pro každé volání nástroje, omezte počet opakovaných pokusů i celkovou dobu opakování a vynucujte celkový termín pro pracovní postup, aby vnoření agenti nemohli stejnou operaci spouštět stále znovu. Pokud závislost opakovaně selhává, použijte jistič (circuit breaker), který požadavky dočasně zastaví.

U operací s externími vedlejšími efekty přiřaďte každé logické akci stabilní klíč idempotence a používejte ho při všech opakovaných pokusech. Pokud API podporuje deduplikaci na straně serveru, dokáže opakované požadavky rozpoznat, aniž by akci provedlo dvakrát. Pokud ji nepodporuje, dotazujte se externího systému pomocí korelačního ID nebo jiného autoritativního odkazu.

Když nedokážete zjistit, co se stalo, zastavte se a eskalujte.

Příklad logiky opakovaných pokusů pro našeho agenta CI vyjádřený pseudokódem:

Poznámka ke kódu: Příklad předpokládá, že API CI podporuje vyhledávání běhů podle ID požadavku. Identifikátor request_id zabraňuje duplicitám pouze tehdy, pokud poskytovatel výslovně zaručuje idempotenci. bounded_retry() je ilustrativní pseudokód. V produkčním prostředí by opakované pokusy měly být omezeny jak rozpočtem opakování pro každou operaci (maximální počet pokusů nebo uplynulý čas), tak celkovým termínem pracovního postupu.

U delších pracovních postupů, které zahrnují více služeb, zvažte vzor Saga pro koordinaci kompenzačních akcí, když pozdější kroky selžou. Pamatujte ale, že kompenzace není vždy úplný rollback. Aktualizaci databáze vrátit můžete, ale odeslaný e-mail už vzít zpět nelze.

5. Směrujte a paralelizujte práci s explicitními rozpočty prostředků

Je potřeba vyvážit dvě věci: kolik schopností modelu každá úloha potřebuje a kolik úloh můžete spouštět současně. Pokud jedno či druhé nastavíte špatně, riskujete, že agenti budou soupeřit o sdílené kvóty API nebo se budou spoléhat jen na drahé modely s uvažováním.

Při výběru modelu přizpůsobte schopnosti modelu a míru uvažování složitosti úlohy – je to jednoduché, ale dost často přehlížené. Mějte na paměti, že můžete buď sami nakonfigurovat pravidla směrování a vyhodnocovat modely, nebo použít orchestrační platformu, která výběr modelu zajistí za vás.

Například Effort Mode v Perplexity Computer vám umožňuje zvolit, kolik úsilí si úloha zaslouží, aniž byste museli ručně vybírat model. Zvolte Light, Standard, High nebo Ultra a Perplexity automaticky vybere orchestrační model a jeho úroveň uvažování. Tento orchestrátor pak deleguje dílčí úlohy na podpůrné agenty, kteří mohou používat modely od různých poskytovatelů.

Perplexity vyhodnocuje konfigurace modelů z hlediska kvality a nákladů a upřednostňuje levnější možnosti, které poskytují srovnatelné výsledky. Pokud si chcete model a úroveň uvažování zvolit sami, můžete také použít ovládací prvky Custom.

U paralelismu by měl limit vycházet z vaší infrastruktury a externích závislostí. Ověřte limity rychlosti požadavků a tokenů u sdílených API a pak zátěžově otestujte svůj pracovní postup s rostoucí souběžností. Sledujte, zda se propustnost zlepšuje, nebo zda se požadavky začínají řadit do fronty, zpomalovat či vracet chyby 429.

Aby spotřeba prostředků zůstala předvídatelná, vynucujte limity prostředků a mechanismy plánování:

• Řiďte souběžnost a rychlost požadavků: Omezte počet probíhajících volání na službu a nadbytečnou práci řaďte do fronty. Pamatujte, že samotný limit souběžnosti nevynutí limity počtu požadavků za minutu ani tokenů za minutu.
• Sledujte rozpočty tokenů a nákladů: Započítávejte využití v celém pracovním postupu včetně subagentů a přestaňte spouštět novou práci, když zbývající rozpočet nestačí.
• Vynucujte termíny provádění: Nastavte časové limity pro úlohy a pracovní postupy a tam, kde je to podporováno, propagujte zrušení do běžících agentů.
• Respektujte závislosti: Navazující úlohy spouštějte až ve chvíli, kdy jsou k dispozici jejich požadované vstupy, místo abyste spouštěli všechny agenty současně.

6. Vynucujte schvalování a izolujte spouštění agentů

Nikdy nežádejte model, aby sám rozhodoval, zda jsou jeho akce bezpečné. Místo toho přidělujte agentům jen minimální nutná oprávnění a pravidla schvalování založená na riziku vynucujte v kódu aplikace. Pokud agenti spouštějí kód, izolujte toto spouštění od hostitelského prostředí a omezte přístup k souborům, sítím a přihlašovacím údajům. Tím omezíte škody, pokud agent udělá chybu nebo spustí nebezpečný kód.

„K příliš složitým multiagentním systémům jsem skeptický, zejména když agenti navzájem kontrolují a schvalují svou práci. Můžete skončit s několika agenty, kteří si sebevědomě předávají stejnou chybu, aniž by ji kdokoli skutečně zachytil,“ varuje Spilker.

Zvětšit

U akcí, které vyžadují lidské schválení, pozastavte provádění a uložte přesnou navrhovanou operaci:

• její parametry
• její cílový prostředek
• její commit nebo verzi stavu
• rozhodnutí kontrolora

Definujte také, co se stane, pokud bude schválení zamítnuto, vyprší nebo bude vyžadovat eskalaci. To je zásadní u obnovitelných frameworků, protože obnovení přerušeného uzlu spustí kód znovu od začátku tohoto uzlu. Jakékoli vedlejší efekty před přerušením se mohou provést znovu.

Pokud je tedy schválení zamítnuto nebo vyprší, žádost se uzavře. Pokud se cílový commit, parametry nebo oprávnění před provedením změní, zneplatněte schválení a vyžádejte si nové.

Spilker také nesouhlasí s představou, že cílem jsou plně autonomní end-to-end agenti. „Podle mě je lepší vytvořit několik zaměřených agentů s jasnými odpovědnostmi, definovanými oprávněními a lidskou kontrolou ve správných bodech. Stále získáte efektivitu, aniž byste se vzdali plné kontroly,“ uzavírá.

7. Nezávisle ověřujte výstupy a testujte chování při obnově

Stalo se vám někdy, že agent hlásil Success, i když ve skutečnosti selhal? Je to nepříjemné, ne-li přímo k vzteku, a oprava není rychlá, protože závěrečná zpráva agenta vám nemusí prozradit, kde se něco pokazilo.

Chcete-li problém prošetřit, dohledejte, co se během provádění stalo, a nezávisle ověřte výsledky. Pojďme si tedy vyhradit čas na izolaci a vyřešení problému.

Pomocí trasování pracovního postupu zjistěte, co se pokazilo

Než začnete ladit prompty agenta, zachyťte celou cestu provádění. Potřebujete trasu, která propojí vyvolání agentů, volání nástrojů, chyby a opakované pokusy v rámci stejného běhu pracovního postupu.

Sémantické konvence GenAI od OpenTelemetry poskytují standardizovaný způsob popisu těchto operací. Například invoke_workflow identifikuje provádění pracovního postupu, invoke_agent vyvolání agenta a execute_tool volání nástroje. Každou operaci lze zaznamenat jako span s jejím časováním, stavem a relevantními metadaty.

Tento krok vám poskytne trasu cesty provádění, takže můžete zjistit, kde se agent zadrhl.

Ilustrativní trasa provádění.

Nezávisle zkontrolujte výstup

Kdekoli je to možné, používejte programové kontroly. Ověřujte výstupy proti schématům JSON, spouštějte jednotkové a integrační testy, kontrolujte, zda existují požadované artefakty, a dotazujte se externích systémů, abyste si potvrdili, že akce byly skutečně úspěšné.

U výstupů, které vyžadují subjektivní úsudek – a proto je nelze posoudit programovými kontrolami – zaveďte nezávislého agenta kontrolora. Jedním z přístupů je smyčka implementátor–kontrolor–řešitel, kdy jeden agent vytvoří artefakt, kontrolor s čerstvým kontextem identifikuje problémy a řešitel je vyřeší dříve, než se znovu spustí ověření.

Zjištění kontrolora je přesto potřeba tam, kde je to možné, ověřovat, a pokud k opakovanému hodnocení používáte hodnotitele založené na LLM, kalibrujte jejich úsudky podle příkladů zkontrolovaných lidmi.

Otestujte obnovu vkládáním selhání

Zatím jste sledovali, co agenti provedli, a kontrolovali, zda byly jejich výstupy správné. Co se ale stane, když pracovní proces spadne uprostřed úlohy nebo když u API po přijetí požadavku vyprší časový limit? Možná vás překvapí, že se váš pracovní postup může za běžných podmínek chovat bezchybně, ale během obnovy selhat.

Abyste to otestovali, záměrně vkládejte chyby do testovacího prostředí:

• Simulujte vypršení časového limitu API
• Nechte pracovní procesy spadnout mezi zápisy do externích systémů a kontrolními body
• Vracejte chybně formátované výstupy nástrojů
• Nechte vypršet platnost schválení

Po každém testu prozkoumejte trasování provádění a zjistěte, které kroky proběhly, kde pracovní postup pokračoval a zda se některé akce zopakovaly nebo byly přeskočeny. Poté zkontrolujte skutečné výsledky.

Řekněme, že váš agent CI odešle požadavek na spuštění testovacího běhu, ale u odpovědi API vyprší časový limit. Agent pokus zopakuje, obdrží úspěšnou odpověď a nahlásí Success. Všechno vypadá v pořádku, dokud nezkontrolujete službu CI a nezjistíte, že místo jednoho testovacího běhu vznikly dva.

Proto byste měli ověřovat jak stav zaznamenaný pracovním postupem, tak skutečné změny v externích systémech. Test obnovy by měl projít pouze tehdy, když pracovní postup dosáhne očekávaného stavu bez nezamýšlených vedlejších účinků.

Selhání, která odhalíte, přidejte do regresních testů, aby je budoucí změny znovu nezavedly.

Úspěch tedy v konečném důsledku znamená, že pracovní postup prošel požadovanými kontrolami a jeho externí výsledky byly ověřeny.

Časté dotazy k orchestraci AI agentů

Proč izolovaní AI agenti v podnikovém měřítku selhávají?

Izolovaní agenti mohou své jednotlivé úlohy splnit správně, a přesto společně přinášet nekonzistentní výsledky. Představte si prodejního agenta, který v 10:00 načte zákaznické podmínky, cenového agenta, který v 10:05 vypočítá nabídku podle aktualizovaných cen, a právního agenta, který kontroluje smlouvu změněnou v 10:07. Každý agent pracuje s jiným snímkem stavu firmy, takže si jejich výstupy mohou navzájem odporovat.

V podnikovém měřítku je tento problém výraznější, protože agenti komunikují s více systémy, které se aktualizují nezávisle na sobě, pracují s různými oprávněními a nemusí nutně sdílet kontext ani stav provádění.

Jak u AI agentů zabránit nekonečným smyčkám opakovaných pokusů?

Nastavte limity na více úrovních: maximální počet opakovaných volání nástrojů, maximální počet iterací agenta, hloubku delegování a celkový termín pro dokončení pracovního postupu. Před opakováním pokusu selhání klasifikujte. U přechodných odpovědí 429 respektujte hlavičku Retry-After, pokud je k dispozici. V ostatních případech použijte omezený exponenciální backoff s jitterem.

Po chybách validace nebo oprávnění přestaňte opakovat nezměněné požadavky. Pokud navazující služba opakovaně selhává, může jistič (circuit breaker) zabránit tomu, aby agenti vytvářeli další zátěž.

Jak obnovit pracovní postup AI agenta po pádu?

Mechanismus obnovy závisí na vašem běhovém prostředí. V LangGraph ukládá trvalý checkpointer, například PostgresSaver, stav grafu pod identifikátorem thread_id, což umožňuje pokračovat v provádění z uloženého stavu. V Temporalu může jiný pracovní proces zrekonstruovat pracovní postup přehráním jeho historie událostí. Během přehrávání znovu využije dříve zaznamenané výsledky aktivit.

Pokud je aplikace znovu nasazena ve chvíli, kdy pracovní postupy stále běží, uložený stav a historie provádění už nemusí být kompatibilní. Temporal to řeší pomocí funkce Worker Versioning a záplatování pracovních postupů. U systémů založených na kontrolních bodech naplánujte migrace schématu a před zavedením nekompatibilních změn otestujte obnovu na existujících uložených stavech.

Jak testovat spolehlivost orchestrace AI agentů?

Spouštějte stejné reprezentativní úlohy opakovaně a rozlišujte pass@k (zda uspěje alespoň jeden z k pokusů) a pass^k (zda uspěje všech k pokusů)

Výsledky měřte podle kategorie úloh a verze pracovního postupu, místo abyste se spoléhali na jedinou souhrnnou míru úspěšnosti. Sledujte úspěšnost na první pokus, konzistenci napříč opakovanými běhy, latenci p95, náklady na jednu dokončenou úlohu a podíl úloh vyžadujících lidský zásah. U měr úspěšnosti uvádějte velikosti vzorků a intervaly nejistoty.