🔧 Was ist ein Skill?
Im Kontext von AI-Agenten ist ein skill (auch genannt ein tool or function) ein verpacktes, wiederverwendbares Feature, das ein LLM aufrufen kann, um mit der Welt außerhalb seines Kontextfensters zu interagieren. Skills überbrücken die Lücke zwischen Sprachverständnis und realer Handlung.
Jeder Skill hat vier Komponenten:
- Name — eine eindeutige Kennung, die das Modell verwendet, um auf den Skill zu verweisen (z. B.,
web_search) - Description — Fließtext in natürlicher Sprache, der erklärt, was der Skill tut und wann er verwendet werden sollte; das LLM liest dies, um zu entscheiden, wann der Skill aufzurufen ist
- Eingabeschema — eine strukturierte Definition der Argumente (JSON Schema); das Modell füllt diese basierend auf der Aufgabe aus
- Implementation — der eigentliche Code, der läuft: ein API-Aufruf, Datenbankabfrage, Shell-Befehl oder eine andere Operation
Beispiel: A get_weather Skill hat die Beschreibung "Holt aktuelles Wetter für eine Stadt", akzeptiert { "city": "string" } als Eingabe und ruft eine Wetter-API auf. Das LLM sieht niemals den API-Schlüssel oder den HTTP-Aufruf — es erhält lediglich das Ergebnis als Text zurück.
⚙️ Wie Tool-Aufrufe funktionieren
Wenn ein Agent Zugriff auf Skills hat, ruft das LLM sie nicht direkt auf — es requests einen Aufruf, indem es eine strukturierte Ausgabe erzeugt. Die Runtime (dein Anwendungscode) führt den tatsächlichen Aufruf aus und gibt das Ergebnis zurück. Hier ist der vollständige Zyklus:
- Tool-Registrierung — Dein Code sendet dem Modell eine Liste verfügbarer Skills mit ihren Beschreibungen und Schemata
- Modell-Reasoning — Das LLM liest die Aufgabe und die verfügbaren Tools, entscheidet, welches Tool aufzurufen ist und mit welchen Argumenten
- Tool-Aufruf-Anfrage — Das Modell gibt eine strukturierte "tool call"-Nachricht aus (z. B.,
{ "tool": "web_search", "args": { "query": "current Gemini models" } }) - Execution — Dein Runtime-Code ruft die tatsächliche Funktion, API oder den Dienst auf
- Resultatinjektion — Das Ergebnis wird wieder zum Gesprächskontext hinzugefügt
- Fortgesetztes Reasoning — Das Modell liest das Ergebnis und ruft entweder ein weiteres Tool auf, stellt eine Folgefrage oder erzeugt die finale Antwort
Diese Schleife kann sich in einer einzigen Runde viele Male wiederholen. Eine komplexe agentische Aufgabe könnte 10–20 Tools hintereinander aufrufen, bevor eine endgültige Antwort erzeugt wird.
📊 Skills vs Plugins vs MCP Servers
Die Terminologie hat sich schnell entwickelt. So stehen die Konzepte historisch zueinander:
| Era | Name | Wie es funktionierte | Status |
|---|---|---|---|
| 2023 | ChatGPT Plugins | Vom Benutzer installierbare Erweiterungen mit einer OpenAPI-Spezifikation; ChatGPT rief sie via HTTP auf | Veraltet (ersetzt durch GPTs + Tools) |
| 2023 | OpenAI Function Calling | API-Ebene JSON Schema-Definitionen; das Modell erzeugt einen strukturierten Funktionsaufruf, dein Code führt ihn aus | Aktiv — umbenannt in "tool use" |
| 2023– | Tool Use / Skills | Gleich wie Function Calling; Anthropic prägte den Begriff "tool use", andere nutzen "skills" oder "functions" | Aktiv — aktueller Standard |
| 2024– | MCP Servers | Standardisiertes Protokoll (Anthropic, Dez 2024) zum Verpacken und Verteilen von Tool-Servern; jeder MCP-Client kann sich mit jedem MCP-Server verbinden | Aktiv — wachsendes Ökosystem |
Wesentlicher Unterschied: Traditionelles Tool Use wird inline in deinem Anwendungscode definiert. MCP-Server sind eigenständige Prozesse, die Tools über ein standardisiertes Protokoll bereitstellen — wodurch sie wiederverwendbar für verschiedene AI-Clients (Claude Desktop, Cursor, VS Code, benutzerdefinierte Agents) werden. Mehr dazu: Was ist MCP.
🗂️ Tool-Kategorien & Risikostufen
Nicht alle Tools bergen dasselbe Risiko. Eine Gruppierung nach Risikostufen hilft, dieAktionsraumund wo menschliche Checkpoints hinzugefügt werden sollten:
| Category | Examples | Risk | Recommendation |
|---|---|---|---|
| Read-only | web_search, read_file, get_weather, list_dir | Low | Autonom zulassen; alle Aufrufe protokollieren |
| Schreiben (lokal) | write_file, create_dir, edit_code | Medium | Beschränke auf ein sandboxed Arbeitsverzeichnis |
| Netzwerk / Extern | send_email, post_to_slack, call_api | Mittel–Hoch | HITL-Freigabe für irreversible Sendungen |
| OS / Shell | run_command, execute_script, install_package | High | Auf containerisierte Umgebung beschränken; HITL erforderlich |
| Destructive | delete_file, drop_table, revoke_access | Critical | Immer explizite menschliche Bestätigung verlangen |
🏗️ Anatomie eines guten Skills
Die wichtigste Designentscheidung für einen Skill ist seine description. Das LLM liest Beschreibungen, um zu entscheiden, welches Tool aufzurufen ist — eine schlecht geschriebene Beschreibung führt zu falscher Toolauswahl, gescheiterten Aufrufen oder mehrdeutigen Argumenten.
Was eine Beschreibung effektiv macht
- Sei eindeutig, wann es verwendet werden soll — "Verwende dieses Tool, wenn der Nutzer nach Echtzeitdaten oder aktuellen Ereignissen fragt" ist besser als "Durchsucht das Web"
- Gib an, was es NICHT tut — "Gibt keine historischen Daten zurück, die älter als 30 Tage sind"
- Beschreibe das Ausgabeformat — "Gibt ein JSON-Array von Suchergebnissen mit title, url und snippet Feldern zurück"
- Halte es unter 200 Wörtern — Beschreibungen, die länger als ~200 Tokens sind, können die Aufmerksamkeit des Modells überwältigen, wenn viele Tools registriert sind
Prinzipien des Schema-Designs
- Erforderlich vs optional — Markiere Felder nur als erforderlich, wenn es wirklich nötig ist; optionale Felder mit Defaults reduzieren Modellfehler
- Verwende Enums für eingeschränkte Werte —
"format": {"enum": ["json", "markdown", "text"]}verhindert halluzinierte Werte - Bevorzuge idempotente Tools — Tools, die sicher wiederholt werden können (Lesevorgänge, Lookups), sind sicherer als einmalige Aktionen (Senden, Löschen)
- Gib strukturierte Daten zurück — JSON-Antworten sind für das Modell leichter zu verarbeiten als unstrukturierte Textblöcke
💡 Praxisbeispiele
| Skill-Name | Was es tut | Wichtige Argumente | Risk |
|---|---|---|---|
web_search | Frage eine Suchmaschine ab und gib die Top-Ergebnisse zurück | query: string, num_results?: number | Low |
read_file | Lese eine Datei aus dem Workspace-Verzeichnis | path: string, offset?: number, limit?: number | Low |
write_file | Erstelle oder überschreibe eine Datei | path: string, content: string | Medium |
run_tests | Führe die Test-Suite des Projekts aus und gib die Ergebnisse zurück | filter?: string | Medium |
browser_screenshot | Navigiere zu einer URL und gib einen Screenshot zurück | url: string | Medium |
send_email | Sende eine E-Mail an einen oder mehrere Empfänger | to: string[], subject: string, body: string | Hoch — immer HITL |
run_shell | Führe einen beliebigen Shell-Befehl aus | command: string, cwd?: string | Hoch — Sandbox erforderlich |
✅ Beste Vorgehensweisen
Minimale Berechtigungen
Gib jedem Agent nur die Tools, die er für seine spezifische Aufgabe benötigt. Ein Agent, der FAQ beantwortet, braucht nicht write_file or send_email. Je kleiner der Aktionsraum, desto kleiner der Explosionsradius, falls der Agent manipuliert wird. Siehe:Exzessive Agency.
Prüfe alle Tool-Aufrufe
Protokolliere jeden Tool-Aufruf mit seinen Argumenten und dem Ergebnis. Das ermöglicht Debugging, Kostenverteilung und Erkennung anomalem Verhaltens (z. B. ein Agent liest ~/.ssh/ wenn er nur auf das Projektverzeichnis zugreifen sollte). AgentOps-Plattformen wie LangSmith erleichtern dies.
Mensch-in-der-Schleife für irreversible Aktionen
Jede Aktion, die schwer oder unmöglich rückgängig zu machen ist — Nachrichten senden, Daten löschen, Einkäufe tätigen — sollte vor der Ausführung eine explizite menschliche Bestätigung erfordern. Baue HITL-Checkpoints in deine Agent-Runtime ein, nicht nur ins Prompt. Prompts können überschrieben werden; Code nicht.
Achte auf Tool-Poisoning
Wenn du Agenten erlaubst, MCP-Server dynamisch zu installieren oder zu entdecken, kann ein bösartiger Server ein Tool registrieren, dessendessen versteckte Anweisungen in der Beschreibung einbetten. Überprüfe Tool-Beschreibungen stets, bevor du sie in das Registry deines Agents aufnimmst. Siehe:Tool Poisoning.
Gib klare Fehlerantworten zurück
Wenn ein Tool fehlschlägt, gib einen strukturierten Fehler mit genügend Kontext zurück, damit das Modell sich erholen oder einen Eskalationspfad wählen kann — nicht einen rohen Ausnahme-Stacktrace. Beispiel: { "error": "rate_limited", "retry_after": 5 }. Ein gut beschriebener Fehler erlaubt es dem Agenten, erneut zu versuchen, ein Fallback-Tool zu verwenden oder den Nutzer elegant zu informieren.