Self-Critique-Agent-Pattern: Entwurf → Kritik → Revision

Pattern-Kern

Self-Critique Agent ist ein Pattern, bei dem der Agent zuerst einen Entwurf schreibt, dann Risiken und verpflichtende Änderungen nach einem festen Schema erfasst, eine kontrollierte Revision ausführt und genau protokolliert, was sich geändert hat.

Wann sinnvoll: wenn du eine strenge, strukturierte Risikoanalyse und eine kontrollierte Überarbeitung mit Audit-Trail brauchst.

Im Vergleich zu leichtem Reflection ist Self-Critique meist strenger:

• Kritik hat ein festes Format (zum Beispiel JSON)
• Änderungen sind nur nach Regeln erlaubt
• Textwachstum wird begrenzt
• das System speichert ein Änderungsprotokoll (vorher → nachher)

Problem

Stell dir vor, ein Agent erstellt ein Kunden-Update zu einem Problem.

Entwurf:

"Der Release ist wegen eines Ausfalls im Zahlungsmodul verzögert."

Dann kommt die Anfrage:

"Formuliere es bitte etwas weicher."

Ohne Self-Critique-Rahmen macht der Agent oft ein "schönes Umschreiben", das über die Aufgabe hinausgeht:

• fügt neue Annahmen hinzu
• macht den Ton weniger konkret
• bläht den Text über den nötigen Umfang auf
• kaschiert das Problem statt es zu präzisieren

"Formulierung verbessern" darf nicht zu "Bedeutung ändern" werden.

Das Ergebnis:

• die Aussage verschiebt sich unbemerkt
• es ist unklar, was genau korrigiert wurde
• ein Audit kann die Logik der Änderungen nicht rekonstruieren
• die Antwort wird für Entscheidungen weniger verlässlich

Genau das ist das Kernproblem: Während der "Verbesserung" kann der Agent den Inhalt ändern, obwohl er nur die Form ändern sollte.

Lösung

Self-Critique führt eine Regel ein: Es darf nur geändert werden, was in "required changes" steht.

Analogie: wie redaktionelle Korrektur nach einer Kommentarliste. Zuerst fixieren wir, was genau korrigiert werden muss, dann machen wir eine kontrollierte Revision. So wird die Antwort klarer, ohne die Bedeutung zu ändern.

Kernprinzip: erst strukturierte Kritik, dann genau eine kontrollierte Revision mit Audit-Spur.

Der Agent darf Umschreibungen vorschlagen, aber das System erlaubt nur punktuelle Änderungen, die explizit in "required changes" stehen.

Gesteuerter Ablauf:

1. Entwurf: erste Version erzeugen
2. Kritik: Artefakt erstellen (risks + required_changes)
3. Entscheidung: ok/revidieren/eskalieren
4. Revision: genau eine begrenzte Revision ausführen
5. Audit: diff + Metadaten protokollieren

Das bringt:

• bessere Klarheit ohne Faktenänderung
• klare Trennung zwischen "was ist falsch" und "was wurde korrigiert"
• reproduzierbare Revisionen
• Kontrolle über High-Risk-Antworten vor Veröffentlichung

Funktioniert gut, wenn:

• critique eine feste Struktur hat (schema-driven)
• revision auf required_changes begrenzt ist
• no_new_facts erzwungen wird
• Audit-Diff verpflichtend ist

Wie Es Funktioniert

Damit dieses Pattern sicher ist, brauchst du klare Grenzen:

• ein Kritik-Durchlauf
• ein Revisions-Durchlauf
• keine neuen Fakten hinzufügen
• nur Punkte aus required changes bearbeiten
• Text nicht aufblasen (zum Beispiel max. +20%)
• bei hohem Risiko: Stopp oder menschliche Prüfung

Im Code Sieht Das So Aus

draft = writer.generate(goal, context)

critique = critic.review_once(
    draft=draft,
    schema="risks_required_changes_v1",
)

if critique.high_risk:
    return escalate_to_human(critique.reason)

if critique.ok:
    return draft

revised = writer.revise_once(
    draft=draft,
    required_changes=critique.required_changes,
    rules=[
        "no_new_facts",
        "max_length_increase_pct=20",
        "keep_scope",
    ],
)

approved = supervisor.review_output_patch(
    original=draft,
    revised=revised,
    allowed_changes=critique.required_changes,
)

audit.log_diff(
    before=draft,
    after=approved,
    risks=critique.risks,
)

return approved

Self-Critique sollte nicht "bis perfekt" laufen. Ein critique + eine Revision (revise) und eine Prüfung, dass die Revision innerhalb von required_changes blieb.

So Sieht Das Zur Laufzeit Aus

Goal: einen sicheren Maßnahmenplan während eines Netzwerk-Incidents vorschlagen

Draft:
"Das Problem wurde vom Netzwerk verursacht. Wir sollten den gesamten Cluster neu starten."

Critique:
- risk: Aussage zur Ursache ohne Belege
- risk: Aktion hat zu großen Blast Radius (Zustandsänderungen)
- required_change: Prüfungen vor dem Restart ergänzen

Revision:
"Eine wahrscheinliche Ursache ist ein Netzwerkausfall.
Vor dem Neustart des Clusters den Zustand der Knoten und die Latenz prüfen.
Wenn ein Teilausfall bestätigt ist, nur betroffene Knoten neu starten."

Wann Es Passt - Und Wann Nicht

Passt

Passt Nicht

Denn Self-Critique fügt einen zweiten Generierungsschritt hinzu und erhöht die Ausführungskosten.

Unterschied Zu Reflection

Reflection wird häufiger als leichter Filter vor dem Senden genutzt. Self-Critique ist für strengere Kontrolle von Änderungen.

Wann Self-Critique Nutzen (vs Andere Patterns)

Nutze Self-Critique, wenn du tiefe Kritik nach expliziten Kriterien und kontrolliertes Umschreiben brauchst.

Kurzer Test:

• wenn du "nach Checkliste bewerten und Antwort umschreiben" musst -> Self-Critique
• wenn du "nur einen kurzen Check vor dem Senden" brauchst -> Reflection Agent

Kombination Mit Anderen Patterns

• Self-Critique + RAG: Kritik und Revisionen sind nur innerhalb der Fakten aus dem Retrieval-Kontext erlaubt.
• Self-Critique + Supervisor: riskante Änderungen werden nicht automatisch angewendet, sondern zur manuellen Freigabe eskaliert.
• Self-Critique + Reflection: Reflection macht den schnellen Pre-Check, Self-Critique wird für komplexe oder strittige Antworten aktiviert.

Kurzfassung

Vorteile Und Nachteile

FAQ

Q: Kann man mehrere Kritik-Durchläufe machen?
A: Technisch ja, aber das wird schnell ein teurer Loop. Sicherer Baseline-Standard: 1 + 1.

Q: Warum müssen Änderungen zwingend geloggt werden?
A: Ohne diff ist schwer nachvollziehbar, was die Qualität verändert hat und wo der Fehler entstanden ist.

Q: Braucht man ein separates Kritiker-Modell?
A: Manchmal ja, aber nicht zwingend. Wichtiger sind ein strenges Schema, Output-Validierung und harte Revisionsregeln.

Was Danach

Self-Critique verbessert Qualität durch kontrolliertes Umschreiben.

Aber was, wenn die Antwort nicht nur umgeschrieben, sondern vor einer riskanten Aktion gegen Policies geprüft werden muss?