Artykuły
Przestań bezmyślnie robić fan-out: czterowarstwowa architektura orkiestracji Claude Haiku 5.5 w praktyce
Claude Haiku 5.5 jest szybki i tani, ale równoległe rzucanie na niego wszystkich zadań tylko wzmacnia błędne oceny, stronniczość sędziego i ryzyko ataku na łańcuch dostaw (Supply Chain). Ten tekst rozbiera na części warstwową architekturę: osąd Fable, orkiestracja Opus, implementacja Sonnet i Haiku, weryfikacja w CI i odbiór przez Opus, oraz mówi, które zadania naprawdę warto rozdzielać fan-outem.
· 6 min czytania
Claude Haiku 5.5 zadebiutował 7 października 2026 roku. Przy promptach do 100 tys. tokenów kosztuje jedną dwudziestą ceny Sonneta 5.5, a jego opóźnienie jest najniższe w obecnej generacji Claude.
Tani i szybki – łatwo wpaść na pomysł: rozbić wszystkie zadania programistyczne, rzucić je równolegle na grupę Haiku i uznać sprawę za załatwioną.
Przy prototypie to może zadziałać. W prawdziwym środowisku inżynierskim szybko uderzysz w trzy problemy:
- Małe modele słabo radzą sobie z niejednoznacznością. Oficjalnie Haiku 5.5 jest przeznaczony do dużych ilości lekkich zadań: klasyfikacji, ekstrakcji, routingu i subagentów. Gdy wymaganie ma biznesową niejednoznaczność i wymaga kontekstu całego systemu, łatwo oddaje wynik, który wygląda na kompletny, a w rzeczywistości zmierza w złą stronę.
- Gdy model wybiera odpowiedź, pojawia się stronniczość sędziego. Jeśli dasz dużemu modelowi do przeczytania kilkadziesiąt wyników, chętnie wybierze wersję, która „ma ładną architekturę", zamiast takiej, której logika i wykonanie są naprawdę poprawne.
- Uprawnienia rosną razem z liczbą Workerów. Jeśli równoległe subagenty mogą same instalować pakiety lub zmieniać konfigurację, to N Workerów oznacza N potencjalnych wejść dla złośliwych pakietów.
Dlatego przeszedłem na orkiestrację warstwową (Hierarchical Orchestration): każda warstwa robi tylko to, w czym jest dobra, a równoległość Haiku wykorzystuję wyłącznie tam, gdzie naprawdę jest potrzebna.
Wniosek na początek: Fable myśli, Opus rozdziela i odbiera, Sonnet odpowiada za główną implementację, a Haiku robi tylko zadania mechaniczne i zadania wyszukiwawcze, które da się zweryfikować automatycznie. Kandydackie rozwiązania najpierw przechodzą CI, dopiero potem trafiają do modelu.
Cztery warstwy: osąd, orkiestracja, weryfikacja, odbiór#
Wejście wymagań
│
▼
[Warstwa osądu] Fable: decyzje architektoniczne, podział zadań, kryteria odbioru
│
▼
[Warstwa orkiestracji] Opus Main Session: tylko rozdziela, nie dzieli ponownie
├─► Ścieżka A: złożone, ale o jasnych granicach ──► implementacja przez Sonneta
├─► Ścieżka B: zadania mechaniczne ──► pojedynczy Haiku
├─► Ścieżka C: wyszukiwawcze, wiele rozwiązań ──► wiele Haiku, każdy we własnym Git Worktree
│
▼
[Warstwa weryfikacji] Build, Type Check, Test, Benchmark (ze ścieżki C zostają tylko 2–3 najlepsze)
│
▼
[Warstwa odbioru] Opus zbiega wyniki według kryteriów odbioru
Porażka oznacza eskalację: Haiku poprawia 2 razy i nadal nie przechodzi ➔ Sonnet ➔ zwrot do Opusa
O tym, w której warstwie stoi dany model, decydują oficjalne przeznaczenie i cena. Poniżej liczby z oficjalnej dokumentacji Anthropic z 8 października 2026 roku, ceny w dolarach za milion tokenów:
| Model |
Oficjalne przeznaczenie |
Opóźnienie |
Cena Input / Output |
| Claude Fable 5.1 |
Trudne rozumowanie i długotrwała praca agentowa |
Wolniejszy |
$10 / $50 |
| Claude Opus 5.5 |
Długotrwałe agentowe programowanie i praca z wiedzą |
Średnie |
$4 / $20 |
| Claude Sonnet 5.5 |
Najlepsze połączenie szybkości i możliwości |
Szybki |
$2 / $10 |
| Claude Haiku 5.5 |
Duże ilości lekkich zadań: klasyfikacja, ekstrakcja, routing i subagenty |
Najszybszy |
od $0.10 / $0.50 |
Cena Haiku 5.5 ma dwa progi: gdy prompt przekracza 100 tys. tokenów, wynosi $0.50 / $2.50.
Warstwa osądu: Fable odpowiada za decyzje architektoniczne i kryteria odbioru#
Nie każde wymaganie potrzebuje Fable. To najdroższa i najwolniejsza warstwa, więc używam jej tylko wtedy, gdy wymaganie jest niejednoznaczne, dotyczy integracji między systemami albo wymaga kluczowej decyzji architektonicznej.
Fable ma dostarczyć trzy rzeczy:
- projekt rozwiązania
- podział zadań
- kryteria odbioru (Acceptance Criteria) dla każdego podzadania, które da się zweryfikować testami
Rozumowanie i dekompozycję powinna wykonać ta sama warstwa. Tylko ta, która potrafi przemyśleć ślepe punkty systemu, wytnie podzadania o czystych granicach; jeśli architekturę oddasz A, a podział B, definicje interfejsów zwykle się rozmywają.
Wyjątkiem są zadania z zakresu bezpieczeństwa. Wszystkie modele Claude obecnej generacji mają klasyfikatory bezpieczeństwa, a gdy żądanie zostanie zablokowane, zwracają stop_reason: "refusal"; uzasadniona praca z zakresu bezpieczeństwa także bywa blokowana przez pomyłkę. Klasyfikator Fable 5.1 obejmuje większość treści związanych z bezpieczeństwem, a oficjalnie podano, że nie został zaprojektowany z myślą o tej dziedzinie; Opus 5.5 natomiast pozwala szukać podatności w kodzie źródłowym. Dlatego przy wymaganiach w rodzaju naprawy luk bezpieczeństwa wstępną analizę oddaję wprost Opusowi.
Warstwa orkiestracji: Opus tylko rozdziela, nie dzieli ponownie#
Opus jest Main Session i odpowiada za routing oraz przydzielanie pracy. Ta warstwa nie podważa architektury i nie robi drugiego podziału.
- Ścieżka A, złożone, ale o jasnych granicach: zadania ze skomplikowaną logiką, ale z już jasno zdefiniowanymi granicami interfejsów, trafiają do Sonneta. To główny koń roboczy implementacji.
- Ścieżka B, proste zadania mechaniczne: kod szablonowy (Boilerplate), zmiana nazw zmiennych, dopisanie prostych testów jednostkowych i dokumentacji trafiają do jednego Haiku.
- Ścieżka C, zadania wyszukiwawcze i optymalizacyjne: dopiero tu uruchamiam Fan-out – strojenie wydajności, różne sposoby zapisu złożonego SQL lub Regexa, szukanie przyczyn Flaky Test. Wysyłam wiele Haiku, a każdy próbuje innego rozwiązania we własnym, odizolowanym Git Worktree.
Niezależnie od ścieżki wynik musi przejść przez warstwę weryfikacji.
Warstwa weryfikacji: najpierw maszyna, potem model#
Bardzo częsta praktyka to oddanie całego równolegle wytworzonego kodu Opusowi lub Sonnetowi z prośbą o przegląd przez prompt.
Problem w tym, że czytając kod, model łatwo daje się przyciągnąć odpowiedzi ładnie sformatowanej i z pełnymi deklaracjami typów, co nie znaczy, że przeszła ona testy graniczne. Dlatego kandydackie rozwiązania muszą najpierw przejść przez maszynę:
- Build i Type Check: kod się kompiluje, typy są poprawne
- Unit / Integration Tests: testy jednostkowe i integracyjne przechodzą
- Benchmark / Profiling: pomiar wydajności i pamięci
Co nie przejdzie testów automatycznych, odpada od razu. Ze ścieżki C Opus przegląda tylko 2–3 najlepsze rozwiązania, które przeszły kontrole i mają najlepsze wskaźniki, co oszczędza też context window i tokeny.
Warstwa odbioru: Opus zbiega wyniki, a porażka oznacza eskalację#
Na końcu Opus zbiega wyniki według kryteriów odbioru zdefiniowanych w warstwie osądu. Gdy Worker utknie, eskalacja (Escalation Path) idzie w górę po kolei:
- Gdy Haiku zawiedzie i 2 automatyczne poprawki nadal nie przechodzą, przestaje ponawiać próby.
- Naprawę przejmuje Sonnet.
- Jeśli Sonnet też nie przechodzi odbioru, zwykle oznacza to sprzeczność w podziale zadania lub w założeniach wyjściowych. Zadanie wraca do Opusa, który ocenia, czy odesłać je do Fable w celu ponownego podziału.
Trzy zasady przed wdrożeniem na produkcję#
Nie rób fan-outu na ślepo#
Proste zadania nie potrzebują wielu Workerów, a mocno niejednoznacznych małe modele nie rozwiążą. Tylko zadania wyszukiwawcze, w których „przestrzeń rozwiązań jest duża" i „da się je szybko zweryfikować testami automatycznymi", warto powierzać wielu równolegle działającym Haiku.
Izoluj środowisko i blokuj Lockfile#
Git Worktree izoluje zmiany w kodzie, żeby równoległe Workery nie nadpisywały sobie plików; nie ogranicza sieci ani zakresu, do którego program ma dostęp. Aby bronić się przed Supply Chain Attack, potrzebny jest też sandbox oraz zakaz samodzielnego instalowania niezweryfikowanych pakietów i zmieniania Lockfile przez Workery. Swobodne przyznanie uprawnień do instalacji oznacza, że Agent wniesie do repozytorium pakiety i skrypty nieznanego pochodzenia.
Odbieraj po zmierzonych danych, nie po opinii modelu#
Wyniki testów, pokrycie, zużycie pamięci i opóźnienie to podstawa, którą można odtworzyć i porównać. Tekstowa ocena modelu może być wskazówką, ale nie służy do odbioru jakości kodu.
Tani model trzeba użyć we właściwym miejscu#
Haiku 5.5 sprawia, że równoległość jest tania, ale sama równoległość nie sprawia, że wynik jest poprawny. Dopiero gdy rozdzielisz osąd, przydział, weryfikację i odbiór, tanio i szybko staje się prawdziwą przewagą.
Ta warstwowość to w gruncie rzeczy ten Graph, o którym piszę w tekście AI Agent to w gruncie rzeczy zespół zwinny: kto robi pierwszy, komu przekazuje po skończeniu, dokąd trafia sprawa, gdy coś pójdzie nie tak.