Was macht Agent-Selbstevaluation?
Nach der Erledigung einer komplexen Aufgabe hält der Agent inne, um seine eigene Ausgabe anhand einer strukturierten 5-Achsen-Bewertungsmatrix zu bewerten. Dies ist KEIN Bestehen/Nichtbestehen-Tor – es ist ein bewusster Reflexionsschritt, der Auslassungen aufdeckt, übermäßiges Selbstvertrauen markiert und Verbesserungspotenziale aufzeigt, bevor der Benutzer dies tun muss.
Wann zu aktivieren
- Nach dem Schreiben von Code, der 3+ Dateien oder 50+ Zeilen umfasst
- Nach Abschluss eines mehrstufigen Workflows (implementieren → testen → überprüfen)
- Nach einer Debugging-Sitzung mit 3+ Versuchen
- Nach der Erstellung eines Designdokuments, einer Architekturentscheidung oder einer schriftlichen Analyse
- Wenn der Benutzer fragt: „Wie gut war das?“ oder „Bewerte dich selbst“
- Am Ende einer Sitzung, wenn ein Stop-Hook konfiguriert ist (siehe
references/hook-integration.md)
Kernkonzepte
Die 5 Bewertungsachsen
| Achse | Frage | Was wird erfasst |
|---|---|---|
| Genauigkeit | Sind die Fakten, Behauptungen und Ausgaben korrekt? | Halluzinationen, falsche API-Namen, fehlerhafte Syntax, falsche 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, Abschweifungen |
| Handlungsorientierung | Kann der Benutzer die Ausgabe sofort umsetzen? | Vage Vorschläge, fehlende Schritte, „Sie sollten X tun“ ohne zu zeigen wie, fehlender Überprüfungspfad |
| Prägnanz | Wurden die minimal nötigen Wörter/Tokens verwendet? | Redundanz, Übererklärung, wörtliche Wiederholung der Benutzerfrage, Füllinhalt |
Bewertungsskala
5 — Hervorragend: keine vernünftige Verbesserung möglich
4 — Gut: nur geringfügige Spitzfindigkeiten, keine substanziellen Lücken
3 — Ausreichend: erfüllt die Anfrage, hat aber mindestens eine bemerkenswerte Schwäche bei einer Achse
2 — Schwach: hat eine deutliche Lücke, die die Benutzerfreundlichkeit oder Korrektheit beeinträchtigt
1 — Mangelhaft: verfehlt die Anfrage grundlegend oder enthält erhebliche Fehler
Die Belegregel
Jede Note unter 5 MUSS einen spezifischen Beleg anführen. Eine Note von 3 kann nicht einfach sagen „könnte besser sein“ – sie muss genau sagen, was fehlt oder falsch ist. Der Leitspruch: „Zeige die Lücke, benenne sie nicht nur.“
Ablauf
Schritt 1: Sammle das Rohmaterial
Sammle, was du bewerten wirst:
- Die ursprüngliche Benutzeranfrage (aus dem Gesprächsverlauf zurückgelesen)
- Deine endgültige Antwort/Ausgabe (das Arbeitsergebnis)
- Alle Tool-Ausgaben, die die Korrektheit überprüfen (Testergebnisse, Exit-Codes, Lint-Ergebnisse)
- Jegliches während der Aufgabe erhaltene Benutzerfeedback (Korrekturen, „nochmal versuchen“, „das ist nicht richtig“)
Schritt 2: Bewerte jede Achse unabhängig
Gehe die 5 Achsen nacheinander durch. Für jede:
- Lies die Achsenfrage
- Finde Belege (oder deren Fehlen) in der Ausgabe
- Weise eine Note von 1 bis 5 zu
- Falls Note < 5, schreibe einen einzeiligen Verbesserungshinweis mit Verweis auf die Lücke
Bilde NICHT zuerst den Durchschnitt der Noten im Kopf und arbeite dann rückwärts. Bewerte jede Achse frisch.
Schritt 3: Erstelle den Evaluierungsbericht
Verwende die Vorlage aus templates/evaluation-report.md. Der Bericht muss Folgendes enthalten:
- Einzeiler-Zusammenfassung
- 5-Achsen-Bewertungstabelle (Note + Beleg pro Achse)
- Gesamtnote (einfacher Durchschnitt, gerundet auf eine Dezimalstelle)
- 1-3 spezifische Verbesserungen, geordnet nach Auswirkung
- Selbstkontrolle: „Würde der Benutzer dieser Einschätzung zustimmen?“
Schritt 4: Setze die Verbesserung um
Wenn eine Achse mit 3 oder weniger bewertet wurde:
- 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 wurde mit [Grund] bewertet, da [Beleg]. Eine erneute Ausführung mit [spezifische Korrektur] würde die Note wahrscheinlich auf [Note] anheben.“
Codebeispiele
Beispiel: Gute Bewertung (Note 4+)
Aufgabe: Wiederholungslogik zum HTTP-Client hinzufügen
Bewertungstabelle:
Genauigkeit: 5 — Alle API-Aufrufe korrekt. Verifiziert: Wiederholungen
verwenden exponentielle Backoff. Keine halluzinierten Methoden.
Vollständigkeit: 4 — Happy Path + 3 Fehlerfälle abgedeckt. Fehlt:
Timeout-Behandlung für hängende Verbindungen.
Klarheit: 5 — Code-Kommentare erklären die Backoff-Formel.
PR-Beschreibung verlinkt auf den Vorfall, der dies motivierte.
Handlungsorientierung:5 — Ein einzelner Merge. Keine Folgetasks. Tests bestanden.
Prägnanz: 4 — 47 Zeilen insgesamt. Die Wiederholungsschleife könnte in
eine Hilfsfunktion extrahiert werden, um ~8 Zeilen einzusparen.
Gesamtnote: 4.6 — Eine Lücke (Timeout-Behandlung). Vor dem Mergen beheben.
Beispiel: Schwache Bewertung (Note 2-3)
Aufgabe: Wiederholungslogik zum HTTP-Client hinzufügen
Bewertungstabelle:
Genauigkeit: 2 — urllib3 verwendet, das 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 ist lesbar. Gute Variablennamen.
Handlungsorientierung:2 — „Tests hinzufügen“ erwähnt, aber keine Testdatei erstellt.
Benutzer muss vor dem Mergen Tests schreiben.
Prägnanz: 3 — 120 Zeilen. Die Wiederholungskonfiguration ist an
3 Stellen dupliziert statt einem gemeinsamen RetryConfig-Objekt.
Gesamtnote: 2.8 — Falsche Bibliothek verwendet. Benötigt httpx-Neuschreibung.
Zuerst Genauigkeit beheben (zu httpx wechseln), dann auf alle
HTTP-Methoden erweitern, dann Konfiguration zusammenführen.
Anti-Patterns
„Alles ist eine 5“
FEHLER: Genauigkeit: 5 — Alles gut.
Vollständigkeit: 5 — Alles abgedeckt.
Klarheit: 5 — Verständlich.
Kein Beleg angeführt. Dies ist Selbstbeweihräucherung, keine Bewertung. Eine echte 5 erfordert den Nachweis, dass es nichts zu verbessern gibt.
Übermäßiges Bestrafen von 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 angefordert hat, nicht das, was du noch zusätzlich hättest bauen können.
Die Bewertung zur erneuten Diskussion nutzen
FEHLER: „Wie ich bereits sagte, ist dieser Ansatz falsch. Note: 1“
Die Bewertung bezieht sich auf die gelieferte Ausgabe, nicht auf das Wiederaufgreifen von Designentscheidungen, die bereits getroffen wurden. Wenn der Ansatz falsch war, hätte das vor der Lieferung auffallen müssen.
Persönliche Vorlieben mit objektiven Lücken vermischen
FEHLER: „Note: 3. Ich mag Python-Dekorateure nicht.“
„Mag ich nicht“ ist kein Beleg. Nenne ein konkretes Bedenken hinsichtlich Lesbarkeit, Testbarkeit oder Korrektheit, oder belasse die Note bei 4+.
Best Practices
- Bewerte die Ausgabe, nicht den Prozess. Der Benutzer interessiert sich für das, was du geliefert hast, nicht dafür, 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 der Benutzerauswirkung. „Fehlende Fehlerbehandlung führt dazu, dass der API-Aufruf des Benutzers stillschweigend abstürzt“ schlägt „Fehlerbehandlung hinzufügen“.
- Sei konkret, wie „behoben“ aussieht. „Erneute Ausführung mit für Wiederholungen konfiguriertem httpx-Transport“ schlägt „das Bibliotheksproblem beheben“.
- Verwende Tool-Ausgaben als Belege. Wenn Tests bestanden haben, zitiere sie. Wenn Lint sauber ist, zitiere es. Rate nicht – greppe nach dem Beweis.
- Wenn du keine Lücken finden kannst, versuche es härter. Eine perfekte Note über alle 5 Achsen ist selten. Frage: „Wenn ich der Benutzer wäre, was würde mich an dieser Ausgabe stören?“
Verwandte Skills
agent-eval— Direkter Vergleich verschiedener Codierungsagenten bei Benchmark-Aufgabenverification-loop— Systematische Überprüfung von Ausgaben anhand erwarteter Ergebnissesecurity-review— Sicherheitsorientierte Checkliste zur Codeüberprüfung