Stellen Sie sich vor, Sie bringen einem superintelligenten Roboter-Assistenten bei, wie er Ihre Hausaufgaben erledigt, Ihren Code repariert oder eine Geschichte schreibt. Sie haben eine riesige Bibliothek von „Bedienungsanleitungen“ (genannt Skills), die dem Roboter genau erklären, wie er bestimmte Aufgaben bewältigt, wie zum Beispiel „eine Website bereitstellen“ oder „eine Code-Änderung überprüfen“. Das Problem ist, dass der Roboter nur eine sehr begrenzte Menge an Aufmerksamkeit gleichzeitig aufbringen kann. Stellen Sie sich diese Aufmerksamkeit wie eine winzige Schreibtischoberfläche vor. Wenn Sie versuchen, zu Beginn des Tages alle Bedienungsanleitungen auf diesen Schreibtisch zu legen, wird der Schreibtisch überladen, der Roboter wird verwirrt und er vergisst die wichtigsten Anweisungen, weil sie unter einem Stapel von Papieren begraben liegen, die er gerade gar nicht braucht. Dies ist die Kernherausforderung von KI-Agenten: Wie gibt man ihnen Zugriff auf Tausende nützlicher Werkzeuge, ohne ihren winzigen mentalen Arbeitsraum zu überfordern?

Dieses Paper mit dem Titel @skills: Attention Is All You Have befasst sich mit einem spezifischen Kopfschmerz in der Welt der KI-Agenten. Derzeit ist der einzige Weg, einem Agenten einen neuen Skill zu geben, ihn zu „installieren“. Das Installieren ist so, als würde man einen Klebezettel mit der Beschreibung des Skills auf die Stirn des Roboters kleben. Dieser Zettel bleibt dort für immer und nimmt Platz auf seinem „Schreibtisch“ (dem System-Prompt) ein, jedes Mal, wenn er mit Ihnen spricht, selbst wenn Sie nie nach diesem Skill fragen. Die Autoren argumenten, dass dies eine schreckliche Verschwendung der begrenzten Aufmerksamkeit des Roboters ist. Sie schlagen ein neues, offenes Protokoll namens @skills vor, das das Spiel verändert: Anstatt Notizen auf die Stirn zu kleben, zeigen Sie einfach auf die Bedienungsanleitung, wenn Sie sie brauchen.

Das Problem: Die „Klebe-Zettel“-Falle

Die Autoren beobachteten, dass es bereits über 56.804 verschiedene Skills in der öffentlichen Welt gibt, aber das aktuelle System ist kaputt. Da jeder installierte Skill einen permanenten Platz im Aufmerksamkeitsbudget des Roboters beansprucht, und dieses Budget winzig ist (die Autoren schätzen weniger als 100 zuverlässige Plätze pro Agent), können die meisten dieser Skills niemals genutzt werden. Es ist, als hätte man eine Bibliothek von 56.000 Büchern, aber man dürfte nur drei davon auf dem Nachttisch liegen lassen. Wenn man ein viertes lesen möchte, muss man eines der drei wegwerfen.

Schlimmer noch: Das aktuelle System erzwingt einen „Einheitsansatz“. Um einen Skill zu nutzen, muss man ihn installieren, was bedeutet, dass seine Beschreibung ständig im Geist des Roboters präsent ist. Dies führt zu drei großen Problemen:

1. Die Steuer: Jedes Mal, wenn der Roboter spricht, muss er auf jede einzelne installierte Skill-Beschreibung „achten“, selbst wenn sie irrelevant ist. Das verschwendet Energie und verlangsamt das Denken.
2. Die Lotterie: Der Roboter muss raten, welchen Skill er verwenden soll, basierend auf diesen winzigen Beschreibungen. Wenn er falsch rät, bleibt der Skill stumm, und der Nutzer erfährt nie, dass er überhaupt existierte.
3. Die Junk-Schublade: Da das Installieren der einzige Weg ist, einen Skill zu behalten, enden die Menschen mit einem chaotischen Haufen von Skills, die sie einmal ausprobiert und dann vergessen haben, was den Geist des Roboters auf ewig verstopft.

Die Lösung: Das „Magische Zeiger“-Protokoll

Das Paper schlägt @skills vor, eine neue Art, diese Anweisungen zu handhaben, die drei Dinge trennt, die zuvor fest miteinander verknüpft waren: Inhalt (die Anweisungen), Persistenz (das Behalten einer Kopie) und Triggerung (das automatische Auslösen).

Die Autoren führen ein einfaches, dreistufiges System ein, mit dem man das richtige Werkzeug für die jeweilige Aufgabe wählen kann:

• Stufe 1: Die Referenz (Der „Just-in-Time“-Zeiger)
  Dies ist für den „Long Tail“ der Skills gedacht, die man vielleicht nur ein oder zweimal benötigt. Anstatt sie zu installieren, gibt man einfach @skills:<pfad> ein, wenn man sie braucht. Es ist, als würde man einen Bibliothekar bitten, ein bestimmtes Buch aus dem Regal zu holen, nur wenn man danach fragt. Das Buch erscheint direkt neben der Frage, der Roboter lift es, erledigt die Arbeit und dann verschwindet das Buch wieder. Es kostet null permanenten Aufmerksamkeitsraum. Dies ermöglicht den Zugriff auf alle 56.000+ Skills, ohne das Gehirn des Roboters zu verstopfen.

• Stufe 2: Die gespeicherte Kopie (Der „Vendored“-Ordner)
  Manchmal möchte man eine Kopie eines Skills in seinem eigenen Projektordner behalten (wie einen spezifischen Workflow eines Teams), damit man ihn bearbeiten und besitzen kann. Mit @skills können Sie einen Skill in den .atskills/-Ordner Ihres Projekts „speichern“. Das ist wie das Fotokopieren eines Rezepts und das Ablegen in einem eigenen Kochbuch. Er bleibt in Ihrem Projekt, liegt aber trotzdem nicht auf der Stirn des Roboters, es sei denn, Sie fordern ihn explizit an. Er ist für Sie da, um gefunden und genutzt zu werden, aber er verschwendet die Aufmerksamkeit des Roboters nicht, bis Sie ihn benötigen.

• Stufe 3: Der installierte Skill (Die „Auto-Trigger“-Ausnahme)
  Dies ist die einzige Stufe, die noch die alte „Klebe-Zettel“-Methode verwendet, aber sie ist den absoluten Essentials vorbehalten, die automatisch feuern müssen, ohne dass man darum bittet, wie etwa Sicherheitsregeln oder Formatierungsprüfungen. Selbst hier ist das Protokoll intelligenter: Nur der winzige Titel und die Beschreibung (der „Frontmatter“) bleiben auf der Stirn des Roboters. Der Rest der Anweisungen wird erst geladen, wenn der Roboter sie tatsächlich benötigt.

Wie es in der Praxis funktioniert

Das Paper legt nahe, dass dieses Protokoll den chaotischen „Installiere alles“-Ansatz in ein sauberes, dateibasiertes System verwandelt.

• Keine „Installieren“-Buttons mehr: Man installiert keinen Skill; man referenziert ihn einfach über seinen Pfad.
• Keine versteckten Ordner mehr: Skills leben in der Dateistruktur Ihres Projekts (wie .atskills/), sodass Sie sie sehen, bearbeiten und Änderungen mit Git tracken können, genau wie Code.
• Keine „Update“-Kopfschmerzen mehr: Wenn Sie möchten, dass ein Skill aktuell bleibt, „folgen“ Sie ihm einfach (eine Zeile in einer Konfigurationsdatei). Wenn Sie ihn zu Ihrem eigenen machen wollen, „speichern“ Sie ihn (eine Kopie in Ihrem Ordner).

Die Autoren haben auch einen kostenlosen „Hub“ (eine Website) gebaut, um Menschen bei der Suche nach diesen Skills zu helfen, aber das Protokoll ist so konzipiert, dass man den Hub nicht benötigen muss. Man kann direkt auf Skills auf GitHub oder dem lokalen Computer verweisen. Der Hub ist lediglich eine Suchmaschine, kein Gatekeeper.

Was das Paper tatsächlich herausgefunden hat

Das Paper stellt nicht nur eine Theorie auf; es weist auf reale Daten hin. Die Autoren fanden heraus, dass das aktuelle „Nur-Installieren“-Modell strukturell defekt ist, weil es jeden Skill dazu zwingt, um eine knappe Ressource (Aufmerksamkeit) zu konkurrieren, die er oft gar nicht benötigt. Durch die Trennung der Notwendigkeit, einen Skill zu haben, von der Notwendigkeit, einen Skill zu erinnern, ermöglicht das @skills-Protokoll es Agenten, den Long Tail von 56.000+ Skills zu nutzen, ohne ihr Gehirn zu überlasten.

Die Autoren sind zuversichtlich, dass dieser Ansatz das „Aufmerksamkeitsbudget“-Problem löst, merken aber an, dass die genaue Anzahl der zuverlässigen „Auto-Trigger“-Slots (das Limit der Stufe 3) eine Schätzung ist, die auf bestehender Forschung darüber basiert, wie KI-Modelle in langen Gesprächen den Fokus verlieren. Sie schlagen vor, dass während das aktuelle System eine „Junk-Schublade“ ist, in der wichtige Skills verloren gehen, das neue dreistufige System jedem Skill ein eigenes Zuhause gibt: Entweder in der Cloud (Stufe 1), in Ihrem Projekt (Stufe 2) oder als kritische Regel (Stufe 3).

Kurz gesagt: Das Paper argumentt, dass wir aufhören sollten, KI-Skills wie schwere Möbel zu behandeln, die wir an die Wand kleben müssen, und stat beginnen sollten, sie wie Bücher zu behandeln, die wir jederzeit aus dem Regal ziehen können. Das Ergebnis ist ein Agent, der leichter, schneller und in der Lage ist, ein viel breiteres Spektrum an Wissen zu nutzen, ohne überwältigt zu werden.