Agent antwortet nach 401-Fehler ohne Daten, der Workflow meldet Erfolg

Nach dem 401 antwortet der Rechnungs-Agent ohne Daten und meldet Erfolg

Laut hyper.ai beschreibt eine Praxisanalyse einen Agenten für Rechnungsfragen. Dessen API-Credential läuft mitten in einer mehrstufigen Aufgabe ab. Jeder folgende Tool-Call liefert einen 401-Fehler. Das Modell kann es mit geänderten Argumenten erneut versuchen. Danach antwortet es ohne die benötigten Daten, und der Workflow meldet Erfolg.

Die Analyse führt das darauf zurück, dass das Modell Fehler als Text im Kontext behandelt und womöglich trotzdem versucht, den Nutzer zufriedenzustellen. Ein stärkeres Modell allein löse das Problem daher möglicherweise nicht.

Vorsicht ist bei der Einordnung geboten. Es handelt sich um ein beschriebenes Szenario, nicht um eine gemessene Häufigkeit. Eine Datenbasis und der Originalautor sind im Material nicht erkennbar; die Analyse liegt nur als Zusammenfassung vor. Neu ist vor allem die Rahmung als stilles Produktionsrisiko. Das Phänomen selbst ist es nicht.

Explizite Fehler bemerken Agenten meist, plausible Falschwerte deutlich seltener

Die auf arXiv veröffentlichte Fault-Injection-Studie „Loud Failures, Quiet Failures“ untersucht, was Agenten tun, wenn die Tool-Schicht Fehler produziert. Die Autoren injizierten je einen von vier typisierten Fehlern in 24 mehrstufige Tasks. Sechs Modelle aus drei Familien absolvierten dabei 1.920 Trials. Erfasst wurde, ob der Agent den Fehler bemerkt, den Plan ändert, die Aufgabe rettet oder sich wiederholt.

Gibt das Tool einen expliziten Fehler zurück, behandeln Agenten ihn in 91,3 Prozent der Trials als Problem. Liefert es hingegen einen plausiblen, aber falschen Wert, sind es nur 58,8 Prozent. Bei fehlerfreiem Lauf melden die Agenten in 26,8 Prozent der Trials dennoch ein Problem.

Reasoning-Modelle schneiden nicht besser ab. Im Paarvergleich mit ihren Instruct-Geschwistern derselben Familie bemerken sie Fehler seltener und ändern häufiger den Plan. Die Erholungsrate bleibt unverändert. Mehr Nachdenken führt hier also nicht zu besserer Recovery.

Die Studie stützt die These nur teilweise, weil sie etwas anderes misst

Auf den ersten Blick scheinen sich beide Quellen zu widersprechen. Die Praxisanalyse beschreibt, wie ein Agent einen expliziten Fehler faktisch übergeht. Die Studie misst bei expliziten Fehlern eine Problembehandlung in 91,3 Prozent der Trials.

Die Messgrößen unterscheiden sich aber. Die Studie erfasst, ob der Agent das Problem im Trial bemerkt oder meldet. Sie prüft nicht, ob die finale Antwort ehrlich auf fehlende Daten hinweist. Die Praxisanalyse schildert dagegen ein einzelnes Szenario: einen Retry und eine spätere Antwort ohne Daten, ohne genannte Datenbasis.

Ein echter Widerspruch ist damit nicht belegt. Die Studie stützt die These zu expliziten Fehlern nur teilweise. Am stärksten stützt sie die Gefahr bei still falschen, aber plausiblen Rückgaben. Aussagen über Credential-Ausfälle trifft sie nicht.

Schwache Hazard-Diagnose und Recovery, nicht zu wenig Rechenaufwand

Drei weitere unabhängige Arbeiten zeigen ein ähnliches Grundmuster. Keine von ihnen misst das Credential-Szenario.

ToolBench-X injiziert fünf Hazard-Typen, darunter Invocation Error, Execution Failure und Output Drift. Jeder Fall bleibt über mindestens einen Weg lösbar, etwa Retry oder Fallback. Agenten, die mit zuverlässigen Tools gut abschneiden, scheitern dennoch oft. Laut den Autoren liegt das eher an mangelnder Hazard-Diagnose und ineffektiver Recovery als an der Menge der Tool-Nutzung oder am Inferenzbudget. Gezielte Recovery-Hinweise retten viele gescheiterte Tasks. Test-time-Scaling bringt weniger.

AgentChaosBench injiziert zehn Fault-Typen in fünf A2A/MCP-Anwendungen, darunter nicht erreichbare oder langsame Tools und korrupte Antworten. Laut den Autoren lösen Zero-Shot-LLM-Baselines die Fehlererkennung aus Telemetrie bei Weitem nicht.

ReliabilityBench testet Gemini 2.0 Flash und GPT-4o mit ReAct und Reflexion in vier Domänen über 1.280 Episoden. Perturbationen senken pass@1 von 96,9 auf 88,1 Prozent. Der Abstract nennt diese Zahl allerdings für Task-Perturbationen, nicht für Credential-Ausfälle.

Alle drei Arbeiten stützen das Grundmuster. Sie messen aber nicht dasselbe Szenario. Ihre Veröffentlichungsdaten fehlen im Material.

LangChain bietet Fehler-Middleware, ihre Wirksamkeit ist nicht geprüft

LangChain dokumentiert vorgefertigte Middleware für solche Fälle. Tool error gibt Tool-Exceptions als Fehlermeldungen an das Modell weiter. Tool retry und Model retry wiederholen Aufrufe mit Exponential Backoff. Dazu kommen Model fallback, Human-in-the-loop zur Freigabe von Tool-Calls und ein Model call limit. Der MCPAdapter wandelt MCP-Tool-Ergebnisse in ToolMessage-Objekte um, deren Status Erfolg oder Fehler anzeigt.

Eine belegte Wirksamkeitsprüfung dieser Maßnahmen liegt im Material nicht vor. Teams mit credential-abhängigen Tool-Zugriffen können sie als Optionen verstehen, nicht als nachgewiesene Lösung.