Agent Skills bei Perplexity entwerfen, verfeinern und pflegen

Die wegweisenden Agentenprodukte von Perplexity stützen sich auf ein Fundament aus Know-how und Fachwissen, das in modularen Agent Skills verpackt ist. Wir pflegen eine sorgfältig kuratierte Bibliothek von Skills in unseren technischen Umgebungen. Diese Skills umfassen viele der allgemeinen Hilfsprogramme, die Perplexity Computer antreiben, vertikale spezifische Fähigkeiten in Bereichen wie Finanzen, Recht und Gesundheit sowie eine Vielzahl von Modulen zur Erfüllung von Benutzerbedürfnissen. Einige Skills werden selten, aber wenn sie aufgerufen werden, sind sie entscheidend. Um eine konstant exzellente Benutzererfahrung zu gewährleisten, priorisiert das Agents-Team von Perplexity die Skill-Qualität ebenso hoch wie die Code-Qualität.

Die Intuitionen und Best Practices, die für die Entwicklung eines qualitativ hochwertigen Skills erforderlich sind, unterscheiden sich wesentlich von denen, die für die Erstellung herkömmlicher Software notwendig sind. Das Agents-Team prüft zahlreiche Pull Requests von exzellenten Ingenieuren, die im Rahmen ihrer Arbeit Skills entwickeln. Das Ergebnis sind fast immer zahlreiche Anmerkungen und Änderungsvorschläge, da viele nützliche Muster für das Schreiben von Code bei der Skill-Erstellung zu Antipatterns werden.

Wenn man zum Beispiel einige der Aphorismen aus PEP20 – The Zen of Python heranzieht, wird schnell klar, dass das Schreiben von gutem Python-Code nicht mit dem Schreiben von guten Skills vergleichbar ist. Von den 20 Weisheiten sind mindestens die Hälfte beim Schreiben von Skills völlig falsch oder irreführend. Hier sind fünf davon:

Fünf Gegensätze zwischen dem Zen von Python und dem Leitfaden des Artikels zum Schreiben von Skills.

Dieser Leitfaden ist das Dokument, das Ingenieure bei Perplexity bei der Entwicklung und Überprüfung von Skills verwenden. Wir veröffentlichen diesen Leitfaden auch öffentlich, damit unsere Entdeckungen und Erkenntnisse der breiteren Gemeinschaft zugutekommen können. Ob Sie ein Ingenieur sind, der in seiner täglichen Arbeit produktive Skills entwirft, ein Computer-Benutzer, der einen eigenen Skill für einen Bereich entwickeln möchte, in dem Sie sich am besten auskennen, oder beides – dieser Leitfaden ist für Sie.

Was ist ein Skill?

Wenn Sie einen Skill schreiben, schreiben Sie keine gewöhnliche Software (auch wenn Skills jetzt Teil der wichtigsten logischen Engines für Agentensysteme sind). Vielmehr erstellen Sie Kontext für Modelle und deren Umgebungen. Ein Skill hat andere Einschränkungen und andere Designprinzipien. Wenn Sie einen Skill wie Code schreiben, werden Sie scheitern.

Ein Skill ist mindestens vier Dinge, insbesondere im Kontext dessen, wie wir sie bei Perplexity erstellen.

Ein Skill ist ein Verzeichnis

Ein Skill ist nicht nur eine einzelne SKILL.md-Datei. In vielen Fällen umfasst ein Skill mehrere Dateien. Unter dem Verzeichnis, das nach Ihrem Skill benannt ist, könnten Sie haben:

SKILL.md: Frontmatter und Anweisungen

scripts/: Code, den der Agent ausführt, nicht neu erfindet

references/: umfangreiche Dokumente, die bedingt geladen werden

assets/: Vorlagen, Schemata und Daten

config.json: Ersteinrichtung durch den Benutzer

Dieses Hub-and-Spoke-Muster ermöglicht es Ihnen, Skills sehr fokussiert und kompakt zu halten, und man kann die Ordnerstruktur sehr kreativ nutzen. Manchmal profitieren besonders komplizierte Skills von mehreren Hierarchieebenen, damit das Modell besser navigieren kann. Angenommen, ein Skill erfordert Wissen zu 300 Themen, die in 20 Themenbereiche unterteilt werden können. Die zuverlässige Auswahl des richtigen Themas aus 300 ist selbst für die besten heutigen Spitzenmodelle eine ungelöste Herausforderung. Es ist für ein Modell ein viel einfacheres Auswahlproblem, sich auf einen von 20 Bereichen zu konzentrieren, als auf eines der 15 Themen innerhalb dieses Bereichs.

Als ein Beispiel dafür, wie eine mehrstufige Hierarchie einen Mehrwert bietet: Unser Team setzte in der vergangenen Steuersaison drei Ebenen der thematischen Verschachtelung innerhalb der Skills ein, die die US-Einkommensteuer-Funktionen von Computer antreiben. Diese Hierarchie war angesichts der Komplexität des Steuerrechts absolut unverzichtbar: In unseren frühen Tests führte die Bereitstellung eines einzigen Ordners mit allen 1.945 Abschnitten des U.S. Internal Revenue Code für das Modell zu einer schlechteren Leistung als das Nicht-Laden des Skills. Die Organisation der Informationen in logische Unterteilungen war unverzichtbar, um hochpräzise Leseoperationen zu gewährleisten.

Doch diese Hierarchie war nicht kostenlos. Zunehmende Hierarchieebenen erfordern ein zunehmendes Maß an Kuratierung in der gesamten Informationsarchitektur, um die resultierende Indirektion zu verwalten. Wir haben Kurzanleitungen, benutzerdefinierte Suchprogramme und andere Tools entwickelt, um das Modell beim Auffinden von Informationen mit einem Minimum an Indirektion zu unterstützen. In diesem Fall führte die harte Arbeit der Kuratierung letztendlich zu einem positiven Endergebnis: ein Skill, der es Modellen ermöglichte, steuerbezogene Aufgaben weitaus fähiger auszuführen als durch die bloße Verwendung allgemeiner Werkzeuge.

Vergrößern

Ein Skill ist ein Format

Ein Skill ist ein Format. Die zentrale Root-Datei SKILL.md muss sowohl einen Namen als auch eine Beschreibung haben. Darüber hinaus muss der Skill genau dem Verzeichnisnamen entsprechen, in dem sich der Skill befindet. Der Name muss aus kleingeschriebenen Zeichen bestehen, darf keine Leerzeichen enthalten und kann Bindestriche verwenden. Die Beschreibung ist der Routing-Auslöser. Dies ist ein häufiger Fehlerpunkt: Die Beschreibung ist keine interne Dokumentation für das, was der Skill tut. Sie stellt Anweisungen für das Modell dar, wann der Skill geladen werden soll. Daher werden Sie häufig „Laden, wenn“ sehen, nicht „Dieser Skill macht“. Dies ist wichtig aufgrund der Art und Weise, wie die meisten Implementierungen die Beschreibung in den Modellkontext injizieren.

Innerhalb des Frontmatters gibt es auch „depends:“, was es Ihnen ermöglicht, hierarchische Skill-Abhängigkeiten zu erstellen, und „metadata:“, das für Überprüfungen und Bewertungen verwendet wird. Verschiedene Agentensysteme können sogar ihre eigenen Frontmatter-Felder definieren, die auf eine für diese Systeme spezifische Weise verwendet werden. Alternativ können Skill-spezifische Metadaten in einer zusätzlichen JSON- oder YAML-Konfigurationsdatei verpackt werden. Dies ist wünschenswert bei der Erstellung von Agentensystemen, die verschiedene Arten von Laufzeitverhalten pro Skill erleichtern müssen, ohne den Kontext des Modells mit Kleinigkeiten zu belasten. Schließlich ist ein ähnliches Verhalten durch das Entfernen des Skill-Frontmatters beim Lesen erreichbar. Computer verwendet diese Methodik, was es ermöglicht, die Konfiguration in der Root-Datei SKILL.md zu bewahren. Sorgfältige Detailgenauigkeit ist bei der Parsing-Logik erforderlich, und man möchte möglicherweise ein bedingtes Entfernen implementieren, falls bestimmte Felder vorhanden sind, die innerhalb des Modellkontexts nützlich sind.

Ein Skill ist aufrufbar

Ein Skill ist aufrufbar. Der Agent lädt einen Skill zur Laufzeit. Wichtig ist, dass Skills nicht immer in den Kontext eingebunden sind. Standardmäßig entfalten die meisten Agentensysteme Skills progressiv bei spezifischem Bedarf.

Es gibt mindestens drei Stufen von Kontextkosten bei der Art und Weise, wie wir Skills in Computer implementiert haben. Hier ist der Prozess:

Computer ruft load_skill(name="...") auf

Computer kopiert das Skill-Verzeichnis in die isolierte Ausführungs-Sandbox

Computer lädt rekursiv Abhängigkeiten im „depends:“-Tag automatisch

Computer entfernt dann das Frontmatter, sodass der Agent nur den Körper und die zusätzlichen Dateien sieht

Verschiedene Agentensysteme können wählen, Skill-Inhalte auf unterschiedliche Weise offenzulegen. Als Beispiel könnten einige Systeme wählen, die Dateihierarchie überhaupt nicht offenzulegen, und es dem Modell überlassen, die Hierarchie durch Dateisystemoperationen zu entdecken. Andere Systeme können wählen, dem Modell eine Abbildung des gesamten Dateibaums bis zu einer bestimmten Kürzung und/oder Tiefengrenze zu geben. Um den Kontext sauber zu halten, lässt Computer vollständige Dateihierarchien aus dem Aufrufkontext weg; dies ist jedoch auf Skill-Basis überschreibbar.

Ein Skill ist progressiv

Skills sind progressiv. In Computer gibt es drei verschiedene Stufen von Kontextkosten, und wir fallen bei verschiedenen Phasen in alle drei:

Die drei Ebenen des Skill-Kontexts: Index, vollständiges Skill-Laden und Laufzeit-Referenzdateien.

Computer erstellt einen Skill-Index, der den Namen und die Beschreibung für jeden verfügbaren Skill enthält. Das Budget dafür liegt bei etwa 100 Token pro Skill (kürzer ist sogar noch besser). Es ist so knapp, weil Sie diese Kosten in jeder Sitzung für jeden Benutzer bezahlen. Dies wird zu Beginn der Konversation in den System-Prompt injiziert. Das Modell hat Zugriff auf eine Reihe von benannten Skills und Beschreibungen, sodass es entscheiden kann, ob es „load_skill()“ aufruft. Die Messlatte für die Aufnahme in diesen Index liegt extrem hoch. Ihr Skill muss sehr nützlich sein, und die Beschreibung muss extrem dicht und prägnant sein, da jeder die Kosten die ganze Zeit bezahlt.

Nachdem das Agentensystem den Skill geladen hat, gibt es den vollständigen SKILL.md Körper. Idealerweise überschreitet der Textkörper nicht 5.000 Token. Selbst dann möchten Sie, dass jeder Satz zählt, denn sobald Sie einen Skill laden, muss der Rest der Konversation dafür zahlen, bis Sie die Komprimierungsgrenze erreichen. Viele Threads laden irgendwo zwischen drei und fünf verschiedene Skills, was diese Kosten vervielfacht. Skills mit viel „Füllmaterial“ werden fast sicher andere Skills sowie die gesamten agentischen Fähigkeiten verschlechtern. Kurz gesagt, wenn Ihr Skill geladen wird und er nicht das Richtige tut, ist das verschwendeter Kontext.

Die letzte Stufe der Progression sind Skripte oder Spezialfälle, wie Subskills oder Formatierung. Hier möchten Sie unbegrenzte bedingte verzweigte Logik platzieren. Der Agent wird sie nur verwenden, wenn er es muss, was bedeutet, dass es eine viel niedrigere Hürde dafür gibt, was Sie hier einfügen möchten.

Im Index ist jeder Token wichtig. Der geladene Skill-Körper ist entspannter, und die Laufzeit ist am entspanntesten. Das können 20.000 Token oder null Token sein. Dies ist die Ebene, auf der Sie darüber nachdenken könnten, den Kontext des Modells progressiv zu erweitern.

Wann benötigen Sie einen Skill?

Das Agents-Team wird oft gefragt, ob ein Skill für einen bestimmten Bereich oder Anwendungsfall wirklich benötigt wird. Nur sehr selten haben wir eine definitive Antwort allein aus Prinzipien. Der einzige Weg, dies wirklich herauszufinden, besteht darin, mit Ihrem Agenten ohne den Skill zu beginnen, einige Heldenabfragen durchzuführen und dann herauszufinden, ob der Agent gute Arbeit leistet.

Wenn Sie einen Skill benötigen

Es gibt viele Aufgaben, die in der Verteilung für trainierte Modelle liegen. Sie müssen einen Skill nur dann anwenden, wenn Sie dieses Verhalten auf eine bestimmte Weise ändern möchten, was Sie z. B. nicht mit einem Satz in Ihrem Prompt können. Sie benötigen also einen Skill, wenn der Agent es ohne speziellen Kontext falsch machen wird, oder wenn es eine gewisse Inkonsistenz oder Nicht-Determinismus gibt, bei der Sie extrem konsistent über Ausführungen hinweg sein müssen.

Es könnte sein, dass Ihr Wissen dauerhaft ist, aber nicht in den Trainingsdaten enthalten ist. Es könnte Grenzwerte oder unternehmensspezifische Workflows geben, oder es könnte eine Frage des Geschmacks sein. Zum Beispiel haben wir mehrere designbezogene Skills in Computer, die von Henry Modisett (unserem Leiter des Designs) geschrieben wurden. Der Grund, warum jeder Token in diesen Skills existiert, ist, dass Henry einen sehr guten Geschmack hat, wenn es um das Design von Websites und PDFs geht. Henry legt fest, welche Schriftarten zu verwenden sind und welche nicht, wie sich diese Schriftarten anfühlen und andere Urteilsfragen, die das Modell nicht allein aus Trainingsdaten lernen kann.

Wenn Sie keinen Skill benötigen

Wir sehen viele Skills, bei denen Ingenieure eine Reihe von Git-Befehlen geschrieben haben, die nacheinander ausgeführt werden müssen. Das ist unnötig, weil das Modell bereits weiß, wie das geht, was bedeutet, dass es eine großartige Dokumentation, aber einen schlechten Skill abgibt.

Wir sehen Beispiele, bei denen Skills Anweisungen aus dem System-Prompt rekapitulieren. Dafür benötigen Sie keinen Skill. Wissen, das für die Mehrheit der Anfragen relevant ist, sollte im globalen Kontext enthalten sein, nicht in einem bedingt geladenen Skill.

Wenn sich etwas schneller ändert, als Sie es warten können, benötigen Sie keinen Skill. Wenn Sie zum Beispiel einen entfernten MCP-Endpunkt aufrufen und dessen Tools oder die Versionen dieser Tools sich häufig ändern, sollten Sie diese nicht in einen Skill injizieren. Wenn Sie dies tun, werden Sie nur mit Drift enden und das Modell wird Fehler machen.

Jeder Skill ist eine Steuer

Hier ist ein nützlicher Test, den Sie auf jeden Satz in Ihrem Skill anwenden können: „Würde der Agent dies ohne diese Anweisung falsch machen?“ Wenn der Satz nicht da sein muss, kann er es sich nicht leisten, dort zu sein, weil jeder diese Kosten jedes Mal bezahlt. Wenn Sie entscheiden, ob Sie einen Skill hinzufügen oder nicht, erinnern Sie sich an diese Steuer, bei der jede Sitzung und jeder Benutzer Token kostet.

Das folgende berühmte Zitat, das auf Französisch viel besser klingt, lässt sich grob übersetzen als: „Ich habe diesen Brief nur deshalb länger gemacht, weil ich nicht die Zeit hatte, ihn kürzer zu machen.“

„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

Genau wie Pascal müssen Sie Zeit in jeden Skill investieren. Es ist schwer, einen kurzen Skill zu schreiben. Wenn Ihr Skill einfach zu schreiben ist, ist er wahrscheinlich zu lang oder sollte nicht existieren. Ein guter Skill ist so kurz, wie er sein kann.

Wenn Sie sich dabei ertappen, wie Sie versuchen, die Skill-Generierung auf einen Schlag zu erledigen und PRs in fünf Minuten einzureichen, werden die Ergebnisse fast sicher unterdurchschnittlich sein. Tatsächlich hat frühe Forschung gezeigt, dass, wenn Sie LLMs verwenden, um Skills zu schreiben, das LLM wahrscheinlich nicht davon profitieren wird: „Selbstgenerierte Skills bieten im Durchschnitt keinen Nutzen, was zeigt, dass Modelle das prozedurale Wissen, von dessen Konsum sie profitieren, nicht zuverlässig verfassen können.“

Wie man einen Skill baut

Anders ausgedrückt, Sie müssen Ihre Meinung in jeden Skill einbringen, den Sie schreiben. Befolgen Sie diese Schritte.

Schritt 0: Schreiben Sie die Evals

Schreiben Sie zuerst einige der Evals. Sie können Bewertungsfälle beziehen aus:

Echte Benutzeranfragen: Stichproben aus der Produktion oder Ihrem Vertrauenskreis

Bekannte Fehler: Der Agent ist fehlgeschlagen, weil der Skill nicht existierte

Nachbarschaftsverwirrung: Nah an Ihrer Domänengrenze, aber Routen zu einem anderen Skill

Zumindest sollten Sie sicherstellen, dass Sie testen, dass der Skill geladen wird, wenn er benötigt wird. Idealerweise ziehen Sie einige davon als Stichprobe, vielleicht aus einer Produktionsumgebung. Sie könnten auch bekannte Fehlerfälle in Betracht ziehen: Vielleicht ist der ganze Grund, warum Sie angefangen haben, den Skill zu schreiben, ein spezifischer Fehler, den Sie bemerkt haben, oder vielleicht refaktorisieren Sie und es gibt eine gewisse Verwirrung in zwei nahe beieinander liegenden Domänen, die durch einen Skill abgedeckt werden.

Beginnen Sie mit ähnlichen negativen und positiven Beispielen. Negative Beispiele sind extrem mächtig und können mehr zählen als positive Beispiele.

Schritt 1: Die Beschreibung

Dies ist die schwierigste Zeile im Skill. Es ist ein Routing-Auslöser, keine Dokumentation. Um den Namen und die Beschreibung richtig zu machen, ist Ihnen der Inhalt des Skills egal. Sie interessieren sich nur dafür, ob der Skill geladen und an den richtigen Stellen injiziert wird und frei von Nebeneffekten außerhalb des Ziels ist, was der häufigste Fehlermodus ist. Jedes Mal, wenn Sie einen zusätzlichen Skill hinzufügen, riskieren Sie, jeden anderen Skill leicht zu verschlechtern, daher müssen Sie sicherstellen, dass Sie Regression minimieren.

Noch einmal: Eine schlechte Beschreibung beschreibt, was der Skill tut oder warum er nützlich ist. Eine gute Beschreibung sagt, wann der Agent den Skill laden soll. Wenn Sie zum Beispiel etwas zur Überwachung von Pull Requests haben: Schreiben Sie nicht, was der Skill tut. Schreiben Sie, was Ingenieure sagen, wenn sie frustriert sind und möchten, dass Sie sicherstellen, dass ihr PR funktioniert, wie „babysitten“ oder „CI beobachten“ oder „sicherstellen, dass dies landet“.

Hier ist eine kurze Checkliste:

Beginnt mit „Laden, wenn...“

Ziel 50 Wörter oder weniger

Beschreibt die Absicht des Benutzers, idealerweise aus echten Anfragen

Fasst nicht den Workflow zusammen

Echte Anfragen sind das, was Sie in einer 80-20-Regel abdecken können. Normalerweise funktionieren zwei oder drei Beispiele gut. Es ist nicht einfach, genau und nur so viel hinzuzufügen, wie Sie benötigen.

Schritt 2: Schreiben Sie den Körper

Als Nächstes schreiben Sie den Inhalt des Skills selbst. Beachten Sie, dass dies nicht Schritt 0 oder Schritt 1 ist.

Workflows an ein LLM zu kommunizieren ist völlig anders, als Workflows an einen Kollegen oder sogar an Ihr Laufzeitsystem zu kommunizieren. Beim Lernen eines neuen Software-Tools muss ein Ingenieur möglicherweise die Dokumentation lesen, sich von jemandem mit Erfahrung durchführen lassen und lernen, wie man das Tool verwendet. In der Zwischenzeit müssen Sie bei fast jedem Software-Tool, das es seit mindestens einem Jahr gibt, nur seinen Namen erwähnen und das LLM hat alle Informationen, die es benötigt.

Wenn Sie den Körper schreiben, lassen Sie die offensichtlichen Dinge weg. Viele Ingenieure haben viel Erfahrung beim Schreiben von Readme.md-Dateien, die jeden Befehl auflisten, den jemand ausführen muss. Es ist einfach, darauf zurückzugreifen, wenn Sie einen Skill schreiben, weil es sich anfühlt, als würden Sie eine Dokumentation schreiben, aber wenn Sie das tun, wird Ihr Skill Müll sein. Schreiben Sie also nicht eine Reihe von Befehlen auf.

Zum Beispiel müssen Sie nicht schreiben: „git log # find the commit; git checkout main; git checkout -b <clean-branch>; git cherry-pick <commit>;“

Schreiben Sie stattdessen: „Cherry-pick den Commit auf eine saubere Branch. Löse Konflikte unter Wahrung der Absicht. Wenn es nicht sauber landen kann, erkläre warum.“

Das Modell wird mit dem Letzteren viel bessere Arbeit leisten als mit der zu präskriptiven Reihe von Befehlen des Ersteren, besonders wenn Dinge schief gehen. Seien Sie nicht zu präskriptiv, was zerbrechlich ist, und seien Sie stattdessen flexibel, wo mehrere Ansätze funktionieren können. Noch einmal: Gute Dokumentation für Menschen ist meistens schlechte Dokumentation für Modelle.

Konzentrieren Sie sich als Nächstes auf die Gotchas oder negative Beispiele. Dies sind Inhalte mit extrem hohem Signalwert, da sie das Modell oft in Bezug auf das leiten, was nicht zu tun ist. Wenn Sie jedes Mal eine Zeile hinzufügen, wenn der Agent stolpert, lernen Sie durch Ausführen und die Gotchas werden organisch wachsen.

Schließlich, wenn es einen Teil gibt, der bedingt ist oder inhaltlich extrem schwer, nehmen Sie ihn aus der SKILL.md, die der Hub ist, und setzen Sie ihn in einen der Spokes. Setzen Sie ihn in eine Zubehördatei, die progressiv geladen werden kann, worauf wir als Nächstes eingehen werden.

Schritt 3: Nutzen Sie die Hierarchie

Nutzen Sie die Skill-Hierarchie, wenn Sie ein Skript, Referenzen oder ein bestimmtes Tool verwenden:

Empfohlene Einsatzmöglichkeiten für Skripte, Referenzen, Assets und Konfiguration innerhalb eines Skills.

Für alles, was bedingt ist oder vom Haupt-Skill abzweigt, brechen Sie es in einen Ordner aus. Denken Sie auch daran, dass eine mehrstufige Hierarchie für besonders komplizierte Skills verwendet werden kann. Für diese möchten Sie sorgfältig darüber nachdenken, ob die Funktionalität monolithisch oder als Sammlung von Skills implementiert werden sollte (vielleicht mit depends:-basierten Ladebeziehungen).

Schritt 4: Iterieren

Führen Sie als Nächstes eine Reihe von Iterationen auf einer Branch durch. Starten Sie auf der Haupt-Branch ohne Skill, führen Sie einige Iterationen durch, erstellen Sie Ihren Heldenabfrage-Satz und führen Sie eine Reihe von Evals aus. Jeder, der Ihren Skill-Code überprüft, wird Ihnen dafür danken, dass Sie einen einzelnen Changeset komplett mit einem Evaluationssatz einreichen. Die Überprüfung aufeinanderfolgender inkrementeller Änderungen (außer einem neuen Gotcha) ist sehr schwer, versuchen Sie also, dies zu minimieren.

Sie werden wahrscheinlich viele kleine Wortänderungen vornehmen. Kleine Wortänderungen in Beschreibungen können eine überproportionale Auswirkung auf das Routing haben (einschließlich Spillover-Effekte auf andere Skills), also erledigen Sie all diese Arbeit vor Schritt 5.

Schritt 5: Versenden

Versenden Sie es.

Wie man einen Skill wartet

Jetzt, da Sie einen Skill geschrieben haben, müssen Sie ihn warten.

Das Gotchas-Schwungrad

Ab diesem Zeitpunkt neigt Ihre Liste von Gotchas dazu, viel zu wachsen oder sich zu ändern. Wir sehen oft Ingenieure, die PRs machen, die nicht evaluiert sind, zum Beispiel die Beschreibung ändern. Wenn Sie die Beschreibung ändern, nachdem Ihr Skill gemergt wurde, sind Sie auf dem falschen Weg. Wenn Sie Änderungen an der Sache vornehmen, die entscheidet, ob Ihr Skill geroutet werden soll, müssen Sie einige Evals schreiben, die die Änderungen unterstützen.

Skills sind meistens append-only. Der Gotchas-Abschnitt erzielt im Laufe der Zeit den größten Wert:

Agent scheitert an etwas → Gotcha hinzufügen

Agent lädt den Skill abseits des Ziels → Beschreibung straffen und negative Evals hinzufügen

Agent lädt den Skill nicht, wenn er sollte → Schlüsselwörter und positive Evals hinzufügen

System-Prompt ändert sich → Auf Kontention oder Duplizierung prüfen

Es ist leicht, einen einzelnen Fehlerfall bei internen Tests oder in der Produktion zu bemerken und ein Gotcha hinzuzufügen. Es ist ein negatives Beispiel, also ändert es nicht wirklich die explizite Anleitung, aber es lässt das Modell wissen: „Hey, da ist dieser bekannte Fehler.“

Wenn Sie von der 80-20-Regel zum Erreichen einer Erfolgsquote von 99,9 % oder 99,99 % übergehen, ist es einfach, diese Gotcha-Liste wachsen zu lassen. Wenn Sie diese negativen Beispiele sehen, sollten Sie hauptsächlich an den Gotcha-Abschnitt anhängen. Sie sollten keine längeren Anweisungen hinzufügen oder die Beschreibung ändern.

Eval-Suiten

Bei Perplexity führen wir viele Eval-Suiten aus, um auf verschiedene Dinge zu prüfen. Es gibt Skill-Laden und Skill-Dateilesen, was die Präzision, den Rückruf und verbotene Überprüfungen des Skill-Ladens selbst überprüft. Wird der Agent Ihren Skill routen, wenn er es soll? Diese stellen sicher, dass neue Skills keine bestehenden Grenzen verletzen.

Es gibt auch Evals, die auf ordnungsgemäßes progressives Laden prüfen können. Der Agent könnte den Skill laden, aber liest er die Zubehördatei oder Dateien? Zum Beispiel: Wenn Sie einen Finanz-Skill für Finanzanfragen haben, liest er die spezielle FORMATTING.md-Datei?

Es gibt auch Evals für Skills, die auf End-to-End-Aufgabenerfüllung innerhalb von Domänen testen. Wir führen den vollständigen Agenten-Loop aus und verwenden einen LLM-Richter, um die Ergebnisse basierend auf einer Rubrik gut definierter Kriterien zu bewerten.

Schließlich ist es wichtig, diese Evals gegen verschiedene Modelle auszuführen. Computer unterstützt mindestens drei verschiedene Orchestrierungs-Modellfamilien: GPT, Claude Opus und Claude Sonnet. Sie möchten Ihr Skill-Laden und die Domänen-Skills gegen diese verschiedenen Agenten-Orchestratoren ausführen, um sicherzustellen, dass Sie kein anderes Verhalten erhalten. Sonnet und GPT verhalten sich in Bezug auf Skills ziemlich unterschiedlich.

Abschließende Gedanken und Erkenntnisse

Je mehr Skills Sie bauen, desto besser werden Sie darin, sie zu bauen. Wenn Sie nicht automatisieren oder versuchen, reproduzierbarere Aufgaben zu erstellen, die Sie täglich mit Skills erledigen, beginnen Sie sofort.

Der Akt des Bauens von Skills macht Sie besser darin, mehr Skills zu bauen, aber sie sind auch extrem gut darin, Geschäftsprozesse zu automatisieren. Wenn Sie etwas beschreiben können, das Sie jede Woche vor Ihrem Standup, am Ende jedes Sprints oder irgendetwas, das Sie als Ingenieur täglich, wöchentlich oder sogar vierteljährlich tun, sollten Sie einen Skill schreiben, um Ihre Zeit zurückzugewinnen.

Können Sie Postmortems automatisieren? Können Sie Pull Requests überprüfen? Bei jeder Aufgabe, die Sie erledigen können, können Sie zumindest den ersten Durchlauf zu einem Agent Skill machen. Es wird Ihnen bedeutende Zeit sparen.

Das gesagt, denken Sie daran, dass ein Skill nicht einfach oder sogar immer notwendig ist. Weniger ist mehr. Ein paar andere Erkenntnisse:

Schreiben Sie Evals vor dem Skill. Fügen Sie negative Beispiele und verbotene Ladungen für angrenzende, aber unterschiedliche Skills hinzu.

Die Beschreibung ist der schwierige Teil. „Laden, wenn...“ (jedes Wort kostet Aufmerksamkeit).

Gotchas sind Inhalte mit extrem hohem Wert. Starten Sie dünn, wachsen Sie, wenn der Agent scheitert.

Denken Sie daran, dass es einfach ist, andere bereits bestehende Skills durch Hinzufügen eines neuen Skills zu zerstören, obwohl Sie ihn nicht berührt haben (hüten Sie sich vor Fernwirkung).

Nutzen Sie jedes Mal alle verfügbaren Tools, wenn Sie einen Skill schreiben und warten. Wenn Sie mehr erfahren möchten, bietet die Agent Skills-Website viele gute Beispiele, und sowohl unser internes Repository als auch das öffentliche Ökosystem enthalten viele Beispiele für gut designte Skills.

Zitieren

@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}
}