03 – Agentyczne przepływy pracy: rozkładanie problemów dla sztucznej inteligencji
Jest taki moment, w którym sztuczna inteligencja przestaje być asystentką, a staje się współpracownikiem: kiedy przestaniesz pytać „napisz tę funkcję” i zaczynasz ją pytać „rozwiązać ten problem". Tym mentalnym przeskokiem, od pojedynczej instrukcji do złożonego zadania, jest serce bogowie Przepływy pracy agenta. To właśnie tam znajduje się większość programistów utknie, ponieważ zbudowanie skutecznego, agentowego przepływu pracy wymaga głębokiej zmiany paradygmatu: nie chodzi tu o dłuższe podpowiedzi, ale o architekturę.
W 2025 roku 92% amerykańskich programistów wykorzystuje w swojej codziennej pracy narzędzia AI (Ankieta dla programistów Stack Overflow 2025), ale tylko część z nich faktycznie korzysta z potencjał systemów agentowych. Problemem nie jest dostęp do technologii, lecz jej brak przejrzystych wzorów architektonicznych dla rozkładać złożone problemy w zadaniach które agent AI może rozwiązać w sposób niezawodny, weryfikowalny i powtarzalny.
W tym artykule wspólnie zbudujemy głębokie zrozumienie agentycznych przepływów pracy: daj spokój podstawowe wzorce (sekwencyjne, równoległe, hierarchiczne, iteracyjne) do wdrożenia ćwicz z Claude Code, przechodząc przez zarządzanie kontekstem, metryki jakości i anty-wzorce, które przekształcają obiecujący przepływ pracy w zawodny system. Całość z prawdziwymi studiami przypadków i działającym kodem.
Czego się nauczysz
- Cztery podstawowe wzorce dekompozycji: sekwencyjny, równoległy, hierarchiczny, iteracyjny
- Architektura agentycznego przepływu pracy: Planista, Wykonawca, Recenzent, Pamięć
- Jak zorganizować CLAUDE.md, aby prowadził agentów przy prawdziwych projektach
- Pętla Plan-Wykonaj-Przegląd i przepływy pracy samonaprawy
- Zarządzanie narzędziami i kontekstem w przypadku długich sesji agentów
- Metryki służące do oceny jakości przepływu pracy agenta
- Najbardziej niebezpieczne anty-wzorce i jak ich unikać
- Studium przypadku: refaktoryzacja bazy kodu Angular przy użyciu przepływu pracy agenta
Co to jest agentyczny przepływ pracy
Un Przepływ pracy agenta oraz uporządkowaną sekwencję operacji, w której jedna lub więcej Agenci AI planują, realizują i weryfikują działania, aby osiągnąć złożony cel. A W przeciwieństwie do pojedynczego wywołania LLM, agentyczny przepływ pracy ma pamięć między krokami, z której może korzystać narzędzia (system plików, terminal, web, API), mogą delegować podzadania wyspecjalizowanym agentom i potrafi dostosować się do błędów bez interwencji człowieka.
Kluczowa różnica w porównaniu z „naiwnym” kodowaniem wibracji polega na tym przemyślana konstrukcja. Poproszenie Claude’a o „refaktoryzację tej bazy kodu” daje mierne rezultaty. Budowanie przepływu pracy który: (1) analizuje bazę kodu, (2) identyfikuje komponenty do refaktoryzacji w kolejności priorytetu, (3) refaktoryzuj po jednym komponencie za pomocą testów regresyjnych, (4) najpierw testuj każdy krok kontynuować, daje profesjonalne rezultaty. Różnica i rozkład.
Definicja operacyjna
Agentyczny przepływ pracy, np niezawodny gdy: każdy krok jest niezależnie weryfikowalny, niepowodzenie jednego kroku nie psuje całego przepływu pracy, końcowego i deterministycznego wyniku w stosunku do danych wejściowych, a operator może w dowolnym momencie sprawdzić i skorygować przepływ pracy punkt kontrolny. Definicja ta pochodzi z ram Anthropic „Budowanie skutecznych agentów” (2024) i pozostaje kompasem do oceny każdego wdrożenia.
Rozkład problemów: rdzeń agentycznego przepływu pracy
Badania TDAG (Dekompozycja zadań i generowanie agentów, 2025) wykazały tę jakość rozkładu i najbardziej przewidywalny czynnik sukcesu systemu wieloagentowego: zła dekompozycja powoduje wykładniczą propagację błędów w kolejnych krokach, podczas gdy prawidłowy rozkład izoluje awarie i umożliwia odzyskanie.
Istnieją cztery podstawowe wzorce rozkładu, każdy odpowiedni do różnych typów problemów:
Wzór 1: Sekwencyjny (łańcuchowy)
Najprostszy wzór: każde zadanie zależy od wyniku poprzedniego. Nadaje się do liniowych przepływów pracy gdzie kolejność jest istotna semantycznie (np. analiza -> projekt -> wdrożenie -> 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. DocumentationWzorzec 2: Równolegle (zbieranie rozproszone)
Wiele niezależnych zadań jest realizowanych jednocześnie przez odrębnych agentów za pomocą agregatora który gromadzi i podsumowuje wyniki. Drastycznie zmniejsza opóźnienia, ale wymaga, aby m.in podzadania są naprawdę niezależne (nie ma współdzielenia zmiennego stanu).
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 findingsWzorzec 3: Hierarchiczny (przełożony-pracownik)
Agent nadzorujący rozkłada problem na podzadania i deleguje wyspecjalizowanym pracownikom. Robotnicy mogą z kolei mieć podwykonawców. I najpotężniejszy wzór dla dużych problemów ale także najbardziej skomplikowany do debugowania. LangGraph udokumentował ten wzorzec najlepiej przyjęte w 2025 r. dla systemów korporacyjnych.
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)Wzór 4: Iteracyjny (ReAct / Refleksja)
Agent działa w pętli: wykonuje akcję, obserwuje wynik, zastanawia się nad bieżącym stanem i decyduje o kolejnym kroku. I wzór Framework ReAct (Rozumowanie + Aktorstwo) i jego rozszerzenie Refleksja (co dodaje wyraźną krytykę). Nadaje się do problemów eksploracyjne, gdy ścieżka rozwiązania nie jest znana a priori.
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 agentycznego przepływu pracy
Niezależnie od wybranego wzorca, dojrzały, agentowy przepływ pracy składa się z czterech komponentów podstawy. Zrozumienie ich jest warunkiem koniecznym do zbudowania solidnych systemów w środowisku produkcyjnym.
1. Planista
Planista otrzymuje cel wysokiego poziomu i przekształca go w ustrukturyzowany plan: sekwencję (lub DAG) podzadań z zależnościami, przypisaniem do agentów, kryteriami sukcesu dla każdego kroku i oszacowanie zasobów (budżet tokenowy, niezbędne narzędzia). Dobry planista tworzy plany sprawdzalny: każdy krok ma dobrze zdefiniowany oczekiwany wynik.
2. Wykonawca
Executor przejmuje od Planisty poszczególne zadania i realizuje je korzystając z dostępnych narzędzi: systemu plików,
bash, wyszukiwarka internetowa, API. Każdy wyspecjalizowany wykonawca (agent zaplecza, agent testowy, agent dokumentów) ma
dostęp tylko do narzędzi niezbędnych dla swojej domeny, kierując się zasadą
najmniejszy przywilej. Claude Code implementuje to poprzez system
uprawnienia i niestandardowi podagenci z allowedTools konfigurowalne.
3. Recenzent
Recenzent weryfikuje, czy wyniki każdego Wykonawcy spełniają określone kryteria sukcesu z Planera. To nie jest proste stwierdzenie „wydaje się ok”: kontroler jakości przeprowadza automatyczne testy, analiza statyczna, kontrole regresji. Recenzent może zatwierdzić (przepływ prac), zażądaj zmian (ponawianie prób przez wykonawcę) lub eskaluj do człowieka (obowiązkowy punkt kontrolny).
4. Pamięć
Pamięć zarządza kontekstem na poszczególnych etapach przepływu pracy. Ma dwa poziomy:
- Krótkoterminowe (w kontekście): zawartość bieżącego okna kontekstowego, łącznie z wynikami poprzednich etapów. Ograniczone dostępnymi tokenami.
-
Długoterminowe (zewnętrzne): plik stanu (np.:
claude-progress.txt), bazy danych, historia git. Umożliwia wznawianie przerwanych przepływów pracy pomiędzy różnymi sesjami.
Wzorzec claude-progress.txt
Anthropic zaleca stosowanie a claude-progress.txt w katalogu głównym projektu
dla pamięci międzysesyjnej. Agent inicjujący zapisuje stan przepływu pracy co
punkty kontrolne; następny agent czyta ten plik, aby zrozumieć, gdzie jest praca i co
musi zrobić. W połączeniu z git log, zapewnia pełny kontekst bez
nasycić okno kontekstowe.
Praktyczna implementacja z Claude Code
Claude Code oferuje trzy główne narzędzia do tworzenia przepływów pracy agentów: plik
CLAUDE.md kierować zachowaniem agenta, tj
Narzędzia zadań delegować podwykonawców, oraz i niestandardowi agenci
(zdefiniowane w .claude/agents/) według specjalizacji. Zobaczmy, jak je połączyć.
Struktura CLAUDE.md dla przepływów pracy agenta
Plik CLAUDE.md to „konstytucja” Twojego projektu dla agentów AI. CLAUDE.md Zaprojektowany dla agentycznych przepływów pracy zawiera nie tylko informacje o projekcie, ale także struktura samego przepływu pracy: jacy agenci istnieją, jak koordynują, jakie są kryteria sukcesu dla każdej fazy.
# 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 chiarimentiSzybka inżynieria rozkładu zadań
Jakość rozkładu zależy bezpośrednio od jakości początkowego podpowiedzi. Oto przetestowany szablon, który pomaga agentowi w rozkładzie złożonych zadań:
# 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"
}Korzystanie z narzędzia zadań dla podagentów
Claude Code udostępnia narzędzie Zadania umożliwiające delegowanie pracy podwykonawcom. Każdy sub-agent działa w izolowanym kontekście z własnym oknem kontekstowym, które pozwala zarządzać przepływami pracy przekraczające limity pojedynczej sesji. Badania antropiczne (2026 Agentic Coding Raport Trendów) wskazuje, że najskuteczniejszy wzorzec wykorzystuje Opus do orkiestracji i Sonnet dla pracowników, obniżając koszty o 40-60% przy zachowaniu jakości.
# 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à."Zaawansowane wzorce przepływu pracy
Pętla Planuj – Wykonaj – Przegląd
Pętla PER (Plan-Execute-Review) to najbardziej niezawodny wzorzec dla złożonych przepływów pracy. Każdy iteracja generuje weryfikowalny artefakt przed przejściem do następnej. Klucz oraz że etap przeglądu nie jest opcjonalny: jest to mechanizm zapobiegający rozprzestrzenianiu się błędów.
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 complessivoProces przeglądu kodu wieloagentowego
Potok przeglądu kodu obejmujący wielu agentów i jeden z najbardziej dojrzałych przypadków użycia przepływów pracy agentów w roku 2025. Każdy wyspecjalizowany agent wnosi inną perspektywę i agregację zapewnia bardziej wszechstronną recenzję niż jakikolwiek pojedynczy 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 issuesSamonaprawiające się przepływy pracy: ponowna próba i powrót
Przepływy pracy produkcyjnej zawodzą. Pytanie nie brzmi „czy”, ale „kiedy” i „jak wyzdrowiejesz”. Samonaprawiający się przepływ pracy implementuje strategie ponawiania prób z wykładniczym wycofywaniem i wycofywaniem automatycznie do ostatnich ważnych punktów kontrolnych i powrót do alternatywnych strategii, gdy główna ścieżka wielokrotnie zawodzi.
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"Użycie narzędzi i zarządzanie kontekstem
Zarządzanie kontekstem to prawdopodobnie najbardziej subtelne wyzwanie techniczne w przepływach pracy agentów. Źle zarządzane okno kontekstowe powoduje pogorszenie wyników, zapomnienie i halucynacje. Dobrze zarządzane okno kontekstowe umożliwia wielogodzinne sesje agentów w tysiącach baz kodu plików.
Budżet tokenów i ustalanie priorytetów
Claude Code działa z oknem kontekstowym zawierającym 200 000 tokenów, ale wykorzystuje je wszystkie w jednym sesja i anty-wzorzec. Badania antropiczne sugerują działanie w przedziale 60-80%. maksymalne okno kontekstowe, aby utrzymać stałą jakość. Ponad 80% jakość odpowiedzi znacznie się 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.Zarządzanie wywołaniami narzędzi
Każde wywołanie narzędzia zużywa tokeny (zarówno za użycie narzędzia, jak i za odpowiedź). Efektywne zarządzanie wywołań narzędzi i krytyki długich przepływów pracy. Kluczowa zasada tj dozowanie: agreguj wiele operacji w to samo wywołanie narzędzia, zamiast wykonywać wiele oddzielnych wywołań.
Anty-wzorzec: Burza wywołań narzędzi
Częstym błędem jest proszenie agenta o odczytywanie plików pojedynczo z jawnymi pętlami.
Generuje to setki wywołań narzędzi i szybko nasyca kontekst. Zamiast tego użyj wzorów
jak Glob + Grep aby zidentyfikować odpowiednie pliki, a następnie przeczytaj tylko te.
Claude Code może wykonywać wiele wywołań narzędzi równolegle, jeśli są one niezależne: to
Funkcja zmniejsza opóźnienia o 40-60% w porównaniu do połączeń sekwencyjnych.
Metryki i ocena agentycznych przepływów pracy
„To działa” nie jest wskaźnikiem. Aby ocenić i ulepszyć przepływ pracy agenta, potrzebujesz metryk ilościowe w czterech wymiarach: niezawodność, jakość wyjściowa, wydajność i bezpieczeństwo.
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 patternsAnty-wzorce, których należy unikać
W literaturze dotyczącej systemów agentowych z 2025 r. zidentyfikowano powtarzające się wzorce niepowodzeń. Znajomość ich z wyprzedzeniem jest najskuteczniejszym sposobem tworzenia solidnych przepływów pracy.
1. Nadmierny rozkład
Podział zadania na zbyt wiele podzadań powoduje obciążenie koordynacji, które przewyższa korzyści. Jeśli zadanie zajmuje mniej niż 5 minut i 3000 tokenów, prawdopodobnie nie ma sensu go delegować oddzielnemu subagentowi. Badania wieloagentowe pokazują, że systemy posiadające więcej niż 5-7 agentów aktywne jednocześnie mają tendencję do wykładniczo wyższego poziomu błędów (tzw. „pułapka błędów 17x” udokumentowana w Towards Data Science, 2025).
Nadmierny rozkład: przykład
Zło: Utwórz 15 sub-agentów, aby zrefaktoryzować 15 funkcji w jedną
Plik 200 linii. Narzut koordynacyjny (konfiguracja kontekstu dla każdego agenta, połączenie
wyniki, zarządzanie konfliktami) przekracza czas, jaki zająłby pojedynczy agent.
Prawidłowy: Pojedynczy agent czyta plik, identyfikuje 15 funkcji,
refaktoryzuj je sekwencyjnie za pomocą testów pośrednich. Tak naprawdę subagenci tylko dla plików/modułów
niezależny i znacznych rozmiarów.
2. Niedostateczna specyfikacja
Niejasno opisane zadania dają nieprzewidywalny wynik. „Ulepszenie kodu” nie jest zadaniem: i nadzieja. Każde zadanie musi określać: co robić, na jakich plikach, jakich ograniczeń należy przestrzegać, jak zweryfikować sukces. Wydaje się, że niedostateczna specyfikacja jest główną przyczyną przepływów pracy działają, ale dają wydruki o niskiej jakości.
3. Kontekst Zanieczyszczenie
Ładowanie zbyt dużej ilości nieistotnego kontekstu do okna kontekstowego (niepotrzebne pliki, rozmowy precedensy, pełna dokumentacja) pogarszają jakość odpowiedzi. Zjawisko „zagubienia”. środek” – udokumentowane badaniami LLM w 2024 r. – pokazuje, że LLM osiągają mniejsze wyniki Zwróć uwagę na informacje znajdujące się pośrodku okna kontekstowego. Utrzymuj kontekst w czystości i skupieniu i uporządkowany.
4. Brakująca strategia wycofywania
Incydent Replit z 2025 r. – w którym agent usunął produkcyjną bazę danych – i najczęściej cytowany przykład przepływu pracy bez strategii wycofywania zmian. Wszelkie destrukcyjne operacje (usuwanie, overwrite, DROP) musi mieć mechanizm cofania: git stash, kopia zapasowa, transakcje odwracalne. „Agent wiedział, co robi” nie jest strategią odzyskiwania po awarii.
5. Żadnych ludzi w pętli
W pełni zautomatyzowane przepływy pracy bez ludzkich punktów kontrolnych nadają się tylko do zadań niskie ryzyko i dobrze rozumiane. Badania antropiczne (raport dotyczący trendów w kodowaniu agentycznym z 2026 r.) pokazuje, że programiści w pełni delegują (0% nadzoru) tylko 20% zadań: pozostałe 80% wymaga co najmniej jednego punktu kontrolnego przeglądu. Projektuj przepływy pracy za pomocą Human-in- Wyraźne pętle dotyczące decyzji architektonicznych, wdrożeń i zmian danych.
6. Agent bez pamięci między sesjami
Każda nowa sesja Claude Code zaczyna się od zera. Złożony przepływ pracy (ponad 5 godzin pracy), który
nie zapisuje stanu zewnętrznego i jest skazany na utratę postępu. Zawsze używaj claude-progress.txt,
plik planu w docs/ i częste zatwierdzenia jako mechanizmy trwałości.
Studium przypadku: Refaktoryzacja bazy kodu Angular za pomocą agentycznego przepływu pracy
Zobaczmy jak te zasady odnoszą się do prawdziwego przypadku: refaktoryzacji modułu bloga portfela Angular ze starszej architektury (duże komponenty, logika w szablonie, bez testów) do nowoczesnej architektury (małe komponenty, oddzielne usługi, pokrycie 80%+).
Kontekst
- Baza kodu: Angular 21, SSR, ~3000 linii w module bloga
- Problem: 0% pokrycia testowego, ponad 500 komponentów wierszy, brak rozdzielenia problemów
- Cel: Całkowita refaktoryzacja bez regresji funkcjonalnych
- Ograniczenie: aktywna produkcja, tolerowane zero przestojów
Zaprojektowany przepływ pracy
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)Wnioski wyciągnięte ze studium przypadku
Z tego typu przepływu pracy na rzeczywistych bazach kodu wyłoniły się trzy spostrzeżenia:
- Testowanie E2E przed refaktoryzacją nie podlega negocjacjom. Bez sieci bezpieczeństwo funkcjonalne, każdy etap refaktoryzacji to skok w ciemność. Zainwestowany czas w FAZIE 2 (test E2E) opłaca się 10x w uniknięciu niezauważonych regresji.
-
Zatwierdzenia atomowe to pamięć przepływu pracy. Jedno zatwierdzenie dla każdej usługi/komponentu
refaktoryzacja sprawia, że wycofanie jest chirurgiczne: jeśli refaktoryzacja powoduje problem, zostaje to zrobione
git reverttego pojedynczego zatwierdzenia bez utraty poprzedniej pracy. - Czas ludzki spada do 10-15% całości. Dzięki dobrze zaprojektowanemu procesowi pracy, programista spędza większość czasu na przeglądaniu wyników i zatwierdzaniu punktów kontrolnych, nie pisać kodu. To jest kodowanie wibracji dojrzałych: nie deleguj wszystkiego, ale deleguj strategiczne utrzymanie nadzoru nad kluczowymi decyzjami.
Fakt, o którym należy pamiętać
21% startupów YC Winter 2025 ma bazę kodu, z której wygenerowano ponad 91%. przez sztuczną inteligencję. Ale bardziej dojrzałe startupy nie używają „surowego” kodowania wibracji: korzystają z przepływu pracy ustrukturyzowani agenci z ludzkimi punktami kontrolnymi, automatycznymi testami i strategiami wycofywania zmian. Różnica między „wygenerowanym kodem” a „oprogramowaniem wysokiej jakości generowanym przez sztuczną inteligencję” jest dokładnie taka strukturę przepływu pracy.
Przyszłość agentycznych przepływów pracy
Badania przeprowadzone w latach 2025-2026 wskazują na trzy kierunki ewolucji agentycznych przepływów pracy w kontekst tworzenia oprogramowania:
- Dynamiczna dekompozycja zadań: Ramy takie jak TDAG (2025) przenoszą rozkład ze statycznego (zdefiniowanego przez programistę) na dynamiczny (agent decyduje o strukturze przepływu pracy w oparciu o problem). Pierwsze wyniki są obiecujące, ale wymagają więcej Nadzór ludzki nad bazą kodu produkcyjnego.
- Trwała pamięć agenta: Integracja wektorowych baz danych ze frameworkami agentowymi (LangGraph + pgvector, CrewAI + Chroma) pozwala agentom zapamiętywać wzorce w różnych projektach różne, gromadzące „doświadczenie” na określonych bazach kodów.
- Umiejętności agenta w standardzie: Anthropic wprowadził umiejętności agenta w 2025 r.: pakiety instrukcji, skryptów i zasobów, które agenci mogą ładować dynamicznie. Pomysł i że umiejętności takie jak „Ekspert Angular”, „Audytor bezpieczeństwa” czy „Optymalizator wydajności” stają się formularze wielokrotnego użytku w zespołach i organizacjach.
Wnioski
Agentyczne przepływy pracy to nie magia: to architektura. Różnica między systemem agentowym to działa, a to, co zawodzi, prawie zawsze zależy od jakości rozkładu, od jasność kryteriów sukcesu i solidność strategii usuwania błędów.
Cztery wzorce (sekwencyjny, równoległy, hierarchiczny i iteracyjny) nie wykluczają się wzajemnie wyjątkowe: najskuteczniejsze przepływy pracy łączą je. Planista hierarchiczny może delegować zadania równolegle, z których każdy wykorzystuje pętlę iteracyjną, aby osiągnąć wymaganą jakość. Struktura służy zawsze konkretnemu problemowi.
Najważniejszy praktyczny krok, jaki możesz dzisiaj podjąć: podejmij złożone zadanie, które zwykle rozwiązać w jednej sesji AI i spróbować rozłożyć to na 3-5 testowalnych podzadań. Zdefiniuj kryteria sukcesu dla każdego z nich, zanim zaczniesz. Po każdym dodaj ludzki punkt kontrolny faza krytyczna. Następnie zmierz: czy ustrukturyzowany przepływ pracy zapewnia lepsze wyniki? Prawie na pewno tak. To jest punkt wyjścia do zostania architektem systemów agentowych.
Seria: Kodowanie Vibe i rozwój agentyczny
- 01 – Kodowanie Vibe: paradygmat, który zmienił rok 2025
- 02 - Kod Claude'a: Rozwój agenta z terminala
- 03 – Agentyczne przepływy pracy: rozkładanie problemów dla sztucznej inteligencji (ten artykuł)
- 04 - Kodowanie wieloagentowe: LangGraph, CrewAI i AutoGen
- 05 - Testowanie kodu wygenerowanego przez sztuczną inteligencję
- 06 - Szybka inżynieria dla IDE i generowania kodu
- 07 – Bezpieczeństwo w kodowaniu Vibe: ryzyko i środki łagodzące
- 08 - Przyszłość rozwoju agentycznego w roku 2026
Powiązane spostrzeżenia
- Claude i protokół kontekstu modelu (MCP) - Jak MCP rozszerza możliwości agenta za pomocą narzędzi zewnętrznych
- Bezpieczeństwo sieciowe: API i luki w zabezpieczeniach - Specyficzne zagrożenia bezpieczeństwa w przepływach pracy agenta