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

Wczoraj wieczorem opublikowałem sekcję Referencje ustawień w przewodniku Claude Code. Piętnaście wpisów. Każde cytowanie zweryfikowane pod kątem numeru linii. Wypuściłem to z przekonaniem, po tym jak pętla krytyki wróciła bez zastrzeżeń. Zanim zacommitowałem plik .md, już wiedziałem, że będę potrzebował wersji v3 — nie dlatego, że zrobiłem coś źle, lecz dlatego, że przewodnik się zmienia, zmienia się produkt leżący u jego podstaw, przesuwają się zapytania użytkowników, a sekcja, którą właśnie opublikowałem, zacznie dryfować w momencie, gdy od niej odejdę.

Umiejętność (niezależnie od tego, czy jest to sekcja referencyjna w Markdown, czy definicja skill agenta w .claude/skills/) żyje tylko dopóty, dopóki ktoś obserwuje jej trajektorię. W chwili, gdy przestaje Pan/Pani obserwować, staje się ona statyczna. Statyczne umiejętności degradują się w miejscu. Poniższy wpis jest częścią serii AI engineering dokumentującej, jak infrastruktura agentów ewoluuje w środowisku produkcyjnym.

Statyczne umiejętności agentów AI zawodzą, ponieważ przestają się uczyć w momencie wydania. Bez pętli informacji zwrotnej, która pochłania rzeczywiste trajektorie wywołań (wejścia, wywołania narzędzi, wyjścia i stany błędów z faktycznego użycia), umiejętności nie są w stanie dostosować się do zmieniających się produktów, przesuwających się zapytań użytkowników ani powtarzających się trybów awarii. Wielu użytkowników niezależnie odkrywa na nowo te same obejścia, podczas gdy definicja umiejętności pozostaje zamrożona. Rozwiązaniem jest ciągła agregacja trajektorii, która przekształca wzorce użytkowania w zautomatyzowane aktualizacje umiejętności.

Nowa praca 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 sformułowanie, zacytowane bezpośrednio: „Agenci dużych modeli językowych (LLM), tacy jak OpenClaw, polegają na wielokrotnie używanych umiejętnościach do wykonywania 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 uczenie się na podstawie doświadczenia.”¹

Od miesięcy żyję z tym trybem awarii. Pan/Pani również, jeśli buduje Pan/Pani umiejętności dla jakiegokolwiek frameworku agenta.

TL;DR

Umiejętności agentów są wypuszczane, a następnie przestają się ulepszać. Użytkownicy niezależnie odkrywają te same tryby awarii i nigdy nie przekazują tych odkryć z powrotem do samej umiejętności. Ma i in. przedstawiają to jako problem inteligencji zbiorowej: interakcje między użytkownikami i rozłożone w czasie stanowią sygnał o tym, 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 behawioralne i przekłada je na udoskonalenia lub rozszerzenia możliwości.¹ Abstrakt powołuje się na „OpenClaw” jako przykład agenta LLM, który używa wielokrotnie używanych umiejętności. Nie udało mi się zidentyfikować OpenClaw jako konkretnego produktu wypuszczonego na rynek wyłącznie na podstawie abstraktu i nie zamierzam w tym wpisie spekulować na ten temat. To, co zamierzam twierdzić, to fakt, że strukturalny problem opisany w pracy odnosi się do każdego, kto buduje umiejętności dla Claude Code, Codex, Cursor lub własnego frameworku agenta. Wniosek: jeśli Pana/Pani biblioteka umiejętności nie pochłania nieprzerwanie trajektorii z rzeczywistego użycia, jest martwa od dnia wydania.

Kluczowe wnioski

• Autorzy umiejętności: Praca nie jest skończona, gdy umiejętność zostaje wydana. Praca jest skończona, gdy ma Pan/Pani pętlę, która obserwuje, jak umiejętność jest używana, wychwytuje powtarzające się tryby awarii i przekazuje je z powrotem do definicji umiejętności. Wydanie jest początkiem życia umiejętności, a nie jego końcem.
• Twórcy frameworków: Proszę logować każde wywołanie umiejętności wraz z jej trajektorią: wejściami, wywołaniami narzędzi, wyjściami, stanem błędu. Ten log jest sygnałem ewolucji. Jeśli Pan/Pani go nie loguje, nie ulepsza Pan/Pani swoich umiejętności; jedynie je utrzymuje.
• Praktycy o nastawieniu Jiro: Praca 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 praca faktycznie mówi

Zamierzam ostrożnie przejść przez twierdzenia z abstraktu, a następnie wyraźnie zaznaczyć, gdzie rozszerzam ich ujęcie.

Sformułowanie problemu (z abstraktu). Agenci LLM polegają na wielokrotnie używanych umiejętnościach do wykonywania 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 uczy się na podstawie doświadczenia.¹

Autorzy biorą na cel konkretny tryb awarii, a nie uniwersalne twierdzenie, że wszystkie umiejętności się degradują. Umiejętność, która nigdy nie zostaje wywołana, nie ulega degradacji. Umiejętność, którą jeden użytkownik wywołuje bez zgłaszania problemów, nie degraduje się w zauważalny sposób. Degradacja ujawnia się, gdy wielu użytkowników napotyka własną wersję tej samej awarii, a system nie ma sposobu, by zagregować te spotkania w jedną aktualizację. (To ostatnie zdanie jest moim ujęciem, nie pracy.)

Istniejąca luka (z abstraktu). Abstrakt stwierdza, że chociaż interakcje między użytkownikami „dostarczają komplementarnych sygnałów o tym, kiedy umiejętność działa lub zawodzi, istniejącym systemom brakuje mechanizmu przekształcania tak heterogenicznych doświadczeń w wiarygodne aktualizacje umiejętności.”¹ Nośne twierdzenie tkwi właśnie tutaj. Luka nie polega na tym, że nikt nie pomyślał o ulepszaniu umiejętności. Luka polega na tym, że żaden mechanizm na poziomie ekosystemu nie agreguje trajektorii, nie identyfikuje powtarzających się wzorców i nie przekłada ich na aktualizacje.

Pipeline SkillClaw (z abstraktu). Abstrakt opisuje ciągły pipeline: SkillClaw „agreguje trajektorie generowane podczas użytkowania i przetwarza je za pomocą autonomicznego ewolutora, który identyfikuje powtarzające się wzorce behawioralne i przekłada je na aktualizacje zestawu umiejętności poprzez udoskonalanie istniejących umiejętności lub rozszerzanie ich o nowe możliwości.”¹ System utrzymuje zaktualizowane umiejętności we współdzielonym repozytorium i synchronizuje je między użytkownikami, tak że ulepszenia odkryte w jednym kontekście rozprzestrzeniają się w całym systemie bez wymagania wysiłku ze strony użytkowników.¹

Ocena (z abstraktu). Praca ocenia SkillClaw na benchmarku o nazwie WildClawBench, używając Qwen3-Max jako modelu bazowego. Własne sformułowanie abstraktu jest gramatycznie wybrakowane w wersji opublikowanej: „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ące ulepszenia wydajności względem punktu odniesienia. Abstrakt nie publikuje konkretnych liczb; pełna praca przypuszczalnie tak.

Tym jest praca według opisu z abstraktu. Autorzy proponują, że wieloużytkownikowe ekosystemy agentów ze współdzielonymi umiejętnościami korzystają ze zautomatyzowanej agregacji trajektorii zasilającej zautomatyzowane aktualizacje umiejętności, i raportują, że ich implementacja znacząco poprawia wydajność Qwen3-Max w warunkach ograniczonej informacji zwrotnej.

Czego praca nie mówi (i co dodaję)

Abstrakt powołuje się na „OpenClaw” jako jeden przykład („agenci LLM, tacy jak OpenClaw”) agenta, który używa wielokrotnie używanych umiejętności. Nie wiem, czym jest OpenClaw, na podstawie samego abstraktu; nie mogłem szybko zidentyfikować go jako konkretnego produktu wypuszczonego na rynek. Framework pracy (SkillClaw) bierze na cel wieloużytkownikowe ekosystemy agentów ogólnie, a nie konkretnie OpenClaw, więc pytanie „czym jest OpenClaw” jest w dużej mierze styczne wobec argumentacji. Zaznaczam to, aby nikt nie odczytał tego wpisu i nie odszedł z przekonaniem, że praca dotyczy Claude Code. Nie dotyczy. Wymienia OpenClaw jako przykład i proponuje SkillClaw jako ogólny mechanizm.

To, co twierdzę, oddzielnie od pracy, to że strukturalny problem opisany w pracy odnosi się do realnego problemu, z którym żyję w ekosystemie umiejętności Claude Code. To twierdzenie jest moje, nie pracy. Oto dlaczego uważam, że się odnosi.

Umiejętności w ekosystemie Claude Code są wypuszczane jako statyczne artefakty. Umiejętność to plik SKILL.md (lub pakiet plików pomocniczych), który opisuje, jak powinno zostać wykonane zadanie. Pisze się ją raz. Commituje się ją. Odwołuje się do niej poleceniem slash lub przez podpowiedź @skill-name; mechanika budowania niestandardowych umiejętności jest prosta. Po wydaniu jest statycznym artefaktem. Żaden automatyczny mechanizm nie obserwuje, jak umiejętność jest używana w praktyce, ani nie aktualizuje jej definicji na podstawie tego, co działa, a co zawodzi.

Różni użytkownicy niezależnie napotykają te same tryby awarii. Każda umiejętność, którą wypuściłem, ma co najmniej jeden powtarzający się tryb awarii, który pojawia się tylko w określonych warunkach. Ktoś wywołuje umiejętność z danymi wejściowymi, których nie przewidziałem, trafia na przypadek brzegowy, obchodzi go ręcznie i idzie dalej. Inna osoba, gdzieś indziej, trafia na ten sam przypadek brzegowy i tworzy własne obejście. Sama umiejętność nigdy się nie zmienia.

Zagregowany sygnał jest realny, ale niewykorzystywany. Gdybym mógł zobaczyć każdą trajektorię z każdego wywołania każdej umiejętności, którą wypuściłem, mógłbym zidentyfikować powtarzające się tryby awarii w jedno popołudnie. Ten sygnał istnieje w historii sesji każdego pojedynczego użytkownika. Po prostu nigdzie nie jest agregowany, więc nikt na nim nie działa.

Rozwiązaniem jest albo praca ręczna, albo jego brak. W tej chwili jedynym mechanizmem ulepszania umiejętności jest zauważenie przeze mnie problemu w moim własnym użytkowaniu albo ktoś zgłaszający issue, albo ktoś otwierający PR. Wszystkie te ścieżki wymagają wysiłku użytkownika. Kluczowy wgląd pracy SkillClaw, że dane trajektorii już istnieją i powinny automatycznie zasilać aktualizacje umiejętności, to dokładnie ten mechanizm, którego brakuje.

To moje twierdzenie o tym, jak ujęcie pracy stosuje się do Claude Code. Nie jest to to, co mówi praca. To sposób, w jaki czytam pracę wobec mojej własnej pracy.

Wzorzec Shokunin zastosowany do umiejętności

Jedno ujęcie stale wypływa, gdy myślę o rzemiośle. Jiro Ono, mistrz sushi, jest kanonicznym przykładem. Sześćdziesiąt lat tej samej pracy. Każdego dnia obserwuje, co dzieje się przy ladzie, dostosowuje technikę, udoskonala temperaturę ryżu, kąt noża, moment przygotowania shari. Sama praca jest sygnałem treningowym. Praktyk jest agregatorem.

Pisałem o ujęciu Shokunin / pętli jakości jakiś czas temu. Kluczowa idea: rzemiosło jest pętlą informacji zwrotnej. Wykonuje się pracę, obserwuje się pracę, zauważa się, co się zepsuło, dostosowuje się, ponownie wykonuje się pracę. Raz za razem. Mistrzostwo żyje w różnicy między tym, co się zamierzało, a tym, co rzeczywiście się wydarzyło, oraz w gotowości, by tę różnicę przenieść do następnej próby.

Statyczna umiejętność przerywa tę pętlę. Wypuszcza się umiejętność. Przestaje się obserwować. Różnica między tym, co umiejętność zamierzała, a tym, co rzeczywiście 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.

Praca SkillClaw proponuje zautomatyzowanego agregatora: nie zamiennik człowieka, lecz mechanizm, który obserwuje wszystkie trajektorie, zauważa, co się zepsuło w poszczególnych sesjach, i proponuje aktualizacje z powrotem do definicji umiejętności. Ambicja nie jest szalona. Jest to w istocie minimalny próg, jeśli chce się, aby umiejętność przetrwała własne wdrożenie.

Jak to wygląda w praktyce

Gdybym chciał zbudować wzorzec SkillClaw na bazie 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, które wykonuje, wyjścia, stany błędów oraz końcowa dyspozycja (czy użytkownik zaakceptował wynik? cofnął go? napisał od nowa?). Logowanie na poziomie sesji już istnieje w Claude Code; pytanie brzmi, czy jest agregowane między sesjami i wydobywane 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ść 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żytkowników. Wymaganiem jest klasteryzacja na danych trajektorii o strukturze, a nie AGI.

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

4. Bramka. Każda proponowana aktualizacja przechodzi przez przegląd człowieka, weryfikację merytoryczną (tę samą twardą bramkę, którą stosuję do wszystkiego innego) oraz pętlę krytyki, zanim zostanie wydana. Automatyzacja wykonuje agregację, a nie wydawanie.

5. Dystrybucja. Gdy proponowana aktualizacja zostaje zaakceptowana, rozchodzi się do każdego użytkownika tej umiejętności. W scentralizowanym ekosystemie jest to trywialne (aktualizacja kanonicznej umiejętności, wszyscy pobierają). W rozproszonym ekosystemie jest to trudniejsze.

Większość tego już istnieje w Claude Code: logowanie sesji, wersjonowane definicje umiejętności, operacyjna pętla krytyki. Brakującym elementem jest warstwa agregacji i wykrywania wzorców, która łączy trajektorie sesji z aktualizacjami umiejętności. Taksonomia organizacyjna poleceń, umiejętności, subagentów i reguł zapewnia już strukturalny fundament; brakuje kanału informacji zwrotnej, który utrzymuje każdą kategorię przy życiu po wdrożeniu.

Niewygodna implikacja

Każda umiejętność, którą wypuściłem w ciągu ostatnich sześciu miesięcy, jest martwa dokładnie w sensie opisanym przez pracę SkillClaw. Piszę umiejętność. Sam jej używam. Zauważam problemy. Naprawiam je w umiejętnościach, których ja używam. Moje umiejętności stają się dla mnie lepsze. 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 Referencjami ustawień, jest dokładnie tym wzorcem. Przewodnik Claude Code jest współdzielonym artefaktem. Użytkownicy pytają o konkretne klucze konfiguracyjne. Widzę dane GSC mówiące mi, których kluczy konfiguracyjnych się szuka. To są zagregowane dane trajektorii, dosłownie mówiące mi, które umiejętności w przewodniku są wywoływane i gdzie lądują rezultaty. I dopóki nie poszedłem sprawdzić tych danych, przewodnik był statyczny. Był statyczny od tygodni. Nie dlatego, że nikt nie obserwował trajektorii, lecz dlatego, że byłem jedyną osobą, która mogła je obserwować, a miałem inne sprawy.

Praca SkillClaw to akademicka formalizacja problemu. Praktyczny mechanizm jest prostszy: jeśli nie ma się automatycznego pipeline’u od danych trajektorii do aktualizacji umiejętności, 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 brzmi, czy akceptuje się, że umiejętności umierają w momencie wydania, czy buduje się obserwatora, który utrzymuje je przy życiu. Tu stosuje się zasada compound context: każda obserwacja trajektorii kumuluje się z następną, a wartość umiejętności rośnie nieliniowo wraz z informacją zwrotną, którą pochłania. Odwrotnie, traktowanie kontekstu jako architektury oznacza uznanie, że struktura umiejętności determinuje jej zdolność do wchłaniania nowej informacji w ogóle.

Minimalny wartościowy agregator

Zanim zacząłem ten wpis, miałem zerową agregację trajektorii w moich umiejętnościach. Żadną. Miałem historię sesji, którą mogłem czytać ręcznie, ale nic, co wydobywałoby wzorce między sesjami. To właśnie patologia statycznej umiejętności opisana w pracy, a ja ją uruchamiałem.

Oto najmniejsza realna rzecz, którą mogę wypuścić natychmiast, dzisiaj: pojedynczy plik tekstowy, który loguje każde wywołanie umiejętności we wszystkich moich sesjach, w trybie append-only, ze znacznikiem czasu + nazwą umiejętności + kształtem wejścia + końcową dyspozycją (zaakceptowane / zrewidowane / cofnięte). Bez detektora wzorców. Bez autonomicznego ewolutora. Tylko log.

Ten plik jest minimalnym wartościowym agregatorem. Nie jest to SkillClaw. Jest to warstwa wejściowa, której SkillClaw by potrzebował, gdyby istniał, i warstwa wejściowa, której potrzebuję, zanim będę mógł w ogóle zobaczyć, czy moje umiejętności mają powtarzające się tryby awarii. Bez niej zgaduję. Z nią mogę przynajmniej przejrzeć log ręcznie, gdy przeglądam umiejętność, i zapytać: czy ta sama awaria wystąpiła trzy razy w tym miesiącu?

To jest zobowiązanie. Jeden plik. Append-only. Logowany per 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ą pracy jest w pełni autonomiczny ewolutor działający w wieloużytkownikowym ekosystemie. Moją ambicją jest nie działać po omacku.

FAQ

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

Nie, a ja również nie jestem w stanie powiedzieć, czym jest OpenClaw. Abstrakt wspomina „agentów LLM, takich jak OpenClaw” jako jeden przykład agenta używającego wielokrotnie używanych umiejętności, bez jego definiowania. Nie mogłem szybko zidentyfikować go jako konkretnego produktu wypuszczonego na rynek na podstawie samego abstraktu. Rzecz ważna: framework SkillClaw z pracy bierze na cel wieloużytkownikowe ekosystemy agentów ogólnie, nie konkretnie OpenClaw ani Claude Code. Czymkolwiek jest OpenClaw, praca nie jest pracą o Claude Code, a moje twierdzenia dotyczące Claude Code w tym wpisie są moje własne, nie pracy.¹

Jaki jest faktyczny nowatorski wkład pracy?

Według abstraktu: framework dla zbiorowej ewolucji umiejętności w wieloużytkownikowych ekosystemach agentów, który (1) agreguje trajektorie między użytkownikami i w czasie, (2) uruchamia autonomicznego ewolutora w celu wykrywania powtarzających się wzorców oraz (3) przekłada wzorce na aktualizacje umiejętności we współdzielonym repozytorium, które synchronizują się między użytkownikami.¹ Nowością nie jest „umiejętności można ulepszać” (to oczywiste). Nowością jest propozycja, by pętla ulepszeń była autonomiczna i napędzana trajektoriami, a nie napędzana przez człowieka.

Czy praca podaje konkretne liczby ulepszeń?

Abstrakt opisuje ulepszenie jako „znaczące” na benchmarku o nazwie WildClawBench z użyciem Qwen3-Max, w warunkach ograniczonej informacji zwrotnej, lecz nie publikuje konkretnych liczb.¹ Źródłem liczb jest pełna praca.

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

PR jest mechanizmem inicjowanym przez człowieka. Ktoś musi zauważyć problem, napisać poprawkę, złożyć PR, zrecenzować go, zmergować. Każdy krok wymaga wysiłku człowieka. Framework SkillClaw proponowany przez pracę jest autonomiczną agregacją — system zauważa wzorzec wśród wielu użytkowników, sam proponuje poprawkę i synchronizuje aktualizację, nie wymagając, by jakikolwiek pojedynczy użytkownik cokolwiek zgłaszał.¹ To, czy ta autonomiczna wersja jest pożądana lub bezpieczna dla jakiegokolwiek konkretnego ekosystemu, to odrębne pytanie. Wkładem pracy jest pokazanie, że jest ona technicznie spójna.

Czy stosuje się to do moich niestandardowych umiejętności Claude Code?

Praca nie formułuje twierdzeń o żadnym konkretnym ekosystemie umiejętności Claude Code. Moje twierdzenie, odrębne od pracy, jest takie, że problem strukturalny (umiejętności wypuszczane jako statyczne artefakty, tryby awarii odkrywane na nowo niezależnie przez każdego użytkownika, brak mechanizmu agregacji) istotnie odnosi się do umiejętności Claude Code, a każdy, kto buduje umiejętności dla Claude Code lub jakiegokolwiek podobnego frameworku agenta, powinien myśleć o tym, jak zbudować pętlę ulepszeń napędzaną trajektoriami. To moja opinia, nie ustalenie z pracy.

Jakie jest powiązanie z Shokunin?

Ujęcie Shokunin / pętli jakości argumentuje, że mistrzostwo bierze się z różnicy między tym, co się zamierzało, a tym, co rzeczywiście się wydarzyło, przeniesionej do następnej próby. Statyczne umiejętności przerywają tę pętlę, ponieważ różnice kumulują się w sesjach, których rzemieślnik nigdy nie widzi. SkillClaw jest akademicką wersją zamknięcia tej pętli: automatyzacją zbierania różnic i przekazywania ich z powrotem do umiejętności. Dyscyplina jest taka sama; mechanizm jest inny.

Referencje