Wir haben 30 Skills mit 150 Aufgaben getestet und 7 unintuitive Ergebnisse erzielt.

Im ersten Halbjahr 2026 kam es zu einem Sprung in der Anzahl der Skills. Viele Unternehmen haben alle internen Arbeitsabläufe in Skills umgewandelt. Wenn man einem Large Language Model (LLM) einen Skill hinzufügt, wird erwartet, dass das Modell "sofort professioneller" wird.

Wenn die Anzahl der Skills von ein paar Dutzend auf einige Hundert ansteigt, wird immer wieder eine einfache Frage gestellt:

Wird das Modell wirklich stärker, wenn man ihm Skills hinzufügt?

Mit dieser Frage haben wir in der TRACE-Selektionsbewertung systematische Experimente durchgeführt. Wir haben nicht die leichten Methoden wie "Auf der Download-Liste gucken" oder "Einmal ausführen und eine Note geben" gewählt. Stattdessen haben wir unter einheitlichen Prompts, einheitlichen Richtern und einheitlichen Bewertungskriterien jedes Skill-Modell mit dem "nackten Modell" (ohne Skills) in 150 Aufgabenpaaren verglichen, die Kosten und Stabilität von 30 Skills geprüft, 107 Normierungsprobleme untersucht und eine Übertragbarkeitstestung bei unterschiedlicher Inferenzstärke der Modelle durchgeführt.

Eine detaillierte Einführung in die TRACE-Selektionsbewertung finden Sie in "3 Bilder, 5000 Wörter: Was ist wirklich ein guter Skill?".

Während der kontinuierlichen Bewertung der Skills haben wir 7 bemerkenswerte Erkenntnisse zusammengetragen und die zugehörigen Experimentaldaten, den Bewertungsprozess und die Mechanismen öffentlich gemacht. Viele dieser Ergebnisse waren uns überraschend.

01 Ein Skill garantiert keine besseren Ergebnisse

Unser ursprünglicher Gedanke hinter der Hinzufügung von Skills war, dass das LLM oder ein allgemeiner Agent in bestimmten Bereichen stärkere Fachkompetenzen erlangt. Aber in unseren Experimenten wurde die erste Intuition, dass "mehr Skills immer besser sind", widerlegt.

In 150 Aufgabenpaaren gewann die Skill-Gruppe 62 Mal (41,3%), die Gruppe ohne Skills 55 Mal (36,7%) und es gab 33 Unentschieden (22,0%). Die Skill-Gruppe hatte nur einen geringen Vorteil, weit entfernt von einer überwältigenden Dominanz.

Was noch wichtiger ist, die Unterschiede zwischen den Skills variierten stark:

· Skills, die stabile positive Effekte hatten, waren: data-analysis, multi-search-engine, baoyu-cover-image usw.;

· Skills, die schlechter waren als das nackte Modell: note-taker, fliggy-travel-planner, meeting-minutes usw.

Warum ist das so? Wenn man die Sieges- und Niederlagendaten analysiert, wird die Regelung klar: Ein Skill ist nützlich, wenn er etwas hinzufügt, was das nackte Modell nicht kann, wie eine klare Ausgabestruktur, externe Tools, einen eingeschränkten Arbeitsablauf oder ein konkretes Ergebnis. Wenn ein Skill nur das macht, was das Modell sowieso kann, "nur nochmal in Markdown schreibt", bringt er eher Belastung als Vorteil.

02 Es gibt ein "Sogphänomen" bei Skills

Bei unseren Routing-Experimenten mit Skills haben wir ein Phänomen beobachtet, das wir "Skill-Sog" nennen können: Manche Anfragen sind so einfach, dass das nackte Modell direkt antworten kann. Aber wenn die Semantik einer Anfrage einem Skill ähnelt, kann das System es nicht widerstehen, diesen Skill zu laden.

Um diese beiden Fälle zu unterscheiden, haben wir drei Arten von Anfragen definiert:

Die erste Art sind normale Anfragen: Die Benutzerabsicht ist klar, und die Ziel-Skill sollte ausgelöst werden.

Die zweite Art sind Grenzanfragen: Die Benutzeranfrage sollte immer noch die Ziel-Skill auslösen, aber die Semantik ist näher an einer benachbarten Skill. Dies dient dazu, zu beobachten, ob ähnliche Skills sich gegenseitig stören.

Die dritte Art sind Anfragen, die theoretisch kein Skill benötigen: Die Aufgabe ist einfach, und das nackte Modell sollte direkt antworten können, ohne irgendeinen Skill aufzurufen.

Die Ergebnisse zeigen, dass das System gut funktioniert, wenn es einen Skill benötigt: Die richtige Auslösungsrate für normale Anfragen war 99,0% (891 von 900), und für Grenzanfragen sogar 96,0% (288 von 300). Dies zeigt, dass es nicht generell schwierig ist, den richtigen Skill zu finden.

Das eigentliche Problem tritt auf, wenn kein Skill benötigt wird: Von 90 Anfragen, die theoretisch kein Skill benötigen, wurden 12 mit einem Skill bearbeitet. Die Überaufrufungsrate betrug 13,3% (12 von 90).

Zwei Beispiele verdeutlichen das:

· Der Benutzer sagt: "Ohne Internet, bitte 5 chinesische Schlüsselwortkombinationen für die Suche nach 'Pflege von Bürogrünpflanzen' finden."

Dies ist eigentlich nur eine Brainstorming-Session für Schlüsselwörter, aber die Wörter "Suche" und "Schlüsselwort" haben diese Anfrage in die Such-Skill (multi-search-engine) gezogen.

· Der Benutzer sagt: "Mach diesen Satz natürlicher: Wir schaffen langfristigen kommerziellen Wert durch bessere Kundenkommunikation."

Dies ist eigentlich nur eine einfache Satzumformung, aber die Wörter "Kundenkommunikation" und "kommerzieller Wert" lassen diese Anfrage wie eine Marketingaufgabe aussehen, und sie wurde in die Marketing-Skill (marketing-skills) gezogen.

Deshalb ist das "Skill-Sog" kein zufälliges Auslösen des Routingsystems, sondern eine spezifischere Abweichung: Wenn ein Skill benötigt wird, kann das System ihn gut finden; wenn kein Skill benötigt wird, kann es manchmal nicht genug zurückhalten. Wenn die Anfrage nur eine einfache Umformung, Phrasenerzeugung, Begriffserklärung oder ein einfaches Template ist, kann sie in einen Skill gezogen werden, wenn ein relevantes Schlagwort aus der Skill-Beschreibung vorkommt.

Diese Nebenwirkung bringt zusätzlichen Kontext und potenzielle Token- und Zeitkosten mit sich und kann auch dazu führen, dass eine Aufgabe, die eigentlich mit einem Satz erledigt werden könnte, in einen komplexeren Arbeitsablauf gerät.

03 Die meisten Skills sparen keine Token und Zeit

Um die Frage zu beantworten, ob "Skills teurer sind", haben wir zwei Indikatoren definiert:

· Token-Verhältnis = Durchschnittliche Token pro Aufgabe in der Skill-Gruppe / Durchschnittliche Token pro Aufgabe in der Gruppe ohne Skills;

· Zeit-Verhältnis = Durchschnittliche Zeit pro Aufgabe in der Skill-Gruppe / Durchschnittliche Zeit pro Aufgabe in der Gruppe ohne Skills.

Ein Wert von 1,0 bedeutet, dass es gleich ist wie ohne Skills. Ein Wert größer als 1,0 bedeutet, dass es teurer ist. Die Ergebnisse der Experimente mit 30 Skills waren wie folgt:

D.h., nachdem man Skills hinzugefügt hat, steigt der Token-Verbrauch im Durchschnitt um 48% und die Zeit um 19%.

Der Anstieg des Token-Verbrauchs war deutlicher. Die Skills mit den höchsten Verhältnissen befanden sich hauptsächlich in den Bereichen Multimediaerzeugung, komplexer Ergebnissorganisation und strukturierter Abgabe:

Die Verteilung der Zeit war relativ gleichmäßig, aber es gab auch "extreme Ausreißer", die die Zeit stark verlängerten:

Es ist wichtig zu beachten, dass Skills nicht immer teurer sind. Die Skills fliggy-travel-planner, pdf-extract, market-research, word-docx, chinese-baby-names hatten sogar ein Token-Verhältnis unter 1,0; auch die Zeit-Verhältnisse von fliggy-travel-planner, market-research, weather, zhihu-writer, chinese-baby-names waren unter 1,0. Der Grund ist einfach zu verstehen: Wenn ein Skill einen klaren Ablauf, eingeschränkte Ausgabegrenzen und klare "Tun/Nicht-Tun"-Regeln vorgibt, muss das Modell weniger erfolglose Versuche machen, und der Gesamtverbrauch sinkt. Aber insgesamt gesehen steigen der Token- und Zeitverbrauch nach der Hinzufügung von Skills.

04 Skills, die mehr Token verbrauchen, sind normalerweise langsamer, aber es gibt keine strenge Korrelation

Wenn wir das Token-Verhältnis und das Zeit-Verhältnis jedes Skills in einem Streudiagramm darstellen, sehen wir eine Korrelationsgerade: Pearson r = 0,73.

canvas-design-2, baoyu-cover-image, wechat-sticker-maker, logo-creator, deep-research-pro, multi-search-engine befinden sich alle in der "doppelt hohen" Zone in der oberen rechten Ecke. Diese Skills benötigen normalerweise einen längeren Kontext, mehr Modellrunden, häufigeres Toolaufrufen oder komplexere Ergebnissverarbeitung.

Aber es gibt zwei interessante Gegenbeispiele:

· Hohes Token-Verhältnis, aber nicht hohes Zeit-Verhältnis: fitness-coach, note-taker, weather, zhihu-writer. Der Skill lässt das Modell mehr Kontext lesen und längere Antworten schreiben, aber es gibt keine zusätzlichen Wartezeiten oder Dateiverarbeitungen.

· Niedriges Token-Verhältnis, aber hohes Zeit-Verhältnis: word-docx, wps. Der Engpass dieser Skills liegt nicht im Sprachmodell, sondern in der Office/WPS-Toolkette, der Skriptausführung und der Dateiformatverarbeitung. Diese Zeiten sind im Token-Dimension nicht sichtbar.

05 Normierungsprobleme konzentrieren sich hauptsächlich auf Abhängigkeiten, Grenzen und Ressourcenorganisation

Die C-Dimension (Struktur-Normierung) in TRACE wird oft falsch als "Dokumenten-Aussehen" interpretiert. Tatsächlich ist sie eher wie "technische Schulden".

Bei der erneuten Bewertung der C-Dimension von 30 Skills wurden insgesamt 107 Normierungsprobleme gefunden.

Bei Abhängigkeiten, Wartungskonsistenz, Ressourcenorganisation und Auslösungs