Agenty doskonalące się poprzez umiejętności: ponowne wykorzystanie, selekcja, naprawa i weryfikacja.

Agen kodujący, który dwukrotnie napotyka ten sam problem, zazwyczaj nie ma trwałego miejsca na przechowywanie tego, czego się nauczył. Ideą pluginu o nazwie Whetstone jest to, aby praca wykonywana dziś ułatwiała pracę jutro. Narzędzie pomocnicze napisane i przetestowane przez agenta powinno być dostępne przy następnej okazji. Proces pracy wymagający korekty powinien prowadzić do trwałej zmiany, którą ktoś może przejrzeć. A zanim wynik zostanie przekazany, sprawdzenia niezbędne do potwierdzenia prawidłowości zadania powinny już zostać przeprowadzone.

To są zwykłe praktyki inżynierskie, jednak zwykle pozostają jedynie w umyśle osoby i są powtarzane na końcu każdej sesji. Whetstone pakuje je w cztery umiejętności, które wspierają pozostałe: ponowne wykorzystanie sprawdzonego kodu, ulepszenie sposobu wyboru umiejętności, dokumentowanie wniosków z procesów oraz weryfikacja wyników przed przekazaniem ich użytkownikowi.

Określenie to odnosi się do „agentów samodoskonalących się” w celowo umiarkowanym sensie. Agent pomaga ulepszać własne instrukcje i narzędzia, człowiek sprawdza te zmiany i decyduje, co zostanie utrzymane na stałe; sam model nie jest ponownie szkoleny, a nic nie działa w tle bez nadzoru w celu samodzielnego uczenia się.

Pierwotna weryfikacja 383 plików z umiejętnościami dała temu pluginowi konkretny teren do testowania. Jednak najważniejszą częścią jest projekt: gdzie powinny znajdować się elementy wielokrotnego użytku, jak wybrać odpowiednią interwencję oraz jakie dowody należy zażądać przed zatwierdzeniem zmiany. Ten sposób myślenia jest przydatny zarówno z pluginem, jak i z wersją stworzoną według własnych procedur pracy.

Część agenta, którą faktycznie można ulepszyć

Umiejętność to folder. Zawiera on plik SKILL.md z instrukcjami, a opcjonalnie także skrypty i dokumenty referencyjne. Oficjalna specyfikacja Agent Skills określa standardową strukturę tego pliku – na początku znajduje się krótkie nazwanie i opis. Zespół inżynieryjny Anthropic opisuje umiejętności jako sposób na zapewnienie agentom uniwersalnym możliwości wykorzystania powtarzalnych kompetencji, a zaletą jest to, że można ulepszyć procedurę bez konieczności przepisywania całego oprogramowania.

W tym procesie biorą udział dwa oddzielne elementy: agent musi wybrać odpowiednią umiejętność, a ta z kolei musi skutecznie kierować jego działaniami. Poprawa jednego elementu nie automatycznie poprawia drugiego.

Whetstone przypisuje każdej ze swoich czterech umiejętności jedną konkretną rolę:

• dry-promotion służy do przechowywania kodu nadającego się do ponownego użycia.
• skill-audit sprawdza informacje wykorzystywane do wyboru umiejętności.

skill-repair proponuje zmiany proceduralne.

verify-before-return sprawdza wynik.

To, co sprawia, że taka struktura funkcjonuje, polega na tym, że każda operacja zmienia coś innego. Pomocnik może zasługiwać na zapisanie, mimo że nic się nie nie udało. Niejasny opis może wymagać uwagi, podczas gdy procedura w tle działa perfekcyjnie. Przesyłanie każdej prośby przez wszystkie cztery operacje łączyłoby ze sobą niespowiązane zadania, natomiast oddzielne punkty wejścia pozwalają wywołać tylko tę część, która jest potrzebna do wykonania zadania.

Każda operacja kończy się czymś, co można zobaczyć: plikiem na dysku, raportem audytowym, zalecanym porównaniem lub dowodem weryfikacji. To ułatwia debugowanie i daje osoby sprawdzającej konkretny element do zatwierdzenia. Pomoc agenta jest mile widziana, ale sama przekonująca wyjaśnienie nigdy nie czyni zmiany trwałą.

1. DRY: zachowaj to, co już zadziałało

DRY oznacza „nie powtarzaj się” oraz odnosi się do agenta, który zawiera wcześniej stworzony kod funkcyjny. Gdy każda prośba o prezentację zmusza do ponownego zbudowania renderera, musi on najpierw rozwiązać stary problem inżynieryjny, zanim przejdzie do nowej treści.

Renderer to urządzenie wielokrotnego użycia, a treść jest tym, co się zmienia. Dokumentacja Anthropic ilustruje ten pomysł przykładem umiejętności w formacie PDF, która uruchamia wcześniej napisany skrypt do wydobywania danych: kod zajmuje się stabilną, mechaniczną częścią zadania, podczas gdy model podejmuje decyzje specyficzne dla danego zadań.

To właśnie jest zadaniem dry-promotion. Kopia on pomocniczego pliku do foldera scripts/ umiejętności i przepisuje instrukcje tak, aby skrypt mógł zostać wykonywany. Samo zapisanie pliku nie wystarcza – chociaż umiejętność nadal poleca agentowi napisanie skryptu, nic nie wskazuje mu na ten zapisany plik.

Licznik znaków to dobry przykład z procesu pisania. Napis ma określony limit długości, a niewielki program może obliczyć tę liczbę, podczas gdy model skupia się na sformułowaniu tekstu. Takie narzędzie może zawierać instrukcje w następującym stylu:

Zanim zwrócisz napis, uruchom zapisany licznik znaków. Jeśli wynik przekroczy limit, skróć tekst i policz ponownie. Nigdy nie zgaduj liczby i nigdy nie twórz licznika od nowa.

Dzięki temu uzyskujemy stabilną implementację, którą można sprawdzić i przetestować. Nie czyni to całego procesu deterministycznym, ponieważ sam napis może nadal się różnić, a program może wiernie powtarzać błędną definicję. Licznik musi ustalić, czy ma liczyć punkty kody Unicode, czy widoczne znaki, oraz jak ma traktować spacje i przecinki.

Przed promowaniem pomocnika przygotuj go tak: usuń ścieżki powiązane z jedną sesją, ujawnij dane wejściowe i przetestuj go w przypadkach innych niż ten, który go inspirował. Następnie uruchom proces ponownie i sprawdź, czy zapisany plik to właśnie to, do czego ma służyć. Uruchomienie, które potajemnie tworzy kolejny licznik, unieważnia sens ponownego użycia, nawet jeśli ostateczne liczby się zgadzają.

To samo zasada dotyczy szablonów i wspólnych odniesień. Gdy kilka umiejętności dzieli ten sam kontrakt wyjściowy, zachowaj jedną autorytatywną kopię, a pozostałe niech do niej odwołują się. Nie próbuj wymusić dwóch zupełnie różnych procesów za pomocą jednego pomocnika tylko dlatego, że ich pierwsze przykłady wyglądają podobnie. Ponowne użycie powinno zapewniać stabilną pracę i nie powinno ukrywać istotnych różnic.

2. Pomóż agentowi wybrać odpowiednią umiejętność

Dzięki stopniowej prezentacji agent zaczyna od lżejszych metadanych i ładuje pełne instrukcje umiejętności dopiero w momencie jej wyboru. Praktycznym powodem jest to, że wcześniejsze ładowanie wszystkich procedur marnuje zasoby na zadania, które mogą nigdy nie zostać zlecone.

W przypadku automatycznego wyboru nazwa i opis pełnią rolę informacji przekierowujących. Starannie napisane wyjaśnienie umieszczone w środku pliku może nawet nie być dostępne, gdy model decyduje o jego otwarciu.

Opisy nie są jedynym sposobem wyboru. Claude Code obsługuje również wyraźne wywołanie, a konfiguracja w czasie wykonywania wpływa na to, co jest dostępne. Mimo to opis stanowi sygnał wyboru, którym kontroluje autor umiejętności.

Przegląd biblioteki umiejętności jednej osoby, z oddzielnym liczeniem duplikatów o tej samej nazwie pomijając kolizje, dał następujący podsumowanie:

383 skills scanned
  missing description           0
  no trigger language         306
  colliding pairs               3
  duplicate names              23
  skills with >=1 defect      306  (79%)

79% to skrócona wartość uzyskana przez podzielenie 306 przez 383, co daje około 79,9%. Te opisy nie przeszły sprawdzenia sformułowań, co nie jest tożsame z 306 zaobserwowanymi przypadkami niewykorzystania umiejętności. Skaner sprawdza jedynie dosłowne sformułowania wyzwalające, takie jak „użyj, gdy” lub „gdy użytkownik”. Model może postępować zgodnie z opisem bez tych słów, a opis zawierający je może nadal być zbyt ogólny, by pomóc. Wynik to lista do zbadania, a nie miara tego, na jak bardzo uszkodzony jest agent.

Przypisz sąsiednim umiejętnościom różne zadania

Rozważmy dwa rzeczywiste opisy dwóch umiejętności w tym samym pluginie:

Jeden z nich przedstawia się jako ekspert od budowy systemów generatywnych wzbogaconych o wyszukiwanie przy użyciu baz danych wektorowych, embeddingów oraz zaawansowanych strategii wyszukiwania. Drugi przedstawia się jako ekspert od wyboru, konfiguracji i optymalizacji baz danych wektorowych takich jak Pinecone, Weaviate, Chroma, Qdrant i Milvus do zastosowań w wyszukiwaniu semantycznym i RAG.

Oba teksty są dobrze napisane, więc który z nich będzie lepszy dla użytkownika potrzebującego pomocy w doborze bazy danych wektorowych do aplikacji RAG? Skuteczny model może faworyzować drugi, bardziej specjalistyczny w tym zakresie, jednak pierwszy nadal rości sobie prawa do tej samej dziedziny. Nie jest jasne, jakie umiejętności posiada każdy z nich, więc model musi sam ustalić granice.

Przepisywanie tekstów w taki sposób pozwoliłoby wyraźniej rozdzielić te dwa podejścia. Nie przeprowadzono na ich temat żadnych testów porównawczych:

name: vector-database-selection
description: >-
  Compare vector databases against workload, filtering,
  deployment, and operating-cost requirements. Use when
  choosing or replacing a vector store. For retrieval-pipeline
  design with an already chosen store, use rag-pipeline-design.

name: rag-pipeline-design
description: >-
  Design ingestion, chunking, retrieval, reranking, and
  evaluation for a RAG application. Use when building or
  diagnosing a retrieval pipeline. For a standalone vector
  database selection, use vector-database-selection.

Pierwsza osoba odpowiada za wybór bazy danych, a druga za znalezienie drogi od dokumentów do przydatnego kontekstu potrzebnego do udzielenia odpowiedzi. Część słownictwa pozostaje wspólna, ponieważ prace te rzeczywiście się pokrywają.

Napisz szkic zapytań testowych, zanim zmienisz jakiekolwiek sformułowania. „Porównaj magazyny wektorowe dla aplikacji do wyszukiwania dokumentów uruchamianej lokalnie” powinno dotyczyć wyboru bazy danych. „Gdzie powinny znajdować się nasze embeddingi? Pomóż mi zdecydować” oznacza to samo, tylko innymi słowami. „Mamy już magazyn wektorowy, ale wyszukiwanie pomija istotne akapity” należy do diagnostyki procesu.

Następnie dodaj zapytanie, którego żadna z umiejętności nie powinna obsługiwać, na przykład poprawę odstępów w przycisku wyszukiwania na urządzeniach mobilnych. Bez tego sprawdzisz tylko, która z dwóch umiejętności jest lepsza, a nie to, czy agent może odrzucić obie.

Próbuj ich w nowych sesjach z identycznym modelem, włączonymi umiejętnościami i kontekstem projektu. Nie uwzględniaj nazwy zamierzonej umiejętności w żadnym teście automatycznego wyboru, ponieważ jej podanie zmienia eksperyment. Tam, gdzie czas wykonywania go ujawnia to informację, zapisz, która umiejętność została załadowana, oraz zachowaj uzyskaną odpowiedź lub wynik. Zapis pliku, który został otwarty, jest lepszym dowodem niż twierdzenie agenta, że użył właściwej umiejętności.

Porównaj wyniki przed i po, a także wyłącz niektóre parafrazy z sesji przepisywania, aby nie dostosowywać się wyłącznie do własnych przykładów. Ten mały zestaw testów regresji pokazuje, czy zmiana przyniosła korzyść w przypadku istotnych zapytań.

3. Przekształcenie doświadczenia w wielokrotnie używalne instrukcje

Wykrycie problemu rodzi bardziej użyteczne pytanie: gdzie powinna znajdować się korekta?

skill-repair zapisuje swoje propozycje w formie różnic do zatwierdzenia przez użytkownika, w odniesieniu do wersji kontrolowanej. Celem jest jak najmniejsza modyfikacja, która naprawi zaobserwowany błąd, aby osoba sprawdzająca mogła ją przeczytać i cofnąć, jeśli coś innego zostanie uszkodzone.

Załóżmy umiejętność pisania raportów, która zwraca streszczenie bez konsultacji z oryginalnym dokumentem. Prośba o „większą ostrożność” daje temu systemowi bardzo mało informacji do działania. To, co to naprawi, zależy od tego, dlaczego sprawdzenie zostało pominęte:

• Procedura nigdy nie wymagała źródła: należy zmienić procedurę.
• Źródło jest wymagane, ale nie podano jego lokalizacji: należy dostarczyć ten kontekst lub poprosić o brakujące dane.
• Źródło zostało przeczytane, ale tabela została błędnie skopiowana: potrzebne jest inne sprawdzenie.

Jedno ogólne ostrzeżenie umieszczone we wszystkich przypadkach całkowicie pominęłoby proces diagnozy.

Zachowaj nieudaną prośbę wraz z proponowaną modyfikacją, opisz oczekiwane zachowanie i zachowaj plik, który ujawnił błąd. Uruchom ponownie prośbę w nowej sesji, a następnie spróbuj innej prośby, która powinna nadal działać. W przeciwnym razie łatwo jest zatwierdzić zmianę, ponieważ jest ona przekonująca, co stanowi wygodny sposób na spędzenie popołudnia bez żadnych ulepszeń.

Ważny jest również zakres. Preferencje dotyczące jednego raportu pozostają przy tym raporcie. Zasady dla każdego raportu, który tworzy umiejętność, trafiają do tej umiejętności. Fakty, które często się zmieniają, mogą lepiej pasować do referencji, do której odwołuje się umiejętność. Jeśli każda korekta trafia do stałych instrukcji, procedura wielokrotnego użycia stopniowo staje się zapisem ostatniej sesji jednej osoby.

Uspiechy zasługują na takie samo wsparcie. Gdy sekwencja działa niezawodnie, należy zachować przydatny porządek, dane wejściowe i przykłady, a nie tylko ostrzeżenia o błędach. Wytyczne dotyczące tworzenia umiejętności Agent Skills zalecają opieranie ich na rzeczywistej pracy oraz doskonalenie poprzez ich wykonywanie. Umiejętność powinna zawierać wiedzę, której brakuje przy kolejnym uruchomieniu, a nie transkrypcję wszystkiego, co się wydarzyło.

Gdy wspólny przewodnik wymaga naprawy

Biblioteka jednej osoby to jej własny zbiór nieuporządkowanych materiałów, sprawdzany przez jej własne narzędzie, dlatego to samo sprawdzenie zostało zastosowane do publicznego repozytorium pluginów prowadzonego przez zespół zajmujący się oprogramowaniem badawczym na uczelni. W tym zrzutku znajdowało się 76 umiejętności w 12 pluginach.

Flagi zostały pogrupowane według pluginów. Siedem pluginów otrzymało flagi we wszystkich kategoriach, a jeden plugin naukowy w Pythonie miał flagi we czterech z pięciu kategorii. To zagrupowanie skłoniło do poszukiwania wspólnych szablonów i konwencji, a okazało się, że przewodnik dla autorów jest źródłem tych standardów. Wymagał on „jasnego opisu agenta i jego przeznaczenia” oraz dostarczył szablon wzorcowy, który określał, co agent robi. Nigdzie nie wspomniano o tym, kiedy należy go używać. Trzydzieści sześć elementów zostało stworzonych zgodnie z tym przewodnikiem, ale sam przewodnik stanowił błąd.

Doniesiono o otwarciu dwóch publicznych problemów – jednego dotyczącego przewodnika, a drugiego dotyczącego 36 opisów, przy czym kolejność ma znaczenie. Należy najpierw zaktualizować konwencje i pokazać dobry przykład, a dopiero potem dostosować istniejące opisy. W przeciwnym razie kolejny autor będzie postępował idealnie zgodnie z przewodnikiem i ponownie wprowadzi ten sam wzorzec.

Sprawdzenie typu CI może pomóc, ale należy je uruchomić w trybie doradczym. Jeśli reguła zna tylko kilka fraz wyzwalających, ustawienie błędu na poziomie „ciężkiego” skłania twórców do wklejania tych fraz, aż budowa się uda, co zwiększa liczbę prób bez poprawy umiejętności. Prawdziwy test akceptacji nadal wymaga reprezentatywnych zapytań, w tym takich, które umiejętność powinna zignorować.

4. Weryfikacja przed przekazaniem

verify-before-return wyposaża umiejętność w kryteria akceptacji oraz pętlę przeglądania. Zapisanie pliku na dysku to tylko etap pośredni, a proces musi nadal sprawdzić wynik przy użyciu dowodów odpowiednich do zadania:

• W przypadku prezentacji konieczne jest jej wyrenderowanie, a następnie sprawdzenie, czy nie ma obciętego tekstu, nieczytelnych etykiet lub elementów poza obszarem wyświetlania.
• W przypadku raportu badawczego należy otworzyć źródła i sprawdzić, czy potwierdzają one przedstawione twierdzenia.
• W przypadku kodu należy uruchomić testy, które sprawdzają wymagane zachowanie.

Każde twierdzenie o ukończeniu pracy powinno wskazywać, co dokładnie zostało sprawdzone.

Zdefiniuj te kryteria przed rozpoczęciem pracy. Następnie niech specjalista przygotuje pierwszą wersję, sprawdzi ją, naprawi błędy i ponownie przeprowadzi sprawdzenia dotknięte tymi poprawkami. Ogranicz cykl modyfikacji i wymagaj ujawnienia wszystkiego, co nadal pozostaje nierozwiązane, ponieważ „ciągłe doskonalenie” może inaczej przerodzić się w niekończące się edytowanie bez wyraźniejszego rezultatu.

Praca subiektywna wymaga innego rodzaju oceny. Symulowany początkujący może zaznaczyć niewyjaśnione terminy, a sceptyczny czytelnik może zakwestionować argumentację. Obie formy są przydatne, ale obie stanowią krytykę wygenerowaną przez model, a nie opinie rzeczywistych odbiorców, dlatego oceniaj każdą sugestię w kontekście celu dzieła, zamiast przyjmować każdą zastrzeżenie. Ocenę gustu i strategii pozostawia się osobie, która zleciła pracę.

Przeprowadzenie sprawdzenia to nie to samo, co przeprowadzenie właściwego sprawdzenia, a własne testy audytora pokazują dlaczego.

Jakie testy zmienił audytor

Testy wykazały, że audytor musiał traktować duplikatowe instalacje oraz nakładające się opisy jako odrębne ustalenia. Pierwsze przeprowadzone testy wykazały 81 par kandydatów, z których wiele stanowiły identyczne umiejętności znajdujące się w różnych wersjach pluginów w pamięci podręcznej. Analiza tych par doprowadziła do wyodrębnienia duplikatów o tym samym nazwie z analizy kolizji, co zmniejszyło liczbę kandydatów do 3.

Dlatego zapisy stanowiące podstawę podsumowania wymagają weryfikacji przed wprowadzeniem jakichkolwiek zmian. Pliki duplikatowe wymagają sprawdzenia stanu magazynowego, natomiast sprzeczne opisy wymagają testu kierowania. Ich łączenie prowadzi do błędnego wyboru sposobu naprawy.

Wyodrębnienie duplikatów nazw ujawniło również 23 nazwy obecne w więcej niż jednej skanowanej ścieżce. Zapisane kopie nie dowodzą, że stare wersje były aktywne, co wymaga sprawdzenia włączonych w czasie działania pluginów oraz rozwiązanych ścieżek. Podobnie, 383 to liczba skanowanych plików, a nie aktywnych, unikalnych umiejętności, a wykluczenie porównań nazw nie eliminuje wszystkich duplikatów z całego inventarza.

Wynik jest jedynie heurystyką opartą na sformułowaniach: słowa wspólne dla obu opisów podzielone przez liczbę różnych słów w nich zawartych, przy standardowym progu 0,35. Wykluczenie może wyglądać jak nakładanie się, a dwa różnie sformułowane opisy tej samej pozycji mogą przejść niezauważone. Parser frontmatter obsługuje również tylko podzbiór formatu YAML. Każdy flag wymaga sprawdzenia przez człowieka, zanim zostanie przekształcony w naprawę.

Po pomyślnym zakończeniu naprawy należy zachować przypadek z awarią wraz z takim, w którym stara wersja już poprawnie funkcjonowała. Razem pokazują one, czy późniejsza zmiana naprawia jedno zachowanie kosztem innego. Nie zaobserwowano żadnego ogólnego poprawienia skuteczności zadań w narzędziu whetstone, a te sprawdzenia służą do jej oceny.

Pakiet nie jest przenoszony; przenoszone są umiejętności

Celem było umożliwienie użycia whetstone poza Claude Code. Dzielenie się formatem SKILL.md pomaga w tym celu. Umiejętność może nadal polegać na narzędziach, uprawnieniach lub ścieżkach plików, których nie dostarcza inny klient, a każdy klient pakuje plugini w inny sposób. Standard Agent Plugins, dokumentacja Claude Code oraz OpenCode opisują te struktury.

Whetstone wysyła oba listy manifestów do jednego wspólnego katalogu skills/. Procedura jest przechowywana w jednym miejscu, a integracja każdego klienta jest testowana osobno. Instrukcje przenośne nadal nie sprawiają, że modele są wzajemnie zamienne, dlatego należy wykonać tę samą zadaniową próbę w innym kompatybilnym środowisku i sprawdzić jego wywołania narzędzi, zależności oraz wynik, zanim założy się, że zachowanie jest takie samo.

Próba w jednym procesie pracy

Nie wymagana jest żadna duża biblioteka. Wybierz jeden proces pracy – na przykład pomocnik, który agent ciągle odbudowuje, dwie umiejętności, które łączy, lub wynik, który zwykle kończysz ręcznie. Zachowaj jeden reprezentatywny żądanie wraz z jego wynikiem do porównania.

Następnie wybierz odpowiednią interwencję: użyj istniejącego narzędzia pomocniczego, udoskonal selekcję, nagraj lekcję proceduralną lub dodaj brakującą weryfikację akceptacji. Następnie porównaj następne uruchomienie z zapisanym przykładem. Szerszy spis może poczekać, a stary cache nie powinien być usuwany tylko dlatego, że skan rekurencyjny odkrył stare pliki.

Projekt jest objęty licencją MIT. W przypadku Claude Code w pliku README podane są poniższe polecenia instalacyjne:

claude plugin marketplace add cdcore09/whetstone
claude plugin install whetstone@whetstone

Udostępniono cztery punkty wejścia: /audit, /promote, /repair oraz /verify. Wybierz ten, który pasuje do Twojego procesu pracy. Przy pierwszej próbie rozsądnie jest, aby narzędzie sprawdziło odpowiednie pliki i zaproponowało zmiany, zanim cokolwiek zostanie zastosowane.

Aby przyjrzeć się narzędziu audytowemu bez konieczności instalowania czegokolwiek, sklonuj repozytorium i przeczytaj plik skills/skill-audit/scripts/audit_skills.py. Z góry repozytorium uruchamia się poniższy polecenie, przy czym używana jest wyłącznie standardowa biblioteka Pythona:

python3 skills/skill-audit/scripts/audit_skills.py ./skills

Zamień ./skills na katalog, który chcesz przeanalizować, zaczynając od małej kolekcji, którą rozpoznajesz, zanim przeszukasz każdą pamięć cache pluginów na twoim komputerze. --json generuje ustrukturyzowany raport, a --threshold 0.25 pokazuje szerszy zbiór nakładających się opisów.

Skrypt jedynie czyta pliki i nigdy nie zapisuje na nowo informacji o umiejętnościach. Status wyjścia 1 oznacza, że znaleziono specjalne flagi, kolizje kandydatów lub duplikatów nazw, ale to niekoniecznie oznacza awarię Pythona. Domyślne ścieżki również nie obejmują struktury instalacji wszystkich klientów, więc wyraźna ścieżka sprawia, że zakres analizy jest jaśniejszy i łatwiejszy do odtworzenia. Jeśli raport zawiera prywatne opisy umiejętności lub ścieżki w systemie plików, przechowuj go lokalnie, a zamiast pełnego spisu wewnętrznych projektów udostępniaj jedynie statystyki oraz zanonimizowany przykład.

Celem jest gromadzenie przydatnych rozwiązań: kodu, który można ponownie wykorzystać, procedur, które można przeanalizować, oraz mechanizmów weryfikacji towarzyszących zadaniu. To praktyczny punkt wyjścia do tworzenia agentów zdolnych do samodoskonalenia, który pozostaje pod kontrolą wersji. Każdy, którego proces pracy wymaga innej implementacji, może oprzeć swoje rozważania na czterech pytaniach: co ponownie wykorzystać, co wybrać, czego się nauczyć oraz jak sprawdzić wynik.