Kapitel 22: Agent Skills – Modulares Expertenwissen

In Kapitel 8 haben wir das Problem der Tool-Überladung ("Tool Fatigue") besprochen. Eine der fortschrittlichsten Lösungen hierfür, die in Systemen wie dem Gemini CLI oder Claude zum Einsatz kommt, sind Agent Skills.

Von Intents zu Skills: Die Evolution der Steuerung

Wer bereits Erfahrung mit LLM-Prompts hat, kennt das Konzept der Intents (Absichten). Man weist das Modell an: "Wenn der User X will (Intent), dann antworte mit Y."

Agent Skills sind die logische Weiterentwicklung dieses Musters:

  • Der Intent als Trigger: Das Modell erkennt den Wunsch des Nutzers (z. B. "Prüfe die Sicherheit meines Codes").
  • Der Skill als Antwort: Anstatt nur eine Antwort zu generieren, erkennt das Modell, dass es für diesen speziellen Intent einen Skill (den "Security Expert") besitzt, und aktiviert diesen.

Während ein Intent in einem klassischen Prompt oft nur zu einer Textantwort führt, führt er im agentischen Kontext zur Selbst-Erweiterung des Modells. Es lädt sich aktiv die Werkzeuge und Regeln nach, die es zur Erfüllung dieses spezifischen Intents benötigt.

Trigger-Strategien: Wie wird ein Skill aktiviert?

Es gibt drei Wege, wie ein Agent Skill in den Kontext gelangt. In modernen Systemen wie dem Gemini CLI verschmelzen diese Ansätze oft:

  1. Expliziter Trigger (Slash-Commands): Der Benutzer gibt die Richtung vor (z. B. /security). Der Client weiß sofort: "Lade die Security-Anweisungen". Dies spart dem Modell die Entscheidungslast, erfordert aber einen informierten Nutzer.

  2. Klassifizierungs-Schritt (Router-Chain): Ein vorgeschaltetes, kleineres Modell analysiert die User-Anfrage und entscheidet: "Das ist ein Forschungs-Intent". Das System injiziert daraufhin den passenden Skill, noch bevor das Haupt-Modell die Anfrage sieht.

  3. Agentisches Tool-Calling (Autonom): Das Haupt-Modell hat das Tool activate_skill. Während es die Anfrage liest, entscheidet es selbst: "Um das zu beantworten, brauche ich mein Expertenwissen über Kryptographie." Es ruft das Tool auf und erweitert seinen eigenen Kontext "on-the-fly". Dies ist die flexibelste, aber auch anspruchsvollste Methode.

Architektur-Muster der Skill-Auswahl

Wie die Entscheidung für einen Skill fällt, hängt vom gewählten Architektur-Muster ab:

A. Der zentrale Orchestrator (Top-Down)

Ein primärer Agent (der "Chef") hat Zugriff auf die Liste aller Skills. Seine einzige Aufgabe ist es, die Anfrage zu analysieren, den richtigen Skill zu wählen und die Aufgabe an einen spezialisierten Sub-Agenten zu delegieren.

  • Vorteil: Sehr stabil und kontrollierbar.
  • Nachteil: Der Orchestrator selbst verbraucht permanent Token für die Verwaltung.

B. Das autonome Modell (Flat-Hierarchy)

Es gibt keinen "Chef". Das Modell, mit dem der User spricht, hat einfach das Werkzeug activate_skill. Es entscheidet situativ, ob es sich selbst zum Experten "upgraden" muss.

  • Vorteil: Extrem schnell und flexibel.
  • Nachteil: Gefahr von "Looping" (Modell lädt ständig neue Skills, ohne die Aufgabe zu lösen).

C. Kontextbasierte Vorauswahl (Umgebungs-Trigger)

Das System erkennt den Kontext außerhalb des Chats.

  • Beispiel: Wenn das Gemini CLI erkennt, dass im aktuellen Verzeichnis eine go.mod liegt, lädt es den "Go-Expert"-Skill automatisch in die Discovery-Liste vor.
  • Vorteil: Erhöht die Trefferquote massiv, da irrelevante Skills (z. B. Python) gar nicht erst zur Auswahl stehen.

Der Erfolgsfaktor: Metadaten-Qualität (Discovery)

Damit ein Agent den richtigen Skill auswählt, muss die Beschreibung im YAML-Header perfekt sein. Ein häufiger Fehler ist eine zu vage Beschreibung.

  • Schlecht: "Hilft bei Go-Programmierung."
  • Gut: "Experte für Go-Backend-Entwicklung mit dem Gin-Framework. Spezialisiert auf API-Design, JWT-Authentifizierung und SQL-Optimierung."

Je präziser die Schlagworte (Keywords) im Discovery-Teil sind, desto sicherer trifft das Modell die Wahl – egal ob via Tool-Call oder Router-Chain.

Praxis-Beispiele

1. Der Orchestrator-Prompt (System-Ebene)

Dieser Prompt wird dem "Chef"-Modell mitgegeben, um die Auswahl zu steuern:

Du bist ein strategischer Koordinator. Deine Aufgabe ist es, Nutzeranfragen zu analysieren 
und den am besten geeigneten Experten-Skill zu aktivieren.

Verfügbare Skills:
- go-expert: Spezialist für Go-Backend und Gin-Framework.
- security-audit: Fokus auf OWASP, SQLi und Code-Sicherheit.
- docker-ops: Experte für Containerisierung und Deployment.

Regeln:
1. Wenn eine Anfrage mehrdeutig ist, frage den Nutzer nach Details, bevor du einen Skill lädst.
2. Nutze das Tool `activate_skill(name)`, um den Experten-Modus zu starten.
3. Sobald ein Skill geladen ist, trittst du in den Hintergrund und lässt den Experten arbeiten.

2. Anatomie einer `SKILL.md`

So sieht eine Skill-Datei aus, die vom System indexiert und später nachgeladen wird:

---
id: "go-expert"
description: "Experte für Go-Backend-Entwicklung (Gin, Gorm, Clean Architecture)."
keywords: ["go", "golang", "backend", "api", "gin", "database"]
---

# 🛠 Go Expert Skill Instructions

Du bist ein Senior Go-Entwickler. Befolge bei jeder Code-Generierung diese Regeln (unter Nutzung gängiger Frameworks wie Gin für APIs und Gorm als ORM):
1. Nutze immer `set -euo pipefail` in begleitenden Shell-Skripten.
2. Fehlerhandling hat oberste Priorität: Prüfe jedes `err != nil`.
3. Verwende für APIs ausschließlich das Gin-Framework.
4. Dokumentiere öffentliche Funktionen nach Go-Standard.

Verfügbare Spezial-Tools für diesen Skill:
- `analyze_go_deps`: Prüft `go.mod` auf veraltete Pakete.
- `generate_gin_route`: Erstellt Boilerplate für Endpunkte.

Der technische Workflow

Der Einsatz von Agent Skills folgt einem zweistufigen Prozess:

1. Die Discovery-Phase (Indexieren)

Anstatt den gesamten Inhalt aller Skills in den Prompt zu werfen (was das Kontextfenster sprengt), liest dein Go-Backend beim Start nur die YAML-Frontmatter (Name und Description) jeder SKILL.md ein. Du registrierst diese Skills als Liste im System-Prompt oder als verfügbare "Tools".

2. Die Aktivierung (On-Demand Loading)

Anstatt den User den Skill manuell wählen zu lassen, gibst du dem LLM ein Tool (z. B. activate_skill), mit dem es den Skill selbst "nachladen" kann, wenn die Beschreibung des Skills zur Nutzeranfrage passt. Der vollständige Inhalt der SKILL.md wird dann als neue Nachricht in den Chat-Verlauf (Conversation History) "injiziert".

Fazit

Agent Skills verwandeln ein LLM von einem "Generalisten mit zu vielen Werkzeugen" in einen koordinierenden Experten, der sich genau dann das richtige Wissen aneignet, wenn es benötigt wird. Für komplexe MCP-Ökosysteme ist dieses Muster unverzichtbar, um hohe Qualität bei niedriger Latenz und geringen Kosten zu gewährleisten.

← Kapitel 21: Programmiersprachen | Inhaltsverzeichnis ltsverzeichnis](README.md)