Ein Rechnungsagent liest eine Nachricht eines Lieferanten, bereitet einen Zahlungsauftrag vor und meldet, die Aufgabe sei erfolgreich erledigt. Dieser Satz kann mehrere sehr unterschiedliche Tests beschreiben. Einer prüfte den vorgeschlagenen Auftrag. Ein anderer rief ein simuliertes Zahlungstool auf. Ein dritter untersuchte die daraus entstandene Buchung und die Genehmigung, die sie erlaubte. Jeder Test kann ein nützliches Ergebnis liefern, und jeder stützt eine andere Schlussfolgerung über den Agenten.
Das Szenario dient der Veranschaulichung. Es rahmt eine Forschungsfrage: Welche Schlussfolgerung stützt eine veröffentlichte Agenten-Evaluierung, gemessen an dem System und den Beobachtungen, die sie hervorgebracht haben? Dieser Beitrag bespricht zwei aktuelle Preprints, einen individuellen Internet-Draft und ein älteres Benchmark-Paper, berichtet die Zählung einer veröffentlichten Ergebnisdatei und stellt ein Protokoll der Evaluierungsgrenzen bereit, das jeden zentralen Score begleiten sollte. Dieser Beitrag ist der zweite der Reihe Forschungsnotizen zur Agentenausführung. Die vorherige Notiz behandelt, wie die Erfolgsmeldung eines KI-Agenten seinen Prüfer beeinflussen kann.
Die beabsichtigte Aussage vor der Wahl des Benchmarks festlegen
Agent Evaluation Reliability: More Tasks Won’t (Always) Fix An Agent Leaderboard, ein am 30. September 2026 eingereichtes Preprint von Michael Hardy, Ruhana Azam, Anka Reuel, Mykel Kochenderfer und Sanmi Koyejo, trennt zwei Fragen, die eine Rangliste beantworten kann. Die eine fragt, welches vollständige System höher rangiert. Die andere fragt, welches zugrunde liegende Modell höher rangiert. Die Autoren wenden eine bayessche Varianzzerlegung auf 22 Benchmarks an: neun aus dem Holistic Agent Leaderboard (HAL) und dreizehn aus dem Harbor Index.
Die Autoren berichten, dass Ranglisten fester Systeme aus Modell und Scaffold zuverlässiger waren als Ranglisten der zugrunde liegenden Modelle. Ihre Zuverlässigkeitsmaße beschreiben, wie konsistent eine Rangfolge für die gezogenen Modelle, Scaffolds und Aufgaben bestehen bleibt. Sie sagen nichts darüber aus, wie oft ein Agent eine Aufgabe erledigt, und sie zeigen nicht, ob eine Rangliste die richtige Fähigkeit misst. Ob das Paper angenommen wurde, haben wir nicht geprüft. Zum Paper.
Ein Scaffold ist die Software rund um das Modell: Sie verwaltet den Zustand, stellt Tools bereit und setzt Modellausgaben in Aktionen um. Wer eine vollständige Agentenanwendung auswählt, sollte diese Software in das bewertete System einbeziehen. Ein Team, das ein Ersatzmodell auswählt, sollte dieselbe Software als Bedingung behandeln, die konstant gehalten oder gezielt variiert wird.
Formulieren Sie die beabsichtigte Schlussfolgerung in einem Satz, bevor Sie eine Evaluierung aufbauen oder lesen. Zum Beispiel: „Diese Konfiguration kann aus diesen Dokumenttypen unter dieser Genehmigungsrichtlinie einen autorisierten Zahlungsauftrag vorbereiten.“ Der Satz legt den Workflow, die Aktion und die Bedingungen fest, die die Nachweise abdecken müssen. Eine allgemeine Aussage über die Fähigkeiten eines Agenten bräuchte ein deutlich breiteres Design.
Die getestete Grenze offenlegen
Evaluation Profiles for AI Agent Security Assessment von Han, Chen, Fan und Wu wurde am 23. Oktober 2026 veröffentlicht. Das Dokument ordnet die Evaluierung nach Infrastruktur- und Szenarioprofilen, verlangt von Berichten, die gewählten Profile und ihre Konfiguration anzugeben, und verlangt, nicht anwendbare Metriken ausdrücklich zu kennzeichnen. Es ist Revision 00 eines individuellen Internet-Drafts. Es hat keine Unterstützung der IETF und keinen Status als Standard; hier dient es als konkreter Berichtsvorschlag, der sich noch in Entwicklung befindet. Zum Vorschlag und seinem Status.
Für einen Geschäftsprozess benennt eine Grenzerklärung die Teile des Systems, die das Ergebnis hervorgebracht haben, und die Instanz, die es bewertet hat:
Persistenz braucht eine eigene Zeile. Eine frische Sitzung kann nicht zeigen, wie ein Agent mit Informationen umgeht, die über Sitzungen hinweg mitgeführt werden; dieser Frage geht die Notiz zu Richtlinien im Agentengedächtnis nach. Ein simuliertes Tool stützt Aussagen über die Simulation. Eine Aussage über einen Live-Dienst braucht Nachweise, die die Interaktion mit dem Dienst und den hinterlassenen Zustand abdecken.
- Modell: Snapshot-Kennung und Inferenzeinstellungen.
- Scaffold: die Betriebssoftware und ihre Version.
- Tools und Berechtigungen: welche Tools der Agent aufrufen konnte und was jedes davon ändern durfte.
- Ausgangszustand: der Testfall und wie er zwischen den Fällen zurückgesetzt wurde.
- Wirkungsziele: die Systeme, die Wirkungen empfangen, und ob jedes davon simuliert oder live ist.
- Beobachter: was der Bewerter lesen konnte. Ein Bewerter, der die Konversation des Agenten liest, verfügt über andere Nachweise als ein Beobachter, der nach dem Lauf eine maßgebliche Datenbank ausliest.
Prüfen, was Tools und Bewerter belegen
Do Agent Benchmarks Do What They Say?, ein am 29. September 2026 eingereichtes Preprint von Rohith Reddy Bellibatlu, Zichong Wang und Wenbin Zhang, behandelt das angekündigte Verhalten jedes Tools als Vertrag und prüft die Implementierung dagegen. Über vier Benchmarks berichten die Autoren sieben Tool-Defekte und eine Eigenschaft des Evaluators bei fixierten Commits. Bekannte Defekte haben ihre Auswahl der Benchmarks teilweise bestimmt; die Befunde sind daher Beispiele und ergeben keine allgemeine Defektrate. Der frühere Code-Snapshot der Autoren verwendet andere Begriffe; wir folgen der Klassifikation des Papers. Zum Audit.
Das ältere MedAgentBench-Paper (Version 2, 12. Februar 2025) zeigt eine Grenze, die in seinen eigenen Methoden benannt ist. Sein Evaluierungsaufbau sendet GET-Anfragen an die Umgebung, prüft POST-Payloads und meldet dem Agenten eine erfolgreiche Ausführung; die Bewertung der Aktionen prüft die angeforderte Payload. Die Autoren dokumentieren diesen Aufbau, sodass Leser die Aktionsergebnisse in diesem Rahmen einordnen können. Zu den Originalmethoden, Abschnitte 2.4–2.4.3.
Halten Sie bei einem Rechnungsworkflow vier Stufen auseinander und bewahren Sie jede vorhandene auf. Endet die Evaluierung bei einer davon, machen Sie diesen Endpunkt im Ergebnis sichtbar.
- Vorgeschlagener Auftrag: was der Agent tun wollte.
- Tool-Anfrage: was der Agent tatsächlich gesendet hat.
- Tool-Antwort: was das Tool zurückgemeldet hat. Eine Erfolgsmeldung ist die eigene Aussage des Tools.
- Aufgezeichnete Wirkung: was ein unabhängiger Beobachter danach im führenden System (System of Record) vorgefunden hat.
Ein ausgearbeitetes Grenzprotokoll für eine Lieferantenzahlung
Betrachten Sie einen fiktiven Workflow für Lieferantenzahlungen mit drei Evaluierungsdesigns. Die Eingabe ist fest: Lieferant SUP-042, Rechnung INV-042 über EUR 1.200 und die Anweisung, eine Zahlung vorzubereiten, die ein Finanzsachbearbeiter genehmigen muss, bevor eine Zahlung erfasst wird. Die Zahlungsausführung existiert nur in einer lokalen Simulation. Kein Modell, kein Simulator und kein Zahlungsworkflow wurde ausgeführt, und Modell-Snapshot, Harness (die Testumgebung, die die Evaluierung ausführt) und Evaluator-Versionen sind noch nicht ausgewählt. Die Tabelle ist ein Auszug aus dem vollständigen Protokoll der Evaluierungsgrenzen (auf Englisch).
Lieferant, Betrag und erforderliche Genehmigung sind in allen drei Designs identisch, und die Ergebnisspalten bleiben trotzdem getrennt. Persistentes Gedächtnis bringt neues Verhalten mit, das beobachtet werden muss. Wird der Tool-Host verlegt, verschiebt sich die Stelle, an der Berechtigungen und Wirkungen geprüft werden. Design C führt außerdem zwei Sitzungen aus; sein Ressourcenbudget unterscheidet sich daher, und das Protokoll weist diesen Unterschied aus. Identische Modell-Snapshots allein würden die drei Scores nicht austauschbar machen.
| Feld | A: Vorbereitung des Auftrags | B: Simulation der Genehmigung | C: Simulation eines persistenten Workflows |
|---|---|---|---|
| Tools | Keine | read_invoice, request_approval, record_payment in einer lokalen Simulation | B plus write_supplier_memory und read_supplier_memory |
| Berechtigungsgrenze | Nur Erzeugung der Ausgabe | Simulator prüft Akteur, Identität der Genehmigung, Rechnung und Betrag | B plus Zugriff auf Lieferanten- und Sitzungsgedächtnis |
| Zugang des Evaluators | Eingabe-Testfall und Ausgabe | Testfall, vollständiger Tool-Trace, Entscheidungsdatensatz, Simulatorzustand vorher und nachher | B plus Gedächtnis-Snapshots und Lese- und Schreib-Trace |
| Folgenreiche Wirkung | Es gibt keine Zahlungsoperation | Lokaler Zustandsübergang der Zahlung | Lokaler Zustandsübergang der Zahlung nach persistierten Lesevorgängen |
| Ausschlüsse | Ausführung, Durchsetzung der Genehmigung, Gedächtnis, Netzwerkwirkungen | Echte Zahlungsinfrastruktur, sitzungsübergreifendes Gedächtnis, Delegation | Echte Zahlungsinfrastruktur, Isolation zwischen Benutzern, direkte Manipulation des Speichers, Delegation |
| Erreichbare Aussage nach der Ausführung | Korrekte Vorbereitung für die gelieferten Fälle | Korrektes Verhalten innerhalb der erklärten Simulation | Korrektes Verhalten über die getestete Sitzungsfolge |
| Ausführungsstatus | Nicht ausgeführt | Nicht ausgeführt | Nicht ausgeführt |
Jedem Fall einen Status geben, auch nicht ausgeführten Fällen
Das Protokoll definiert drei Fälle: eine gewöhnliche autorisierte Zahlung, einen Auftrag ohne Genehmigung und eine zweite Sitzung, die einen in der ersten gespeicherten Lieferantendatensatz wiederverwendet. Sie zeigen die beabsichtigte Abdeckung. Sie schätzen nicht, wie oft in der Praxis etwas fehlschlägt, und ihre Auswahl sagt nichts darüber, ob eine Implementierung besteht. Der Fall der zweiten Sitzung testet weder Beschädigung noch Widerruf oder Löschung des gespeicherten Datensatzes, und der Fall der fehlenden Genehmigung liefert keine Schätzung der Robustheit gegen Angriffe.
Jedes Ergebnis erhält eines von fünf Labels. Der Entwurf zu Evaluierungsprofilen verlangt, nicht anwendbare Metriken zu kennzeichnen; das übrige Vokabular ist unser eigener Vorschlag, und keine Gruppe hat es übernommen. In diesem Beispiel ist jedes ausführungsabhängige Ergebnis „Nicht ausgeführt“, und das Protokoll definiert keinen Gesamtscore.
- Veröffentlichen Sie pro Fall die Verfügbarkeit der Nachweise und den Nenner hinter jeder Rate.
- Zählen Sie fehlende Beobachtungen und nicht anwendbare Kontrollen nicht als Erfolg.
| Label | Verwendung |
|---|---|
| Bestanden oder nicht bestanden | Ein definiertes Kriterium, bewertet mit ausreichend aufgezeichneten Beobachtungen |
| Nicht anwendbar | Die Fähigkeit fehlt in der erklärten Konfiguration |
| Nicht erreicht | Die Fähigkeit existiert, und der gewählte Fall hat sie nie erreicht |
| Nicht beobachtet | Die für ein Urteil nötige Beobachtung ist nicht verfügbar |
| Nicht ausgeführt | Die Ausführung hat nicht stattgefunden |
Was wir in den veröffentlichten Daten geprüft haben
Die Autoren des Zuverlässigkeits-Papers veröffentlichen ihre Ergebnisdaten. Wir haben die HAL-Ergebnisdatei aus ihrem Repository bei Commit e7ec464 (29. September 2026) heruntergeladen und mit der Python-Standardbibliothek gezählt: 29.923 Zeilen, 9 Benchmarks, 54 Werte für Modellnamen, 13 Scaffold-Namen und 1.117 unterschiedliche Paare aus Benchmark und Aufgabe, wobei jeder Score entweder 0 oder 1 ist. Diese Dimensionen stimmen mit der Datenbeschreibung des Repositorys überein. Die Modellnamen enthalten Varianten für den Reasoning-Aufwand; 54 ist daher eine Zahl von Kennungen und überzeichnet die Zahl der Basismodelle. Fixiertes Repository, fixierte Datei.
Es handelte sich um eine Datenzählung. Wir haben keinen Agenten erneut ausgeführt, keine Trajektorien untersucht und das statistische Modell nicht neu geschätzt, und die Zählung kann nicht zeigen, dass die Labels und Bewertungen in der Datei korrekt sind. Sie bestätigt Form und Identität der Eingabe, auf der die berichteten Zuverlässigkeitswerte beruhen. Die Zuverlässigkeitswerte selbst bleiben Ergebnisse der Autoren.
Das Grenzprotokoll mit dem Ergebnis veröffentlichen
Hängen Sie das Grenzprotokoll unter derselben Versionskennung an ein Ergebnis an und füllen Sie die Laufdaten aus, sobald die Evaluierung ausgeführt wird:
Ändert sich eine Komponente, führen Sie die Änderung neben dem neuen Ergebnis auf, damit Leser einschätzen können, was ein Vergleich bedeutet. Ein Leser kann dann eine Schlussfolgerung auf eine bestimmte Konfiguration, Aktion und Beobachtung zurückführen, und ein Assurance-Team kann entscheiden, welche weiteren Nachweise sein eigener Workflow braucht.
- Lauf-ID und exakte Versionen: Modell-Snapshot, Harness, Tool-Host, Evaluator und Hash des Datensatzes.
- Sampling-Einstellungen oder Seed, das Ressourcenbudget und der tatsächliche Verbrauch des Laufs.
- Nachweise für das Zurücksetzen, Berechtigungen der Akteure und die Identität jeder Person, die entschieden hat.
- Zugang des Beobachters, Initialisierungsfehler und Ausschlüsse, jeweils mit ihrer Wirkung auf den Nenner.
- Aktions-Trace und Zustandsunterschiede, wobei Erfolgsmeldungen der Tools getrennt von unabhängig beobachteten Wirkungen geführt werden.
- Die auf jeden Fall angewandte Urteilsregel.
Häufig gestellte Fragen
Was misst der Benchmark-Score eines KI-Agenten?
Ein Score misst eine Konfiguration an einer Aufgabenmenge unter einem Bewerter: das Modell und seine Einstellungen, das Scaffold, die Tools und Berechtigungen, den Ausgangszustand und das, was der Bewerter beobachten konnte. Ob er etwas über das Modell allein oder über einen Live-Dienst aussagt, hängt davon ab, wie diese Teile konstant gehalten oder variiert wurden.
Sollte man das KI-Modell oder das gesamte Agentensystem evaluieren?
Richten Sie sich nach der Aussage, die Sie brauchen. Wer eine vollständige Agentenanwendung auswählt, sollte das Modell zusammen mit seinem Scaffold evaluieren. Ein Team, das ein Ersatzmodell auswählt, sollte das Scaffold konstant halten oder gezielt variieren. Ein Preprint von Hardy und Kollegen vom September 2026 berichtet, dass vollständige Systeme in den untersuchten Benchmarks zuverlässiger gerankt wurden als die zugrunde liegenden Modelle.
Was sollte ein Evaluierungsbericht für KI-Agenten enthalten?
Die beabsichtigte Aussage, exakte Versionen von Modell, Scaffold, Tools und Evaluator, Berechtigungen, das Verfahren zum Zurücksetzen, das Ressourcenbudget, den Zugang des Beobachters, Ausschlüsse und Initialisierungsfehler mit ihrer Wirkung auf den Nenner sowie einen Status für jeden Fall: bestanden, nicht bestanden, nicht anwendbar, nicht erreicht, nicht beobachtet oder nicht ausgeführt.
Gibt es einen Standard für Berichte über Sicherheitsevaluierungen von KI-Agenten?
Der in diesem Beitrag besprochene Berichtsvorschlag hat keinen Status als Standard. Evaluation Profiles for AI Agent Security Assessment (23. Oktober 2026) schlägt vor, Infrastruktur- und Szenarioprofile offenzulegen und nicht anwendbare Metriken zu kennzeichnen. Es ist Revision 00 eines individuellen Internet-Drafts ohne Unterstützung der IETF. Das zugehörige Methodikdokument war am 26. Oktober 2026 nicht abrufbar.
Die wichtigsten Erkenntnisse
Ein Benchmark-Score stützt die Schlussfolgerung, die seine Konfiguration und seine Beobachtungen tragen können. Formulieren Sie die beabsichtigte Aussage, legen Sie die Grenze offen, halten Sie Tool-Antworten und aufgezeichnete Wirkungen auseinander und geben Sie jedem Fall einen Status. Beginnen Sie mit dem Protokoll der Evaluierungsgrenzen, und lesen Sie im Audit-Programm für KI-Agenten nach, wie Assurance-Teams die Nachweise hinter Agentenaktionen abgrenzen und Stichproben daraus ziehen.
Die Quellen wurden am 26. Oktober 2026 geprüft. Beide Papers sind Preprints, und ihre Ergebnisse bleiben die der Autoren. Das Dokument zu Evaluierungsprofilen ist ein individueller Internet-Draft ohne Status als Standard. Das ausgearbeitete Protokoll ist synthetisch und nicht ausgeführt; für diesen Beitrag wurde kein Agentenexperiment durchgeführt. Unsere Datenprüfung hat eine veröffentlichte Datei gezählt und kein statistisches Ergebnis reproduziert. Dieser Beitrag enthält kein KLA-Ergebnis.