Fehlertests für Agenten-Tools: Unsichere Retries früh erkennen

Tests für Fehler von Agenten-Tools sollten sich darauf konzentrieren, was der Agent nach einem fehlgeschlagenen Vorgang glaubt, nicht nur darauf, ob das Tool einen Fehler ausgegeben hat. Ein Tool, das nach einem möglicherweise bereits ausgeführten Schreibvorgang in der Ferne «Anfrage fehlgeschlagen» meldet, schafft ein größeres Problem als ein Tool, das mit einer unvollständigen Antwort stoppt. Agenten planen auf Grundlage des Ergebnisses, das man ihnen gibt.

Der Erfolgsfall verdeckt die Entscheidungen, die darüber bestimmen, ob ein autonomer Lauf sicher ist: wiederholen, Freigabe anfordern, Zugang erneuern, Daten reparieren oder stoppen. Ich habe Tool-Sammlungen mit Hunderten grünen Tests gesehen, in denen nie ein Netzwerkausfall zwischen dem Start eines entfernten Befehls und dem Eintreffen seiner Ausgabe erzwungen wurde. Diese Tests prüften nicht den gefährlichen Teil.

Eine Fehlerantwort ist eine Eingabe für den Planer des Agenten

Ein Agent behandelt ein Tool-Ergebnis als Beleg. Wenn das Ergebnis nahelegt, dass keine Änderung erfolgt ist, kann der Agent den Vorgang wiederholen. Wenn es auf einen abgelaufenen Zugang hindeutet, kann er einen autorisierten Weg zur Wiederherstellung suchen. Wenn es Erfolg meldet, obwohl das entfernte Ergebnis unbekannt ist, kann der Agent mehrere nachfolgende Aktionen auf einer erfundenen Grundlage aufbauen.

Trennen Sie Fehler danach, was der Aufrufer wissen kann. Diese Unterscheidung wird ständig verwischt:

• Eine bestätigte Ablehnung bedeutet, dass der entfernte Dienst die Anfrage erhalten und abgelehnt hat.
• Ein bestätigter Fehler bedeutet, dass der entfernte Dienst ein Ergebnis zurückgegeben hat, das besagt, dass er die angeforderte Arbeit nicht ausgeführt hat.
• Ein ungewisses Ergebnis bedeutet, dass der Aufrufer nicht feststellen kann, ob die entfernte Seite die Arbeit ausgeführt hat.
• Ein lokaler Fehler bedeutet, dass das Tool fehlschlug, bevor es einen sinnvollen entfernten Versuch unternehmen konnte.

Eine verweigerte Verbindung, bevor eine TCP-Sitzung geöffnet wird, ist normalerweise ein lokaler Fehler. Ein HTTP-403 ist eine bestätigte Ablehnung. Ein Lese-Timeout nach dem Senden eines POST ist ungewiss, sofern der entfernte Dienst keine Möglichkeit bietet, den Vorgang nachzuschlagen. Diese Kategorien sollten in Ihren Testfällen und im Ergebnisschema des Tools auftauchen. Verstecken Sie sie nicht in einem Satz, den ein Agent erst interpretieren muss.

Eine kompakte Ergebnisstruktur macht den Vertrag testbar:

{
  "ok": false,
  "category": "outcome_unknown",
  "operation": "create_deployment",
  "retry": "reconcile_first",
  "correlation_id": "case-ssh-017",
  "message": "Connection closed after the remote command started; remote completion is unknown."
}

Die Namen sind nicht entscheidend. Die Trennung ist es. retry: "never" bei einer Berechtigungsverweigerung und retry: "reconcile_first" bei einem abgelaufenen Schreib-Timeout vermitteln dem Agenten unterschiedliche Anweisungen, ohne die gesamte Fehlermeldung in einen Prompt zu verwandeln.

Geben Sie nicht nur rohe Provider-Fehler zurück. Sie ändern sich häufig, enthalten oft irrelevante Formulierungen und manchmal Anfragedaten, die Sie einem Agenten nicht übergeben sollten. Bewahren Sie den ursprünglichen Status, Body und die Header in geschützten Diagnosedaten auf. Geben Sie dem Aufrufer stattdessen ein stabiles, bewusst kleines Ergebnis zurück.

Bauen Sie die Matrix um Vorgänge und Belege herum auf

Eine nützliche Matrix verbindet jeden Vorgang mit den Fehlermodi, die seine Bedeutung verändern können. Listen Sie zunächst Tools auf, die lesen, erstellen, aktualisieren, löschen, auslösen oder ausführen. Ein Lesevorgang mit Timeout braucht eine andere Wiederherstellungsregel als ein Befehl, der einen Produktionshost verändert.

Verwenden Sie diese Matrix als Ausgangspunkt. Ersetzen Sie die Vorgangsnamen und erwarteten Einträge durch Ihre eigenen, aber löschen Sie die Spalte «remote effect known» nicht. Sie zwingt die unangenehmen Fälle ans Licht.

Fügen Sie Zeilen für Vorgänge hinzu, die Geld ausgeben, Berechtigungen ändern, Zugangsdaten erneuern oder gemeinsam genutzte Zustände beeinflussen. Für diese Vorgänge reicht nicht nur eine Timeout-Zeile. Testen Sie einen Timeout, bevor Bytes den Prozess verlassen, nachdem die Anfrage-Header gesendet wurden, nachdem der Dienst die Anfrage angenommen hat und während ein Antwort-Body eintrifft. Die genauen Injektionspunkte hängen vom Protokoll ab, aber wenn Sie sie zu einem allgemeinen Fall «Timeout» zusammenfassen, verlieren Sie das Verhalten, das Sie überprüfen müssen.

Jede Zeile braucht vier Zusicherungen:

1. Prüfen Sie die Ergebniskategorie des Tools und die Retry-Anweisung.
2. Prüfen Sie die nächste Aktion des Agenten, einschließlich dessen, dass er keinen destruktiven Retry improvisiert.
3. Prüfen Sie den entfernten Zustand oder den dokumentierten Grund, warum er unbekannt bleibt.
4. Prüfen Sie, dass die Ereignisspur die Korrelations-ID und das beobachtete Ergebnis enthält.

Das ist mehr Arbeit, als nur ok == false zu prüfen. Es erkennt auch die Fehler, die wichtig werden, nachdem ein Agent bereits mehrere Aktionen ausgeführt hat.

Abgelaufene Zugangsdaten und abgelehnte Aktionen brauchen unterschiedliche Wiederherstellung

Ein abgelaufener oder widerrufener Zugang beweist, dass die Authentifizierung fehlgeschlagen ist. Eine abgelehnte Aktion beweist, dass der Aufrufer authentifiziert wurde, aber keine Berechtigung für diesen Vorgang besitzt, sofern ein Provider den Unterschied nicht absichtlich verbirgt. Wenn beides als «Zugriff fehlgeschlagen» behandelt wird, verhält sich der Agent falsch.

RFC 9110 definiert 401 als nicht authentifizierte Anfrage und verlangt vom Server eine WWW-Authenticate-Challenge. 403 bezeichnet die Ablehnung der Anfrage, auch wenn der Server den Grund nicht offenlegt. Provider halten diese Unterscheidung nicht immer sauber ein, deshalb sollten Sie die tatsächliche Antwort des Providers testen. Ihr Tool sollte die beobachteten Belege dennoch in getrennte Kategorien abbilden, sofern dies ehrlich möglich ist.

Verwenden Sie für einen Test mit abgelaufenen Zugangsdaten einen Zugang, der beim Setup akzeptiert und beim eigentlichen Aufruf abgelehnt wurde. Eine künstliche Zeichenfolge, die der Dienst nie erkannt hat, testet nur den Pfad für ungültige Zugangsdaten. Sie wollen Caches, Erneuerungslogik und Fehlerzuordnungen erkennen, die sich anders verhalten, sobald ein Zugriffstoken abgelaufen ist.

Eine einfache Fixture kann beide Fälle ausdrücken, ohne ein Geheimnis offenzulegen:

cases:
  - id: expired-token
    request:
      method: POST
      path: /v1/releases
    fixture_response:
      status: 401
      headers:
        www-authenticate: Bearer error="invalid_token"
      body: {"error":"token_expired"}
    expect:
      category: authentication_failed
      retry: never
      secret_in_result: false

  - id: denied-release
    request:
      method: POST
      path: /v1/releases
    fixture_response:
      status: 403
      body: {"error":"insufficient_scope"}
    expect:
      category: authorization_denied
      retry: never
      secret_in_result: false

Die Zusicherung secret_in_result erkennt einen Fehler, der bei hektischer Fehlersuche auftaucht: Der Code hängt den ausgehenden Authorization-Header oder ein Konfigurationsobjekt an eine Exception. Testen Sie die serialisierte Tool-Ausgabe, die Trace-Ausgabe und jedes Transkript, das den Agenten erreicht. Eine Redigierung in einem Logger schützt keinen anderen Logger.

Lassen Sie den Agenten nicht «ein anderes Zugangstoken ausprobieren», sofern Ihr System ihm nicht ausdrücklich eine eigene, autorisierte Identität dafür bereitstellt. Eine blinde Auswahl von Zugangsdaten kann eine Berechtigungsgrenze überschreiten und dabei wie eine Lösung für ein Verfügbarkeitsproblem aussehen. Ein Test sollte beweisen, dass ein Authentifizierungsfehler den Lauf stoppt oder ihn an den genehmigten menschlichen Wiederherstellungspfad weiterleitet.

Fehlerhafte Daten brauchen einen Vertragstest, keinen Parser-Test

Fehlerhafte Daten umfassen gültiges JSON, das Ihr Code nicht sicher verwenden kann. Ungültige Syntax ist der einfache Fall. Produktionsfehler entstehen häufiger, wenn ein Feld seinen Typ ändert, eine benötigte ID verschwindet, eine Fehlerstruktur eine Erfolgsstruktur ersetzt oder eine Antwort abgeschnitten wird, nachdem ein Proxy die Verbindung schließt.

Die Spezifikation JSON-RPC 2.0 trennt Parse-Fehler (-32700) von ungültigen Anfragen (-32600). Diese Trennung ist hilfreich, weil sie unlesbare Bytes von einer lesbaren, aber protokollwidrigen Nachricht unterscheidet. Wenden Sie dieselbe Disziplin auf Ihre fachlichen Antworten an: Ein erfolgreicher Parser beweist nicht, dass die Antwort den Tool-Vertrag erfüllt.

Schreiben Sie für jede Provider-Antwort, die Sie verarbeiten, Fixtures, die jeweils eine Annahme verletzen:

• Ersetzen Sie eine String-ID durch null, eine Zahl und ein Objekt.
• Lassen Sie ein Feld weg, das spätere Tool-Aufrufe für den Abgleich benötigen.
• Geben Sie einen Erfolgsstatus mit einem fehlerförmigen Body zurück.
• Geben Sie einen Fehlerstatus mit einem HTML-Body oder einem abgeschnittenen JSON-Dokument zurück.
• Duplizieren Sie ein Element oder ändern Sie die Reihenfolge, wenn Ihr Code das erste Element auswählt.

Prüfen Sie anschließend das genaue Verhalten. Das Tool sollte das fehlerhafte Feld oder die Vertragsbedingung in geschützten Diagnosedaten benennen, dem Agenten malformed_response zurückgeben und keine nachfolgende Änderung auf Grundlage geratener Werte ausführen.

Ein häufiges, harmlos wirkendes Muster lautet: response.id || request.id. Es hält einen Workflow am Laufen, wenn ein Provider id weglässt, kann aber ein Update oder eine Löschung an einem falschen Objekt auslösen, wenn sich Anfrage-ID und Antwort-ID unterscheiden. Testen Sie, dass eine fehlende Identität in der Antwort den Vorgang stoppt. Ein fehlgeschlagener Workflow ist billiger als ein falscher Schreibvorgang.

MCP-Tool-Clients brauchen dieselbe Sorgfalt. Das Ergebnisformat des Model Context Protocol unterstützt das Signal isError für einen Fehler auf Tool-Ebene. Verwenden Sie es, wenn das Tool seine zugesagte Arbeit nicht abschließen kann, aber halten Sie den Inhalt des Ergebnisses konkret genug, damit ein Agent einen sicheren Pfad wählen kann. Tarnen Sie eine fehlerhafte Upstream-Antwort nicht als normalen Text, der mit «Error:» beginnt. Viele Clients behandeln das als erfolgreiche Tool-Ausführung und überlassen dem Agenten die Interpretation.

Timeouts sind nach Beginn eines Schreibvorgangs unklar

Ein Timeout sagt, dass Ihr Zeitlimit abgelaufen ist. Es sagt nicht, in welchem Zustand sich der entfernte Vorgang befindet. Das klingt offensichtlich, bis eine Retry-Schleife eine verlorene Antwort stillschweigend in eine doppelte Rechnung, zwei Deployments oder einen zweiten Neustart verwandelt.

Testen Sie das Timeout-Verhalten an der Grenze, an der die Gewissheit wechselt. Ihr Fehler-Injektor oder Fake-Dienst sollte jede Phase protokollieren:

case=C05 request_id=case-http-005 received=true
case=C05 request_id=case-http-005 mutation_committed=true
case=C05 response_write=delayed
client case=C05 deadline_exceeded=true

Die erwartete Zusicherung lautet nicht «Client hat Timeout erhalten». Sie lautet, dass der Client outcome_unknown zurückgibt, kein zweites POST ausführt und vor dem Fortfahren eine Statusabfrage oder einen Idempotenzmechanismus verwendet.

Idempotenz-Token helfen nur, wenn die entfernte API sie für den betreffenden Vorgang dokumentiert und berücksichtigt. Testen Sie sie als vollständige Sequenz: Senden Sie eine Anfrage mit einem eindeutigen Token, verzögern Sie die erste Antwort, bis der Aufrufer aufgibt, senden Sie dasselbe Token über den Wiederherstellungspfad und prüfen Sie anschließend, dass der Dienst einen logischen Vorgang meldet. Behaupten Sie keine Idempotenz, nur weil Sie einen Header hinzugefügt haben, den ein Provider ignoriert.

Bei Vorgängen ohne Abgleich-Endpunkt oder Idempotenz-Unterstützung sollte das Tool dies im Ergebnis angeben. Die sichere Aktion kann darin bestehen, zu stoppen und eine Person zur Prüfung des entfernten Systems aufzufordern. Das ist kein Fehler der Entwicklung. Gewissheit vorzutäuschen, weil ein Workflow fortgesetzt werden soll, ist einer.

Legen Sie Timeouts nach Möglichkeit pro Phase fest: Verbindung, Schreiben der Anfrage, erstes Antwortbyte und gesamte Dauer des Vorgangs. Ein einziges großes Zeitlimit verbirgt, ob ein Peer nie eine Verbindung angenommen oder einen Schreibvorgang angenommen und anschließend blockiert hat. Ihre Tests müssen nicht jede Phase dem Agenten offenlegen, aber die Diagnosedaten brauchen genug Details, damit ein Betreiber das Ereignis nachvollziehen kann.

Unterbrochene entfernte Befehle müssen die Ungewissheit erhalten

Ein SSH-Befehl hat ein Fehlerfenster, das HTTP-Entwickler häufig unterschätzen. Der Client kann den Befehl senden, die entfernte Shell kann ihn starten und die Verbindung kann anschließend schließen, bevor der Aufrufer einen Exit-Status erhält. Ein Absturz des lokalen Prozesses oder eine verlorene Netzwerkroute macht eine Arbeit, die der entfernte Host bereits begonnen hat, nicht rückgängig.

OpenSSH dokumentiert, dass sein Client den Exit-Status des entfernten Befehls zurückgibt, wenn er einen erhalten kann. Bricht der Transport zuerst ab, besitzt der Aufrufer diesen Status nicht. Testen Sie diesen Fall gezielt, statt einen Exit-Code des lokalen Prozesses ungleich null als Beweis dafür zu behandeln, dass der entfernte Befehl fehlgeschlagen ist.

Erstellen Sie einen entfernten Testbefehl, der eine Startmarkierung schreibt, wartet, eine Abschlussmarkierung schreibt und ein erkennbares Ergebnis ablegt. Beenden Sie anschließend den lokalen Transport während der Wartezeit. Beschränken Sie dies auf einen isolierten Host oder Container, den Sie selbst kontrollieren.

# remote command used only in an isolated test environment
id="case-ssh-017"
printf '%s start\n' "$id" >> /tmp/agent-tool-test.log
sleep 20
printf '%s complete\n' "$id" >> /tmp/agent-tool-test.log

Führen Sie den Befehl über denselben SSH-Pfad aus, den das Tool verwendet, warten Sie, bis die Startmarkierung erscheint, und beenden Sie dann den lokalen Helfer. Prüfen Sie nach Ablauf der Wartezeit die Protokolldatei. Führen Sie den Test zweimal aus: einmal, wenn der entfernte Prozess abschließt, und einmal, wenn die entfernte Seite ihn nach der Startmarkierung beendet. Beide Fälle erzeugen lokal eine Unterbrechung, verlangen aber eine unterschiedliche Wiederherstellung.

Entwerfen Sie für Befehle, die den Zustand ändern, zuerst einen Abgleichsbefehl und erst danach einen Retry. Ein Dienstneustart könnte die Prozesslaufzeit oder eine Deployment-Version abfragen. Eine Paketinstallation könnte die installierte Version prüfen. Ein Befehl, der sich nicht abgleichen lässt, sollte nach einer Unterbrechung ausdrücklich menschliche Bearbeitung erfordern.

Vermeiden Sie Shell-Snippets, die teilweise ausgeführte Vorgänge hinter &&-Verkettungen und vager Ausgabe verstecken. Geben Sie eine dauerhafte Vorgangs-ID aus, bevor der verändernde Teil beginnt, und verwenden Sie diese ID bei späteren Prüfungen. Kann die entfernte Umgebung keine Markierung speichern, hat das Tool keine Grundlage, einem Agenten mitzuteilen, dass ein Retry sicher ist.

Menschliche Ablehnungen sind ein normales Ergebnis, kein fehlerhafter Test

Wenn eine Person eine Aktion ablehnt, sollte ein eigenes Ergebnis erzeugt werden, das diesen Aktionspfad sauber beendet. Teams testen häufig, ob ein Freigabebildschirm erscheint, und vergessen den Ablehnungspfad. Dann wiederholen Agenten die Anfrage, formulieren sie neu oder melden eine Freigabeverweigerung fälschlich als Netzwerkproblem.

Testen Sie die Ablehnung an jeder von Ihnen bereitgestellten Berechtigungsgrenze. Prüfen Sie, dass das Tool nach einer Ablehnung keine Verbindung zum entfernten Dienst herstellt. Prüfen Sie, dass es eine Freigabe nicht für einen späteren Prozess oder eine spätere Aktion behält, die eine neue Entscheidung erfordert. Prüfen Sie, dass der Agent eine Formulierung erhält, die er verwenden kann, ohne die Ablehnung als Einladung zu einem Umgehungsversuch zu verstehen.

Sallyports Tresor-Gate verweigert jede Aktion, solange es gesperrt ist. Sitzungs- und Einzelaufruf-Freigaben machen diese Entscheidungen testbar, ohne Zugangsdaten in den Agentenprozess zu legen. Diese Trennung ist hilfreich, weil ein gesperrter Tresor, eine abgelehnte Sitzung und eine verweigerte Einzelfreigabe einen Vorgang aus jeweils unterschiedlichen Gründen stoppen können.

Freigabeermüdung ist selbst ein Testfehler. Wenn ein harmloser Lesevorgang während eines normalen Laufs wiederholt nachfragt, werden Menschen freigeben, ohne zu lesen. Wenn ein destruktiver Aufruf versehentlich eine weitreichende Freigabe übernimmt, erhalten Menschen den erwarteten Entscheidungspunkt nie. Testen Sie neben dem Vorhandensein auch Anzahl, Zeitpunkt und Umfang der Anfragen.

Verwenden Sie einen Testagenten, der eine freigegebene Aktion, eine abgelehnte Aktion und eine Aktion nach dem Beenden des Prozesses versucht. Der letzte Aufruf erkennt Freigabestatus, die über die vorgesehene Sitzung hinaus erhalten bleiben. Simulieren Sie dies nicht nur durch das Umschalten eines Booleans im Speicher. Starten Sie einen neuen Prozess, damit der Test denselben Lebenszyklus nutzt wie die tatsächlichen Benutzer.

Protokolle müssen erklären, was geschah, ohne Zugang offenzulegen

Ein nützlicher Fehlerdatensatz ermöglicht die Rekonstruktion der Ursache: Welcher Agentenlauf hat welchen Vorgang versucht, welche Anfrage-ID wurde verwendet, was hat das entfernte System beobachtet, was hat das Tool zurückgegeben und was hat der Agent als Nächstes getan? Die Zugangsdaten, die den Aufruf autorisiert haben, sollten darin nicht stehen.

Protokollieren Sie ein Ereignis an jedem Punkt, an dem sich die Antwort ändern kann. Halten Sie bei einem zeitlich begrenzten Schreibvorgang die Erstellung der Anfrage, den Versandbeginn, die Annahme durch die entfernte Seite, sofern Ihre Fixture dies melden kann, den Ablauf des Zeitlimits, den Abgleichsversuch und die abschließende Klassifizierung fest. Fügen Sie eine Korrelations-ID ein, die vor der ersten Netzwerkaktion erzeugt wurde. Leiten Sie sie nicht aus einem Geheimnis ab und verwenden Sie sie nicht für mehrere Vorgänge.

Dieses Format eignet sich für einen lokalen Test-Harness:

{"time":"2025-04-12T10:18:03Z","case":"C05","id":"case-http-005","event":"dispatch_started"}
{"time":"2025-04-12T10:18:03Z","case":"C05","id":"case-http-005","event":"remote_committed"}
{"time":"2025-04-12T10:18:08Z","case":"C05","id":"case-http-005","event":"client_timeout"}
{"time":"2025-04-12T10:18:08Z","case":"C05","id":"case-http-005","event":"result","category":"outcome_unknown"}

Ihre Zusicherung kann anschließend Client- und Fixture-Einträge anhand von id vergleichen. Wenn die Fixture remote_committed meldet und das Tool confirmed_failure, muss der Test fehlschlagen. Diese Abweichung zeigt eine unsichere Behauptung auf, selbst wenn alle Codepfade ein ordentliches Fehlerobjekt zurückgegeben haben.

Für eine manipulationssichere Spur sollten Sie auch die Prüfung testen. Sallyport erzeugt seine Sitzungs- und Aktivitätsdatensätze aus einem verschlüsselten, hashverketteten Audit-Log. sp audit verify prüft die Kette offline, ohne einen Tresorschlüssel zu benötigen. Ein Fehlertest sollte eine bekannte Ereignisfolge hinzufügen, sie prüfen, einen kopierten Eintrag verändern und feststellen, dass die Prüfung für die veränderte Kopie fehlschlägt.

Schreiben Sie standardmäßig keine vollständigen Request-Bodies in gewöhnliche Protokolle. Anfragedaten enthalten häufig personenbezogene Daten, Quellcode oder Token, die ein unvorsichtiger Aufrufer eingebettet hat. Protokollieren Sie den Vorgangsnamen, die Zielklassifizierung, die Korrelations-ID, die Ergebniskategorie und einen geschützten Verweis auf Diagnosedaten. Erweitern Sie die Erfassung nur in einer kontrollierten Testumgebung, deren Fixtures Sie kennen.

Testen Sie das Wiederherstellungsverhalten des Agenten, nicht nur den Adapter

Unit-Tests beweisen, dass ein Adapter 403 auf authorization_denied abbildet. Sie beweisen nicht, dass ein Agent nach Erhalt dieses Ergebnisses stoppt. Führen Sie eine kleine End-to-End-Suite mit einer deterministischen Agentenanweisung und einem Fake-Dienst aus, der das injizierte Ereignisprotokoll offenlegt.

Geben Sie jedem Lauf eine begrenzte Aufgabe und eine klare Grenze. Zum Beispiel: einen Datensatz erstellen, ihn zurücklesen und anschließend eine Notiz anhängen. Verzögern Sie die Antwort auf das Erstellen, nachdem der Datensatz bereits gespeichert wurde. Das korrekte Verhalten des Agenten besteht darin, anhand der Korrelations-ID oder des Idempotenz-Tokens zu prüfen, ob der Datensatz existiert, bevor er einen zweiten Erstellungsversuch unternimmt. Der Test muss fehlschlagen, wenn ein weiterer Datensatz erstellt wird, selbst wenn die Aufgabe später erfolgreich abgeschlossen wird.

Halten Sie den Agenten-Prompt für diese Suite stabil. Wenn Sie Prompt, Tool-Vertrag, Fixture-Verhalten und Modellversion gleichzeitig ändern, sagt ein Fehler nur wenig aus. Zeichnen Sie das Tool-Transkript und den nächsten Aufruf des Agenten auf und vergleichen Sie sie mit den erlaubten Übergängen:

create -> outcome_unknown -> lookup_by_request_id -> found -> attach_note
create -> outcome_unknown -> create

Der erste Übergang ist nur erlaubt, wenn die Abfrage die ursprüngliche Erstellung bestätigt. Der zweite ist ein Fehler. Diese Zustandsprüfung ist nützlicher, als zu bewerten, ob die abschließende Textantwort vernünftig klang.

Führen Sie deterministische Matrixfälle bei jeder Änderung am Tool-Code, an Ergebnisschemata, der Berechtigungsbehandlung oder der Retry-Logik aus. Wiederholen Sie Unterbrechungsfälle in isolierter Infrastruktur, weil die Ablaufplanung eine Rolle spielt. Wenn ein neuer Vorfall auftritt, fügen Sie der Matrix vor der Behebung die kleinste reproduzierbare Variante hinzu. Andernfalls kehrt derselbe attraktive, falsche Wiederherstellungspfad beim nächsten Refactoring zurück.

Der Maßstab für ein Tool ist nicht, dass es nach jedem Fehler weiterläuft. Der Maßstab ist, dass es die eigenen Erkenntnisse wahrheitsgemäß beschreibt, Beweise hinterlässt und sich weigert, Ungewissheit in eine zweite destruktive Aktion zu verwandeln.