SkillsBench: Ein Benchmark zur Bewertung der Leistung von Agenten-Skills über vielfältige Aufgaben hinweg

 (arxiv.org)
3 Punkte von GN⁺ 2026-02-18 | 1 Kommentare | Auf WhatsApp teilen
  • Der erste Benchmark zur quantitativen Bewertung der Wirkung von Skills (Agent Skills) bei auf großen Sprachmodellen (LLMs) basierenden Agenten; umfasst 84 Aufgaben in 11 Domänen
  • Jede Aufgabe wird unter drei Bedingungen evaluiert: ohne Skills, mit kuratierten Skills und mit selbst erzeugten Skills; insgesamt wurden 7.308 Ausführungspfade erfasst
  • Kuratierte Skills zeigten im Durchschnitt eine Leistungssteigerung von +16,2 Prozentpunkten, allerdings mit großen Unterschieden zwischen den Domänen, und bei einigen Aufgaben (16 von 84) sank die Leistung sogar
  • Selbst erzeugte Skills (Self-generated Skills) waren im Durchschnitt nicht wirksam und zeigen, dass Modelle prozedurales Wissen nicht zuverlässig selbst erzeugen können
  • Kleine, fokussierte Skill-Module (2–3 Bausteine) sind effizienter als umfassende dokumentartige Skills, und kleine Modelle mit Skills erreichen eine ähnliche Leistung wie große Modelle ohne Skills

Überblick über SKILLSBENCH

  • SKILLSBENCH ist ein Benchmark zur Bewertung des Effekts von Skill-Erweiterungen bei LLM-Agenten und wurde auf Basis des Harbor-Frameworks aufgebaut
    • Jede Aufgabe enthält eine Container-Umgebung, einen deterministischen Verifier und eine Referenzlösung (Oracle)
    • Dieselbe Aufgabe wird je nach Skill-Einsatz wiederholt ausgeführt, um den reinen Effekt der Skills zu messen
  • Während bestehende Benchmarks nur die Grundfähigkeiten von Modellen bewerten, misst SKILLSBENCH direkt den Einfluss von Skills auf die Leistung

Definition und Aufbau von Skills (Agent Skills)

  • Skills sind strukturierte Pakete mit prozeduralem Wissen (procedural knowledge), die das Verhalten von Agenten zum Inferenzzeitpunkt erweitern, ohne das Modell selbst zu verändern
    • Bestandteile: SKILL.md (Vorgehensweise für die Aufgabe), ausführbare Skripte, Code-Templates, Beispiele usw.
  • Skills müssen die folgenden vier Kriterien erfüllen
    • Sie enthalten prozedurale Inhalte
    • Sie gelten für eine Klasse von Aufgaben und nicht nur für einen Einzelfall
    • Sie enthalten strukturierte Bestandteile
    • Sie sind dateisystembasiert und dadurch portabel
  • System-Prompts, Few-Shot-Beispiele, RAG-Abrufe und Tool-Dokumentationen gelten nicht als Skills

Aufgabenaufbau und Erstellung des Datensatzes

  • Jede Aufgabe besteht aus vier Elementen: Anweisung, Umgebung, Lösung und Verifier
    • Die Umgebung ist in einem Docker-Container isoliert, um Reproduzierbarkeit zu gewährleisten
    • Der Verifier ist ein deterministisches Testskript, das Bestehen oder Nichtbestehen automatisch entscheidet
  • 105 Mitwirkende reichten 322 Aufgabenkandidaten ein; nach automatischer Validierung und menschlicher Prüfung wurden 84 Aufgaben final ausgewählt
  • Die Mitwirkenden mussten folgende Anforderungen erfüllen
    • Von Menschen verfasste Anweisungen (keine LLM-generierten)
    • Skills müssen prozedurale Anleitungen liefern und keine spezifischen Aufgabenlösungen
    • Alle Prüfungen müssen deterministisch (assertion-basiert) erfolgen
    • Sie müssen automatische Strukturprüfungen, Oracle-Ausführung, Erkennung von KI-Generierung und Leckage-Audits bestehen
  • Um Leckagen zu verhindern, werden Skills abgelehnt, wenn sie aufgabenspezifische Dateinamen, Konstanten oder Testreferenzen enthalten

Aufbau des Benchmarks und Schwierigkeitsklassen

  • SKILLSBENCH besteht aus 84 Aufgaben in 11 Domänen (Software, Gesundheitswesen, Finanzen, Robotik usw.)
  • Die Schwierigkeit wird anhand der menschlichen Bearbeitungszeit in drei Stufen eingeteilt
    • Core (unter 60 Minuten): 17
    • Extended (1–4 Stunden): 43
    • Extreme (mehr als 4 Stunden): 26

Versuchsaufbau

  • Bewertung von drei kommerziellen Agent-Harnesses: Claude Code, Gemini CLI, Codex CLI
  • Sieben Modelle verwendet: GPT-5.2, Claude Opus 4.5/4.6, Claude Sonnet 4.5, Claude Haiku 4.5, Gemini 3 Pro, Gemini 3 Flash
  • Bewertung unter drei Bedingungen
    • No Skills: ohne Skills
    • With Skills: mit kuratierten Skills
    • Self-Generated Skills: vom Modell selbst erzeugte und dann eingesetzte Skills
  • Insgesamt wurden 7.308 gültige Ausführungspfade (trajectories) gesammelt

Bewertungsmetriken

  • Pass Rate wird als zentrale Metrik verwendet
  • Zusätzlich wird der normalisierte Gewinn (normalized gain) berechnet, um absolute und relative Verbesserungen gemeinsam zu analysieren
  • Für jede Aufgabe wird der Mittelwert aus fünf Wiederholungen berechnet

Zentrale Ergebnisse

  • Kuratierte Skills erzielten im Durchschnitt eine Verbesserung um +16,2 Prozentpunkte, je nach Konfiguration im Bereich von +13,6 bis +23,3 Prozentpunkten
    • Die Unterschiede zwischen den Domänen sind groß; der stärkste Zugewinn zeigt sich im Gesundheitswesen (+51,9 Prozentpunkte), der geringste im Software Engineering (+4,5 Prozentpunkte)
    • Bei 16 von 84 Aufgaben sank die Leistung sogar
  • Selbst erzeugte Skills waren im Durchschnitt wirkungslos oder hatten einen negativen Effekt
    • Die Modelle sind nicht in der Lage, prozedurales Wissen zuverlässig selbst zu erzeugen
  • Fokussierte Skills (2–3 Module) zeigen eine höhere Effizienz als umfassende dokumentartige Skills
  • Die Kombination aus kleinem Modell + Skills erreicht eine ähnliche Leistung wie große Modelle ohne Skills

Fazit

  • SKILLSBENCH bietet ein skill-zentriertes Bewertungssystem und belegt quantitativ, welchen Einfluss Skills auf die tatsächliche Aufgabenleistung von LLM-Agenten haben
  • Die Ergebnisse zeigen, dass Qualität des Skill-Designs und Domänenpassung entscheidend für Leistungssteigerungen sind
  • Künftige Forschung kann dies als Grundlage nutzen, um strukturelle Designprinzipien von Skills und die Grenzen automatischer Erzeugung zu untersuchen

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-18
Hacker-News-Kommentare

  • Das Konzept der „Self-Generated Skills“ ist interessant, aber ich möchte darauf hinweisen, dass es sich von dem unterscheidet, was viele Leute unter „dem Prozess verstehen, in dem ein LLM selbst Fähigkeiten lernt“
    In der Studie wird dem Modell lediglich ein Prompt gegeben, vor dem Lösen eines Problems relevantes prozedurales Wissen zu erzeugen; mit tatsächlich aus Erfahrung gelernten Fähigkeiten hat das wenig zu tun
    Ich hoffe, dass die Medien diesen Unterschied sauber herausarbeiten

    • Der Umfang der experimentellen „Tasks“ ist viel zu eingeschränkt. Es wird nur eine einzelne Markdown-Datei und ein Validator verwendet; realistische Probleme wie bestehende Codebasen oder Refactoring werden nicht behandelt
      Selbst wenn ein LLM eigene Skills erzeugt, ist die Struktur so angelegt, dass weder Exploration noch Lernen möglich sind; letztlich wiederholt es also nur seinen eigenen Kontext
      Solche Ergebnisse zu verallgemeinern, ist irreführend
    • Der eigentliche Zweck von „Skills“ ist, dass sie wie kurze How-to-Notizen bei Bedarf abgerufen und genutzt werden können
      Wenn das Wissen ohnehin schon im Modell steckt, muss man es nicht extra als Dokument aufschreiben; sinnvoll wird es nur bei Informationen, die sich sonst nur schwer explizit machen lassen
    • Ich interessiere mich ebenfalls für einen Ansatz, bei dem ein LLM die nach einem Versuch gelernten Lektionen als Skill zusammenfasst
      Einen Skill vor dem Versuch zu erzeugen, ist ein realitätsferner Ansatz
    • Ich habe durch eine „Role-Play-Session“ nützliche Skills erstellt
      Den Agenten Fragen stellen zu lassen, ihn den Problemlösungsprozess durchlaufen zu lassen und das Ergebnis anschließend als evidenzbasierten, komprimierten Skill zusammenzufassen, war effektiv
    • Wie unter thisistheway.to/ai beschrieben, nutzen wir Fehlschläge von Agenten als Lernchancen
      ① Fehler erfassen → ② Ursache diagnostizieren → ③ Verbesserungswerkzeug auswählen → ④ als versioniertes Artefakt dokumentieren → ⑤ bei Bedarf zu einem Gate hochstufen
      Diese Schleife ist bei uns als Standardanweisung in allen Agenten enthalten

  • Ich nutze einen eigenen Skill-Creator für Claude
    Um zu verhindern, dass Claude Informationen, die es bereits kennt, erneut als Skill niederschreibt, darf ein Dokument nur Folgendes enthalten:
    ① Informationen außerhalb der Trainingsdaten, ② Kontext, der nur für die aktuelle Session gilt, ③ Informationen, die das Verhalten künftiger Claude-Instanzen ausrichten
    Der vollständige Inhalt steht im GitHub-Link

    • LLMs sind zwar schwach darin, zu reflektieren, was sie wissen und nicht wissen, aber ich halte diesen Ansatz selbst für sehr nützlich
    • Es ist allerdings riskant anzunehmen, dass Claude „das beste Wissen“ auswählen kann
      Die im Internet gelernten Daten sind qualitativ sehr uneinheitlich, daher ist kaum zu erwarten, dass das Modell Auswahlen auf Expertenniveau trifft
    • Mir gefällt, dass sich dieses Skill-Dokument wie ein guter Blogpost liest
      Ein Text mit nicht offensichtlichen Einsichten könnte ein gutes Kriterium dafür sein, was ein guter Skill ist
    • Solche praktischen Einsichten könnten Forschende ruhig zuerst auf arXiv veröffentlichen, bevor daraus ein Paper wird

  • Am interessantesten an den Studienergebnissen ist, dass selbst erzeugte Skills die Leistung verschlechtern (-1,3 Prozentpunkte), während kuratierte Skills sie stark verbessern (+16,2 Prozentpunkte)
    Das passt zur Hypothese, dass LLMs hervorragende Konsumenten prozeduralen Wissens sind, aber schwache Produzenten
    Besonders im Gesundheitswesen ist der Effekt viel stärker als im Softwarebereich, was vermutlich daran liegt, dass es bereits reichlich SWE-Daten gibt

    • Mir ist dieser Unterschied ebenfalls aufgefallen. Beim Umgang mit neuen oder seltenen Bibliotheken ist der Effekt von Skills drastisch größer
      Adobe React Spectrum UI ist zum Beispiel ohne Skill kaum sinnvoll nutzbar, mit einem gut gemachten Skill aber ein völlig anderes Erlebnis

  • Dem Modell einfach nur zu sagen: „Erstelle einen Skill“, ist bedeutungslos
    Wenn sein Wissen nicht durch neue Informationen oder externe Quellen erweitert wird, ist das letztlich nur ein Kreislauf, bei dem seine eigene Ausgabe wieder als Eingabe dient
    Ich verwende zur Skill-Erstellung einen skill-creator, der automatisch Recherche durchführt und die Ergebnisse für aktuelle Informationen oder Workflows aufbereitet

    • In der Studie erhielt der Agent keine Rechte für autonome Exploration oder Zugriff auf Materialien
      Unter solchen Bedingungen Skills zu erzeugen, ist sinnlos
    • In der Praxis ist es viel nützlicher, wenn Skills nach dem Einsatz im Feld über Feedback automatisch verbessert werden

  • Je stärker man LLMs über mehrere Ebenen hinweg automatisiert, desto eher sinkt die Qualität jedes einzelnen Schritts
    Wenn Menschen die Idee und den Umsetzungsplan vorgeben und das LLM nur codiert, funktioniert es ganz gut; sobald aber auch die Planung ausgelagert wird, kommt es zu einem starken Qualitätsverlust

    • Dieses Phänomen nenne ich „semantic collapse“
      Wenn Zusammenfassungen oder Reproduktionen immer weiter wiederholt werden, bricht die Bedeutung am Ende zusammen
      In bestimmten Abständen braucht es frischen menschlichen Input
    • Mit gutem Kontextmanagement kann aber auch das Gegenteil passieren
      Ich lasse das LLM in großen Codebasen zunächst einen Explorationsbericht schreiben und arbeite in einer neuen Session dann mit diesem Bericht weiter
      Das kostet mehr Tokens, aber wichtige Details gehen nicht verloren
    • Googles Aletheia zeigt, dass sich die Leistung in einer solchen Pipeline-Struktur sogar verbessern kann
      Der entscheidende Punkt ist letztlich, ob man dem Modell genügend Weltwissen zur Verfügung stellt
    • Ich würde diesen Prozess mit dem „Stille-Post-Spiel“ vergleichen
      Natürliche Sprache ist ihrem Wesen nach instabil; je öfter sie weitergegeben wird, desto stärker wird sie verzerrt
      Dass wir uns trotzdem so gut verständigen, ist an sich schon erstaunlich
    • Mit einer Feedback-Schleife sieht die Sache allerdings anders aus
      In einer Open-Loop-Struktur sinkt die Genauigkeit, aber wenn sich jeder Schritt selbst anpassen kann, ist das Ganze deutlich stabiler

  • Ich baue ein agentic-ready Data Warehouse (GitHub.com/mathisdrn/orca)
    Anfangs wollte ich Skills gegen Benchmarks optimieren, aber Ansätze wie DsPy und GEPA, bei denen die Modellsprache selbst als Evaluator und Builder dient, sind effizienter
    Ich frage mich, ob die Skill-Creator von Anthropic oder OpenAI ebenfalls eine solche Selbstoptimierungsstruktur haben

  • Ich halte diese Studie weder für überraschend noch für besonders relevant für die Praxis
    In der Realität erzeugen Modelle fast nie Skills nur aus ihrem eigenen latenten Wissen
    Die Studie hat genau unter diesen eingeschränkten Bedingungen getestet, daher ist das Ergebnis erwartbar
    Interessanter wäre ein Ansatz, bei dem das Modell Menschen interviewt oder nach tiefer Recherche Skills erzeugt

    • Diesem Einwand stimme ich voll zu
      Eher überrascht mich, dass so ein Paper überhaupt erschienen ist
    • Die moderne Wissenschaft fördert auch die Veröffentlichung von „nicht überraschenden Ergebnissen“
      Außerdem helfen solche Studien dabei, Manager davon abzuhalten, „das Modell einfach ohne Kontext ein Best-Practice-Dokument schreiben zu lassen“
    • Früher gab es tatsächlich Fälle, in denen Ansätze wie „erst planen, dann ausführen“ wirksam waren
      Diese Studie berücksichtigt diesen Kontext nicht
    • Letztlich ist das, als würde man sagen, dass CLAUDE.md oder AGENTS.md bedeutungslos seien, nur weil das Modell sie selbst geschrieben hat

  • Ich habe das Gefühl, dass derzeit zu viele kluge Leute ihre Energie an solchen KI-Debatten verschwenden
    Früher hat man einfach nützliche Software gebaut; heute vergräbt man sich in den wöchentlich neu auftauchenden KI-Themen
    Der Nerd-Sniping-Effekt ist noch stärker als bei Web3 oder JS-Frameworks
    Auch dieser Artikel bestätigt im Grunde nur ein erwartbares Ergebnis

    • Derzeit läuft ein dezentraler Evolutionsprozess, deshalb gibt es viele doppelte Versuche
      Es ist aber gut möglich, dass bald ein neues Modell erscheint und diese Diskussionen obsolet macht
      Viele Teams bekommen die Anweisung, auf eine „Skill-Strategie“ umzuschwenken, doch in der Zwischenzeit baut ein neues Modell es einfach besser
      Letztlich finden alle in einer instabilen Überlebensstruktur keine klare Richtung

  • Ich habe ebenfalls oft erlebt, dass die Qualität selbst erzeugter Dokumentation sinkt
    Wenn ein LLM aus Code „Best Practices“ extrahiert, werden fehlerhafte Muster oft direkt mitdokumentiert
    In C#-Code gab es zum Beispiel Fälle von falscher Nutzung von ConfigureAwait(false) oder Task.Run
    Um solche Probleme zu lösen, bauen wir ein kuratiertes Wissenssystem
    Ich glaube, dass Markdown-basiertes agentic coding die nächste Abstraktionsebene sein wird

    • Der Unterschied zu früheren Sprachen ist allerdings, dass die LLM-Ebene nicht deterministisch ist
      Welche Auswirkungen diese Eigenschaft auf das Gesamtverhalten hat, ist noch nicht klar

  • Der eingereichte Titel lautete „Self-generated agent skills are useless“, was gegen die HN-Richtlinien verstößt
    Den Originaltitel beizubehalten und Meinungen in den Kommentaren auszudrücken, ist fairer

    • Es ist allerdings auch problematisch, wenn unter einem zu vagen Titel das Kernergebnis untergeht
      Ein klarer Titel kann der Community größere Einsichten vermitteln
      Die Absicht war nicht Clickbait, sondern die Kernentdeckung hervorzuheben