Agenten-Skills in der Praxis: Entwurf und Implementierung in produktiven Systemen

von Denis Shokhirev, Enterprise AI Architect aus Erlangen. Ich leite das DennisCraft AI Studio und liefere produktive KI-Agenten für B2B-Kunden im DACH-Raum. Mein aktueller Stack: Claude, Supabase, n8n, Doppler, selbst gehostetes Postgres. Die größte Herausforderung: Agentenfähigkeiten (“Skills”) so zu gestalten, dass sie in regulierten, produktiven Umgebungen stabil und auditierbar funktionieren – nicht nur im Demo-Modus.

Was ist ein Agenten-Skill in der Produktivumgebung?

Ein Skill besteht nicht nur aus einem Prompt oder einer LLM-Funktion. Im Produktivbetrieb ist ein Skill eine klar definierte Pipeline: Eingabevalidierung, Verarbeitung (oft über APIs oder Datenbanken), Fehlerbehandlung und strukturierte Rückgabe. Beispiel: Der Skill „Rechnung erstellen“ beinhaltet die Prüfung der Eingabedaten, Eintrag in Postgres, Auslösung eines externen Billing-API-Aufrufs und Rückgabe einer Statusstruktur. Das größte Risiko: Skills brechen, wenn sich APIs oder Schemata ändern. In regulierten Märkten wie Deutschland ist dies kritisch, da jede Änderung mit DSGVO und ggf. BSI Grundschutz abgeglichen werden muss.

Skill-Design: Funktionsmuster statt Prompt-Muster

Warum „Prompt as Skill“ in der Praxis scheitert

In Demos wird oft jeder Skill als neuer Prompt implementiert. In der Realität bricht dieses Muster. Bei drei meiner letzten Projekte führten Prompt-basierte Skills zu SQL-Code mit bekannten Schwachstellen (z. B. fehlende Parametrisierung, fehlerhafte JOINs). Lösung: Jeder Skill ist eine eigenständige Funktion mit definiertem Input/Output, Validierung und klarer Geschäftslogik außerhalb der LLM. Die LLM dient nur als Parser oder Generator, nicht als Ausführungsinstanz.

Beispiel: Skill zur Rechnungserstellung

def create_invoice(payload: dict) -> dict:
    if not validate_invoice(payload):
        return {"error": "validation_failed"}
    invoice_id = insert_into_pg(payload)
    api_result = send_invoice(invoice_id)
    return {"invoice_id": invoice_id, "api_status": api_result}

Die LLM kann unstrukturierte Anfragen analysieren oder Texte generieren, übernimmt aber keine Geschäftsregeln oder Datenbankoperationen.

Skill-Integration: Orchestrierung und Supabase

Skills nicht fest im Agenten kodieren

Skills als fester Bestandteil im Agenten-Code sind im Betrieb schwer wartbar. Jede Änderung erfordert einen vollständigen Rollout. Ich registriere Skills als REST-Endpoint in Supabase oder als separate Node in n8n. So können Skills unabhängig weiterentwickelt und bei Fehlern schnell zurückgesetzt werden. Die Trennung erleichtert auch die DSGVO-konforme Protokollierung und Auditierung.

Orchestrierung mit n8n

- id: create_invoice
  type: httpRequest
  properties:
    url: https://api.denniscraft.ai/invoice
    method: POST
- id: send_notification
  type: emailSend
  properties:
    to: {{$json.client_email}}
    subject: "Ihre Rechnung"

n8n ermöglicht das visuelle Verketten von Skills. Supabase dient als zentrale Skill-Verwaltung mit Versionierung und Zugriffskontrolle.

Skill-Sicherheit: Statische Analyse und Runtime-Sandbox

Praxisbeobachtungen

Prompt-generierte Skills produzieren oft unsicheren Code. Bei drei Projekten habe ich SQL-Statements ohne Parametrisierung entdeckt – ein Einfallstor für SQL-Injection (siehe auch OWASP Top 10, 2023 – owasp.org). Ich setze semgrep und bandit für statische Codeanalyse sowie gitleaks zur Geheimnis-Erkennung ein. Im Betrieb laufen alle Skills in einer Sandbox: Keine exec/eval-Aufrufe, Zeitlimits, vollständiges Logging externer Aktionen. Dies ist für ISO 27001 und NIS2-Compliance essenziell.

Skill-Versionierung und Rollback

Jeder produktive Skill braucht explizite Versionierung. In Supabase führe ich eine skills-Tabelle mit skill_id, version, schema, code_hash und active_flag. Rollbacks erfolgen durch Setzen des active_flag. Ohne diese Trennung kann ein fehlerhafter Skill Kettenfehler im Gesamtsystem verursachen – ein Compliance-Risiko.

CREATE TABLE skills (
    skill_id TEXT,
    version INT,
    schema JSONB,
    code_hash TEXT,
    active_flag BOOLEAN
);

FAQ

Wie testen Sie einen neuen Skill ohne Risiko für den Produktivbetrieb?

Ich stelle einen dedizierten Test-Endpoint bereit, führe Skills mit Produktionsdaten im Read-Only-Modus in einer Sandbox aus und prüfe alle Logs. Erst nach manuellem Review erfolgt die Freischaltung.

Darf eine LLM direkt CRUD-Operationen auf die Hauptdatenbank ausführen?

Nein. Immer über eine Proxy-Schicht mit Whitelisting. Selbst Claude generiert gelegentlich DROP statt SELECT. LLMs dienen als Parser oder Generator, niemals als Executor.

Wie spielen Sie einen Hotfix für einen Skill live ein?

Ich pflege einen Hotfix-Branch mit eigenem CI/CD auf einen Test-Endpoint. Nach Review wird das active_flag in Supabase umgeschaltet. Downtime beträgt nur Sekunden.

Welches minimale Logging ist für Skills erforderlich?

user_id, skill_id, Ein-/Ausgabe ohne PII, Status, Ausführungszeit, Fehlerdetails. In n8n schreibe ich diese Daten in eine eigene Logs-Collection.

Können Skills als openapi.yaml für Codegenerierung beschrieben werden?

Ja, sofern das Schema strikt und ohne „Human-in-the-Loop“-Schritte spezifiziert ist. Das ermöglicht automatisierte Tests und Validierung.

An welcher Stelle Ihrer Skill-Pipeline treten die meisten Fehler im Produktivbetrieb auf – bei der Eingabevalidierung, beim Aufruf externer APIs oder bei der Ergebnisrückgabe? Teilen Sie gerne konkrete Erfahrungen. Ich biete für DACH-CTOs einen kostenlosen 30-min Stack-Audit für KI-Projekte in regulierten Branchen an. Kontaktieren Sie mich auf LinkedIn oder via @ger_dennis_ai.