Pięć warstw w Claude Code: pamięć, umiejętności, Hooki, podagenty oraz pluginy
Claude Code postrzegany jako środowisko działania agentów: pamięć CLAUDE.md, umiejętności na żądanie, deterministyczne Hooki, izolowane podagenty oraz pluginy, które łączą to wszystko dla zespołu.
Źródła: **Claude Code’s 5-Layer Agent Development Kit: The Architecture Most Engineers Are Missing**
Wielu inżynierów traktuje Claude Code jako bardzo sprawnego asystenta do programowania: otwiera się terminal, przekazuje zadanie, pozwala mu czytać pliki i wykonywać polecenia, a następnie obserwuje postępy pracy. Ten opis jest dokładny, ale niekompletny. Dokumentacja Anthropic przedstawia go jako narzędzie do programowania oparte na agentach, które działa w terminalu, rozumie bazę kodu, wykonywa rutynowe zadania oraz łączy się z zewnętrznymi systemami za pomocą mechanizmów takich jak MCP. Po uważnym przeczytaniu okazuje się, że produkt to raczej zorganizowana środowisko działania agentów z kilkoma odrębnymi interfejsami sterowania, a nie model umieszczony w obudowie linii poleceń.
Do tych elementów należą plik CLAUDE.md przechowywany w pamięci, wielokrotnie używalne umiejętności, deterministyczne Hooki, podagenty, którym deleguje się zadania, pluginy, które można zainstalować, oraz łącza MCP do systemów zewnętrznych. Dlatego istotne staje się inne pytanie – ważniejsze jest zastanowienie się nad tym, jak kształtować, ograniczać, specjalizować i udostępniać zachowanie Claude Code w ramach zespołu, niż to, co może on wygenerować.
Stack w pięciu warstwach
Model podstawowy potrafi pisać kod, tłumaczyć zawartość plików i odpowiadać na pytania. Sam w sobie pozostawia jednak kilka problemów nierozwiązanych: przechowywanie projektu między sesjami, ponowne wykorzystanie wiedzy specjalistycznej, wprowadzanie ograniczeń na poziomie infrastruktury, ograniczanie tego, co może być delegowane, oraz zapewnienie spójnego zachowania w zespole. Te kwestie wykraczają poza sam prompt, a projekt Claude Code coraz bardziej to odzwierciedla. Dokumentacja opisuje trwałe pliki instrukcji, rozszerzalne umiejętności, dostosowane podagenty, hooki, zakresy ustawień, wtyczki oraz połączenia MCP jako odrębne mechanizmy. Razem nie stanowią one zbioru losowych funkcji – tworzą warstwy, które sprawiają, że zachowanie agenta jest bardziej niezawodne, wielokrotnie wykorzystywalne i łatwe w zarządzaniu:
- CLAUDE.md to warstwa pamięci i polityk.
- Umiejętności stanowią warstwę wiedzy, dostarczającą specjalistyczną wiedzę na żądanie.
Wzory MCP i agent-team otaczają tę strukturę, pełniąc rolę systemów łączących ją ze światem zewnętrznym.
To ujęcie wyjaśnia problem występujący w nieudanych projektach agentów: rzadko model był słabym punktem. Brakowało jakiejś warstwy. Jedna z drużyn polega wyłącznie na podawaniu instrukcji bez trwałej pamięci projektu. Inna ma szczegółowe wytyczne, ale brakuje jej deterministycznych mechanizmów kontrolujących używanie ryzykownych narzędzi. Trzecia przeciąża jednego agenta uniwersalnego, podczas gdy praca powinna być rozdzielona między specjalistów. Większość niepowodzeń agentów ma charakter architektoniczny, a nie wynika z problemów z instrukcjami. Każda warstwa zostanie omówiona poniżej, począwszy od najniższej.
Dlaczego perspektywa architektury jest lepsza od listy funkcji
Gdy patrzymy na Claude Code jako na listę funkcji, pojawia się pytanie o to, co potrafi. Gdy jednak patrzymy na niego przez pryzmat architektury, pojawia się lepsze pytanie: które warstwy są dostępne do kontrolowania sposobu kształtowania, ograniczania, delegowania i udostępniania zachowań agenta? Gdy zmienia się pytanie, staje się łatwiej zrozumieć całą strukturę, a także szybciej zdiagnozować problemy w praktyce.
Z dokumentacji wynikają dwa wnioski. Po pierwsze, żaden z tych mechanizmów nie znajduje się wewnątrz modelu – istnieją one wokół niego, w plikach, obsługiwaczach zdarzeń, zakresach konfiguracji oraz formatach pakietowania. Po drugie, każdy z nich rozwiązuje inny problem: pamięć pomaga w radzeniu sobie z zapominaniem, umiejętności odpowiadają za ogólne zachowanie, haki radzą sobie z niestabilnością, podagenty pomagają w uporządkowaniu zbyt skomplikowanego kontekstu, a wtyczki eliminują konieczność ręcznego powtarzania skutecznych ustawień.
Pierwszy warstwa: CLAUDE.md jako pamięć
Podstawą jest CLAUDE.md. Dokumentacja opisuje je jako miejsce na trwałe instrukcje dotyczące sposobu pracy nad projektem, podczas gdy oddzielna funkcja automatycznej pamięci przechowuje notatki, które Claude tworzy dla siebie po wielokrotnych korektach i ustaleniach preferencji.
To rozdzielenie ma znaczenie. CLAUDE.md nie służy jako notatnik na tymczasowe polecenia. Zespoły umieszczają tu długoterminowy kontekst: standardy programistyczne, wcześniejsze decyzje architektoniczne, ulubione biblioteki, listy kontrolne do przeglądu oraz ograniczenia w procesie pracy – wszystko to, co powinno być widoczne przed pierwszą wiadomością w sesji.
Ciekawą kwestią techniczną jest sposób ich ładowania. Nie chodzi o jedyny plik pobierany wyłącznie z bieżącego katalogu. Claude przemieszcza się w górę drzewa katalogów od katalogu roboczego i ładuje każdy plik o nazwie CLAUDE.md oraz CLAUDE.local.md, który znajdzie. Pliki te są łączone ze sobą, zamiast się wzajemnie przytłaczać, a instrukcje znajdujące się bliżej katalogu uruchomienia są czytane później.
To sprawia, że jest to system pamięci z ograniczonym zakresem, a nie pojedynczy plik konfiguracyjny. Plik najwyższego poziomu może zawierać zasady obowiązujące w całym repozytorium, takie jak konwencje nazewania, oczekiwania dotyczące testów czy granice architektoniczne, natomiast plik znajdujący się głębiej w drzewie może określić specyficzne zasady dla danego podsystemu. Wyobraźmy sobie monorepo: plik korzeniowy określa, jak nazywane są testy i gdzie leżą granice usług, podczas gdy plik w katalogu payments dodaje bardziej restrykcyjne zasady obowiązujące wyłącznie tam. Każdy, kto rozpoczyna sesję w tym katalogu, otrzymuje obie wersje zasad, przy czym bardziej szczegółowe wytyczne są czytane na końcu.
Importy zapewniają możliwość kompozycji. Składnia @path/to/import umożliwia zespołom dzielenie dużych zestawów instrukcji na mniejsze, wielokrotnie używalne moduły, dzięki czemu jeden plik Markdown nie zamienia się w chaotyczną kolekcję elementów. Narzędzie Launch rozszerza zaimportowane pliki w kontekście, a sam import może importować inne pliki, maksymalnie na pięć poziomów w dół. W praktyce CLAUDE.md funkcjonuje bardziej jak pamięć projektu umożliwiająca kompozycję niż statyczny szablon promptu.
Pamięć automatyczna pełni inną rolę. Obie są ładowane na początku każdej rozmowy, ale CLAUDE.md przechowuje to, co ludzie celowo napisali, natomiast pamięć automatyczna zawiera własne notatki zgromadzone przez Claude’a w lokalnym katalogu maszyny, indeksowane za pomocą MEMORY.md. Podczas startu sesji ładowane są tylko pierwsze 200 wierszy lub 25 KB tego indeksu. Z kolei pliki CLAUDE.md są ładowane w całości, niezależnie od długości, chociaż Anthropic zauważa, że krótsze pliki są lepiej śledzone. Jedna z tych pamięci jest kontrolowana i deklaratywna; druga natomiast adaptacyjna i emergentna.
Lepszym modelem mentalnym niż „kontekst wklejony raz, aby Claude zapamiętał styl” jest dokument regulujący działanie agenta. Anthropic określa nawet lokalizacje w całej organizacji dla centralnie zarządzanych plików CLAUDE.md na najważniejszych systemach operacyjnych desktopowych, co wskazuje, że ta warstwa ma służyć trwałej polityce operacyjnej, a nie tylko osobistym upodobaniom. Dzięki temu zespoły unikają powtarzania tych samych ograniczeń przy każdej sesji, a agent otrzymuje stabilną podstawę przed rozpoczęciem pracy nad konkretnym zadaniem.
Praktyczną konsekwencją zasad ładowania jest to, że CLAUDE.md wymaga starannej obsługi redakcyjnej. Ponieważ każdy odkryty plik jest ładowany w całości, jego nadmiar odczuwalny jest przy każdej sesji, a zalecenia Anthropic dotyczące korzystania z krótszych plików stanowią powód do ich regularnego oczyszczania. Procedury, które przerosły rozmiar pliku, są pierwszymi kandydatami do usunięcia, co prowadzi bezpośrednio do następnej warstwy.
Warstwa druga: Umiejętności jako wiedza na żądanie
Jeśli CLAUDE.md stanowi pamięć trwałą i zasady działania, to umiejętności dostarczają modułowej wiedzy specjalistycznej, która pojawia się w momencie potrzeby. Zgodnie z dokumentacją, wpisywanie instrukcji do pliku SKILL.md jest sposobem, w jaki Claude nabywa nowe umiejętności. Polecenie z użyciem słowa „slash” wywołuje konkretne umiejętność, albo Claude może je samodzielnie wykorzystać, gdy uzna, że zadanie do tego wymaga.
Kluczowym aspektem architektury jest timing. Zbiór umiejętności nie stanowi trwałej pamięci projektu – zostaje wprowadzony do kontekstu tylko wtedy, gdy jest to konieczne, dzięki czemu procedury wielokrotnego użycia, listy kontrolne oraz wskazówki specjalistyczne mogą być dołączane bez obciążania każdej sesji.
Wielu inżynierów traktuje personalizację jako jeden długi prompt: wkładają wszystko do trwałego kontekstu i mają nadzieję, że model sam odkryje to, co jest ważne. Umiejętności stanowią bardziej zorganizowaną alternatywę. Anthropic zaleca ich tworzenie, gdy te same instrukcje są powtarzanie wielokrotnie lub gdy jakaś sekcja pliku CLAUDE.md przekształciła się z faktu w procedurę. PLIK CLAUDE.md powinien zawierać trwałe zasady projektu, natomiast umiejętności – procedury operacyjne nadające się do ponownego użycia. Dzięki temu kontekst stale ładowany pozostaje lekki, a skomplikowane procesy przekształcają się w moduły, które Claude może wykorzystać w odpowiednim momencie.
Umiejętności to również nie po prostu przemianowane, spersonalizowane polecenia. Starsze pliki .claude/commands/.md oraz nowsze definicje w formacie .claude/skills//SKILL.md zachowują się podobnie podczas wywoływania, ale umiejętności dają większą kontrolę. Pozwalają one na istnienie katalogu z plikami pomocniczymi, decydują, czy użytkownik, Claude lub obaj mogą je uruchomić, obsługują dynamiczną iniekcję kontekstu, a nawet mogą działać wewnątrz podagenta. Dlatego właśnie pasuje określenie „warstwa wiedzy”: umiejętność to jednostka, dzięki której ekspertyza, procedury i kontekst zadań stają się komponowalne w trakcie działania systemu.
Rozważmy umiejętność jako zamkniętą paczkę wiedzy przeznaczoną do wykonywania określonej pracy. Jej opis wskazuje na cel, a porównanie podczas wykonywania decyduje o tym, czy pasuje do bieżącej prośby; instrukcje znajdujące się wewnątrz są ładowane tylko wtedy, gdy mogą być pomocne. Dokumentacja zaznacza, że umiejętności takie jak /debug, /loop i /simplify opierają się na promptach, a nie na stałej logice, co jest ważną wskazówką dotyczącą ich projektu. Dzięki temu zachowanie staje się modułowe, bez konieczności wbudowywania wszystkiego bezpośrednio do głównego produktu – to znacznie bardziej skalowalny model niż zakładanie, że jeden ogromny prompt będzie wystarczający do obsługi każdego procesu pracy.
Rozważmy zespół, który używa standardowej metody do debugowania niestabilnych testów, przeglądania migracji SQL lub sporządzania notatek o wydaniu. Pamięć trwała jest zbyt ogólna w tym kontekście, a jednorazowe prośby o działanie są zbyt powtarzalne. Zespół pakuje tę procedurę raz, przechowuje materiały referencyjne obok niej, a Claude ładuje je tylko wtedy, gdy zadanie tego wymaga. Długi tekst referencyjny w ramach umiejętności kosztuje prawie nic, dopóki nie zostanie użyty, więc taki model jest bardziej uporządkowany i również tańszy w obsłudze.
Dlatego umiejętności nagradzają nawyk dostrzegania powtórzeń. Ilekroć ta sama wyjaśnienie jest wpisywane po raz trzeci, lub akapit w pliku CLAUDE.md zaczyna przypominać numerowaną procedurę, to prawdopodobnie chodzi o umiejętność, którą można wyekstrahować. Ta operacja zajmuje kilka minut, ale się opłaca za każdym razem, gdy zadanie się powtarza.
W połączeniu CLAUDE.md zapewnia agentowi stabilne zasady podstawowe, natomiast Skills dostarczają mu precyzyjną, wielokrotnie wykorzystywalną wiedzę bez powiększania głównego okna kontekstu. Kolejna warstwa sprawia, że to zachowanie jest bezpieczniejsze.
Warstwa trzecia: Hooki jako zasady bezpieczeństwa
Hooki przekształcają zachowanie agenta w coś, co można egzekwować. Oficjalne dokumentacje przedstawiają je jako automatyzację opartą na zdarzeniach: polecenie jest wykonywane przed lub po określonej akcji w Claude Code, uruchamiane przez samo zdarzenie. Hooki określają i katalogują typowe zastosowania: automatyczne formatowanie kodu po edycjach, odrzucanie zmian w plikach chronionych, przywracanie kontekstu po skompresowaniu rozmowy, audyt zmian konfiguracji, odświeżanie stanu środowiska po zmianach w plikach oraz wstępna akceptacja określonych prośb o uprawnienia.
To jest zupełnie inna praca niż generowanie promptów. Prompt może sugerować określone zachowanie; hook natomiast może je przechwycić lub przekształcić w sposób deterministyczny. Z tego powodu hooki należy postrzegać przede wszystkim jako warstwę ochronną, a nie jedynie udogodnienie w automatyzacji.
Konkretnym przykładem jest przewodnik kosztów: hook PreToolUse przechwytuje polecenia Bash, rozpoznaje testy i przepisuje je tak, aby wynik otrzymywany przez Claude zawierał tylko informacje o błędach, a nie cały strumień danych. Mechanicznie hook otrzymuje payload w formacie JSON opisujący planowaną funkcję, analizuje polecenie i odpowiada JSON-em, który modyfikuje dane wprowadzane do narzędzia. W tym procesie sztuczna inteligencja nie decyduje o lepszym rozwiązaniu – to infrastruktura określa, co model może zobaczyć lub zrobić w danym momencie procesu pracy.
Należy podkreślić kontrast pomiędzy zasadami na poziomie promptu a innymi regułami. Miękkie ograniczenia często okazują się zbyt słabe do użycia w produkcji. Załóżmy, że generowany kod musi zawsze być ponownie sformatowany, pliki wrażliwe nie mogą ulec żadnym zmianom, lub wywołania destruktywnych narzędzi wymagają bardziej rygorystycznej weryfikacji. Poleganie wyłącznie na pisemnych instrukcjach jest kruche, natomiast haki przenoszą kontrolę poza dyskrecję modelu i egzekwują zasady przepływu pracy na poziomie konkretnych wydarzeń.
Haki znajdują się również obok zarządzania kontekstem, a nie w jego obrębie. Dokumentacja dotycząca rozwiązywania problemów wymienia „haki, które się nie uruchamiają” jako odrębny problem konfiguracyjny i zaleca użycie narzędzia /doctor do diagnozowania problemów z hakami, serwerami MCP oraz wykorzystaniem kontekstu. Obie te informacje wskazują, że haki należą do środowiska wykonawczego: to zachowanie sterowane konfiguracją, które musi zostać prawidłowo połączone z czasem wykonywania sesji, a nie tekst, który Claude czyta.
Istnieje również aspekt kosztów. Przewodnik po kosztach Anthropic zaleca przenoszenie obliczeń do hooków i umiejętności, ponieważ hooki mogą przetwarzać duże dane wejściowe przed tym, jak model je zobaczy. Jako przykład podaje filtrowanie ogromnego logu testowego tak, by pozostały tylko błędy, co zmniejsza objętość danych – mogących wynosić dziesiątki tysięcy tokenów – do znacznie mniejszej ilości. Dlatego hooki służą zarówno efektywności, jak i bezpieczeństwu: ograniczają marnotrawstwo tokenów, utrzymują czystszy kontekst i oszczędzają modelowi pracochłonne zadania filtrowania, które logika shella realizuje taniej i bardziej niezawodnie.
Pomaga wyobrazić sobie sytuację przed i po wdrożeniu hooków. Przed ich użyciem zespół zapisuje w instrukcjach „zawsze uruchamiaj formatera” i ma nadzieję, że to wystarczy. Po wdrożeniu hooków formater uruchamia się przy każdej edycji, niezależnie od tego, czy model o tym pamięta, a plik chroniony po prostu nie może zostać zmodyfikowany. Agent nadal swobodnie decyduje, co ma zostać stworzone; hooki określają natomiast, co jest dozwolone w ramach tych decyzji.
Większość zespołów najpierw nie docenia tej warstwy. Pamięć pomaga agentowi zapamiętywać informacje, a umiejętności – specjalizować się, ale hooki przekształcają powtarzające się wymagania operacyjne w zasady. Znajdują się dokładnie tam, gdzie rozumowanie oparte na modelu spotyka się z zachowaniem narzuconym przez system, a właśnie tam występuje najwięcej awarii w produkcji. Bez nich jakość zbyt mocno zależy od treści wprowadzanych promptów.
Warstwa czwarta: Podagenty do delegowania zadań
Gdy haki służą do sterowania, podagenty zajmują się delegowaniem zadań. Dokumentacja opisuje je jako specjalistycznych asystentów AI, którzy obsługują określone rodzaje zadań w swoim własnym oknie kontekstowym i zwracają tylko wynik.
Rozumowanie jest proste. Jednym z najszybszych sposobów na pogorszenie jakości sesji jest pozwolenie zadaniom pobocznym na zanieczyszczenie głównej rozmowy logami, wynikami wyszukiwań lub rozumowaniem eksploracyjnym, które nigdy nie zostanie ponownie wykorzystane. Zamiast zmuszać jednego ogólnistego agenta do obsługi wszystkiego w pojedynczym wątku, główny agent przekazuje zadanie poboczne specjalistycznemu pracownikowi, który działa niezależnie i przesyła podsumowanie. Korzyści obejmują:
- Eksploracja i implementacja nie wpływają na główną rozmowę, dzięki czemu zachowany zostaje kontekst.
- Ograniczony dostęp do narzędzi wprowadza restrykcje.
- Konfiguracje mogą być ponownie wykorzystywane w różnych projektach.
- Skupione instrukcje specjalizują zachowanie agenta.
Nazywanie subagenta nazwą promptu jest niedocenieniem jego roli. W rzeczywistości jest to samodzielna jednostka pracy, zawierająca opis, prompt systemowy, wybrany model, zestaw dozwolonych narzędzi, ustawienia pamięci oraz ograniczenia czasowe.
Wbudowane przykłady ilustrują jego przeznaczenie. Explore jest optymalizowany do wyszukiwania tylko do odczytu i analizy kodu, Plan służy do planowania procesów pracy, natomiast agent uniwersalny zajmuje się złożonymi, wieloetapowymi zadaniami łączącymi rozumowanie z działaniem. W dokumentacji podano, że wbudowane subagenty odziedziczą uprawnienia z głównej rozmowy wraz z dodatkowymi ograniczeniami dotyczącymi narzędzi, więc delegowanie zadań jest od początku ograniczone.
Kolejna ograniczenie: podagenty nie wykonują rekurencji. Anthropic stwierdza, że podagent nie może tworzyć innych podagentów, co pozwala Claude’un unikać nieskończonego nawinięcia, jednocześnie pozwalając mu zbierać potrzebny kontekst. Bez wyraźnej granicy delegowanie może prowadzić do niekontrolowanych struktur agentów, które są kosztowne w utrzymaniu, trudne do monitorowania i zrozumienia. Model pozostaje prosty: główny agent przekazuje zadania w dół, podagent wykonuje je samodzielnie, a wynik wraca na górę.
Z praktycznego punktu widzenia podagenty można konfigurować na różnych poziomach. Można je tworzyć interaktywnie za pomocą polecenia /agents, przechowywać dla każdego użytkownika w katalogu ~/.claude/agents/, przechowywać dla każdego projektu w katalogu .claude/agents/, przekazywać przez linię poleceń na określoną sesję lub umieszczać w plikach rozszerzeń. Każdy z nich to plik Markdown z metadanymi w formacie YAML, jednak zachowanie, które definiują, jest bogate: wybór modelu, dostęp do narzędzi, zachowanie pamięci, haki oraz umiejętności – wszystko to można dostosować do danego podagenta. Są to profile wykonywania zapakowane w formie plików, a nie etykiety ról.
Dlatego właśnie subagenty należą do najważniejszych warstw. CLAUDE.md umacnia głównego agenta w zasadach projektu, dostarczanie umiejętności zapewnia modułową ekspertyzę, a mechanizmy hooków egzekwują zasady w czasie wykonywania, ale subagenty zapobiegają temu, by wszystko spłynęło w jedną przeciążoną rozmowę z zbyt wieloma obowiązkami. Izolacja to cichy atut – subagent może czytać dziesiątki plików, przeprowadzać wyszukiwania i podążać ślepo zakończonymi ścieżkami, przy czym żadna z tych działań nie trafia do głównego wątku, który otrzymuje jedynie wynik końcowy. Subagenty wyznaczają wyraźne granice dla zadań pobocznych, pozwalają zespołom specjalizować się w konkretnych procesach i utrzymują główny kontekst w czystości oraz przez dłuższy czas. Gdy delegacja jest już wdrożona, pozostaje problem organizacyjny: jak to wszystko zapakować dla zespołu.
Wybór miejsca dla każdej zasady
Dostępnych jest pięć warstw, więc wybór miejsca umieszczenia staje się decyzją projektową. Przydatnym testem jest zastanowienie się, jak powinna zachowywać się dana reguła. Jeśli musi być zawsze znana, umieść ją w pliku CLAUDE.md. Jeśli jest to procedura potrzebna tylko czasami, przekształć ją w umiejętność. Jeśli musi być egzekwowana bez względu na decyzję modelu, jest to hook. Jeśli praca jest złożona, samodzielna lub nadaje się do użycia z tańszym modelem, przekaż ją podagentowi. Jeśli całe rozwiązanie musi być przenoszone, zapakuj je jako plugin. Reguły umieszczone w niewłaściwej warstwie zazwyczaj zawodzą w typowych sposobach: polityka pozostawiona w formie tekstu prostego jest ignorowana, długa procedura przechowywana w pamięci zajmuje całą dostępną przestrzeń, a sprytnie skonfigurowane rozwiązanie na jednym laptopie nigdy nie dociera do zespołu.
Warstwa piąta: Plugini do dystrybucji
Załóżmy, że zespół już posiada swój plik pamięci, umiejętności, elementy sterujące oraz podagentów. Problemem nie jest już zachowanie lokalne, lecz dystrybucja. Jak taka konfiguracja może być przenoszona między repozytoriami, maszynami i kolegami z zespołu bez konieczności ręcznego jej ponownego tworzenia za każdym razem?
Anthropic oferuje kilka mechanizmów do pakowania i ponownego wykorzystywania zachowań w różnych kontekstach: podagentów na poziomie użytkownika i projektu, wspólne umiejętności, ustawienia wtyczek, rozproszone wdrażanie plików CLAUDE.md w całej organizacji oraz wtyczki dostarczające inteligencję kodową lub inne funkcje. Claude Code nie jest konfigurowalny tylko dla jednej osoby; coraz częściej służy zespołom do standaryzacji i dystrybucji sposobu działania agenta.
Najwyraźniejszym oficjalnym sygnałem jest model wtyczek i ustawień. Dokumentacja dotycząca ustawień opisuje dedykowane sekcje konfiguracji wtyczek, listy dozwolonych elementów oraz uprawnienia takie jak codeIntelligence.*, a także ustawienia lokalne projektu i odziedziczone ustawienia użytkownika. Wskazuje ona również, że argumenty CLI, takie jak flagi append-system-prompt i allowed-tools, nie są przenoszone do wtyczek, co potwierdza, że wtyczki stanowią odrębne jednostki dystrybucyjne z własną powierzchnią zachowań, a nie pasywne rozszerzenia głównej sesji. Dlatego wtyczki służą raczej do pakietowania zachowań agenta, aby można je było instalować, ponownie wykorzystywać i zarządzać na dużą skalę.
To samo wzorzec występuje w innych miejscach. Podagenty umożliwiają instalację na poziomie użytkownika, projektu, tylko dla danej sesji oraz zdefiniowaną przez pluginy. Umiejętności są zaprojektowane w sposób modułowy, co pozwala na wykorzystywanie powtarzalnych wiedz technicznych poza warstwą pamięci stale ładowanej. Architektura nie ogranicza się do pytania, czy agent może coś zrobić. Coraz częściej bada, w jaki sposób tę zdolność można zapakować i udostępnić – to jest cecha charakterystyczna platformy, a nie asystenta przeznaczonego dla jednego użytkownika.
Rządyzna również jest jego częścią. Jeden wspólny pakiet może zawierać sprawdzone podagenty, ściśle ograniczone uprawnienia do narzędzi, standardowe elementy integracyjne lub procesy pracy specyficzne dla danej organizacji, dzięki czemu zespoły rozpowszechniają polityki, a nie tylko ułatwienia. Ścieżki korporacyjne do centralnie zarządzanych plików CLAUDE.md pokazują, że standaryzacja była planowana od samego początku. Ten sam wielowarstwowy projekt, który przyspiesza pracę pojedynczego inżyniera, może stać się modelem operacyjnym dla całego zespołu, w którym pamięć, wiedza specjalistyczna, kontrole i delegowanie są dzielone zamiast budowane od nowa.
Co się dzieje, gdy brakuje warstwy
Gdy spojrzeć na całość, ta struktura stanowi praktyczną listę kontrolną do diagnozowania niewiarygodnego ustawienia agenta. Objawy zazwyczaj wskazują na brakującą warstwę.
- Agent ciągle zadaje te same pytania lub ignoruje styl domu. Brakuje pamięci. Zasady trwałe powinny znajdować się w pliku CLAUDE.md, być zgrupowane według katalogów i podzielone na sekcje importu, aby plik nie stawał się zbyt duży.
- Każda sesja zaczyna się od długiego, skopiowanego procedur. Wiedza jest uwięziona w instrukcjach. Części, które można powtarzać, należy przenieść do umiejętności, aby ładowały się tylko wtedy, gdy jest to konieczne do wykonania zadania.
- Działania ryzykowne zależą od tego, czy model pamięta o konieczności ostrożności. Zasady bezpieczeństwa są jedynie sugestiami. Elementy typu hook umożliwiają formatowanie, ochronę plików oraz przepisywanie poleceń, niezależnie od decyzji modelu.
- Główna rozmowa wypełnia się logami i ścieżkami bez wyjścia. Brakuje delegowania zadań. Podagenty z ograniczonym zestawem narzędzi przejmują pracę wymagającą dużo uwagi i zwracają jedynie streszczenie.
Wspólnym mianownikiem jest to, że żadna z tych poprawek nie polega na lepszym sformułowaniu zdania w poleceniu. Są to zmiany strukturalne, dlatego sprawdzają się przy rzeczywistych obciążeniach. Traktowanie Claude Code jako zestawu do rozwoju agentów, który przypadkowo działa w terminalu, ułatwia dostrzeżenie tych zmian, łatwiejszą dyskusję z zespołem oraz ich stopniowe wdrażanie, warstwa po warstwie.
Literatura pokrewna
- Harness produkcyjny dla Claude Code: sześć warstw od Slack do połączonego MR — Jak harness składający się z sześciu warstw przekształca zgłoszenia z Slack w połączony kod: przyjmowanie zdarzeń, pętle agenta z kontrolą dostępu, trwały stan, samoregeneracja, możliwości obserwacji oraz kontrola operatora.
- Używanie Codex w VS Code: zakres działania, punkty odzyskiwania oraz rozwiązania typowych problemów — Praktyczny przewodnik po rozszerzeniu Codex dla VS Code: instalacja, logowanie, pierwsze zadanie agenta, użycie chmury w porównaniu z CLI, wspólna konfiguracja oraz rozwiązania problemów z WSL, procedury zatwierdzania i autoryzacja zdalna.