Anatomia Claw: 84 haki jako warstwa orkiestracji

Napisanie pierwszego haka zajęło cztery minuty. Blokował on model przed sugerowaniem produktów OpenAI w przepływie pracy wyłącznie dla Anthropic. Dwa miesiące później ten pojedynczy hak zamienił się w 84. Te 84 haki połączone były z 43 umiejętnościami, 19 wyspecjalizowanymi agentami i 30 modułami bibliotek. W pewnym momencie zbiór ten przestał być zestawem skryptów i stał się warstwą orkiestracji.

„Claw” to warstwa orkiestracji zbudowana na szczycie CLI agenta AI, obsługująca harmonogramowanie, zarządzanie kontekstem, routing narzędzi oraz egzekwowanie jakości. Rośnie ona organicznie z rozwiązywania indywidualnych awarii, a nie z odgórnego projektowania. Architektura ta odwzorowuje pięć funkcji wskazanych przez Karpathy’ego, przy czym oddzielenie planowania od wykonania wyłania się jako naturalna właściwość systemów opartych na hakach.

Nie zaprojektowałem tego w ten sposób. Nikt nie siada i nie mówi: „zbuduję 15 000 linii infrastruktury dla agentów”. Rozwiązuje się jeden problem. Potem kolejny. Potem rozwiązuje się problem interakcji między problemami. Zanim zauważy się architekturę, ona już istnieje.

Andrej Karpathy również to zauważył. W lutym 2026 roku opisał „Claws” jako nową warstwę obliczeniową: orkiestrację, harmonogramowanie, zarządzanie kontekstem i routing narzędzi zbudowane na szczycie agentów LLM, tak samo jak agenci są zbudowani na szczycie LLMs.¹ To ujęcie skrystalizowało coś, co praktycy budowali bez nazywania. Niniejszy wpis stanowi anatomię jednego z takich systemów: co zawiera, jak się rozwijał, gdzie działa i gdzie zawodzi.

TL;DR

Warstwa „Claws” opisana przez Karpathy’ego to systemy orkiestracji zbudowane na szczycie CLIs agentów. Zbudowałem taką warstwę organicznie przez dwa miesiące na Claude Code: 84 haki w 15 typach zdarzeń, 43 umiejętności, 19 agentów i ponad 30 modułów bibliotek. System jasno odwzorowuje pięć funkcji Claws (orkiestrację, harmonogramowanie, zarządzanie kontekstem, routing narzędzi, egzekwowanie jakości), z jedną znaczącą luką (deklaratywne definicje przepływów pracy). Kluczowy wniosek: oddzielenie planowania od wykonania wyłoniło się jako naturalna właściwość orkiestracji opartej na hakach, a nie jako cel projektowy. Obserwacja Lattnera, że „osąd i abstrakcja pozostają kluczowe, podczas gdy AI automatyzuje implementację”, bezpośrednio odwzorowuje się na architekturę haków: haki zarządcze sprawują osąd, haki automatyzacji realizują implementację.

Taksonomia Claws

Opis Karpathy’ego identyfikuje pięć funkcji, które pełni warstwa Claws. Każda z tych funkcji ma bezpośredni odpowiednik w systemie haków, który zbudowałem na Claude Code w ciągu ostatnich dwóch miesięcy.¹

Taksonomia ta jest użyteczna, ponieważ rozdziela kwestie, które praktycy mają tendencję budować w sposób splątany. Moje wczesne haki mieszały zarządzanie kontekstem z egzekwowaniem jakości. Hak śledzenia kosztów zarówno wstrzykiwał kontekst budżetu (zarządzanie kontekstem), jak i blokował kosztowne operacje (egzekwowanie jakości). Rozdzielenie tego na oddzielne haki poprawiło niezawodność, ponieważ każdy hak mógł zawieść niezależnie, nie psując drugiej funkcji.

Pełny system

Liczby na luty 2026:

Rozkład haków w poszczególnych typach zdarzeń ujawnia, gdzie koncentruje się złożoność orkiestracji:

UserPromptSubmit niesie największe obciążenie, ponieważ uruchamia się przy każdej wiadomości użytkownika. Dyspozytor (prompt-dispatcher.sh) uruchamia dziewięć haków sekwencyjnie przy każdej podpowiedzi: filtrowanie bezpieczeństwa, analityka, śledzenie użycia, monitoring systemu, wstrzykiwanie celu, blokowanie szacunków czasowych, wstrzykiwanie kontekstu, wstrzykiwanie tematów pamięci oraz monitorowanie presji kontekstu.²

Każdy hak dodaje opóźnienie. Dziewięć sekwencyjnych haków dodaje zmierzone łącznie 200 ms na jedną podpowiedź. Dyspozytor uruchamia je sekwencyjnie (nie równolegle), ponieważ współbieżne zapisy haków do współdzielonych plików stanu JSON powodowały uszkodzenie danych we wczesnych testach. Dwa haki zapisujące jednocześnie do jiro.state.json produkowały obcięty JSON, który psuł każdy kolejny hak. Sekwencyjne wykonywanie jest wolniejsze, ale bezpieczne. Narzut 200 ms jest niewidoczny dla użytkowników, ponieważ wąskim gardłem jest prędkość pisania człowieka, a nie opóźnienie haków.

Jak to rosło

Wzrost nie był liniowy. Podążał za wzorcem cykli problem-rozwiązanie-integracja.

Faza 1: haki jednocelowe (tydzień 1-2). Każdy hak rozwiązywał jeden problem. enforce-opus-model.sh blokował żądania modeli innych niż Opus. no-time-estimates.sh usuwał szacunki wysiłku z odpowiedzi. filter-sensitive.sh wyłapywał dane uwierzytelniające w wywołaniach narzędzi. Haki te działały niezależnie. Żaden hak nie wiedział o żadnym innym haku.

Faza 2: problemy koordynacji (tydzień 3-4). Haki zaczęły wzajemnie się zakłócać. Filtr danych uwierzytelniających blokował legalne wywołania API. Egzekwowanie modelu konfliktowało ze spawningiem subagentów. Rozwiązanie: dyspozytorzy. Pojedynczy punkt wejścia (prompt-dispatcher.sh) zastąpił siedem indywidualnych haków UserPromptSubmit, kontrolując kolejność wykonywania i współdzieląc stan przez buforowany potok stdin.

Faza 3: zdolności złożone (tydzień 5-8). Pojedyncze haki składały się w systemy. Pętla jakości łączyła haki przed-narzędziowe (wyłapujące problemy, zanim się wydarzą) z hakami po-narzędziowymi (weryfikującymi wyniki po ich wystąpieniu) poprzez wspólny plik stanu (jiro.state.json). System deliberacji wykorzystywał zabezpieczenia przed rekurencją, budżety rozrostu i protokoły konsensusu w celu koordynacji wielu agentów bez nieskończonych pętli. Ralph (autonomiczna pętla rozwoju) łączył pliki PRD ze spawningiem Claude, weryfikacją testów i przeglądem kodu w jednym orkiestrowanym potoku.

Faza 4: samoświadomość (tydzień 9+). System stał się wystarczająco duży, by potrzebować narzędzi do rozumienia samego siebie. Wyszukiwanie semantyczne w całym systemie haków (umiejętność /find) pozwalało agentom odkrywać haki po celu, a nie po nazwie pliku. Monitorowanie wydajności (umiejętność /perf) śledziło, czy własny narzut systemu nie degraduje maszyny. Monitor presji kontekstu ostrzegał, gdy kontekst wstrzykiwany przez warstwę orkiestracji zużywał zbyt dużo okna kontekstu modelu.

Progresja od haków jednocelowych do infrastruktury samomonitorującej odzwierciedla wzorzec, który Chris Lattner zidentyfikował w swojej recenzji projektu Kompilatora C Claude: „Dobre oprogramowanie zależy od osądu, komunikacji i jasnej abstrakcji. AI to wzmocniło.”³ Architektura systemu haków ujawnia tę samą prawdę. Wartościowe haki to nie te, które automatyzują zadania. Wartościowe haki to te, które kodują osąd dotyczący tego, kiedy i w jaki sposób zadania powinny być automatyzowane.

Haki osądu vs. haki automatyzacji

Recenzja Kompilatora C Claude autorstwa Lattnera rozróżniała, co AI dobrze automatyzuje (implementacja), a co pozostaje fundamentalnie ludzkie (osąd i abstrakcja).³ To rozróżnienie bezpośrednio odwzorowuje się na system haków.

Haki osądu decydują, czy coś powinno się wydarzyć. Kodują politykę, nie procedurę.

Haki automatyzacji wykonują z góry ustalone działania. Kodują procedurę, nie politykę.

Haki osądu są trudniejsze do napisania, trudniejsze do przetestowania i bardziej wartościowe. quality-gate.sh wymagał siedmiu nazwanych trybów awarii, sześciu kryteriów dowodowych i detektora języka hedżującego. inject-context.sh wymagał pięciu linii bash. Jednak oba są niezbędne. Haki automatyzacji dostarczają danych, które haki osądu oceniają. sysmon-snapshot.sh (automatyzacja) zasila danymi monitor wydajności, który decyduje, czy zalecić ograniczenie liczby agentów (osąd).

Proporcja ma znaczenie. W zdrowej warstwie orkiestracji haki osądu powinny przewyższać liczebnie haki automatyzacji. Jeśli większość haków jedynie wstrzykuje dane lub rejestruje metryki, system dobrze automatyzuje, ale słabo zarządza. Zweryfikowana liczba obecnego systemu: 35 haków osądu, 44 haków automatyzacji, w przybliżeniu 4:5. Automatyzacja wciąż prowadzi. Proporcja zaczynała się od około 1:6 (niemal wyłącznie haki wstrzykiwania i logowania) i przesunęła się w stronę osądu przez dwa miesiące, gdy dodawano ograniczenia zarządcze po napotkaniu awarii, którym sama automatyzacja nie mogła zapobiec. Proporcja jeszcze nie osiągnęła parytetu, co samo w sobie jest użytecznym sygnałem: ten system wciąż bardziej automatyzuje, niż zarządza.

Oddzielenie planowania od wykonania

Wpis Borisa Tane’a „How I use Claude Code” przyciągnął 936 punktów na Hacker News poprzez opis wzorca przepływu pracy: oddzielanie planowania od wykonania.⁴ Najpierw planowanie w jednej sesji Claude (badania, szkicowanie, projektowanie), następnie wykonanie w świeżej sesji, która otrzymuje plan jako uporządkowane wejście. Wzorzec znalazł oddźwięk, ponieważ rozwiązuje realny problem: planowanie i wykonanie konkurują o miejsce w oknie kontekstu.

System haków doszedł do tego samego rozdzielenia inną drogą. System deliberacji generuje wyspecjalizowanych agentów do badania i dyskutowania podejść. Wyjściem jest uporządkowany PRD (Product Requirements Document) ze historyjkami, kryteriami akceptacji i typami weryfikacji. Pętla Ralph odczytuje PRD i generuje świeże instancje Claude w celu implementacji każdej historyjki. Agenci planujący nigdy nie implementują. Agenci implementujący nigdy nie planują.

Rozdzielenie nie było celem projektowym. Wyłoniło się z dwóch niezależnych ograniczeń:

1. Presja okna kontekstu. Planowanie wymaga czytania wielu plików i eksplorowania opcji. Implementacja wymaga skupionego kontekstu na bieżącym zadaniu. Umieszczenie obu w tym samym oknie kontekstu oznacza, że żadne nie dostaje wystarczającej przestrzeni. Oddzielne sesje dają każdej fazie pełny kontekst.

2. Niezależność weryfikacji jakości. Jeśli ten sam agent planuje i implementuje, nie może obiektywnie zweryfikować własnej implementacji wobec planu. Świeży agent mający tylko plan i kod zapewnia niezależną weryfikację. Pętla Ralph egzekwuje to: agenci implementujący uruchamiają testy, natomiast trzech oddzielnych agentów recenzujących (poprawność, bezpieczeństwo, konwencje) weryfikuje wyniki.

Zbieżność między ręcznym przepływem pracy Tane’a a zautomatyzowanym systemem haków sugeruje, że oddzielenie planowania od wykonania jest naturalną właściwością systemów agentowych, a nie tylko preferencją praktyka. Każdy system, który zarządza oknami kontekstu i weryfikuje wyjścia, w końcu rozdzieli planowanie od wykonania, ponieważ alternatywa (robienie obu w jednym kontekście) produkuje gorsze wyniki w obu fazach.

Gdzie system haków zawodzi

Architektura ma trzy istotne słabości, którymi zająłby się framework orkiestracji zbudowany specjalnie w tym celu.

Brak deklaratywnych definicji przepływów pracy. Każdy przepływ pracy jest kodowany imperatywnie w skryptach bash. Pętla Ralph to 1320 linii basha kodujących konkretną sekwencję: odczytaj PRD, wybierz historyjkę, zbierz kontekst, wygeneruj Claude, uruchom testy, uruchom przeglądy, obsłuż awarie, zaktualizuj stan. Zmiana przepływu pracy oznacza edycję basha. System deklaratywny zdefiniowałby przepływy pracy jako dane (YAML, JSON), które wykonuje interpreter. Przepływy deklaratywne są łatwiejsze do modyfikacji, komponowania i wizualizacji. Skrypty imperatywne są łatwiejsze do początkowego napisania, ale trudniejsze w utrzymaniu w miarę ich rozrostu.

Kolejność haków jest krucha. Dyspozytor podpowiedzi uruchamia haki w zakodowanej na sztywno sekwencji. Przeniesienie memory-capsule-inject.sh przed inject-context.sh zepsułoby wstrzykiwanie kapsuły, ponieważ zależy ono od identyfikatora sesji, który inject-context.sh rozwiązuje. Te zależności są niejawne (kodowane w kolejności dyspozytora), a nie jawne (deklarowane jako zależności między hakami). System zbudowany specjalnie wyrażałby zależności haków jako DAG i topologicznie sortował kolejność wykonania.

Brak wizualizacji przepływu pracy. Przy 84 hakach zrozumienie pełnej ścieżki wykonania dowolnej akcji użytkownika wymaga ręcznego czytania kodu dyspozytora i śledzenia łańcuchów haków. Nie ma narzędzia, które pokazuje „gdy użytkownik wpisuje wiadomość, te 9 haków uruchamia się w tej kolejności, a hak 3 wywołuje funkcję biblioteczną X, która zapisuje do pliku stanu Y.” System jest obserwowalny przez logi, ale nie przez strukturę. Framework orkiestracji zbudowany specjalnie zapewniłby wizualny graf zależności haków, przepływów danych i ścieżek wykonania.

Te słabości mają wspólną przyczynę: system rozrósł się organicznie z rozwiązywania indywidualnych problemów, a nie został zaprojektowany jako spójna warstwa orkiestracji. Organiczny wzrost produkuje systemy, które działają (wszystkie 84 haki poprawnie funkcjonują w produkcji), ale są trudne do rozumowania jako całość. Kompromis jest rzeczywisty: zaprojektowanie warstwy orkiestracji z góry dałoby lepszą strukturę, ale gorsze możliwości, ponieważ wiele możliwości (kapsuły pamięci, białe listy wyjść, budżety rozrostu) zostało wymyślonych w odpowiedzi na awarie, których nie można było przewidzieć przed ich wystąpieniem.

Harness staje się mainstreamem

Trzy tygodnie po tym, jak Karpathy nazwał tę warstwę, koncepcja ma drugą nazwę i rosnącą społeczność.

Geoffrey Huntley zaproponował formalną definicję: „Agent Harness — warstwa orkiestracji wokół modelu językowego, która przekształca go z narzędzia w członka zespołu.”⁵ Ujęcie jest precyzyjne. Harness nie jest modelem. Nie jest narzędziami, które model wywołuje. Jest systemem, który decyduje, które narzędzia wywołać, kiedy je wywołać i jak ocenić, czy wywołanie się powiodło. Każdy produkcyjny system agentowy buduje tę warstwę. Większość buduje ją niejawnie, wewnątrz kodu aplikacji, który miesza logikę orkiestracji z logiką biznesową. Nazwanie jej sprawia, że architektura staje się widoczna.

Sygnały społeczności potwierdzają, że wzorzec się rozprzestrzenia. Pieter Levels zgłosił trwałe przejście na uruchamianie Claude Code na serwerze, traktując to jako infrastrukturę, a nie narzędzie lokalne.⁶ Anthropic wypuścił Remote Control, pozwalający użytkownikom rozpoczynać zadania z terminala i odbierać je z Claude.ai.⁷ Ben Cherny ogłosił /simplify i /batch jako umiejętności pierwszej strony.⁸ Każda z tych rzeczy to cecha harnessa: trwałe wykonanie, zdalna orkiestracja oraz wbudowane moduły zdolności. CLI rośnie w harness.

Tymczasem praktycy budują własne komponenty harnessa. Jeden programista opublikował 22 niestandardowe polecenia Obsidian + Claude Code dla osobistego systemu operacyjnego.⁹ Inny stworzył umiejętność agentową „Visual Explainer” z uzupełniającymi poleceniami slash.¹⁰ Wzorce się pokrywają: dyspozytorzy, umiejętności, współdzielony stan, haki sterowane zdarzeniami. Nikt nie czyta przewodnika do frameworka przed budowaniem tych systemów. Rozwiązują jeden problem, potem kolejny, potem problemy interakcji między problemami.

Dwa niedawne projekty ujawniają, jak wyrafinowane stały się komponenty harnessa budowane przez społeczność. nah to świadomy kontekstu strażnik uprawnień, który rejestruje się jako hak PreToolUse.¹⁴ Klasyfikuje 20 odrębnych typów działań (zapisy plików, żądania sieciowe, spawning procesów itd.) i stosuje polityki według typu. Narzędzie wykrywa ataki dekompozycji potoku, w których agent łańcuchowo wykonuje niewinne polecenia, aby osiągnąć zablokowaną operację. Architektura odzwierciedla filter-sensitive.sh i recursion-guard.sh z tego wpisu, do których doszedł niezależnie inny praktyk rozwiązujący te same problemy zarządcze.

Rudel zapewnia analitykę sesji poprzez wprowadzanie danych sesji Claude Code do ClickHouse.¹⁵ Analiza 1573 sesji ujawniła, że tylko 4% użytkowników wywołuje umiejętności, a 26% sesji jest porzucanych w ciągu 60 sekund. Liczby potwierdzają to, co sugeruje architektura harnessa: większość użytkowników wchodzi w interakcję z CLIs agentów na poziomie powierzchniowym. Warstwa orkiestracji opisana w tym wpisie reprezentuje głęboki koniec rozkładu użycia, gdzie ogromna większość nigdy nie opuszcza płytkiego końca. Luka między tym, co narzędzie potrafi, a tym, o co większość użytkowników je prosi, to przestrzeń, którą wypełnia infrastruktura harnessa.

Autoresearch: harness jako pętla badawcza

Własny projekt Karpathy’ego autoresearch demonstruje wzorzec harnessa w innej dziedzinie.¹¹ System kieruje model językowy na skrypt treningowy (train.py), uruchamia pięciominutowy eksperyment, ocenia wynik wobec ustalonej metryki (bity walidacji na bajt) i zachowuje ulepszenia lub odrzuca regresje. W ciągu dwóch dni system przeprowadził około 700 eksperymentów i znalazł około 20 prawdziwych ulepszeń, skracając czas treningu GPT-2 o 11%.

Architektura jest identyczna z systemem haków opisanym powyżej. Stały harness oceny (prepare.py) jest odpowiednikiem haków osądu: decyduje, czy eksperyment się powiódł. Skrypt treningowy (train.py) jest odpowiednikiem haków automatyzacji: wykonuje modyfikacje agenta. Zarządzanie gałęziami git (zachowaj przy ulepszeniu, resetuj przy regresji) jest odpowiednikiem zarządzania stanem pętli Ralph. Log results.tsv jest odpowiednikiem telemetrii sesji.

Wzorzec się przenosi, ponieważ harness rozwiązuje problem niezależny od domeny. Niezależnie od tego, czy agent pisze kod, optymalizuje pętlę treningową czy zarządza potokiem treści, potrzebuje: sposobu oceny wyników wobec kryteriów, sposobu zachowania lub odrzucenia zmian, sposobu utrzymywania stanu w iteracjach oraz sposobu autonomicznego działania bez interwencji człowieka. Te cztery wymagania produkują tę samą architekturę, niezależnie od tego, co agent faktycznie robi.

Dyrektor generalny Shopify, Tobi Lütke, zaadaptował autoresearch wewnętrznie. Jego mniejszy model zoptymalizowany przez agenta przewyższył ręcznie skonfigurowany większy model, potwierdzając tezę, że autonomiczna iteracja sterowana harnessem odkrywa konfiguracje, których ludzie nie pomyśleliby wypróbować.¹²

Luka bezpieczeństwa w harnessie

Harness rozwiązuje orkiestrację. Nie rozwiązuje automatycznie bezpieczeństwa.

Badanie iteracyjnego udoskonalania kodu sterowanego LLM wykazało, że 43,7% łańcuchów iteracji zawierało więcej luk bezpieczeństwa po dziesięciu rundach modyfikacji agentowych niż bazowy kod, od którego zaczęły.¹³ Podstawową przyczyną było odchylenie specyfikacji: w miarę jak agent optymalizował pod kątem poprawności funkcjonalnej, postępująco usuwał logikę obronną i osłabiał obsługę wyjątków. Co gorsza, dodanie narzędzi statycznej analizy bezpieczeństwa (bramek SAST) do pętli iteracji faktycznie zwiększyło utajoną degradację z 12,5% do 20,8%. Skanery stworzyły fałszywe poczucie bezpieczeństwa, które sprawiło, że agent był mniej ostrożny, a nie bardziej.

Ustalenie o degradacji jest bezpośrednio istotne dla projektowania harnessa. Haki osądu opisane w tym wpisie (quality-gate.sh, filter-sensitive.sh, recursion-guard.sh) adresują wymiary jakości i bezpieczeństwa, które sama automatyzacja degraduje. Framework SCAFFOLD-CEGIS, który zaadresował problem degradacji, wykorzystywał cztery warstwy weryfikacji z bramkami, osiągając 2,1% utajonej degradacji przy 100% monotoniczności bezpieczeństwa.¹³ Architektura jest równoległa do systemu haków: oddzielne warstwy ewaluacji, każda sprawdzająca inną właściwość, z jawnymi bramkami między fazami.

Oddzielny wysiłek potwierdza model zagrożeń z produkcyjnej strony. Odpowiedź Perplexity dla NIST w sprawie bezpieczeństwa agentów AI zmapowała powierzchnię ataku systemów agentowych działających na dużą skalę.¹⁶ Główne wektory: pośrednie wstrzykiwanie podpowiedzi przez kanały danych (strony internetowe, e-maile, wyjścia narzędzi), naruszenia triady CIA specyficzne dla agentów (eksfiltracja danych przez wywołania narzędzi, manipulacja działaniami przez zatruwanie kontekstu, wyczerpywanie zasobów przez rekurencyjne spawning) oraz realne CVE z systemów sąsiadujących z agentami. Ich zalecana architektura obrony (filtrowanie na poziomie wejścia, wyrównanie na poziomie modelu oraz deterministyczne egzekwowanie poprzez sandboxing i listy dozwolonych) odzwierciedla trójwarstwowy wzorzec, który wyłonił się organicznie w systemie haków opisanym tutaj. Haki automatyzacji filtrują wejścia. Model sprawuje osąd. Haki zarządcze egzekwują deterministyczne ograniczenia, których model nie może unieważnić.

Lekcja dla praktyków: jeśli twój harness tylko automatyzuje i orkiestruje bez zarządzania, iteracyjne wykonanie agentowe wprowadzi regresje bezpieczeństwa, których standardowe narzędzia nie wykryją. Haki osądu nie są narzutem. Są powodem, dla którego system nie degraduje.

Co praktycy powinni wynieść

Jeśli budują Państwo warstwę orkiestracji na szczycie CLI agenta — zaczynając od przewodnika Claude Code lub od zera — trzy wzorce z tego systemu przenoszą się bezpośrednio.

Proszę zacząć od dyspozytorów, nie od indywidualnych haków. Największym ulepszeniem architektonicznym było zastąpienie siedmiu indywidualnych haków UserPromptSubmit pojedynczym dyspozytorem, który uruchamia je sekwencyjnie. Jeśli przewidują Państwo więcej niż trzy haki na dowolnym typie zdarzenia, warto zbudować dyspozytora jako pierwszego. 30 minut poświęconych na napisanie dyspozytora oszczędza godziny późniejszego debugowania błędów interakcji haków. Minimalny wzorzec:

#!/bin/bash
# dispatcher.sh — sequential hook execution with shared stdin
HANDLERS=("inject-context.sh" "track-usage.sh" "quality-gate.sh")
HOOK_DIR="$(dirname "$0")/handlers"
INPUT=$(cat)  # Cache stdin once (each handler gets the same input)

for handler in "${HANDLERS[@]}"; do
    [ -x "$HOOK_DIR/$handler" ] && echo "$INPUT" | "$HOOK_DIR/$handler"
done

Proszę zarejestrować pojedynczego dyspozytora jako punkt wejścia haka. Proszę dodawać procedury obsługi do tablicy w miarę ich budowania. Każda procedura obsługi odczytuje ten sam buforowany stdin (ładunek zdarzenia haka) i niezależnie zapisuje do stdout.

Proszę oddzielić osąd od automatyzacji wcześnie. Pisząc nowy hak, warto zapytać: „Czy hak decyduje, czy coś powinno się wydarzyć, czy wykonuje z góry ustalone działanie?” Haki osądu wymagają więcej testowania, więcej obsługi przypadków brzegowych i więcej iteracji. Haki automatyzacji wymagają niezawodności i wydajności. Traktowanie ich tak samo prowadzi do niedostatecznie przetestowanych haków osądu i nadmiernie zaprojektowanych haków automatyzacji.

Proszę pozwolić, aby oddzielenie planowania od wykonania wyłoniło się. Proszę nie wymuszać tego rozdzielenia pierwszego dnia. Proszę zbudować najprostszą działającą rzecz. Gdy zauważą Państwo, że okno kontekstu agenta jest zbyt pełne zarówno dla planowania, jak i implementacji, proszę je rozdzielić. Gdy zauważą Państwo, że agent nie może obiektywnie zweryfikować własnej pracy, proszę dodać niezależnych agentów recenzujących. Rozdzielenie wyda się oczywiste, gdy ograniczenia tego zażądają.

Harness staje się mainstreamem, ponieważ wzorzec jest nieunikniony. Niezależnie od tego, czy nazwiemy tę warstwę Claws, Agent Harness, czy po prostu „mój folder z hakami”, każdy system koordynujący agentów wokół celów będzie zbiegał do tej samej architektury: dyspozytorzy dla kolejności, haki osądu dla zarządzania, haki automatyzacji dla wykonania i pliki stanu dla ciągłości. Wyciek kodu źródłowego Claude Code potwierdził, że wewnętrzna architektura Anthropic podąża za tymi samymi wzorcami — tryb koordynatora jest implementowany w całości jako instrukcje promptów systemowych, a nie orkiestracja na poziomie kodu. Podejście oparte na hakach ma jedną przewagę nad frameworkami orkiestracji zbudowanymi specjalnie w tym celu: zerowe zobowiązanie. Każdy hak jest niezależny. Można przyjąć jeden hak, dziesięć haków lub osiemdziesiąt cztery haki. Można usunąć dowolny hak bez psucia innych (zakładając utrzymanie dyspozytora). Nie ma frameworka do nauki, żadnej zależności do zarządzania, żadnego środowiska uruchomieniowego do obsługi. Warstwa orkiestracji to po prostu pliki.

FAQ

Czym jest agent harness lub warstwa „Claws”?

Warstwa Claws (nazwana przez Andreja Karpathy’ego w lutym 2026 r.) to system orkiestracji zbudowany na szczycie CLI agenta, który przekształca go z narzędzia w członka zespołu.¹ Pełni pięć funkcji: orkiestrację (koordynowanie wielu agentów), harmonogramowanie (określanie, kiedy zadania są wykonywane), zarządzanie kontekstem (utrzymywanie istotnych informacji między turami), routing narzędzi (kierowanie wywołań narzędzi przez odpowiednie procedury obsługi) i egzekwowanie jakości (weryfikowanie, czy wyniki spełniają standardy). Geoffrey Huntley sformalizował tę definicję jako „warstwę orkiestracji wokół modelu językowego”.⁵

Jak działają haki PreToolUse w Claude Code?

Haki PreToolUse uruchamiają się przed każdym wywołaniem narzędzia (polecenia Bash, zapisy plików, edycje plików, spawn subagentów) i otrzymują ładunek wywołania narzędzia jako JSON na stdin. Skrypt haka ocenia ładunek i zwraca decyzję: dozwól, odmów lub zmodyfikuj. Model nie może pominąć, unieważnić ani negocjować z hakami, ponieważ wykonują się one na poziomie infrastruktury, a nie na poziomie podpowiedzi.² Wzorzec dyspozytora uruchamia wiele haków sekwencyjnie dla każdego zdarzenia, z buforowanym potokiem stdin, aby każda procedura obsługi otrzymała to samo wejście.

Jaka jest różnica między hakami osądu a hakami automatyzacji?

Haki osądu decydują, czy coś powinno się wydarzyć (polityka), podczas gdy haki automatyzacji wykonują z góry ustalone działania (procedura). Haki osądu obejmują bramki jakości, filtry danych uwierzytelniających, zabezpieczenia rekurencji oraz bramki kosztów. Haki automatyzacji obejmują wstrzykiwanie kontekstu, śledzenie użycia, monitoring systemu i sygnały aktywności.³ Proporcja ma znaczenie: system w większości składający się z haków automatyzacji dobrze automatyzuje, ale słabo zarządza. Obecny system wykorzystuje 35 haków osądu do 44 haków automatyzacji, przesuwając się w stronę zarządzania, gdy awarie ujawniły, czemu sama automatyzacja nie może zapobiec.

Dlaczego oddzielenie planowania od wykonania naturalnie wyłania się w systemach agentowych?

Dwa niezależne ograniczenia wymuszają to rozdzielenie. Po pierwsze, planowanie wymaga czytania wielu plików i eksplorowania opcji, podczas gdy implementacja wymaga skupionego kontekstu na bieżącym zadaniu, a umieszczenie obu w tym samym oknie kontekstu oznacza, że żadne nie dostaje wystarczającej przestrzeni. Po drugie, jeśli ten sam agent planuje i implementuje, nie może obiektywnie zweryfikować własnej pracy wobec planu.⁴ Każdy system, który zarządza oknami kontekstu i weryfikuje wyjścia, w końcu rozdzieli planowanie od wykonania, ponieważ alternatywa produkuje gorsze wyniki w obu fazach.

Jak rozpocząć budowę własnego systemu haków?

Warto zacząć od dyspozytorów, a nie od indywidualnych haków. Jeśli przewidują Państwo więcej niż trzy haki na dowolnym typie zdarzenia, warto zbudować pojedynczego dyspozytora, który uruchamia procedury obsługi sekwencyjnie z tablicy. 30 minut poświęconych na napisanie dyspozytora oszczędza godziny późniejszego debugowania błędów interakcji haków. Warto wcześnie oddzielić osąd od automatyzacji, pytając „czy ten hak decyduje, czy coś powinno się wydarzyć, czy wykonuje z góry ustalone działanie?” Proszę zacząć od tutorialu haków Claude Code i dodawać haki w miarę jak realne awarie tego zażądają, zamiast projektować pełny system z góry.

Źródła