Hat der Agent wirklich abgeschlossen? So überprüfen Sie das Ergebnis, ohne sich auf seine Abschlussmeldung zu verlassen

Die Aktion ist nicht das Ergebnis

Ein Agent kann „Erledigt“ melden, obwohl das Ziel nicht erreicht wurde. Er kann auch einen Tool-Aufruf auslösen und eine Antwort erhalten, dass die Anfrage angenommen wurde – und trotzdem kann die Arbeit noch ausstehen oder unvollständig sein. Das sind unterschiedliche Aussagen, für die jeweils andere Nachweise erforderlich sind.

Es ist hilfreich, drei Zustände auseinanderzuhalten. Erstens hat der Agent eine Aktion versucht, zum Beispiel eine Anweisung zum Ändern eines Eintrags gesendet. Zweitens hat das System, bei dem die Anfrage einging, sie angenommen oder darauf geantwortet. Drittens ist der von der Person gewünschte Endzustand eingetreten und erfüllt die vereinbarten Bedingungen. Nur der dritte Zustand belegt für sich genommen, dass das Ziel erreicht wurde.

Diese Unterscheidung ist wichtig, denn eine Erfolgsmeldung kann sich nur auf einen Teil des Ablaufs beziehen. „Anfrage eingegangen“ bedeutet nicht unbedingt „Änderung gespeichert“; „Test ausgeführt“ bedeutet nicht, dass alle Anforderungen an die Änderung erfüllt sind; und „Reservierung angefragt“ ist nicht gleichbedeutend mit „Reservierung bestätigt“. Die Antwort des Agenten kann zusammenfassen, was geschehen ist, sollte aber nicht zum einzigen Beleg dafür werden, was tatsächlich geschehen ist.

Bei der Evaluation von Agenten geht es darum zu prüfen, ob Systeme, die Aktionen ausführen, eine Aufgabe zuverlässig erledigen können. Dieser Artikel behandelt eine enger gefasste Frage: Welche Nachweise reichen aus, um eine konkrete Aufgabe als abgeschlossen anzunehmen? Die folgenden Empfehlungen und Beispiele bilden eine praktische Methode ab. Sie behaupten nicht, dass es für alle Agenten und Tools ein universell gültiges Signal gibt.

Schritt 1: Die Anfrage in einen beobachtbaren Endzustand übersetzen

Formulieren Sie vor der Ausführung einer Aufgabe neu, wie die Welt am Ende aussehen soll. „Aktualisiere den Eintrag“ ist mehrdeutig: Es bleibt offen, welches Feld geändert werden soll, welcher Wert erwartet wird und ob andere Daten unverändert bleiben müssen. Auch „Ändere den Code“ legt weder das erwartete Verhalten noch die Bedingungen fest, die weiterhin erfüllt sein sollen.

Eine brauchbare Beschreibung benennt das betroffene Objekt, den gewünschten Zustand, zu wahrende Bedingungen und relevante Grenzen. Nicht jede Anfrage muss in eine ausführliche Spezifikation verwandelt werden. Unklarheiten, die die Entscheidung beeinflussen würden, ob die Aufgabe als abgeschlossen gilt, müssen jedoch geklärt werden.

Das beobachtbare Ergebnis sollte sich beschreiben lassen, ohne sich auf die Absicht des Agenten zu stützen. Legen Sie statt „Der Agent hat die Reservierung bearbeitet“ fest, was vorhanden sein müsste, damit Sie sie als bestätigt bezeichnen können. Definieren Sie statt „Der Agent hat den Code repariert“, welches erwartete Verhalten funktionieren muss und welche Prüfungen für die Änderung relevant sind.

Grenzen Sie auch ab, was nicht zum Auftrag gehört. Wenn ein Feld aktualisiert werden soll, nehmen Sie nicht an, dass der Agent weitere Felder ändern, Dritte benachrichtigen oder die gesamte Historie prüfen soll. Diese Grenze hilft, zwei entgegengesetzte Fehler zu vermeiden: eine teilweise erledigte Aufgabe als vollständig anzunehmen und den Auftrag ohne Genehmigung auszuweiten.

Schritt 2: Abnahmekriterien vor der Ausführung festlegen

Abnahmekriterien legen konkret fest, was beobachtet werden müsste, damit die Anfrage als erfüllt gilt. Legen Sie sie möglichst vor der Ausführung fest: Im Nachhinein ist es leichter, eine bequeme Ausgabe mit einem geeigneten Nachweis zu verwechseln oder den Maßstab herunterzusetzen, um ein Teilergebnis zu rechtfertigen.

Ein brauchbares Kriterium ist spezifisch und überprüfbar. „Der Eintrag ist in Ordnung“ lässt zu viel Interpretationsspielraum. „Im identifizierten Eintrag zeigt das Statusfeld den vereinbarten Wert“ benennt sowohl einen Zustand als auch ein Objekt. Wenn andere Felder unverändert bleiben müssen, sollte das als zusätzliches Kriterium formuliert werden.

Nicht jede Anforderung lässt sich mit einem einzigen Signal überprüfen. Bei einer Änderung kann wichtig sein, dass der Wert vorhanden ist und ein anderes Attribut unverändert geblieben ist. Bei einer Reservierung können sowohl die Bestätigung als auch die richtigen Details erforderlich sein. Ein Code-Test kann ein wichtiges Verhalten abdecken, beweist aber nicht allein, dass jede Anforderung des Auftrags umgesetzt wurde. Die Kriterienliste sollte die tatsächlichen Bedingungen der Anfrage abbilden und nicht nur die am einfachsten messbaren.

Bei offenen Anfragen kann zunächst eine Rückfrage nötig sein. Wenn mehrere plausible Auslegungen zu unterschiedlichen akzeptablen Ergebnissen führen, sollte der Agent nicht stillschweigend eine davon auswählen und sie später so behandeln, als wäre sie die einzig mögliche gewesen. Die vereinbarten Kriterien bestimmen auch, wann eine Aufgabe nur teilweise abgeschlossen ist und welche Informationen kommuniziert werden müssen.

Schritt 3: Nachweise auswählen, die zur Aussage passen

Der Nachweis sollte die konkrete Frage beantworten: Was erlaubt die Aussage, dass der gewünschte Endzustand vorliegt? Eine Tool-Ausgabe kann geeignet sein, um festzustellen, ob eine Anfrage bei einer bestimmten Komponente eingegangen ist. Sie belegt aber nicht unbedingt, dass das Ergebnis dauerhaft gespeichert wurde oder alle Anforderungen erfüllt. Schreiben Sie einem Signal nicht mehr Bedeutung zu, als es tatsächlich hat.

Prüfen Sie den Zustand nach Möglichkeit durch ein passendes Auslesen des betroffenen Systems oder durch eine Prüfung, die das Ergebnis direkt bewertet. Bei manchen Aufgaben kann ein automatisierter Test als Nachweis dienen, bei anderen eine sichtbare Bestätigung in der Quelle, die den betreffenden Zustand verwaltet. „Unabhängig“ bedeutet nicht immer „von einem anderen Anbieter“; es bedeutet, dass nicht allein die Aussage des Agenten als Beleg dient, der behauptet, die Aufgabe abgeschlossen zu haben.

Auch Unabhängigkeit gibt es in verschiedenen Abstufungen. Den Agenten noch einmal zu fragen, ob er fertig ist, kann lediglich seine Aussage wiederholen, statt sie zu überprüfen. Eine Ansicht des Eintrags aufzurufen kann eine Beobachtung des Zustands liefern. Dazu muss jedoch klar sein, was diese Ansicht abbildet und ob sie sich auf das richtige Objekt bezieht. Eine separate Quelle kann einen zusätzlichen Abgleich ermöglichen, sofern sie tatsächlich das gewünschte Ergebnis misst.

Der Nachweis muss mit dem passenden Kriterium und Objekt verknüpft sein. Ein erfolgreicher Code-Test belegt nicht automatisch Anforderungen, die er gar nicht abdeckt. Eine Reservierungsbestätigung ist nur dann hilfreich, wenn sie sich auf die angefragte Reservierung bezieht und deren Angaben mit dem Vereinbarten übereinstimmen. Lässt sich diese Verbindung nicht herstellen, sollten Sie die Unsicherheit benennen, statt die Lücken mit Annahmen zu füllen.

Schritt 4: Ausführung und Überprüfung voneinander trennen

Die Komponente, die eine Aktion ausführt, und diejenige, die das Ergebnis prüft, haben unterschiedliche Aufgaben. In einem einfachen Ablauf kann derselbe Agent ein Tool aufrufen und anschließend das betroffene System abfragen. Trotzdem muss der zweite Vorgang eine Beobachtung des Zustands liefern und darf nicht lediglich wiederholen, dass der erste erfolgreich war.

Bei Systemen mit größeren Auswirkungen kann es sinnvoll sein, für die Überprüfung einen anderen Weg als für die Ausführung zu nutzen oder einen Menschen einzubeziehen. Diese Trennung verringert das Risiko, dass dieselbe Antwort zugleich als Aktion und als Beweis behandelt wird. Sie ist keine absolute Regel: Wie viel Trennung angemessen ist, hängt vom Risiko, von der Mehrdeutigkeit der Aufgabe und von der Qualität der verfügbaren Signale ab.

Automatisierung kann ausreichen, wenn die Kriterien eindeutig sind, die Prüfung das relevante Ergebnis abdeckt und mögliche Fehler begrenzte Folgen haben. Eine menschliche Prüfung wird wichtiger, wenn die Anweisungen verschiedene Auslegungen zulassen, erhebliche Folgen drohen, die Nachweise nicht eindeutig sind oder ein Kontexturteil erforderlich ist, das ein automatisierter Test nicht abbildet.

Eine menschliche Prüfung macht eine Schlussfolgerung nicht automatisch richtig. Die prüfende Person muss sehen können, was angefragt wurde, welche Kriterien vereinbart wurden und welche Nachweise vorliegen. Eine Freigabe ohne diese Informationen kann zu einem weiteren unbelegten „Ja“ werden. Die Prüfung sollte eine konkrete offene Frage klären und keine vom Ergebnis losgelöste Formalität sein.

Drei Beispiele Schritt für Schritt

Die folgenden Beispiele veranschaulichen die Methode anhand hypothetischer Kriterien. Sie beschreiben kein bestimmtes Tool und kein konkretes Produkt; die verfügbaren Signale unterscheiden sich je nach System. In jedem Fall kommt es darauf an, eine Annahmebestätigung nicht ohne Prüfung ihrer Bedeutung als Beleg für den Abschluss zu werten.

Bei einer Aktualisierung eines Eintrags kann die Anfrage darin bestehen, ein bestimmtes Feld zu ändern. Die ausgelöste Aktion belegt einen Versuch; eine Annahmebestätigung kann bedeuten, dass das System die Anfrage erhalten hat. Um die Arbeit als abgeschlossen zu bezeichnen, muss der richtige Eintrag beobachtet und der vereinbarte Wert geprüft werden. Wenn außerdem andere Daten erhalten bleiben sollen, müssen sie ebenfalls in die Überprüfung einbezogen werden. Zeigt das System lediglich, dass die Änderung noch aussteht, erfüllt das Ergebnis kein Kriterium, das verlangt, dass der Wert bereits im Eintrag steht.

Bei einer Codeänderung ist die Aufgabe nicht schon dadurch definiert, dass ein Patch erstellt wurde oder eine Erfolgsmeldung vorliegt. Klären Sie vor der Ausführung, welches Verhalten erwartet wird und welche Bedingungen zum Auftrag gehören. Nutzen Sie anschließend passende Prüfungen für dieses Verhalten und überprüfen Sie auch die Kriterien, die von den Tests nicht abgedeckt werden. Dass ein Test ohne Fehler durchläuft, liefert einen Nachweis für das, was dieser Test ausgeführt hat; es beweist nicht automatisch, dass jede funktionale oder qualitative Anforderung des Auftrags erfüllt ist.

Bei einer Reservierung ist es entscheidend, zwischen dem Absenden einer Anfrage und einer Bestätigung zu unterscheiden. Der Agent kann eine Anfrage senden und eine Antwort erhalten, aus der nicht hervorgeht, ob die Reservierung tatsächlich bestätigt wurde. Der Nachweis muss erkennen lassen, um welche Reservierung es geht, und einen Abgleich mit den vereinbarten Details ermöglichen. Liegt nur eine ausstehende Anfrage vor oder lassen sich die erforderlichen Angaben nicht bestätigen, muss die Abschlussmeldung das mitteilen, statt die Reservierung als erledigt darzustellen.

Teilweise, widersprüchliche oder nicht überprüfbare Ergebnisse

Wenn nur ein Teil der Kriterien erfüllt ist, beschreiben Sie diesen Teil als Teilergebnis. Machen Sie aus „Die Aktion wurde angenommen“ nicht „Die Aufgabe ist abgeschlossen“, nur um einen überzeugenderen Abschluss zu bieten. Vermeiden Sie auch das Gegenteil: Wenn gültige Nachweise für einige Anforderungen vorliegen, nennen Sie diese, statt die gesamte Arbeit als unbekannt darzustellen.

Widersprechen sich zwei Signale, sollten Sie erst dann eine Schlussfolgerung ziehen, wenn geklärt ist, was die Signale messen und auf welchen Zustand sie sich beziehen. Eine positive Antwort kann den Eingang der Anfrage bestätigen, während eine andere Beobachtung zeigt, dass sich der Endzustand noch nicht geändert hat. Das muss kein echter Widerspruch sein; möglicherweise beziehen sich die Signale auf unterschiedliche Prozessschritte. Solange die Abweichung jedoch nicht geklärt ist, stützt sie keine uneingeschränkte Erfolgsmeldung.

Gibt es keine geeignete Möglichkeit, das Ergebnis zu beobachten, lautet die richtige Schlussfolgerung: Das Ergebnis konnte nicht überprüft werden. Daraus folgt weder zwangsläufig, dass der Agent gescheitert ist, noch dass er erfolgreich war. Kommunizieren Sie, welche Aktion versucht wurde, welche Antwort vorliegt und welches Kriterium noch offen ist. Fehlende Nachweise zum Endzustand beweisen für sich genommen nicht, welcher Zustand tatsächlich eingetreten ist.

Formulieren Sie die Beschreibung des Ergebnisses so, dass sie dem Nachweis entspricht. „Anfrage gesendet“ ist etwas anderes als „Anfrage angenommen“; „Änderung im Feld beobachtet“ ist etwas anderes als „alle Anforderungen überprüft“; und „ausgewählte Tests abgeschlossen“ ist nicht gleichbedeutend mit „es gibt keine Probleme mehr“. Eine präzise Meldung hilft der empfangenden Person zu entscheiden, ob sie warten, prüfen oder die Aufgabe annehmen sollte.

Checkliste für die Gestaltung eines Ablaufs

Bei der Evaluation von Agenten kann geprüft werden, ob ein System, das Aktionen ausführt, eine Aufgabe zuverlässig erledigt. Tests können helfen, konkrete Ausführungen zu interpretieren. Ein Score, ein Ausführungsstatus oder eine Tool-Antwort ersetzen jedoch nicht die Definition des Ergebnisses, das bei einer bestimmten Aufgabe zählt. Das Team muss die Anfrage in beobachtbare Kriterien übersetzen und jede Schlussfolgerung mit den passenden Nachweisen verknüpfen.

Gehen Sie diese Liste durch, bevor Sie eine Aufgabe als abgeschlossen annehmen oder so kommunizieren. Können Sie eine Frage nicht beantworten, bedeutet das nicht immer, dass die Aufgabe gescheitert ist. Es ist aber ein Hinweis darauf, die Aussage einzugrenzen, fehlende Nachweise zu beschaffen oder eine Prüfung einzuholen, die den möglichen Auswirkungen angemessen ist.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.