Agents API dostává prohlížeč: co může AI vyřídit na webu a kde potřebuje kontrolu

AI už nemusí pouze vysvětlovat, kam na webu kliknout. Od 29. září 2026 mohou vývojáři v Agents API zapojit také ovládání prohlížeče hostovaného OpenAI. Agent tak může procházet stránky a pracovat s jejich rozhraním. Důležitou změnou je možnost dokončit úlohu ve webové aplikaci; stejně důležité je určit, co smí skutečně potvrdit. Kliknutí na tlačítko může změnit účet nebo odeslat data.

Rozbor vychází z dokumentace ověřené 25. října 2026. Vysvětluje architekturu a modelový návrh použití, nikoli vlastní test úspěšnosti agentů. Pro obecné nastavení oprávnění navazuje průvodce agentem s přístupem k účtům. Před nasazením je potřeba ověřit konkrétní podmínky cílové aplikace a vašeho účtu.

Co přináší prohlížeč v Agents API

Dokumentace popisuje agenta, který v prostředí OpenAI používá prohlížeč, sleduje jeho stav a podle něj pokračuje. Vaše aplikace založí relaci, zpracovává události a obsluhuje přístup na weby i přihlášení. Nejde tedy jen o model, kterému předáte text stránky. Součástí systému je také běžící pracovní prostředí.

Takový způsob práce může pomoci tam, kde web nabízí potřebnou funkci pouze v uživatelském rozhraní. Agent má vidět skutečný výsledek, vybrat ovládací prvky a ověřit další stav. Dostupnost této techniky ale sama neslibuje úspěšné vyřízení každého formuláře. Rozhraní se mohou měnit a některé kroky vyžadují člověka.

Vývojář musí zachovat rozdíl mezi relací a úlohou. Vytvoření browserové relace ještě neznamená zahájení konkrétní práce. Uchovejte její identifikátor, abyste poznali, kam patří události a výsledky. Při přerušeném spojení potřebujete dohledat stejnou práci, nikoli bez rozmyslu založit další.

Kdy je lepší přímé propojení aplikací

Pokud služba nabízí vhodné API, bývá pro opakované zpracování užitečné nejprve prověřit právě je. Můžete přesněji určit vstup, povolené pole a vrácený identifikátor. Ovládání prohlížeče je zase kandidátem pro práci, která vyžaduje orientaci v dostupném rozhraní a nemá vhodné přímé propojení.

Není nutné zvolit jeden přístup pro všechny kroky. Informace můžete přečíst přes podporované rozhraní a finální podobu ověřit v prohlížeči. Nebo agent připraví podklady, zatímco odeslání proběhne řízenou funkcí s pevnými parametry. Rozhoduje přehlednost, provozní spolehlivost a dohledatelnost změn.

Před výběrem technologie si napište přesnou potřebu. „Pracovat s objednávkami“ je příliš široké zadání. „Najít stav tří vlastních objednávek a zapsat jej do přehledu“ už má ověřitelný konec. Zvolený nástroj má sloužit tomuto cíli, nikoli vytvářet další možnosti změn, které nepotřebujete.

Modelový první projekt: kontrola webového formuláře

Představme si provozovatele webu, který chce zkontrolovat veřejný kontaktní formulář na malé a velké obrazovce. První úloha může skončit přehledem viditelných polí, povinných položek a případných problémů s čitelností. K tomu nepotřebuje používat skutečné osobní údaje ani posílat zprávu cizímu příjemci.

Pro takovou úlohu připravte testovací prostředí nebo jasně označený vlastní formulář. Určete, zda se smí také odeslat zkušební záznam a kam. Pokud je cílem pouze kontrola rozložení, ukončete práci před odesláním. Hodnoticí klíč má zahrnovat skutečně načtený stav a pořízený důkaz, nikoli jen tvrzení agenta, že stránku prošel.

Na výstupu požadujte například:

• adresu a název zkontrolované stránky;
• rozměry použitého zobrazení;
• seznam polí a pozorovaných problémů;
• snímek relevantního místa;
• přesné označení toho, co zůstalo neověřené.

Když se některý snímek nenačte, kontrola tohoto místa neproběhla. Uložení názvu souboru ještě není důkazem jeho obsahu. Stejný princip platí pro všechny další výsledky: ověření musí odpovídat tomu, co chcete o dokončení úlohy tvrdit.

Přístup na web a přihlášení jsou dvě různé věci

Dokumentace počítá se zpracováním požadavků na přístup k webu a případného přihlášení. Povolení otevřít veřejnou stránku nemá automaticky znamenat oprávnění použít libovolný účet. V návrhu aplikace oddělte návštěvu domény, práci v účtu a konkrétní změny, které uživatel dovolil.

Prohlížeč může při přihlášení získat přístup k více údajům, než vyžaduje samotná úloha. Proto je vhodné vybrat účet s odpovídající rolí a pracovním rozsahem. Agent kontrolující dostupnost rezervace nepotřebuje spravovat uživatele celé organizace. Omezení je srozumitelnější, pokud jej podporují i oprávnění cílové služby.

Přístupové údaje nepatří do běžného promptu, poznámek ani veřejného protokolu. Návrh přihlášení musí odpovídat podporovanému mechanismu aplikace. Pokud krok vyžaduje osobní rozhodnutí, například potvrzení nové podmínky, předání člověku je součást práce. Není důvod přidávat agentovi širší oprávnění jen proto, že narazil na překážku.

Co má uživatel schvalovat konkrétně

Schválení je užitečné tehdy, když člověk vidí přesný zamýšlený výsledek. Věta „mohu pokračovat?“ příliš neříká. Lepší je ukázat cílový objekt, novou hodnotu a důsledek. U návrhu zprávy má člověk vidět příjemce i celý text. U změny záznamu původní a nové údaje.

Práci před schválením dokončete do kontrolovatelné podoby. Agent může připravit souhrn, vyplnit návrh nebo vybrat konkrétní položku. Souhlas má uzavírat rozhodnutí nad konkrétním výsledkem. Nemá nahrazovat přemýšlení o zadání na začátku každého běžného kroku.

Současně má systém rozpoznat, které činnosti už byly jasně povolené. Opakované dotazy u stejné vratné operace zhoršují použitelnost a mohou vést k bezmyšlenkovitému potvrzování. Rozsah povolení proto ukládejte srozumitelně a vztahujte jej na konkrétní objekty a typy akcí.

Webová stránka není zdroj nových oprávnění

Agent při práci čte také obsah vytvořený někým jiným. Může v něm narazit na text, který se tváří jako instrukce: například výzvu odeslat dokument jinam nebo změnit původní úkol. Takový obsah je podklad k posouzení, nikoli automatické rozšíření zadání uživatele.

Představme si stránku s poznámkou, že pro správné dokončení má agent nahrát celý seznam zákazníků do jiného formuláře. Pokud to uživatel neobjednal, stránka nemůže rozhodnout za něj. Rozlišení původu instrukcí je podstatné i u vlastního webu, pokud obsahuje komentáře, vložené dokumenty nebo informace od externích lidí.

Podrobnější souvislosti rozebírá článek o prompt injection v dokumentech. Pro první nasazení zvolte úzký úkol a omezený výběr zdrojů. Zkouška má zahrnovat i podklad s nepatřičnou instrukcí, aby bylo vidět, jak jej proces vyhodnotí.

Přerušené spojení a opakovaný požadavek

Výpadek spojení neprokazuje, že se nic nestalo. Agent mohl potvrdit zápis těsně předtím, než aplikace ztratila přehled o událostech. Pokud bez kontroly zahájíte stejnou práci znovu, může vzniknout druhá objednávka, duplicitní záznam nebo opakovaně odeslaná zpráva.

Dokumentace doporučuje před opakováním obnovit stejnou relaci a ověřit její stav. Ve vlastní aplikaci uchovávejte identifikátor úlohy, poslední potvrzený krok a výsledný identifikátor změněného objektu, pokud jej cílová služba poskytuje. Nejasný výsledek předávejte do dohledání, ne do automatického nekonečného opakování.

Modelovým případem je založení interního servisního požadavku. Jestliže nevíte, zda vznikl, nejprve jej vyhledejte podle jednoznačného označení. Počet nových pokusů nastavte omezeně a zaznamenejte jejich důvod. Každý další krok má navazovat na skutečný stav, nikoli na předpoklad odvozený jen z poslední chybové hlášky.

Náklady tvoří celý běžící systém

Agents API zahrnuje více než samotné tokeny modelu. Dokumentace rozlišuje modelovou spotřebu, použité nástroje a hostované prostředí. Pro první rozpočet si proto připravte úplný seznam složek. Pevnou cenu za jednu vyřízenou webovou úlohu nelze určit bez její délky a podmínek.

Měřte čas běhu, počet opakování, nástroje a zásahy člověka. Úloha může strávit velkou část času čekáním na pomalý web nebo na osobní schválení. Provozní návrh má řešit, co v takové chvíli zůstává aktivní a jak se relace ukončí. Příjemný dojem z rychlého psaní odpovědi nevypovídá o celkové ceně.

Začněte jedním typem práce a malým objemem. Pokud se postup nevyplatí, potřebujete poznat příčinu: nevhodnou úlohu, nestabilní rozhraní, velký počet oprav nebo příliš široké zadání. Teprve podle toho rozhodnete, zda pomůže změna modelu, přímé API nebo běžná ruční obsluha.

Co má obsahovat použitelný protokol

Záznam má odpovědět, co bylo požadováno, co se skutečně provedlo a co zůstalo otevřené. Příliš podrobný protokol plný citlivých údajů může vytvořit další problém. Zbytečně stručné „hotovo“ zase nepomůže při kontrole chyby. Vyberte údaje potřebné pro konkrétní provoz.

• Jednoznačný identifikátor úlohy a použité relace.
• Rozsah původního povolení a případná další schválení.
• Potvrzené důležité kroky a výsledné objekty.
• Důvod přerušení nebo ručního předání.
• Výsledek závěrečného ověření.

Při práci s osobními údaji si samostatně určete, kdo protokol smí číst a jak dlouho jej potřebujete. Pravidla konkrétního nasazení posuzujte podle skutečných dat a smluv. Obecný technický návod nemůže nahradit toto rozhodnutí za každou organizaci.

Jak vybrat chyby do přejímací zkoušky

Vedle běžného úspěšného průchodu si připravte několik záměrně neúplných situací. Web může vrátit prázdný výsledek, požadovaný záznam nemusí existovat a formulář může odmítnout hodnotu. U každé situace si předem napište správné chování. Chybějící výsledek není důvod vymyslet náhradní údaj jen proto, aby přehled vypadal hotově.

Další zkouška může obsahovat změněné rozložení stránky. Agent má buď najít skutečně odpovídající ovládací prvek, nebo vysvětlit, proč nemůže bezpečně pokračovat. Nemá automaticky použít první podobně pojmenované tlačítko. U hromadné práce přidejte případ, v němž je část položek hotová a část čeká; výstup musí tyto skupiny rozlišit.

Nakonec ověřte předání člověku. Příjemce potřebuje stručný popis problému, poslední potvrzený stav a konkrétní další možnost. Obecná chybová hláška bez návaznosti může znamenat, že se celá úloha začne zbytečně znovu. Dobrý návrh dovolí pokračovat z dohledatelného místa a přitom respektovat původní rozsah povolení.

Otázky před nasazením

Nahradí prohlížeč všechny integrace?

Některé úlohy zjednoduší, jiné je vhodnější řešit přímým podporovaným rozhraním. Porovnávejte dohledatelnost výsledku, četnost změn rozhraní a cenu provozu. Pro kombinaci kroků může být vhodný smíšený postup.

Stačí agentovi zadat, ať nic nepokazí?

Takové přání nevymezuje konkrétní hranici. Napište, které objekty smí číst nebo měnit a které úkony vyžadují potvrzení. Důležitá omezení podpořte také oprávněními v cílové aplikaci.

Kdy je úloha opravdu dokončená?

Když ověřený stav odpovídá zadání a existuje potřebný důkaz. Přečtená hláška nemusí potvrzovat uloženou změnu. U zápisu zkontrolujte výsledný objekt; u vizuální kontroly skutečně prohlédněte načtený snímek.

Co udělat po výpadku spojení?

Nejprve obnovte přehled o původní relaci a zjistěte, co už proběhlo. Až potom rozhodněte o opakování konkrétního kroku. Tento postup chrání před duplicitami a zároveň umožňuje dokončit práci bez zbytečného nového začátku.