03 - Pracovní postupy agentů: Problémy s rozkladem pro AI
Existuje přesný okamžik, kdy AI přestává být asistentem a stává se spolupracovníkem: když se přestaneš ptát "napiš tuto funkci" a ty se jí začneš ptát "řešit tento problém". Tím mentálním skokem, od jediného pokynu ke složitému úkolu, je srdce bohové Agentní pracovní postupy. A je to také místo, kde většina vývojářů uvízne, protože vytvoření efektivního agentského pracovního postupu vyžaduje hlubokou změnu paradigmatu: nejde o delší výzvy, ale o architekturu.
V roce 2025 92 % amerických vývojářů používá nástroje AI při své každodenní práci (Stack Overflow Developer Survey 2025), ale jen zlomek z nich skutečně využívá výhody potenciál agentních systémů. Problém není v přístupu k technologiím, ale v jejich nedostatku jasných architektonických vzorů pro rozkládat složité problémy v úkolech které může agent AI vyřešit spolehlivým, ověřitelným a opakovatelným způsobem.
V tomto článku společně vybudujeme hluboké porozumění agentním pracovním postupům: no tak základní vzory (sekvenční, paralelní, hierarchické, iterativní) k implementaci praxe s Claude Code, procházení kontextovým managementem, metrikami kvality a anti-vzorce, které přeměňují slibný pracovní postup na nespolehlivý systém. Celá věc se skutečnými případovými studiemi a pracovním kódem.
Co se naučíte
- Čtyři základní vzorce rozkladu: sekvenční, paralelní, hierarchický, iterativní
- Architektura agentního pracovního postupu: Plánovač, Exekutor, Recenzent, Paměť
- Jak strukturovat CLAUDE.md, aby vedl agenty na skutečných projektech
- Smyčka Plan-Execute-Review a samoopravné pracovní postupy
- Použití nástroje a kontextová správa pro dlouhé relace agentů
- Metriky pro hodnocení kvality agentského pracovního postupu
- Nejnebezpečnější anti-vzory a jak se jim vyhnout
- Případová studie: refaktoring Angular codebase s agentem workflow
Co je to agentský pracovní postup
Un Agentní pracovní postup a strukturovanou sekvenci operací, ve kterých je jedna nebo více Agenti AI plánují, provádějí a ověřují akce k dosažení komplexního cíle. A Na rozdíl od jednoho volání LLM má agentní pracovní tok paměť mezi kroky, kterou může používat nástroje (souborový systém, terminál, web, API), mohou delegovat dílčí úkoly na specializované agenty a dokáže se přizpůsobit chybám bez lidského zásahu.
Klíčový rozdíl oproti „naivnímu“ kódování vibrací spočívá v záměrná struktura. Zeptat se Clauda "zrefaktorovat tuto kódovou základnu" přináší průměrné výsledky. Budování pracovního postupu který: (1) analyzuje kódovou základnu, (2) identifikuje komponenty k refaktorování v pořadí priority, (3) refaktorujte jednu složku po druhé pomocí regresního testování, (4) nejprve otestujte každý krok pokračovat, přináší profesionální výsledky. Rozdíl a rozklad.
Operační definice
Agentní pracovní postup e spolehlivý když: každý krok je nezávisle ověřitelný, selhání jednoho kroku nepoškodí celý pracovní postup, konečný a deterministický výstup vzhledem ke vstupu a lidský operátor může kdykoli zkontrolovat a opravit pracovní postup kontrolní bod. Tato definice pochází z antropického rámce „Building efektivních agentů“ (2024) a zůstává kompasem pro hodnocení jakékoli implementace.
Dekompozice problému: Jádro pracovního postupu agentů
Výzkum TDAG (Task Decomposition and Agent Generation, 2025) tuto kvalitu prokázal rozkladu a nejvíce prediktivní faktor úspěchu multiagentního systému: špatný rozklad šíří chyby exponenciálně prostřednictvím následujících kroků, zatímco správný rozklad izoluje selhání a umožňuje obnovu.
Existují čtyři základní vzorce rozkladu, z nichž každý je vhodný pro různé typy problémů:
Vzor 1: Sekvenční (řetězec)
Nejjednodušší vzor: každý úkol závisí na výstupu předchozího. Vhodné pro lineární pracovní postupy kde je pořadí sémanticky významné (např. analýza -> návrh -> implementace -> test).
Pattern Sequential:
[Input]
|
v
[Task A] --> output_A
|
v
[Task B] --> output_B
|
v
[Task C] --> [Output Finale]
Caratteristiche:
- Ogni task riceve output del precedente come contesto
- Fallimento in Task B blocca Task C
- Debugging semplice: errore localizzato al task fallito
- Latenza: somma di tutti i tempi (A + B + C)
Caso d'uso tipico: Pipeline di generazione codice
1. Analisi requisiti
2. Design architetturale
3. Implementazione
4. Test generation
5. DocumentationVzor 2: Paralelní (Scatter-Gather)
Více nezávislých úloh je současně prováděno samostatnými agenty s agregátorem který shromažďuje a shrnuje výsledky. Drasticky snižuje latenci, ale vyžaduje, aby i dílčí úkoly jsou skutečně nezávislé (žádné sdílení proměnlivého stavu).
Pattern Parallel (Scatter-Gather):
[Input]
|
[Orchestrator/Splitter]
/ | \
v v v
[Task A] [Task B] [Task C]
out_A out_B out_C
\ | /
v v v
[Aggregator/Merger]
|
[Output Finale]
Caratteristiche:
- Task A, B, C eseguiti in parallelo (via sub-agents)
- Latenza: max(A, B, C) invece di A + B + C
- Fallimento parziale: gestibile se aggregatore e robusto
- Rischio: race condition su risorse condivise
Caso d'uso tipico: Review multi-dimensionale
Agent 1: Security review
Agent 2: Performance analysis
Agent 3: Code style check
Agent 4: Test coverage analysis
Aggregator: Synthesize findingsVzor 3: Hierarchický (nadřízený-pracovník)
Dohlížející agent rozloží problém na dílčí úkoly a deleguje je na specializované pracovníky. Dělníci mohou zase mít podzaměstnance. A nejúčinnější vzor pro velké problémy ale také nejsložitější na ladění. LangGraph zdokumentoval tento vzor jako nejvíce přijata v roce 2025 pro podnikové systémy.
Pattern Hierarchical:
[Planner Agent]
"Refactorizza il modulo auth"
/ | \
v v v
[Backend Agent] [Frontend] [Test Agent]
"Refactorizza "Aggiorna "Aggiorna
AuthService" LoginCmp" test suite"
| | |
[sub-tasks] [sub-tasks] [sub-tasks]
| | |
done done done
\ | /
v v v
[Planner: Merge & Verify]
|
[Output Finale]
Livelli tipici in sistemi reali:
L0: Problem Planner (decompone goal globale)
L1: Domain Agents (backend, frontend, infra)
L2: Task Workers (singoli file, funzioni)
L3: Tool Calls (bash, file system, test)Vzor 4: Iterativní (ReAct / Reflexe)
Agent pracuje ve smyčce: provádí akci, pozoruje výsledek, reflektuje aktuální stav a rozhodne o dalším postupu. A vzor Rámec ReAct (Důvod + Herectví) a jeho rozšíření Reflexe (které přidává výslovnou kritiku). Vhodné na problémy průzkumné, kde cesta řešení není a priori známa.
Pattern Iterative (ReAct + Reflexion):
[Goal]
|
v
[Think] <-----------+
| |
v |
[Act / Tool Use] | (se max_iter non
| | raggiunto e goal
v | non soddisfatto)
[Observe] |
| |
v |
[Critique/Reflect]--+
|
(se goal soddisfatto)
|
v
[Output]
Elementi chiave:
- Scratchpad: memoria degli step precedenti
- Stop condition: goal raggiunto O max_iterations
- Critique: valutazione esplicita dell'output parziale
- Tool repertoire: set di tool disponibili all'agente
Caso d'uso: Debugging di un test che fallisce
1. Leggi error message
2. Analizza codice correlato
3. Formula ipotesi
4. Applica fix
5. Esegui test
6. Se fallisce ancora: ritorna a step 2
7. Se passa: scrivi explanationArchitektura agentského pracovního postupu
Bez ohledu na zvolený vzor má vyspělý agentní pracovní postup čtyři složky základy. Jejich pochopení je předpokladem pro budování robustních systémů ve výrobě.
1. Plánovač
Plánovač obdrží cíl na vysoké úrovni a přemění ho na strukturovaný plán: sekvenci (nebo DAG) dílčích úkolů se závislostmi, přiřazení agentům, kritéria úspěšnosti pro každý krok a odhad zdrojů (tokenový rozpočet, potřebné nástroje). Dobrý plánovač vytváří plány ověřitelný: každý krok má dobře definovaný očekávaný výstup.
2. Exekutor
Exekutor přebírá jednotlivé úkoly z Plánovače a provádí je pomocí dostupných nástrojů: souborový systém,
bash, vyhledávání na webu, API. Každý specializovaný Exekutor (backendový agent, testovací agent, doc agent) má
přístup pouze k nástrojům nezbytným pro jeho doménu, na základě principu
nejmenší privilegium. Claude Code to implementuje prostřednictvím systému
oprávnění a vlastní podřízené agenty s allowedTools konfigurovatelné.
3. Recenzent
Recenzent ověří, že výstup každého vykonavatele splňuje definovaná kritéria úspěšnosti z Plánovače. Není to jednoduché „zdá se to v pořádku“: recenzent kvality provádí automatické testy, statická analýza, regresní kontroly. Recenzent může schválit (pracovní postup pokračuje), požadovat změny (exekutor se znovu pokusí) nebo eskalovat na člověka (povinný kontrolní bod).
4. Paměť
Paměť spravuje kontext prostřednictvím kroků pracovního postupu. Má dvě úrovně:
- Krátkodobé (v kontextu): obsah aktuálního kontextového okna, včetně výstupů z předchozích kroků. Omezeno dostupnými tokeny.
-
Dlouhodobé (externí): stavový soubor (např.
claude-progress.txt), databáze, historie git. Umožňuje obnovit přerušené pracovní postupy mezi různými relacemi.
Vzor claude-progress.txt
Antropická doporučuje používat a claude-progress.txt v kořenovém adresáři projektu
pro paměť mezi relacemi. Agent iniciátor zapisuje stav pracovního postupu každých
kontrolní body; další agent čte tento soubor, aby pochopil, kde je práce a co
musí udělat. V kombinaci s git log, poskytuje úplný kontext bez
saturovat kontextové okno.
Praktická implementace s Claude Code
Claude Code nabízí tři hlavní nástroje pro pracovní postupy stavebního agenta: soubor
CLAUDE.md řídit chování agenta,
Úkolové nástroje delegovat na dílčí agenty a i zakázkové agenty
(definováno v .claude/agents/) podle specializace. Podívejme se, jak je kombinovat.
Struktura CLAUDE.md pro Agentické pracovní postupy
Soubor CLAUDE.md je „ústavou“ vašeho projektu pro agenty AI. A CLAUDE.md navržený pro agentní pracovní postupy zahrnuje nejen informace o projektu, ale také struktura samotného workflow: kteří agenti existují, jak koordinují, co jsou kritéria úspěchu pro každou fázi.
# CLAUDE.md - Workflow Agentico per Progetto Angular
## Progetto
Portfolio Angular con SSR, Angular 21, TypeScript strict.
Stack: Angular, Firebase, SCSS.
## Workflow Agentici Disponibili
### Workflow: Feature Development
Usa questo workflow per implementare nuove feature:
**Fase 1 - Planning** (obbligatoria):
- Leggi tutti i file correlati alla feature
- Crea `docs/plans/[feature-name].md` con:
- Componenti da creare/modificare
- Interfacce TypeScript necessarie
- Test da scrivere (TDD: scrivi prima i test)
- Dipendenze e rischi
- NON implementare finchè il piano non e approvato
**Fase 2 - TDD Implementation**:
- Scrivi unit test PRIMA dell'implementazione
- Implementa il minimo necessario per far passare i test
- Poi refactorizza
- Verifica `npm test` passa senza errori
**Fase 3 - Review**:
- Esegui `npm run lint`
- Verifica che build SSR compili: `npm run build`
- Controlla che non ci siano regressioni
### Workflow: Refactoring
Per refactoring di componenti esistenti:
1. Crea branch: `git checkout -b refactor/[nome]`
2. Analizza dipendenze del componente con grep/Glob
3. Refactorizza UN componente alla volta
4. Verifica test dopo ogni componente
5. Commit atomico per ogni componente
### Workflow: Debug
Per bug fixing:
1. Riproduci il bug con un test che fallisce
2. Identifica root cause (NON fixare sintomi)
3. Applica fix minimale
4. Verifica che il test ora passi
5. Controlla regressioni
## Agenti Specializzati
Disponibili in `.claude/agents/`:
- `architect.md`: Per decisioni architetturali
- `security-reviewer.md`: Prima di ogni commit
- `code-reviewer.md`: Dopo ogni implementazione
- `tdd-guide.md`: Per TDD workflow
## Criteri di Successo Globali
- TypeScript strict: zero errori `tsc --noEmit`
- Test coverage: minimo 80%
- Build SSR: `npm run build` deve completare senza errori
- Nessun `any` implicito
- Nessuna mutazione di stato (immutability pattern)
## Gestione Errori
Se un comando fallisce:
1. Leggi l'errore completo
2. NON procedere al passo successivo
3. Identifica e risolvi prima di continuare
4. Se non riesci dopo 2 tentativi: STOP e chiedi chiarimentiPrompt Engineering for Task Decomposition
Kvalita rozkladu přímo závisí na kvalitě počáteční výzvy. Zde je testovaná šablona, která agenta povede při rozkladu složitých úkolů:
# Prompt Template: Task Decomposition
## Contesto
Sei un Planning Agent. Il tuo compito e decomporre il goal seguente
in subtask concreti, verificabili e assegnabili a agenti specializzati.
## Goal
[DESCRIZIONE DEL GOAL]
## Vincoli
- Ogni subtask deve avere: ID, descrizione, input atteso, output atteso,
agente responsabile, criteri di successo (verificabili automaticamente)
- I subtask devono essere ordinati per dipendenze (DAG)
- Nessun subtask deve durare più di [X] minuti / [Y] token
- Definisci i checkpoint obbligatori dove un umano deve approvare
## Output Atteso
Produci un piano strutturato in questo formato JSON:
{
"goal": "descrizione del goal",
"estimated_complexity": "low|medium|high",
"subtasks": [
{
"id": "T001",
"description": "Analizza la struttura del componente AuthService",
"agent": "analyzer",
"inputs": ["src/app/services/auth.service.ts"],
"outputs": ["docs/analysis/auth-service.md"],
"success_criteria": ["file creato", "contiene sezioni: deps, interfaces, methods"],
"depends_on": [],
"estimated_tokens": 8000
},
{
"id": "T002",
"description": "Scrivi test per AuthService",
"agent": "tdd-agent",
"inputs": ["docs/analysis/auth-service.md", "src/app/services/auth.service.ts"],
"outputs": ["src/app/services/auth.service.spec.ts"],
"success_criteria": ["npm test -- --testPathPattern=auth.service passa"],
"depends_on": ["T001"],
"estimated_tokens": 12000
}
],
"checkpoints": ["dopo T001: review del piano", "dopo T003: review implementazione"],
"rollback_strategy": "git stash prima di ogni modifica distruttiva"
}Použití nástroje Task Tool pro dílčí agenty
Claude Code zpřístupňuje nástroj Task pro delegování práce na podagenty. Každý sub-agent funguje v izolovaném kontextu s vlastním kontextovým oknem, které vám umožňuje spravovat pracovní postupy které překračují limity jedné relace. Antropický výzkum (2026 Agentické kódování Trends Report) ukazuje, že nejúčinnějším vzorem je Opus pro orchestraci a Sonnet pro pracovníky, snížení nákladů o 40-60 % při zachování kvality.
# Prompt per orchestrare sub-agents con Task tool
Devo refactorizzare il modulo di autenticazione di questa Angular app.
Ho analizzato il codebase e identifico questi task paralleli indipendenti:
**Task 1 - Security Review** (usa Task tool):
Prompt: "Leggi src/app/services/auth.service.ts e tutti i file che lo importano.
Analizza vulnerabilità di sicurezza: token storage, session management,
CSRF protection. Produci un report markdown in docs/security/auth-review.md
con priorità: CRITICAL, HIGH, MEDIUM, LOW."
Tools: Read, Grep, Write
**Task 2 - Test Coverage Analysis** (usa Task tool):
Prompt: "Analizza src/app/services/auth.service.spec.ts vs auth.service.ts.
Identifica funzioni non coperte dai test. Produci lista in docs/analysis/test-gaps.md"
Tools: Read, Glob, Grep, Write
**Task 3 - Dependency Graph** (usa Task tool):
Prompt: "Mappa tutte le dipendenze di AuthService usando grep e glob.
Crea docs/analysis/auth-deps.md con grafo ASCII delle dipendenze."
Tools: Read, Glob, Grep, Write
Esegui i 3 Task in parallelo. Quando tutti completano, leggi i 3 report
e produci docs/plans/auth-refactoring.md con il piano di refactoring
consolidato, ordinato per priorità."Pokročilé vzory pracovních postupů
Smyčka naplánovat-provést-revidovat
Smyčka PER (Plan-Execute-Review) je nejrobustnějším vzorem pro komplexní pracovní postupy. Každý iterace vytváří ověřitelný artefakt před pokračováním k dalšímu. Klíč a že krok Review není volitelný: je to mechanismus, který zabraňuje šíření chyb.
Plan-Execute-Review Loop:
ITERAZIONE 1:
Plan: "Analizza AuthService e crea piano di refactoring"
Execute: Agente legge codice, scrive docs/plans/auth.md
Review: Verifica che docs/plans/auth.md esiste e ha sezioni richieste
-> PASS: procedi a iterazione 2
-> FAIL: retry Execute (max 2 volte), poi escalate
ITERAZIONE 2:
Plan: "Scrivi test per AuthService (basati sul piano)"
Execute: Agente scrive auth.service.spec.ts
Review: `npm test -- --testPathPattern=auth` deve passare
-> PASS: procedi a iterazione 3
-> FAIL: agente debug + retry
ITERAZIONE 3:
Plan: "Refactorizza AuthService (TDD: test devono restare verdi)"
Execute: Agente modifica auth.service.ts
Review: `npm test` + `tsc --noEmit` + `npm run lint`
-> PASS: procedi a iterazione 4
-> FAIL: `git checkout src/app/services/auth.service.ts` + retry
ITERAZIONE 4:
Plan: "Aggiorna componenti che usano AuthService"
Execute: Agente aggiorna LoginComponent, ProfileComponent, etc.
Review: `npm run build` (SSR build completa)
-> PASS: workflow completato
-> FAIL: rollback + analisi root cause
Metriche del Loop:
- Tasso di retry per iterazione (ideale: <20%)
- Token consumati per iterazione
- Tempo per iterazione
- Success rate complessivoMulti-Agent Code Review Pipeline
Multiagentní kanál pro kontrolu kódu a jeden z nejvyspělejších případů použití pro pracovní postupy agentů v roce 2025. Každý specializovaný agent přináší jiný pohled a agregaci vytváří obsáhlejší přehled než kterýkoli jednotlivý agent.
Pipeline Multi-Agent Code Review:
Input: Pull Request con modifiche al codebase
FASE 1 - Parallel Review (4 agenti in parallelo):
Agent A: Security Reviewer
- Cerca: SQL injection, XSS, CSRF, secrets esposti
- Tool: Read, Grep (pattern: hardcoded secrets, eval, innerHTML)
- Output: security-report.md (CRITICAL/HIGH/MEDIUM/LOW)
Agent B: Performance Analyst
- Cerca: memory leak, N+1 queries, bundle size impact
- Tool: Read, Glob, Bash (npm run analyze)
- Output: performance-report.md
Agent C: Type Safety Checker
- Cerca: any impliciti, type assertion unsafe, null check mancanti
- Tool: Read, Bash (tsc --noEmit --strict)
- Output: types-report.md
Agent D: Test Coverage
- Verifica: nuove funzioni hanno test, edge cases coperti
- Tool: Read, Bash (npm test -- --coverage)
- Output: coverage-report.md
FASE 2 - Synthesis (1 agente):
Input: i 4 report paralleli
Task: Sintetizza in PR-review.md con:
- Issues raggruppate per severita
- Blockers (nessun merge finchè non risolti)
- Suggestions (opzionali ma consigliate)
- Positive findings (cosa e fatto bene)
FASE 3 - Human Checkpoint:
Il developer legge PR-review.md e decide:
- Merge as is (zero blockers)
- Fix blockers e re-run pipeline
- Request clarification on specific issuesSamoopravné pracovní postupy: Opakujte pokus a návrat
Výrobní pracovní postupy selžou. Otázka nezní „jestli“, ale „kdy“ a „jak se uzdravíte“. Samoopravný pracovní postup implementuje strategie opakování s exponenciálním ústupem a vrácením automaticky na poslední platné kontrolní body a návrat k alternativním strategiím, když hlavní cesta opakovaně selhává.
Self-Healing Workflow Pattern:
STRATEGIA 1: Retry con Backoff
Tentativi: 1, 2, 3 (max)
Attesa: 0s, 30s, 120s
Condizione retry: errore transitorio (timeout, rate limit)
Condizione NO retry: errore logico (file non trovato, syntax error)
STRATEGIA 2: Checkpoint + Rollback
Prima di ogni modifica distruttiva:
$ git stash push -m "checkpoint-[step-id]-[timestamp]"
Se step fallisce dopo max retry:
$ git stash pop # rollback allo stato precedente
-> Notifica umano con context dell'errore
STRATEGIA 3: Alternative Path
Step principale: Refactorizza con TypeScript strict
Se fallisce 3 volte:
Fallback 1: Refactorizza con TypeScript non-strict + TODO commenti
Se fallisce ancora:
Fallback 2: Documenta il problema invece di risolvere
Escalate: crea docs/issues/[step-id]-blocked.md
STRATEGIA 4: Isolamento Fallimenti
Workflow di 10 step:
Step 1-5: completati con successo
Step 6: fallisce
-> NON annullare step 1-5
-> Salva stato "parzialmente completato"
-> Riprendi da step 6 dopo fix manuale
IMPLEMENTAZIONE in Claude Code:
"Se il comando fallisce, NON procedere al passo successivo.
Prima di ogni modifica ai file, esegui:
git stash push -m 'pre-[descrizione]'
Se dopo 2 tentativi il task non funziona, STOP.
Crea docs/blocked/[task-id].md con:
- Comando che ha fallito
- Output dell'errore completo
- Ipotesi sulla causa
- Cosa e stato completato prima del blocco"Použití nástrojů a kontextová správa
Správa kontextu je pravděpodobně nejjemnější technickou výzvou v pracovních postupech agentů. Špatně spravované kontextové okno má za následek zhoršené výsledky, zapomnětlivost a halucinace. Dobře spravované kontextové okno umožňuje hodinové relace agentů na tisících kódových základen souborů.
Tokenový rozpočet a prioritizace
Claude Code pracuje s kontextovým oknem 200 000 tokenů, ale vše spotřebuje v jediném sezení a anti-vzor. Antropický výzkum naznačuje, že operuje v rozmezí 60–80 %. maximální kontextové okno pro udržení konstantní kvality. Přes 80%, kvalita odpovědí výrazně degraduje.
Strategie di Context Management:
1. PROGRESSIVE SUMMARIZATION
Dopo ogni step completato:
"Aggiorna claude-progress.txt con un riassunto conciso di questo step:
- Cosa e stato fatto
- File modificati (lista)
- Test status (pass/fail)
- Prossimo step previsto
MAX 200 parole. Poi usa /compact per comprimere la conversazione."
2. SELECTIVE LOADING
NON leggere tutti i file del progetto all'inizio.
Leggi solo i file rilevanti per il task corrente:
- Usa Glob per identificare file per pattern
- Usa Grep per trovare dipendenze specifiche
- Leggi file solo quando necessario (lazy loading)
3. EXTERNAL STATE
File di stato persistenti (sopravvivono tra sessioni):
- claude-progress.txt: stato workflow corrente
- docs/plans/[feature].md: piano approvato
- docs/analysis/[component].md: analisi completate
Inizio sessione: "Leggi claude-progress.txt e docs/plans/
attivi. Dimmi dove siamo nel workflow e cosa devi fare ora."
4. TOOL CHAINING EFFICIENTE
INSTEAD OF: Read 20 file + analizza tutto
DO THIS:
1. Grep per pattern specifico (trova file rilevanti)
2. Glob per struttura directory
3. Read SOLO i file identificati come rilevanti
4. Elabora
Risparmio tipico: 60-70% token
5. CHECKPOINT COMPACTION
Ogni 5-10 step complessi, usa /compact in Claude Code.
Poi ricarica contesto da claude-progress.txt.
Mantieni la sesione fresca per i task restanti.Správa volání nástrojů
Každé volání nástroje spotřebovává tokeny (jak pro použití nástroje, tak pro odezvu). Efektivní řízení volání nástrojů a kritika za dlouhé pracovní postupy. Klíčový princip e dávkování: agregovat více operací do stejného volání nástroje namísto provádění mnoha samostatných volání.
Anti-Pattern: Tool Call Storm
Častou chybou je požadavek, aby agent četl soubory jeden po druhém s explicitními smyčkami.
To generuje stovky volání nástrojů a rychle saturuje kontext. Místo toho použijte vzory
jak Glob + Grep k identifikaci relevantních souborů, pak čtěte pouze ty.
Claude Code může paralelně provádět více volání nástrojů, když jsou nezávislá: toto
Tato funkce snižuje latenci o 40–60 % ve srovnání se sekvenčními hovory.
Metriky a hodnocení agentských pracovních postupů
„Funguje to“ není metrika. Chcete-li vyhodnotit a zlepšit pracovní postup agenta, potřebujete metriky kvantitativní ve čtyřech dimenzích: spolehlivost, kvalita výstupu, účinnost a bezpečnost.
Framework di Metriche per Workflow Agentici:
AFFIDABILITA
- Task Completion Rate (TCR): % task completati senza intervento umano
Target: >85% per workflow di produzione
- Retry Rate: % step che richiedono più di 1 tentativo
Target: <20% per step (>20% indica task mal specificato)
- Escalation Rate: % step escalati a umano
Target: dipende dal rischio del dominio (5-30%)
QUALITA OUTPUT
- Test Pass Rate: % test che passano dopo il workflow
Target: 100% (zero regressioni accettabili)
- Build Success Rate: % build SSR che completano senza errori
Target: 100%
- Code Review Score: punteggio da code-reviewer agent (1-10)
Target: >7 prima di merge
EFFICIENZA
- Token per Task: token consumati / task completato
Baseline: misura nelle prime 10 esecuzioni
- Latenza End-to-End: tempo totale del workflow
Ottimizza con parallelismo quando bottleneck identificato
- Cost per Feature: costo API totale / feature implementata
Target: definito dal business, tipico $0.10 - $2.00
SICUREZZA
- Destructive Operations Count: operazioni che modificano/eliminano dati
Flag ogni operazione con rm, DROP, DELETE, overwrite
- Unauthorized Tool Use: tool calls non consentite dal CLAUDE.md
Target: 0 (monitorato via hooks)
- Secret Exposure: secrets nel codice generato
Verifica automatica con grep patternsAnti-vzory, kterým je třeba se vyhnout
Literatura o agentních systémech z roku 2025 identifikovala opakující se vzorce selhání. Jejich znalost předem je nejúčinnějším způsobem, jak vybudovat robustní pracovní postupy.
1. Nadměrný rozklad
Rozdělení úkolu na příliš mnoho dílčích úkolů vytváří koordinační režii, která převažuje nad přínosem. Pokud úkol trvá méně než 5 minut a 3 000 tokenů, pravděpodobně nemá smysl ho delegovat na samostatného sub-agenta. Multiagentní výzkum ukazuje, že systémy s více než 5-7 agenty aktivní současně mívají exponenciálně vyšší chybovost (takzvaná „past na chyby 17x“ zdokumentovaná Towards Data Science, 2025).
Nadměrný rozklad: Příklad
Špatně: Vytvořte 15 dílčích agentů pro refaktorování 15 funkcí do jediné
200 řádkový soubor. Režie koordinace (nastavení kontextu pro každého agenta, sloučení
výsledky, řešení konfliktů) přesahuje dobu, kterou by zabral jeden agent.
Opravit: Jediný agent čte soubor, identifikuje 15 funkcí,
refaktorujte je postupně pomocí průběžných testů. Sub-agenti opravdu pouze pro soubory/moduly
nezávislé a významné velikosti.
2. Nedostatečná specifikace
Vágně popsané úkoly produkují nepředvídatelný výstup. "Vylepšit kód" není úkol: a naději. Každý úkol musí specifikovat: co dělat, na kterých souborech, která omezení respektovat, jak ověřit úspěch. Zdá se, že nedostatečná specifikace je příčinou č. 1 pracovních postupů fungují, ale produkují nekvalitní výstup.
3. Kontextové znečištění
Načítání příliš velkého množství irelevantního kontextu do kontextového okna (nepotřebné soubory, konverzace precedenty, podrobná dokumentace) snižuje kvalitu odpovědí. Fenomén „ztraceno v“. střed“ – dokumentovaný výzkumem LLM v roce 2024 – ukazuje, že LLM fungují méně Věnujte pozornost informacím uprostřed kontextového okna. Udržujte kontext čistý, soustředěný a strukturované.
4. Chybějící strategie vrácení zpět
Incident Replit z roku 2025 – při kterém agent smazal produkční databázi – a nejcitovanější příklad pracovního postupu bez strategie vrácení zpět. Jakákoli destruktivní operace (smazat, overwrite, DROP) musí mít mechanismus zpět: git stash, záloha, vratné transakce. „Agent věděl, co dělá“ není strategie obnovy po havárii.
5. Žádný Human-in-the-Loop
Plně automatizované pracovní postupy bez lidských kontrolních bodů jsou vhodné pouze pro úkoly nízké riziko a dobře srozumitelné. Antropický výzkum (zpráva o trendech kódování agentů z roku 2026) ukazuje, že vývojáři plně delegují (0 % dohledu) pouze 20 % úkolů: zbývajících 80 % vyžaduje alespoň jeden kontrolní bod kontroly. Navrhujte pracovní postupy pomocí Human-in- Explicitní smyčky pro architektonická rozhodnutí, nasazení a změny dat.
6. Agent bez paměti mezi relacemi
Každá nová relace Claude Code začíná od nuly. Komplexní pracovní postup (5+ hodin práce), který
nepíše vnější stav a předurčen ke ztrátě pokroku. Vždy používejte claude-progress.txt,
soubor plánu v docs/ a časté závazky jako mechanismy persistence.
Případová studie: Refactoring Angular Codebase s Agentic Workflow
Podívejme se, jak tyto principy platí pro skutečný případ: refaktoring modulu blogu portfolia Angular ze starší architektury (velké komponenty, logika v šabloně, žádné testy) na moderní architekturu (malé komponenty, samostatné služby, 80%+ pokrytí).
Kontext
- Codebase: Angular 21, SSR, ~3000 řádků v modulu blogu
- Problém: 0% pokrytí testem, více než 500 řádkových komponent, žádné oddělení obav
- Cíl: Kompletní refaktorizace bez funkčních regresí
- Omezení: aktivní výroba, tolerovány nulové prostoje
Workflow Designed
WORKFLOW: Blog Module Refactoring
FASE 0 - Setup (5 min, umano):
$ git checkout -b refactor/blog-module
Crea claude-progress.txt con stato iniziale
Crea docs/plans/blog-refactoring.md (vuoto, agente lo popolera)
FASE 1 - Analysis (agente, ~30 min):
Task: "Analizza il modulo blog completo.
Leggi tutti i file in src/app/articles/ e src/app/services/blog.service.ts.
Crea docs/analysis/blog-module.md con:
- Lista completa componenti e loro dimensioni (righe)
- Dipendenze tra componenti (chi importa chi)
- Logica duplicata identificata
- Violazioni separation of concerns
- Priorità di refactoring (impatto x sforzo)"
Review: Umano legge docs/analysis/blog-module.md e approva il piano
FASE 2 - Test Foundation (agente, ~60 min):
Task: "Scrivi test E2E per le funzionalità critiche del blog
PRIMA di qualsiasi refactoring. Usa Playwright.
Funzionalità da coprire:
- Navigazione alla lista articoli
- Apertura articolo specifico
- Navigazione serie (prev/next)
- Switch lingua IT/EN
I test devono passare sulla versione CORRENTE del codice."
Review: `npm run test:e2e` deve avere 100% dei test E2E verdi
FASE 3 - Service Extraction (agente, ~90 min, iterativo):
Task: "Estrai logica da BlogComponent in servizi separati.
UN servizio alla volta, in questo ordine:
1. BlogFilterService (filtraggio e ricerca articoli)
2. BlogSeriesService (navigazione serie)
3. BlogSEOService (meta tags per articoli)
Per ogni servizio:
a) Crea il file .service.ts con logica estratta
b) Crea il file .service.spec.ts con test unitari
c) Aggiorna BlogComponent per usare il servizio
d) Verifica: npm test passa, npm run build passa
e) Commit: git commit -am 'refactor: extract [ServiceName]'"
Review dopo ogni servizio: E2E test devono restare verdi
FASE 4 - Component Split (agente, ~120 min, iterativo):
Task: "Dividi BlogComponent (attuale 480 righe) in:
- BlogListComponent (lista articoli)
- BlogCardComponent (singola card articolo)
- BlogFilterComponent (filtri e ricerca)
- BlogPaginationComponent (paginazione)
Un componente alla volta. Stesso pattern di FASE 3:
implementa, test, verifica build, commit atomico."
Review: Umano verifica UI visivamente + E2E test
FASE 5 - Coverage Check (agente, ~30 min):
Task: "Verifica che coverage sia >80% per tutti i nuovi file.
Per ogni file sotto soglia, aggiungi test mancanti.
Produci report in docs/analysis/coverage-report.md"
Review: Coverage report + npm test
FASE 6 - Final Review (umano):
- Legge PR diff completo
- Verifica docs/analysis/coverage-report.md
- Merge su master se tutto ok
RISULTATI TIPICI DI QUESTO WORKFLOW:
Coverage: 0% -> 82%
Dimensione componenti: 480 righe -> media 95 righe
Build time: -15% (componenti più piccoli, lazy loading più efficace)
Tempo umano: ~45 min (fase 0 + review + fase 6)
Tempo agente: ~5-6 ore
Costo API stimato: $3-8 (dipende da modello)Poučení z případové studie
Z tohoto typu pracovního postupu na skutečných kódových základnách vzešly tři poznatky:
- Testování E2E před refaktoringem je nesmlouvavé. Bez sítě funkční bezpečnost, každý krok refaktoringu je skokem do tmy. Investovaný čas ve FÁZI 2 (E2E test) se 10x vyplatí vyhnout se nedetekovaným regresím.
-
Atomické commity jsou pamětí pracovního postupu. Jedno potvrzení pro každou službu/komponentu
refactored dělá rollback chirurgickým: pokud refactoring přináší problém, je hotovo
git reverttohoto jediného odevzdání bez ztráty předchozí práce. - Lidský čas klesá na 10-15 % z celkového počtu. Díky dobře navrženému pracovnímu postupu vývojář tráví většinu času kontrolou výstupu a schvalováním kontrolních bodů, nepíše kód. Toto je vyzrálé kódování vibrací: nedelegujte vše, ale delegujte strategicky udržovat dohled nad klíčovými rozhodnutími.
Fakt, který je třeba mít na paměti
21 % startupů YC Winter 2025 má kódovou základnu s více než 91 % vygenerovaného kódu od AI. Ale vyspělejší startupy z nich nepoužívají "raw" vibrační kódování: používají workflow strukturované agenty s lidskými kontrolními body, automatizovanými testy a strategiemi návratu. Rozdíl mezi „vygenerovaným kódem“ a „kvalitním softwarem vygenerovaným AI“ je přesně strukturu pracovního postupu.
Budoucnost agentských pracovních postupů
Výzkum v letech 2025–2026 ukazuje na tři směry vývoje agentních pracovních toků kontext vývoje softwaru:
- Dynamická dekompozice úkolů: Rámce jako TDAG (2025) posouvají rozklad ze statického (definovaného vývojářem) na dynamický (agent rozhoduje o struktuře pracovního postupu založeného na problému). První výsledky jsou slibné, ale vyžadují více Lidský dohled nad výrobní kódovou základnou.
- Trvalá paměť agenta: Integrace vektorových databází s agentními frameworky (LangGraph + pgvector, CrewAI + Chroma) umožňuje agentům zapamatovat si vzory napříč projekty různé, hromadící "zkušenosti" na konkrétních kódových základnách.
- Dovednosti agenta jako standard: Anthropic představil Agent Skills v roce 2025: svazky příkazů, skriptů a prostředků, které mohou agenti dynamicky načítat. Myšlenka a že dovednosti jako "Angular Expert", "Security Auditor" nebo "Performance Optimizer" se stanou opakovaně použitelné formuláře napříč týmy a organizacemi.
Závěry
Agentské pracovní postupy nejsou magie: jsou to architektura. Rozdíl mezi agentním systémem který funguje a ten, který selže, téměř vždy spočívá v kvalitě rozkladu, v jasnost kritérií úspěšnosti a spolehlivost strategie odstraňování chyb.
Čtyři vzory (sekvenční, paralelní, hierarchický, iterativní) se vzájemně nevylučují jedinečné: nejúčinnější pracovní postupy je kombinují. Hierarchický plánovač může delegovat úkoly paralelní, z nichž každý používá iterační smyčku k dosažení požadované kvality. Struktura je vždy ve službách konkrétního problému.
Nejdůležitější praktický krok, který můžete dnes udělat: přijmout složitý úkol, který obvykle vyřešit v jedné AI relaci a pokusit se ji rozložit na 3–5 testovatelných dílčích úkolů. Definujte kritéria úspěšnosti každého z nich, než začnete. Za každým přidejte lidský kontrolní bod kritická fáze. Poté změřte: Poskytuje strukturovaný pracovní postup lepší výstup? Téměř jistě ano. A to je výchozí bod, jak se stát architektem agentních systémů.
Série: Vibe Coding and Agentic Development
- 01 – Vibe Coding: The Paradigm that Change 2025
- 02 - Claude Code: Vývoj agentů z Terminálu
- 03 - Pracovní postupy agentů: Problémy s rozkladem pro AI (tento článek)
- 04 - Multi-Agent Coding: LangGraph, CrewAI a AutoGen
- 05 - Testování kódu generovaného AI
- 06 - Prompt Engineering pro IDE a generování kódu
- 07 - Bezpečnost v kódování vibrací: Rizika a zmírnění
- 08 - Budoucnost vývoje agentů v roce 2026
Související statistiky
- Claude a protokol kontextu modelu (MCP) - Jak MCP rozšiřuje možnosti agentů pomocí externích nástrojů
- Zabezpečení webu: API a zranitelnosti - Specifická bezpečnostní rizika v agentních pracovních postupech