Agent Drift: Wenn KI-Agenten schrittweise den Fokus verlieren

Das Problem

Von außen wirkt alles stabil. Monitoring schlägt nicht an, es gibt keine klaren Incidents, und die Erfolgsrate (success rate) ist fast gleich.

Aber in den Run-Metriken ist ein Shift sichtbar: Vor einer Woche hat dieser Agent die Aufgabe in 2-3 Schritten abgeschlossen, nach einem kleinen Prompt- und Modellversions-Update braucht er 7-9.

Das System ist nicht abgestürzt.

Es ist nur langsam seitlich weggerutscht.

Analogie: Stell dir eine Ladenwaage vor, die jeden Tag nur 1-2 Gramm falsch liegt. Am ersten Tag ist das fast unsichtbar. Nach einem Monat trifft der Fehler schon die ganze Kasse. Beim Agenten genauso: kleiner Drift pro Run ergibt großen Schaden auf Skalierung.

Warum das passiert

LLM-Agenten sind stochastische Systeme. Eine kleine Änderung an Modell, Prompt oder Eingabedaten kann die Reihenfolge der Schritte ändern. Schon kleine Unterschiede im Reasoning Loop akkumulieren mit der Zeit zu Drift.

In Production läuft Drift meist leise ab:

1. Modell, Prompt, Tool-Output oder Retrieval-Daten ändern sich;
2. der Agent schließt Tasks formal weiter ab;
3. aber er macht andere Schritte und verbraucht mehr Ressourcen;
4. ohne Baseline-Vergleich wirkt es wie "alles normal".

Das Problem ist nicht eine einzelne Änderung. Das Problem ist fehlende Release-Kontrolle, die Abweichungen von der Baseline früh erkennt.

Welche Ausfälle am häufigsten auftreten

Um es nicht zu verkomplizieren, trennt man in Production meist vier Drift-Typen.

Modell-Drift

Nach einem LLM-Versionswechsel rankt der Agent Schritte anders: er "prüft noch mal", beendet Runs später oder wählt ein anderes tool.

Typische Ursache: Modellversion wurde ohne Baseline-Vergleich auf einem Golden-Task-Set aktualisiert.

Prompt-Drift

Eine kleine Änderung im System-Prompt verschiebt Prioritäten: der Agent wird "zu vorsichtig" oder "zu aktiv".

Typische Ursache: Prompt wurde wie Text geändert, nicht wie Production-Code mit Test und Canary.

Tool-Contract-Drift

Ein tool liefert ein neues Feld, anderes Fehlerformat oder ein leeres Array statt null. Der Agent interpretiert das anders und verändert seinen Entscheidungszyklus.

In Production kippt das leicht in Tool-Fehler oder Tool-Spam.

Retrieval- und Context-Drift

Der Wissensindex wurde aktualisiert: neue Dokumente, anderes Ranking, mehr irrelevante Chunks im Context Window. Der Agent funktioniert formal, nutzt aber häufiger falsche Fakten.

Von den Symptomen sieht das oft aus wie Context Poisoning.

Wie man diese Probleme erkennt

Drift sieht man am besten nicht über eine einzelne Metrik, sondern über Abweichungen von der Baseline.

Wie man Drift von einer wirklich nützlichen Änderung unterscheidet

Nicht jede Verhaltensänderung ist schlecht. Manchmal ist die neue Version tatsächlich besser. Die Kernfrage: wurde Qualität besser, ohne unverhältnismäßigen Preis.

Normal, wenn:

• Qualität steigt und tokens_per_task + latency_p95 bleiben fast gleich;
• neues Verhalten ist stabil auf Golden-Tasks;
• Canary zeigt keinen Anstieg bei timeout und max_steps_reached.

Gefährlich, wenn:

• success rate ähnlich bleibt, aber Kosten und Latenz steigen;
• stop reasons Richtung Limits wandern;
• Agent häufiger Tools nutzt ohne Genauigkeitsgewinn.

Wie man solche Ausfälle stoppt

Praktisch sieht das so aus:

1. du machst eine Änderung (Candidate);
2. im Drift Gate in CI laufen Tests und Candidate wird mit Baseline verglichen über quality/tokens/tool calls/latency/stop reasons;
3. wenn Schwellen verletzt sind, wird Release blockiert oder Rollback ausgeführt;
4. wenn Schwellen passen, geht die Änderung in Canary und dann in den vollen Rollout.

baseline
   ↓
candidate evaluation
   ↓
threshold gate
   ↓
canary
   ↓
production

Minimale Barriere gegen Drift in Runtime-CI:

from dataclasses import dataclass


@dataclass(frozen=True)
class Thresholds:
    max_tool_calls_delta: int = 2
    max_tokens_delta_pct: float = 0.30
    max_latency_delta_pct: float = 0.30
    allow_stop_reason_change: bool = False


def violates_thresholds(baseline: dict, candidate: dict, t: Thresholds) -> list[str]:
    errors: list[str] = []

    if candidate["tool_calls"] > baseline["tool_calls"] + t.max_tool_calls_delta:
        errors.append("tool_calls_delta_exceeded")

    if candidate["tokens"] > baseline["tokens"] * (1 + t.max_tokens_delta_pct):
        errors.append("tokens_delta_exceeded")

    if candidate["latency_ms"] > baseline["latency_ms"] * (1 + t.max_latency_delta_pct):
        errors.append("latency_delta_exceeded")

    if (not t.allow_stop_reason_change) and candidate["stop_reason"] != baseline["stop_reason"]:
        errors.append("stop_reason_changed")

    return errors

Diese Barriere macht keine Magie. Sie verhindert nur, dass eine langsamere und teurere Regression als "erfolgreiches" Release geschippt wird.

Wo das in der Architektur implementiert wird

Drift-Kontrolle ist meistens über zwei Schichten verteilt.

Agent Runtime erfasst Drift-Signale während der Ausführung: stop_reason_distribution, steps_per_task, tokens_per_task. Ohne diese Metriken hat ein Threshold Gate nichts zum Vergleichen.

Tool Execution Layer ist Quelle für einen Teil des Drifts: Änderung im Tool-Output-Format, neue Retry-Policy oder anderer Fehlervertrag ändern das Agent-Verhalten unauffällig. Hier sollten Tool-Verträge versioniert werden.

Selbstcheck

Schneller Check vor dem Release. Hake die Punkte ab und sieh dir den Status unten an.
Das ist ein kurzer Sanity-Check, kein formales Audit.

FAQ

Q: Bedeutet Drift immer, dass das Modell schlechter wurde?
A: Nein. Drift bedeutet, dass Verhalten sich geändert hat. Schlecht wird es, wenn die Änderung ungemessen und unkontrolliert ist.

Q: Kann man Drift nur über success rate erkennen?
A: Nein. Success rate reagiert oft zu spät. tool_calls, Tokens, Latenz und stop reasons bewegen sich früher.

Q: Braucht man Canary für kleine Prompt-Änderungen?
A: Für High-Traffic-Systeme ja. Schon ein Satz im Prompt kann die Aktionswahl des Agenten verändern.

Q: Was tun, wenn Drift da ist, aber Qualität leicht besser?
A: Rechne Unit Economics: Kosten pro erfolgreichem Run in Baseline und Candidate. Wenn Qualität steigt und neue Run-Kosten im Budget bleiben, shippen und neue Baseline fixieren.

Agent Drift sieht fast nie wie ein großer Crash aus. Es ist eine langsame Regression, die nur im Vergleich zur Baseline sichtbar ist. Darum brauchen Production-Agenten nicht nur bessere Modelle, sondern strikte Release-Kontrolle.

Verwandte Seiten

Um Drift in Production besser zu schließen, sieh dir an:

• Warum KI-Agenten scheitern - allgemeine Karte typischer Production-Ausfälle.
• Budget Explosion - wie Verhaltensdrift Kosten leise aufbläht.
• Tool-Spam - wie man unnötig wachsende Tool-Aufrufe kontrolliert.
• Context Poisoning - wie Context-Probleme als "komische" Agent-Entscheidungen maskiert werden.
• Agent Runtime - wo man Release-Gates, Limits und stop reasons setzt.
• Tool Execution Layer - wo Validierung, Retries und Aufrufkontrolle hingehören.