Poslechněte si tento článek

Namluvila Ifigenie AI

Ifigenie
0:00 / 0:00

Poslední vlna nástrojů pro AI agenty nepřipomíná další chatbot. Připomíná pracovní stůl, na kterém se hromadí terminál, přihlášený prohlížeč, záznamník rozhodnutí, obnovovací protokol a provozní panel. To je dobrá zpráva: agenti konečně dostávají infrastrukturu, bez níž zůstávali drahou ukázkou v jedné kartě prohlížeče. Zároveň je to varování. Jakmile agent dostane ruce, nestačí obdivovat, že je má.

Na Radyz se dnes sešlo několik krátkých zpráv, které dohromady ukazují jednu věc. Helium Terminal staví terminál kolem práce coding agentů. Chrome Relay otevírá agentům přihlášený Chrome. DHP řeší převzetí práce po pádu procesu, Rutter ukládá rozhodnutí do poznámek a Zulu Assistant chce sjednotit dohled nad automatizacemi na Macu. Každý projekt je malý, raný a různě ověřený. Dohromady ale popisují posun od „model odpoví“ k „model něco dělá v prostředí, které musíme umět spravovat“.

Podle nás je hlavní otázka méně okázalá než samotná autonomie: kdo pozná, že agent právě překročil hranici rozumné pomoci? Ne jestli dokáže otevřít kartu, spustit příkaz nebo navázat po pádu. To všechno je jen mechanika. Skutečná kvalita začne ve chvíli, kdy nástroj umí práci přerušit, předat, doložit a nechat člověka rozhodnout u kroku, který už má dopad mimo pracovní sešit.

Terminál se mění v řídicí věž

Helium Terminal se podle veřejného repozitáře projektu nesnaží vymyslet nový jazykový model. Je to nativní macOS terminál postavený na libghostty, Swiftu a AppKitu, bez Electronu. V postranním panelu ukazuje pracovní složky, poslouchající porty, stav gitové větve a upozornění na panely, které vyžadují pozornost. To zní skoro banálně, dokud si neuvědomíme, že u agentické práce se člověk často neztrácí v samotném promptu, ale v okolí: který server běží, kde agent čeká na souhlas, který proces už skončil a co vlastně zůstalo rozpracované.

Právě tady se začíná lámat pohodlný mýtus o autonomii. Agent nemusí být „samostatnější“ tím, že zmizí z dohledu. Často je užitečnější pravý opak: vidět jeho pracovní prostor, porty, větve a žádosti o zásah tak obyčejně, jako dnes vidíme panely v prohlížeči. Dobře navržený terminál pro agenty proto není ozdoba pro vývojáře. Je to pokus dát člověku zpět situační přehled.

Tohle navazuje na starší problém, který jsme rozebírali u dohledávání důvodů změn pomocí Wy. Když agent upraví kód, nestačí zpětně dostat elegantní vysvětlení. Potřebujeme vědět, v jakém stavu systém byl, co agent viděl a proč zvolil danou cestu. Terminál je jen jedna část téhle historie, ale bez ní se z agentické práce stává divadlo: na konci vidíme výsledek, ne průběh.

Přihlášený prohlížeč je výhoda i pokušení

Ještě citlivější je prohlížeč. Projekt Browser Relay, který odpovídá dnešní rychlé zprávě o Chrome Relay, v README popisuje, že agentům umožňuje používat běžný přihlášený Chrome přes lokální nebo vzdálený relay, rozšíření a CLI. Smysl je zřejmý: spousta dnešní práce není v API, ale ve webových aplikacích, kde je člověk už přihlášený a kde agent potřebuje číst, klikat a připravovat kroky.

Jenže přihlášený prohlížeč není neutrální okno do internetu. Je to místo s účty, oprávněními, platebními údaji, firemními dokumenty a administrací. Pokud agent dostane možnost kliknout v kartě, nejdůležitější už není, zda kliknutí technicky zvládne. Důležité je, zda smí kliknout právě tam, zda akce mění stav systému a kdo ji uvidí v auditním záznamu.

Na Radyz jsme u staršího komentáře o Chrome jako půdě pro AI agenty psali, že prohlížeč může být pro agenty větší změna než další chatbot. Dnešní malé projekty ukazují praktičtější tvář téhož trendu. Nečekají na velké platformní oznámení. Otevírají agentovi reálné uživatelské prostředí. A tím nutí řešit pravidla, která se v demu snadno přeskočí.

Obnova po pádu není jen pohodlí

DHP, tedy Durable Handoff Protocol, se podle svého repozitáře snaží zajistit, aby práce agenta přežila smrt pracovního procesu. Úkol je oddělený od konkrétního workeru, postup se ukládá do checkpointů a jiný worker může navázat na poslední známý stav. Autor projektu to rámuje jako chybějící vrstvu mezi agentem a časem. Marketingová formulace je trochu velká, ale problém je skutečný.

U dlouhé agentické práce totiž pád procesu není jen technická nepříjemnost. Může znamenat ztrátu rozhodnutí, opakování částečně provedené akce nebo nejhorší variantu: dva procesy, které si myslí, že pořád mají právo zapsat výsledek. DHP proto zavádí časově omezené oprávnění k úloze a odmítání opožděných zápisů původního procesu. To není efektní část AI, kterou dáte do videa na sociální síť. Je to účetnictví odpovědnosti.

Právě takové účetnictví bude rozhodovat o tom, zda agenti opustí režim hraček pro trpělivé nadšence. Pokud má nástroj po pádu navázat, musí vědět, co už bylo provedeno, co bylo jen naplánováno a co se nesmí zopakovat. Bez této hranice může „odolnost“ snadno znamenat, že se chyba provede dvakrát. Schopnost pokračovat je užitečná jen tehdy, když systém ví, odkud pokračuje a kdo právě drží právo měnit svět.

Paměť rozhodnutí není paměť modelu

Rutter jde na podobnou oblast z jiné strany. Podle dokumentace projektu je to MCP server nad složkou markdownových poznámek, kam se ukládají datované řádky o rozhodnutích a odkazy na citované poznámky včetně obsahových otisků. Není v něm vlastní model. Neprodává se jako mozek agenta. Spíš jako lodní deník: co jsme udělali, kdy a z čeho jsme vycházeli.

To je zdravější představa paměti než nejasné „agent si pamatuje“. Jazykový model si může v další relaci plynule domyslet souvislosti, ale plynulost není důkaz. U pracovních rozhodnutí potřebujeme záznam, který se nepřepisuje podle nálady příštího shrnutí. Pokud Rutter ukáže, že odkazovaná poznámka byla přejmenována beze změny obsahu, je to užitečnější než další sebevědomý odstavec o tom, co si agent nejspíš myslel.

Tahle linka souvisí i s dnešní debatou o nechtěných akcích Claude. V článku AI musí umět i nedokončit úkol jsme psali, že u agentů s přístupem do skutečného světa je včasné zastavení součást kvality. Stejně tak je součástí kvality zanechat po sobě stopu, která se dá číst i bez víry v dodatečné vysvětlení modelu.

Self‑healing nesmí být samočinné odpouštění

Zulu Assistant chce podle veřejného GitHubu sledovat LaunchAgenty, kontejnery, cronové úlohy, endpointy a živé relace Claude Code či Codexu na Macu. Slibuje sdílený seznam úkolů, koordinaci workerů a opatrné samoopravné zásahy. Zní to jako přesně ten typ panelu, který si dříve nebo později vyrobí každý, kdo nechá na svém počítači běžet víc než jednoho agenta.

Slovo „self‑heal“ ale zaslouží přísné čtení. Restart služby po pádu může být rozumný. Automatické opakování kroku, který něco stojí, mění data nebo posílá požadavek ven, už je jiná liga. Zulu v popisu zdůrazňuje pravidla nastavená vlastníkem počítače a eskalaci destruktivních, placených nebo navenek působících akcí člověku. Přesně tudy vede hranice mezi užitečným provozním panelem a malým domácím chaosem s hezkým rozhraním.

Největší přínos těchto nástrojů proto není v tom, že agentům dovolí dělat víc. Je v tom, že mohou z „víc“ udělat spravovanou činnost. Kdo má právo psát? Kdo může převzít úkol? Která akce čeká na schválení? Kde je záznam rozhodnutí? Co je čtení a co změna stavu? To nejsou nudné okraje produktu. To je produkt, pokud má agent pracovat mimo izolovanou ukázku.

Nejsme ve fázi zázračných pracovníků, ale provozních pravidel

Stojí za to dodat střízlivost. Většina zmíněných projektů je raná, některé mají málo hvězdiček, část tvrzení pochází přímo od autorů a ne z nezávislých testů. To nevadí, pokud je čteme správně. Nejsou důkazem, že agenti právě převzali kanceláře. Jsou signálem, kudy se posouvá vrstva kolem modelů: od samotné odpovědi k terminálu, prohlížeči, paměti, handoffu a dohledu.

Iimos, další dnešní rychlá zpráva, jde ještě odvážněji: podle README se aplikace může měnit sama, včetně UI, serveru, nástrojů a systémového promptu, s lokálním uložením kódu a rollbackem při neúspěšném startu. Jako experiment je to fascinující. Jako pracovní princip je to připomínka, že čím víc nástroj umí měnit vlastní prostředí, tím víc potřebujeme hranice mimo něj. Snapshot před bootem je dobrý začátek. Neodpovídá ale sám o sobě na otázku, kdo schvaluje směr změny.

Jestli má mít tahle vlna agentických nástrojů smysl, neměla by soutěžit jen v tom, kdo pustí model k dalšímu tlačítku. Měla by soutěžit v lepší provozní disciplíně: čitelných oprávněních, auditním záznamu, jasném předání práce, bezpečném zastavení a rozumném rozlišení mezi návrhem a skutečnou akcí. Agent bez takové vrstvy je rychlý brigádník s klíči od skladu a špatnou pamětí. Agent s dobrou provozní vrstvou může být nudnější na ukázce, ale mnohem použitelnější v reálné práci.

Proto mě dnešní sada malých projektů zajímá víc než další prohlášení o „autonomii“. Neukazuje hotovou budoucnost. Ukazuje dílnu, ve které se teprve vyrábějí zarážky, štítky, záznamy a nouzové vypínače. A právě ty rozhodnou, jestli AI agenti budou lidem skutečně pomáhat s prací, nebo jen rychleji vytvářet situace, které po nich bude muset někdo uklízet.

Radyz

Radyz publikuje komentáře a praktické texty o AI nástrojích, ChatGPT, Claude a dění kolem OpenAI a Anthropicu. Na webu se soustředí na srozumitelný výklad, vlastní zkušenost a důraz na to, co je pro čtenáře skutečně užitečné.