Často jsme mluvili o agentních rámcích. LangGraph, CrewAI, AutoGen, různé SDK, smyčka, volání nástrojů, paměť, plánovač, kritik, supervizor. Všechna užitečná slova, proboha. Čím víc se ale dívám na skutečně použité agenty, tím víc se mi zdá, že se zajímavá část posunula pod rámec rámce.

Otázka už nezní jen: kterou knihovnu mám použít, aby krokový model přemýšlel?

Skutečná otázka zní: kde tento agent žije, když přestane být demo?

Protože seriózní agent není funkce, která volá model a vrací text. Je to malý distribuovaný systém. Musí číst kontext, používat nástroje, spouštět kód, dotýkat se souborů, pamatovat si rozhodnutí, žádat o povolení, dobře selhat, restartovat, nechat protokoly, nespálit rozpočet a neproměnit se v buldozer uvnitř produkčního úložiště.

Rámem je volant. Infrastruktura je silnice, brzdy, garáž, pojištění a člověk, který ví, kde jsou klíče.

Protože se o tom teď hodně mluví

V letech 2023 a 2024 byla konverzace velmi zaměřená na model. Která LLM? Kolik kontextu? kolik to stojí? Jak dobrý je v programování?

V letech 2025 a 2026 se konverzace posunula. Modely jsou dost dobré na to, aby dělaly skutečnou práci, ale právě proto se zviditelní nudné kousky: runtime, zabezpečení, konektory, identita, pozorovatelnost, provádění kódu, nasazení, vrácení zpět.

Je to přirozený přechod od magie k inženýrství.

Když agent potřebuje vygenerovat odpověď, stačí chat. Když potřebujete otevřít požadavek na stažení, dotazovat se na databázi, volat CRM, spustit úlohu, procházet web, číst Slack, kompilovat kód a aktualizovat dokument, potřebujete kolem toho operační systém.

Ne v doslovném smyslu. V organizačním smyslu.

První díl: běhové prostředí, kde agent vydrží

Agent často pracuje v krocích. Podívejte se na stav, vyberte akci, použijte nástroj, sledujte výsledek, aktualizujte plán, opakujte.

Pokud tato smyčka žije uvnitř jediného požadavku HTTP, máte okamžitě problém. Některé akce jsou pomalé. Někteří čekají na lidský zásah. Některé selžou a musí se zkusit znovu. Některé musí přežít nasazení nebo časový limit.

Zde přicházejí do hry trvalé pracovní postupy, fronty, pozadí úloh a stavové automaty. Nejsou okouzlující, ale je v nich rozdíl mezi agentem, který vypadá chytře na demu, a agentem, kterého můžete nechat pracovat, když si půjdete dát kávu.

Pro mě musí agentní runtime odpovídat na velmi konkrétní otázky:

• kam uložím stav mezi jedním krokem a druhým?
• co se stane, když proces v polovině skončí?
• mohu se pozastavit a požádat o schválení?
• Mohu si přehrát běh, abych pochopil, proč se tak rozhodl?
• mohu omezit dobu trvání, paměť, nástroje a náklady?

Vercel na této frontě tvrdě tlačí s AI SDK, funkcemi, pracovními postupy a nástroji pro vytváření agentů v rámci webových aplikací. Ale nejde jen o Vercela. Jde o to, že agent potřebuje operační domov, nikoli jeden koncový bod.

Druhý kousek: pískoviště, protože agent se musí umět ušpinit, aniž by se rozbil

Jakmile agent napíše kód nebo provede příkazy, je potřeba sandbox.

Vypadá to jako technické slovo, ale myšlenka je domácí: dáte mu pracovní stůl. Může otevírat soubory, instalovat závislosti, spouštět testy, dělat experimenty, generovat výstup. Pokud to udělá špatně, zadržel jsi poškození. Pokud to funguje, propagujte výsledek.

Agentní karanténa by měla mít některé vlastnosti:

• izolovaný souborový systém;
• CPU, paměť a časové limity;
• řízená síť;
• tajemství namontovaná pouze v případě potřeby;
• kompletní protokoly;
• možnost exportu artefaktů;
• v případě potřeby čistý reset mezi běhy.

Vercel Sandbox jde přesně tímto směrem: izolovaná prostředí pro spouštění kódu, instalaci závislostí, práci se soubory a vytváření artefaktů, aniž by vše běželo v hlavním běhovém prostředí aplikace.

Tato věc je důležitější, než se zdá. Mnoho agentních prototypů skáče přímo z modelu do reálného systému. Model může volat nástroj. Nástroje dokážou věci. Všechno to vypadá elegantně až do prvního špatného příkazu, první závislosti nainstalované na špatném místě, prvního tokenu, který skončí v protokolu.

Pískoviště je způsob, jak říci dospělým: jděte do toho, ale tady.

Třetí část: MCP a problém s konektorem

Protokol kontextu modelu se stal jednou z nejzajímavějších částí ekosystému, protože se snaží standardizovat něco, co se jinak rychle stane neovladatelným: jak model objevuje a používá externí nástroje.

Bez standardu je každá integrace malým ostrovem. Konektor pro GitHub vytvořený jedním způsobem, jeden pro Slack vytvořený druhým, jeden pro databáze s jinou sémantikou, jeden pro automatizaci prohlížeče, která vypadá jako nic.

MCP navrhuje společný jazyk mezi klientem a serverem: nástroje, zdroje, výzvy, autorizace, přenos, zjišťování. Kouzelně to neřeší vládnutí a bezpečnost, ale dává gramatiku.

A na gramatice záleží. Když se agent může připojit k mnoha nástrojům, otázka nezní jen „dokáže to?“. Problém je, "chápe, co může dělat, s jakými limity, jménem koho a zanechávat jakou stopu?".

Pro mě MCP není humbuk, protože „vyvolává nástroje“. Už jsme to udělali. Je to humbuk, protože posouvá těžiště z jednoduché integrace do provozního katalogu nástrojů.

V dobré agentní architektuře se MCP stává jakýmsi patch panelem:

• GitHub pro kód a problémy;
• Slabý pro konverzační kontext;
• Lineární nebo Jira pro plánovanou práci;
• databáze pouze pro čtení pro analýzu;
• prohlížeč nebo škrabák ovládaný pro externí stránky;
• ukládání dokumentů;
• izolovaná prováděcí prostředí;
• interní systémy vystavené s přísnými oprávněními.

Záludná část je v tom, že katalog nástrojů bez zásad je jen elegantnějším způsobem, jak vytvořit chaos.

Čtvrtá část: identita a oprávnění

To je oblast, kde mnoho ukázek zavírá oči.

Agent jedná jménem někoho. Musí tedy být jasné, kdo je předmětem žaloby.

Používá uživatelská oprávnění? Servisní účet? Z pracovního prostoru? Máte dočasný nebo trvalý přístup? Umíte číst všechno nebo jen některé zdroje? umíš psát? můžete zrušit? Může psát SMS skutečným lidem?

Pokud na tyto otázky neodpovíte dobře, dříve nebo později si postavíte pomocníka s klíči od domu a bez paměti, kdo mu je dal.

Základní pravidlo, které se mi líbí, je toto: agent musí umět méně než člověk, ne více než člověk. A když musí udělat něco riskantnějšího, musí se zastavit a zeptat se.

To znamená OAuth, rozsah tokenu, správa tajemství, protokol auditu, zásady nástroje, seznam povolených, krok schválení. Ne moc romantické věci. Nezbytné věci.

Pátý díl: paměť a kontext, ale bez hromadění odpadků

Agenti potřebují paměť, ale paměť je nebezpečná, když se stane podkrovím.

Existují alespoň tři typy paměti:

• paměť běhu: co se stalo při tomto provádění;
• paměť projektu: konvence, rozhodnutí, omezení;
• osobní nebo týmová paměť: preference, tón, rituály, procesy.

Vložení všeho do výzvy je zkratka. Funguje to, dokud to už nejde. O užitečnou paměť je třeba pečovat: indexovat, aktualizovat, vypršela platnost, ověřovat, učinit citovatelnou.

Agent, který si špatně pamatuje, je horší než agent, který si to nepamatuje. Protože mluví sebevědomě.

Infrastruktura proto musí zahrnovat vyhledávání, instrukční soubory, znalostní bázi, vkládání v případě potřeby, ale také čištění. Potřebujeme kulturu paměti: co vstupuje, kdo to schvaluje, když se rozpadá, jak to napravím.

Šestý díl: pozorovatelnost, hodnocení a opakování

Udělá-li agent chybu, protokol „volaný model“ nestačí.

Chcete vidět trasu. Jaký kontext dostal? Jaké nástroje byly k dispozici? Jaký nástroj jste si vybrali? S jakými argumenty? Jakou odpověď jste dostali? kolik to stálo? Kde se to zaseklo? Schvaloval člověk něco? Je chybový model, nástroj, výzva, data nebo oprávnění chybou?

Zde jsou agenti spíše distribuovanými systémy než chatboty.

Potřebujete čitelné stopy, nejen textové protokoly. Musíte být schopni přehrát běh. Je nutné porovnat dvě verze stejného agenta na známých úlohách. Potřebujeme měřit regrese: nejenže „lépe odpovídá“, ale „uzavře správný lístek, aniž by se dotkl nevyžádaných souborů“.

Agentní hodnoty jsou obtížnější než textové, protože zahrnují akce. Nestačí porovnat očekávaný řetězec. Musíte se podívat na sekvence, vedlejší efekty, kvalitu artefaktu, čas, cenu, počet lidských zásahů.

Legrační je, že se tam vždy vracíme: softwarové inženýrství. Testy, prostředí, trasování, vrácení zpět. Až na to, že kód nyní také rozhoduje o tom, co dál.

Sedmý díl: lidská rozhraní

Agent nemusí bydlet jen na chatu.

Někteří agenti potřebují desku. Ostatní stránka se stavem a logem. Ostatní tlačítko "schválit". Více vložených komentářů. Ještě další z CLI.

Uživatelské rozhraní mění chování. Pokud je jediným způsobem, jak ovládat agenta, napsat dlouhou zprávu, uživatel dá agentovi nejasné pokyny. Pokud však vidí plán, rozdíl, zdroje, rizika a další akci, může přesně zasáhnout.

Slušná infrastruktura agentů zahrnuje ovládací plochy:

• aktuální stav;
• upravitelný plán;
• vyrobené artefakty;
• rozdíl;
• žádosti o schválení;
• chronologie;
• tlačítko stop;
• tlačítko opakování;
• viditelná oprávnění.

Zdá se to triviální, ale není. Rozdíl mezi „strašidelnou umělou inteligencí“ a „spolehlivým asistentem“ je často jen v tom, že druhý vám ukáže, kde má ruce.

Mentální zásobník

Kdybych to měl nakreslit dnes, minimální zásobník agentů by byl tento:

1. Model: uvažování, generování, volání nástrojů, v případě potřeby multimodální.
2. Orchestrování: smyčka, krok, plánovač, politika, člověk ve smyčce.
3. Trvalý běh: pracovní postup, fronta, opakování, pozastavení, obnovení.
4. Sandbox: provádění kódu, izolovaný souborový systém, omezení, artefakty.
5. Nástrojová vrstva: MCP, interní API, prohlížeč, databáze, úložiště.
6. Vrstva identity: OAuth, rozsah, tajemství, audit, politika.
7. Paměťová vrstva: kontext projektu, vyhledávání, instrukce, expirace.
8. Pozorovatelnost: sledování, přehrání, vyhodnocení, metriky nákladů a kvality.
9. Povrch produktu: chatujte, když je to dost, řídicí panel, když je potřeba, kontrolujte, když je to důležité.

Agentní rámec pokrývá hlavně body 2 a část bodu 1. Zbytek je skutečná práce.

Co bych dělal v praxi

Kdyby mi tým řekl „chceme agenty ve výrobě“, nezačínal bych s deseti agenty.

Začal bych malým, opakujícím se a pozorovatelným pracovním postupem. Například: otevírat PR údržby, aktualizovat dokumentaci z uzavřených problémů, připravovat týdenní revizi, třídit duplicitní chyby, generovat testy pro postižené soubory.

Pak bych stanovil velmi jasné limity:

• žádné psaní bez větví nebo pískoviště;
• žádná tajemství ve výzvě;
• nástroje v seznamu povolených;
• lidské schvalování vnějších akcí;
• povinný protokol a sledování;
• rozpočet na běh;
• výstup vždy kontrolovatelný.

Teprve pak bych expandoval.

Agenti neselžou jen proto, že se modelky pletou. Selhají, protože jsme je umístili do vágních prostředí s matoucími oprávněními a divadelními očekáváními.

Moje čtení

Infrastruktura agentů je nudná tím nejlepším způsobem.

Není to část, která vás nutí tleskat v demu. Je to část, která vám umožní skutečně použít demo v pondělí ráno se skutečnými lidmi, skutečnými daty a skutečnými důsledky.

O budoucnosti agentů nerozhodne jen to, kdo má nejlepší vzor. O tom bude rozhodovat ten, kdo postaví to nejlepší místo, kde ho donutí pracovat: izolovaný, když experimentuje, připojený, když je potřeba, vždy pozorovatelný, autorizovaný podle kritérií a dostatečně pokorný, aby přestal, když neví.

Tam agenti přestávají být hračkou a stávají se infrastrukturou.

Zdroje

– Vercel: Jak vytvářet agenty AI pomocí Vercel a AI SDK

• Vercel Docs: Sandbox
• Vercel Docs: Práce se sandboxem
• Vercel Docs: MCP
• Model Context Protocol: Specification
• OpenAI: Nové nástroje pro stavební agenty – Cloudflare Blog: Agents on Cloudflare