Agent, který nečeká na prompt
Většina AI asistentů mlčí, dokud jim někdo nenapíše. Ambientní agent, jak ho popisuje blog AWS Machine Learning, funguje obráceně. Reaguje na proud událostí, třeba na nahrání souboru do úložiště Amazon S3, a pracuje bez chatového okna. Spouštěčem tedy není lidská zpráva, ale něco, co se stane v systému. Když si agent neví rady, potřebuje zpřesnění nebo souhlas, požádá člověka o vstup přes jediný nástroj ask_human. Jakmile dostane odpověď, naváže tam, kde skončil. Autoři na platformě Amazon Bedrock AgentCore ukazují referenční implementaci, která tento vzor skládá z běžných služeb AWS. Zajímavá je hlavně tím, jak přesně řeší chvíli, kdy se agent zastaví a předá slovo člověku. Právě tato chvíle odlišuje užitečný automat od nebezpečného.
Autonomie s pojistkou
Ambientní neznamená plně samostatný. Autoři výslovně uvádějí, že tito agenti plně autonomní nejsou. Produkční návrh má podle nich věnovat pečlivou pozornost tomu, kdy se agent zastaví a osloví člověka. Nejde tedy o to, zda lidi do procesu zapojit, ale kdy a jak. Právě tato lidská složka podle textu snižuje riziko nasazení agentů do produkce a pomáhá budovat důvěru uživatelů. Dodávají také, že se agenti mohou díky zpětné vazbě postupně zlepšovat. Jde o tvrzení autorů, nikoli o změřený výsledek. Zdroj k nim žádná čísla neuvádí. Pro čtenáře je důležité hlavně to, že lidský zásah je v architektuře záměrně vložená součást, nikoli nouzový východ. Celý návrh pak stojí na otázce, jak tento zásah technicky provést čistě a předvídatelně.
Cesta události systémem
Referenční implementace sestavuje tok událostí z několika služeb. Amazon S3 po vytvoření objektu odešle notifikaci o vzniku objektu, kterou přijme funkce Lambda zvaná Signal Processor. Ta v tabulce signálů ambient-signals vyhledá záznamy odpovídající bucketu, ve kterém událost vznikla. K tomu využívá globální sekundární index (GSI), tedy pomocný přístup k datům podle jiného atributu než primárního klíče. Pro každou nalezenou shodu pak vytvoří záznam úlohy. Signál je tu v podstatě pravidlo, které spojuje typ události s úlohou pro agenta. Úlohu zařadí do fronty Amazon SQS vrstva API, případně plánovač. Druhá funkce Lambda, Job Execution, tutéž roli obsluhuje i při volání přes API. Frontu zpracovává přes připojený zdroj událostí SQS, zavolá agenta běžícího na AgentCore Runtime a výsledky zapíše do databáze DynamoDB. Tam míří i případné žádosti o lidský vstup. Fronta mezi událostí a agentem tak odděluje okamžik, kdy něco vznikne, od okamžiku, kdy se to začne zpracovávat.
Spustit hned, nebo počkat na schválení
Zda agent po vzniku úlohy hned začne pracovat, určuje jediné nastavení signálu: autoExecute. Výchozí hodnota false znamená opatrný režim. Úloha se objeví na stránce Jobs ve stavu idle a čeká, až ji člověk zkontroluje a spustí. Dokud se tak nestane, agent nic nedělá. Při hodnotě true zařadí Signal Processor úlohu rovnou do pracovní fronty a agent běží okamžitě. Člověk je pak přizván jen tehdy, když agent sám zavolá ask_human. Rozdíl je praktický a týká se rozložení kontroly. První varianta dává lidem dohled před startem, takže se nic nespustí bez jejich vědomí. Druhá varianta kontrolu přesouvá až do průběhu práce a spoléhá na úsudek samotného agenta, kdy je nutné se zeptat. Že je výchozí hodnotou false, ukazuje, že ukázka počítá s opatrným začátkem. Volba mezi režimy je zároveň volbou mezi rychlostí a mírou předběžného dohledu.
Jedna cesta pro každý dialog s člověkem
Všechny interakce s člověkem procházejí jediným nástrojem ask_human a vracejí se v jednotné obálce odpovědi. Stav v ní nabývá tří hodnot: completed, interrupted, nebo error. Podle něj se vyplní odpovídající pole, tedy result, question, nebo error. Dokončená práce tak nese výsledek, pozastavená otázku a selhání popis chyby. Pojmy Notify, Question a Review podle autorů nejsou samostatné režimy běhu. Jde o konvence, jak agent formuluje svůj dotaz, tedy zda jen informuje, ptá se, nebo žádá o posouzení. Na úrovni platformy tak existuje právě jedna cesta kódu a jedna obálka. Pro vývojáře je to výhoda. Nemusí ošetřovat několik různých mechanismů a jejich odlišné stavy, stačí jim sledovat jediný tvar odpovědi se třemi možnými stavy. Rozdíly mezi typy dotazů žijí ve formulaci, ne v infrastruktuře.
Jak se agent vlastně zastaví
Technicky nejzajímavější je způsob, jakým se agent pozastaví. Nástroj ask_human nevyvolá výjimku. Framework LangGraph totiž zachytává výjimky nástrojů jako chybová pozorování a vrací je modelu. Přerušení by se tak mohlo ztratit v běžné chybové logice a model by s ním zacházel jako s obyčejnou chybou nástroje. Nástroj proto vrátí zvláštní řetězec, který slouží jako předem dohodnutá značka (autoři mluví o sentinelu). Orchestrátor ho po doběhnutí grafu najde ve zprávách nástroje a převede na odpověď se stavem interrupted. Tím se z pozastavení stává řízený a rozpoznatelný stav, který lze předat člověku. Po odpovědi uživatele funkce Job Execution agenta vyvolá znovu a odpověď vloží do navazujícího promptu. Agent tak pokračuje s novou informací v rukou. Celé řešení vychází z toho, že se chování frameworku nesnaží obejít silou, ale přizpůsobuje se mu.
Limity, které autoři zmiňují
Referenční implementace omezuje každý tah agenta na patnáctiminutový timeout funkce Lambda. Autoři to v praxi považují za více než dostatečnou rezervu. Výchozí konfigurace navíc povoluje zhruba deset kol mezi modelem a nástrojem (max_iterations: 10). Orchestrátor tuto hodnotu zdvojnásobuje, aby získal limit rekurze LangGraphu, protože jedno kolo projde dvěma uzly grafu. Číslo v konfiguraci tedy neodpovídá přímo číslu, které nakonec platí uvnitř grafu. Autoři uvádějí, že takový rozsah pokryje vícekrokové použití nástrojů, které ukázkový příklad s nástroji pro S3, kalkulačku a ask_human očekává. Jde o dvě různé pojistky. Časový strop hlídá délku jednoho tahu a počet kol hlídá, aby se agent nezacyklil mezi modelem a nástroji. Úlohy, které by se do těchto mezí nevešly, zdroj nerozebírá.
Co text neprokazuje
Zdrojem je blog samotného AWS a popisuje referenční implementaci, nikoli nezávislé měření nebo provozní zkušenost. Text nepřináší čísla o spolehlivosti agentů, o nákladech ani o tom, jak často se agent v praxi zastaví a zeptá. Tvrzení o snížení rizika a posílení důvěry jsou argumentem autorů. Ověřená zůstává architektura: událost, fronta, agent, záznam v databázi a jednotná obálka pro dialog s člověkem. Zda se vzor osvědčí v konkrétním podniku, z dodaných podkladů zjistit nejde. Čtenář by proto měl ukázku chápat jako popis způsobu stavby, ne jako důkaz, že takový systém v produkci funguje bez potíží.
Co si z ukázky odnést
Pro týmy, které zvažují podobného agenta, ukázka předkládá dvě konkrétní rozhodnutí. Prvním je nastavení autoExecute: začít s výchozím false, kdy úloha čeká na člověka ve stavu idle, nebo agentovi povolit okamžitý běh. Druhým je tvar komunikace s člověkem. Podle autorů stačí jeden nástroj, jedna obálka a tři stavy. Přerušení se přitom nesmí schovat za výjimku, kterou by framework vrátil modelu jako chybu. Pomáhá k tomu značkovací řetězec, který orchestrátor rozpozná po doběhnutí grafu. Ostatní části vycházejí ze standardních služeb: S3, Lambda, SQS a DynamoDB. Samotný agent běží na AgentCore Runtime. Hlavní poučení je, že důvěryhodnost ambientního agenta nevzniká jen z modelu, ale z promyšleného místa, kde se zastaví a zeptá.
Zdroje
- Building ambient agents with Amazon Bedrock AgentCore: From event-driven signals to human-in-the-loop workflows | Artificial Intelligence — AWS Machine Learning Blog
Článek vznikl s pomocí AI; podklady a odkazy jsou uvedeny výše.