Agents’ Last Exam: Was ein Agent für reale Arbeit misst – und warum seine Erfolgsquote nicht bedeutet, dass er „einen Beruf automatisiert“

Welches Problem Agents’ Last Exam lösen will

Benchmarks für Agenten vereinfachen berufliche Arbeit oft, um sie messbar zu machen: eine Frage mit einer Antwort, eine Codeänderung in einem Repository oder eine isolierte Aktion in einer Benutzeroberfläche. Diese Vereinfachung kann notwendig sein, lässt aber einen wichtigen Teil realer Arbeitsabläufe aus: Dateien vorbereiten, lokale Informationen prüfen, mehrere Anwendungen bedienen, ein Artefakt erzeugen und einen Endzustand hinterlassen, den eine andere Person überprüfen kann.

Agents’ Last Exam, meist ALE abgekürzt, präsentiert sich als Rahmenwerk zur Bewertung von Agenten, die längere berufliche Aufgaben in isolierten Betriebssystemumgebungen ausführen. Die Dokumentation beschreibt eine Einheit aus Agent, Aufgabe und Sandbox-Umgebung. Die Aufgabe besteht nicht nur aus einer Textanweisung: Sie umfasst auch einen Ausgangszustand und einen Mechanismus zur Bewertung des nach der Ausführung erzeugten Ergebnisses.

Diese Veränderung der Messeinheit ist relevant. Statt nur zu fragen, ob ein Modell ein Verfahren kennt, will ALE beobachten, ob eine konkrete Konfiguration eine Aufgabe unter festgelegten Betriebsbedingungen abschließen kann. Zu dieser Konfiguration gehören mindestens das Modell, die Agentenschleife, die bereitgestellten Werkzeuge, die Umgebung, die Ausführungsbeschränkungen und der Evaluator. Das Ergebnis gehört daher zu einer konfigurierten Ausführung, nicht zu einem Modell als abstrakt verstandener Fähigkeit.

Damit kann ALE einer Prüfung von Arbeitsabläufen näherkommen als eine Bewertung isolierter Fähigkeiten. „Näherkommen“ bedeutet jedoch nicht, dass es mit beruflicher Praxis gleichzusetzen ist. Ein Beruf umfasst nicht enthaltene Aufgaben, wechselnde Prioritäten, menschliche Koordination, Verantwortung, Zugriff auf interne Systeme, Sicherheitsrichtlinien und wirtschaftliche Folgen. Eine Sandbox-Bewertung kann Evidenz über Leistung innerhalb dieser Sandbox liefern, ohne all diese Elemente unmittelbar zu messen.

Die tatsächliche Bewertungseinheit: Aufgabe, Umgebung, Harness und Budget

Um ein Ergebnis lesen zu können, muss rekonstruiert werden, was ausgeführt wurde. Die Aufgabe legt Ziel und Ausgangszustand fest. Die Sandbox-Umgebung enthält Dateien, Anwendungen, Daten und Beschränkungen, mit denen der Agent interagieren darf. Der Agent entscheidet seine Aktionen über ein Harness, das das Modell mit Werkzeugen wie Terminal, grafischer Oberfläche, Navigation oder Datei-Lese- und Schreibzugriff verbindet. Schließlich prüft ein Grader das Resultat anhand der für die Aufgabe definierten Kriterien.

Jede dieser Komponenten kann das Ergebnis verändern. Eine scheinbar identische Aufgabe kann einfacher sein, wenn die Umgebung ein vorinstalliertes Hilfsprogramm, Zugangsdaten, lokale Dokumentation oder bereits normalisierte Daten enthält. Sie kann sich ebenfalls verändern, wenn der Agent Screenshots, strukturierte Accessibility-Informationen, Terminalbefehle, einen automatisierten Browser oder eine Kombination davon erhält. Zwei Prozentwerte ohne Kenntnis dieser Bedingungen zu vergleichen, kann einem Modell einen Unterschied zuschreiben, der tatsächlich durch Harness oder Sandbox verursacht wurde.

Auch das Budget ist Teil des Experiments. Zeitlimit, maximale Schrittzahl, erlaubte Kosten, Kontextlänge, Wiederholungsversuche und die Richtlinie für temporäre Fehler beeinflussen die Wahrscheinlichkeit eines erfolgreichen Abschlusses. Ein Agent, der viele Interaktionen benötigt, kann mit einem großzügigen Budget ein hohes Ergebnis erzielen und bei Latenz- oder Kostenlimits nicht praktikabel sein. Umgekehrt kann eine sehr strenge Beschränkung eine Strategie verdecken, die in einem asynchronen Prozess funktionieren würde.

Das offizielle Repository enthält Code, öffentliche Aufgaben und Ausführungsinfrastruktur, während die technische Dokumentation den Zyklus der Aufgabenerstellung und -bewertung erklärt. Das ist eine nützliche Grundlage, um Konfigurationen zu prüfen. Praktische Reproduzierbarkeit erfordert aber die Erfassung exakter Versionen, Parameter, Umgebungsabbilder oder Abhängigkeiten sowie der Ergebnisse je Wiederholung. Dass Code vorhanden ist, garantiert nicht, dass jede historische Ausführung ohne diese Angaben reproduzierbar ist.

Berufliche Abdeckung: 13 Cluster und 55 Subdomänen sind nicht 13 automatisierte Branchen

Die Projektmaterialien beschreiben eine Abdeckung von 55 Subdomänen, die in 13 Clustern gruppiert sind, und verknüpfen ihre Taxonomie mit O*NET und SOC 2018. Diese Entscheidung dient dazu, heterogene berufliche Aufgaben zu ordnen und sichtbar zu machen, dass die Bewertung nicht auf Programmierung oder eine einzelne Desktop-Anwendung begrenzt ist. Sie erlaubt außerdem die Frage, welche Bereiche vertreten sind und welche nur schwach repräsentiert werden.

Die Berufstaxonomie macht eine Sammlung von Aufgaben jedoch nicht automatisch zu einer Messung von Berufen. O*NET klassifiziert und beschreibt Berufe, Kenntnisse, Fähigkeiten, Arbeitsaktivitäten und weitere Arbeitsmerkmale; eine reale Stelle vereint zahlreiche Aufgaben mit unterschiedlicher Häufigkeit, Kritikalität und Kontextabhängigkeit. Eine ausgewählte Aufgabe aus einer Subdomäne kann für einen konkreten Vorgang repräsentativ sein, ohne den gesamten zugehörigen Beruf zu repräsentieren.

Auch eine proportionale Abdeckung sollte nicht daraus abgeleitet werden. Dass ein Cluster vorhanden ist, verrät nicht, wie viele Aufgaben er enthält, welche interne Vielfalt er abdeckt, welchen Schwierigkeitsgrad seine Fälle aufweisen oder welches wirtschaftliche Gewicht sie haben. Für die Bewertung eines eigenen Anwendungsfalls lautet die passende Frage nicht, ob der eigene Sektor auf dem Etikett erscheint, sondern ob der Satz vergleichbare Eingaben, Werkzeuge, Ausnahmen und Qualitätskriterien wie der eigene Prozess enthält.

Die Verbindung zu O*NET kann eine Hilfe für konzeptionelle Nachvollziehbarkeit sein. Sie ermöglicht eine Diskussion darüber, welche Aktivitäten angenähert werden sollten und welche Lücken bleiben. Eine Berufsklassifikation liefert jedoch für sich genommen weder eine Automatisierungsrate noch eine Lohnprognose oder eine Schätzung für Personalabbau. Solche Schlussfolgerungen würden zusätzliche Daten über Einführung, Prozessneugestaltung, Aufsicht, Kosten und dauerhaftes Leistungsvermögen erfordern.

Vollständiger Erfolg, Teilgutschrift und verborgene Referenzen

Die Ergebnisseite unterscheidet zwischen Pass Rate und Score. Nach dieser Definition ist die Pass Rate der Anteil der Ausführungen mit perfekter Punktzahl, während der Score die durchschnittliche Teilgutschrift zusammenfasst. Beide Metriken beantworten unterschiedliche Fragen. Die erste verlangt, dass das Ergebnis das vollständige Aufgabenkriterium erfüllt; die zweite kann abbilden, dass ein Agent teilweise vorangekommen ist, obwohl er kein vollständig gültiges Ergebnis geliefert hat.

Teilgutschrift ist aufschlussreich, besonders um zu diagnostizieren, an welchen Stellen Agenten scheitern. Sie kann anzeigen, dass korrekte Dateien erstellt wurden, aber eine Prüfung fehlte, dass ein Teil des Verfahrens abgeschlossen wurde oder dass sich das Endergebnis dem erwarteten Zustand angenähert hat. Sie sollte jedoch nicht als operativer Erfolg dargestellt werden, wenn der Anwendungsfall eine vollständige Lieferung verlangt. Bei einem Finanzabschluss, einer Datenmigration oder einer Compliance-Aktualisierung kann eine teilweise korrekte Lösung nutzlos sein oder sogar Risiken einführen.

Die Dokumentation zur Aufgabenerstellung erklärt, dass die zur Bewertung verwendete Referenz verborgen bleibt und für die Evaluierung materialisiert wird. Der Grader führt eine Bewertungsfunktion aus, die einen Score zurückgibt, üblicherweise im Intervall von null bis eins. Dieses Design soll verhindern, dass der Agent die für den Evaluator verfügbare Referenzlösung unmittelbar erhält, und ermöglicht deterministische Prüfungen von Artefakten oder Endzuständen.

Dass der Grader deterministisch ist, beseitigt nicht alle Messentscheidungen. Jemand muss festlegen, welche Eigenschaften geprüft werden, welche Toleranz zulässig ist und welches Ergebnis Teilgutschrift verdient. Ein Grader kann bei Wiederholung derselben Eingabe konsistent sein und dennoch nur die formalisierten Bedingungen messen. Die Gültigkeit des Scores hängt ebenso von dieser Definition wie von der Fähigkeit des Agenten ab, Aktionen auszuführen.

CLI, GUI und das Problem, unterschiedliche Agenten zu vergleichen

ALE umfasst Interaktionen über die Kommandozeilenschnittstelle, die grafische Benutzeroberfläche und Konfigurationen, die beides kombinieren können. Die Modalität ist wichtig, weil sie bestimmt, welche Beobachtungen und Aktionen verfügbar sind. Im Terminal kann der Agent Dateistrukturen prüfen, Befehle ausführen und Umwandlungen kompakt automatisieren. In einer grafischen Oberfläche muss er den visuellen Zustand wahrnehmen, Steuerelemente finden und mit Fokuswechseln, Fenstern, Ladezeiten oder mehrdeutigen Elementen umgehen.

Das Leaderboard weist Teilmengen aus, darunter ALE-CLI. Diese Teilmenge kann nützlich sein, um terminalorientierte Agenten zu untersuchen, darf aber nicht als numerisch austauschbare Version der vollständigen Bewertung behandelt werden. Ein CLI-Score schließt Aspekte grafischer Interaktion aus oder reduziert sie; ein kombinierter Score stellt andere Anforderungen. Ein Vergleich ist nur vertretbar, wenn Aufgabensatz, Regeln, Umgebung und Metrik übereinstimmen oder wenn die Unterschiede ausdrücklich offengelegt werden.

Ein generalistischer Computer-Use-Agent wird nicht allein dadurch definiert, dass er einen Cursor bedient. Aus Sicht der Evaluierung ist entscheidend, ob er den relevanten Zustand beobachten, Werkzeuge auswählen, den Kontext einer langen Aufgabe bewahren, sich von unerwarteten Ergebnissen erholen und seine eigene Arbeit überprüfen kann. Ein Harness mit spezialisierten Zusatzwerkzeugen kann die Leistung verbessern; dann bewertet das Ergebnis jedoch das System aus Modell und Werkzeugen, nicht nur die Modellpolitik.

Diese Vorsicht gilt auch gegenüber Terminal-Bench, OSWorld-Verified und SWE-Bench Verified. Jeder Benchmark stellt eine andere Frage und verwendet eigene Aufgaben, Umgebungen und Verifikationsmethoden. Terminal-Bench konzentriert sich auf Terminalaufgaben; OSWorld-Verified untersucht Interaktion mit verifizierten Desktop-Umgebungen; SWE-Bench Verified ist auf die Lösung von Softwareproblemen ausgerichtet. Kein Ergebnis wird automatisch zu einem anderen, nur weil Modell oder Agentenbezeichnung übereinstimmen.

Wie ein Leaderboard oder eine Anbieterankündigung zu lesen ist

Ein Leaderboard bietet eine nützliche Momentaufnahme, aber keine unabhängige Einsatzgarantie. Bevor eine Zahl akzeptiert wird, sollte geprüft werden, ob die ALE-Version, die Teilmenge, die Anzahl bewerteter Aufgaben, die Metrik und die Aggregationsmethode angegeben sind. Ebenso verfügbar sein sollten die genaue Identität von Modell und Harness, die Werkzeuge, die Ausführungslimits und die Richtlinie für Wiederholungen, Infrastrukturfehler oder unvollständige Ausführungen.

Eine Erfolgsrate braucht einen klaren Nenner. Es ist nicht dasselbe, alle verfügbaren Aufgaben zu bewerten, eine Auswahl auszuführen, Fälle mit ungelösten Abhängigkeiten auszulassen oder nur erfolgreiche Ausführungen zu veröffentlichen. Wenn es mehrere Wiederholungen je Aufgabe gibt, muss angegeben werden, ob das Ergebnis den Durchschnitt, den besten Versuch, den ersten Versuch oder eine andere Regel verwendet. Den besten aus mehreren Versuchen zu wählen, kann eine Frage nach maximaler Fähigkeit beantworten, misst aber nicht die Zuverlässigkeit einer einzelnen Ausführung.

Außerdem sollten beobachtete Tatsachen und Interpretation getrennt werden. Eine Tatsache ist, dass eine Konfiguration unter veröffentlichten Regeln eine bestimmte Metrik erreicht hat. Eine mögliche Analyse lautet, dass der Agent für eine bestimmte Art von Aufgaben besonders geeignet erscheint. Der zweite Satz erfordert die Prüfung aufgeschlüsselter Ergebnisse, Fehler und Ähnlichkeit mit dem Zielablauf; er folgt nicht allein aus einer globalen Zahl.

Der Charakter als lebender Benchmark fügt eine weitere Vorsicht hinzu. Wenn Aufgaben, öffentlicher Korpus, Umgebung oder Grader verändert werden, kann eine Zahl zu einem Zeitpunkt nicht mit einer späteren Zahl vergleichbar sein. Das Projekt dokumentiert den lebenden Charakter von ALE und die Existenz eines öffentlichen Korpus. Für längsschnittliche Ergebnisse sind Version und Datum keine redaktionellen Details, sondern Teil der Bedeutung der Daten.

Grenzen von ALE und fehlende Tests vor dem Produktionseinsatz

ALE belegt nicht, dass ein System in einer konkreten Organisation sicher oder zuverlässig ist. Eine Sandbox begrenzt den Umfang und ermöglicht die Prüfung von Endzuständen, bildet aber nicht zwingend Unternehmensidentitäten, sensible Daten, historisch gewachsene Berechtigungen, instabile Integrationen, Audit-Anforderungen oder Auswirkungen auf Kunden nach. Das Fehlen von Zugriff auf reale Systeme kann beabsichtigt und für eine kontrollierte Messung wünschenswert sein, begrenzt aber die Extrapolation.

Ebenso löst ALE für sich allein nicht das Risiko einer Optimierung auf den Benchmark. Die Verfügbarkeit öffentlicher Aufgaben und von Code erleichtert Auditierung und Forschung, kann jedoch erlauben, dass Modelle, Prompts oder Werkzeuge an Regelmäßigkeiten des Satzes angepasst werden. Verborgene Referenzen und Grader verringern eine konkrete Form des Durchsickerns von Antworten; sie belegen nicht, dass es keine Kontamination von Trainingsdaten, keine Vertrautheit mit Aufgabenmustern oder keine indirekte Optimierung gibt. Die verfügbare Evidenz erlaubt es nicht, dieses Risiko für jedes Modell für sich allein zu quantifizieren.

Die Repräsentativität ist eine weitere Grenze. Aufgaben werden ausgewählt und formalisiert; reale Prozesse enthalten Mehrdeutigkeit, Ausnahmen, miteinander kollidierende Ziele und Qualitätsstandards, die sich während der Arbeit verändern können. Ein gutes Ergebnis ist Evidenz dafür, dass der Agent festgelegte Kriterien in den ausgewählten Aufgaben erreicht hat. Um zu schließen, dass er in einem eigenen Prozess funktioniert, ist eine lokale Bewertung mit für diesen Prozess relevanten Daten, Kontrollen und Fehlern erforderlich.

Schließlich berechnet die Metrik keinen wirtschaftlichen Wert. Die Entscheidung über einen Einsatz hängt von Aufsichtszeit, Korrekturraten, Fehlerschwere, Inferenz- und Infrastrukturkosten, Geschwindigkeit, Nachvollziehbarkeit, Datenschutz und Verantwortung ab. Es kann Fälle geben, in denen eine mäßige Leistung mit menschlicher Prüfung nützlich ist, und andere, in denen eine hohe Quote nicht ausreicht, weil ein einzelner Fehler schwerwiegende Folgen hat.

Checkliste für einen eigenen Anwendungsfall

Der Nutzen von ALE steigt, wenn es als Filter und nicht als endgültiges Urteil eingesetzt wird. Erzielt ein Agent gute Ergebnisse bei Aufgaben, die einem eigenen Ablauf nahekommen, gibt es einen Grund, einen internen Test zu entwerfen; erzielt er sie nicht, kann dies ein Risikosignal oder ein zu untersuchender Konfigurationsunterschied sein. In beiden Fällen muss die Übertragbarkeit nachgewiesen und darf nicht vorausgesetzt werden.

Der interne Test sollte repräsentative Beispiele erfassen, einschließlich Normalfällen, seltenen Fällen und behebbaren Fehlern. Er sollte sowohl das Endartefakt als auch den Ablauf bewerten, wenn der Prozess Nachvollziehbarkeit verlangt. Ebenso muss er festlegen, wann eine Person eingreift, welche Aktionen verboten sind, wie Änderungen rückgängig gemacht werden und welche Metriken bestimmen, dass das System nützlich ist, ohne das Risiko über die akzeptable Schwelle zu erhöhen.

Das verantwortungsvollste Ergebnis ist keine Verkündung allgemeiner Autonomie, sondern eine eingegrenzte Aussage: Eine bestimmte Konfiguration kann unter veröffentlichten Bedingungen einen beobachteten Anteil von Aufgaben eines bekannten Satzes abschließen. ALE hilft dabei, diese Aussage anspruchsvoller zu formulieren als ein isoliertes Beispiel. Es ersetzt nicht die technische, operative und organisatorische Validierung, die erforderlich ist, um einen Teil eines realen Prozesses zu automatisieren.

Weiter entdecken

Korrekturen und Transparenz

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