Statyczne umiejętności to martwe umiejętności

Wczoraj wieczorem wdrożyłem sekcję Settings Reference do przewodnika Claude Code. Piętnaście wpisów. Każdy cytat zgrep’owany pod konkretny numer wiersza. Wdrożyłem go z przekonaniem, po tym jak pętla krytyki wróciła czysta. Zanim zdążyłem zacommitować plik .md, już wiedziałem, że będę potrzebował v3 — nie dlatego, że zrobiłem coś źle, ale dlatego, że przewodnik się zmienia, produkt u podstaw się zmienia, zapytania użytkowników się przesuwają, a sekcja, którą właśnie wdrożyłem, zacznie dryfować w chwili, gdy tylko od niej odejdę.

Umiejętność, czy to sekcja referencyjna w Markdown, czy definicja umiejętności agenta w .claude/skills/, żyje tylko tak długo, jak ktoś obserwuje jej trajektorię. W momencie, gdy przestaje się ją obserwować, staje się statyczna. Statyczne umiejętności gniją w miejscu.

Nowy artykuł z arxiv autorstwa Ma, Yang, Ji, Wang i Wang („SkillClaw: Let Skills Evolve Collectively with Agentic Evolver”, kwiecień 2026) formalizuje ten problem na poziomie badawczym.¹ Ich otwierające ujęcie, cytowane bezpośrednio: „Agenci dużych modeli językowych (LLM), tacy jak OpenClaw, polegają na wielorazowych umiejętnościach przy wykonywaniu złożonych zadań, jednak umiejętności te pozostają w dużej mierze statyczne po wdrożeniu. W rezultacie podobne przepływy pracy, wzorce użycia narzędzi i tryby awarii są wielokrotnie odkrywane na nowo przez różnych użytkowników, co uniemożliwia systemowi doskonalenie się wraz z doświadczeniem.”¹

Żyję z tym trybem awarii od miesięcy. Pan/Pani również, jeśli buduje umiejętności dla dowolnego wiązania agenta.

TL;DR

Umiejętności agentów zostają wdrożone, a następnie przestają się doskonalić. Użytkownicy odkrywają niezależnie te same tryby awarii i nigdy nie zwracają tych odkryć do samej umiejętności. Ma i współautorzy ujmują to jako problem inteligencji zbiorowej: interakcje między użytkownikami i w czasie są sygnałami mówiącymi, kiedy umiejętność działa lub zawodzi, ale nie istnieje żaden mechanizm na poziomie ekosystemu, który agregowałby je w aktualizacje umiejętności. Ich framework SkillClaw proponuje traktowanie zagregowanych trajektorii jako sygnału ewolucji, uruchamiając autonomicznego ewolutora, który identyfikuje powtarzające się wzorce zachowań i przekłada je na udoskonalenia lub rozszerzenia możliwości.¹ Abstrakt cytuje „OpenClaw” jako przykład agenta LLM, który używa wielorazowych umiejętności — nie udało mi się zidentyfikować OpenClaw jako konkretnego wdrożonego produktu wyłącznie na podstawie abstraktu i nie zamierzam spekulować na jego temat w tym wpisie. Co zamierzam twierdzić, to że strukturalny problem opisany w artykule odnosi się do każdego, kto buduje umiejętności dla Claude Code, Codex, Cursor lub własnego wiązania. Wniosek: jeśli Pana/Pani biblioteka umiejętności nie przyjmuje w sposób ciągły trajektorii z rzeczywistego użycia, jest martwa od dnia wdrożenia.

Kluczowe wnioski

• Autorzy umiejętności: Praca nie jest skończona, gdy umiejętność zostaje wdrożona. Praca jest skończona, gdy istnieje pętla obserwująca sposób, w jaki umiejętność jest używana, wychwytująca powtarzające się tryby awarii i zwracająca je z powrotem do definicji umiejętności. Wdrożenie jest początkiem życia umiejętności, nie końcem.
• Budowniczowie wiązań: Należy logować każde wywołanie umiejętności wraz z jej trajektorią — wejścia, wywołania narzędzi, wyjścia, stan błędu. Ten log jest sygnałem ewolucji. Jeśli nie jest on logowany, nie doskonali się umiejętności; jedynie się je utrzymuje.
• Praktycy w duchu Jiro: Artykuł SkillClaw to akademicki język dla wzorca Shokunin zastosowanego do umiejętności. Umiejętność jest rzemiosłem. Trajektorie są praktyką. Ewolucja jest dążeniem do mistrzostwa. Statyczne = martwe.

Co artykuł właściwie mówi

Przejdę przez twierdzenia abstraktu z uwagą, a następnie wyraźnie zaznaczę, gdzie rozszerzam jego ujęcie.

Sformułowanie problemu (z abstraktu). Agenci LLM polegają na wielorazowych umiejętnościach przy wykonywaniu złożonych zadań. Umiejętności te pozostają w dużej mierze statyczne po wdrożeniu. Podobne przepływy pracy, wzorce użycia narzędzi i tryby awarii są wielokrotnie odkrywane na nowo przez różnych użytkowników. System nie doskonali się wraz z doświadczeniem.¹

To jest twierdzenie o konkretnym trybie awarii, a nie twierdzenie, że wszystkie umiejętności gniją. Umiejętność, która nigdy nie jest wywoływana, nie gnije. Umiejętność wywoływana przez jednego użytkownika, który nigdy nie zgłasza problemów, nie gnije widocznie. Gnicie pojawia się, gdy ma się wielu użytkowników, z których każdy napotyka własną wersję tej samej awarii, a system nie ma sposobu, by zagregować te napotkania w jedną aktualizację. (To ostatnie zdanie to moje ujęcie, nie artykułu.)

Istniejąca luka (z abstraktu). Abstrakt stwierdza, że chociaż interakcje między użytkownikami „dostarczają uzupełniających się sygnałów o tym, kiedy umiejętność działa lub zawodzi, istniejącym systemom brakuje mechanizmu przekształcania takich heterogenicznych doświadczeń w wiarygodne aktualizacje umiejętności.”¹ To jest twierdzenie nośne. Nie chodzi o to, że nikt nie myślał o doskonaleniu umiejętności. Chodzi o to, że żaden mechanizm na poziomie ekosystemu nie agreguje trajektorii, nie identyfikuje powtarzających się wzorców i nie przekłada ich na aktualizacje.

Potok SkillClaw (z abstraktu). Abstrakt opisuje ciągły potok: SkillClaw „agreguje trajektorie generowane podczas użycia i przetwarza je za pomocą autonomicznego ewolutora, który identyfikuje powtarzające się wzorce zachowań i przekłada je na aktualizacje zestawu umiejętności, udoskonalając istniejące umiejętności lub rozszerzając je o nowe możliwości.”¹ Zaktualizowane umiejętności są utrzymywane we wspólnym repozytorium i synchronizowane między użytkownikami, więc udoskonalenia odkryte w jednym kontekście propagują się w całym systemie bez wymaganego wysiłku ze strony użytkownika.¹

Ewaluacja (z abstraktu). Artykuł ocenia SkillClaw na benchmarku o nazwie WildClawBench, używając Qwen3-Max jako modelu bazowego. Sformułowanie samego abstraktu jest gramatycznie wadliwe w opublikowanej wersji: „experiments on WildClawBench show that limited interaction and feedback, it significantly improves the performance of Qwen3-Max in real-world agent scenarios.”¹ Odczytuję to jako: przy ograniczonej interakcji i informacji zwrotnej, SkillClaw nadal zapewnia znaczącą poprawę wydajności względem punktu odniesienia. Abstrakt nie publikuje konkretnych liczb — pełny artykuł prawdopodobnie tak.

Tyle o artykule, jak opisuje go abstrakt. Autorzy proponują, by ekosystemy agentów wieloużytkownikowych ze współdzielonymi umiejętnościami korzystały z automatycznej agregacji trajektorii zasilającej automatyczne aktualizacje umiejętności, i raportują, że ich implementacja znacząco poprawia wydajność Qwen3-Max w warunkach ograniczonej informacji zwrotnej.

Czego artykuł nie mówi (i co dodaję od siebie)

Abstrakt cytuje „OpenClaw” jako jeden przykład („agenci LLM tacy jak OpenClaw”) agenta używającego wielorazowych umiejętności. Nie wiem, czym jest OpenClaw wyłącznie na podstawie abstraktu — nie udało mi się go szybko zidentyfikować jako konkretnego wdrożonego produktu. Framework artykułu (SkillClaw) jest przedstawiany jako rozwiązanie dla ekosystemów agentów wieloużytkownikowych ogólnie, a nie dla OpenClaw konkretnie, więc pytanie „czym jest OpenClaw” jest w dużej mierze poboczne względem argumentu. Zwracam na to uwagę, żeby nikt nie odszedł od tego wpisu z przekonaniem, że artykuł jest o Claude Code. Nie jest. Wymienia OpenClaw jako przykład i proponuje SkillClaw jako mechanizm ogólny.

Co twierdzę — oddzielnie od artykułu — to że strukturalny problem opisany w artykule odnosi się do rzeczywistego problemu, którym żyję w ekosystemie umiejętności Claude Code. To twierdzenie jest moje, nie artykułu. Oto dlaczego sądzę, że się odnosi.

Umiejętności w ekosystemie Claude Code są wdrażane jako artefakty statyczne. Umiejętność to plik SKILL.md (lub pakiet plików wspierających), który opisuje, jak powinno być wykonane zadanie. Pisze się go raz. Commituje się go. Odwołuje się do niego poleceniem slash lub poprzez podpowiedzi @skill-name. Gdy zostanie wdrożony, jest artefaktem statycznym. Nie istnieje żaden automatyczny mechanizm, który obserwowałby, jak umiejętność jest używana w praktyce, i aktualizowałby jej definicję w oparciu o to, co działa, a co zawodzi.

Różni użytkownicy napotykają niezależnie te same tryby awarii. Każda umiejętność, którą wdrożyłem, ma co najmniej jeden powtarzający się tryb awarii, który pojawia się tylko w specyficznych warunkach. Ktoś wywołuje umiejętność z wejściem, którego nie przewidziałem, trafia na przypadek brzegowy, obchodzi go ręcznie i idzie dalej. Ktoś inny, gdzie indziej, trafia na ten sam przypadek brzegowy i robi własne obejście. Sama umiejętność pozostaje niezmieniona.

Sygnał zagregowany jest realny, ale niewykorzystany. Gdybym mógł zobaczyć każdą trajektorię z każdego wywołania każdej wdrożonej przeze mnie umiejętności, mógłbym zidentyfikować powtarzające się tryby awarii w jedno popołudnie. Ten sygnał istnieje — jest w historii sesji każdego indywidualnego użytkownika. Po prostu nie jest nigdzie agregowany, więc nikt na niego nie reaguje.

Poprawka jest albo ręczna, albo jej brak. W tej chwili jedynym mechanizmem doskonalenia umiejętności jest to, że zauważę problem w swoim własnym użyciu, albo ktoś zgłosi issue, albo ktoś otworzy PR. To wszystko są ścieżki wymagające wysiłku użytkownika. Centralny wgląd artykułu SkillClaw — że dane o trajektoriach już istnieją i powinny być automatycznie przekształcane w aktualizacje umiejętności — to dokładnie ten mechanizm, którego nam brakuje.

To moje twierdzenie o tym, jak ujęcie z artykułu stosuje się do Claude Code. Nie jest to to, co mówi artykuł. Jest to to, jak odczytuję artykuł w kontekście własnej pracy.

Wzorzec Shokunin zastosowany do umiejętności

Istnieje ujęcie, do którego ciągle wracam, gdy myślę o rzemiośle. Jiro Ono, mistrz sushi, jest kanonicznym przykładem. Sześćdziesiąt lat tej samej pracy. Każdego dnia obserwując, co dzieje się przy ladzie, dostosowując technikę, udoskonalając temperaturę ryżu, kąt noża, moment ułożenia shari. Sama praca jest sygnałem treningowym. Praktykujący jest agregatorem.

Pisałem o ujęciu Shokunin / pętli jakości jakiś czas temu. Główna idea: rzemiosło jest pętlą informacji zwrotnej. Wykonuje się pracę, obserwuje się pracę, zauważa się, co się zepsuło, dostosowuje się i wykonuje się pracę ponownie. W kółko. Mistrzostwo żyje w delcie między tym, co się zamierzało, a tym, co faktycznie się wydarzyło, oraz w gotowości przeniesienia tej delty do następnej próby.

Statyczna umiejętność zrywa tę pętlę. Wdraża się umiejętność. Przestaje się obserwować. Delta między tym, co umiejętność zamierzała, a tym, co faktycznie się dzieje, kumuluje się w setkach różnych sesji, których nigdy się nie widzi. Umiejętność nie staje się lepsza, ponieważ rzemieślnika nie ma przy ladzie.

Artykuł SkillClaw proponuje automatycznego agregatora — nie zastępstwo dla człowieka, ale mechanizm obserwujący wszystkie trajektorie, zauważający, co się zepsuło w różnych sesjach, i proponujący aktualizacje z powrotem do definicji umiejętności. To nie jest szalona ambicja. To właściwie minimalny poziom, jeśli chce się, by umiejętność przetrwała własne wdrożenie.

Jak to wygląda w praktyce

Gdybym chciał zbudować wzorzec SkillClaw wobec umiejętności Claude Code, które dziś utrzymuję, oto czego bym potrzebował:

1. Log trajektorii dla każdego wywołania umiejętności. Za każdym razem, gdy umiejętność się uruchamia — wejścia, wywołania narzędzi, jakie wykonuje, wyjścia, stany błędów oraz ostateczne rozstrzygnięcie (czy użytkownik zaakceptował wynik? cofnął? przepisał?). To już istnieje na poziomie sesji w Claude Code — pytanie brzmi, czy jest agregowane między sesjami i wyodrębniane dla właściciela umiejętności.

2. Detektor wzorców. Coś, co czyta log trajektorii i identyfikuje powtarzające się wzorce: ta sama klasa wejścia prowadząca do tej samej awarii, to samo wywołanie narzędzia zawodzące w ten sam sposób, ten sam przypadek brzegowy pojawiający się w różnych kontekstach użytkownika. To nie jest AGI — to klasteryzacja na ustrukturyzowanych danych trajektorii.

3. Generator propozycji. Mając wykryty wzorzec, szkicuje kandydującą aktualizację umiejętności: nową gałąź obsługi, dodatkowy przykład, dodatkowe ograniczenie w treści SKILL.md. Aktualizacja jest propozycją, nie wdrożoną zmianą.

4. Bramka. Każda proponowana aktualizacja przechodzi przez przegląd człowieka, weryfikację faktograficzną (ta sama twarda bramka, którą stosuję do wszystkiego innego) i pętlę krytyki, zanim zostanie wdrożona. Automatyzacja zajmuje się agregacją, nie wdrażaniem.

5. Dystrybucja. Gdy proponowana aktualizacja zostanie zaakceptowana, propaguje się do każdego użytkownika tej umiejętności. W scentralizowanym ekosystemie jest to trywialne (aktualizacja umiejętności kanonicznej, każdy pobiera). W ekosystemie rozproszonym jest to trudniejsze.

Większość tego jest już obecna w Claude Code — logowanie sesji istnieje, definicje umiejętności są wersjonowane, pętla krytyki jest operacyjna — brakującym elementem jest warstwa agregacji i wykrywania wzorców, która łączy trajektorie sesji z aktualizacjami umiejętności.

Niewygodna implikacja

Każda umiejętność, którą wdrożyłem w ciągu ostatnich sześciu miesięcy, jest martwa dokładnie w sensie, który opisuje artykuł SkillClaw. Piszę umiejętność. Sam jej używam. Zauważam problemy. Naprawiam je w umiejętnościach, których ja używam. Umiejętności stają się lepsze dla mnie. Nie stają się lepsze dla nikogo innego, chyba że ta osoba niezależnie zauważy ten sam problem i coś zgłosi.

Praca, którą wykonałem wczoraj wieczorem nad Settings Reference, to dokładnie ten wzorzec. Przewodnik Claude Code jest wspólnym artefaktem. Użytkownicy wyszukują w nim konkretne klucze konfiguracyjne. Widzę dane GSC, które mówią mi, jakie klucze konfiguracyjne są wyszukiwane. To są zagregowane dane trajektorii — dosłownie mówią mi, które umiejętności w przewodniku są wywoływane i gdzie lądują wyniki. I dopóki nie zajrzałem do tych danych, przewodnik był statyczny. Był statyczny od tygodni. Nie dlatego, że nikt nie obserwował trajektorii, ale dlatego, że ja byłem jedyną osobą, która mogła je obserwować, a miałem inne rzeczy do zrobienia.

Artykuł SkillClaw jest akademicką formalizacją problemu. Mechanizm praktyczny jest prostszy: jeśli nie ma się automatycznego potoku od danych trajektorii do aktualizacji umiejętności, Pana/Pani umiejętności starzeją się w miejscu. Mogą nadal działać dla niektórych użytkowników w niektórych warunkach. Nie stają się lepsze.

Jedyne pytanie to, czy akceptuje Pan/Pani, że Pana/Pani umiejętności są martwe w chwili wdrożenia, czy też buduje się obserwatora, który utrzymuje je przy życiu.

Minimalny opłacalny agregator

Zanim zacząłem ten wpis, miałem zerową agregację trajektorii na moich umiejętnościach. Żadnej. Miałem historię sesji, którą mogłem czytać ręcznie, ale nic, co ujawniałoby wzorce między sesjami. To jest dokładnie patologia statycznych umiejętności, którą opisuje artykuł, i ją właśnie uprawiałem.

Oto najmniejsza rzecz, którą mogę wdrożyć przeciwko temu właśnie teraz, dzisiaj: pojedynczy plik tekstowy, który loguje każde wywołanie umiejętności w moich własnych sesjach, tylko z dopisywaniem, ze znacznikiem czasu + nazwą umiejętności + kształtem wejścia + ostatecznym rozstrzygnięciem (zaakceptowane / zmodyfikowane / cofnięte). Bez detektora wzorców. Bez autonomicznego ewolutora. Tylko log.

Ten plik jest minimalnym opłacalnym agregatorem. Nie jest to SkillClaw. Jest to warstwa wejściowa, której SkillClaw by potrzebował, gdyby istniał, i jest to warstwa wejściowa, której ja potrzebuję, zanim w ogóle mogę zobaczyć, czy moje umiejętności mają powtarzające się tryby awarii. Bez niej zgaduję. Z nią mogę przynajmniej przejrzeć log ręcznie podczas przeglądu umiejętności i zapytać: czy ta rzecz zepsuła się w ten sam sposób trzy razy w tym miesiącu?

Taka jest decyzja. Jeden plik. Tylko z dopisywaniem. Logowany na wywołanie. Przeglądany, gdy przeglądam umiejętność.

Jeśli to zadziała, następną warstwą jest detektor wzorców. Jeśli detektor wzorców zadziała, następną warstwą jest generator propozycji. Ambicją artykułu jest pełny autonomiczny ewolutor działający w ekosystemie wieloużytkownikowym. Moją ambicją jest nie działać w ciemno.

FAQ

Czy „OpenClaw” w artykule to to samo co Claude Code?

Nie, i nie potrafię też powiedzieć, czym jest OpenClaw. Abstrakt wymienia „agentów LLM takich jak OpenClaw” jako jeden przykład agenta używającego wielorazowych umiejętności, bez definiowania go. Nie udało mi się go szybko zidentyfikować jako konkretnego wdrożonego produktu wyłącznie na podstawie abstraktu. Istotne jest to, że framework SkillClaw z artykułu jest przedstawiany jako ogólne rozwiązanie dla ekosystemów agentów wieloużytkownikowych, a nie jako rozwiązanie specjalnie dla OpenClaw czy Claude Code. Czymkolwiek jest OpenClaw, artykuł nie jest artykułem o Claude Code, a moje twierdzenia o Claude Code w tym wpisie są moje własne, nie artykułu.¹

Jaki jest rzeczywisty nowatorski wkład artykułu?

Zgodnie z abstraktem: framework dla zbiorowej ewolucji umiejętności w ekosystemach agentów wieloużytkownikowych, który (1) agreguje trajektorie między użytkownikami i w czasie, (2) uruchamia autonomicznego ewolutora do wykrywania powtarzających się wzorców i (3) przekłada wzorce na aktualizacje umiejętności we wspólnym repozytorium, które synchronizują się między użytkownikami.¹ Nowość nie polega na tym, że „umiejętności można doskonalić” — to jest oczywiste. Nowość polega na propozycji, by pętla doskonalenia była autonomiczna i sterowana trajektoriami, a nie sterowana człowiekiem.

Czy artykuł raportuje konkretne liczby poprawy?

Abstrakt opisuje poprawę jako „znaczącą” na benchmarku o nazwie WildClawBench przy użyciu Qwen3-Max, w warunkach ograniczonej informacji zwrotnej, ale nie publikuje konkretnych liczb.¹ Po liczby należy sięgnąć do pełnego artykułu.

Czym to się różni od git pull request wobec definicji umiejętności?

PR jest mechanizmem inicjowanym przez człowieka. Ktoś musi zauważyć problem, napisać poprawkę, złożyć PR, przejrzeć go, zmergować. Każdy krok wymaga wysiłku człowieka. Framework SkillClaw, który proponuje artykuł, to autonomiczna agregacja — system zauważa wzorzec u wielu użytkowników, sam proponuje poprawkę i synchronizuje aktualizację bez konieczności, by jakikolwiek pojedynczy użytkownik cokolwiek składał.¹ To, czy ta autonomiczna wersja jest pożądana lub bezpieczna dla konkretnego ekosystemu, jest osobnym pytaniem. Wkładem artykułu jest pokazanie, że jest to technicznie spójne.

Czy odnosi się to do moich własnych niestandardowych umiejętności Claude Code?

Artykuł nie formułuje twierdzeń o żadnym konkretnym ekosystemie umiejętności Claude Code. Moje twierdzenie — oddzielnie od artykułu — to że strukturalny problem (umiejętności wdrażane jako artefakty statyczne, tryby awarii odkrywane na nowo przez każdego użytkownika niezależnie, brak mechanizmu agregacji) rzeczywiście odnosi się do umiejętności Claude Code, i że każdy, kto buduje umiejętności dla Claude Code lub podobnego wiązania, powinien myśleć o tym, jak zbudować pętlę doskonalenia sterowaną trajektoriami. To jest moja opinia, nie ustalenie z artykułu.

Jaki jest związek z Shokunin?

Ujęcie Shokunin / pętli jakości argumentuje, że mistrzostwo pochodzi z delty między tym, co się zamierzało, a tym, co faktycznie się wydarzyło, przenoszonej do następnej próby. Statyczne umiejętności zrywają tę pętlę, ponieważ delty kumulują się w sesjach, których rzemieślnik nigdy nie widzi. SkillClaw jest akademicką wersją domknięcia tej pętli — automatyzacją zbierania delt i zwracaniem ich z powrotem do umiejętności. Dyscyplina jest ta sama; mechanizm jest inny.

Bibliografia