Anatomie agentní smyčky
Únor 2026 — 7 min
Každý agent, kterého nasazuji, běží ve stejné smyčce: pozoruj svět, přemýšlej, co se změnilo, jednej přes nástroj, opakuj. Zvládněte tuhle smyčku a zbytek slovníku roku 2026 — MCP, orchestrace, evaly, guardrails — zapadne sám.
Smyčka: pozoruj → přemýšlej → jednej
Odmyslete si marketing frameworků a agent je while-smyčka obalená kolem modelu. V každé iteraci model pozoruje stav — výstupy nástrojů, soubory, chybové hlášky — přemýšlí o dalším kroku a jedná voláním nástroje. Výstup akce se stává pozorováním dalšího kola. Smyčka končí, když je úkol ověřeně hotový nebo dojde rozpočet. To je celý trik; všechno ostatní je inženýrství kolem něj.
Skutečná rozhodnutí leží na okrajích. Rozhodněte, co agent v každé iteraci vidí, protože příliš velký kontext zhoršuje uvažování. Rozhodněte, co smí dělat: allowlisty nástrojů a úrovně oprávnění. Rozhodněte, kdy musí skončit: limit kroků, strop nákladů, timeout. Nad podmínkami ukončení trávím víc času než nad prompty — agent, který neumí přestat, je horší než agent, který neumí začít. V praxi je to rozdíl mezi agentem, kterému věříte celý deploy, a hračkou na jedno odpoledne.
Nástroje jsou kontrakty (MCP)
Volání nástroje je API volání, které si model skládá sám. Berte definici jako kontrakt: typované vstupy, zdokumentované chování, předvídatelné chyby. Model Context Protocol (MCP) tenhle kontrakt standardizuje — jeden tool server zapojíte do libovolného klienta, ať je to coding agent, IDE nebo CI pipeline, bez přepisování. Můj test: pokud nástroj podle popisu správně nepoužije junior, nepoužije ho ani model. Stejný kontrakt kryje i bezpečnost: server validuje vstupy dřív, než se dotknou produkce.
{"name": "search_orders", "description": "Find orders by customer email. Read-only.", "inputSchema": {"type": "object", "properties": {"email": {"type": "string"}}, "required": ["email"]}}Orchestrace: jeden agent nikdy nestačí
Reálné úkoly rychle přerostou jedno kontextové okno. Práci proto dělím: supervisor vlastní plán a rozesílá fokusované subagenty, kteří vrací kompaktní výsledky místo surového šumu. Supervisor drží celkový obraz, subagenti hloubku — a kontextová okna zůstávají malá a levná. Čtyři vzory pokryjí většinu systémů, které stavím:
- Supervisor: jeden agent plánuje, deleguje a slučuje; na surová data sám nesahá.
- Fan-out / fan-in: nezávislé podúkoly běží paralelně a výsledky se spojí v jednom průchodu.
- Subagenti jako kontextový firewall: každý worker spálí vlastní tokeny a vrátí jen krátké shrnutí.
- Checkpointy: stav se ukládá mezi kroky, takže spadlý běh naváže místo restartu od nuly.
Context engineering porazí větší prompty
Největší zisky kvality přináší kontrola nad tím, co vstoupí do okna, ne delší prompt. Retrieval (RAG) natáhne jen dokumenty, které aktuální krok potřebuje. Prompt caching drží stabilní prefix — systémová pravidla, schémata nástrojů — levný a rychlý napříč koly. Paměťové soubory přenášejí rozhodnutí mezi sezeními, takže agent neobjevuje codebase každé ráno znovu. S kontextem hospodařte jako s penězi: každý token v okně si musí své místo zasloužit. Komprese historie navíc drží dlouhé běhy při smyslech: staré kroky shrnete a okno uvolníte pro další práci.
Co neměříte, je jen demo
Agenti selhávají pravděpodobnostně, proto je měřte statisticky. Mému dashboardu vládnou dvě čísla: task success rate — vrátil běh ověřený, správný výsledek? — a míra lidských zásahů — jak často musel člověk zasáhnout? Každá změna promptu nebo nástroje projde před nasazením fixní sadou evalů; jinak měníte známé chování za pocit a říkáte tomu pokrok. Obrázek doplňují guardrails: destruktivní akce čekají na lidské schválení (HITL) a každá akce končí v logu, který jde auditovat. Regrese tak chytáte v CI, ne od naštvaných uživatelů v produkci.
- Stavte smyčku malou: jasná pozorování, nástroje s kontraktem, tvrdé podmínky ukončení.
- Dělte práci mezi agenty a řiďte kontext — nikdy nenafukujte jeden obří prompt.
- Nasazujte s evaly a guardrails; z dema se stane produkt v den, kdy ho začnete měřit.