So prüfen Sie, ob ein KI-Agent eine Aufgabe wirklich erledigt hat
Ein praktischer Abnahmeprozess für Claude Code, Codex und andere Agenten: Soll-Endzustand definieren, Zielsysteme zurücklesen, Ergebnis einstufen und nur fehlende Arbeit erneut ausführen.
Inhalt
Sie haben Claude Code, Codex oder einen anderen Agenten beauftragt, Dateien zu sortieren, eine Tabelle zu aktualisieren oder Geschäftsdatensätze anzulegen. Der Agent meldet „erledigt“, und es erscheint kein offensichtlicher Fehler. Das zeigt nur, dass der Lauf beendet wurde; der Geschäftserfolg muss separat abgenommen werden.
Eine belastbare Abnahme beginnt mit dem erwarteten Endzustand. Danach lesen Sie die tatsächlichen Daten aus den Zielsystemen zurück und prüfen fehlende ebenso wie unerwartete Nebenwirkungen. Ist das Ergebnis unbekannt, suchen Sie zuerst nach vorhandenen Datensätzen, statt den gesamten Ablauf erneut zu starten.
Warum ein erfolgreicher Tool-Aufruf keine abgeschlossene Aufgabe beweist
Beruhigende Zwischensignale gibt es viele: Ein Tool liefert success, ein Prozess endet mit Code 0, ein Bericht wird erzeugt oder die letzte Antwort behauptet, alle Schritte seien abgeschlossen. Offen bleiben dennoch die entscheidenden Fragen:
- Wurde die richtige Datei am richtigen Ort mit dem richtigen Inhalt gespeichert?
- Enthält die Tabelle oder Datenbank wirklich alle vorgesehenen Datensätze?
- Wurden Zeilen, Aufträge, Benachrichtigungen oder Dateien doppelt angelegt?
- Läuft ein asynchroner Job noch, oder wurde eine Schreiboperation später zurückgerollt?
- Hat der Agent einen Datensatz nur gelesen und die notwendige Änderung ausgelassen?
Microsofts öffentliches ThinkingBox-Bench v1.0 ist ein synthetischer Forschungsbenchmark, keine Produktions-Fehlerquote. Er umfasst 507 ausführbare Aufgaben aus fünf Geschäftsdomänen. Ein Versuch gilt nur dann als bestanden, wenn Prüfungen des Endzustands, der Nebenwirkungen und festgelegter Dialogeigenschaften erfolgreich sind. Die getaggte Dokumentation vergibt keine Teilpunkte. „Teilweise“ und „nicht verifiziert“ sind hier betriebliche Abnahmestatus, keine Benchmark-Wertungen.
Definieren Sie vor dem Lauf einen Abnahmevertrag
Die Prüfung wird einfacher, wenn die Endbedingungen vorab feststehen:
| Punkt | Was festgelegt wird | Beispiel |
|---|---|---|
| Pflichtzustand | Objekte, Felder, Mengen und Beziehungen | 120 Dateien umbenannt; 120 eindeutige IDs in der Tabelle |
| Verbotener Zustand | Änderungen und Effekte, die nicht auftreten dürfen | Keine Quelldatei löschen, keine zweite Mail, kein anderes Tabellenblatt ändern |
| Maßgebliche Quelle | Das System, dessen gespeicherter Zustand entscheidet | Zielordner, echte Zellen, CRM oder Ticketstatus |
| Wiederholungsidentität | Schlüssel für genau diese Geschäftsoperation | Eine auf die aktuelle Aufgabe/Operation bezogene operation_id oder Bestellnummer; Kunden-ID, Dateiname, Objekt-ID und Manifest-Hash bezeichnen Abfrageobjekte und belegen diese Operation allein nicht |
Beschreiben Sie das Geschäftsergebnis, nicht die Aktivität des Agenten. „Das Tabellen-Tool wurde aufgerufen“ ist kein Endzustand. „Das Zielblatt enthält 120 Zeilen, eindeutige Kunden-IDs und abgestimmte Summen“ ist einer.
Legen Sie auch die Reihenfolge irreversibler Schritte fest. Führen und prüfen Sie zuerst reversible Datei- und Datensatzänderungen; senden Sie erst danach E-Mail, Bestellung oder Zahlung. Ein früher Fehler darf keine blinde Wiederholung eines duplikatempfindlichen Schritts erzwingen.
Bewahren Sie die minimale Ausführungsevidenz auf
Speichern Sie die Informationen, die einen Lauf seinen Schreibvorgängen zuordnen:
- ursprünglicher Auftrag, erlaubter Umfang und erwarteter Endzustand;
- Start- und Endzeit, Arbeitsverzeichnis und Zielmanifest;
- Sitzungs-ID des Agenten und zurückgegebene job ID;
operation_idoder einen anderen eindeutigen Geschäftsschlüssel;- vorherige Mengen, Versionen, Schlüsselfelder oder Hashes;
- Fehler, Timeouts, Berechtigungsverweigerungen und ausgelassene Schritte.
Private Modellgedanken sind für die Abnahme nicht nötig. Reproduzierbare Eingaben, Identitäten, Umfang und Zielzustand sind es. API-Schlüssel, Tokens und Kundengeheimnisse gehören nicht in das Protokoll.
Warten Sie auf den Endzustand des Systems, nicht auf die letzte Antwort
Uploads, Massenimporte, Berichte und externe Schreibvorgänge können nach der Agentenantwort weiterlaufen. Speichern Sie die job ID und fragen Sie das maßgebliche System in sinnvollen Abständen ab, bis Erfolg, Fehler, Abbruch oder Timeout eindeutig sind.
Protokollieren Sie Fortschritt und letzte Aktualisierung. Bei eventual consistency legen Sie ein Zeitfenster zur Stabilisierung fest und lesen danach erneut. Eine frische Schreiboperation ist nicht automatisch gescheitert, nur weil sie noch nicht sichtbar ist; unbegrenzt warten sollten Sie ebenfalls nicht. Bleibt das Ergebnis unklar, lautet der Status nicht verifiziert, nicht „nicht ausgeführt“.
Lesen Sie das Ergebnis in sechs Ebenen zurück
1. Existiert das Objekt und gehört es zu diesem Lauf?
Prüfen Sie Pfad, Dateiname, Datensatz-ID, Änderungszeit und Version. Eine ältere Datei mit gleichem Namen ist kein Beweis. Ein neuer Datensatz beim falschen Kunden ebenso wenig.
2. Stimmen Inhalt und Geschäftsinvarianten?
Prüfen Sie Anzahl, Eindeutigkeit, Summen, Pflichtfelder, Beziehungen und Format. Bei Tabellen sind das IDs, Zeilen und Summen; bei Dateien Manifest, Größe, Hash oder Stichprobe; bei Geschäftsdaten Status, Betrag, Eigentümer und Zeitraum.
3. Verwenden Sie das maßgebliche System
Agentenzusammenfassung, Terminalausgabe und lokaler Cache sind Hilfsbelege. Die Abnahme kommt aus dem System, das das Ergebnis speichert: Dateidienst, echte Tabellenzellen, CRM, Tickets, Datenbank oder Zahlungsbuch.
4. Prüfen Sie alle erforderlichen Nebenwirkungen
Eine Aufgabe kann Datei, Indexaktualisierung, verknüpften Datensatz und Benachrichtigung verlangen. Prüfen Sie jedes Element mit derselben Geschäftsidentität. Fehlt ein Pflichtbestandteil, ist der Auftrag teilweise erledigt.
5. Suchen Sie nach unerwünschten Effekten
Prüfen Sie doppelte Zeilen und Datensätze, zusätzliche E-Mails, gelöschte Dateien, Änderungen außerhalb des Umfangs und Schreibvorgänge am falschen Objekt. Ein unerwarteter Effekt muss die automatische Wiederholung stoppen.
6. Stimmen Sie Systeme miteinander ab
Wenn die Aufgabe Dateien, Tabellen und Anwendungen umfasst, grenzen Sie jede Abfrage zuerst durch die aktuelle operation_id oder den Aufgabenbereich ein; prüfen Sie danach Kunden- und Objekt-IDs, den geforderten Status oder die Version sowie das Manifest. Ein passender Objektbezeichner beweist nicht, dass diese Operation erfolgt ist. Vergleichen Sie ID-Mengen und listen Sie fehlende sowie zusätzliche Elemente.
Verwenden Sie vier betriebliche Status
| Status | Wann er gilt | Nächster Schritt |
|---|---|---|
| Abgeschlossen | Alle Pflichtbedingungen sind verifiziert und kein unzulässiger Zusatzeffekt besteht | Evidenz speichern und schließen |
| Teilweise | Ein Teil ist bestätigt, konkrete Elemente fehlen | Nur das Fehlende reparieren |
| Nicht verifiziert | System nicht erreichbar, noch in Stabilisierung oder Schreibstatus unklar | Abfragen oder warten; nicht blind wiederholen |
| Unerwarteter Effekt | Duplikat, Löschung, Änderung außerhalb des Umfangs oder falsches Ziel | Automatisierung stoppen und prüfen lassen |
„Nicht verifiziert“ bedeutet nicht „fehlgeschlagen“. Es bedeutet, dass das Ergebnis noch unbekannt ist.
Entscheiden Sie die Wiederholung in dieser Reihenfolge
- Zuerst diese Operation abfragen. Grenzen Sie die Suche in der maßgeblichen Quelle mit
operation_idoder Bestellnummer auf die aktuelle Aufgabe ein und kombinieren Sie Dateiname, Kunden-/Objekt-ID sowie geforderten Status oder Version. Das Objekt allein belegt diese Speicherung nicht. - Die abgeschlossene Grenze bestimmen. Listen Sie richtige und fehlende Objekte.
- Idempotent reparieren. Kann derselbe Schlüssel kein zweites Ergebnis erzeugen, senden Sie nur Fehlendes. Ist die Idempotenz unbekannt, wiederholen Sie keine irreversible Aktion automatisch.
- Datensätze, Benachrichtigungen und Transaktionen trennen. Ist der Datensatz vorhanden und nur die Mail fehlgeschlagen, senden Sie nur die Mail. Ist die Mail raus und der Datensatz unklar, fragen Sie zuerst ab.
- Bei unerwarteten Effekten stoppen. Falsche Objekte reparieren oder zurückrollen, bevor ein Mensch die Fortsetzung freigibt.
Kurzregel: Nur nach bestätigter Abwesenheit wiederholen; bei Teilschreibvorgängen nur Fehlendes ergänzen; bei unbekanntem Ergebnis zuerst fragen; bei falschem Zustand stoppen.
Beispiel: Dateien, Tabelle und CRM
Dies ist ein hypothetisches Beispiel, kein Kundenincident und kein reproduziertes Produktionsprotokoll.
Ein Agent soll 120 Dateien umbenennen, 120 Tabellenzeilen schreiben, 12 Zusammenfassungen im CRM erstellen und eine Abschlussmail senden. Das Zurücklesen zeigt korrekte Dateien und Zeilen, nur 9 CRM-Datensätze und eine bereits gesendete Mail.
Der richtige Status ist teilweise. Eine sichere Wiederherstellung:
- CRM mit
operation_idund den 12 erwarteten Geschäftsschlüsseln abfragen; - die 9 vorhandenen erkennen und nur die 3 fehlenden mit Deduplizierungsschlüsseln anlegen;
- die abschließenden 12 CRM-IDs mit Datei- und Tabellenzusammenfassungen abgleichen;
- Dateien nicht erneut umbenennen, 120 Zeilen nicht neu schreiben und die Mail nicht erneut senden.
Kann das CRM nicht abgefragt werden, bleibt der Status nicht verifiziert. Ein kompletter Neustart könnte Duplikate und eine zweite Benachrichtigung erzeugen.
Kopierbare Abnahmeakte
| Feld | Inhalt |
|---|---|
| Aufgabe und Umfang | Aktion, erlaubte Ziele und verbotene Änderungen |
| Erwarteter Endzustand | Objekte, Felder, Mengen, Beziehungen und Status |
| Ausführungsidentität | Sitzung, job ID, operation_id und Geschäftsschlüssel |
| Maßgebliche Evidenz | Zielobjekte, Abfragezeit, IDs und Links |
| Fehlende Effekte | Abwesende Pflichtobjekte oder Aktionen |
| Zusätzliche Effekte | Duplikate, Löschungen, Fremdänderungen oder Extrabenachrichtigungen |
| Abnahmestatus | Abgeschlossen, teilweise, nicht verifiziert oder unerwarteter Effekt |
| Nächste Aktion | Schließen, warten, reparieren, wiederholen, zurückrollen oder übergeben |
Fügen Sie ID-Listen, Differenzen und Abfragezeiten an. Nur „geprüft“ zu notieren reicht nicht.
BetterToken liefert die Modellverbindung, nicht die Ergebnisabnahme
Für Claude Code über BetterToken gilt der aktuelle Leitfaden zur Einrichtung und Verbindungsprüfung. Eine normale Antwort ohne Verbindungs- oder Modellfehler bestätigt die Konfiguration; sie beweist nicht, dass Datei, Tabelle oder externer Datensatz den Sollzustand erreicht haben.
Sitzungskennungen helfen, die Ausführung zu finden. Die Abnahme erfolgt trotzdem in den Zielsystemen. Modellverfügbarkeit, erfolgreiche Antwort oder Tokenverbrauch sind kein Nachweis für den Geschäftsabschluss.
Schließen Sie erst nach drei Fragen
- Sehe ich den erwarteten Endzustand im maßgeblichen System und nicht nur in der Agentenbeschreibung?
- Habe ich fehlende Ergebnisse, Duplikate und andere unerwartete Effekte geprüft?
- Werde ich bei unbekanntem Ergebnis zuerst per eindeutigem Geschäftsschlüssel suchen?
Schließen Sie die Aufgabe nur bei drei klaren Antworten. Kopieren Sie vor dem nächsten risikoreichen Lauf die Abnahmeakte und tragen Sie Endzustand, Verbote und Wiederholungsidentität ein. Das ist günstiger, als eine doppelte Geschäftsoperation später zu entwirren.
