Projektowanie, udoskonalanie i utrzymywanie agent skills w Perplexity

Produkty Perplexity typu frontier agent opierają się na fundamencie wiedzy technicznej i specjalistycznej, zamkniętej w modułowych Agent Skills. Utrzymujemy starannie wyselekcjonowaną bibliotekę Skill we wszystkich naszych środowiskach technicznych. Te Skill obejmują wiele uniwersalnych narzędzi zasilających Perplexity Computer; możliwości specyficzne dla pionów, takie jak finanse, prawo i zdrowie; oraz bardzo długą listę modułów zaspokajających potrzeby użytkowników. Niektóre Skill są wywoływane rzadko, ale są kluczowe, gdy zostaną wywołane. Aby zapewnić niezmiennie doskonałe doświadczenie użytkownika, zespół Perplexity ds. agentów traktuje jakość Skill tak samo priorytetowo, jak jakość kodu.

Intuicja i najlepsze praktyki wymagane do opracowania wysokiej jakości Skill znacząco różnią się od tych potrzebnych do tworzenia tradycyjnego oprogramowania. Zespół ds. agentów przegląda wiele zgłoszeń zmian od doskonałych inżynierów, którzy tworzą Skill w trakcie swojej pracy. Wynikiem jest prawie zawsze duża liczba komentarzy i sugestii poprawek. Dzieje się tak, ponieważ wiele przydatnych wzorców pisania kodu staje się antywzorcami przy tworzeniu Skill.

Na przykład, jeśli weźmiemy niektóre aforyzmy z PEP20 – The Zen of Python, szybko staje się jasne, że pisanie dobrego kodu w języku Python różni się od pisania dobrych Skill. Z 20 linii mądrości, co najmniej połowa jest całkowicie błędna lub aktywnie myląca przy pisaniu Skill. Oto pięć z nich:

Pięć kontrastów między zenem Pythona a wskazówkami artykułu dotyczącymi pisania Skills.

Ten przewodnik to dokument, z którego korzystają inżynierowie w Perplexity podczas opracowywania i przeglądania Skill. Udostępniamy również ten przewodnik publicznie, aby nasze odkrycia i wnioski mogły przynieść korzyści szerszej społeczności. Niezależnie od tego, czy jesteś inżynierem projektującym produkcyjne Skill w swojej codziennej pracy, użytkownikiem Computer chcącym opracować własny Skill w obszarze, który znasz najlepiej, czy też robisz obie te rzeczy, ten przewodnik jest dla Ciebie.

Czym jest Skill?

Pisząc Skill, nie piszesz zwykłego oprogramowania (mimo że Skill są teraz częścią głównych silników logicznych dla systemów agentowych). Raczej budujesz kontekst dla modeli i ich środowisk. Skill ma inne ograniczenia i inne zasady projektowania. Jeśli napiszesz Skill tak, jak piszesz kod, poniesiesz porażkę.

Skill to co najmniej cztery rzeczy, szczególnie w kontekście tego, jak tworzymy je w Perplexity.

Skill to katalog

Skill to nie tylko pojedynczy plik SKILL.md. W wielu przypadkach Skill obejmuje kilka plików. W katalogu nazwanym od Twojego Skill możesz mieć:

SKILL.md: frontmatter i instrukcje

scripts/: kod, który agent uruchamia, a nie wymyśla na nowo

references/: ciężkie dokumenty, ładowane warunkowo

assets/: szablony, schematy i dane

config.json: konfiguracja użytkownika przy pierwszym uruchomieniu

Ten wzorzec hub-and-spoke pozwala zachować bardzo skupione i zwarte Skill, a strukturę folderów można wykorzystać w bardzo kreatywny sposób. Czasami szczególnie skomplikowane Skill korzystają z wielu poziomów hierarchii, aby pomóc modelowi lepiej nawigować. Załóżmy, że Skill wymaga wiedzy z 300 tematów, które można pogrupować w 20 obszarów tematycznych. Niezawodne wybranie właściwego tematu spośród 300 to nierozwiązane wyzwanie nawet dla dzisiejszych najlepszych modeli frontier. Dla modelu problem wyboru jest znacznie łatwiejszy, gdy musi skupić się na jednym z 20 obszarów, niż na 15 tematach w obrębie tego obszaru.

Jako przykład wartości wielopoziomowej hierarchii, nasz zespół zastosował trzy poziomy zagnieżdżenia tematycznego w ramach Skill zasilających możliwości Computer w zakresie amerykańskiego podatku dochodowego w poprzednim sezonie podatkowym. Ta hierarchia była absolutnie niezbędna ze względu na złożoność prawa podatkowego: w naszych wczesnych testach prezentowanie modelowi pojedynczego folderu zawierającego wszystkie 1945 sekcji U.S. Internal Revenue Code skutkowało gorszą wydajnością niż nieładowanie Skill w ogóle. Organizacja informacji w logiczne podziały była niezbędna dla zapewnienia wysokiej precyzji operacji odczytu.

Jednak ta hierarchia nie była darmowa. Zwiększanie poziomów hierarchii wymaga zwiększenia poziomu kurateli w architekturze informacji, aby zarządzać wynikającą z tego pośredniością. Opracowaliśmy szybkie przewodniki, niestandardowe narzędzia wyszukiwania i inne przybory wspierające model w lokalizowaniu informacji przy minimalnej pośredniości. W tym przypadku wykonanie ciężkiej pracy kuratorskiej ostatecznie przyniosło pozytywny rezultat: Skill, który pozwolił modelom wykonywać zadania związane z podatkami znacznie sprawniej niż przy użyciu samych narzędzi ogólnych.

Powiększ

Skill to format

Skill to format. Główny plik źródłowy SKILL.md musi mieć zarówno nazwę, jak i opis. Co więcej, Skill musi dokładnie odpowiadać nazwie katalogu, w którym się znajduje. Nazwa musi składać się wyłącznie z małych liter, nie może zawierać spacji i może zawierać myślniki. Opis jest wyzwalaczem routingu. Jest to częsty punkt awarii: opis nie jest dokumentacją wewnętrzną tego, co robi Skill. Składa się on z instrukcji dla modelu, kiedy załadować Skill. Dlatego często będziesz widzieć „Ładuj, gdy”, a nie „Ten Skill robi”. Jest to ważne ze względu na sposób, w jaki większość implementacji wstrzykuje opis do kontekstu modelu.

Wewnątrz frontmatter znajduje się również „depends:”, co pozwala na tworzenie hierarchicznych zależności Skill, oraz „metadata:”, używane do przeglądów i ocen. Różne systemy agentowe mogą nawet definiować własne pola frontmatter, które będą używane w sposób specyficzny dla tych systemów. Alternatywnie, metadane specyficzne dla Skill mogą być spakowane w pomocniczym pliku konfiguracyjnym JSON lub YAML. Jest to pożądane podczas budowania systemów agentowych, które muszą ułatwiać różne typy zachowań wykonawczych na Skill bez zanieczyszczania kontekstu modelu drobnymi szczegółami. Wreszcie, podobne zachowanie można uzyskać poprzez usuwanie frontmatter Skill podczas odczytu. Computer stosuje tę metodologię, która pozwala na zachowanie konfiguracji w pliku głównym SKILL.md. Wymagana jest staranna dbałość o szczegóły w logice parsowania i warto wdrożyć warunkowe usuwanie, jeśli istnieją pewne pola, które są przydatne do posiadania wewnątrz kontekstu modelu.

Skill jest wywoływalny

Skill jest wywoływalny. Agent ładuje Skill w czasie wykonywania. Co ważne, Skill nie zawsze są zawarte w kontekście. Domyślnie większość systemów agentowych rozwija Skill progresywnie w zależności od konkretnej potrzeby.

Istnieją co najmniej trzy poziomy kosztów kontekstu w sposobie, w jaki zaimplementowaliśmy Skill w Computer. Oto proces:

Computer wywołuje load_skill(name="...")

Computer kopiuje katalog Skill do izolowanej piaskownicy wykonawczej

Computer rekurencyjnie automatycznie ładuje zależności w tagu „depends:”

Computer następnie usuwa frontmatter i dzięki temu agent widzi tylko treść oraz dodatkowe pliki

Różne systemy agentowe mogą wybierać różne sposoby prezentowania zawartości Skill. Jako przykład, niektóre systemy mogą zdecydować się na całkowite nieujawnianie hierarchii plików, pozostawiając modelowi samodzielne odkrywanie hierarchii poprzez operacje na systemie plików. Inne systemy mogą zdecydować się na przekazanie modelowi mapowania całego drzewa plików do określonego limitu obcięcia i/lub głębokości. Aby utrzymać kontekst w czystości, Computer pomija pełne hierarchie plików z kontekstu wywołania; jednakże można to nadpisać na zasadzie poszczególnych Skill.

Skill jest progresywny

Skill są progresywne. W Computer istnieją trzy różne poziomy kosztów kontekstu i ponosimy wszystkie trzy na różnych etapach:

Trzy poziomy kontekstu Skill: indeks, pełne wczytanie Skill oraz pliki referencyjne czasu działania.

Computer buduje indeks Skill, który zawiera nazwę i opis dla każdego dostępnego Skill. Budżet na to wynosi około 100 tokenów na Skill (krótszy jest nawet lepszy). Jest tak ciasno, ponieważ płacisz ten koszt w każdej Sesji, za każdego użytkownika. Jest to wstrzykiwane do systemowego promptu na samym początku konwersacji. Model ma dostęp do grupy nazwanych Skill i opisów, dzięki czemu może zdecydować, czy wywołać „load_skill()”. Poprzeczka wejścia do tego indeksu jest niezwykle wysoka. Twój Skill musi być bardzo przydatny, a opis musi być niezwykle gęsty i zwięzły, ponieważ wszyscy płacą ten koszt przez cały czas.

Po tym, jak system agentowy załaduje Skill, dostępna jest pełna treść SKILL.md. Idealnie byłoby, gdyby tekst treści nie przekraczał 5000 tokenów. Nawet wtedy chcesz, aby każde zdanie miało znaczenie, ponieważ po załadowaniu Skill reszta konwersacji musi za to płacić, dopóki nie osiągniesz granicy kompakcji. Wiele wątków ładuje od trzech do pięciu różnych Skill, zwielokrotniając ten koszt. Skill z dużą ilością zbędnych treści prawie na pewno pogorszą działanie innych Skill, jak również ogólne możliwości agentowe. Krótko mówiąc, jeśli Twój Skill się ładuje i nie robi tego, co należy, jest to zmarnowany kontekst.

Ostatnim poziomem progresji są skrypty lub przypadki szczególne, takie jak pod-Skill lub formatowanie. To tutaj chcesz umieścić nieograniczoną, warunkową logikę rozgałęzioną. Agent będzie jej używał tylko wtedy, gdy będzie jej potrzebował, co oznacza, że poprzeczka dla tego, co chcesz tutaj umieścić, jest znacznie niższa.

W indeksie każdy token jest ważny. Załadowana treść Skill jest bardziej zrelaksowana, a runtime najbardziej zrelaksowany. Może to być 20 000 tokenów lub zero tokenów. Jest to poziom, na którym można pomyśleć o rozszerzeniu kontekstu modelu w sposób progresywny (Rozumowanie).

Kiedy potrzebujesz Skill?

Zespół ds. agentów jest często pytany o opinię, czy Skill jest rzeczywiście potrzebny dla danej domeny lub przypadku użycia. Bardzo rzadko mamy ostateczną odpowiedź opartą wyłącznie na podstawowych zasadach. Jedynym sposobem, aby to naprawdę ustalić, jest rozpoczęcie pracy z agentem bez Skill, uruchomienie kilku zapytań hero, a następnie sprawdzenie, czy agent wykonuje dobrą robotę.

Kiedy potrzebujesz Skill

Istnieje wiele zadań, które znajdują się w dystrybucji dla wytrenowanych modeli. Musisz zastosować Skill tylko wtedy, gdy chcesz zmienić to zachowanie w określony sposób, czego nie możesz zrobić na przykład jednym zdaniem w swoim prompcie. Więc potrzebujesz Skill, gdy agent bez specjalnego kontekstu zrobi to źle lub jeśli występuje jakaś niespójność lub niedeterminizm, które musisz utrzymać w niezwykle spójny sposób przez wszystkie uruchomienia.

Może być tak, że Twoja wiedza jest trwała, ale nie znajduje się w danych treningowych. Mogą istnieć daty graniczne lub specyficzne przepływy pracy dla przedsiębiorstw, albo może to być kwestia gustu. Na przykład, mamy w Computer kilka Skill związanych z projektowaniem, napisanych przez Henry'ego Modisetta (naszego szefa działu projektowania). Powodem, dla którego każdy token istnieje w tych Skill, jest to, że Henry ma bardzo dobry gust, jeśli chodzi o projektowanie stron internetowych i plików PDF. Henry określa, jakich czcionek używać, a jakich nie, jak te czcionki odczuwać i inne kwestie oceny, których model nie może nauczyć się z samych danych treningowych.

Kiedy nie potrzebujesz Skill

Widzimy wiele Skill, w których inżynierowie napisali serię poleceń git, które muszą być wykonane w kolejności. To niepotrzebne, ponieważ model już wie, jak to zrobić, co oznacza, że jest to świetna dokumentacja, ale słaby Skill.

Widzimy przykłady, gdzie Skill powtarzają instrukcje z systemowego promptu. Nie potrzebujesz do tego Skill. Wiedza istotna dla większości zapytań powinna być zawarta w globalnym kontekście, a nie w warunkowo ładowanym Skill.

Jeśli jest coś, co zmienia się szybciej, niż możesz to utrzymać, nie potrzebujesz Skill. Na przykład, jeśli korzystasz z zewnętrznego punktu końcowego MCP, a jego narzędzia lub wersje tych narzędzi zmieniają się często, nie powinieneś wstrzykiwać ich do Skill. Jeśli to zrobisz, skończysz z dryfem, a model będzie popełniał błędy.

Każdy Skill to podatek

Oto użyteczny test, który możesz zastosować do każdego zdania w swoim Skill: „Czy agent zrobiłby to źle bez tej instrukcji?” Jeśli zdanie nie musi tam być, nie może sobie pozwolić na bycie tam, ponieważ każdy płaci ten koszt za każdym razem. Decydując, czy dodać Skill, czy nie, pamiętaj o tym podatku, w którym każda Sesja i każdy użytkownik kosztuje tokeny.

Poniższy słynny cytat, który brzmi znacznie lepiej po francusku, w przybliżeniu tłumaczy się jako „Napisałem ten list dłuższym tylko dlatego, że nie miałem czasu, aby uczynić go krótszym”.

« Je n’ai fait celle-ci plus longue que parce que je n’ai pas eu le loisir de la faire plus courte. » — Blaise Pascal, Lettres Provinciales, 1657

Podobnie jak Pascal, musisz zainwestować czas w każdy Skill. Trudno napisać krótki Skill. Jeśli Twój Skill jest łatwy do napisania, prawdopodobnie jest za długi lub nie powinien istnieć. Dobry Skill jest tak krótki, jak to tylko możliwe.

Jeśli próbujesz generować Skill za jednym zamachem i wysyłać PR-y w pięć minut, wyniki będą prawie na pewno poniżej średniej. W rzeczywistości wczesne badania wykazały, że jeśli używasz LLM do pisania Skill, LLM prawdopodobnie z tego nie skorzysta: „Samogenerowane Skill nie przynoszą korzyści średnio, pokazując, że modele nie mogą niezawodnie tworzyć wiedzy proceduralnej, z której konsumpcji korzystają”.

Jak zbudować Skill

Innymi słowy, musisz wstrzyknąć swoją opinię do każdego Skill, który piszesz. Wykonaj te kroki.

Krok 0: Napisz oceny (Evals)

Najpierw napisz kilka ocen. Możesz czerpać przypadki ewaluacyjne z:

Rzeczywiste zapytania użytkowników: próbka z produkcji lub Twojego zaufanego zespołu

Znane awarie: Agent zawiódł, ponieważ Skill nie istniał

Zamieszanie sąsiednie: Blisko granicy Twojej domeny, ale kieruje do innego Skill

Przynajmniej powinieneś upewnić się, że testujesz, czy Skill ładuje się, gdy jest potrzebny. Idealnie byłoby, gdybyś pobrał próbki niektórych z nich, może ze środowiska produkcyjnego. Możesz również rozważyć znane przypadki błędów: może cały powód, dla którego zacząłeś pisać Skill, wynika z konkretnej awarii, którą zauważyłeś, lub może dokonujesz refaktoryzacji i istnieje zamieszanie w dwóch bliskich domenach, które są objęte jednym Skill.

Zacznij od podobnych negatywnych i pozytywnych przykładów. Negatywne przykłady są niezwykle potężne i mogą mieć większe znaczenie niż pozytywne przykłady.

Krok 1: Opis

To najtrudniejsza linia w Skill. To wyzwalacz routingu, a nie dokumentacja. Aby dobrze dobrać nazwę i opis, nie dbasz o treść Skill. Dbasz tylko o to, czy Skill jest ładowany i wstrzykiwany we właściwych punktach oraz czy jest wolny od niepożądanych skutków ubocznych, co jest głównym trybem awarii. Za każdym razem, gdy dodajesz dodatkowy Skill, ryzykujesz, że uczynisz każdy inny Skill nieco gorszym, więc musisz upewnić się, że minimalizujesz regresję.

Powtarzam, zły opis opisuje, co robi Skill lub dlaczego jest przydatny. Dobry opis mówi, kiedy agent powinien załadować Skill. Na przykład, powiedzmy, że masz coś do monitorowania PR-ów. Nie pisz, co robi Skill. Napisz, co mówią inżynierowie, gdy są sfrustrowani i chcą, abyś upewnił się, że ich PR działa, jak „babysit” lub „watch CI” lub „make sure this lands”.

Oto krótka lista kontrolna:

Zaczyna się od „Ładuj, gdy...”

Celuj w 50 słów lub mniej

Opisuje intencję użytkownika, najlepiej z rzeczywistych zapytań

Nie podsumowuje przepływu pracy

Rzeczywiste zapytania to to, co możesz pokryć w zasadzie 80-20. Zazwyczaj dwa lub trzy przykłady działają dobrze. Nie jest łatwo dodać dokładnie i tylko tyle, ile potrzebujesz.

Krok 2: Napisz treść (Body)

Następnie napisz treść samego Skill. Zauważ, że to nie jest Krok 0 ani Krok 1.

Komunikowanie przepływów pracy do LLM jest zupełnie inne niż komunikowanie przepływów pracy do kolegi, a nawet do Twojego systemu uruchomieniowego. Ucząc się nowego narzędzia programowego, inżynier może potrzebować przeczytać dokumentację, przejść przez walkthrough z kimś z doświadczeniem i nauczyć się, jak używać narzędzia. Tymczasem w przypadku prawie każdego narzędzia programowego, które istnieje co najmniej rok, wystarczy wspomnieć jego nazwę, a LLM ma wszystkie potrzebne informacje.

Pisząc treść, pomiń oczywiste rzeczy. Wielu inżynierów ma spore doświadczenie w pisaniu plików readme.md, które wymieniają każde polecenie, jakie ktoś musi uruchomić. Łatwo jest w to wpaść, pisząc Skill, ponieważ wydaje się, że piszesz dokumentację, ale jeśli to zrobisz, Twój Skill będzie bezużyteczny. Więc nie wypisuj serii poleceń.

Na przykład, nie musisz pisać: „git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;”

Zamiast tego napisz: „Cherry-pick commit onto a clean branch. Resolve conflicts preserving intent. If it can't land cleanly, explain why.”

Model wykona znacznie lepszą pracę z tym drugim niż z nadmiernie preskryptywną serią poleceń tego pierwszego, zwłaszcza gdy sprawy idą źle. Nie wywieraj presji ani nie bądź zbyt preskryptywny, co jest kruche, a zamiast tego bądź elastyczny tam, gdzie może sprawdzić się wiele podejść. Powtarzam, dobra dokumentacja dla ludzi jest najczęściej złą dokumentacją dla modeli.

Następnie skup się na gotchas lub negatywnych przykładach. Są to treści o wysokim sygnale, ponieważ często prowadzą model w zakresie tego, czego nie robić. Jeśli dodasz linię za każdym razem, gdy agent się potknie, nauczysz się tego, uruchamiając go, a gotchas będą rosły organicznie.

Wreszcie, jeśli istnieje jakakolwiek część, która jest warunkowa lub niezwykle ciężka pod względem treści, wyjmij ją z SKILL.md, który jest hubem, i umieść ją w jednej z odnóg (spokes). Umieść ją w pliku pomocniczym, który można progresywnie ładować, w co zagłębimy się w następnej kolejności.

Krok 3: Użyj hierarchii

Wykorzystaj hierarchię Skill, gdy masz skrypt, referencje lub używasz określonego narzędzia:

Sugerowane zastosowania skryptów, materiałów referencyjnych, zasobów i konfiguracji w obrębie Skill.

Dla wszystkiego, co jest warunkowe lub odgałęzia się od głównego Skill, wyodrębnij to do folderu. Pamiętaj również, że wielopoziomowa hierarchia może być używana do szczególnie skomplikowanych Skill. Dla nich będziesz chciał dokładnie przemyśleć, czy funkcjonalność powinna być zaimplementowana monolitycznie czy jako zbiór Skill (być może z relacjami ładowania opartymi na depends:).

Krok 4: Iteruj

Następnie wykonaj serię iteracji na gałęzi. Zacznij od głównej gałęzi bez Skill, wykonaj kilka iteracji, zbuduj swój zestaw zapytań hero i uruchom serię ocen. Każdy, kto przegląda Twój kod Skill, podziękuje Ci za przesłanie pojedynczego changesetu wraz z zestawem ewaluacyjnym. Przeglądanie kolejnych zmian przyrostowych (z wyjątkiem nowego gotcha) jest bardzo trudne, więc staraj się to minimalizować.

Prawdopodobnie wykonasz wiele małych zmian słownych. Małe zmiany słowne w opisach mogą mieć ogromny wpływ na routing (w tym efekty uboczne na inne Skill), więc wykonaj całą tę pracę przed Krokiem 5.

Krok 5: Wypuść

Wypuść to.

Jak utrzymywać Skill

Teraz, gdy napisałeś Skill, musisz go utrzymywać.

Koło zamachowe Gotchas

Od tego momentu Twoja lista gotchas ma tendencję do wzrostu lub zmiany. Często widzimy inżynierów, którzy wykonują PR-y bez ewaluacji, na przykład zmieniając opis. Jeśli zmieniasz opis po scaleniu swojego Skill, jesteś na złej drodze. Jeśli dokonujesz zmian w czymś, co decyduje, czy kierować Twój Skill, musisz napisać kilka ewaluacji, które wspierają zmiany.

Skill są w większości „append-mostly”. Sekcja gotchas zyskuje najwięcej wartości w czasie:

Agent zawodzi w czymś → Dodaj gotcha

Agent ładuje Skill poza celem → Zacieśnij opis i dodaj negatywne ewaluacje

Agent nie ładuje Skill, kiedy powinien → Dodaj słowa kluczowe i pozytywne ewaluacje

Zmiana promptu systemowego → Sprawdź pod kątem rywalizacji lub duplikacji

Łatwo jest zauważyć pojedynczy przypadek awarii w testach wewnętrznych lub na produkcji i dodać gotcha. To negatywny przykład, więc nie zmienia on radykalnie jawnych wytycznych, ale daje modelowi znać: „Hej, istnieje ta znana awaria”.

Gdy przechodzisz od 80-20 do uzyskania 99,9% lub 99,99% wskaźnika sukcesu, łatwo jest powiększyć tę listę gotchas. Gdy widzisz te negatywne przykłady, powinieneś dodawać je głównie do sekcji gotcha. Nie powinieneś dodawać dłuższych instrukcji ani zmieniać opisu.

Zestawy ewaluacyjne (Eval Suites)

W Perplexity uruchamiamy wiele zestawów ewaluacyjnych, aby sprawdzać różne rzeczy. Istnieją ładowanie Skill i odczyty plików Skill, które sprawdzają precyzję, odwołanie i kontrole zakazanych działań samego ładowania Skill. Czy agent skieruje Twój Skill, kiedy powinien? Zapewnia to, że nowe Skill nie łamią istniejących granic.

Istnieją również ewaluacje, które mogą sprawdzać poprawne ładowanie progresywne. Agent może załadować Skill, ale czy czyta plik pomocniczy lub pliki? Na przykład, jeśli masz Skill finansowy do zapytań finansowych, czy czyta on specjalny plik FORMATTING.md?

Istnieją również ewaluacje dla Skill, które testują zakończenie zadania end-to-end w ramach domen. Uruchamiamy pełną pętlę agenta i używamy sędziego LLM do oceniania wyników na podstawie rubryki dobrze zdefiniowanych kryteriów.

Wreszcie, ważne jest, aby uruchamiać te ewaluacje przeciwko różnym modelom. Computer obsługuje co najmniej trzy różne rodziny modeli orkiestracyjnych: GPT, Claude Opus i Claude Sonnet. Chcesz uruchomić swoje ładowanie Skill i Skill domenowe przeciwko tym różnym orkiestratorom agentów, aby upewnić się, że nie uzyskasz innego zachowania. Sonnet i GPT zachowują się zupełnie inaczej, jeśli chodzi o Skill.

Końcowe przemyślenia i wnioski

Im więcej budujesz Skill, tym lepiej będziesz je budować. Jeśli nie automatyzujesz lub nie starasz się tworzyć bardziej powtarzalnych zadań, które wykonujesz na co dzień przy użyciu Skill, zacznij natychmiast.

Akt budowania Skill sprawia, że stajesz się lepszy w budowaniu kolejnych, ale także są one niezwykle dobre w automatyzowaniu procesów biznesowych. Jeśli potrafisz opisać coś, co robisz co tydzień przed standupem, pod koniec każdego sprintu lub cokolwiek, co robisz jako inżynier codziennie, co tydzień, a nawet co kwartał, powinieneś pisać Skill, aby odzyskać swój czas.

Czy możesz zautomatyzować postmortemy? Czy możesz przeglądać PR-y? Każde zadanie, które potrafisz wykonać, możesz przynajmniej mieć w formie Agent Skill jako pierwszy krok. Zaoszczędzi Ci to znaczną ilość czasu.

Powiedziawszy to, pamiętaj, że Skill nie jest łatwy, a nawet nie zawsze konieczny. Mniej znaczy więcej. Kilka innych wniosków:

Napisz ewaluacje przed Skill. Dołącz negatywne przykłady i zakazane ładowania dla sąsiednich, ale odrębnych umiejętności.

Opis jest trudną częścią. „Ładuj, gdy...” (każde słowo kosztuje uwagę).

Gotchas to treści o niezwykle wysokiej wartości. Zacznij cienko, rośnij, gdy agent zawodzi.

Pamiętaj, że łatwo jest zepsuć inne wcześniej istniejące Skill, dodając nowy Skill, nawet jeśli go nie dotknąłeś (uważaj na działanie na odległość).

Używaj wszystkich dostępnych narzędzi za każdym razem, gdy piszesz i utrzymujesz Skill. Jeśli chcesz dowiedzieć się więcej, strona internetowa Agent Skills zawiera mnóstwo dobrych przykładów, a zarówno nasze wewnętrzne repozytorium, jak i publiczny ekosystem zawierają wiele przykładów dobrze zaprojektowanych Skill.

Cytat

@online{perplexity2026DesigningRefiningAndMaintainingAgentSkillsAtPerplexity,
  author = {{Perplexity} and Marshall Kiely and Daisy Lee and Jerry Ma and Lauren Kolm},
  title = {{Designing, refining, and maintaining agent skills at Perplexity}},
  date = {2026-05-01},
  url = {https://www.perplexity.ai/hub/blog/designing-refining-and-maintaining-agent-skills-at-perplexity}
}