Následující text je odvozený z přednášky prezentované 20.4.2026. Vznikl automatickým přepisem v Teams, byl shrnutý po třetinách, pomocí tří paralelních subagentů v GPT Codex (GPT 5.4), aby žádný subagent načtením přepisu a napsáním výstupu nepřekročil velikost kontextu a nemusel ho komprimovat. Následně byly texty spojené za sebe, a ručně upravené do čitelnější podoby. S ohledem na délku textu v něm určitě zůstaly i po kontrole různé fráze, co naznačují, že to psal umělák, i navzdory použití upraveného HumanizerCzech skillu, co to má omezit :-)
Od běžného chatu k agentnímu režimu
Kam se práce s umělou inteligencí posunula za poslední tři roky? Od prostého chatu v prohlížeči k skillům, agentům a týmům agentů. Zatímco dřívější použití stálo hlavně na zadávání dotazů do ChatGPT nebo podobných služeb, dnes se stále víc prosazuje agentní režim. Ten se objevuje ve více podobách: v editorech zdrojového kódu, v příkazové řádce i v samostatných desktopových aplikacích. Společným znakem je, že model už jen negeneruje text, ale dostává možnost něco aktivně provádět – číst soubory, spouštět příkazy, zapisovat změny nebo procházet projekt.
Dnes lze provozovat i pokročilejší platformy pro orchestraci více agentů, dlouhodobou paměť a napojení na externí služby. Právě tady ale s rostoucí schopností systému roste i riziko. Čím blíž se agent dostává k reálnému prostředí uživatele, tím důležitější je rozumět tomu, co dělá, jaké má pravomoci a kde jsou hranice jeho bezpečného nasazení.
Zásadní rozdíl proti webovému chatu je v tom, že agent běžící v lokálním nástroji má přístup k disku a k příkazům operačního systému. V prohlížeči je model do velké míry omezený prostředím služby, zatímco v agentním režimu se z něj stává nástroj, který může do projektu skutečně zasahovat. To přináší vyšší produktivitu, ale i nutnost průběžné kontroly.
Tokeny, čeština a praktické limity kontextu
Je potřeba rozumět tomu, co jsou pro AI modely tokeny a kontextové okno modelů. Modely nepracují s textem tak, jak ho čte člověk, ale s tokeny. U praktické práce je podstatné, že čeština bývá proti angličtině zhruba jedenapůl až dvojnásobně náročná. Stejný obsah tedy v češtině spotřebuje víc kontextu i peněz. To je důležité nejen při samotném psaní, ale i při návrhu instrukcí, dokumentace a pracovních postupů. Pokud člověk umí anglicky a nepotřebuje český výstup, je rychlejší a efektivnější komunikovat a dostávat výstupy anglicky.
Na historickém srovnání se ukazuje, jak se sice velikost kontextového okna výrazně zvětšila, ale problém nezmizel. Dříve modely zapomínaly po několika tisících tokenů, dnes se pracuje se statisíci nebo milionem tokenů. Ani velké kontextové okno však neznamená, že model dlouhému vláknu skutečně rozumí stejně dobře od začátku do konce. Jakmile se kontext plní, klesá spolehlivost vybavování konkrétních detailů. Je to jako hledání jehly v kupce sena: informace může být v kontextu stále přítomná, ale model ji už nemusí spolehlivě najít.
Když se kontext zaplní, model se ho snaží komprimovat. Starší obsah shrne do kratší podoby, aby uvolnil místo pro další práci. Tím ale nevyhnutelně dochází ke ztrátám. Některé souvislosti zmizí, některé detaily se zjednoduší a roste riziko chyb nebo halucinací. Z toho plyne praktický závěr: není výhodné kontext bez rozmyslu plnit. Laická představa, že čím víc toho model „ví o nás a o projektu“, tím bude chytřejší, neplatí bez výhrad. Od určitého bodu začíná dlouhá historie spíš škodit.
Dalším tématem je cena. U placených služeb se spotřeba neodvíjí jen od toho, co uživatel napíše a co dostane zpět. Významnou část nákladů tvoří i interní zpracování, zejména reasoning tokeny a veškeré čtení souborů, webových stránek nebo dalších zdrojů. Pokud má agent udělat rešerši, stáhnout více webů nebo analyzovat větší soubory, lze stovky tisíc tokenů spotřebovat velmi rychle. Limity tarifů se obvykle sledují v několika časových oknech, například pěti hodinové, denní a týdenní.
Proč je nutné rozumět shellu a co umí Rust Token Killer
Jakmile agenti přecházejí od chatu k činnostem nad soubory a projektem, začínají na pozadí používat příkazovou řádku. Na Windows typicky PowerShell, na Linuxu a macOS shellové příkazy. Uživatel nemusí znát všechny detaily, ale je důležité rozumět aspoň základům. Pokud má člověk schvalovat příkaz, kterým agent maže, kopíruje nebo přesouvá soubory, musí být schopen odhadnout, co ten příkaz skutečně provede. Jinak nemá reálnou kontrolu a „human in the loop“ zůstává jen formální.
Právě tady se ukazuje i bezpečnostní rovina. Jediný špatně zadaný znak může změnit neškodný příkaz v destruktivní operaci (Smazání všech disků na Linuxu a Macu bez jakéhokoli dotazu: rm -rf /, smazání všech souborů uživatele stačí nahradit / za ~ atd.). Ve webovém chatu podobné riziko obvykle nevzniká, protože prohlížeč nemá přímý přístup k lokálnímu disku. Lokální agentní nástroj ale může mít oprávnění, která už vyžadují opatrnost srovnatelnou s běžnou administrací systému.
Na problém nadměrné spotřeby kontextu při práci s příkazy je efektivní používat nástroj Rust Token Killer (RTK). Jeho smyslem není měnit logiku práce agenta, ale zkrátit výstupy některých běžných příkazů ještě předtím, než se dostanou do kontextu modelu. Typickým příkladem je výpis adresáře. Člověk v něm možná ocení metadata, práva, časová razítka a další detaily, ale model pro základní orientaci často potřebuje jen seznam položek. Pokud se odstraní nadbytečná část výstupu, šetří se tokeny bez ztráty užitečné informace.
Takové zkracování u běžných workflow může ušetřit významnou část spotřeby, zvlášť když agent opakovaně prochází projekt, otevírá složky a analyzuje strukturu souborů. Neplatí to pro všechny situace. U čistého textového souboru, který je třeba skutečně přečíst celý, není moc co komprimovat. Jde tedy o praktický optimalizační nástroj pro konkrétní typy operací, nikoli o univerzální řešení.
Systémové prompty, projekty a selektivní načítání skillů
Další problém vzniká už na úrovni instrukcí, které model dostává automaticky. Uživatel si může nastavit globální styl komunikace nebo vlastní pokyny (Custom prompt v ChatGPT apod., nebo globální AGENTS.md soubor), což je pohodlné, ale vše se pak načítá do každé konverzace. Instrukce, které dávají smysl v programátorském úkolu, jsou zbytečné v úplně jiném kontextu, a přesto pořád zabírají místo. Projektové instrukce jsou lepší než globální nastavení, protože se vážou jen k určité oblasti práce. Ani to ale nestačí, pokud jeden projekt zahrnuje řadu různých činností.
Jako udržitelnější řešení představuje koncept skillů. Skill je markdownový soubor v jasné složce projektu nebo globálně skills/NazevSkillu/SKILLS.md s metadaty v YAML frontmatteru, kde je stručně popsáno, co skill dělá a kdy se má použít. Klíčová výhoda spočívá v tom, že model nemusí načítat celý obsah všech skillů předem. Nejprve si přečte jen krátký popis a až ve chvíli, kdy je skill relevantní nebo je výslovně vyvolán, načte si jeho plné zadání. Díky tomu lze mít k dispozici více specializovaných instrukcí bez toho, aby všechny neustále zatěžovaly kontext.
Tento princip lze ilustrovat na skillu pro „humanizaci“ češtiny. Čeština bývá v generovaných textech nápadná řadou opakujících se vzorců, a proto vznikají specializované instrukce, které mají takové projevy potlačit. Současně ale tento skill je trochu nešťastný, protože je příliš dlouhých. Pokud má skill desítky tisíc znaků a navíc vede model k tomu, aby nejprve vytvořil nepovedený text a až potom ho přepisoval, spotřeba tokenů zbytečně roste. Lepší cíl je naučit model psát kvalitně hned v prvním kroku a používat co nejkratší, přesně formulované instrukce.
Se skilly souvisí i práce po projektech. Agent má přístup jen k určité složce, kterou uživatel otevře a schválí jako pracovní prostor. To je praktická jednotka, v níž se kombinuje kontext projektu, lokální oprávnění a případné specializované instrukce. Pracovní prostor se otvírá zpravidla jako sandbox, ale izolace není nikdy zaručena. Pokud agent běží na stejném operačním systému jako ostatní programy, izolace má limity a nelze ji brát jako neprůstřelnou ochranu pro citlivá data. Celý repozitář nebo i data mimo něj dokáže hloupý model nebo záměrně škodlivá instrukce (prompt injection) během okamžiku smazat.
MCP servery: silný nástroj, vysoká cena a nové riziko
Stejnou logikou jako dlouhé systémové prompty zatěžují kontext také MCP servery. Jde o protokol a standardizovaný způsob, jak agentovi zpřístupnit externí služby a aplikace. Může jít o Microsoft Teams, Excel, SharePoint, e-shop (např. Rohlík.cz) nebo lokální systémovou službu. Agent pak s danou službou nepracuje klikáním v grafickém rozhraní, ale přes rozhraní, které složité operace převádí na srozumitelné textové příkazy a odpovědi.
Příklady: takový server může být mimořádně užitečný. Agent může zjistit seznam kanálů v Teams, poslat zprávu, připravit objednávku v e-shopu nebo ovládat jinou firemní službu. Stejný princip lze použít i lokálně, například pro tisk. Uživatel by mohl nadiktovat požadavek a agent by přes lokální MCP službu zajistil tisk dokumentu nebo zpracování výstupu z porady.
Hlavní problém je v tom, že mnohé implementace načítají schopnosti MCP serveru už při startu konverzace. Agent si vyžádá seznam dostupných funkcí, jejich parametry a formáty odpovědí. Pokud je serverů více a každý vrací rozsáhlou specifikaci, spolyká to velkou část kontextového okna ještě před prvním skutečným úkolem. Náklad tak nevzniká jen při použití serveru, ale už při jeho samotném připojení.
Vedle ceny a spotřeby kontextu je tu i bezpečnost. Nedůvěryhodný MCP server může být cestou k prompt injection nebo k exfiltraci dat. Pokud agent slepě přijme instrukce obsažené v odpovědi serveru, může předat dál přístupové klíče, hesla nebo jiné citlivé informace. Rizikem je i to, že uživatel službě svěří přihlášení k firemním účtům. Bezhlavé připojování cizích MCP serverů lze považovat za jednu z nejkratších cest k bezpečnostnímu průšvihu.
Navržené řešení je podobné jako u skillů. MCP server se nemá načítat plošně, ale až ve chvíli, kdy ho konkrétní úkol opravdu potřebuje. Ideální je, když je spuštění serveru součástí specializovaného skillu. Pak se například server pro objednávky aktivuje jen při nákupu a nikoli v každé konverzaci. Tím se šetří tokeny, zmenšuje plocha útoku a roste přehled o tom, proč se která externí schopnost právě používá.
Lokální agent, webový chat a otázka důvěry
Jaké je srovnání webového chatu s lokálním agentním prostředím? Webová varianta umí část úloh řešit v cloudovém sandboxu, například spustit Python nad nahranými daty někde u poskytovatele typu OpenAI, a vrátit graf nebo soubor. To je užitečné, ale stále omezené. Model nemá přímý přístup k lokálním datům, každý soubor je třeba výslovně nahrát a prostředí je dočasné a nemá dostupné všechny možné programy, moduly atd.
Lokální agent naproti tomu může číst a zapisovat v pracovním adresáři, spouštět programy a obecně zasahovat do prostředí počítače. Z pohledu produktivity je to mnohem silnější nástroj. Z pohledu správy rizik je ale nutné počítat s tím, že samotné systémové instrukce nebo sandbox nemusejí vždy stačit. Pro citlivější práci proto je vhodné uvažovat i o odděleném prostředí, například o virtuálním stroji (VirtualBox, virt-manager, Hyper-V) nebo dokonce vyhrazeném fyzickém stroji (lze použít i starší počítač, pokud stejně AI model používáme cloudový v rámci předplatného).
Jak na tom jsou tarify u jednotlivých produktů: NMarketingové názvy jsou nejasné a není dobré zaměňovat různé produkty označené jako Copilot, kde to je asi 80 věcí od Microsoftu nebo Githubu. Důležitější než značka je v praxi to, jaký má nástroj limit, kolik stojí, jak hospodaří s tokeny a jaké pravomoci dostává vůči projektu a souborům. Claude Code od Anthropicu propálí 20dolarový limit základního předplatného téměř okamžitě, GPT Codex od OpenAI se stejně drahým předplatným aktuálně (4/2026) vydrží mnohem déle.
Proč má Markdown v práci s AI zvláštní význam
Proč je důležité rozumět Markdownu? Není to jen textový formát pro psaní poznámek, ale jde o praktický pracovní jazyk pro dokumentaci, instrukce i spolupráci s modely. Markdown je čistý text s jednoduchou strukturou, dobře čitelný pro člověka i stroj a neobsahuje zbytečnou výplň typickou pro složitější formáty (HTML, nebo dokonce DOCX, ODT, OneNote). Právě to je v kontextu práce s tokeny podstatné.
Ve srovnání s HTML nebo s uzavřenými dokumentovými formáty je Markdown úspornější. Obsahuje informaci o struktuře, například nadpisech, odrážkách nebo odkazech, ale bez velkého množství technických značek navíc. Model se tak snáz soustředí na obsah a neplýtvá tokeny na čtení balastu. To vysvětluje, proč se Markdown stal běžným formátem v open source projektech, na GitHubu, a proč se hodí i pro definici skillů, README dokumentaci nebo interní poznámky.
Je doporučené, aby si lidé práci s Markdownem osvojili. Není nutné psát vše ručně, existují editory, které formátování usnadňují (Obsidian, VS Code, nově to umí i Microsoft ve webovém rozhraní OneDrive a Sharepointu). Důležité je spíš pochopit, že jde o přenositelný a dlouhodobě použitelný formát. Dokumenty v Markdownu lze snadno číst v různých nástrojích, předávat mezi systémy a přímo používat jako vstup pro AI.
Obsidian jako vhodné prostředí pro poznámky a pracovní paměť, Markdown, práce se znalostmi
Na to už přímo navazuje doporučení používat pro poznámky nástroje, které ukládají data právě v Markdownu. Ideálním v tomto je Obsidian. Přirovnat ho jde k poznámkovému bloku nebo k alternativě k Microsoft OneNote, ale s důležitým rozdílem: data nejsou uzavřená v proprietárním formátu. Jsou to běžné markdownové soubory, se kterými lze pracovat i mimo samotnou aplikaci, klidně v obyčejném Poznámkovém bloku Windows.
To je výhodné jak pro člověka, tak pro umělou inteligenci. Poznámky je možné otevřít v různých editorech, verzovat, propojovat odkazy a v případě potřeby je dát agentovi k dispozici pro čtení nebo zápis. Obsidian navíc umí nabídnout pohodlné grafické rozhraní, takže uživatel nemusí znát celou syntaxi Markdownu zpaměti. Jde o praktický základ osobní i týmové znalostní báze, která je dobře použitelná i v době agentních workflow.
Praktická vlastnost, která je pro práci s AI důležitější než samotné rozhraní aplikace: poznámky jsou obyčejné soubory na disku. Obsidian nad nimi staví pohodlné prostředí, možnost vizualizovat graficky vztahy a hypertextové propojení souborů, metadat v yaml frontmatteru atd., ale uživatel není vázaný na konkrétní cloudovou službu ani na jediný program. Pokud nechce používat placenou synchronizaci Obsidianu, která je pohodlná a řadě lidí se vyplatí, může stejnou složku ukládat třeba přes OneDrive, ownCloud, Google Drive nebo Dropbox, a soubory otevřít i mimo Obsidian, klidně ve webovém editoru nebo v jednoduchém textovém editoru na jiném počítači. Právě to z něj dělá vhodný základ pro propojení s agentními nástroji.
Lze si napsat jednoduchý skill, který po dokončení úkolu automaticky zapisuje stručný denní záznam do jediné vyhrazené složky. Zápis se ukládá po dnech a v rámci dne po projektech, takže se dají zpětně dohledat domluvy, provedené změny, hotové body i rozdělaná práce. Smyslem není ukládat poznámky rozptýleně do každého projektu zvlášť, ale naopak mít na jednom místě průběžný pracovní deník napříč všemi projekty. Takový přehled pak jde jednou za týden znovu projít a nechat si shrnout, kde se něco zastavilo nebo co zůstalo nedokončené. Důležitý je i bezpečnostní rámec: agent má právo zapisovat jen do určené složky, ne do osobních poznámek. Kromě skillů lze v Claude Code nebo nejnovějších verzích Codexu použít i automatický hook, co řeší problémy s překročením sandboxu projektu, v kterém se pracuje.
Na tomto příkladu se ukazuje širší princip. Markdown se stal společným pracovním formátem současného AI ekosystému, protože se v něm dobře píše, snadno se čte strojově i lidsky a lze nad ním budovat další pravidla. Sofistikovanější workflow pak nestojí jen na jednom promptu, ale na sadě skillů, které agentovi přesně určují strukturu zápisu, povolené činnosti a způsob práce s poznámkami. Tím se z běžného textového souboru stává stabilní paměť projektu.
Převod do jiného formátu a proč nechat syntaxi na nástrojích
Z markdownu udělat výstup pro jiný systém, konkrétně třeba pro již dlouho existující firemní wiki, co používá vlastně dost podobnou, ale jinou syntaxi (zde Dokuwiki, ale může to být např. Mediawiki, na které běží Wikipedia). Základní doporučení zní psát primárně v markdownu a až na konci provést převod do cílového formátu specializovaným nástrojem, konkrétně u konverze Markdown -> Dokuwiki je na to vhodný nástroj pandoc. Výhoda je zřejmá: AI model píše v prostředí, které zvládá spolehlivě, a převod obstará nástroj, který je na to určený. Lze samozřejmě naučit model psát dobře i např. Dokuwiki syntaxi, ideálně formou specializovaného SKILLu, ale je to někdy méně spolehlivé, než použít tradiční nástroje, co to už umí dobře a nevyžadují na to ani pálení AI tokenů.
Přímé generování méně běžné (doku)wiki syntaxe je ze zkušenosti spíš nespolehlivé. Modely si formáty pletou, míchají různé značkovací jazyky a chybují i v případech, kdy je syntaxe veřejně zdokumentovaná. Situaci navíc komplikuje to, že řada webů dnes chrání dokumentaci před automatizovaným stahováním, takže model nemusí mít snadný přístup ani k aktuálním pravidlům. Pokud je nutné, aby AI psala v konkrétním specializovaném formátu, je možné jí požadovanou syntaxi přiložit přímo do projektu jako referenční soubor např. do adresáře docs/ a odkázat na to v AGENTS.md, jiných pravidlech nebo skillech.
Git jako základ práce na skriptech a automatizaci
Ve chvíli, kdy práce s AI přestane být jen jednorázovou textovou konzultací a začne zahrnovat skripty, automatizace nebo úpravy kódu, naráží se na potřebu verzování. Bez základní orientace ve verzovacím nástroji git se dnes podobná práce dělá velmi těžko. Git je prakticky nezbytný proto, že umožňuje vracet se ke starším stavům, sledovat historii změn a seskupovat související úpravy do smysluplných celků.
Na příkladech z VS Code lze ukázat, že uživatel nemusí od prvního dne znát desítky příkazů. Důležité je pochopit princip: v projektu existují soubory se změnami, ty lze prohlížet, zahodit nebo potvrdit do commitu a každý commit má mít srozumitelný popis. Rozhraní editoru ukazuje změny přehledně barevně, podobně jako jiné systémy pro schvalování obsahu (např. již používáaná Dokuwiki). Zásadní rozdíl je ale v tom, že Git nepracuje jen s jedním souborem, nýbrž s logickým balíčkem změn napříč více soubory. To je podstatné při větších úpravách, refaktoringu nebo opravách, které musí držet pohromadě.
Git má význam i tehdy, když na projektu pracuje jediný člověk. Jakmile totiž agent dostane oprávnění něco přepisovat, je velmi snadné dostat se do stavu, kdy nová verze něco rozbije a bez historie už není jasné proč. Pokud jsou změny průběžně commitované, dá se vrátit ke staré podobě, porovnat ji s novou a nechat agenta hledat rozdíl mezi funkčním a nefunkčním stavem. Starou a novou verzi lze spustit vedle sebe a nechat systém analyzovat, kde se chování rozešlo. Bez verzování by se podobné hledání rychle změnilo v ruční improvizaci se složkami typu „záloha 2026-04-20“, což je sice možné, ale málo přehledné a špatně škálovatelné a žádný profesionální softwarový vývoj tak (snad) neprobíhá.
Význam má psát přehledné commit messages a na to, že technická dokumentace i komentáře ve zdrojových kódech má smysl psát anglicky, pokud existuje šance, že se k projektu dostane někdo mimo české prostředí. Ukázkou suboptimálního stavu je pokus navázat na vývoj již neudržovaného starého Dokuwiki pluginu s francouzskými komentáři i popisy commitů. Pro interní uživatelské rozhraní může být čeština v pořádku, ale technická vrstva má být co nejpřístupnější i lidem zvenčí.
GitHub
Na Git navazuje GitHub jako webová vrstva nad repozitáři. Je to dnes nejrozšířenější platforma pro distribuci otevřeného softwaru i praktický domov pro neveřejné osobní či firemní repozitáře. Pro uživatele je důležité, že nabízí zálohování mimo lokální počítač a pohodlnější rozhraní než čistá příkazová řádka: soubory lze prohlížet, editovat a v omezené míře spravovat i přes web. Tím se snižuje vstupní bariéra pro lidi, kteří zatím nemají jistotu v terminálu.
Vibecoding
Na příkladu starých pluginů pro dokuwiki lze ilustrovat, že dnes existuje i třetí cesta, která donedávna nebyla myslitelná bez profesionálního vývojáře po ruce: buď se neudržovaný plugin přestane používat, nebo se firma smíří s tím, že kvůli němu neaktualizuje celý systém a ten bude mít bezpečnostní zranitelnosti atd. Třetí možnost, kterou umožňuje až kvalitní agentní AI v poslední době, je tolik skloňovaný vibecoding, tj. vzít zdrojový kód do vlastní správy, a s pomocí AI ho adaptovat na novější prostředí (např. major verzi Wiki s novým API, novější verzi PHP, databázového engine apod.). Aby to ale bylo bezpečně zvládnutelné, je potřeba mít historii změn, vidět cizí commity z minulých let a rozumět tomu, co se v projektu postupně dělo a pustit se do práce.
Rozdílné nástroje, shell a bezpečnostní hranice
Přestože se agentní nástroje (Claude Code, GPT Codex, Github Copilot CLI, Gemini CLI) v posledních měsících postupně sbližují, stále mezi nimi nejsou zanedbatelné rozdíly. Liší se syntaxe pro volání agentů, způsob spouštění skillů i konkrétní integrace. Člověk proto nemá čekat úplnou zaměnitelnost, i když se postupně rýsují společné vzory. Uživatel musí rozumět alespoň základům shellu a vědět, co znamenají příkazy, které agent navrhuje spustit v nějakém shellu (Windows: cmd nebo Powershell, Linux: bash, Mac: zsh). Human-in-the-loop přestává dávat smysl ve chvíli, kdy člověk všechno pouze mechanicky potvrzuje, aniž by tušil, co se má stát.
Agent neusiluje o dodržení lidského záměru v úzkém smyslu, ale o splnění cíle. Když mu jedna cesta nefunguje, má tendenci hledat jinou. Zakázat jeden konkrétní příkaz (např. smazání souboru pomocí rm) proto problém neřeší – agent si může napsat skript např. v Pythonu, použít jiný nástroj nebo obejít překážku jiným prostředkem. Jdou už medializované případy nejnovějšího Claude modelu Mythos, které se ze sandboxu dostaly ven pomocí kombinace více zranitelností. Stoprocentně bezpečný způsob, jak agentní workflow provozovat, dnes neexistuje.
Ani izolace do virtuálního stroje není všelék. Čím lépe je prostředí uzavřené, tím méně má agent přístup k datům, systémům a přihlašovacím údajům, které potřebuje pro reálnou práci. Pokud má testovat automatizaci nad firemními instrukcemi, databází, VPN, wiki nebo cloudovým úložištěm, musí k nim nějak získat přístup. Tím se ale bezpečnostní hranice znovu otevírá. Neexistuje jednoduché řešení jak efektivně a zároveň bezpečně tyhle nástroje používat. Kdo chce tyto nástroje používat, musí počítat s novou úrovní rizika, dělat zálohy a učit se porozumět tomu, co agentům dovoluje.
Omezená je i představa, že bezpečnost vyřeší korporátní smlouva s poskytovatelem AI služeb, kde je něco napsané v podmínkách. Ten může smluvně ošetřit, že poskytovatel nebude data používat k trénování modelu, ale neřeší škody, které agent může napáchat lokálně na počítači nebo v připojených systémech. Kriticky je potřeba vnímat, jak jsou podobné funkce integrovány přímo do operačních systémů, zejména Copilot ve Windows, ale je to i na Androidu, iOS a Mac OS. Když výrobce současně nabízí agentní nástroj jako prostředek produktivity a v podmínkách se odvolává na to, že jde jen o experimentální nebo zábavnou funkci bez záruk, přenáší tím praktické následky na uživatele a správce. Příklady z nedávné doby: Copilot v Poznámkovém bloku Windows nebo v Malování.
Projektová paměť, PLANS.md, MEMORY.md a subagenti
Jak k organizaci práce s agenty v průběhu času?. Není rozumné spoléhat na staré chatové konverzace ani na obecnou paměť služby typu ChatGPT nebo Claude. Důležité dohody, rozhodnutí a průběžný stav projektu je potřeba zapisovat do souborů uvnitř projektu nebo do navázané znalostní báze. Obecně lze používat soubor AGENTS.md, který agenti čtou automaticky jako sadu pravidel pro práci v daném repozitáři (u Claude je potřeba doplnit symlink z CLAUDE.md.), zatímco README.md je určený hlavně lidem.
Vedle toho je dobré dát agentům pravidlo vytvářet PLANS.md, kde je rozpad práce na konkrétní kroky. Agent má jednotlivé body odškrtávat až ve chvíli, kdy je opravdu splní. Tady se znovu ukazuje důležitost dobře navržených skillů: bez nich má model tendenci oznámit hotovo příliš brzy, protože výsledek vypadá plausibilně, i když nebyl ověřený. Správný postup proto zahrnuje i testování a kontrolu funkčnosti před uzavřením úkolu.
Další vrstvu tvoří MEMORY.md nebo obdobný stručný soubor, do něhož se ukládá stav projektu, otevřené otázky a kontext potřebný pro pozdější navázání. Výhoda je dvojí. Jednak lze po týdnu rychle navázat bez dlouhého vysvětlování, jednak se tím otevírá možnost plynule přecházet mezi různými AI nástroji a modely. Pokud mají všechny přístup ke stejné sadě markdownových poznámek a znají pravidla zápisu, není uživatel tolik závislý na jednom poskytovateli ani na jediné dlouhé konverzaci.
Zásadní rozhodnutí o směřování projektu je dobré nechat agenty dokumentovat nebo ručně psát ve formě číslovaných nebo chronologických ADR, Architecture Decision Records, do adresáře docs/decisions, odkud je opět možné kdykoli v budoucnu navázat a pochopit, proč je projekt nyní v takovém stavu, jakém je.
Mocným nástrojem jsou subagenti s vlastním kontextovým oknem. Smyslem je rozdělit práci mezi specializované role, aby se v jednom vlákně nemíchaly bezpečnostní otázky, architektura, dokumentace nebo kritická oponentura. Každý subagent dostane vlastní zadání, pracuje s čistým kontextem a vrátí strukturovaný výstup. Hlavní orchestrátor pak odpovědi spojí, případně zadá další kolo. Je to technicky náročnější, ale mimořádně silný způsob práce, který otevírá cestu k council systémům a týmům specialistů.
Doporučený balík councilových skillů a definovaných agentů: forge-council: https://github.com/N4M3Z/forge-council
Council: Orchestrace subagentů a rozdělení práce mezi modely
Jak lze z jednoho hlavního agenta udělat koordinátora menšího týmu specializovaných subagentů?
Projekt forge-council to řeší sofistikovaně a přitom pouze pomocí dobře napsaných Markdown souborů SKILLů a dalších Markdown souborů definující persony jednotlivých subagentů.
Příkladem na softwarový vývoj je DeveloperCouncil: Každý ze subagentů dostává vlastní, úzce vymezený úkol, pracuje s vlastním kontextem a po prvním kole vrací výsledek zpět. Tyto dílčí odpovědi se potom rozešlou znovu všem zúčastněným agentům, kteří v dalším běhu reagují nejen na původní zadání, ale i na výstupy ostatních. Tím vzniká řízená vícekolová debata, v níž se jednotlivé role navzájem doplňují a korigují.
Podstatné je, že pro různé role není nutné používat stejný model ani stejnou úroveň uvažování. Náročnější koordinaci může vést silnější model (např. Opus nebo GPT 5.4), zatímco jednodušší vyhledávání na webu, čtení dokumentace nebo dílčí klasifikace mohou obstarávat levnější a menší modely (např. Sonnet nebo GPT 5.4-mini). V praxi není a nebude ekonomické nasazovat nejdražší modely na každou drobnost. Pokud má subagent jasně vymezený úkol, krátký kontext a přesně určený formát odpovědi, může i starší nebo levnější model odvést použitelnou práci.
Tato modularita je důležitá i z ekonomického hlediska. Skutečná hodnota agentního přístupu neleží v jednom univerzálním modelu, ale ve vhodném rozdělení rolí, nákladů a odpovědností. Hlavní agent funguje jako vedoucí, který zadává úkoly, čeká na návraty jednotlivých specialistů a rozhoduje, co se bude dít dál. Kvalita výsledku pak nezávisí jen na samotném modelu, ale hlavně na tom, jak dobře jsou role definované a jak pečlivě je navržené jejich řetězení.
Skilly, role a textové definice jako praktický základ agentů
Současný pokrok v agentním zpracování nestojí na nějakém skrytém technickém kouzlu, ale do značné míry na dobře připravených textových souborech. Ve složkách se dají udržovat skilly i definice agentů, obvykle v markdownu nebo podobně jednoduchém formátu. V nich je stručně a přesně popsáno, kdy se má daný agent použít, jaký model má dostat, jak hluboké má mít uvažování, na co se má soustředit a co naopak řešit nemá.
Na příkladu vývojářského specialisty (persona – subagent SoftwareDeveloper z forge-council projektu) je dobře vidět, proč je takové omezení důležité. Pokud má agent hodnotit software, má se držet právě vývojářské perspektivy a nemá současně suplovat testera, databázového architekta ani dokumentačního specialistu. Užitečný agent není ten, který se vyjadřuje ke všemu, ale ten, který se spolehlivě drží svého úkolu. Stejný princip se opakuje i u dalších rolí, například u českého právního poradce (CzechLawAdvisor) zaměřeného na pracovní právo nebo u datového analytika (DataAnalyst). Každá role má vlastní pravidla, vlastní záběr a vlastní omezení.
Hlavní agent tyto podrobné instrukce nemusí znát celé. Zpravidla jen ví, koho má zavolat, s jakým zadáním a v jakém formátu čekat odpověď. Samotné detaily role zůstávají uvnitř daného subagenta. O subagentovi ví hlavní agent pouze základní metadata přítomná v úvodním YAML frontmatteru na pár řádků. Celý popis role subagenta si přečte až nově spuštěný subagent. Tím se šetří kontext i tokeny a zároveň se zvyšuje přehlednost celého systému. Je to zásadní paradigmatický i kvalitativní posun, kdy se z jednoduchého chatování stává strukturovaný provoz malých specializovaných programů, které lze nad sebou skládat a kombinovat.
Prompt engineering včera a dnes
Z této logiky vychází i důraz na prompt engineering. Není pravda, že by přestal být potřebný. Jen se přesunul z jednorázového psaní dlouhých promptů v chatu webu ChatGPT k pečlivému návrhu opakovaně použitelných instrukcí v Markdown formátu s YAML frontmatter metadaty, a tzv. „lazy-loading“ celých rolí a skillů jen tam, kde to je potřeba, a až to je opravdu potřeba.
Demo na projektu výrobního záznamníku
Praktická ukázka: nově rozpracovaný projekt, jehož cílem je digitalizovat evidenci výrobních dávek. Současný stav vypadá asi takto: ruční zápisy do tabulek na vytištěných technologických postupech, které se následně ukládají do šanonů. Data tedy existují, ale nejsou systematicky uložena v databázi a obtížně se dohledávají. Záměr je vytvořit jednoduchou webovou aplikaci, zpočátku opřenou o SQLite, s možností pozdější migrace na plnohodnotnou SQL databázi na serveru.
S touto úvodní představou lze vytvořit adresář nového projektu a v něm spustit DeveloperCouncil – vývojářskou radu agentů, aby se rozpracoval vznikající architektonický návrh. V okně GPT Codex lze po zadání vidět, jak systém čte README, plány, paměť projektu a další soubory, přičemž pomocí RTK omezuje množství tokenů spotřebovaných na technické příkazy.
Výsledek prvního kola není prezentován jako hotové řešení, ale jako podklad pro další rozhodování. Agenti odhalují nesoulad mezi dříve uvedenou volbou databáze a nově formulovaným plánem. Z jejich pohledu nejde jen o technickou drobnost, ale o dokumentační rozpor, který je třeba ujasnit dřív, než se začne něco implementovat. Právě v tom je přínos podobné orchestrace: systém nepíše bezhlavě další kód, ale dokáže zastavit a upozornit na místo, kde si projekt sám protiřečí.
Když se doplní další kontext a požádá o návrh Minimal viable product, agenti navrhnou další architektonické kroky. Zazní i doporučení nepřistupovat k databázi přímo, ale přes abstrakční vrstvu, aby šlo později snadno typ databáze nahradit za jiný. I na takovouto práci ale uživatel musí rozumět aspoň základům toho, co čte. Pokud nerozezná, jestli je dané doporučení rozumné, nebo zbytečně složité, samotná agentní rada ho nespasí. Nástroj pomáhá, ale nerozhoduje za člověka.
Na konci ukázky agent žádá oprávnění zapisovat mimo sandbox, konkrétně do poznámkového systému Obsidian, co je v úplně jiném adresáři na disku mimo projekt. Codex ukazuje příkazy, co plánuje spustit a žádá o povolení to udělat. Rozhraní sice popisuje, co chce provést, ale uživatel by měl mít aspoň základní představu o tom, co daný příkaz znamená. Bez toho se z odpovědného schvalování stává slepé klikání. Agentní nástroje zvyšují schopnosti člověka, ale zároveň kladou vyšší nároky na jeho úsudek.
ADR jako řízená dokumentace rozhodnutí
Zpět k už stručně zmíněným Architecture Decision Records (https://adr.github.io/madr). Je to způsob, jak formálně a přitom úsporně zachytit podstatná projektová rozhodnutí. Nejde jen o technickou dokumentaci pro programátory, ale o širší metodu systematizace. Každý záznam má stručně vysvětlit kontext, problém, zvažované varianty, důvody volby, klady i zápory rozhodnutí a případně také to, kdo se na něm podílel.
Taková dokumentace má několik funkcí najednou. Pomáhá novým lidem pochopit, proč projekt vypadá právě tak, jak vypadá. Zabraňuje tomu, aby se stejné debaty po čase opakovaly bez znalosti předchozích úvah. A zároveň vytváří materiál, se kterým se mohou orientovat i budoucí agenti nebo jiné automatizované nástroje. Smyslem není psát dlouhé slohy, ale stručně a dohledatelně zaznamenat, proč padlo konkrétní rozhodnutí. Perfektně to naplňuje potřeby kladené v rámci celé firmy normou ISO9001.
Asi nepřekvapí, že i účelné a v čase konzistentní formátování ADR si lze značně usnadnit pomocí skillu zaměřeného právě na tvorbu ADR. Člověk může zadat volnější popis problému, zvažovaných možností a výsledné volby a agent z toho připraví standardizovaný záznam. V této podobě už nejde jen o pomůcku pro software, ale o obecně použitelný nástroj pro firemní rozhodování. Podobná struktura dávala smysl i u obchodních, marketingových nebo provozních změn, nejen u vývoje aplikací.
Systematizace poznámek, wiki a Obsidian jako příprava na budoucí práci s AI
Přesuňme se od vysoce technických AI agentů k širší otázce, jak ve firmě ukládat znalosti tak, aby byly později použitelné. Za ideální formát lze dnes považovat již opakovaně zmiňované Markdown dokumenty, sdílené poznámky a nástroje typu Obsidian jako praktičtější základ než roztříštěné soubory ve Wordu po Sharepointu nebo izolované zápisy v OneNotu. Nejde jen o to, že se s markdownem lépe pracuje v nástrojích pro vývoj. Podstatné je i to, že takové soubory lze snadno verzovat, sdílet, prohledávat a případně nad nimi nechat pracovat agenty.
Obsidian je uživatelsky příjemným rozhraním, jak s informacemi v Markdownu pracovat. Dokumenty zůstávají běžnými soubory na disku, je možné je ukládat na sdílené úložiště a budovat mezi nimi odkazy a metadata. To má význam nejen pro lidskou orientaci, ale i pro budoucí strojové zpracování. Pokud má firma jednou pustit AI na obchod, nákup nebo interní procesy, bude mnohem lépe fungovat nad uspořádaným korpusem stručných, konzistentních a propojených dokumentů v Markdown vaultech než nad nahodilou směsí různých formátů na Sharepointu, Onedrivu nebo jakémkoli jiném uložišti.
Stejnou systematizaci by bylo možné dělat i v existující wiki, která má téměř stejné výhody jako Markdown a Obsidian, v některých aspektech (čtení ve webovém rozhraní) je vhodnější, v jiných (agentní přístup k datům bez složitého napojování se na API) méně vhodná, ale pokud se do ní obsah dlouhodobě neukládá a uživatelé preferují např. soubory ve Wordu, Excelu nebo Onenote, jsou veškeré výhody wiki i Obsidianu ryze hypotetické. Skutečná změna proto nespočívá jen v přechodu z jednoho prostředí do druhého, ale v disciplinovaném zapisování rozhodnutí a znalostí napříč firmou. Obsidian nebo sdílené markdowny mohou tento přístup usnadnit, ale nedokážou uživatele k tomu napříč firmou donutit.
Praktické limity nasazení ve firmě
Opakovaně se tak vrací otázka, jak takové nástroje zavádět v prostředí, kde mají lidé různé operační systémy, různou úroveň technické znalosti a často ani nemají odpovídající placené tarify AI modelů, umožňující agentní využití v příkazové řádce (CLI), dedikované desktopové aplikaci nebo vývojovém prostředí (IDE typu VS Code). Bez předplatného nebo placení za tokeny přes API přístup se firma výrazně neposune z bodu, kde si uživatelé povídají s ChatGPT nebo Microsoft Copilot v prohlížeči. Zvlášť při orchestraci skillů a subagentů je spotřeba tokenů znatelná a nejlevnější tarify (zejm. Claude) nebudou stačit.
Je taky rozdíl mezi individuálním experimentováním a firemním provozem. Jedna věc je mít rozběhané agenty invididuálně a v rámci osobního předplatného ChatGPT nebo Claude, druhá je nabídnout něco stabilního širšímu týmu a platit licence a spotřebu AI zdrojů centrálně. Ve firmě navíc nevzniká jen technická otázka, jak to nainstalovat, ale i organizační otázka, kdo to bude spravovat, kdo bude definovat role, kdo bude schvalovat sdílené agenty a jak se bude hlídat bezpečnost promptů a případných cizích skillů.
Další vrstva rizika je samozřejmě pokud si člověk stahuje cizí agenty nebo skilly (např. ten opakovaně doporučovaný forge-council), měl by si je přečíst a ověřit, že neobsahují škodlivé nebo nechtěné instrukce. Tím se téma bezpečnosti vrací i do roviny promptů. Nejde jen o to, zda shellový příkaz smaže soubor, ale i o to, zda textová definice agenta, skillu nebo MCP serveru nevede systém k něčemu, co uživatel ve skutečnosti nechce a o čem ani neví, že se může stát.
Smysluplný mezikrok pro většinu lidí
Plně orchestrální režim s více agenty bude ve firmě realisticky využitelný jen pro malou skupinu technicky zdatných lidí. Pro většinu ostatních je vhodnější mezikrok. Tím může být práce s jednoduššími asistenty v prostředí, které už používají, například v ekosystému Microsoft 365 nebo v běžném placeném chatu. Smyslem není hned každého učit stavět agentní architekturu, ale nejprve ukázat, jak si vytvořit opakovaně použitelný specializovaný prompt nebo asistenta pro konkrétní agendu.
Pokud už např. na marketingovém odělení existují dobře odladěné prompty pro určitý styl komunikace, je škoda nechávat je uzamčené v nějakém konkrétním účtu ChatGPT. Lepší je převést je do sdílené podoby, ideálně do markdownových souborů a ve formátu standardizovaných SKILLs nebo agentních person, aby je šlo zálohovat, upravovat a používat napříč nástroji. Takový přístup snižuje závislost na jednotlivci, konkrétním účtu a konkrétním poskytovateli AI, a zároveň brání tomu, aby si každý znovu vymýšlel totéž.
Odkazy
- N4M3Z’s forge-council: https://github.com/N4M3Z/forge-council
- Markdown Architecture Decision Records: https://adr.github.io/madr/
- Agent Skills specification: https://agentskills.io
- Claude Code Skills development SKILL: https://github.com/anthropics/claude-code/blob/main/plugins/plugin-dev/skills/skill-development/SKILL.md
- HumanizerCzech SKILL: https://github.com/bejek/humanizer-czech
