Warum Erfolgsquoten bei Aufgaben stille Agentenfehler nicht erkennen

Im September und Oktober 2026 führte ein Entwickler eine Reihe kontrollierter Experimente mit einem KI-Agenten für den Kundensupport durch, um festzustellen, welche Monitoring-Metriken tatsächlich stille Fehler erkennen. Die Tests umfassten das absichtliche Brechen des Systems auf acht verschiedene Arten, von Modellwechseln bis hin zu Infrastruktur-Latenz, um zu prüfen, ob herkömmliche Observability-Tools Alarm schlagen würden.

Was geschah

Der erste Test im September verglich zwei Modelle, Claude Haiku 4.5 und Claude Sonnet 5, bei zwanzig Support-Aufgaben. Beide erzielten perfekte Ergebnisse. Als jedoch zwei Fallen-Aufgaben mit unberechtigten Rückerstattungsanträgen gestellt wurden, gewährte Haiku alle sechs Rückerstattungen, während Sonnet sie korrekt ablehnte. Trotz dieser gefährlichen Abweichung blieben ihre hochrangigen Erfolgsquoten identisch. Im Oktober wiederholte der Entwickler die Bewertung und stellte fest, dass Haiku nun unberechtigte Rückerstattungen ablehnte. Eine erste Analyse legte nahe, dass die Verarbeitung vorheriger Aufgaben in einer Warteschlange dem Agenten beigebracht hatte, den Status zu überprüfen. Weitere Untersuchungen ergaben jedoch eine einfachere Ursache: Das Modellalias war ohne Protokollierung oder Benachrichtigung stillschweigend von claude-haiku-4-5 auf claude-haiku-5-5 aktualisiert worden.

Um zu verstehen, warum Standardmetriken diese Probleme übersahen, entwarf der Entwickler ein rigoroses Testframework unter Verwendung einer simulierten Enterprise-API mit dreißig definierten Operationen (Scopes). Die Suite umfasste neunzehn Standardaufgaben und zwei Rückerstattungsfallen. Nach der Festlegung einer Baseline mit drei Durchläufen von Claude Sonnet 5.5 führte der Entwickler acht spezifische Regressionen nacheinander ein. Dazu gehörten der Wechsel zu einem schwächeren Modell, das Abschneiden von API-Dokumentation, das Entziehen von Berechtigungen, das Einführen veralteter Lesevorgänge aus Datenbank-Replikas, das Injizieren transienter API-Fehler, das Hinzufügen von Netzwerklatenz und das Freilegen veralteter Tools.

Die Ergebnisse zeigten, dass traditionelle Erfolgsquoten bei Aufgaben schlechte Indikatoren für die Systemgesundheit sind. Nur zwei der acht Regressionen führten dazu, dass die Aufgabenerfüllung unter den Schwellenwert fiel. Die anderen sechs Fehler, darunter ein Anstieg der API-Aufrufe um 70 % aufgrund von Retry-Logik und erheblicher Token-Verschwendung durch das Raten fehlender Befehle, ließen die Erfolgsquote unverändert. Die Fähigkeit des Agenten, autonom von Fehlern zu erholen, maskierte die zugrunde liegende Infrastrukturdegradation und erzeugte ein falsches Sicherheitsgefühl bei Ingenieuren, die sich ausschließlich auf Pass/Fail-Metriken verlassen.

Wie es funktioniert

Die Erkennungsstrategie basierte auf dem Vergleich der Ausführungstelemetrie mit einer engen Baseline-Streuung. Anstatt nur zu prüfen, ob eine Aufgabe abgeschlossen wurde, verfolgte das System vier Schlüsselmetriken: Anzahl der erfolgreichen Aufgaben, Token-Kosten, Volumen der Tool-Aufrufe und Scope-Drift. Der Scope-Drift misst die Überlappung zwischen den in einem Durchlauf verwendeten API-Scopes und der Baseline, berechnet als eins minus die durchschnittliche Überlappung. Die Schwellenwerte für Warnungen wurden auf das Doppelte der Baseline-Streuung festgelegt, um der natürlichen statistischen Verteilung Rechnung zu tragen.

Das Volumen der Tool-Aufrufe erwies sich als die empfindlichste Metrik für Infrastrukturprobleme. Da die Baseline-Tool-Aufrufe nur um 3 % variierten, konnte ein enger Schwellenwert von ±7 % Anomalien leicht kennzeichnen. Als beispielsweise die Upstream-API instabil gemacht wurde, verursachte die Retry-Logik des Agenten einen Sprung der Tool-Aufrufe um 70 %, was eine Warnung auslöste, obwohl jede Aufgabe weiterhin erfolgreich war. Im Gegensatz dazu variierte der Token-Verbrauch über die Baseline-Durchläufe hinweg um 18 %, was einen breiten Schwellenwert von ±37 % erforderte, der signifikante Ineffizienzen unbemerkt durchrutschen ließ.

Die Studie hob auch die Bedeutung der Analyse unstrukturierter Ausgaben hervor. Beim Test auf veraltete Lesevorgänge, bei dem der Agent veraltete Daten aus einer Replika las, blieben alle quantitativen Metriken innerhalb normaler Grenzen. Der Agent erkannte die Diskrepanz zwischen seinen Schreibvorgängen und den nachfolgenden Lesevorgängen und unterdrückte dann vorsätzlich Wiederholungen, um doppelte Mutationen zu vermeiden. Dieses defensive Verhalten rettete das System vor finanziellen Fehlern, machte den Infrastrukturfehler aber für numerische Monitore unsichtbar. Der einzige Nachweis des Fehlers fand sich in der abschließenden Textzusammenfassung des Agenten, die die Anomalie explizit beschrieb.

Wichtige Details

• Stille Modellupdates: Ein nicht fixiertes Modellalias änderte sich zwischen den Testläufen von claude-haiku-4-5 zu claude-haiku-5-5 und veränderte das Verhalten, ohne Bereitstellungswarnungen auszulösen.
• Metrikempfindlichkeit: Tool-Aufrufzahlen fingen vier Fehler ab, Scope-Drift fing vier ab, die Erfolgsquote fing nur zwei ab und Token-Kosten fingen einen ab.
• Retry-Maskierung: Ein instabiler API-Zweig injizierte 31 transiente Fehler, die alle vom Agenten durch Wiederholungen absorbiert wurden, was zu einem Anstieg der Tool-Aufrufe um 70 % führte, aber eine Erfolgsquote von 19/19 ergab.
• Autonome Workarounds: Als die Dokumentation abgeschnitten wurde, nutzte der Agent Brute-Force-Shell-Schleifen, um fehlende Endpunkte zu erraten, was den Token-Verbrauch um 73 % erhöhte und die Ausführungszeit von fünf auf fünfzehn Minuten verlängerte.
• Unsichtbare Fehler: Veraltete Datenbanklesungen lösten keine Metrikwarnungen aus, da die vorsichtige Reaktion des Agenten die Änderungen bei Token- und Tool-Aufrufen unterhalb der Erkennungsschwellen hielt.
• Adversarial Decay: Rückerstattungsfallen-Aufgaben, die die Modelle im September unterschieden, konnten im Oktober keine Fehler mehr erfassen, da das neuere Modell sie korrekt handhabte, wodurch der Test obsolet wurde.

Warum es wichtig ist

Für Engineering-Teams, die autonome Agenten entwickeln, demonstriert diese Studie, dass hohe Erfolgsquoten bei Aufgaben mit schweren operativen Ineffizienzen und Risiken koexistieren können. Agenten sind zunehmend in der Lage, Infrastrukturprobleme durch Retry-Logik und adaptives Verhalten zu verbergen. Wenn Sie nur überwachen, ob eine Aufgabe abgeschlossen wird, werden Sie steigende Kosten, Latenzen und potenzielle Datenkonsistenzprobleme übersehen, die sich hinter den Kulissen ansammeln. Diese Entkopplung der Aufgabenerfüllung von der Infrastrukturgesundheit bedeutet, dass herkömmliche Uptime- und Erfolgsdashboards für KI-gesteuerte Systeme unzureichend sind.

Darüber hinaus ist die Abhängigkeit von statischen adversarialen Testsets eine Schwachstelle. Wenn sich Modelle aktualisieren, können zuvor effektive Fallen-Aufgaben trivial werden und ein falsches Sicherheitsgefühl vermitteln. Ingenieure müssen die Ausgaben von Agenten als strukturierte Telemetrie betrachten, nicht nur als endgültige Antworten. Das Parsen von Zusammenfassungen nach Unsicherheiten und das Verfolgen niedrigstufiger Ausführungsmetriken wie Tool-Aufrufe bieten die notwendige Sichtbarkeit, um zwischen echter Verbesserung und stiller Degradation zu unterscheiden. Ohne diese tieferen Erkenntnisse riskieren Teams, Agenten bereitzustellen, die funktional erscheinen, aber finanziell oder technisch instabil sind.

Was Sie tun können

• Aufgelöste Modell-IDs protokollieren: Erfassen Sie die spezifische Modellversionszeichenkette für jeden Durchlauf und lösen Sie bei jeder Änderung eine Warnung aus, um stille Updates zu erkennen.
• Tool-Aufrufe pro Aufgabe verfolgen: Überwachen Sie die Anzahl der API-Aufrufe neben den Erfolgsquoten und verwenden Sie einen engen Schwellenwert basierend auf der Baseline-Streuung, um Retry-Stürme zu erfassen.
• Retry-Metriken isolieren: Verfolgen und warnen Sie explizit bei transienten Fehlern und Wiederholungsversuchen als Frühwarnung für die Degradation der Upstream-Infrastruktur.
• Agenten-Zusammenfassungen parsen: Nutzen Sie natürliche Sprachverarbeitung, um abschließende Agentenberichte nach Schlüsselwörtern zu durchsuchen, die auf Unsicherheit, Verifikationsfehler oder unterdrückte Aktionen hinweisen.
• Adversariale Tests rotieren: Aktualisieren Sie Ihre Fallen-Aufgaben und negativen Testfälle regelmäßig, um sicherzustellen, dass sie für die aktuelle Modellgeneration relevant bleiben.
• Mit Injection-Tests validieren: Injizieren Sie periodisch transiente Netzwerkfehler in Ihre Staging-Umgebung, um zu verifizieren, dass Ihre Telemetrieschicht den daraus resultierenden Anstieg der Tool-Aufrufe erkennt.