Mit prüfbaren Hypothesen debuggen

Beschreiben Sie den Fehler vor dem Lösungsvorschlag

Ein nützlicher Debugging-Auftrag nennt erwartetes Verhalten, beobachtetes Verhalten und betroffenen Umfang. Ergänzen Sie Version, relevante Eingabe und Fehler. Entfernen Sie Zugangsdaten und private Datensätze aus Logs, bevor Sie sie einem KI-Werkzeug geben.

„Der Export ist kaputt“ gibt wenig Orientierung. Besser ist: „Lokal gelingt der Export. In Staging liefert dieselbe Anfrage einer Führungskraft seit dem letzten Deployment 403. Andere Routen funktionieren weiterhin.“

Diese Beschreibung belegt die Ursache nicht. Sie benennt Unterschiede, die eine Untersuchung leiten können.

Halten Sie mehrere Erklärungen offen

Bitten Sie den Agenten um wenige plausible Ursachen und die Nachweise für jede. Fordern Sie ihn nicht auf, sich auf die erste überzeugende Erklärung festzulegen.

Beim fiktiven Exportfehler sind mögliche Ursachen eine fehlende Berechtigung der Dienstidentität, eine geänderte Rollenzuordnung oder eine Anfrage an die falsche Umgebung. Jede Erklärung lässt andere Nachweise erwarten.

Die Tabelle ist ein Ausgangspunkt. Eine 403-Antwort kann aus verschiedenen Schichten stammen. Ermitteln Sie die erzeugende Komponente, bevor Sie ein Scheitern der Anwendungsautorisierung annehmen.

Wählen Sie eine sichere Beobachtung

Beginnen Sie mit einer Beobachtung, die Erklärungen mit geringem Aufwand unterscheiden kann. Vergleichen Sie die bereitgestellte Version und nicht geheime Konfiguration. Prüfen Sie den relevanten Fehler und die Anfragekennung. Reproduzieren Sie das Problem möglichst in einer autorisierten Testumgebung.

Gewähren Sie keine weitreichenden Berechtigungen, nur um zu sehen, ob der Fehler verschwindet. Das verändert die Sicherheitsgrenze und kann die tatsächlich fehlende Berechtigung verdecken. Fügen Sie kein vollständiges Produktionslog in das Modell ein, wenn eine um sensible Angaben bereinigte Fehlermeldung und der Anfragepfad ausreichen.

Halten Sie fest, was jede Hypothese schwächen würde. Das hilft dem Agenten, seine Erklärung zu überarbeiten, statt seine erste Antwort zu verteidigen.

Ändern Sie jeweils nur eine Ursache

Wenn die Nachweise eine wahrscheinliche Ursache zeigen, nehmen Sie eine gezielte Korrektur vor. Kombinieren Sie nicht eine Berechtigungsänderung, ein Bibliotheks-Upgrade und einen neu geschriebenen Handler. Verschwindet das Symptom, wüssten Sie sonst nicht, welche Änderung entscheidend war.

Prüfen Sie die ursprüngliche Fehlerbedingung. Prüfen Sie auch die angrenzende Berechtigungsgrenze. Wenn Sie den Zugriff einer Führungskraft korrigieren, bestätigen Sie, dass ein unberechtigter Nutzer weiterhin abgewiesen wird.

Ergänzen Sie bei einem wiederkehrenden Fehler eine Regressionsprüfung in der Schicht, die ihn erkennen kann. Ein Unit-Test kann nicht jeden Deployment-Konfigurationsfehler erkennen. Manche Fehler brauchen eine Integrationsprüfung oder eine kontrollierte Prüfung nach dem Deployment.

Stoppen Sie wiederholte Versuche ohne neue Nachweise

Ein Agent kann viele Varianten einer Korrektur erzeugen. Mehr Versuche verbessern die Diagnose nicht unbedingt. Wiederholt sich derselbe Fehler, fragen Sie, welche neue Beobachtung der nächste Versuch liefern wird.

Setzen Sie bei unsicheren Untersuchungen ein Zeit- oder Versuchslimit. Melden Sie dann die aktuellen Nachweise, verworfenen Hypothesen und die offene Frage. So kann eine andere Person fortfahren, ohne dieselben Experimente zu wiederholen.

Dokumentieren Sie nach der Wiederherstellung die Ursache und die Bedingung, durch die der Fehler die betroffene Umgebung erreichte. Eine Korrektur beseitigt den unmittelbaren Fehler. Eine nützliche Folgemaßnahme verringert die Wahrscheinlichkeit seiner Wiederkehr.