SkillOpt: Jak wytrenować umiejętności agenta AI bez dotykania modelu

GPT-5.5 nie da się fine-tunować. Claude też nie. A mimo to oczekujemy, że te zamrożone modele obsłużą automatyzację arkuszy kalkulacyjnych, olimpiady matematyczne i wielokrokowe wyszukiwanie - wszystko na podstawie ręcznie napisanego system promptu. SkillOpt (arXiv 2605.23904, maj 2026) odwraca perspektywę: skoro nie możemy zmieniać wag modelu, to potraktujmy dokument skill - instrukcję proceduralną w języku naturalnym - jako jedyny trenowalny parametr i zoptymalizujmy go z pełną dyscypliną deep learningu. Efekt? Wygrana lub remis we wszystkich 52 ewaluowanych komórkach (model, benchmark, harness), zyski do +39 punktów na benchmarkach proceduralnych, a finałowy artefakt to plik Markdown o długości 300-2000 tokenów.

Problem: skill agentowy bez pętli treningowej

Czym jest skill agenta?

Skill to dokument w języku naturalnym - coś w rodzaju podręcznika proceduralnego - który mówi LLM-owi, jak podchodzić do konkretnej dziedziny. Mogą to być polityki użycia narzędzi (“zawsze waliduj formuły arkusza przed wysłaniem”), reguły formatu wyjścia (“zwracaj odpowiedzi jako JSON z polami X, Y, Z”) czy strategie rozumowania (“rozbijaj wielokrokową matematykę na podproblemy”). Skill trafia do system promptu albo jako plik SKILL.md do workspace’u agenta.

Siła skilli tkwi w ich przenośności: ten sam dokument działa z GPT-5.5, GPT-5.4-nano, Codex CLI i Claude Code. Bez retreningu. Bez adapterów. Tylko tekst.

Dlaczego ręczne i jednorazowe skille nie wystarczają

Trzy dominujące podejścia do tworzenia skilli mają fundamentalne wady:

• Skille pisane ręcznie wymagają eksperta, który przewidzi każdy tryb awarii. Są drogie, kruche i nigdy nie poprawiają się na podstawie feedbacku z wdrożenia.
• Jednorazowe generowanie przez LLM daje rozsądny punkt startowy, ale skill jest zamrożony od momentu generacji - nie uczy się z sukcesów i porażek agenta.
• Luźno kontrolowana samorefleksja (TextGrad, GEPA, EvoSkill) pozwala agentowi edytować własny skill po obserwacji błędów. Ale bez zabezpieczeń te metody mogą wymazywać użyteczne reguły, overfitować do pojedynczych przykładów albo oscylować między sprzecznymi edycjami.

Centralna teza SkillOpt: dokument skill to zewnętrzny stan agenta - bezpośredni analog wag modelu w deep learningu. Jeśli zastosujemy tę samą inżynierską dyscyplinę do edycji tekstu (ograniczone kroki, walidacja na held-out, pamięć negatywna, konsolidacja między epokami), otrzymamy odtwarzalne, monotoniczne poprawy bez modyfikowania modelu.

Analogia, która wyjaśnia wszystko

Wyobraźmy sobie, że zatrudniliśmy konsultanta do napisania podręcznika procedur dla zespołu obsługi klienta. Zamiast wręczać gotowy podręcznik pierwszego dnia, pozwalamy zespołowi obsługiwać zgłoszenia, obserwujemy co idzie źle i iteracyjnie poprawiamy po kilka paragrafów naraz - ale zachowujemy poprawkę tylko wtedy, gdy niezależny recenzent potwierdzi, że faktycznie pomaga. Podręcznik nie puchnie niekontrolowanie, bo każda rewizja jest ograniczona w zakresie zmian, a każda odrzucona rewizja jest zapamiętywana, żeby konsultant nie próbował tego samego dwa razy.

To jest SkillOpt. “Podręcznik” to dokument skill. “Zespół” to zamrożony LLM. “Konsultant” to osobny model optymalizujący. “Niezależny recenzent” to held-out validation split.

Pętla optymalizacji SkillOpt

Cały pipeline składa się z czterech powtarzających się faz na krok, opakowanych w epoki:

1. Forward pass - uruchom zamrożony model na batchu zadań z aktualnym skillem; zbierz trajektorie i wyniki
2. Backward pass - podziel wyniki na sukcesy i porażki; wygeneruj strukturalne edycje add/delete/replace przez minibatch reflection
3. Ograniczona aktualizacja tekstu - zastosuj co najwyżej $L_t$ edycji (“tekstowy learning rate”)
4. Bramka walidacyjna - zaakceptuj kandydata tylko jeśli ściśle poprawia wynik na held-out selection split; w przeciwnym razie odrzuć i zapamiętaj porażkę

Na końcu każdej epoki - slow/meta update: porównanie aktualnego skilla z poprzednią epoką na tych samych zadaniach i ekstrakcja trwałych lekcji.

Forward pass: zbieranie dowodów z rolloutów

Formalnie model wykonawczy wygląda tak:

$$(\tau(s), r(s)) = h(M, x, s), \quad r(s) \in [0, 1] \tag{1}$$

gdzie:

• $h$ - harness wykonawczy (direct chat, Codex CLI lub Claude Code CLI)
• $M$ - zamrożony model docelowy
• $x$ - zadanie ze splitu treningowego
• $s$ - aktualny dokument skill (string w języku naturalnym)
• $\tau(s)$ - pełna trajektoria: wiadomości, wywołania narzędzi, obserwacje, finalna odpowiedź
• $r(s)$ - skalarny wynik za trajektorię, znormalizowany do $[0,1]$

Interpretacja: To jest forward pass. Harness uruchamia zamrożony model na zadaniu uwarunkowanym na skillu, produkując obserwowalną trajektorię i numeryczny wynik. Skill $s$ to jedyna zmienna, którą możemy modyfikować - reszta (model, harness, scorer) jest zamrożona.

Domyślna konfiguracja: $B = 40$ zadań na batch - wystarczająco, żeby odróżnić systemowe słabości skilla od losowego szumu.

Backward pass: refleksja w minibatchach

Po forward passie trajektorie są dzielone na sukcesy i porażki. Każda grupa jest dzielona na minibatche refleksyjne o rozmiarze $B_m = 8$. Osobny model optymalizujący - typowo frontier LLM jak GPT-5.5 - analizuje każdy minibatch i proponuje strukturalne edycje.

Dlaczego osobny model? Z tego samego powodu, dla którego trener nie musi sam grać w meczu. Silniejszy optymalizator diagnozuje wzorce porażek rzetelniej niż model docelowy. Co więcej, umożliwia to schemat nauczyciel-uczeń: GPT-5.5 optymalizuje skille dla GPT-5.4-nano bez dotykania wag studenta. Nawet optymalizator target-matched (ten sam model w obu rolach) odzyskuje 56-74% zysku frontier-optymalizatora.

Minibatche porażkowe proponują reguły korekcyjne i brakujące. Minibatche sukcesu chronią zachowania, które już działają. Oba produkują propozycje edycji add/delete/replace trafiające do kroku mergowania.

Tekstowy learning rate: ograniczony budżet edycji

Tu SkillOpt najsilniej odbiega od wcześniejszych metod optymalizacji promptów. Zamiast pozwalać optymalizatorowi pisać skill od nowa, każda aktualizacja jest ograniczona:

$$s_{t+1} = \text{Modifier}(s_t,; \text{TopK}_{L_t}(\mathcal{E}_t)), \quad L_t \in {\text{constant},; \text{cosine},; \text{linear},; \text{autonomous}} \tag{2}$$

gdzie:

• $s_t$ - skill w kroku $t$
• $\mathcal{E}_t$ - pula zmergowanych edycji add/delete/replace zaproponowanych przez optymalizator
• $L_t$ - budżet edycji (tekstowy learning rate) w kroku $t$: maksymalna liczba zastosowanych edycji
• $\text{TopK}_{L_t}$ - operator zachowujący tylko top-$L_t$ edycji uszeregowanych po oczekiwanej użyteczności
• $\text{Modifier}$ - aplikuje wybrane edycje, produkując kandydacki skill

Interpretacja: Ograniczając każdą aktualizację do co najwyżej $L_t$ atomowych edycji, SkillOpt zapewnia, że kolejne wersje skilla pozostają wystarczająco blisko siebie, by optymalizator mógł uczyć się z historii akceptacji i odrzuceń. To identyczny mechanizm jak mały learning rate utrzymujący bliskie wektory wag w gradient descent.

Domyślny harmonogram to cosine decay od $L_t = 4$ (podłoga = 2). Wczesne epoki dokonują większych zmian strukturalnych - ustalają procedury, formaty wyjścia, polityki narzędzi. Późniejsze epoki dopracowują detale. Ablacje pokazują, że umiarkowane budżety ($L_t \in [1, 16]$) działają porównywalnie; kluczowe odkrycie to fakt, że usunięcie budżetu obniża wyniki o nawet 4 punkty.

Bramka walidacyjna: empiryczne filtrowanie zamiast uznaniowości

To prawdopodobnie najważniejsza decyzja projektowa. Po każdej ograniczonej aktualizacji kandydacki skill jest ewaluowany na held-out selection (walidacyjnym) splicie:

$$s^\star_{\text{sel}} = \arg\max_{s \in \mathcal{C}(D_{\text{tr}})} \frac{1}{|D_{\text{sel}}|} \sum_{x \in D_{\text{sel}}} r(s) \tag{3}$$

gdzie:

• $\mathcal{C}(D_{\text{tr}})$ - zbiór kandydackich skilli wygenerowanych przez optymalizator na splicie treningowym
• $D_{\text{sel}}$ - held-out selection split, używany wyłącznie do decyzji accept/reject
• $s^\star_{\text{sel}}$ - najlepszy skill wybrany przez bramkę spośród wszystkich kandydatów
• $r(s)$ - wynik per-task jak w Równaniu 1

Interpretacja: Kandydacki skill trafia do best_skill.md tylko gdy jego średni wynik na selection splicie ściśle przekracza aktualny najlepszy. Remisy są odrzucane. Przekształca to refleksję w optymalizację propose-and-test: przekonująco brzmiące diagnozy tekstowe, które faktycznie nie pomagają modelowi docelowemu, są odfiltrowane empirycznie.

Dlaczego ścisła bramka? Bo LLM-y doskonale generują przekonujące wyjaśnienia porażek i pozornie rozsądne poprawki - ale te poprawki często nie pomagają (albo aktywnie szkodzą). Bez bramki walidacyjnej SkillOpt degeneruje do tej samej bezwarunkowej samoedycji, która jest problemem TextGrad.

Bufor odrzuconych edycji: nauka z porażek

Gdy kandydat nie przejdzie bramki walidacyjnej, nie znika. Odrzucona edycja i powiązany spadek wyniku trafiają do bufora odrzuconych edycji lokalnego dla epoki. Bufor jest przekazywany przyszłym wywołaniom optymalizatora w tej samej epoce.

Można o nim myśleć jako o liście “nie próbuj tego ponownie”. Bez niego optymalizator mógłby niezależnie zaproponować tę samą atrakcyjną-ale-szkodliwą edycję trzy razy w jednej epoce. Usunięcie bufora obniża SearchQA o -1.6, SpreadsheetBench o -4.6 i LiveMath o -2.4 punkta.

Bufor jest resetowany na granicach epok - zapobiega to sytuacji, w której przestarzały negatywny feedback blokuje edycje, które mogłyby zadziałać w nowym kontekście skilla.

Slow/meta update: konsolidacja międzyepokowa

Na końcu każdej epoki SkillOpt wykonuje slow update - tekstowy analog momentum update w optymalizacji wag.

Procedura:

1. Uruchom skill z poprzedniej epoki i skill z bieżącej epoki na tych samych 20 zadaniach
2. Pogrupuj wyniki: poprawy, regresje, trwałe porażki, stabilne sukcesy
3. Zapisz zwięzły blok longitudinalnych wskazówek do chronionego pola slow-update - sekcji skilla, której edycje krokowe nie mogą nadpisać
4. Zaktualizuj meta skill po stronie optymalizatora (tylko dla nauczyciela, nigdy nie jest wysyłany z finalnym artefaktem)

Dlaczego chronić pole slow-update? Szybkie lokalne aktualizacje reagują na dowody z poziomu batcha - “ta formuła w arkuszu zawiodła, dodaj krok walidacji.” Ale trwałe lekcje domenowe - “zawsze sprawdzaj scalone komórki przed parsowaniem” - nie powinny być nadpisywane przez sprzeczny sygnał z jednego batcha. Chronione pole zapewnia, że mądrość długoterminowa przetrwa krótkookresowy szum.

To komponent o największym wpływie. Usunięcie meta skilla i slow update obniża SpreadsheetBench o druzgocące -22.5 punkta (77.5 do 55.0). Żadna inna ablacja nie zbliża się do tego.

Finalny artefakt: po prostu plik tekstowy

Po 4 epokach (domyślnie) SkillOpt eksportuje best_skill.md - kompaktowy plik o długości 300-2000 tokenów. Żadnych checkpointów modelu, wag adapterów, grafów ONNX. Plik Markdown, który trafia do system promptu.

Finalna ewaluacja testowa:

$$\text{Test}(s^\star_{\text{sel}}) = \frac{1}{|D_{\text{test}}|} \sum_{x \in D_{\text{test}}} r(s^\star_{\text{sel}}) \tag{4}$$

gdzie:

• $D_{\text{test}}$ - held-out test split, zablokowany do finalnego raportowania
• $s^\star_{\text{sel}}$ - skill wybrany przez bramkę walidacyjną, nigdy retrenowany na $D_{\text{test}}$

Interpretacja: Standardowy protokół train/val/test zastosowany do optymalizacji w przestrzeni tekstu. Podział danych to 4:1:5 (train:selection:test) - połowa danych zarezerwowana na testowanie. Niezwykle konserwatywne, co czyni raportowane zyski bardziej wiarygodnymi.

Eksperymenty i wyniki: 52/52 komórek wygranych

Direct chat: do +39 punktów na benchmarkach proceduralnych

Zyski na SpreadsheetBench (+38.9) i OfficeQA (+39.0) są oszałamiające. To benchmarki proceduralne - zadania wymagające spójnych polityk narzędziowych, formatowania wyjścia i wielokrokowych strategii rozumowania. Dokładnie tego rodzaju wiedza, którą zoptymalizowany skill koduje.

Harnessy agentowe: Codex i Claude Code

Zyski w harnessach agentowych są jeszcze większe. Dlaczego? Bo środowiska wykonawcze wzmacniają zarówno dobre, jak i złe nawyki. Model bez skilla dokonuje niespójnych wyborów narzędzi, które kumulują się w wielokrokowych workflow’ach. Zoptymalizowany skill wymusza spójne procedury od pierwszego kroku.

Czy zoptymalizowane skille się przenoszą?

Jedno z najbardziej zaskakujących odkryć: best_skill.md transferuje - do innych modeli, harnessów, a nawet benchmarków.

Transfer między harnessami

Skill zoptymalizowany dla Codex CLI, wrzucony do Claude Code bez żadnej modyfikacji, osiąga 81.8 na SpreadsheetBench - faktycznie wyżej niż in-domain Claude Code SkillOpt (80.4). To +59.7 punkta zysku vs baseline Claude Code bez skilla. Dokument skill koduje wiedzę domenową niezależną od harnessu.

Transfer między modelami

Skille zoptymalizowane na GPT-5.5 transferują pozytywnie na mniejsze GPT bez reoptymalizacji. Zyski maleją z dystansem skali, ale pozostają dodatnie.

Transfer między benchmarkami

Skille matematyczne z OlympiadBench dają pozytywne zyski (+1.3 do +3.7 punkta) na Omni-MATH na trzech skalach modeli. Transfer jest skromny, ale konsekwentnie pozytywny.

Ablacje: co naprawdę napędza zyski?

Budżet edycji jest ważny; konkretny harmonogram nie

Umiarkowane budżety ($L_t \in [1, 16]$) działają porównywalnie. Constant, cosine i linear mieszczą się w 3 punktach. Ale usunięcie budżetu powoduje mierzalne spadki: -4.0 na LiveMath, -1.8 na SpreadsheetBench.

Slow/meta update to najważniejszy komponent

Kolaps o -22.5 punkta na SpreadsheetBench bez obu komponentów potwierdza, że benchmarki proceduralne wymagają konsolidacji długoterminowej. Szybkie lokalne edycje same nie wystarczą.

Skalowanie danych treningowych

SpreadsheetBench rośnie z 47.5 (1 przykład) do 78.0 (pełny set treningowy). SearchQA saturuje koło 84-86 po zaledwie 20% danych. Benchmarki proceduralne są głodne danych, bo wymagają różnorodnych trybów awarii do budowy kompleksowych reguł.

Koszt i interpretowalność

Pętla optymalizacji nie jest tania: od 0.6M do 46.4M tokenów na benchmark. Ale to jednorazowy koszt offline - wyeksportowany best_skill.md dodaje zero narzutu inferencyjnego poza 300-2000 tokenami kontekstu.

Za to historia interpretowalności jest przekonująca. Każda edycja skilla to patch w języku naturalnym: “dodaj regułę: waliduj referencje komórek przed ewaluacją formuły.” Każda odrzucona edycja jest zalogowana z jej wpływem na wynik. Każda konsolidacja slow-update to czytelny paragraf. Spróbujcie tego z fine-tunowanym adapterem LoRA.

Ograniczenia

• Koszt optymalizacji. Trening wymaga wielu rollout batchów (domyślnie $B = 40$ na krok, 4 epoki), co konsumuje znaczny budżet API.
• Jeden skill na domenę. SkillOpt bada jeden kompaktowy skill per (domena, model, harness). Biblioteki wielu skilli z selektywnym routingiem pozostają niebadane.
• Ograniczony transfer między benchmarkami. Zyski +1.3 do +3.7 sugerują, że transfer działa najlepiej w wąskich rodzinach zadań.
• Zależność od optymalizatora. Najsilniejsze wyniki używają GPT-5.5 jako optymalizatora. Optymalizacja target-matched odzyskuje 56-74% zysku, ale luka jest realna.
• Narzut slow/meta update. Powtórne uruchomienie 20 zadań na epokę dodaje koszt proporcjonalny do czasu wykonania zadania.

Podsumowanie

1. Dokumenty skill to trenowalne parametry. SkillOpt pokazuje, że skille w języku naturalnym można optymalizować z tą samą rygorem co wagi sieci neuronowej - ograniczone aktualizacje, bramkowanie walidacyjne, pamięć negatywna, konsolidacja momentowa - produkując kompaktowe artefakty poprawiające zamrożone modele o nawet +39 punktów.

2. Bramka walidacyjna jest niezbywalna. Przekonująco brzmiące samoedycje LLM-ów często szkodzą. Ścisła walidacja na held-out zamienia refleksję z pobożnych życzeń w empiryczną optymalizację.

3. Konsolidacja długoterminowa napędza największe zyski. Slow/meta update - porównywanie skilli między epokami i zapisywanie chronionych lekcji domenowych - jest wart do 22.5 punkta na benchmarkach proceduralnych.

4. Artefakt to po prostu tekst. Finalny wynik to plik Markdown o 300-2000 tokenach, który transferuje między skalami modeli, harnessami i powiązanymi benchmarkami. Bez chirurgii modelowej, bez adapterów, bez retreningu.

5. 52/52 trudno podważyć. SkillOpt wygrywa lub remisuje w każdej ewaluowanej kombinacji (model, benchmark, harness). Średni zysk +23.5 na GPT-5.5 direct chat, +24.8 na Codex, +19.1 na Claude Code sugeruje, że principialna optymalizacja w przestrzeni tekstu to autentycznie ogólna zdolność.

Źródła i materiały:

📄 SkillOpt: Executive Strategy for Self-Evolving Agent Skills - arXiv 2605.23904