SkillClaw: Jak sprawić, by umiejętności agentów LLM ewoluowały kolektywnie

Wyobraź sobie, że 8 osób w firmie korzysta z tego samego asystenta AI. Każdy z nich napotyka te same problemy - zły port API, brakujący plik, źle sformatowany argument - i za każdym razem samodzielnie odkrywa obejście. Następnego dnia ktoś inny wpada w dokładnie ten sam dół. System nie uczy się z doświadczenia swoich użytkowników. Co gdyby nocna “zmiana redakcyjna” automatycznie analizowała wszystkie interakcje z dnia, wyciągała wnioski i rano udostępniała ulepszone procedury wszystkim?

Dokładnie to robi SkillClaw - framework, który zamienia izolowane interakcje wielu użytkowników w ciągłą, kolektywną ewolucję umiejętności agentów LLM.

Motywacja: Dlaczego statyczne umiejętności to problem?

Współczesne systemy agentowe, takie jak OpenClaw, opierają się na skill’ach - strukturyzowanych procedurach, które kodują jak agent powinien używać narzędzi i rozwiązywać zadania. Użytkownicy instalują skills z centralnego hubu i te skills stają się podstawowymi budulcami zachowania agenta.

Problem? Te skills są statyczne. Po deployu nie ewoluują.

W praktyce oznacza to, że:

• Te same workflow’e, wzorce użycia narzędzi i tryby awarii są wielokrotnie odkrywane niezależnie przez różnych użytkowników
• Rozwiązania znalezione podczas interakcji nie przetrwają poza sesją - giną wraz z zamknięciem okna
• System nie gromadzi wiedzy na poziomie systemowym - każdy użytkownik zaczyna od zera

Istniejące podejścia nie rozwiązują tego problemu w pełni:

Brakuje mechanizmu, który zamienia codzienne interakcje w ciągłą ewolucję umiejętności - i to kolektywnie, między użytkownikami.

Kluczowy pomysł: Kolektywna ewolucja przez agentic evolver

Zanim przejdziemy do formalizmów, zbudujmy intuicję.

Pomyśl o firmowym podręczniku procedur (SOP). Osiem osób go używa, każda w nieco innym kontekście. Ktoś odkrywa, że procedura X nie działa gdy plik jest w formacie PDF zamiast TXT. Ktoś inny odkrywa, że port API zmienił się z 9100 na 9110. Jeszcze ktoś wymyśla lepszą kolejność kroków.

W typowym systemie te odkrycia pozostają w prywatnych notatkach. W SkillClaw działa to inaczej:

1. Zbieranie dowodów: Każda interakcja jest rejestrowana z pełnym łańcuchem przyczynowym - co agent zrobił, jaką odpowiedź dostał, co poszło nie tak
2. Grupowanie: Sesje są grupowane według użytych skills - wszystkie interakcje z tym samym skill’em trafiają do jednej “puli dowodowej”
3. Autonomiczny redaktor: Agent LLM (evolver) analizuje sukcesy i porażki, i decyduje: naprawić istniejący skill? Stworzyć nowy? Zostawić bez zmian?
4. Nocna walidacja: Kandydackie zmiany testowane w realnych warunkach. Tylko potwierdzone ulepszenia trafiają do deployu
5. Synchronizacja: Rano wszyscy użytkownicy dostają ulepszoną wersję

Kluczowy insight tego podejścia: różni użytkownicy wywołujący ten sam skill w różnych kontekstach tworzą naturalną ablację. Kiedy 5 użytkowników wywołuje skill “Slack summarization” i 3 z nich odnoszą sukces, a 2 nie - porównanie ujawnia dokładnie gdzie skill się łamie. Jeden użytkownik generuje za mało sygnału, żeby odróżnić uogólnialną poprawkę od jednorazowego obejścia. Agregacja wielu użytkowników dostarcza stabilną bazę dowodową.

Formalizacja: Jak działa SkillClaw

Formalnie, niech $S = {s_1, \ldots, s_M}$ oznacza współdzielony zbiór umiejętności, gdzie każda umiejętność to wielokrotnie używalny proceduralny artefakt. Każda interakcja użytkownika generuje trajektorię sesji $\tau$, która rejestruje pełną pętlę: prompt, akcje agenta, feedback ze środowiska i finalną odpowiedź.

Cel systemu można wyrazić jednym równaniem:

$$ S’ = \Phi(S, T) \tag{1} $$

gdzie:

• $S$ - bieżący zbiór umiejętności
• $T = {\tau_i}$ - zbiór trajektorii zebranych od wielu użytkowników
• $\Phi$ - operator ewolucji
• $S’$ - zaktualizowany zbiór umiejętności

Interpretacja: Weź obecny zestaw skills i zebrane interakcje użytkowników, wyprodukuj ulepszoną wersję. Kluczowe: $T$ zawiera trajektorie od wielu użytkowników - to perspektywa niedostępna żadnemu pojedynczemu agentowi.

Od izolowanych sesji do wspólnej bazy dowodowej

Ewolucja odbywa się w dwóch etapach: strukturyzacja i agregacja.

Strukturyzacja. Każda surowa sesja jest przekształcana w reprezentację zachowującą łańcuch przyczynowy:

$$ \text{prompt} \rightarrow \text{action} \rightarrow \text{feedback} \rightarrow \cdots \rightarrow \text{agent response} \tag{2} $$

Dlaczego to ważne? Większość awarii na poziomie skill’i jest proceduralna - zły format argumentu, brak kroku walidacji, błędna kolejność wywołań narzędzi. Te problemy są niewidoczne w finalnej odpowiedzi agenta. Można je zdiagnozować tylko z pełnego łańcucha akcja-feedback.

Z każdej sesji wyciągane są też metadane: (i) które skills zostały użyte, (ii) czy wystąpiły błędy narzędzi, (iii) zgrubne oszacowanie jakości.

Agregacja i grupowanie. Sesje grupowane są po skill’ach, które wywołały:

$$ G(s) = {\tau_i \mid s \in K_i} \tag{3} $$

gdzie:

• $G(s)$ - grupa sesji wywołujących skill $s$
• $K_i$ - zbiór skill’i użytych w sesji $\tau_i$
• $G(\emptyset)$ - sesje nie używające żadnego skilla

Interpretacja: To grupowanie to coś więcej niż organizacja danych. Kiedy wiele sesji wywołuje ten sam skill, ale daje różne wyniki u różnych użytkowników, w różnych zadaniach i środowiskach - skill staje się kontrolowanym czynnikiem, a porównanie bezpośrednio ujawnia gdzie skill działa, a gdzie zawodzi. To naturalna ablacja, która umożliwia dwie operacje niewykonalne z danych jednego użytkownika:

1. Ocenę jak istniejący skill faktycznie performuje w realnym użyciu
2. Identyfikację powtarzających się procedur, których żaden skill nie pokrywa (z wzorców w $G(\emptyset)$)

Agentic Skill Evolution - Refine, Create, Skip

Serce systemu to agentic evolver - agent LLM wyposażony w strukturyzowany harness, który dostarcza pogrupowane sesje, definicje skill’i i dozwolone akcje. Harness zapewnia strukturę, ale nie ogranicza rozumowania evolvera.

Dla danego skilla $s$ i jego grupy sesji $G(s)$, evolver analizuje sukcesy i porażki, a następnie wybiera jedną z trzech akcji:

• Refine - zaktualizuj skill, korygując zidentyfikowane błędy lub poprawiając niezawodność
• Create - stwórz nowy skill, gdy $G(s)$ ujawnia powtarzające się podprocedury niezachycone przez istniejące skills
• Skip - zostaw skill bez zmian, gdy dowody są niewystarczające

Dlaczego nie reguły, a agent? Awarie skill’i są heterogeniczne - różne formaty, długości kontekstu, typy błędów. Predefiniowane reguły (np. pattern matching na komunikatach błędów) byłyby zbyt kruche dla realnych scenariuszy. Agent LLM może reasoning’ować end-to-end nad sesją dowolnej długości i formatu.

Kluczowa zasada ewolucji: wspólna analiza sukcesów i porażek. Sukcesy definiują inwarianty - części skill’a, które działają i nie mogą być zmienione. Porażki definiują cele - konkretne zachowania wymagające korekty. Ta wspólna perspektywa zapobiega naiwnej naprawie, w której fixowanie jednego buga łamie coś, co wcześniej działało. Każda aktualizacja koryguje deficyty, zachowując to, co sukcesy potwierdziły - ewolucja jest kumulatywna.

Pętla synchronizacji i nocna walidacja

Po ewolucji kandydackie aktualizacje przechodzą walidację zanim trafią do wspólnego repozytorium. Walidacja odbywa się nocą w dostępnych idle’owych środowiskach użytkowników:

1. Dla skill’a $s$ i jego kandydackiej aktualizacji $s’$ system wybiera relevantne zadania z dziennych interakcji
2. Obie wersje są wykonywane w tych samych warunkach - pełny toolchain, wielokrokowe interakcje, pośredni feedback
3. Model porównuje wyniki: jeśli $s’$ jest lepszy → Accept; w przeciwnym razie → Reject
4. Zaakceptowane aktualizacje mergowane do wspólnego repozytorium i synchronizowane do wszystkich agentów na następny dzień

Ta strategia wprowadza monotoniczność deployu: ponieważ tylko ulepszenia są akceptowane, wdrożony zestaw skills nie degraduje się w czasie. Użytkownicy zawsze interagują z najlepszą walidowaną pulą z poprzedniej nocy.

Cała pętla:

$$ \text{Interaction} \rightarrow \text{Evidence} \rightarrow \text{Evolution} \rightarrow \text{Validation} \rightarrow \text{Deployment} \tag{4} $$

Z perspektywy użytkownika - nic z tego nie jest widoczne. Użytkownicy korzystają ze swoich agentów jak zwykle, a ewolucja skill’i dzieje się w tle.

Algorytm krok po kroku

Kompletny algorytm kolektywnej ewolucji skill’i:

Algorithm: Agentic Collective Skill Evolution
Input: Skill repository S, user sessions T
Output: Updated repository S'

1. Convert T into structured evidence E
2. Group E by referenced skills → {G(s)} and G(∅)
3. S' ← S
4. For each group G(s):
   a. Agentic evolver analyzes recurring success/failure patterns
   b. Select action from {refine, create, skip}
   c. Generate candidate skill update if evidence supports modification
   d. Apply conservative editing and validation
   e. Merge approved updates into S'
5. Analyze G(∅) for missing but reusable procedures
6. Add validated new skills into S'
7. Synchronize S' back to all agents
8. Return S'

Trzy kluczowe właściwości wynikające z tego designu:

1. Kolektywna ewolucja - sesje agregowane między użytkownikami; wiedza z jednej interakcji propaguje się do wspólnego ekosystemu
2. Pełna automatyzacja - cały pipeline (rejestracja → ewolucja → synchronizacja) bez ręcznej kuracji czy interwencji użytkownika
3. Agentic adaptability - aktualizacje produkowane przez open-ended reasoning, nie predefiniowane reguły

Eksperymenty na WildClawBench

Setup eksperymentalny

Autorzy ewaluują SkillClaw na WildClawBench - benchmarku 60 złożonych zadań w 6 domenach (productivity, code, social, retrieval, creative, safety). Kluczowe właściwości benchmarku:

• Pełne środowisko wykonawcze (kontener Linux z narzędziami)
• Multimodalne wejścia (tekst, kod, obraz, wideo)
• 15-50 kroków na zadanie
• Krytyczne błędy → wynik zero

Symulacja: 6 dni (6 rund), 8 równoległych użytkowników, cykl dzień/noc, Qwen3-Max jako model backbone.

Wyniki główne

Creative Synthesis z największym relatywnym skokiem (+88.41%) - ale uwaga: główny bottleneck to nie generowanie treści, a setup środowiska (walidacja plików, konfiguracja katalogów, pipeline’y multimedialne).

Kontrolowana walidacja na 3 izolowanych zadaniach potwierdza mechanizm:

Ewolucja najskuteczniejsza dla braków proceduralnych (save report: brak procedury zapisu → pełna korekta). Słabsza dla zadań wymagających głębszego rozumowania (deadline parsing: +6.9%).

Analiza ewolucji per kategoria

Każda kategoria wykazuje inny wzorzec ewolucji:

Social Interaction - szybki skok na Dzień 2, potem stabilizacja. Główna poprawa: skill “cross-dept Slack summarization” przepisany z opisowej instrukcji w eksplicitny proceduralny workflow. Jeden skill wystarczył.

Search & Retrieval - stopniowa poprawa (Day 2: +7.27, Day 4: +4.55). Ewolucja warstwowa: najpierw walidacja plików i ścieżek (fundament), potem constraint-aware retrieval planning (nadbudowa). Wyższe reasoning skuteczne dopiero gdy niższy poziom jest niezawodny.

Creative Synthesis - duży skok na Day 2, potem plateau. Zaakceptowany skill: validate-tmp-workspace-inputs - walidacja katalogu /tmp_workspace przed zadaniami kreatywnymi. Późniejsze, bardziej złożone pipeline’y multimedialne nie przeszły walidacji w oknie 6 dni.

Safety & Alignment - poprawa dopiero od Day 5. Skills skupione na reliability pod kątem realnych warunków: fallback dla Git push bez credentials, poprawne klonowanie katalogów, bezpieczne wykonanie w środowiskach nieinteraktywnych.

Case studies: jak ewolucja poprawia wykonanie

Analiza wiadomości Slack. Oryginalny agent: pobiera wszystkie wiadomości, przetwarza uniformicznie, trial-and-error przy błędach narzędzi (np. zły port API 9100 zamiast 9110). Ewolucja: skill koduje poprawny port, wprowadza skanowanie podglądów → selektywne pobieranie pełnych treści → ekstrakcja zadań. Trzy ulepszenia: dekompozycja zadania, proaktywna korekcja błędów, selektywny retrieval.

Analiza afiliacji artykułów ICCV 2025. Oryginalny agent: heurystyczne dopasowanie nazw uczelni - liczy pojawienia się nazwy, nie rozróżnia pierwszej afiliacji od kolejnych. Ewolucja: ścisła definicja “pierwszej afiliacji” z oficjalnej pierwszej strony PDF, wyrównanie z rekordami OpenAccess, targeted re-checks na niejednoznacznych przypadkach.

Inferencja SAM3 w niekompletnym środowisku. Oryginalny agent zakłada, że pliki i warunki (np. CUDA) są dostępne - zawodzi gdy ścieżki brakuje. Ewolucja: precheck środowiska, traktowanie brakującego katalogu output jako non-blocking, przeszukiwanie sąsiednich zasobów, adaptacja do ograniczeń systemu (monkey patch CUDA → CPU).

Dlaczego to działa - głębsza analiza

SkillClaw działa z trzech fundamentalnych powodów:

1. Naturalny eksperyment jako baza dowodowa. Wielu użytkowników wywołujących ten sam skill w różnych kontekstach tworzy quasi-kontrolowany eksperyment. Skill jest czynnikiem kontrolowanym; konteksty, zadania i użytkownicy to zmienne. To pozwala oddzielić uogólnialne ulepszenia od jednorazowych obejść - coś, co jest statystycznie niemożliwe z danych jednego użytkownika.

2. Monotoniczna polityka deployu. Nocna walidacja z regułą “accept only if better” zapewnia, że wdrożony skill pool nigdy nie degraduje. To kluczowe dla zaufania użytkowników - system może się poprawiać, ale nigdy pogarszać. Większość kandydackich skill’i jest odrzucana (z 6 kandydatów Social Interaction tylko 1 zaakceptowany), co pokazuje konserwatyzm systemu.

3. Ewolucja warstwowa odzwierciedla realne zależności. Search & Retrieval najpierw naprawia walidację plików (warstwa fundament), potem przechodzi do constraint-aware planning (warstwa nadbudowa). To nie jest sztuczne - wyższe reasoning faktycznie nie działa, gdy niższy input handling jest zawodny. System odkrywa tę hierarchię automatycznie.

Ale dlaczego deadline parsing poprawia się tylko o 6.9%? Bo ewolucja skill’i jest z natury proceduralna - optymalizuje sekwencje kroków, argumenty narzędzi, walidacje. Zadania wymagające głębszego rozumowania semantycznego (parsowanie dat, interpretacja kontekstu) nie dają się łatwo skodyfikować w proceduralnym skill’u. To fundamentalne ograniczenie podejścia opartego na skill’ach.

Ograniczenia

• Skala testów - 8 użytkowników, 6 dni, 1 benchmark, 1 model backbone (Qwen3-Max). Zachowanie w skali produkcyjnej (setki użytkowników, miesiące) pozostaje niezweryfikowane
• Koszt nocnej walidacji - podwójne wykonanie dla każdego kandydata zwiększa zużycie tokenów
• Brak analizy konwergencji - nie wiadomo, czy pętla ewolucji zbiega do optymalnego skill setu, czy wchodzi w cykle
• Prywatność - trajektorie użytkowników agregowane centralnie, co rodzi obawy o dane wrażliwe w enterprise
• Proceduralne ograniczenie - ewolucja najsłabsza dla zadań wymagających rozumowania, nie procedur
• Status: work in progress - brakuje wyników dla 2 z 6 kategorii benchmarku (Productivity Flow, Code Intelligence)

Podsumowanie

Co zapamiętać:

• SkillClaw zamienia statyczne biblioteki skills w dynamicznie ewoluujące ekosystemy napędzane interakcjami wielu użytkowników
• Kluczowy mechanizm: grupowanie sesji po skill’ach tworzy naturalną ablację, umożliwiając oddzielenie uogólnialnych ulepszeń od jednorazowych obejść
• Agentic evolver (agent LLM) zamiast sztywnych reguł - elastyczne, context-aware ulepszenia skill’i
• Nocna walidacja zapewnia monotoniczność - system nigdy nie deployuje pogorszonego skill’a
• Wyniki na WildClawBench: +11.72% do +88.41% relatywnej poprawy w 4 kategoriach, z 8 użytkownikami w 6 dni

Perspektywa: SkillClaw to koncepcyjnie elegancka propozycja, która przesuwa paradygmat z “agent uczy się sam” na “agenty uczą się kolektywnie”. Największym pytaniem pozostaje skalowanie - czy mechanizm utrzyma skuteczność z setkami użytkowników i tysiącami skill’i? I czy nocna walidacja nie stanie się wąskim gardłem? Na te pytania musimy poczekać na pełniejszą wersję pracy.

Źródła i materiały:

• 📄 Paper: SkillClaw: Let Skills Evolve Collectively with Agentic Evolver
• 💻 Projekt/Kod: GitHub - AMAP-ML/SkillClaw