Was macht Agent-Selbstbewertung?
Nach Abschluss einer komplexen Aufgabe hält der Agent inne, um seine eigene Ausgabe anhand einer strukturierten 5-Achsen-Rubrik zu bewerten. Dies ist KEIN Bestehen/Nichtbestehen-Tor – es ist ein bewusster Reflexionsschritt, der Auslassungen erkennt, Übermut signalisiert und Verbesserungsbereiche aufzeigt, bevor der Benutzer eingreifen muss.
Wann aktivieren
- Nach dem Schreiben von Code, der 3+ Dateien oder 50+ Zeilen umfasst
- Nach Abschluss eines mehrstufigen Workflows (implementieren → testen → reviewen)
- Nach einer Debugging-Sitzung mit 3+ Versuchen
- Nach der Erstellung eines Entwurfsdokuments, einer Architekturentscheidung oder einer schriftlichen Analyse
- Wenn der Benutzer fragt "Wie gut war das?" oder "Bewerte dich selbst"
- Am Ende eines beliebigen Sessions-Stop-Hooks (falls konfiguriert – siehe
references/hook-integration.md)
Kernkonzepte
Die 5 Bewertungsachsen
| Achse | Frage | Was sie erfasst |
|---|---|---|
| Genauigkeit | Sind die Fakten, Behauptungen und Ergebnisse korrekt? | Halluzinationen, falsche API-Namen, falsche Syntax, unwahre Aussagen |
| Vollständigkeit | Wurde alles abgedeckt, was der Benutzer verlangt hat? | Fehlende Randfälle, unbehandelte Fehlerpfade, vergessene Anforderungen, übersprungene Teilaufgaben |
| Klarheit | Ist die Erklärung verständlich und gut strukturiert? | Verwirrende Erklärungen, Fachjargon ohne Definition, fehlender Kontext, abschweifende Formulierungen |
| Handlungsorientierung | Kann der Benutzer sofort auf die Ausgabe handeln? | Vage Vorschläge, fehlende Schritte, "Sie sollten X tun" ohne Anleitung, kein Verifikationspfad |
| Prägnanz | Wurde die minimal nötige Anzahl an Wörtern/Tokens verwendet? | Redundanz, Übererklärung, wörtliche Wiederholung der Benutzerfrage, Füllinhalte |
Bewertungsskala
5 – Hervorragend: Keine sinnvolle Verbesserung möglich
4 – Gut: Nur kleine Kleinigkeiten, keine wesentlichen Lücken
3 – Ausreichend: Erfüllt die Anfrage, hat aber auf mindestens einer Achse eine merkliche Schwäche
2 – Schwach: Hat eine klare Lücke, die Nutzbarkeit oder Korrektheit beeinträchtigt
1 – Mangelhaft: Verfehlt die Anfrage grundlegend oder enthält schwerwiegende Fehler
Die Belegregel
Jede Bewertung unter 5 MUSS einen konkreten Beleg angeben. Eine 3 kann nicht einfach "könnte besser sein" sagen – sie muss genau sagen, was fehlt oder falsch ist. Das Mantra: "Zeige die Lücke, nenne sie nicht nur."
Workflow
Schritt 1: Sammle das Rohmaterial
Sammle, was du bewerten wirst:
- Die ursprüngliche Benutzeranfrage (aus dem Chatverlauf abgerufen)
- Deine endgültige Antwort/Ausgabe (das Arbeitsergebnis)
- Alle Tool-Ausgaben, die Korrektheit belegen (Testergebnisse, Exit-Codes, Lint-Ausgaben)
- Jedes während der Aufgabe erhaltene Benutzerfeedback (Korrekturen, "Versuch es nochmal", "Das ist nicht richtig")
Schritt 2: Bewerte jede Achse unabhängig
Gehe die 5 Achsen einzeln durch. Für jede:
- Lies die Achsen-Frage
- Finde Belege (oder deren Fehlen) in der Ausgabe
- Weise eine Punktzahl von 1-5 zu
- Wenn die Punktzahl < 5 ist, schreibe einen ein-satzigen Verbesserungshinweis, der die Lücke benennt
Bilde NICHT zuerst einen Durchschnitt im Kopf und arbeite dich dann rückwärts. Bewerte jede Achse frisch.
Schritt 3: Erstelle den Bewertungsbericht
Verwende die Vorlage aus templates/evaluation-report.md. Der Bericht muss enthalten:
- Einzeilige Zusammenfassung
- 5-Achsen-Bewertungstabelle (Punktzahl + Beleg pro Achse)
- Gesamtpunktzahl (einfacher Durchschnitt, gerundet auf 1 Dezimalstelle)
- 1-3 spezifische Verbesserungen, geordnet nach Auswirkung
- Selbstprüfung: "Würde der Benutzer dieser Einschätzung zustimmen?"
Schritt 4: Wende die Verbesserung an
Wenn eine Achse 3 oder weniger erreicht hat:
- Gib an, was du anders machen würdest
- Wenn die Lücke in < 30 Sekunden behebbar ist (fehlender Link, unklare Formulierung), behebe sie jetzt
- Wenn die Lücke eine Überarbeitung erfordert, kennzeichne sie explizit: "Diese Achse erreichte [Grund] wegen [Beleg]. Eine erneute Ausführung mit [spezifische Korrektur] würde sie wahrscheinlich auf [Punktzahl] anheben."
Code-Beispiele
Beispiel: Gute Bewertung (Punktzahl 4+)
Aufgabe: Wiederholungslogik zum HTTP-Client hinzufügen
Bewertungstabelle:
Genauigkeit: 5 – Alle API-Aufrufe korrekt. Verifiziert: Wiederholungen
verwenden exponentiellen Backoff. Keine halluzinierten Methoden.
Vollständigkeit: 4 – Happy Path + 3 Fehlerfälle abgedeckt. Fehlt:
Timeout-Handling für hängende Verbindungen.
Klarheit: 5 – Code-Kommentare erklären Backoff-Formel.
PR-Beschreibung verlinkt auf den Vorfall, der dies motivierte.
Handlungsorientierung: 5 – Einfacher Merge. Keine Folgetasks. Tests bestanden.
Prägnanz: 4 – 47 Zeilen insgesamt. Die Wiederholungsschleife könnte
in einen Helfer extrahiert werden, um ~8 Zeilen zu sparen.
Gesamt: 4,6 – Eine Lücke (Timeout-Handling). Vor Merge beheben.
Beispiel: Schwache Bewertung (Punktzahl 2-3)
Aufgabe: Wiederholungslogik zum HTTP-Client hinzufügen
Bewertungstabelle:
Genauigkeit: 2 – urllib3 verwendet, was nicht zu unserer
httpx-basierten Codebasis passt. Falsche Bibliothek.
Vollständigkeit: 3 – Funktioniert für GET. POST/PUT nicht behandelt
(Benutzer sagte "alle HTTP-Anfragen").
Klarheit: 4 – Code lesbar. Gute Variablennamen.
Handlungsorientierung: 2 – "Tests hinzufügen" erwähnt, aber keine Testdatei erstellt.
Benutzer muss vor Merge Tests schreiben.
Prägnanz: 3 – 120 Zeilen. Die Wiederholungskonfiguration ist an
3 Stellen dupliziert statt einem gemeinsamen RetryConfig-Objekt.
Gesamt: 2,8 – Falsche Bibliothek verwendet. Benötigt httpx-Neuschreibung.
Zuerst Genauigkeit beheben (zu httpx wechseln),
dann auf alle HTTP-Methoden erweitern,
dann Konfiguration konsolidieren.
Anti-Patterns
"Alles ist eine 5"
FEHLER: Genauigkeit: 5 – Alles gut.
Vollständigkeit: 5 – Alles abgedeckt.
Klarheit: 5 – Verständlich.
Keine Belege angeführt. Das ist Selbstbeweihräucherung, keine Bewertung. Eine echte 5 erfordert den Nachweis, dass es nichts zu verbessern gibt.
Übermäßige Bestrafung für Scope Creep
FEHLER: Vollständigkeit: 2 – WebSocket-Verbindungen oder
gRPC-Streaming nicht behandelt (Benutzer hat nicht danach gefragt)
Bewerte nur das, was der Benutzer tatsächlich verlangt hat, nicht das, was du zusätzlich hättest bauen können.
Die Bewertung nutzen, um Entscheidungen neu zu verhandeln
FEHLER: "Wie ich bereits sagte, ist dieser Ansatz falsch. Punktzahl: 1"
Die Bewertung bezieht sich auf die gelieferte Ausgabe, nicht auf eine erneute Diskussion von Designentscheidungen, die bereits getroffen wurden. Wenn der Ansatz falsch war, hätte das vor der Auslieferung erkannt werden müssen.
Vermischung von persönlichen Vorlieben mit objektiven Lücken
FEHLER: "Punktzahl: 3. Ich mag keine Python-Dekorateure."
"Mag ich nicht" ist kein Beleg. Nenne ein konkretes Problem mit Lesbarkeit, Testbarkeit oder Korrektheit, oder belasse die Punktzahl bei 4+.
Best Practices
- Bewerte das Ergebnis, nicht den Prozess. Dem Benutzer liegt daran, was du geliefert hast, nicht wie viele Iterationen du gebraucht hast.
- Eine Verbesserung pro schwacher Achse. Liste nicht 5 Dinge für eine Achse auf – wähle die Lücke mit der höchsten Auswirkung.
- Verknüpfe Verbesserungen mit Benutzerauswirkungen. "Fehlende Fehlerbehandlung bedeutet, dass der API-Aufruf des Benutzers stillschweigend abstürzt" ist besser als "Fehlerbehandlung hinzufügen".
- Sei spezifisch, wie 'behoben' aussieht. "Erneut ausführen mit httpx-Transport, der für Wiederholungen konfiguriert ist" ist besser als "das Bibliotheksproblem beheben".
- Verwende Tool-Ausgaben als Belege. Wenn Tests bestanden haben, führe sie an. Wenn der Lint sauber ist, führe ihn an. Rate nicht – grepe nach dem Beweis.
- Wenn du keine Lücken finden kannst, versuche es härter. Eine perfekte Punktzahl auf allen 5 Achsen ist selten. Frage: "Wenn ich der Benutzer wäre, was würde mich an dieser Ausgabe stören?"
Verwandte Fähigkeiten
agent-eval– Direkter Vergleich verschiedener Coding-Agenten bei Benchmark-Aufgabenverification-loop– Systematische Verifikation von Ausgaben gegen erwartete Ergebnissesecurity-review– Sicherheitsorientierte Code-Review-Checkliste