Microsoft hat am 15. Juli ein stabiles Agent Skills Framework für Python veröffentlicht. Es ermöglicht Entwicklern, Fähigkeiten erst dann abzurufen, wenn ein LLM-gesteuerter Agent sie tatsächlich benötigt. Durch den Austausch eines einzelnen, stetig wachsenden System-Prompts gegen ein bedarfsgerechtes Laden von Skills reduziert dieser Ansatz die Prompt-Größe, senkt die Token-Kosten und hält die Argumentation des Agenten klarer.

Warum Prompts anschwellen und warum das wichtig ist

LLM-Agenten verlassen sich auf einen „System-Prompt“, der Richtlinien, Runbooks und Referenzmaterial bündelt, das das Modell bei jedem Durchgang sehen sollte. Fügt man eine Handvoll Richtliniendokumente hinzu, bläht sich der Prompt auf mehrere tausend Token auf. Größere Prompts erhöhen die Inferenzkosten – für jeden vom Modell verarbeiteten Token wird abgerechnet – und sie verwässern das Instruktionssignal, was die Ausgaben des Agenten unpräziser macht. Bei der Vorfallstriage oder Compliance-Prüfungen kann ein unklarer Prompt einen hilfreichen Assistenten in eine Quelle für Fehlinformationen verwandeln.

Das Agent Skills Pattern: Progressive Disclosure

Das neue Framework ersetzt den monolithischen Prompt durch einen vierstufigen Workflow:

  1. Skill ankündigen (Advertise the skill) – ein leichtgewichtiger Metadaten-Eintrag, der der Routing-Ebene den Namen des Skills mitteilt.
  2. Instruktionen laden (Load instructions) – eine prägnante Beschreibung, die der Agent liest, um zu entscheiden, ob der Skill zur Anfrage passt.
  3. Ressourcen lesen (Read resources) – optionale Richtlinien- oder Referenzdateien, die erst abgerufen werden, nachdem der Agent den Skill ausgewählt hat.
  4. Skripte ausführen (Run scripts) – Codeausführung, die die Aktion durchführt, geschützt durch eine explizite Genehmigung.

Nur die kurze SKILL.md-Datei befindet sich im Kern-Prompt. Alle größeren Dokumente und Skripte liegen in einem dateibasierten Skill-Paket, das die Laufzeitumgebung bei Bedarf abruft. Die Verzeichnisstruktur bleibt einfach:

  • SKILL.md – kurze, für Menschen lesbare Beschreibung.
  • references/ – Richtlinien- oder Leitfaden-Dateien.
  • scripts/ – ausführbarer Code.

Da der Agent den vollständigen Inhalt von references/ oder scripts/ erst sieht, wenn er entschieden hat, dass der Skill der richtige ist, bleibt der Haupt-Prompt schlank, egal wie viele Skills Sie registrieren.

In das Framework integrierte Sicherheitsvorkehrungen

Das Framework geht davon aus, dass das Laden eines Skills riskant sein kann, und erzwingt Regeln, die Entwickler befolgen müssen:

  • Ankündigung des Skill-Namens (Skill name advertisement) – automatisch, wird nur für das Routing verwendet.
  • Laden von Instruktionen (Instruction loading) – automatisch für kuratierte Listen; nicht geprüfte Instruktionen können unbeabsichtigt das Verhalten verändern.
  • Lesen von Richtlinien (Policy reading) – automatisch, wenn die Daten nicht sensibel sind; halten Sie sensible Materialien hinter zusätzlichen Zugriffskontrollen.
  • Skriptausführung (Script execution) – erfordert immer eine explizite Genehmigung. Ein Skript führt den Agenten von einer „Empfehlung“ zur „Aktion“, daher muss eine menschliche Prüfung oder eine Richtlinienprüfung eingreifen.
  • Externe Systemaufrufe (External system calls) – müssen über separate Tools mit eingeschränkten Berechtigungen erfolgen; ein Skill selbst ist kein Autorisierungsmechanismus.

Diese Regeln bewegen Entwickler dazu, mit schreibgeschützten Workflows zu beginnen – wie Vorfallstriage, Richtlinienabfrage oder Statusabfragen –, bevor sie schreiborientierte Aktionen wie Datenbankaktualisierungen oder Code-Deployments versuchen.

Operative Hygiene: Logging und Versionierung

Wenn ein Skill ausgeführt wird, fördert das Framework (und viele Implementierungen schreiben es vor) das Logging von:

  • Die ursprüngliche Anfrage und die gewählte Skill-ID.
  • Die verwendete Version des Skill-Pakets.
  • Ob der Agent nur die Beschreibung geladen oder auch eine Ressourcendatei abgerufen hat.
  • Die Entscheidung zur Genehmigung der Skriptausführung.
  • Alle übergebenen Tool-Argumente und die zurückgegebenen Ergebnisse.

Wenn der Agent den falschen Skill auswählt, machen Sie die Fehlwahl zu einem Testfall. Dies schafft eine Regressionsprüfung, bevor der Skill in die Produktion geht.

Behandeln Sie jeden Skill als eine versionierte Abhängigkeit mit einer klaren Abgrenzung und nicht als einen losen Ordner voller Prompts. Die Versionierung ermöglicht es Ihnen, ein fehlerhaftes Skript zurückzurollen, ohne die restliche Wissensbasis des Agenten zu stören.

Erste Schritte: Eine pragmatische Checkliste

  1. Wählen Sie einen schreibgeschützten Workflow – z. B. „Suche nach den neuesten Richtlinien für Sicherheitsvorfälle“.
  2. Paketieren Sie Instruktionen und Skripte separat – halten Sie SKILL.md kurz; speichern Sie umfangreiche Richtlinien-Dateien in references/.
  3. Kuratieren Sie einen Katalog – führen Sie eine Liste genehmigter Skills und erzwingen Sie eine obligatorische Genehmigung für jedes Skript.
  4. Legen Sie Sandbox-Limits fest – definieren Sie CPU-, Speicher- und Netzwerkeinschränkungen für die Skriptausführung; protokollieren Sie jeden Durchlauf.
  5. Benchmark gegen den alten Mega-Prompt – vergleichen Sie Token-Verbrauch, Latenz und Erfolgsraten, um die Kosteneinsparungen zu bestätigen.

Was als Nächstes zu beachten ist

Microsofts Release ist derzeit eine stabile Python-Implementierung.

Fazit

Agent Skills ermöglichen es LLM-gesteuerten Assistenten, leichtgewichtig zu bleiben und dennoch auf eine wachsende Bibliothek von Richtlinien und Skripten zuzugreifen. Indem nur die Beschreibung vorab geladen und ressourcenintensive Inhalte erst bei Bedarf abgerufen werden, bleiben die Prompts kurz, die Inferenzkosten sinken und der Denkprozess des Agenten bleibt fokussiert.