Proč AI agenti potřebují před opakováním akce důkazy

Jak zabránit tomu, aby se z nedoručené odpovědi stala duplicitní akce

Agent podpory oprávněný provést jednu refundaci odešle požadavek, ale ztratí spojení. Nedostane potvrzení o úspěšném provedení a pokusí se refundaci odeslat znovu. Pokud byl původní požadavek úspěšný, může opakovaná akce agenta vést k druhé refundaci.

Jde pouze o hypotetický příklad. Ukazuje problém, který nelze vyřešit samotnou přesností modelu. Jaké kroky by měl agent podniknout, když nedokáže určit, zda jeho předchozí akce změnila stav prostředí?

Unite.AI se věnovala spolehlivosti agentů i nad rámec modelů. Otázky týkající se nápravy si v těchto diskusích zaslouží vlastní pravidla. Než agent podruhé provede akci s významnými důsledky, měl by ověřit, co se stalo, nebo mít platnou záruku, že nedojde k duplicitním účinkům.

Nedoručená odpověď neprokazuje, že akce selhala

Nedoručená odpověď neprokazuje, že akce selhala. Neříká, zda k chybě došlo ještě před provedením, zda byla akce dokončena bez potvrzení, ani zda proces stále probíhá.

Jde o běžný problém distribuovaných systémů, jak popisuje Amazon. Amazon vysvětluje, proč mechanismy pro opakování pokusů potřebují zvláštní ochranu před opakovanými vedlejšími účinky. Agenti přidávají do cesty obnovy systému nový rozhodovací prvek. Mohou činit další rozhodnutí o tom, jak postupovat při nápravě chyb.

Tato rozhodnutí mohou změnit způsob, jakým firma funguje. Opakovat například refundaci s jinou částkou v dolarech není jen další pokus o tentýž požadavek. Stejně tak zvolit druhou platební službu poté, co první přestala odpovídat, není pouhým dalším pokusem o tentýž požadavek.

Týmy musí rozlišovat mezi udělením oprávnění k provedení akce a udělením oprávnění k nápravě situace s neznámým výsledkem. Původní schválení neznamená, že je bezpečné akci provést znovu.

Nedávný výzkum měří riziko

Předtisková studie z září 2026 s názvem „Kde se nachází záruka právě jednoho provedení?“ představila benchmark LIMBO a testovala 25 930 epizod na devíti modelech. Její simulované služby byly testovány při ztrátě potvrzení, zpožděném zpracování a duplicitním doručení.

V hlavním testu autorů došlo k duplicitnímu účinku v 1 279 epizodách; agenti v 90 % případů nahlásili úspěšné dokončení. Agent tedy může oznámit úspěch, i když ve skutečnosti došlo k nesprávnému zpracování.

Tyto výsledky vycházejí z kontrolovaných benchmarků a neodhadují četnost selhání v produkčním prostředí. Služby byly simulované a několik analýz mělo průzkumný charakter. Týmy by měly vyhodnocovat výsledky akcí agentů odděleně od jejich hlášení o úspěšném provedení.

Studie se také zabývá tím, proč nemusí stačit kontrola aktuálního stavu. Požadavek, který se stále zpracovává, se může projevit až po kontrole. Ani prázdná odpověď o stavu neznamená, že se požadavek nakonec neprovede.

Opakované pokusy se vztahují ke stejnému záměru

Přijímající služba může pomocí klíče idempotence rozpoznat opakované pokusy o provedení jedné operace. Pokud tuto metodu správně podporuje, opakované pokusy nevytvářejí další účinky. Klíč idempotence musí zůstat stejný při všech opakovaných pokusech.

Dokumentace API společnosti Stripe uvádí příklady možností i omezení klíčů idempotence. U API v1 lze klíče smazat až po uplynutí nejméně 24 hodin. Opětovné použití odstraněného klíče vyvolá nový požadavek. Stripe také ověřuje, zda parametry zadané žadatelem odpovídají parametrům původního požadavku.

Prakticky to znamená, že idempotence musí být zajištěna ve vaší integrační vrstvě, nejen v zadání. Před odesláním operace zaznamenejte její schválenou podobu. Uložte její identifikátor, přesné parametry, případný odkaz na poskytovatele a stav operace.

U refundace uložte vazbu schválení na původní transakci a také všechny identifikátory refundací vrácené poskytovatelem. Vyhledání jakékoli refundace ve stejné výši je méně přesvědčivým důkazem, protože dvě oprávněné žádosti mohou mít stejnou částku. Mezi žádostí o refundaci a jejím zobrazením ve výsledcích vyhledávání může navíc dojít ke zpoždění. Původní požadavek může stále probíhat.

Když se agent nebo pracovní proces restartuje, vrstva vykonávání by měla zachovat jeho identitu. Upravený požadavek předložený jako tatáž operace by měla odmítnout. Taková změna představuje novou akci, která podle pravidel pracovního postupu vyžaduje nové rozhodnutí o schválení.

Popisy nástrojů nestačí

Kromě popisů nástrojů ověřte také, zda kontrakt přijímající služby zaručuje podporu idempotence. Otestujte její implementaci a potvrďte, jaké záruky skutečně poskytuje.

Považujte nejistotu za provozní stav

Obrázek 1. Navrhovaný postup obnovy po akcích s významnými důsledky. Každý opakovaný pokus také vyžaduje aktuální oprávnění.

Potvrzené dokončení znamená, že pracovní postup zaznamená výsledek a pokračuje, aniž by akci opakoval. Potvrzené neprovedení umožňuje další pokus pouze tehdy, pokud nezůstává nevyřízený původní požadavek a oprávnění je stále platné.

V případě nevyřešeného výsledku je třeba zvážit ještě mnoho dalších faktorů. Pokud existuje platná záruka podporovaná poskytovatelem, že nedojde k duplicitním účinkům, můžete povolit opakování původního požadavku se stejným klíčem. Jinak pozastavte zápis a ověřte stav prostřednictvím dotazu na stav, podpory poskytovatele nebo pověřeného operátora. Neprůkazná kontrola není dostatečným důvodem k povolení dalšího pokusu.

Pozastavení může být odůvodněné také tehdy, když poskytovatel dokumentuje časové hranice zpracování a zpřístupnění výsledku. Bez těchto hranic samotný uplynulý čas nepotvrdí, že se akce neprovedla. Je třeba určit, kdo odpovídá za nevyřešené případy a kdy je tito odpovědní pracovníci musí zkontrolovat.

Obnova po selhání může vyžadovat jiný obchodní proces

Pokud se vrácení peněz podaří, ale následné upozornění zákazníka selže, opakováním celého pracovního postupu by se mohlo vrácení peněz provést znovu. Obnova by se měla zaměřit na dokončení nedokončeného kroku a současně zachovat doklady o již provedené práci.

Pokud je třeba přijmout nápravná opatření u již dokončených akcí, Microsoft poskytuje pokyny k vyrovnávacím transakcím. Každá aplikace určuje správný způsob nápravy chyb. Náprava nemusí nutně vrátit vše do původního stavu a může selhat i sama.

Zrušení transakce může navíc vést k poplatku. Oprava zprávy nemůže zaručit, že někdo neviděl její předchozí verzi. Každá činnost související s obnovou proto musí výslovně vymezit, co může agent vrátit zpět, změnit nebo k čemu se může zavázat. Rozhodnutí přesahující tato omezení musí být předána osobě s potřebnými pravomocemi.

Před nasazením otestujte opakovaný pokus

Vyberte jeden nástroj s významnými důsledky a cíleně otestujte obnovu v testovacím prostředí. Po úspěšném provedení zahazujte odpověď na původní požadavek. Odložte provedení prvního požadavku až do chvíle po kontrole stavu. Během obnovy restartujte pracovní proces. Před dalším pokusem počkejte, až vyprší doba uchovávání klíče. Při opakovaných pokusech změňte jeden parametr.

Vyhodnocujte výsledné obchodní záznamy, místo abyste se spoléhali pouze na odpovědi nástrojů. Zaznamenávejte duplicitní účinky, nevyřešené operace, opomenutou práci, dobu obnovy a dodatečné manuální zásahy. Náklady na správně dokončený úkol vypočítejte na základě celkových nákladů pracovního postupu, včetně storen transakcí a nápravných opatření vůči zákazníkům.

Otestujte také skutečný druhý požadavek podobný původnímu. Zajistěte, aby systém předcházel duplicitám, aniž by bránil nové práci. Předcházení duplicitám a následné dokončení úkolu posuzujte odděleně. Jinak by agent, který ukončí každý úkol, mohl působit bezpečně, přestože přináší jen malou nebo žádnou hodnotu.

Otázka pro vaše hodnocení musí být formulována jasně. Dokázal systém vysvětlit:

• Která operace byla schválena?
• Jaké důkazy potvrzovaly její výsledek?
• Proč bylo možné provést další pokus?

Agent, který se kvůli nevyřešené nejistotě pozastaví, může během ukázek působit méně efektivně. V produkčním prostředí však může pozastavení zachovat původní záměr zákazníka. Užitečná vytrvalost znamená, že systém dokončuje schválené úkoly, aniž by je potichu prováděl duplicitně.