Claude Code Agent view - to je zcela jiný způsob práce

Anthropic oznámil 11. května funkci Agent view v Claude Code. Marketingově vypadá jako přehledná obrazovka pro paralelně běžící agenty - místo skrumáže terminálových oken je tu jeden dispečink, kde je vidět, co každé sezení dělá. Tahle interpretace je technicky přesná, ale prakticky zavádějící. Agent view není lepší okénko na sledování. Je to změna pracovního modelu, která má důsledky pro to, jak píšete prompty, jak strukturujete úkoly, a co od Claude Code vlastně chcete. Nicméně nebojte, se starým způsobem práce jde agentní pohled kombinovat.

Funkce je dostupná jako research preview pro plány Pro, Max, Team, Enterprise a pro zákazníky Claude API. Vyžaduje Claude Code v2.1.139 nebo vyšší a otevírá se příkazem claude agents.

Když uvidíte oznámení Anthropicu poprvé, je snadné si představit, že po spuštění claude agents uvidíte všechna svá otevřená Claude Code okna na jedné obrazovce. Tak to nefunguje. Dokumentace to říká přímo: interaktivní sezení, která máte otevřená v jiných terminálech, se v Agent view neobjeví, dokud je explicitně nepošlete na pozadí.

Filozofie funkce je opačná než “vidět víc oken najednou”. Místo toho je to: “pošli věci na pozadí a do oken se vracej jen, když je to třeba.” Pokud tenhle obrácený postup nepřijmete, Agent view vám reálně nic neudělá - zůstane prázdné okno s nápisem, že žádná sezení neběží.

Jak se mění práce s Claude Code

S Agent view se mění způsob práce s Claude Code.

Dnes je interaktivní Claude Code dialog. Napíšete prompt, vidíte odpověď, reagujete, pokračujete. Drobné neporozumění odhalíte za třicet sekund a opravíte další větou. Když vás napadne lepší úhel, řeknete “počkej, jdeme jinak”. Když Claude udělá špatné rozhodnutí, zastavíte ho.

Tahle interaktivnost má skrytou daň. Když Claude pracuje, sedíte u obrazovky a čekáte. Ne typujete, ale ani neděláte nic jiného - sledujete, jestli to jde správným směrem. Hodina práce s Claudem je hodina vaší pozornosti, i když aktivně píšete maximálně deset minut. Nebo je to přepínání mezi více okny, více rozdělanými projekty, což bývá trochu chaos.

Agent view nabízí jiný model. Zadáte úkol jako balík: tady je cíl, tady jsou rozhodovací kritéria, tady je fallback pro případ, že něco nepůjde, a tady je formát výstupu. Pak agenta pošlete na pozadí, jdete dělat něco jiného, a vrátíte se ke všemu naráz - buď k hotovým výsledkům, nebo k bodu, kde se Claude opravdu fest zasekl a potřebuje vás.

Z hlediska Claude úsilí se nic nemění. Z hlediska vašeho času je to zásadní rozdíl. Místo souvislé hodiny pozornosti máte pět minut soustředění na začátku, pět minut na konci, a šedesát minut volných uprostřed. Rozumíte dobře: cílem je zadat obsáhlý úkol, který bude splněn celý. Ne se dohadovat, že tlačítko chcete modré a vlevo dole…

Pro koho to dává smysl: pro vývojáře, který má víc nezávislých úkolů a umí je dopředu jasně popsat. Pro koho to nedává smysl: pro toho, kdo objevuje problém průběžně, mění směr v polovině, a potřebuje s Claudem skutečně přemýšlet, ne ho úkolovat.

Tady dovolte pár přípodoteků k tomuto konceptu.

Aktivní čas není totéž co doba úlohy. To je hlavní nedorozumění, na kterém celý smysl Agent view stojí. Když Claude pracuje a vy se na to díváte, jste blokovaní - ten čas nepoužijete na nic jiného, i když přímo netypujete. Když Claude pracuje na pozadí, máte svůj čas volný zpátky.

Některé úlohy v interaktivní formě prostě neexistují. Například Loop úkoly (smyčky), jako je třeba nějaký updater nejsou “rychlejší na pozadí” - jsou na pozadí jediné technicky proveditelné. Tady Agent view neoptimalizuje, ale otevírá novou kategorii toho, co s Claude Code vůbec můžete dělat.

Co Agent view technicky dělá a jak se ovládá

Funkce sjednocuje správu sezení na pozadí do jedné terminálové obrazovky. Spouští se příkazem claude agents nebo stiskem šipky doleva v běžícím sezení. Každý řádek zobrazuje název sezení, jednověté shrnutí toho, co dělá (generované Haiku-class modelem, refresh max jednou za 15 sekund), a čas poslední změny.

Stavy a ikony. Sezení může být v šesti stavech: Working (animovaná ikona), Needs input (žlutá), Idle (tlumená), Completed (zelená), Failed (červená), Stopped (šedá). Tvar ikony zvlášť rozlišuje, jestli proces fyzicky běží (✻), je uspaný (∙) nebo se opakuje ve smyčce (✢).

Peek a reply. Stiskem mezerníku otevřete peek panel - rychlý náhled toho, co sezení produkuje nebo čeká. Pokud agent pokládá otázku s výběrem, stačí stisknout číslo příslušné odpovědi. Pokud chcete jen vidět odpověď a pokračovat, peek funguje jako rychlé nahlédnutí bez plného připojení k transcriptu.

Attach a detach. Šipka doprava nebo Enter připojí k vybranému sezení v plné podobě. Zpátky do přehledu se vrátíte šipkou doleva na prázdném promptu. Detach nikdy nezastaví sezení - běží dál, dokud explicitně nepoužijete /stop nebo Ctrl+X.

Supervisor proces. Sezení na pozadí nehostuje terminál, ale samostatný proces (~/.claude/daemon.log), který běží nezávisle na vašem shellu. Sezení tedy přežijí zavření terminálu, ale ne uspání nebo vypnutí počítače. Po hodině nečinnosti supervisor proces sezení uspí (stav zůstane na disku) a probudí ho při dalším peeknutí. Po uspání stroje použijete claude respawn --all.

Worktree izolace. Tohle je nejzajímavější technický detail. Každé sezení na pozadí má zakázán zápis do pracovního adresáře, dokud se nepřesune do izolovaného git worktree pod .claude/worktrees/<id>/. Claude to udělá automaticky, jakmile potřebuje něco zapsat. Důsledek: deset paralelních agentů pracujících ve stejném repozitáři si nemůže navzájem přepisovat soubory. Worktree se smaže spolu se sezením, takže merge nebo push změn musí proběhnout předtím.

Shellové příkazy. Pro skriptování a práci mimo Agent view jsou k dispozici: claude attach <id>, claude logs <id>, claude stop <id>, claude respawn <id>, claude rm <id>.

Vypnutí na úrovni organizace. Administrátoři mohou Agent view zakázat nastavením disableAgentView v managed settings nebo proměnnou CLAUDE_CODE_DISABLE_AGENT_VIEW. Užitečné pro firemní nasazení, kde chcete vědomě omezit, kolik tokenů uživatelé spalují bez dohledu.

Jak posílat úkoly na pozadí

Tři způsoby, podle toho, kde právě jste.

Z čistého shellu:

cd ~/cesta/k/projektu
claude --bg "zpracuj prd.md do implementačního plánu"

Sezení se spustí na pozadí, vrátí krátké ID a vypíše příkazy pro jeho správu.

Z Agent view: Po spuštění claude agents napíšete prompt do spodního pole a stisknete Enter. Sezení se objeví jako nový řádek. Shift+Enter ho spustí a hned k němu připojí.

Z běžícího interaktivního sezení: Příkaz /bg "další instrukce" pošle aktuální konverzaci na pozadí i s navazujícím úkolem.

V promptu lze používat speciální syntaxi: první slovo jako jméno subagenta, @<jméno> pro mention subagenta uprostřed promptu, @<repo> pro spuštění v jiném repozitáři, /<skill> pro spuštění skillu, #<číslo> pro připojení k existujícímu PR sezení.

Filozofie strukturovaného promptu

Tady přichází to, co Anthropic ve vlastní dokumentaci neříká příliš nahlas: Agent view vás nutí psát lepší prompty. Ne explicitně, ale prostředím. Když píšete prompt pro interaktivní sezení, jste sám sobě záchrannou sítí. Vidíte, jak to Claude pochopil, včas ho stopnete a nejasnosti doplníte v dalším turnu. Když píšete prompt pro agenta, najednou tam s ním nejste, když je něco špatně. Agent jede třeba dvacet minut na něčem, co jste mu zadali jednou větou, a vrátí se s výsledkem, který buď sedí, nebo nesedí.

Krátký prompt pro pozadí typu “napiš mi implementační plán z prd.md” skončí jedním ze tří způsobů:

1. Sezení se zasekne na “Needs input” hned na začátku (“Mám použít React nebo Vue?” “Kam mám uložit výstup?”), čímž celá výhoda backgroundování padá.
2. Agent rozhodne sám, vy se vrátíte k výstupu, který neodpovídá tomu, co jste si představovali, a začnete od nuly.
3. Vyjde to náhodou dobře. To je ten nejnebezpečnější případ - vytvoří dojem, že krátké prompty fungují, dokud příště nedostanete úplně něco jiného, než jste chtěli.

Strukturovaný prompt pro pozadí by měl obsahovat několik prvků, které u interaktivního sezení doplňujete za chodu:

• Baseline nebo referenční bod - proti čemu se měří úspěch
• Cíl ve formě výstupu - co konkrétně agent vyprodukuje a kam to uloží
• Autorizační matice - co smí (otevřít PR, upravit soubor, spustit příkaz) a co nesmí (změnit konfiguraci, smazat data)
• Rozhodovací volnost s mantinely - když se objeví A/B otázka, jak rozhodnout, aby se sezení nezaseklo
• Fallback při selhání - co dělat, když primární cesta nepůjde
• Formát výstupu - šablona, jak hlásit zpátky

To zní jako podstatně víc práce než “napiš to a tamto”. Je to víc práce. Ale je to také jediný způsob, jak se vyhnout zaseknutým sezením a špatným výstupům - a má to ještě jednu výhodu, o které bude řeč zachvíli.

Anatomie konkrétního promptu

Vezměme reálný příklad - prompt pro experimentální srovnání kvality dvou jazykových modelů na úloze generování technického článku. Cíl: zjistit, jestli si placený model (Claude Sonnet 4.6) ospravedlní zvýšení nákladů oproti free modelu, který se aktuálně používá.

Srovnej kvalitu Sonnet vs free model na generate-topic-article.
Baseline: redcap-rel-17-rel-19 v DB vyrobený 
inclusionai/ring-2.6-1t:free (15687 znaků EN, 4.3 min). 
Otázka: ospravedlní si claude-sonnet-4-6 (~$0.015/article) zlepšení kvality?

Pre-autorizováno:
- 1× POST /admin/runs s Sonnet override (~$0.02 cost)
- git push, gh pr create pro doc PR

NEautorizováno:
- změna DEFAULT_SYNTHESIS_MODEL bez explicitního schválení v PR review
- mazání nebo přepisování existujícího redcap článku v DB

Kroky:
1. Stáhni stávající redcap článek a ulož jako /tmp/redcap-ring.json.
   Toto je baseline.
2. POZOR: /api/admin/articles dělá UPSERT, takže druhý run pro stejný
   topic přepíše existující draft. Před enqueue změň článku slug —
   nejjednodušší: dočasně changne článku ID v DB přes PATCH na
   "redcap-rel-17-rel-19-ring" (pokud máš povolení), nebo lépe:
   spusť run pro JINÝ topic kde nemáš referenci (Drones, V2X), pak
   stejný topic se Sonnetem. Druhá cesta je čistější — vyber sám.
3. Enqueue run s params.synthesisModel = "anthropic/claude-sonnet-4-6".
   Translation model default. Poll do completed.
4. Stáhni novou verzi do /tmp/redcap-sonnet.json.
5. Srovnej v 5 dimenzích:
   - Délka: chars + slov
   - Cost: ring=$0, Sonnet=cca $0.015 (ověř přes summary.usdCostMicros)
   - Latency: durationMs
   - Specificita: zmínky WIs/specs/FFS samples (grep counts)
   - Subjektivní: pročti úvod + Active Development sekci
6. Branch chore/model-comparison-topic-article, vytvoř
   docs/MODEL-COMPARISON-TOPIC-ARTICLE.md s metrickou tabulkou,
   excerpty (~500 znaků každé verze, stejná sekce), doporučením
   pro default.
7. Pokud Sonnet vyhraje výrazně (>1.5× quality v subjektivním
   hodnocení nebo >30 % víc specifik), DOPORUČ změnu defaultu —
   ale neprováděj ji. PR popis ať obsahuje konkrétní LOC změnu:
   DEFAULT_SYNTHESIS_MODEL v 
   packages/spec-pipeline/src/steps/generate-topic-article.ts řádek 36.
8. gh pr create — toto je doc PR, žádné code změny.

Výsledek na konec: "Sonnet [lepší/srovnatelný/horší] než ring, 
doporučení: [keep ring/switch Sonnet/per-topic tier], PR #X".

Rozhodnutí: pokud Sonnet selže (quota, key permission), zkus
deepseek/deepseek-v3.2 nebo openai/gpt-5.4 jako proxy pro
"paid tier" srovnání. Nemusíš trvat na Sonnetu.

Pozor na UPSERT bug (krok 2). To je důležité, jinak ztratíš baseline.

Co tenhle prompt dělá dobře, prvek po prvku:

• Baseline na začátku. Konkrétní článek v DB, jeho metriky (znaky, čas), použitý model. Agent ví, proti čemu se měří.
• Cílová otázka v jedné větě. “Ospravedlní si Sonnet zlepšení kvality?” To je rozhodovací kritérium, ne instrukce.
• Autorizační matice. Explicitně oddělené pre-autorizováno a neautorizováno. U interaktivního sezení by se agent zarazil dotazem; na pozadí by se buď zasekl, nebo udělal něco, co nechcete.
• Upozornění na konkrétní past. UPSERT bug v /api/admin/articles je informace, kterou agent nemá jak zjistit z kódu rychle - dostane ji v promptu předem, takže neztratí baseline.
• Rozhodovací volnost s mantinely. Krok 2 dává dvě cesty řešení a říká “vyber sám”. Sezení se nezasekne na otázce, ale výběr není náhodný - máte definované možnosti.
• Fallback při selhání. Když Sonnet nepůjde, zkus deepseek nebo gpt-5.4. Bez tohohle by sezení zhynulo na první chybě.
• Konkrétní metriky. Pět dimenzí srovnání, ne abstraktní “porovnej kvalitu”. Agent ví, co měřit, vy víte, co dostanete zpátky.
• Práh pro doporučení. “>1.5× kvalita v subjektivním hodnocení nebo >30 % víc specifik.” Místo pocitu konkrétní kritérium, reprodukovatelné.
• Hranice mezi “doporuč” a “proveď”. Konkrétní řádek souboru, který by se měl změnit - ale agent ho nezmění. Rozhodnutí zůstane na člověku v PR review.
• Formát výstupu. Šablona závěrečné věty “Sonnet [lepší/srovnatelný/horší]…” - když si pak v Agent view peekne, vidíte strukturovanou odpověď, ne tři odstavce textu.

Tenhle prompt má 35 řádků a vytvářím ho jednou. Co by jeho interaktivní ekvivalent stál, ukazuje zhruba následující rozpis:

Trik, který Anthropic neříká: nechte si prompt napsat Claudem

Tady přichází metoda, která teprve dělá z Agent view praktický nástroj. Strukturovaný prompt z předchozí kapitoly vznikl tak, že jsem o něj požádal interaktivního Claude Code. Ne, že jsem ho psal ručně. To by mne fakt nebavilo a hromadu věcí bych prostě nepromyslel a nebo zapomněl. Tím doslovným “game changerem” je, nechat si prompt pro agenty napsat Claudem.

Postup: otevřete normální claude nad repozitářem, popíšete, co chcete experimentem zjistit, a požádáte ho, ať vám napíše prompt pro sezení na pozadí. Claude:

• Vidí kód. UPSERT bug v /api/admin/articles najde tak, že si přečte endpoint a všimne si konfliktové klauzule.
• Vidí historii. Baseline redcap-rel-17-rel-19 je v DB, Claude se na něj podívá a zjistí metriky (15687 znaků, 4.3 min).
• Zná konvence projektu. Branch naming, struktura doc PR, formát commit zpráv.
• Najde konkrétní řádky. DEFAULT_SYNTHESIS_MODEL na řádku 36 - protože si ten soubor přečte.

Kdybyste tohle psali sami, půlku informací dohledáváte ručně. Čas: 20-30 minut. Když to necháte napsat Claude Code v interaktivním režimu, kde má kontext repozitáře, je to 3-5 minut formulace zadání + minuta čtení a úprav.

Ekonomika srovnání:

Tohle není obcházení vlastní práce, je to specializace. Interaktivní Claude má kontext kódu a konvencí. Vy máte strategický záměr a finální kontrolu. Dohromady vytvoříte za pět minut prompt, který by vám sám zabral půl hodiny.

Skrytá výhoda je systematičnost. Když strukturovaný prompt píšete sami, máte tendenci vynechávat věci, které jsou vám samozřejmé. UPSERT bug byste možná zmínili, až když by vám agent přepsal baseline. Claude prochází mentální checklist (baseline? autorizace? edge cases? fallback? formát výstupu?) systematicky, protože k tomu nemá lidský bias zapomínání.

Tři důležitá omezení tohoto postupu:

1. Claude může halucinovat strukturu kódu. Když řeknete “napiš prompt pro experiment”, může si vymyslet řádek, který v souboru není. Proto si prompt vždy přečtěte před spuštěním. To není formalita, je to nutná kontrola.
2. Claude má tendenci přespecifikovat. Pro jednoduchý úkol vám napíše stejně rozsáhlý prompt jako pro složitý. Musíte sami říct “stručněji, jsem si jistý směrem”.
3. Riziko bábušek. Claude Code píše prompt pro Claude Code, který spustí Claude Code. Když chyba vznikne v prvním kroku (špatně pochopený záměr), propaguje se do dalších dvou. Kritické čtení promptu před spuštěním tohle riziko snižuje, jinak budete vrstvit chyby jako ruské bábůšky.

Praktické pravidlo

Po aktivní noční seanci používání Agent view bych shrnul rozhodování takhle:

Krátký prompt → krátký prompt. Spočítej součet sloupce, vysvětli error message, najdi tu funkci. Ručně, interaktivně, hotovo.

Dlouhý strukturovaný prompt → požádej Claude Code o jeho sepsání. 20+ minut úkolu, paralelní běh, kritické rozhodnutí o autorizacích. Náklad: 5 centů a 2 minuty. Návratnost: 20 minut vašeho času a lepší pokrytí edge cases.

Mezitím je široké pásmo, kde záleží na rutině a osobní preferenci a na tom, jak jste sladění s Claude Code. Ale tahle dvě krajní pravidla fungují skoro vždycky.

Co Anthropic neříká

Stojí za to být střízlivý. Funkce má reálné limity a marketingové oznámení je vynechává.

Spotřeba tokenů narůstá nelineárně. Dokumentace to nakonec přiznává v sekci Limitations: “running ten agents in parallel uses quota roughly ten times as fast as running one.” Když Claude jede 20 minut sám, nemůžete ho zastavit ve chvíli, kdy si všimnete, že jede špatným směrem. Zaplatíte plnou dobu, i když výstup zahodíte. U interaktivního sezení tahle ztráta neexistuje.

Falešný pocit kapacity. Spustit deset sezení paralelně je snadné. Reálně dohlédnout na deset výstupů a posoudit, jestli každý dává smysl, je úplně jiná disciplína. Hrozí, že začnete mergovat věci, kterým jste pořádně nerozuměli - jen proto, že “Claude říká, že to funguje”. To je riziko, které roste s počtem souběžných sezení.

Sezení jsou lokální. Background sezení neběží v cloudu, ale na vašem stroji. Uspání laptopu = zastavení sezení. Pro někoho zásadní omezení (chcete nechat běžet úkol přes noc), pro jiného nepodstatné.

Worktree mažou změny. Když smažete sezení, smaže se i jeho worktree, včetně neuložených změn. Před smazáním je nutné mergnout nebo pushnout. Tohle je past, kterou je snadné přehlédnout, dokud o ni jednou nezakopnete.

Není to webové ani IDE rozhraní. Funkce zůstává v terminálu. Pro lidi preferující grafickou kontrolu nad agenty - kterých přibývá v ne-vývojářských profesích, jež začínají Claude Code používat - je to omezení. Pro hardcore CLI uživatele je to naopak přednost.

Kvalita výstupu se v paralelním režimu hůř detekuje. Předchozí měsíce ukázaly, že Claude Code prošel obdobím nestability spojeným s problémem v cachingu. Když pouštíte deset sezení a díváte se jen na finální shrnutí, případnou degradaci kvality zachytíte hůř než v interaktivním režimu, kde vidíte každý krok.

Kontext: jak to zapadá do strategie

Anthropic ve stejný den oznámil Claude Platform na AWS - hostovanou variantu pro firemní nasazení. O několik dní dříve zveřejnil aktualizaci Claude Managed Agents s novými možnostmi orchestrace mezi více agenty. Agent view do této řady zapadá jako klientská strana téhož trendu: serverová orchestrace agentů na straně Anthropicu, klientská orchestrace na straně vývojáře.

Konkurence zatím nemá podobně sjednocený dispečink. Cursor má background agents, ale jejich přehled je integrován do IDE. Windsurf po akvizici Googlem soustředí síly jinam. Cline jde cestou IDE pluginů. Anthropic tedy obsazuje specifickou niku: terminálový vývojář s vícenásobnými agentními sezeními. Jestli se tahle nika ukáže jako dost velká, uvidíme za pár měsíců.

Závěr

Agent view není funkce pro každého Claude Code uživatele. Pro někoho, kdo používá Claude na rychlé dotazy a krátké úpravy kódu, nepřinese nic. Pro toho, kdo Claude úkoluje delšími pracemi, otevírá způsob, jak ze sledovače průběhu udělat skutečného agenta.

Klíčová není funkce sama. Klíčové je přijetí pracovního modelu, který za ní stojí: úkoly se zadávají strukturovaně a předem, ne objevují za chodu. Strukturovaný prompt vypadá jako daň, ale dá se napsat za pět minut, pokud k jeho sepsání použijete samotný Claude Code v interaktivním režimu. Pak je investice nepatrná proti návratnosti.

Kdo se naučí tenhle režim - úkolovat místo dialogovat, popisovat předem místo opravovat za chodu, kontrolovat výsledky místo sledovat průběh - dostane z Claude Code podstatně víc, než kolik dostával před touhle funkcí. Kdo zůstane u interaktivního dialogu, neztratí nic. Jen kolem něj poroste skupina lidí, která pracuje jinak.

Dokumentace je na code.claude.com, spuštění je claude agents. Šipka doleva a doprava jsou klíčové ovládací prvky - stojí za to si je zapamatovat dřív, než Agent view poprvé otevřete.