Tool-Ergebnisse von KI-Agenten richtig deuten

Ein Agent prüft einen Datenbestand und meldet: „Es fehlt nichts.“ Das klingt zurückhaltend. Tatsächlich ist es eine weitreichende Aussage: Die relevanten Datensätze wurden gelesen, die Prüfung umfasste den vorgesehenen Bereich, und die erhobenen Informationen belegen, dass nichts fehlt.

Ich möchte, dass diese Aussage bereits begründet ist, bevor ein Modell den Satz formuliert. Eine leere Liste, ein abgebrochener Abruf und eine nicht verfügbare Quelle dürfen nicht dasselbe bedeuten. Selbst das Lesen aller Seiten ist eine schwächere Zusicherung als das Lesen eines konsistenten Datenstands.

Das wird wichtiger, wenn Agenten Prüfaufgaben übernehmen. FloQast kündigte am 16. September unter anderem KI-Prüfungen von Buchungen und die Erkennung ungewöhnlicher Transaktionen an. Workiva stellte am 15. September Agent Studio und automatisierte Audit-Prüfungen vor. Das sind Funktionsbeschreibungen der Anbieter, keine unabhängigen Qualitätsmessungen. Sie machen eine grundlegende Frage dringlich: Welche Belege erlauben einem Agenten die Aussage, dass eine Prüfung nichts gefunden hat?

Warum braucht ein leeres Tool-Ergebnis einen Nachweis?

„Keine Probleme gefunden“ und „Probleme konnten nicht geprüft werden“ können in einer unvorsichtigen Integration dasselbe leere Array erzeugen. Eine Fehlerbehandlung liefert nach einem Timeout einen Standardwert, die Auswertung zählt dessen Elemente, und der Assistent formuliert einen sicheren Satz. Die Rechnung kann stimmen, obwohl die Schlussfolgerung unbelegt bleibt.

Der Fehler entsteht vor der Textgenerierung. Sobald eine nicht verfügbare Quelle in eine gewöhnliche leere Liste umgewandelt wurde, fehlt dem Modell die Information, um einen gescheiterten Abruf von tatsächlicher Abwesenheit zu unterscheiden. Eine Aufforderung zur Vorsicht kann diese verlorene Information nicht wiederherstellen.

Ein negatives Ergebnis braucht deshalb einen klaren Vertrag für den Abruf. Halte fest, welcher Bereich angefragt wurde, ob der Datenbestand erfolgreich gelesen wurde und welche Konsistenz die Quelle garantiert. Formuliere das Ergebnis innerhalb dieser Grenzen. „Keine fehlenden Verknüpfungen in den zurückgegebenen Datensätzen“ ist enger als „Alle Dokumente sind vorhanden“. Beides beweist nicht, dass jedes reale Dokument überhaupt in der Quelle erfasst ist.

Wie unterscheiden sich vollständige, partielle und nicht verfügbare Ergebnisse?

Trenne den Zustand des Abrufs von seinen Befunden. Ein vollständiger Abruf kann Befunde enthalten oder ohne Befund bleiben. Ein partieller Abruf kann bereits nützliche Beobachtungen liefern, aber keine Gesamtzahl für den gesamten Datenbestand belegen. Ein nicht verfügbarer Abruf liefert keine verifizierte Anzahl.

Ein Tool muss partielle Beobachtungen nicht ausgeben. Normans Leser in diesem Testlauf liefert ein nicht verfügbares Ergebnis statt einer partiellen Zusammenfassung. Das ist eine bewusste Grenze: Nachgelagerter Code erhält keine verbindliche Gesamtzahl aus einem unvollständig gelesenen Bestand. Ein anderes System könnte Teilbefunde zurückgeben, solange deren unvollständige Abdeckung ausdrücklich erhalten bleibt.

Was zeigte Normans Test der Tool-Ergebnisse?

Wir haben Normans Leser für die Dokumentenprüfung und die Zusammenfassungsfunktion lokal mit künstlichen, paginierten Antworten ausgeführt. Die echten Anwendungsfunktionen übernahmen Validierung und Aggregation. Den API-Transport ersetzten wir durch einen Mock; Konfiguration und Kontext waren isoliert. Keine Kundendatenbank, kein Modell und kein Live-Dienst waren beteiligt.

Ein akzeptierter leerer Bestand ergab die Anzahl null. Wenn eine spätere Seite mit einem Timeout ausfiel, kam ein nicht verfügbarer Status ohne Gesamtzahlen zurück. Fehlerhaft aufgebaute Seiten, wiederholte Datensatzkennungen und eine geänderte angekündigte Bestandsgröße wurden ebenfalls abgelehnt. Die Tests belegen konkretes Verhalten für die geprüften Eingaben, keine allgemeine Korrektheit der Daten.

Anschließend bauten wir in einer isolierten Kopie eine absichtlich verlustbehaftete Negativkontrolle ein: Ein nicht verfügbares Ergebnis wurde direkt vor der Aggregation durch eine leere Liste ersetzt. Dieselben Fehlerszenarien erzeugten nun gewöhnliche leere Zusammenfassungen, und die zugehörigen Assertions schlugen fehl. Das war eine bewusste Veränderung für das Experiment. Wir behaupten damit nicht, dass eine frühere produktive Version so gearbeitet hat.

Die Lehre betrifft den Erhalt von Informationen. Eine korrekte Behandlung im Leser reicht nicht, wenn der nächste Adapter einen Standardwert einsetzt. Unser Artikel über Wiederholungen fragt, welche Operation sicher erneut ausgeführt werden darf. Hier geht es darum, welchen Schluss der Empfänger aus einem abgeschlossenen Tool-Aufruf ziehen darf.

Warum beweist vollständige Paginierung keinen konsistenten Datenstand?

Es gibt eine zweite Grenze, die Fehlerbehandlung allein nicht lösen kann. Ein fiktiver Bestand enthält die Datensätze A und B. Vor einer Änderung hat A eine Dokumentverknüpfung, B dagegen keine. Danach fehlt A die Verknüpfung, während B eine besitzt. In beiden Zuständen fehlt also eine Verknüpfung.

Lies nun A aus dem früheren Zustand und B aus dem späteren. Die zusammengesetzte Antwort enthält beide Kennungen, die angekündigte Größe bleibt gleich, und beide gelieferten Datensätze besitzen eine Verknüpfung. Die Zusammenfassung meldet null. Sie beschreibt die zusammengesetzten Antworten, aber keinen der beiden ursprünglichen Zustände.

Wir haben genau diese Seitenantworten konstruiert und durch dieselben Norman-Funktionen geleitet. Der Leser akzeptierte sie. Damit ist eine Grenze seiner Prüfungen von Anzahl und Kennungen gezeigt. Es handelt sich um ein künstliches Gegenbeispiel, weder um einen beobachteten Produktionsvorfall noch um eine Messung der Häufigkeit gleichzeitiger Änderungen.

Eine stabile Sortierung hilft beim Durchlaufen eines Bestands. Sie friert veränderliche Werte aber nicht ein. Eine stärkere Zusicherung erfordert einen Mechanismus an der Quelle, etwa einen an einen Datenstand gebundenen Cursor oder einen versionierten Export. Fehlt diese Garantie, beschreibe die Beobachtung als Abruf über ein Zeitintervall. Stelle sie nicht stillschweigend als Aussage über einen einzigen Zeitpunkt dar.

Wie sollte ein Agenten-Tool ein nicht verfügbares Ergebnis melden?

Verwende eine Ergebnisstruktur, in der Abwesenheit und Unsicherheit verschiedene Zustände sind. Das folgende Beispiel ist ein vorgeschlagener Anwendungsvertrag, weder Normans gespeichertes Schema noch eine MCP-Nachricht:

{
  "status": "unavailable",
  "coverage": "incomplete",
  "finding_count": null,
  "consistency": "not_established",
  "next_action": "repeat_the_read"
}

Entscheidend sind nicht die Feldnamen. Eine fehlende Messung darf nicht versehentlich zur gewöhnlichen Null werden. Definiere, welche Zustände Zahlen erlauben, verlange die Behandlung der übrigen Zustände und teste das bis zur Darstellung. Ein Schema, das widersprüchliche Kombinationen zulässt, braucht weiterhin eine semantische Validierung.

Die MCP-Spezifikation für Tools unterscheidet Protokollfehler von Ausführungsfehlern, die über isError gemeldet werden. Diese Protokollunterscheidung und der Vertrag über die Abdeckung beantworten unterschiedliche Fragen. Ein Ausführungsfehler muss als solcher kommuniziert werden. Ein erfolgreicher Aufruf braucht trotzdem genügend Kontext, um seine Daten zu interpretieren. Unser lokaler Test prüfte das Anwendungsergebnis, nicht die MCP-Serialisierung oder den Umgang eines Clients mit diesem Flag.

Was sollte der Agent bei einer unvollständigen Prüfung sagen?

Die Formulierung sollte den Belegen folgen. Nach einem fehlgeschlagenen Abruf: „Ich konnte die Prüfung nicht abschließen.“ Nach einem partiellen Abruf kennzeichnest du die Beobachtungen als unvollständig und lässt die Gesamtaussage offen. Nach einem akzeptierten Abruf nennst du den geprüften Bereich und sagst, ob ein konsistenter Datenstand gesichert war.

Das ist besonders wichtig, wenn mehrere Quellen in eine Antwort einfließen. Eine funktionierende Quelle darf eine nicht verfügbare nicht verdecken. Bewahre die einzelnen Ergebnisse, bevor du entscheidest, ob eine gemeinsame Schlussfolgerung möglich ist. Ein gut formulierter Absatz darf gemischte Evidenz nicht zu einem einzigen beruhigenden Status zusammenziehen.

Eine ähnliche Unterscheidung haben wir beim Gedächtnis von Agenten getroffen: Aufgezeichnete Aktivität beweist nicht automatisch einen nützlichen Ausgang. Hier beweisen abgerufene Datensätze nicht automatisch Vollständigkeit. Zur Aufgabe des Agenten gehört, die Grenze mitzuteilen und nicht bloß die flüssigste Interpretation einer Zahl auszuwählen.

Wie testest du Verträge für Tool-Ergebnisse?

Beginne mit einem erfolgreich gelesenen leeren Bestand als Positivfall. Unterbrich anschließend eine spätere Seite, wiederhole eine Seite, ändere die angekündigte Größe und entferne Felder, die zur Interpretation eines Datensatzes nötig sind. Prüfe sowohl den Ergebniszustand als auch das Fehlen verbindlicher Gesamtzahlen bei unvollständiger Abdeckung. Wer nur eine Fehlermeldung prüft, kann eine versehentliche Null an anderer Stelle übersehen.

Ergänze eine Negativkontrolle, die den Fehler verwirft, und prüfe, ob die Vertragstests das bemerken. Behalte außerdem das Beispiel mit gemischten Zuständen: Bestandene Paginierungsprüfungen dürfen nicht als Nachweis von Snapshot-Isolation gelten. Unser Artikel über Agent Harnesses beschreibt den Ausführungskontext. Jede Evidenzgrenze braucht aber eine eigene Assertion.

Dieser Test belegt weder das vollständige Modellverhalten noch die Konsistenz der Live-Datenbank oder den Deployment-Status. Er zeigt, wie konkrete Anwendungsfunktionen kontrollierte Eingaben interpretieren. Als Nächstes ist zu prüfen, ob Transport, Empfänger und endgültige Antwort die Unterschiede bewahren. „Nichts gefunden“ wird erst belastbar, wenn das System erklären kann, was es erfolgreich geprüft hat.