Google ADK Agent Skills: Wie man produktionsreife Skills für KI-Agenten baut

Beim Bau autonomer KI-Agenten packen viele Entwicklungsteams sämtliche Edge-Case-Regeln, Datenbankschemata und Formatierungsanweisungen in einen einzigen riesigen System Prompt.

In einfachen Prototypen funktioniert das scheinbar. Sobald das System jedoch in mehrstufigen Kundendialogen oder komplexen Workflows läuft, treten drei kritische Engpässe auf:

• Context Rot (Aufmerksamkeitsverlust): Bei 4.000 bis 8.000 Tokens im System-Prompt verwässert die Aufmerksamkeit des Sprachmodells. Anweisungen in der Mitte des Textes werden schlicht ignoriert.
• Explodierende Token-Kosten: Bei jedem Turn 5.000 statische Tokens mitzuschicken, verbrennt API-Budget für Regeln, die für die aktuelle Teilaufgabe irrelevant sind.
• Aufwendige Deployments: Jede Anpassung einer Geschäftsregel erfordert einen Container-Rebuild und ein neues Deployment.

Im Google ADK-Ökosystem ist ein Skill ein eigenständiges, versioniertes Verzeichnis mit drei klar getrennten Schichten:

Tier 1: YAML Frontmatter (Erkennungs- und Trigger-Engine)

Ein schlanker Metadaten-Header mit Name, Zweck und präzisen Trigger-Schlüsselwörtern. Der Orchestrator prüft nur diese Metadaten über alle Skills hinweg (Latenz unter 100ms), ohne den gesamten Skill-Text zu laden.

Tier 2: SKILL.md (Ausführungsvertrag & Heuristiken)

Der operative Bauplan. Er definiert die zwingende Schrittfolge, Entscheidungsbäume, Negativ-Vorgaben (*was der Agent ausdrücklich nicht tun darf*) und Fallback-Strategien bei API-Fehlern.

Tier 3: scripts/ und references/ (Deterministische Ausführungsebene)

Unterstützende Python-Validierungsskripte, Pydantic-Schemas und API-Payload-Templates. Das Modell rät keine mathematischen Werte, sondern ruft deterministische Skripte direkt aus dem Skill-Ordner auf.

# Anatomie eines produktionsreifen Skills
skills/
└── b2b_lead_audit/
    ├── SKILL.md                # Regeln, Entscheidungsbaum, Negativ-Constraints
    ├── scripts/
    │   ├── validate_vat.py     # Deterministische USt-IdNr.-Prüfung
    │   └── score_lead.py       # Python-basierter Scoring-Algorithmus
    └── references/
        └── schema_v2.json      # Strukturiertes JSON-LD Schnittstellen-Schema

Progressive Disclosure ist das Architekturmuster, bei dem detaillierter technischer Kontext erst dann geladen wird, wenn der Workflow einen bestimmten Trigger erreicht.

Statt 20 verschiedene Geschäfts-Workflows beim Start vollständig in den Kontext zu laden:

• Phase 1 (Routing): Der Orchestrator scannt schlanke Metadaten (~150 Tokens), um den passenden Skill zu wählen.
• Phase 2 (Ausführung): Der Agent lädt gezielt die spezifische SKILL.md (z.B. 800 Tokens) für die Ausführung.
• Phase 3 (Bereinigung): Nach Abschluss der Teilaufgabe wird der Tiefenkontext freigegeben, sodass nachfolgende Agenten mit sauberem Kontext arbeiten.

In Produktions-Benchmarks auf Google Cloud Run sank der durchschnittliche Token-Verbrauch pro mehrstufiger Session von 120.000 Tokens auf 18.500 Tokens — eine Ersparnis von 84%.

Ein Standard-Python-Tool oder ein Model Context Protocol (MCP) Server stellt die Schnittstelle zu einer API her. Rohe API-Tools ohne Verhaltensgrenzen sind jedoch die häufigste Ursache für Ausfälle im Live-Betrieb.

Das Two-Layer Shield stellt vollständige Zuverlässigkeit sicher:

• Layer 1 (Python Tool — 50%): Die technische API-Schnittstelle (Google Ads, Google Maps, CRM), die Authentifizierung, Netzwerkverbindung und HTTP-Aufrufe abwickelt.
• Layer 2 (Strategischer Skill — 50%): Die Geschäftslogik, die Parameter vor dem Aufruf validiert, Budgetgrenzen prüft, Ratenlimits abfängt und deterministische Fallbacks durchsetzt.

Für den Einsatz von Agenten in Unternehmen ist zentrale Steuerung unverzichtbar. Google ADK löst dies über die Google Cloud Skill Registry und den Built-in Skills-Katalog:

• Google Built-in Skills: Vorgefertigte, geprüfte Standard-Skills (Datenformatierung, Dokumenten-Parsing, Routing), die Entwicklungszeit drastisch verkürzen.
• Zentrale Veröffentlichung via agents-cli: Entwickler veröffentlichen Fach-Skills mit agents-cli skill publish im zentralen Cloud-Register.
• Semantische Versionierung (revisions/v1, revisions/v2): Cloud Run Services binden feste Skill-Versionen an. Updates im Staging gefährden die Produktionsstabilität nicht.
• Hot-Reloading ohne Rebuilds: Cloud Run Instanzen ziehen genehmigte Skill-Revisionen zur Laufzeit. Geschäftsregeln werden in Sekunden aktiv — ohne Docker-Build oder Container-Neustart.
• Enterprise IAM-Sicherheit: Granulare Zugriffsrechte beschränken sensible Finanz- oder Compliance-Skills auf berechtigte Service-Accounts.

Produktionsagenten dürfen keine ungeprüften Daten an Endnutzer ausgeben. Über den Single-Agent Tool Loop ruft der Orchestrator vor der finalen Ausgabe interne Validierungstools auf (z.B. Tag-Balance, Link-Prüfungen, mathematische Neuberechnung).

Wird eine Unstimmigkeit festgestellt, korrigiert sich der Agent selbstständig innerhalb des Loops.

Bei komplexen Abläufen nutzt Google ADK das ParallelAgent Fan-Out-Muster:

• Unabhängige Subagenten arbeiten zeitgleich (z.B. Recherche-Agent, Preiskalkulator, Bestandsprüfer).
• Die Gesamtlaufzeit sinkt um den Faktor 2,5 bis 3 gegenüber sequentiellen Ketten.
• Alle Berechnungen laufen in reinem Python-Code — mathematische Halluzinationen sind vollständig ausgeschlossen.